And still miss my Lisp Machine. It's not that Unix is really that bad, it's that it has a certain model of computer use which has crowded out the more ambitious visions which were still alive in the 70s and 80s.
Much as the web (the Unix of hypertext) crowded out the more ambitious visions of what computational media for intellectual work could be (see the work of Doug Engelbart and Ted Nelson). That's a bigger tragedy IMO. Unix, eh, it's good enough, but the shittiness of the web makes humanity stupider than we should be, at a time when we can ill afford it.
As the GNU coding standards say:
> Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility.
This never really clicked with me because I didn't live through a time when my primary Unix utilities weren't robust. The closest I got was using old (1990's) HP/UX and Solaris and AIX systems where the sysadmins had installed the GNU tools already. All I knew is that I shouldn't use the system tools, because they were worse.
Personally, I think what helped Unix succeed is that the implementations were bad but the architecture made it (mostly) possible to improve the implementations piecemeal. Accordingly, the parts that have had the most trouble improving (like X11, and C) are those where the design doesn't allow this.
What helped Unix succeed was that originally Bell Labs wasn't allowed to sell it, so they gave it to universities for what was a symbolic price in comparisasion what a standard OS used to cost, alongside its source code.
So naturally many stundents from those universities went out and started businesses based on UNIX, like Sun for example.
One of the reasons behing the BSD lawsuit was that AT&T got the license to charge for UNIX after Bell Labs was broken down into smaller units and they were trying to kill off those free branches.
People have a tendency to gravitate towards free stuff regarless how bad the quality happens to be.
But lately I’ve been studying systems that for whatever reason ended up losing out in the marketplace despite having really interesting design decisions and features that would be welcome today. Although I like the classic Mac OS, NeXT, and the modern macOS, I wish Steve Jobs would have “copied” all of Smalltalk and then added Mac-like touches to it. I also wish that Genera were open-sourced instead of the current situation where it’s difficult to obtain legally and inexpensively. I have a dream of writing a modern OS inspired by Genera, Smalltalk, and Apple’s OpenDoc, but writing a new OS is a major undertaking.
Maybe it’s my inner romantic speaking, or maybe I’m just drawn to beautiful things, but I’ve always been attracted to “what could have been” things. Hopefully one day we’ll have a “right thing” OS again, and maybe one day we’ll have an alternative to the Web that isn’t as much of a technology hodgepodge.
But then a rich library at university campus opened my mind to other models of computing and sundenly pure old UNIX wasn't that interesting any longer, only NeXT, which used UNIX compatibility more for winning over Sun's customers than anything else.
And there were mechanisms for an OpenDoc-like system of embedded content (maybe more like OLE). While the rough idea of OpenDoc was and is appealing, I don't think that version of the idea is actually tenable.
Alas, since it was killed, it sort of lives on and occupies that space as an ideal version of the rough idea, rather than as an artefact that can be criticised and improved upon.
25 years ago. Who the hell does that?
I heartily recommend his other writings. In fact, he considers "Worse is Better" some of the worst of his writings, and it is the most successful. ¯\_(ツ)_/¯
Just one that I've gotten a lot of mileage out of is "Habitability and Piecemeal Growth" in Patterns of Software. Lots of other gems in there: Reuse vs. Compression, The Quality Without a Name, etc.
EDIT: Forgot the link
This all happened before my time, but having read a lot about the Lisp Machine I'm as interested in the what-ifs of history if it had won out as the next guy.
I wonder though how much of the legitimate sentiment in this book is simply raging against a machine that's successful and installed in production.
Given widespread commercial use a system where you could modify the running Lisp code of any program down to the kernel would have had its own nightmare stories of sysadmins monkeypatching things in production, and e.g. the perceived shittyness of NFS being replaced by some Lisp-native system where you sent serialized Lisp objects for your program over the wire, with corresponding upgrade hassles if you needed to upgrade a client/server pair.
Plus it's too easy to "reinvent the language" in Lisp. In C-based languages, the block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent. In Lisp, one can roll their own. It's great if you are the lone reader: you can customize it to fit your head. But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop.
Here we are 25 years later and now UNIX is the "good" OS.
The horror.
-Chris
From Symbolics (Overview + Technical Summary):
http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/h...
http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/3...
Texas Instruments, Technical Summary
http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/explorer...
Xerox Interlisp-D Friendly Primer
http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/inter...
Too complex and takes too long to deliver.In the end, the winner takes it all.
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> 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.
Ironically, Unix won yet here we are..
The authors use this convoluted bash script to show that pipes are best suited for simple hacks and might fail mysteriously under certain circumstances:
egrep '^To:|^Cc:' /var/spool/mail/$USER | \
cut -c5- | \
awk '{ for (i = 1; i <= NF; i++) print $i }' | \
sed 's/,//g' | grep -v $USER | sort | uniq
awk '/^To:|^Cc:/ { for (i = 2; i <= NF; i++) print $i }' /var/mail/$USER | \
sed 's/,//g' | grep -v myemail@exmaple.com | sort | uniq
By inverse grepping for myemail@example.com, there will not be mysterious behavior if $USER is in another person's email address.
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 memo- ries. 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, collec- tives 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!
However I think it still has a valuable lesson that many, particularly young CS students, would benefit from: Unix is not the perfect fundamental model for computing. C is not the gospel. Their prevalence today is as much a historic and economic accident as a rational consequence of their objective merits. Both are social artifacts, not manifestations of fundamental truths.
Worshipers of Bell Labs (such as the cat-v or suckless folks) don't get this, and I've seen them pull a lot of people down that rabbit hole with them, particularly young and inexperienced students.
>C is not the gospel
>Worshipers of Bell Labs
I think you're one or two generations late, you'd have to be a hipster to be a CS student worshiping C and Bell Labs these days. I suspect most CS students these days start around web technologies using VS Code in stock Ubuntu, not hacking C programs using Emacs running in dwm on a heavily customized Slackware.
I do agree that cat-v and the suckless folks should be taken with a massive grain of salt though.
When I first came across the UHH, my systems exposure was AmigaDOS, DOS, Windows 95, Windows NT 4, Ultrix, FreeBSD and Linux. I had never used VMS in any meaningful way (David Cutler is a well known Unix Hater) and the idea of "Hating Unix" was off putting because it seemed so useful, and the pain inflicted I internalized as my failing for not properly understanding it. I had no idea how much of a patched together mess it was. Hell, I think if we had continued using DOS that it would have eventually gotten a scheduler, memory protection, pipes and signals and then ended up in largely the same place.
At the part of the stack that most programmers are operating now, the operating system doesn't matter much. We can take the pain points from UHH and apply them to our own lack of system design.
More likely, Visual Studio Code on macOS.
The problem is, this book doesn't actually motivate that lesson. Instead, it spends a lot of its time sniping rather than arguing for why the entire philosophy is perhaps misguided or outright wrong. And sometimes, even the snipe targets are pretty idiotic: when complaining about C++ syntax, for example, the target isn't the incomprehensible nature of template rules [1], but one C++ compiler doesn't lex //* correctly.
[1] I'm not sure anyone actually understands how name lookups work when templates are in play. Instead there's a lot of guesswork and don't-shadow-names-if-it-might-matter going on.
Yes but that sniping does a good job of deconstructing the historical revisionism that Unix was some beautifully architected thing, rather than something that's become less shit over time.
All you really need to figure out for that is what a "dependent name" is. And that has a very straightforward definition.
It's a cynical UNIX manual from the 1990's. Here:
> 14 NFS..............283
> Nightmare File System
> Not Fully Serviceable............284
> No File Security...........287
> Not File System Specific? (Not Quite)..........292
Here also:
> The Oxymoronic World of Unix Security .......243
> Holes in the Armor ........244
> The Worms Crawl In ..........257
I work in IT systems development in a University IT department. I want to read this take on UNIX from 1994, just to see how much better things haven't gotten.
OK, the state of the art has gotten better, but if I compare my work environment which is byzantine complexity and full of bespoke garbage sometimes, to the hells apparently described herein, I bet I can find more similarities than differences.
And that will hopefully make me a more effective communicator about how to make things better with modern convenience technologies that we're not using enough. (Dare I say Kubernetes is the one big thing that is actually majorly different today, compared to UNIX in the 1990's.)
Most of what's on the book has been fixed (not NFS, this one is forever), and we have an entirely new set of things to worry about.
The book is funny, but every part of it feels old.
"We wrote the contract with our publisher to have the copyright revert to us once the book went out of print. So yes, we have the right to publish it online. Feel free to mirror it where ever you want, print it out, and bind it."
I think it's a good book and worth reading still, if not especially, in the modern world where to many people Unix and its family are the hot "alternative" that is often favourably compared against Windows and its ilk.
But I also think that Ritchie's "anti-preface" was already quite on-the-nose when the book came out and has only become more true over time.
But how things change. This was before macOS became BSD-based and before I really got into web development because today, I spend so much time at a shell prompt inside of the Terminal app. I certainly appreciate the elegance of Unix a lot more today.
"We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relationships, the server is the remote machine that runs the application (i.e., the server provides services, such a database service or computation service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.” We’re going to follow X terminology when discussing graphical client/servers. So when you see “client” think “the remote machine where the application is running,” and when you see “server” think “the local machine that dis- plays output and accepts user input.”
Sigh.
Highly recommended.
I found the commentary and history both hilarious and informative. The anti-forward by Dennis Ritchie is also very funny.
If anyone has found similar CS style humor books, please let me know!
> Applicants must also have extensive knowledge of Unix, although they should have sufficiently good programming taste to not consider this an achievement.
I got my second ever hard disk drive through her employee-purchase discount. Eighty megabytes!
It came with a vomit bag.
Try unixux. Really.
And what's funny is, some of the things it criticizes are features I'd not heard of and actually learned from the book itself. E.g. bare double dash.
But in geoscience grad school just five or so years ago, a number of older, but technically minded professors were still using Sun machines, and most of the manuals for geoscientific software tend to provide supplementary information for other modern exotic systems/OSes, so I wonder: has windows replaced Unix as the technically inferior/evolutionary superior champion?
I know because I attended that school and worked with the fathers of Multics. The sad fact is that MIT produces extreme bloatware that nobody understands nor needs (gnu emacs cough cough). MIT has almost ruined unix with bloatware like 'configure' and gcc 'extensionettes'. The repeated rant about memory mapped files (a Multics bedrock feature) has been refuted as showboating hundreds of times by OS designers like my manager at Xerox OSD, the designer of Pilot, and an ex-MIT professor who never drank that Kool aid!
What's happening in OS's right now is that European bloatware is strangling Linux ... The reason Unix got people so thrilled is that it could 'terminate and stay resident' in one single human mind!
Say what you will about Multics, but it had essentially "no buffer overflows" [1], simply because it was written in a more memory-safe language (PL/I). (The stack also grew upward rather than downward iirc.)
It also had several nice features that I wish UNIX/Linux hadn't forgotten, even simple ones such as long names for commands (e.g. list-segments in addition to the 'ls' abbreviation.)
"Thirty Years Later: Lessons from the Multics Security Evaluation (2002)", https://news.ycombinator.com/item?id=16956386
Sure--the people who wrote systems with opposing philosophies to the "unix philosophy" are going to be the ones who write this book. And that they failed-in-the-market ("abortions") is already evident by the fact that HN is probably majority unix (mac) or unix-like (linux).
I confess I'm one of those people who has never used a lisp machine, and admires them greatly. I'd love to hear specific reasons I shouldn't admire them.
UNIX succeeded precisely because it was powerful and yet so simple a person could read any part of it and change it.
However, the kernel of UNIX is now beyond ken for most developers precisely because the developers pursued complexity and marginal features for marginal benefits, something very common in European governments and a part of that culture.
The shell commands went from maybe 50kloc to millions of lines precisely because the Linux developers were desperate for contributions and let MIT bloatware people control that part of the source code, strangling Linux with MIT culture.
The only way that makes sense is if they're referring to Lennart being German, but that's kind of a bullshit argument because SystemD was not some novel idea; launchd was around first and came from the American west coast.
Both your statement and my statement don't really mean anything.