Unix and Beyond: An Interview with Ken Thompson (1999)(cs.princeton.edu)
cs.princeton.edu
Unix and Beyond: An Interview with Ken Thompson (1999)
https://www.cs.princeton.edu/courses/archive/spring03/cs333/thompson
7 comments
This file seems to be encoded as Windows-1252, but is served as UTF-8; hence all the tofu. Browsers all used to have an option override the encoding, but unfortunately those are gone now. Firefox still has the ability to "Repair Text Encoding" in the View menu (you've to press Alt to show the old-fashioned menu bar), which seems to do a decent job on this page.
The option is still in Safari's View menu too, perhaps surprisingly!
TIL about 'Repair Text Encoding'! Thank you!
Pale Moon still preserves the option to choose a specific encoding.
There's also a Chrome extension that restores encoding selection: https://chromewebstore.google.com/detail/set-character-encod...
There's also a Chrome extension that restores encoding selection: https://chromewebstore.google.com/detail/set-character-encod...
Whenever I see Pale Moon mentioned, I feel obligated to point out this GitHub issue:
https://github.com/jasperla/openbsd-wip/issues/86
Make of it what you will.
https://github.com/jasperla/openbsd-wip/issues/86
Make of it what you will.
> Make of it what you will.
I see what you did here :)
Just replacing the word will with should could make that post work so much better.
I see what you did here :)
Just replacing the word will with should could make that post work so much better.
It took me way too much time to understand this :')
Wow that was something...
And saving it keeps the fixes, thanks.
> t is the way I think. I am a very bottom-up thinker. If you give me the right kind of Tinker Toys, I can imagine the building. I can sit there and see primitives and recognize their power to build structures a half mile high, if only I had just one more to make it functionally complete. I can see those kinds of things.
I’m no Ken Thompson, but this resonates with me. I like to find the simplest, most powerful and general solution, then apply it to the problem at hand.
Super complex frameworks and systems are the bane of my existence, because I really can’t wrap my head around what they are doing, so I can’t trust them.
I’m no Ken Thompson, but this resonates with me. I like to find the simplest, most powerful and general solution, then apply it to the problem at hand.
Super complex frameworks and systems are the bane of my existence, because I really can’t wrap my head around what they are doing, so I can’t trust them.
I feel exactly the same. The history of computing is full of really simple alternative models that didn’t make it into mainstream. So, the easiest way to imagine what future tech could look like is by looking at the past. The state we are in, I cannot imagine how one could come up with something truly elegant on top of foundations plagued with irreducible complexity.
It’s generally the case that complex frameworks are “the simplest, most powerful and general solution,” since it is usually the case that achieving a powerful and general solution requires a great deal of irreducible complexity.
In fact I think what Ken is talking about here is using those simple tools to generate effective purpose built solutions rather than general multi-tools.
In fact I think what Ken is talking about here is using those simple tools to generate effective purpose built solutions rather than general multi-tools.
Disagree. It is rare that "the most general" and "the simplest" are the same thing.
I mean, it's magical when they're the same. It's just that you don't see that very often.
I mean, it's magical when they're the same. It's just that you don't see that very often.
I must not have phrased what I meant well. I agree with you completely.
>"I think that computer science in its middle age has become incestuous: people are trained by people who think one way. As a result, these so-called orthogonal thinkers are becoming rarer and rarer."
Very true
Very true
Best quote: "I don't think [Linux] will be very successful in the long run."
He seems to have changed his mind a couple decades later.
https://news.ycombinator.com/item?id=35198697
https://news.ycombinator.com/item?id=35198697
His prediction is in response to a question asking if Linux is "following in the tradition" of Unix, and immediately after, the conversation turns towards a discussion of his (at the time ongoing) work on Plan 9. "Changed his mind" seems like a kind of weird phrasing to me because Linux being more successful than Plan 9 in 2023 isn't a matter of opinion, it's a recognition of reality.
After having gotten familiar with Plan 9, I would have thought this at the time too, because it's a better system for the modern world in every single way imaginable than any Unix ever will be. Unfortunately, he did not account for the fact that adoption isn't based on rational processes. The market is not a meritocracy.
Maybe if Plan 9 was released as FOSS in the 90s and somebody made an aggressive push to give it gas in some hacker circles, history would have taken a different path. But that didn't happen and so we live in a broken future. At least 9front is usable for a daily driver these days, I suppose.
Maybe if Plan 9 was released as FOSS in the 90s and somebody made an aggressive push to give it gas in some hacker circles, history would have taken a different path. But that didn't happen and so we live in a broken future. At least 9front is usable for a daily driver these days, I suppose.
I love the pragmatism here. "We try things. Some of them work well, some work badly. We keep the ones that work well."
Go is the proper succesor to C and Plan9/9front, to Unix.
Most of the POSIX cruft does not exist in Plan9/9front. It has a much simpler API. There's NPE, ok, but as an emergency to port some monolitical software from Unix, but not so big. Such as Nethack/Slashem, or Netsurf.
Most of the POSIX cruft does not exist in Plan9/9front. It has a much simpler API. There's NPE, ok, but as an emergency to port some monolitical software from Unix, but not so big. Such as Nethack/Slashem, or Netsurf.
I don't understand this part, can someone entangle this? What is the concept of remoteness here?
"Probably the glaring error in Unix was that it underevaluated the concept of remoteness. The open-close-read-write interface should have been encapsulated together as something for remoteness; something that brought a group of interfaces together as a single thing�a remote file system as opposed to a local file system."
"Probably the glaring error in Unix was that it underevaluated the concept of remoteness. The open-close-read-write interface should have been encapsulated together as something for remoteness; something that brought a group of interfaces together as a single thing�a remote file system as opposed to a local file system."
My interpretation is he's lamenting that certain Unix OS abstractions (e.g. open, close, read, and write) do not lend themselves well to building distributed systems, like a distributed filesystem. Plan9, for example, designed it's API with such possibilities in mind.
And, really, I think he's referring to async I/O.
The thing is that Unix grew up w/o a network. Disk was slow though, so perhaps it could have had async I/O from the beginning, but... everything was slow, so maybe not. Most importantly the key is that when one is building something new, often one will build the easy stuff first, and synchronous metadata operations is definitely easier than async -- this is a lot easier to forgive 50 years ago than now because now we know that async matters a great deal, but 50 years ago it was a lot less clear.
The thing is that Unix grew up w/o a network. Disk was slow though, so perhaps it could have had async I/O from the beginning, but... everything was slow, so maybe not. Most importantly the key is that when one is building something new, often one will build the easy stuff first, and synchronous metadata operations is definitely easier than async -- this is a lot easier to forgive 50 years ago than now because now we know that async matters a great deal, but 50 years ago it was a lot less clear.