> I must say the Linux community is a lot nicer than the Unix community. A negative comment on Unix would warrent death threats. With Linux, it is like stirring up a nest of butterflies.
Interesting comment on the Linux, UNIX communities.
From: dmr@plan9.research.att.com
Date: Tue, 15 Mar 1994 00:38:07 EST
Subject: anti-foreword
To the contributers to this book:
I have succumbed to the temptation you offered in your preface: I do
write you off as envious malcontents and romantic keepers of memories.
The systems you remember so fondly (TOPS-20, ITS, Multics,
Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture,
they are fertilizing it from below.
Your judgments are not keen, they are intoxicated by metaphor. In
the Preface you suffer first from heat, lice, and malnourishment, then
become prisoners in a Gulag. In Chapter 1 you are in turn infected by
a virus, racked by drug addiction, and addled by puffiness of the
genome.
Yet your prison without coherent design continues to imprison you.
How can this be, if it has no strong places? The rational prisoner
exploits the weak places, creates order from chaos: instead, collectives
like the FSF vindicate their jailers by building cells almost com-
patible with the existing ones, albeit with more features. The
journalist with three undergraduate degrees from MIT, the researcher
at Microsoft, and the senior scientist at Apple might volunteer a few
words about the regulations of the prisons to which they have been
transferred.
Your sense of the possible is in no sense pure: sometimes you want
the same thing you have, but wish you had done it yourselves; other
times you want something different, but can't seem to get people to
use it; sometimes one wonders why you just don't shut up and tell
people to buy a PC with Windows or a Mac. No Gulag or lice, just a
future whose intellectual tone and interaction style is set by Sonic the
Hedgehog. You claim to seek progress, but you succeed mainly in
whining.
Here is my metaphor: your book is a pudding stuffed with apposite
observations, many well-conceived. Like excrement, it contains
enough undigested nuggets of nutrition to sustain life for some. But
it is not a tasty pie: it reeks too much of contempt and of envy.
Bon appetit!
Huh, I feel exactly the same way. I've never been employed in a position where the bottom-up approach was the one people were actually looking for, so I've always felt guilty about my work ethic - I feel like I'm satisfying my own curiosity on company time.
I don't feel like not adding value: Being a bottom-up thinker means I can get to the root cause of hard problems, or even warn and prevent bad solutions. My problem is that I have always felt that only top-down thinkers can do architecture and design. This article shows that this is not the case.
If you like this sort of thing, we've been running a Twitter account for several years dedicated to pithy programming related quotes: https://twitter.com/codewisdom
He didn't say "proprietary code is evil" or "property is theft", dude's not Richard Stallman. Also, Google does plenty of open source stuff, including Go, which Thompson works on.
> "I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing."
-Thompson on the superiority of ed to editors such as today's vi or emacs, as summarized by Peter Salus in A Quarter Century of UNIX (Addison-Wesley, 1994).
> The X server has to be the biggest program I've ever seen that doesn't do anything for you.
and I'm glad linux has come to meet his expectations over the years...
> Microsoft is really unreliable but Linux is worse. In a non-PC environment, it just won't hold up. If you're using it on a single box, that's one thing. But if you want to use Linux in firewalls, gateways, embedded systems, and so on, it has a long way to go.
-1999
>I run Linux. And I occasionally look at code, but rarely, so I can't really tell whether the quality has gotten better or not [since 1999]. But certainly the reliability has gotten better.
I have no idea but perhaps in those days (60s & 70s), they wrote code on paper first before feeding it into the computer? If so, then ed was probably tolerable. It's nigh unthinkable these days of course.
That is how we coded. TECO, my first editor, requires keeping ones code in your head while typing in edit instructions. At 300 baud a teletype was pretty slow to print back the code that you had typed, so every dozen or so line edit commands I would print out the lines I was working on.
Try out ed on a Unix or Linux (or MacOS) system to get a taste of the experience, and don’t forget that playback happened on a teletype printing back at around the speed of a fast typist.
Nevertheless, this was much better than punching cards.
Line editors aren't so bad, and the Unix ed is pretty awesome. It's easy to list and read through code, and it has powerful search-and-replace. You just have to get used to using search or cursor movement commands for making edits. The programming I've been doing lately has all been in CP/M, using its "ed", which is a very simple line editor, and I still haven't felt the need to write things out beforehand. I think you just get used to it.
With ed you can do cursor movements? How? I meant to ask people how they use ed and compile an article, so that people would have a better idea of what's possible and what is not with ed. Could we talk about how ed can be used?
Oops, sorry to mislead you. I was wrong about Unix ed. I knew it had powerful regex and line addressing, I figured it had character addressing/cursor positioning too. CP/M ed has basic search and replace, but most work is done with cursor movements.
ITS Emacs has "glass tty" support that responded to keystrokes exactly as normal, but only showed one current line by repainting it without using any fancy control characters or escape codes, just backspace, carriage return and line feed. (That's what it meant to be "glass".) So ^L would refresh just the current line, and you could ^N down through a file to print it out line by line.
I still deal with a line editor on a near daily basis working with some ancient piece of software. For editing records/data, it's very tolerable, and I wouldn't gain too much speed using a visual editor given the data format. For programming, laying it out on paper (or, more often these days, copy pasting the code from a visual editor after you're satisfied with it) is typical.
After a while of using it, you kind of do get used to the limitations and work in the system, but I can't say how efficient I'd actually be making a non trivial program with just a line editor. For instance, creating and maintaining consistent indentation is just plain awful because you can't use tab and there is no auto spacing (well, in this particular instance. Unix ed and most other line editors wouldn't have this issue). I bet if I had to use it entirely with no visual editor to back me up, I'd end up being much more in tune to catching my mistakes though.
I think that the programs, back in the days, were not many thousands lines of code. They were small, and did only one or two things. Each program doing one thing reliably with a simple interface, and you can call it from another program, and build something big from that. But still, they are all small pieces of code.
while i think so highly of ken thompson, and he is probably one of the greatest programmers ever, he is (in my opinion at least) the true father of c and unix
but those quotes, are really really bad ... and some are mean too
"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
Reminds me of Theo de Raadt's quote about ESR's "many eyes" argument:
"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."
Not only is ESR wrong, but also his mis-attributed slogan overpromises a false sense of security, which is dangerous.
In response, he tried to construct a straw man argument that "proprietary software is worse than open source software", which does not in any way support his claim about "all bugs being shallow".
Anyone who thinks all bugs are shallow under any circumstances just hasn't seen many interesting real world bugs with their own eyes. Their experience is limited and their confidence in their software, security and mastery of programming and debugging is pure Dunning-Kruger effect. I'm with Ken on this one.
Actually, that quote was "formulated" by Eric S Raymond (to whom Theo was referring as "the originator of the statement"), and is only deceptively named "Linux's Law" [1] in "honor" of Linus Torvalds, which is ironic because it actually dishonors him by being invalid.
The point that Theo was making is that ESR talks and talks and types and types about many eyeballs looking at code, but when it comes down to actually auditing code, he never actually bothers, and neither do most other of his minions who are so quick to parrot his ill-conceived "Linux's Law".
Neither "enough eyeballs" nor "the right eyeballs" are a GIVEN, even for open source software. Google "Heartbleed".
"Not enough eyeballs" (or "ZERO eyeballs" as he loves to claim) are NOT a GIVEN for proprietary software, because you can license much proprietary source code, and some proprietary source code is available for you to read and audit for free, under licenses like Microsoft's "Shared Source" license.
And qualified eyeballs are NOT FREE, and usually very busy being well paid to look at much more interesting things than poorly written buggy code like OpenSSL. I doubt that Eric Raymond has contributed any of the profits from his books or VA Linux stocks to Theo De Raadt or anyone else who actually takes the long time and tedious effort to actually audit code.
The one time ESR actually did try to audit some code didn't go so well:
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.
>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.)
Linus's Law is a claim about software development, named in honor of Linus Torvalds and formulated by Eric S. Raymond in his essay and book [redacted]. [...]
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 ...
That is a lot of words to say that it doesn't help to have access to the source code if qualified people don't perform adequate audits.
In this regard, open source software is still better. Google "Heartbleed".
When a neglected piece of critical infrastructure code was finally examined, it was shown to have serious flaws. Top talent immediately shifted their focus and began sorely needed maintenance. Nobody asked permission. Nobody called their lawyer. They just got to work to get-er-done. I think Theo was among those to help resolve issues.
I am grateful for those eyeballs and those fingers.
It would probably be better to use a survey of vulnerabilities plus Heartbleed instead of just repeating Heartbleed. It can be dismissed as an outlier: "That's just one project everyone was freeloading on." I know, it's a security-critical project that should've gotten many eyeballs. I just prefer to show how pervasive the problem is when debunking this stuff.
The other thing I noted on a Heartbleed-related thread was that FOSS never produced high-assurance security despite its labor advantage. Proprietary sector, either industry or CompSci teams, beat them about every time.
I elaborate more in replies to DB. It comes down to them not caring enough to apply the level of QA necessary. You have to pay people to do that. You also have to find the right people that can do it since even the knowledge of it isn't widespread. They'll know 100 frameworks and such but not the basic activities for assurance past unit/acceptance testing and review. They'll probably have never heard of Ada/SPARK or SPIN when they tell you about Rust. So on and so forth.
Raymond's claim is utter bullshit. If you want best security, you're better off buying a 3rd-party-evaluated product from high-assurance proprietary. If you want good security that's cheap, it's a small number of proprietary and FOSS projects whose stakeholders put time in for thorough review and analysis. The rest is shit waiting to happen or (looks at CVE list) happening all the time.
I don't necessarily disagree with your thesis [2], but this argument seems strange:
>Neither "enough eyeballs" nor "the right eyeballs" are a GIVEN, even for open source software.
and this argument:
> "Not enough eyeballs" (or "ZERO eyeballs" as he loves to claim) are NOT a GIVEN for proprietary software,
Are you an auditor of proprietary software or something? It almost sounds like you're arguing for many-eyes in theory, but you're saying that it's just as likely to benefit proprietary software? That is pretty bonkers to me. Even the 2-4 reviewers thing seems ridiculous, because open source software might be studied years later. In fact, companies trying to sell software analysis tools often fix bugs in open source software to demo their tools; something that they cannot do with proprietary software.
> Although detection of even deliberately inserted flaws 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.
I find it amusing that there seem to be this contingent of proprietary code proponents who insist that Heartbleed was the singular proof against "many-eyes". Since this particular security issue is the one thing that critics always point to, it almost seems like this is the exception that proves the rule[3]. Discussion also tends to leave out that it was discovered and patched by people other than the core developers because it was open source.
Closed source software security bugs don't seem to get pithy names because they're so common. If we're cherry-picking cases, how about Windows XP? Beloved software created by arguably the biggest, most advanced proprietary software developers at the time. There was a period of time when you could not turn a machine on for an hour without it being compromised. Or serious bugs that are trivially exploitable and are known about and not fixed for many years [4].
1. I think reasonable people would disagree with ESR about various opinions he has expressed. You really sound like you have a bone to pick though.
2. There is just as much diversity in open source software as there is in proprietary. I do suspect that truly bad code doesn't get used as much in the open source world as it does in the proprietary world though.
3. All software has bugs, DJB creations excepted. It seems like critics are saying "Ha! See! Open source has security bugs too!" No shit. Of course, in a black and white world, this could be considered refutation of ESR.
4. Not really an exploit, but this denial of service is one of my favorites because of how trivial it is and how badly it crushes old versions of Windows:
Yeah... it turns out that most eyes prefer to pay attention to interesting things which are easy to look at, so the distribution of attention is determined more by politics and fashion than necessity. Popular frameworks and projects that look good on a resume get deeply scrutinized and contributed to, while even simple bugs in mission critical software can go unnoticed for decades because the code is ugly and arcane, and there's no social value to be gained from the investment in time.
IIRC the guy from Jane Street that does all the OCaml evangelism has said that it's hard to pay people enough money to motivate them to audit "boring" code for any length of time.
On his quote about educational value of UNIX and being so small you can go through it line by line to lean what it does. Can someone recommend a version appropriate for doing this?
As well as Minix, which is intended as just such a teaching aid and comes with a textbook, there's the Lions book, which is a complete annotated source listing of an early Unix, and which was passed around as nerd Samizdat for a while, until the Unix copyright status was changed.
Thank you, and thank you everyone else for all these resources. My wife will be rather displeased that I'm not playing Divinity 2 with her this holiday weekend ;)
As other replies say, I too have read that the Lions' stuff is highly recommended; have not read it though. I have read good chunks of The Design of the Unix Operating System by Maurice Bach, some years ago, which included both concepts and either code or pseudocode for various kernel algorithms such as scheduling, etc, IIRC. Might not be up to date for today's Unixen, but should be good for learning a lot about the basics of Unix internals, I'd say. Disclaimer: I read it out of interest, not done kernel level work myself.
> The press, television, and movies make heroes of vandals by calling them whiz kids. ... There is obviously a cultural gap. The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor's house. It should not matter that the neighbor's door is unlocked.
If only it was just kids now. What's changed in the decades since is we have serious professionals beating on our doors now: state actors, mafia, miners, spammers, malvertisers, id thieves. They're well funded and organized. Amateurs don't stand a chance.
Years ago, I started at Google, and was in Charlie's cafe, eating alone. I'm sitting there, and up walks Ken Thompson. He sits down, introduces himself as Ken, and asks me what I work on. We sat there for a good 40 minutes just chatting.
One of my coolest memories of working at Google was that time. He was so down to earth, never bothered to talk up about who he was (even though I knew). I really appreciated that.
I have a similar Google lunch story. A guy sat down, introduced himself as Rob, and told me it was his first day at Google. We had a nice chat, and later I told my office mate that the new guy seemed really smart. He laughed and told me I'd just had lunch with Rob Pike. :)
When I see devs are talking/fighting for tech trends or programming patterns or frameworks, Ken's quote ( or message you say ) come in my mind always:
"Many if not most of the software we use is probably obsolete according to the latest design criteria. Most users could probably care less if the internals of the operating system they use is obsolete. They are rightly more interested in its performance and capabilities at the user level."
Of course users don't really care about the design principles used to organize source code. They care about features. The design principles are a concern for the developers, and if some standard isn't obeyed, then the users may not get those new, stable features they're craving.
The first time I read that it was in something about Belle playing Q v R against Walter Browne. Belle had the R and Browne had to mate in 50 moves. Seven piece tablebases are achievable now.
It seems this is a real story from the time Ken Thompson started to work at Google:
"Q: I know Google has a policy where every new employee has to get checked out on languages before they're allowed to check code in. Which means you had to get checked out on C [which you co-created].
Thompson: Yeah, I haven't been.
Q. You haven't been! You're not allowed to check in code?
Thompson: I'm not allowed to check in code, no... I just haven't done it. I've so far found no need to."
If you don't have readability in a language, you just have to get a code review from someone who does have readability. You can still check in your code.
75 comments
[ 4.4 ms ] story [ 102 ms ] threadInteresting comment on the Linux, UNIX communities.
The Unix Haters Handbook [1] was dedicated to Ken and Dennis, and Dennis [2] wrote the anti-forward [3].
[1] http://simson.net/ref/ugh.pdf
[2] http://www.donhopkins.com/home/images/DennisRitchiePthththth...
[3] https://news.ycombinator.com/item?id=3106271
I've been trying to figure out what this is supposed to sound like.
> I am a very bottom-up thinker. If you give me the right kind of Tinker Toys
I am a boitom-up thinker, I cannot imagine a house if I don't know about what kind of bricks exist, which we use and why!
I have blamed that trait for the main reason for stagnating in my carreer while idealising people like Thompson, due to their achievements.
http://ground-up-software.com/
These guys are pretty great too:
https://twitter.com/EmacsHaiku
https://twitter.com/ed1conf
iamdevloper ( https://twitter.com/iamdevloper ) is good too.
DEVOPS_BORAT ( https://twitter.com/DEVOPS_BORAT ), which was often hilarious, seems to have stopped a while ago.
> "I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing."
-Thompson on the superiority of ed to editors such as today's vi or emacs, as summarized by Peter Salus in A Quarter Century of UNIX (Addison-Wesley, 1994).
> The X server has to be the biggest program I've ever seen that doesn't do anything for you.
and I'm glad linux has come to meet his expectations over the years...
> Microsoft is really unreliable but Linux is worse. In a non-PC environment, it just won't hold up. If you're using it on a single box, that's one thing. But if you want to use Linux in firewalls, gateways, embedded systems, and so on, it has a long way to go.
-1999
>I run Linux. And I occasionally look at code, but rarely, so I can't really tell whether the quality has gotten better or not [since 1999]. But certainly the reliability has gotten better.
-2009
Try out ed on a Unix or Linux (or MacOS) system to get a taste of the experience, and don’t forget that playback happened on a teletype printing back at around the speed of a fast typist.
Nevertheless, this was much better than punching cards.
http://www.finseth.com/craft/#c2
After a while of using it, you kind of do get used to the limitations and work in the system, but I can't say how efficient I'd actually be making a non trivial program with just a line editor. For instance, creating and maintaining consistent indentation is just plain awful because you can't use tab and there is no auto spacing (well, in this particular instance. Unix ed and most other line editors wouldn't have this issue). I bet if I had to use it entirely with no visual editor to back me up, I'd end up being much more in tune to catching my mistakes though.
It isn't a very productive cycle, but with printouts and smaller codebases, it seems viable.
but those quotes, are really really bad ... and some are mean too
Reminds me of Theo de Raadt's quote about ESR's "many eyes" argument:
"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."
what does he mean?
Reality has proven him quite wrong.
http://heartbleed.com/
Not only is ESR wrong, but also his mis-attributed slogan overpromises a false sense of security, which is dangerous.
In response, he tried to construct a straw man argument that "proprietary software is worse than open source software", which does not in any way support his claim about "all bugs being shallow".
http://esr.ibiblio.org/?p=5665
Anyone who thinks all bugs are shallow under any circumstances just hasn't seen many interesting real world bugs with their own eyes. Their experience is limited and their confidence in their software, security and mastery of programming and debugging is pure Dunning-Kruger effect. I'm with Ken on this one.
The point that Theo was making is that ESR talks and talks and types and types about many eyeballs looking at code, but when it comes down to actually auditing code, he never actually bothers, and neither do most other of his minions who are so quick to parrot his ill-conceived "Linux's Law".
Neither "enough eyeballs" nor "the right eyeballs" are a GIVEN, even for open source software. Google "Heartbleed".
"Not enough eyeballs" (or "ZERO eyeballs" as he loves to claim) are NOT a GIVEN for proprietary software, because you can license much proprietary source code, and some proprietary source code is available for you to read and audit for free, under licenses like Microsoft's "Shared Source" license.
https://en.wikipedia.org/wiki/Shared_source
And qualified eyeballs are NOT FREE, and usually very busy being well paid to look at much more interesting things than poorly written buggy code like OpenSSL. I doubt that Eric Raymond has contributed any of the profits from his books or VA Linux stocks to Theo De Raadt or anyone else who actually takes the long time and tedious effort to actually audit code.
The one time ESR actually did try to audit some code didn't go so well:
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.)
[1] https://en.wikipedia.org/wiki/Linus%27s_Law
Linus's Law is a claim about software development, named in honor of Linus Torvalds and formulated by Eric S. Raymond in his essay and book [redacted]. [...]
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 ...
In this regard, open source software is still better. Google "Heartbleed".
When a neglected piece of critical infrastructure code was finally examined, it was shown to have serious flaws. Top talent immediately shifted their focus and began sorely needed maintenance. Nobody asked permission. Nobody called their lawyer. They just got to work to get-er-done. I think Theo was among those to help resolve issues.
I am grateful for those eyeballs and those fingers.
The other thing I noted on a Heartbleed-related thread was that FOSS never produced high-assurance security despite its labor advantage. Proprietary sector, either industry or CompSci teams, beat them about every time.
https://www.schneier.com/blog/archives/2014/04/reverse_heart...
I elaborate more in replies to DB. It comes down to them not caring enough to apply the level of QA necessary. You have to pay people to do that. You also have to find the right people that can do it since even the knowledge of it isn't widespread. They'll know 100 frameworks and such but not the basic activities for assurance past unit/acceptance testing and review. They'll probably have never heard of Ada/SPARK or SPIN when they tell you about Rust. So on and so forth.
Raymond's claim is utter bullshit. If you want best security, you're better off buying a 3rd-party-evaluated product from high-assurance proprietary. If you want good security that's cheap, it's a small number of proprietary and FOSS projects whose stakeholders put time in for thorough review and analysis. The rest is shit waiting to happen or (looks at CVE list) happening all the time.
I don't necessarily disagree with your thesis [2], but this argument seems strange:
>Neither "enough eyeballs" nor "the right eyeballs" are a GIVEN, even for open source software.
and this argument:
> "Not enough eyeballs" (or "ZERO eyeballs" as he loves to claim) are NOT a GIVEN for proprietary software,
Are you an auditor of proprietary software or something? It almost sounds like you're arguing for many-eyes in theory, but you're saying that it's just as likely to benefit proprietary software? That is pretty bonkers to me. Even the 2-4 reviewers thing seems ridiculous, because open source software might be studied years later. In fact, companies trying to sell software analysis tools often fix bugs in open source software to demo their tools; something that they cannot do with proprietary software.
> Although detection of even deliberately inserted flaws 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.
I find it amusing that there seem to be this contingent of proprietary code proponents who insist that Heartbleed was the singular proof against "many-eyes". Since this particular security issue is the one thing that critics always point to, it almost seems like this is the exception that proves the rule[3]. Discussion also tends to leave out that it was discovered and patched by people other than the core developers because it was open source.
Closed source software security bugs don't seem to get pithy names because they're so common. If we're cherry-picking cases, how about Windows XP? Beloved software created by arguably the biggest, most advanced proprietary software developers at the time. There was a period of time when you could not turn a machine on for an hour without it being compromised. Or serious bugs that are trivially exploitable and are known about and not fixed for many years [4].
1. I think reasonable people would disagree with ESR about various opinions he has expressed. You really sound like you have a bone to pick though.
2. There is just as much diversity in open source software as there is in proprietary. I do suspect that truly bad code doesn't get used as much in the open source world as it does in the proprietary world though.
3. All software has bugs, DJB creations excepted. It seems like critics are saying "Ha! See! Open source has security bugs too!" No shit. Of course, in a black and white world, this could be considered refutation of ESR.
4. Not really an exploit, but this denial of service is one of my favorites because of how trivial it is and how badly it crushes old versions of Windows:
http://www.cvedetails.com/cve/CVE-2010-4669/
https://www.youtube.com/watch?v=00yjWB6gGy8
Edit: formatting.
http://www.lemis.com/grog/Documentation/Lions/index.php
https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6t...
(That's what the sibling comments are also referring to!)
Edited for typo.
:) My favorite. Implying that everything else is great.
> The press, television, and movies make heroes of vandals by calling them whiz kids. ... There is obviously a cultural gap. The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor's house. It should not matter that the neighbor's door is unlocked.
If only it was just kids now. What's changed in the decades since is we have serious professionals beating on our doors now: state actors, mafia, miners, spammers, malvertisers, id thieves. They're well funded and organized. Amateurs don't stand a chance.
One of my coolest memories of working at Google was that time. He was so down to earth, never bothered to talk up about who he was (even though I knew). I really appreciated that.
"Many if not most of the software we use is probably obsolete according to the latest design criteria. Most users could probably care less if the internals of the operating system they use is obsolete. They are rightly more interested in its performance and capabilities at the user level."
From The Tanenbaum-Torvalds Debate[0]
[0]. http://www.oreilly.com/openbook/opensources/book/appa.html
The first time I read that it was in something about Belle playing Q v R against Walter Browne. Belle had the R and Browne had to mate in 50 moves. Seven piece tablebases are achievable now.
"Q: I know Google has a policy where every new employee has to get checked out on languages before they're allowed to check code in. Which means you had to get checked out on C [which you co-created].
Thompson: Yeah, I haven't been.
Q. You haven't been! You're not allowed to check in code?
Thompson: I'm not allowed to check in code, no... I just haven't done it. I've so far found no need to."
https://www.theregister.co.uk/2010/04/21/ken_thompson_take_o...
"So Mr Thompson, you say you have some programming skills..."
Does anybody have any update on that?
Which if true means a stubborn bureaucracy running uncontrolled there.
It's like hiring Andrew Tanenbaum and then insisting on him taking a test to check if he "knows" Linux.
My question was in sense, did anybody right the wrong, once even the media recognized the absurdity of that particular case.
C didn't exist as he wrote the first code of what later was named Unix.