3 ms·
Yes, "big, big, biggity-big". But not an excuse. Nobody forced hypertrophy on Google. Google has access to plenty of money to manage its problems. But size is n
by ncmncm 4y ago
Yes, "big, big, biggity-big". But not an excuse. Nobody forced hypertrophy on Google. Google has access to plenty of money to manage its problems. But size is not the problem, and access to money does not seem to forestall it.
Insisting everybody else in the world has all your problems too can make your management failures seem excusable. But management failure can happen anywhere. It is evidently happening at Google. Software faults are a symptom. I don't know how they can fix the management problem that washed up as billions of lines of bad code.
I do know pretending won't help.
- Arnt 4y agoGoogle seems to manage its problems well; the search engine is very likely the world's biggest and most complex software system and its uptime is excellent. People who deliver that kind of uptime with such a complicated system may be assumed to know their work and do it well.
- ncmncm 4y agoYour assessment is at odds with their own statements. Google can be assumed to know the hole they are in. The mistake is thinking everybody else is in it too.
- ChrisLomont 4y ago>The mistake is thinking everybody else is in it too Which project of similar size doesn't have bugs? You seem to imply most don't, which is empirically untrue. https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=bugs+per+line+of+code&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=bug...
- ncmncm 4y agoWe are not talking about bugs in general, but about a specific sort of bug common in C and Google code.
- ChrisLomont 4y agoFrom the literature on bugs, even this specific bug is common far beyond "C and Google code". And, if you really want to restrict to your goalpost moving subset, then go ahead and demonstrate that the above general trends are not trends in your subset. Because the literature on it disagrees with you. So, to defend your claim "The mistake is thinking everybody else is in it too", care to show where "everybody else" is free from these bugs? https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=use+after+free+bugs&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C15&q=use... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+free https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=use+after+f...
- ncmncm 4y agoYou reveal that you never had any intention of engaging honestly. This is the very first line from the very first post in the thread: >> It’s hard, if not impossible, to avoid use-after-frees in a non-trivial codebase.
- ChrisLomont 4y agoYes, and you replied "Nice excuse. But just wholly untrue." I just provided thousands of examples where it is true. To offset all that evidence can you provide, say, millions of examples where zero (your phrase) use-after-free bugs have been found? >You reveal that you never had any intention of engaging honestly. Honest engaging would be for you to provide evidence for a claim you made when asked. I provided extremely solid counter evidence from the result of many, many research teams. So, care to honestly engage about your claim?