Amazon Lumberyard: A Scream of Anguish(viva64.com)
viva64.com
Amazon Lumberyard: A Scream of Anguish
https://www.viva64.com/en/b/0574/
57 comments
> not actually make them on your OWN fork? Clickbait, gross.
Yup. Something like :
> You have bugs in your codebase of 1M+ line, you want to fix them ? Buy my proprietary software for 30$/Month per user , which was built 100% on open source tech obviously.
Getting traffic using linting issues from a large codebase to promote a proprietary software , Outrageous.
Yup. Something like :
> You have bugs in your codebase of 1M+ line, you want to fix them ? Buy my proprietary software for 30$/Month per user , which was built 100% on open source tech obviously.
Getting traffic using linting issues from a large codebase to promote a proprietary software , Outrageous.
Well that is what happens when releasing open source tech with licenses that support this kind of behavior, nothing to be outrageous about.
[deleted]
One thing that puzzles is me is why some of these checks aren't just part of the warnings that a compiler emits. I get that you wouldn't want to enable them all the time, but usually comparing a variable to itself is not what you want.
gcc and clang have been getting better at this recently. For instance if you do an "x == x" comparison for an int x clang will warn "warning: self-comparison always evaluates to true [-Wtautological-compare]".
I completely agree that having these warnings in the compiler is much better than a standalone analysis tool, because they're less likely to be ignored. But I think it may have been a bit of a shift of mindset for the compiler developers to put more effort into warnings and diagnosing dubious code rather than simply being a code generator for correct code.
I completely agree that having these warnings in the compiler is much better than a standalone analysis tool, because they're less likely to be ignored. But I think it may have been a bit of a shift of mindset for the compiler developers to put more effort into warnings and diagnosing dubious code rather than simply being a code generator for correct code.
Lint exists since 1979.
Everything that is outsourced for an external tool, just happens not to be used by the majority.
Clearly the introduction of clang and its sanitizers has changed a bit the mindset, however they are still used by a minority.
As per CppCon 2016, 1% of the audience confirmed they were using some kind of validation tool.
Everything that is outsourced for an external tool, just happens not to be used by the majority.
Clearly the introduction of clang and its sanitizers has changed a bit the mindset, however they are still used by a minority.
As per CppCon 2016, 1% of the audience confirmed they were using some kind of validation tool.
I agree, but my sense is that the number of people and projects willing to fix complaints reported by compiler warnings is larger than the number of people who care enough to run a separate tool over their codebase. This is purely a UI thing -- if the compiler had a -Wlint option that ran lint and integrated its reports into its own warning output it would probably have a similar effect, especially if enabled by default...
To add on this, clang-tidy is a tool specifically for static code analysis. I don't know if it implements all the checks mentioned in the article, but it is quite powerful, being able to detect eg. array overruns through several layers of function calls and ifs.
You're right, but just a fun edge-case to think about (in JS):
NaN === NaN // -> false
Better to use `Number.isNaN()`
Sure, and there are cases where you may been reading from some volatile register or something. But that's why I mentioned that this is usually what you want, not always :)
Two main reasons: Many warnings that a static analyzer will emit are quite costly to detect, so the compilation would get slower. And since compilation speed is an important benchmark (if not the most important), one would usually not sacrifice this for some warning.
Also, people usually do not accept false-positives in compiler warnings. Static analyzers often have heuristics to detect typos like these:
a.x = x;
a.y = y;
a.y = z; <==
That is why it should at very least, be turned on the CI server.
One of the best blog-ads for a product I've seen in a long time.
It effectively shows value of their software while being interesting enough and relevant to something popular that already has (some) following. Perfect.
Makes me wish they had something similar for JS or Python. I know I've made these mistakes all too often.
It effectively shows value of their software while being interesting enough and relevant to something popular that already has (some) following. Perfect.
Makes me wish they had something similar for JS or Python. I know I've made these mistakes all too often.
If it wasn't obvious from the URL, OP is more about a code analyzer product than Amazon Lumber, mentioned in passing as an example usage.
Yeah. I think the analyzer is pretty neat. It's cool to focus on human mistakes writing code rather than validity of code itself. I see a bunch of errors I've made before, especially when copying and pasting. Time to find something like this for vscode to do realtime linting of human errors.
That being said, I think this article really overstates the dire state of Lumberyard. Yep, it has bugs. I don't think this convinces me that the sky is falling if the devs don't change their ways.
That being said, I think this article really overstates the dire state of Lumberyard. Yep, it has bugs. I don't think this convinces me that the sky is falling if the devs don't change their ways.
The posts from these guys are pure BLACKMAIL.
I work at one of the companies who's product they "reviewed" and many of us got unsolicited emails basically saying, we found all these bugs using our code analyzer. Buy a license from us to fix them or we will post a negative review of your code.
It's a horrible business practice and they do that with many open source products. This behavior shouldn't be praised.
I work at one of the companies who's product they "reviewed" and many of us got unsolicited emails basically saying, we found all these bugs using our code analyzer. Buy a license from us to fix them or we will post a negative review of your code.
It's a horrible business practice and they do that with many open source products. This behavior shouldn't be praised.
No, that's not blackmail. You can only blackmail through exclusive knowledge. If they tested your code, then I'll assume your code is out there in the open, so anyone can run your code through a static analyzer and write a blog post about it.
Yes, these posts are advertisements for PVS-Studio, and since they frequently land on HN, they obviously work for them. Besides, you don't even have to buy PVS-Studio, since the Demo already will show you the complete analyzer output, you just won't be able to directly jump to the source.
Yes, these posts are advertisements for PVS-Studio, and since they frequently land on HN, they obviously work for them. Besides, you don't even have to buy PVS-Studio, since the Demo already will show you the complete analyzer output, you just won't be able to directly jump to the source.
I understand why you feel bad about them, and certainly I would feel the same in the same situation, but it's hard not to admit that revealing bugs to the public is very often the only way to make coders pay attention. So even if their intention is only to squeeze money out of targeted companies, at the end of the day they force devs to eliminate bugs this way, or another. Which is good for users, I suppose.
Just tell them you'll use sonarqube[0] from now on. I mean, what is the point of using proprietary software when the opensource alternative is better?
[0]https://www.sonarqube.org/
[0]https://www.sonarqube.org/
Judging by the errors they describe the code in question really wants some static analyzer love. Even the free/OSS ones can handle 'em. x==x, true || true, etc...
Blackmail or not, this is stupid.
Blackmail or not, this is stupid.
Maybe something got lost in translation? "Fix the bugs or we will publish" seems to be standard operating procedure for security researchers who randomly find a vulnerability. Maybe they just wanted to tell you that you'd be able to use their tool to fix those bugs more easily.
The difference to me is whether they list all the bugs (while suggesting that their product would help) to the developer before publishing or not. If the only way to satisfy them is to pay, then it's incredibly scummy and moreover is a big disincentive for companies to open their source code. After all, every code base has bugs and I'm sure their developers were working on fixing bugs already, but only open source projects can be extorted over their bugs.
Developers of the project can write in support and ask for a full log for free.
In this case, they shouldn’t have to ask. If you’re going to provide a vulnerability report, provide a vulnerability report. Don’t dance around it to see if you can make money first.
Vulnerability is always a Bug.
Weakness is always a Bug.
Weakness is sometimes a Vulnerability.
Bug is sometimes a Weakness and a Vulnerability.
Vulnerability != Weakness!
Vulnerability != Weakness!
I'm not a lawyer, so I don't know if calling it blackmail is hyperbole.
If it really is blackmail, have you contacted a law-enforcement agency?
If it really is blackmail, have you contacted a law-enforcement agency?
That's Russia for you.
That's ANY shady son of a bitch for you, really.
That's ANY shady son of a bitch for you, really.
>That's Russia for you.
Yes, it could not happen elsewhere, e.g:
https://www.xdesk.com/wirecutter-standing-desk-review-pay-to...
(And from a NYT backed website, nonetheless)
>That's ANY shady son of a bitch for you, really.
Better.
Yes, it could not happen elsewhere, e.g:
https://www.xdesk.com/wirecutter-standing-desk-review-pay-to...
(And from a NYT backed website, nonetheless)
>That's ANY shady son of a bitch for you, really.
Better.
REALLY disappointed to read this about The Wirecutter.
From context, Lams use of “kickbacks” in the email refers to Amazon affiliate payments. It’s a freakishly poor choice of words but hardly scandalous.
It clearly does not apply to Amazon affiliate payments only, but is asking for a specific affiliate program with the manufacturer being set up - if it were Amazon affiliates, there'd be no need for them to be involved.
The optics of asking for that and after being denied changing the recommendation (presumably to something where they do get affiliate payouts) are quite bad.
That's a problem for the Wirecutter with products not available on Amazon: their (IMHO reasonable) argument has been that since they get the payout from a Amazon and not the individual vendors, they have no incentive to recommend a product that's not the best, since they get paid for whatever they recommend. This only works as long as everything tested is on Amazon. As soon as they start creating individual agreements with manufacturers, it becomes a lot less obvious that they can be trusted to not optimize for the most profitable affiliate terms. (Maybe there'd be something about having a policy that all agreements have to be the same, but that's tricky)
The optics of asking for that and after being denied changing the recommendation (presumably to something where they do get affiliate payouts) are quite bad.
That's a problem for the Wirecutter with products not available on Amazon: their (IMHO reasonable) argument has been that since they get the payout from a Amazon and not the individual vendors, they have no incentive to recommend a product that's not the best, since they get paid for whatever they recommend. This only works as long as everything tested is on Amazon. As soon as they start creating individual agreements with manufacturers, it becomes a lot less obvious that they can be trusted to not optimize for the most profitable affiliate terms. (Maybe there'd be something about having a policy that all agreements have to be the same, but that's tricky)
Yeah, me too. Thought they were a legit site, and always checked them for 3-4 things I've bought they cover. Now I see them as any other site, to be read with a grain of salt.
You are saying you and your company do not want to fix your buggy code but at the same time you do not want your customers/users to know that your product contains buggy code. Interesting.
Not what I said. Will gladly fix bugs someone discovers. You can also freely point them out, you can even publish them if you want to bring it to our attention. You can even use it to sell your code analysis tool. That's cool with me.
But don't email me asking for money and threatening to write a bad review if I don't do as you say.
But don't email me asking for money and threatening to write a bad review if I don't do as you say.
Why would anyone choose Lumberyard over CryEngine directly? I would think that ones core product will always be better maintained then just some side project that was bought in.
Well, Crytek's financial state isn't the most stable for one. Also Lumberyard's aim is to replace pretty much everything in the long run, some parts of the CryEngine are quite...interesting compared to other engines and the work Amazon has done for example regarding animation and workflow improvements has been great.
I haven't used either.
Cryengine is notoriously difficult to use. Crytek have also had severe financial difficulties. Amazon have their own team working on the source, I'm not sure how this has worked out but clearly amazon have plenty of resources to throw at it if they choose to.
Cryengine is notoriously difficult to use. Crytek have also had severe financial difficulties. Amazon have their own team working on the source, I'm not sure how this has worked out but clearly amazon have plenty of resources to throw at it if they choose to.
Crytek recently (and it may still be going on) sued Cloud Imperium Games (CIG, the people behind StarCitizen) for switching from Cryengine to Lumberyard.
The details are few and far between, but the possibility or being sued by the vendor would be a bit off putting for me.
The details are few and far between, but the possibility or being sued by the vendor would be a bit off putting for me.
I remember reading about this and being left with the impression that CryTek was in the green there. Don't remember any details, but it wasn't as ugly as it sounds, though I also got the impression that CryTek weren't entirely graceful.
I think you might have written CryTek there when you meant CIG so I'm not sure quite what you meant. Was it:
> I remember reading about this and being left with the impression that [CIG] was in the green there.
If so, ISTR CIG is fine, but then they have a lot of money and fancy lawyers, a lot of smaller companies might have fared less well, and it doesn't really look good when a vendor is seen to be suing their customers because it is rumoured they are running out of money.
> I remember reading about this and being left with the impression that [CIG] was in the green there.
If so, ISTR CIG is fine, but then they have a lot of money and fancy lawyers, a lot of smaller companies might have fared less well, and it doesn't really look good when a vendor is seen to be suing their customers because it is rumoured they are running out of money.
No, I meant CryTek. RPG explains: https://www.google.com/amp/s/www.rockpapershotgun.com/2017/1...
Would someone like Unreal have swallowed that from a client in order to avoid bad PR? Possibly. But if the allegations are true then I wouldn't go so far as to expect (in the moral sense) CryTek to let it slide.
Would someone like Unreal have swallowed that from a client in order to avoid bad PR? Possibly. But if the allegations are true then I wouldn't go so far as to expect (in the moral sense) CryTek to let it slide.
I'm not sure that CryTek have the moral high ground here as you seem to suggest.
CIG have moved to Lumberyard, a tech based on CryEngine, so lines of similar looking code are seemingly expected.
And the license was negotiated for a single game, not two as StarCitizen now is, but this would seem to be negated by the fact that these games are no-longer using CryEngine.
On the subject of CIG passing back engine improvements or not to CryEngine, I don't know.
CIG have moved to Lumberyard, a tech based on CryEngine, so lines of similar looking code are seemingly expected.
And the license was negotiated for a single game, not two as StarCitizen now is, but this would seem to be negated by the fact that these games are no-longer using CryEngine.
On the subject of CIG passing back engine improvements or not to CryEngine, I don't know.
E.g. because Amazon might still be around next week? This hasn't been a given regarding Crytec for quite a while now.
Intel is still around but a number of game technologies they bought are not anymore. Lumberyard appears to be rather far from the core (or even the periphery) of Amazon's business, so it's a valid concern.
I believe lumberyard also offers direct integration with AWS.
This is really, really poorly written.
Never heard of Amazon Lumberyard. I thought this post was going to be about them entering the market, and Home Depot/Lowes worrying.
what's the value add of Lumberyard over Cryengine? you'd think the netcode would be the selling point.
AWS integration and everything that goes with it (scaling), Twitch.tv integration etc.
https://aws.amazon.com/lumberyard/details/
https://aws.amazon.com/lumberyard/details/
More integration and hegemony in the Amazon behemoth. Is this what we want?
tl;dr:
Ran static analysis tool author is trying to sell on a 1 million+ line code base for Amazon's open source game engine Lumberyard.
Found warnings. Used it to infer quality of the product and wrote a very click-bait title.
Ran static analysis tool author is trying to sell on a 1 million+ line code base for Amazon's open source game engine Lumberyard.
Found warnings. Used it to infer quality of the product and wrote a very click-bait title.
The funny thing is, the code wasn't even written by Amazon.
They just bought it. Maybe the new team will clean up the code of Crytek?
They just bought it. Maybe the new team will clean up the code of Crytek?
The version lumberyard started with a 2016 engine, a few revisions behind Crytek's current engine. Crytek had fixed some of the logic bombs, as mentioned in the article, in their current release.
Similar to linting, where often I need variation in rules, sometimes there's red herrings even in static code analysis.
Game software in general can be fly-by-the-wind because it's real-world software
... of course this is all me reacting and trying to argue with the clickbait :/