Stats for nerds
0recommend
10mentions
3people
2013–2026years
100% neutral
Mentions per year
What Hacker News says
- ESR's "many eyes" quote in his "Linus's Law" is unmitigated bullshit. And Linux Torvalds should not be blamed for it, since it wasn't his law, ESR just named it after him to get attention. Hardly anyone actually reads code, and the few people actually qualified to find bugs by reading huge piles of buggy code dumped into the public domain when a company abandons it have much more important things to do with their time.
If the many eyes that Macromedia and Adobe paid to work full time on Flash couldn't prevent the need to push out Flash security patches several times a week, the code is fundamentally flawed far beyond the point that the few much less qualified people who might actually take their unpaid spare time to look at it are able to finally find and fix all the bugs.
The major browser developers have enough on their hands designing new open standards and writing and debugging new code, without having to spend any of their time burning their eyes and brains looking at free abandoned obsolete toxic waste code dumps. And ESR certainly isn't going to chip in and help them.
https://news.ycombinator.com/item?id=43133598
>He made up the ridiculous "many eyes" quote himself, then misnamed it "Linus's Law" to avoid personal responsibility and shift the blame to innocent Linus Torvalds, who never said such a stupid thing, and which HeartBleed and many other eyeballable bugs proved terribly wrong and misguided.
>About which the salty security expert Theo de Raadt famously said "Oh right, let's hear some of that "many eyes" crap again. My favorite part of the "many eyes" argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code."
https://en.wikipedia.org/wiki/Linus%27s_law
>In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.[4] While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".[5]
>The persistence of the Heartbleed security bug in a critical piece of code for two years has been considered a refutation of Raymond's dictum.[6][7][8][9] Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain.[9] In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking".[8] Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.[10]
>Empirical support of the validity of Linus's law[11] was obtained by comparing popular and unpopular projects of the same organization. Popular projects are projects with the top 5% of GitHub stars (7,481 stars or more). Bug identification was measured using the corrective commit probability, the ratio of commits determined to be related to fixing bugs. The analysis showed that popular projects had a higher ratio of bug fixes (e.g., Google's popular projects had a 27% higher bug fix rate than Google's less popular projects). Since it is unlikely that Google lowered its code quality standards in more popular projects, this is an indication of increased bug detection efficiency in popular projects.
- > The "many eyes" theory of open source security isn't popular right now, but it certainly seems like bigger targets have smaller margins for error.
https://news.ycombinator.com/item?id=20383529
DonHopkins on July 8, 2019 | parent | context | favorite | on: Contributor Agreements Considered Harmful
And then there's Linus's Law, which he made up, then tried to blame on Linus.
"Given enough eyeballs, all bugs are shallow." -Eric S Raymond
"My favorite part of the "many eyes" argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code." -Theo De Raadt
https://en.wikipedia.org/wiki/Linus%27s_Law
>In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.[4] While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".[5][6]
>Although detection of even deliberately inserted flaws[7][8] can be attributed to Raymond's claim, the persistence of the Heartbleed security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum.[9][10][11][12] Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain.[12] In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking".[11] Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.
The little experience Raymond DOES have auditing code has been a total fiasco and embarrassing failure, since his understanding of the code was incompetent and deeply tainted by his preconceived political ideology and conspiracy theories about global warming, which was his only motivation for auditing the code in the first place. His sole quest was to discredit the scientists who warned about global warming. The code he found and highlighted was actually COMMENTED OUT, and he never addressed the fact that the scientists were vindicated.
http://rationalwiki.org/wiki/Eric_S._Raymond
>During the Climategate fiasco, Raymond's ability to read other peoples' source code (or at least his honesty about it) was called into question when he was caught quote-mining analysis software written by the CRU researchers, presenting a commented-out section of source code used for analyzing counterfactuals as evidence of deliberate data manipulation. When confronted with the fact that scientists as a general rule are scrupulously honest, Raymond claimed it was a case of an "error cascade," a concept that makes sense in computer science and other places where all data goes through a single potential failure point, but in areas where outside data and multiple lines of evidence are used for verification, doesn't entirely make sense. (He was curiously silent when all the researchers involved were exonerated of scientific misconduct.)
More context:
- "You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code." -Ken Thompson
"Given enough eyeballs, all bugs are shallow." -Eric S Raymond pretending to quote Linus Torvalds by mis-attributing his own wishful fallacy as "Linus's Law"
Then there's Theo de Raadt's salty quote about ESR's ridiculous "many eyes" argument that Raymond deceptively calls "Linus's Law":
https://groups.google.com/g/fa.openbsd.tech/c/gypClO4qTgM/m/...
"Oh right, let's hear some of that "many eyes" crap again. My favorite part of the "many eyes" argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code." -Theo de Raadt on ESR's "Linus's Law"
Actually, that fallacious "many eyes" argument was "formulated" by Eric S Raymond (to whom Theo was referring as "the originator of the statement"), which ESR misleadingly named "Linux's Law" in "honor" of Linus Torvalds, who never even made that claim, which is ironic because it actually dishonors Linus by being an invalid fallacy.
https://en.wikipedia.org/wiki/Linus%27s_law
>Validity
>In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate. While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".
>The persistence of the Heartbleed security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum. Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain. In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking". Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.
>Empirical support of the validity of Linus's law was obtained by comparing popular and unpopular projects of the same organization. Popular projects are projects with the top 5% of GitHub stars (7,481 stars or more). Bug identification was measured using the corrective commit probability, the ratio of commits determined to be related to fixing bugs. The analysis showed that popular projects had a higher ratio of bug fixes (e.g., Google's popular projects had a 27% higher bug fix rate than Google's less popular projects). Since it is unlikely that Google lowered its code quality standards in more popular projects, this is an indication of increased bug detection efficiency in popular projects.
The little experience Raymond DOES have auditing code has been a total fiasco and embarrassing failure, since his understanding of the code was incompetent and deeply tainted by his preconceived political ideology and conspiracy theories about climate change, which was his only motivation for auditing the code in the first place. His sole quest was to deceptively discredit the scientists who warned about climate change. The code he found and highlighted was actually COMMENTED OUT, and he never addressed the fact that the scientists were vindicated.
http://rationalwiki.org/wiki/Eric_S._Raymond
>During the Climategate fiasco, Raymond's ability to read other peoples' source code (or at least his honesty about it) was called into question when he was caught quote-mining analysis software written by the CRU researchers, presenting a commented-out section of source code used for analyzing counterfactuals as evidence of deliberate data manipulation. When confronted with the fact that scientists as a general rule are scrupulously honest, Raymond claimed it was a case of an "error cascade," a concept that makes sense in computer science and other places where all data goes through a single potential failure point, but in areas where outside data and multiple lines of evidence are used for verification, doesn't entirely make sense. (He was curiously silent when all the researchers involved were exonerated of scientific misconduct.)
- >It doesn't imply that bugs get fixed, only that they are shallow.
No, actually, it intentionally does imply that the bugs will get fixed: that's the whole point. Where did you get that idea -- have you even bothered to cast your own eyes on the original source of the quote, or any of the discussion around Heartbleed and other bugs, or is that just your "feeling"? If you go back and read the original source of the quote in context, you will see that it explicitly states that the key point is that bugs will get rapidly FIXED, in no uncertain terms:
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...
>[...] Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:
>8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. [...]
>But the key point is that both parts of the process (finding and fixing) tend to happen rapidly. [...]
>In practice, the theoretical loss of efficiency due to duplication of work by debuggers almost never seems to be an issue in the Linux world. One effect of a ``release early and often'' policy is to minimize such duplication by propagating fed-back fixes quickly [JH]. [...]
Notwithstanding the fact that ESR himself incompetently and dishonestly claimed to have found bugs in climate analysis software and didn't bother to fix them, because his actual point was to falsely discredit the scientists (whose exoneration he still has not acknowledged), not to altruistically advance science, but to mendaciously deny science. Is that what you mean by "bikeshedding"?
Did the finding and fixing of the Heartbleed bug happen rapidly because it was open source? No, definitely not! Open source is not magical pixie dust.
https://www.datamation.com/open-source/does-heartbleed-dispr...
>Does Heartbleed Disprove ‘Open Source is Safer’?
>[...] Or, as Eric Raymond famously said, “given enough eyeballs, all bugs are shallow.” Yet, somehow, Heartbleed appears to have existed for over two years before being discovered. It may even have been used by American security agencies in their surveillance of the public. [...]
>Implicit in the description is not only the idea that peer review can substitute for software testing, but also that no special effort is needed to detect bugs. Simply by going about their business as developers, FOSS project members are likely to notice bugs so that they can be repaired.
>This claim has not gone unchallenged. It is a statement of belief, not the conclusion of a scientific study, a rationalization of the fact that peer review in FOSS has always been easier than software testing. Moreover, in Facts and Fallacies about Software Engineering, Robert L. Glass claims that no correlation exists between the number of bugs reported and the number of reviewers.
>Yet despite the claim’s weaknesses, it remains one of FOSS’s major assertions of superiority. Heartbleed seems an exception that at least challenges the widely believed rule, or maybe even overturns it completely. [...]
>A more useful analysis has been offered by Theo de Raadt, the founder of OpenBSD and OpenSSH. De Raadt notes that malloc, a memory allocation library, was long ago patched to prevent Heartbleed-type exploitations. However, at the same time, OpenSSL added “a wrapper around malloc & free so that the library will cache memory on its own, and not free it to the protective malloc” — all in the name of improving performance on some systems.
>In other words, the potential for a bug was detected and patched, but was by-passed by an engineering decision that favored efficiency over security. Perhaps, too, the wrapper was never examined closely because it was assumed to be trivial and to add nothing new. It had become an established part of the code that nobody was likely to modify. But, whatever the case, de Raadt concludes scathingly, “OpenSSL is not developed by a responsible team.”
>Assuming that de Raadt is right, then one take-away for FOSS is that all the eyes in the world cannot be counted on to catch basic design problems.
>Taken together, Segglemann’s and de Raadt’s comments also suggest that assuming no special effort is needed to discover bugs is a mistake. Perhaps more attention needs to be paid to formal reviews and software testing than FOSS traditionally has managed. The fact that FOSS development often involves remote cooperation does not mean that log-in test or in-person testing sessions could not be added to many project’s development cycle.
>What Heartbleed proves is that FOSS needs at to examine the unexamined assumption it has held for years. Greg DeKoenigsberg, a vice president at Eucalyptus Systems, summed up the situation neatly on Facebook: “we don’t put enough eyes in the right places, because we assume [bug-detection] will just happen because of open source pixie dust — and now we’re paying the price for it.” [...]
https://www.esecurityplanet.com/applications/why-all-linux-s...
>Why All Linux (Security) Bugs Aren’t Shallow
>Zemlin quoted the oft-repeated Linus’ law, which states that given enough eyes all bugs are shallow. That “law” essentially promises that many eyes provide a measure of quality and control and security to open source code. So if Linus’ law is true, Zemlin asked, why are damaging security issues being found now in open source code?
>“In these cases the eyeballs weren’t really looking,” Zemlin said.
https://www.zdnet.com/article/did-open-source-matter-for-hea...
>Did open source matter for Heartbleed?
>Open source does not provide a meaningful inherent security benefit for OpenSSL and it may actually discourage some important testing techniques. Also, panhandling is not a good business model for important software like OpenSSL.
>Let's stipulate that OpenSSL has a good reputation, perhaps even that it deserves that reputation (although this is not the first highly-critical vulnerability in OpenSSL). I would argue that the reputation is based largely on wishful thinking and open source mythology.
>Before the word "mythology" gets me into too much trouble, I ought to say, as Nixon might have put it, "we're all open source activists now." For some purposes, open source is a good thing, or a necessary thing, or both. I agree, at least in part, with those who say that cryptography code needs to be open source, because it requires a high level of trust.
>Ultimately, the logic of that last statement presumes that there are people analyzing the open source code of OpenSSL in order to confirm that it is deserving of trust. This is the "many eyeballs" effect described in The Cathedral and the Bazaar, by Eric Raymond, one of the early gospels in the theology of open source. The idea is that if enough people have access to source code then someone will notice the bugs.
- Speaking of Linus, did you know the embarrassingly invalid "Linus's Law" was actually made up by Eric S Raymond, and he just blamed it on Linus?
https://en.wikipedia.org/wiki/Linus%27s_law
>In software development, Linus's law is the assertion that "given enough eyeballs, all bugs are shallow".
>The law was formulated by Eric S. Raymond in his essay and book The Cathedral and the Bazaar (1999), and was named in honor of Linus Torvalds. [...]
>Validity
>In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.[4] While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".[5]
>The persistence of the Heartbleed security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum.[6][7][8][9] Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain.[9] In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking".[8] Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.
>Empirical support to the validity of Linus’s law [10] was obtained by comparing popular and unpopular projects of the same organisation. Organizations like Google and Facebook are known for their quality standards. Popular projects are projects with in the top 5% number of stars (7,481 stars or more). The bug identification was measured using the corrective commit probability, ratio of commits detected to fixing bug. The analysis showed that the popular projects had more bug fixing ratio (e.g., Google’s popular projects had 27% higher bug fix rate than Google’s less popular projects). Since it is unlikely that Google lowered its quality standard in it most popular projects, this is an indication of increased bug detection efficiency in popular projects.
- And then there's Linus's Law, which he made up, then tried to blame on Linus.
"Given enough eyeballs, all bugs are shallow." -Eric S Raymond
"My favorite part of the "many eyes" argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code." -Theo De Raadt
https://en.wikipedia.org/wiki/Linus%27s_Law
>In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.[4] While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".[5][6]
>Although detection of even deliberately inserted flaws[7][8] can be attributed to Raymond's claim, the persistence of the Heartbleed security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum.[9][10][11][12] Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain.[12] In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking".[11] Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.
The little experience Raymond DOES have auditing code has been a total fiasco and embarrassing failure, since his understanding of the code was incompetent and deeply tainted by his preconceived political ideology and conspiracy theories about global warming, which was his only motivation for auditing the code in the first place. His sole quest was to discredit the scientists who warned about global warming. The code he found and highlighted was actually COMMENTED OUT, and he never addressed the fact that the scientists were vindicated.
http://rationalwiki.org/wiki/Eric_S._Raymond
>During the Climategate fiasco, Raymond's ability to read other peoples' source code (or at least his honesty about it) was called into question when he was caught quote-mining analysis software written by the CRU researchers, presenting a commented-out section of source code used for analyzing counterfactuals as evidence of deliberate data manipulation. When confronted with the fact that scientists as a general rule are scrupulously honest, Raymond claimed it was a case of an "error cascade," a concept that makes sense in computer science and other places where all data goes through a single potential failure point, but in areas where outside data and multiple lines of evidence are used for verification, doesn't entirely make sense. (He was curiously silent when all the researchers involved were exonerated of scientific misconduct.)
Related
Facts and Fallacies of Software Engineering
19 recommend · 48
Clean Code
298 recommend · 951
2011–2026
Software Foundations
58 recommend · 77
Patterns of software
31 recommend · 70
A Philosophy of Software Design
163 recommend · 342
Design Patterns
95 recommend · 491
