The Birth of Unix with Brian Kernighan
corecursive.com
corecursive.com
The UNIX room - The unix room at bell labs was a shared room where they would hang out and have coffee. Some people worked exclusively in the UNIX room, like Ken Thompson, but most worked in their private offices and came to the UNIX room to share what they worked on and have a coffee and catch up. This room was the culture center of the computing group at Bell Labs.
Because they were all sharing a file system on a single machine, it was easy for various people to iterate on programs. They only had one rule which was if you changed the program last, you were the owner. In some ways, it mirrors how open source works today.
Brian is super modest and claims to be a horrible programmer but he is comparing himself to Ken Thompson, who he thinks is just incredible. Ken once wrote a disassembler, assembler and B interpreter for a mini-computer that ran a printer they were struggling with, in a couple of days, so that they could get it printing again. This blew Brian's mind.
At the time, Brian didn't think that the work they were doing was 'important' in a big sense. The culture was more like working with computers is hard, let's try to make it better and lets try to solve practical problems.
The book "Unix: A History and a Memoir" has many other great details.
You would often make a point and then play snippets from him supporting it. You often gave yourself center stage and used him as evidence. I found it overedited and synthetic, more a performance than an interview.
I came for BWK and left unsatisfied. If that's the style you were going for, that's fine. Maybe it's just my expectations.
It was entertaining lisen. Thank you for making it!
Thank you very much for transcribing the text; it's better to listen, but it's easier to translate to other languages, and also read while looking busy in an office. The audio is better for the Canadian accents though!
As you said in the podcast - "start at the beginning". If it had then proceeded from the beginning to the middle and from there to the end, I would have found it more relaxing to listen to.
On the other hand, there are some of these heavily edited, radio-style podcasts that lots of people think are amazing but leave me confused and annoyed. So maybe you shouldn't listen to me. :)
I also think there are many straight interview podcasts and I'm trying to do something different.
For example, Accidental Tech Podcast inserts a small jingle at the start of a sponsor break whereas Talk Python inserts a sudden awkward silence in the conversation. It took me many episodes of the latter to stop wondering if the player had crashed, or if the interviewer lost his train of thought, or the guest was offended, etc. The jingle lets the listener know what's happening, which gives a more relaxing listing experience.
So some easy way to distinguish the interview from the narration would be useful, I think.
But maybe I'll be less confused once I've listened to a few more episodes. A new podcast always takes some getting used to. Thanks for making it!
For the next level up here's Ken (in a very interesting conversation with Brian Kernighan about the history of Unix) describing McIlroy:
> McIlroy keeps coming up. He's the smartest of all of us and the least remembered (or written down)... McIlroy sat there and wrote ---on a piece of paper, now, not on a computer--- TMG [a proprietary yacc-like program] written in TMG... And then! He now has TMG written in TMG, he decided to give his piece of paper to his piece of paper and write down what came out (the code). Which he did. And then he came over to my editor and he typed in his code, assembled it, and (I won't say without error, but with so few errors you'd be astonished) he came up with a TMG compiler, on the PDP-7, written in TMG. And it's the most basic, bare, impressive self-compilation I've ever seen in my life.
This story, by the way, leads into how Ken created B (and how that was eventually improved by Dennis Ritchie into C).
I checked out that youtube link too - you might be interested to know that his t-shirt says "επιτέλους το κατάλαβα" which is Greek for "eventually I understood it" - I thought that was neat :)
It looks like my professor was just taking after the people he worked with. For that level of programmer, writing new drivers for hardware was a weekend project.
One of our CompSci textbooks was written by that same professor -- I just took it down off the shelf and looked at the intro. Brian K. was thanked for being an early reader of "several revisions."
In retrospect, it's really cool to have been only a couple degrees away from that kind of history -- and I probably didn't quite realize how awesome that was back then.
Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)
> Another reason the "horde of C hackers" approach has worked remarkably well is that, although the resultant software is rife with bugs, most users have no experience with anything better. When an MBA's Macintosh Quadra crashes due to a C programmer's error in Microsoft Excel, he doesn't say "I remember back in 1978 that my VAX 11/780, with only one tenth the processing power of this machine, had memory protection between processes so that a bug in one program couldn't corrupt the operating system or other applications." Rather, he is likely to say, "Well, it is still easier than using pencil and paper."
but places the blame on a switch to lower-level languages and runtime systems. The improvements on the desktop over about the '00s seem to be attributable to (not an expert) the mainstreaming of, and continued development of, the WinNT and OS X platforms, increasing use of memory-managed languages and/or more recent versions of C++ in applications, and adoption of online crash-reporting infrastructure (though probably also increasing use of increasingly effective error-detection tools, which I assume Blow is fine with as they don't create a runtime dependency). So it certainly seems that Greenspun is more correct than Blow, which is certainly not to say that adding more layers of infrastructure has always been an unqualified good.
Also, Blow's talk has a very '90s focus on crashers, error messages, and the like, but many of the worst regressions in software over the last 10 or 20 years don't manifest as crashers or other straightforward bugs at all; and when they do manifest as bugs the bugginess is often intertwined with architectural issues in a way that makes a bug-hunting mentality relatively ineffective. For example, the pinnacle of WYSIWYG rich text editing was probably about Word 4 for Macintosh, which was a slightly awkward but workable mating of stylesheets to the WYSIWYG UI. Unfortunately it was something of a local optimum: further progress on the problem largely requires serious developer thought and/or further user education. So everyone more or less decided to instead pretend that rich text is a solved problem, and things have largely been gently regressing since then. Which is probably part of the deep background to the GMail rich-text jank Blow complains about at 23:47 https://youtu.be/ZSRHeXYDLko?t=1427 . “We can not solve our problems with the same level of thinking that created them”, as Lincoln said. ;)
Unix founder number
Bell Labs number
I remember that when a friend first introduced me to Linux around 2002 (we were both high school kids), I ended up writing a rudimentary printer driver as the printing support in Linux required installing 250MB worth of packages that I simply didn't have enough space for, as I had installed Linux to a 1GB partition that I got after squeezing the Win98 on my father's laptop into 3GB. I used Red Hat Linux—not the most minimal distro but I had no idea what I was doing. So when I wanted to print something and couldn't install the printing packages, I grabbed the paperback printer manual which described all the low-level commands the printer supported, studied it to find the commands I'd need and then wrote a simple program that took an image and sent it to the printer. It couldn't have been longer than a few hundred lines.
The printers back then were simple and came with real reference manuals that documented how to communicate with the printer, so you could really write a simple printing program/driver without being a UNIX legend (I am not).
I've met folks who worked in Bell Labs and feel enormous envy for the opportunity they enjoyed by working there. Sadly, Bell Labs now seems like a distant, never-to-be-repeated experiment. There's so much intense focus these days on short-term ROI and responding to market pressures. Creativity and discovery very much take a back-seat to predictability and keeping the stock market "happy".
Are there modern-day places like Bell Labs? Or am I idealizing what it was like there?
Don't know the answer to your exact question.
But I wouldn't be surprised if there are at least a few (meaning tens, if not a few hundred) of startups / small and medium companies in the world that have at least a partly Bell Labs-like tech and innovation culture, somewhat modified due to being commercial entities vs. a research place. I have come across descriptions of actual such companies in the past.
I’ll for sure be including a link to it in one of my upcoming newsletters.
Goodreads Link - https://www.goodreads.com/book/show/53011383-unix
Katie Hafner "Where Wizards Stay Up Late: The Origins of The Internet"
I recommended this book before here: https://news.ycombinator.com/item?id=22692281
https://www.informit.com/store/design-and-implementation-of-...
Marshall Kirk McKusick has done some talks on the subject.
https://www.youtube.com/watch?v=DEEr6dT-4uQ
https://www.youtube.com/watch?v=nwbqBdghh6E
https://www.amazon.com/Idea-Factory-Great-American-Innovatio...
Search for the many HN comments about this 2013 book:
https://www.google.com/search?q=idea+factory+site%3Anews.yco...
Michael A. Hiltzik's Dealers of Lightning about the heyday of computing research at Xerox PARC isn't universally praised (IIRC it's more or less Bob Metcalfe's version of the story) but it is very readable.
Bob Johnstone's We Were Burning, about the golden age of Japanese consumer electronics (wich also covers many events and actors in the US and UK).
David Kushner's Masters of Doom, about the heyday of Id Software.
The First Computers—History and Architectures is a more academic book, a selection of history papers, but it's still very readable. The Computer Pioneers: Pioneer Computers videos https://www.youtube.com/watch?v=qundvme1Tik&list=PL14396C953... , presented by Gordon Moore himself, cover much of the same ground (it says little about the wartime Bletchley Park computers).
If I'm going to allow myself some videos then I should also mention Steve Blank "Secret History of Silicon Valley" talk https://www.youtube.com/watch?v=ZTC_RxWN_xo and David Alan Grier's "When Computers Were Human" talk https://www.youtube.com/watch?v=YwqltwvPnkw .
https://www.goodreads.com/book/show/38212134-how-the-interne...
The 'Internet History Podcast' that was made while writing the book is also excellent.
The Friendly Orange Glow (2017) by Brian Dear is also very good. He's also on HN.
https://www.goodreads.com/book/show/34373814-the-friendly-or...
Accidental Empires (1996) by Robert X Cringely is also pretty good:
https://www.goodreads.com/book/show/27652.Accidental_Empires...
These books go into about as much detail.
It's more technical history.
Almost any really major technology or tech company likely has had a book or two written about it. Some examples off the top of my head:
The HP Way
The IBM Way
The New Magicians (Microsoft)
Heard of Fire in The Valley but not read it
The Soul of a New Machine
Hackers by Steven Levy
Sure to be many books about Unix
The Art of Unix Programming (more on tech, but a good amount of history)
There probably are more books about (in no particular order):
Dell, Sun Micro, Compaq, DEC, Novell, SCO, IBM, Wordstar, WordPerfect, Lotus (both company and tech), dBASE, Borland, Microsoft, AutoCAD, Adobe, HP, Silicon Graphics, Tandem, Ardent, Amdahl, Wang, Toshiba, Acer, Sony, Sinclair, Commodore, Atari, Acorn, Facebook, Twitter, MySpace, LinkedIn, Amazon, Netflix, Apple and a host of lesser-known or older companies, both in the US and elsewhere. The list above has non-US companies too.
It's fun to read about the history of our field. I keep doing a bit of it now and then.
That being said, I think you will be able to read it on the kindle player on a desktop computer. At least, that worked for me. I admit this is not ideal, but the book is fantastic and it was worth the extra effort.
An example: In that first class (COS 333) with ~150 students, I was surprised when he knew my name — and then I found out that he didn't know just my name but the names of all of his students. It takes a special kind of professor who takes the time to do that every semester.
0:24:31 The photo must be the one at https://www.bell-labs.com/usr/dmr/www/picture.html (probably the webpage, on Dennis Ritchie's old website, that made it famous recently).
The last part is very quotable: "They had one grave disadvantage, none of them were Ken Thompson"
https://www.youtube.com/watch?v=EY6q5dv_B-o (starting at about 11 minutes in to the video)
1. It is great to hear Brian Kernighan's account of the early history of Unix.
2. It was wonderful to hear about his interactions with one of my personal heroes, Richard Hamming. Hamming's book on error correction (Coding and information theory) is amazing.
3. It is very kind of Adam Gordon Bell to make these wonderful interviews available. These interviews are oral history that will never again be available once the interviewees are gone.
Con:
1. The interviewer talks far too much about irrelevant trivia and often talks at greater length about than the people being interviewed.
2. It has the feel of Adam Gordon Bell interviews Adam Gordon Bell. A little less Bell and more of the interviewee would have been less irritating and easier to listen to.
Despite my caveats, I intend to download and listen to many more of these interviews on my commute to work.
Keep up this historically important work, but please let the interviewees talk without continually interrupting.
It's different from other programming books I read from APress, O'Reilly publications.
Hard to digest but never before read a book so short and crisp that fully explains the programming language.
To any noob programmer out there, I'd say pick K&R's book, spend a semester on it, do the exercises. You will become better engineer. You'll not regret.
I don't think KnR will make you a much better engineer. But it will give you a really strong boost into being a reasonable c programmer. And it does that well because it focuses on that.
At that time I was writing verbose loops in class assignments to write similar functions. Looking their code made a strong positive impact. Their codes are poetic.
And the way they unfold topics in the book is so good. Structures and pointers often confusing many people I knew were natural in their book.
Also, they are free.
> Bonnie went off to California bearing their son who at the time, I think was a year old or something like that. And was there for three weeks. And so Ken figured that he was close and so he built himself basically a working operating system in three weeks. And I think you could argue that’s serious soccer productivity in some sense.
> ... And then what I showed Colby was actually something that basically said sleep for two seconds, and then print the result I had done the day before.
& I really wish the chocolate bar thing is done in my office one day!
That's probably a good formula to go by: get interviews with "big names" who have done incredible things in the field, make the content as good as you can, and submit to HN.
Personally I would love to hear an interview with Fabrice Bellard, if you can get him. That man is a true "superstar" of programming. Interview Fabrice and you have my subscribe, 100%.
I spend way too much time lurking on hacker news so having this show up here is both exciting and frightening for me ... be careful what you wish for.
Nope, in fact it even had a better security model that UNIX clones are yet to achieve.
I also wondered if there are sources from any of their (Dennis Ritchie, Ken Thompson and the group) work hopefully in C or something that I can actually understand.
Fun fact, the original unused PDP-7 computer mentioned in the article that being utilized by Ken Thompson to first develop UNIX actually belongs to another well-funded sound processing research group in Bell Labs.