Live data from Hacker News

Ken Thompson quotes

en.wikiquote.org

21–30 of 76 posts

Re: Ken Thompson quotes

#21

"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…

Given enough eyeballs, all bugs are shallow. - Linus Torvalds

what is that supposed to mean "all bugs are shallow" .. does he mean easy to find, or obvious , or look small ..

what does he mean?

Re: Ken Thompson quotes

#22
post #6
post #5

This was a huge surprise for me, making me experience a cognitive dissonance. > 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.

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.

Re: Ken Thompson quotes

#23
An observation about

> 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.

Re: Ken Thompson quotes

#24
post #21

Earlier quoted context omitted.

Given enough eyeballs, all bugs are shallow. - Linus Torvalds

what is that supposed to mean "all bugs are shallow" .. does he mean easy to find, or obvious , or look small .. what does he mean?

I think he means that given enough people looking at a particular code base, even the most obscure (deep) bugs will be found (made shallow).

Re: Ken Thompson quotes

#25
post #11

Earlier quoted context omitted.

That first one you quoted is pretty incredible. It's hard for me to even imagine writing many thousands of lines of code in ed today.

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.

Re: Ken Thompson quotes

#26

"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…

Given enough eyeballs, all bugs are shallow. - Linus Torvalds

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.

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 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".

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. 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.

https://www.datamation.com/open-source/does-heartbleed-dispr...

https://www.esecurityplanet.com/open-source-security/why-all...

Re: Ken Thompson quotes

#27

"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…

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.

Re: Ken Thompson quotes

#28
post #10

Some gems: > "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…

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

Re: Ken Thompson quotes

#29
post #5

This was a huge surprise for me, making me experience a cognitive dissonance. > 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.

[deleted]

Re: Ken Thompson quotes

#30
post #24
post #21

Earlier quoted context omitted.

what is that supposed to mean "all bugs are shallow" .. does he mean easy to find, or obvious , or look small .. what does he mean?

I think he means that given enough people looking at a particular code base, even the most obscure (deep) bugs will be found (made shallow).

Please note that the quote is mis-attributed to Linus Torvalds, but it's actually from ESR.

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.

Post reply on HN