Ken Thompson quotes | Hacker News Reader

Ken Thompson quotes

en.wikiquote.org

130 pointstosh71 comments

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

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

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

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.

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

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.

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.

Tell us how you really feel about ESR [1].

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.

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.

Yaron Minsky? (https://blog.janestreet.com/author/yminsky)

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

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.

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.

http://www.finseth.com/craft/#c2

Vi likewise has ':open'.

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.

Well, of course, one would write with `cat -`, and only edit with `ed`.

It isn't a very productive cycle, but with printouts and smaller codebases, it seems viable.

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.

Some day we will look back and say the same about generics in Go :-)

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

Yes, the attitude is slightly different with that crowd. They are more cathedral than bazaar.

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

From The Tanenbaum-Torvalds Debate[0]

[0]. http://www.oreilly.com/openbook/opensources/book/appa.html

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.

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.

And that's why I named my company:

http://ground-up-software.com/

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

Death threats for negative comments on Unix??! Pththththt!

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

    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!

> Pththththt

I've been trying to figure out what this is supposed to sound like.

https://upload.wikimedia.org/wikipedia/commons/8/8b/Blowing_...

Excellent

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.

well, those whiz kids had to grow up to be someone, someday...

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?

Minix was designed (originally) for exactly this purpose.

Somewhere I had a 3 ring binder of the complete source for Minix, can't remember where I picked it up, but long gone now, sadly.

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.

http://www.lemis.com/grog/Documentation/Lions/index.php

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 ;)

https://github.com/mit-pdos/xv6-public

Indubitably:

https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6t...

(That's what the sibling comments are also referring to!)

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.

Edited for typo.

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

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?

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.

The topic was that apparently Google insisted on testing Ken Thompson if he knows C, because policy.

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.

I think you meant Linus Torvalds.

Thompson created B, not C.

C didn't exist as he wrote the first code of what later was named Unix.

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

Hey, thanks, will check it out.

These guys are pretty great too:

https://twitter.com/EmacsHaiku

https://twitter.com/ed1conf

Followed it.

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.

When in doubt, use brute force.

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.

Also seems equivalent to pg's "Do things that don't scale" maxim.

Three quotes are from the book "Coders at Work". I can really recommend that one, very interesting read. My review of it: https://www.amazon.com/gp/review/R2OV0TG7MJGXGL

> "I'd spell creat with an e."

:) My favorite. Implying that everything else is great.

And he did spell it with an e afterall :) https://twitter.com/_rsc/status/897555509141794817

Took me a few moments of frantic checking the linked article, plus Google, to make sure this wasn't an obituary.

Same O_O

what a tasteless comment, really

Mods - thanks for changing the subject, adding "quotes".

"It's way too big, way too complex."

> I think the open software movement (and Linux in particular) is laudable.

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 am more thinking to Steve Ballmer. But I should have been more explicit.

Reply on news.ycombinator.com