The UNIX-HATERS Handbook, a review

[athornton]

(note: this was first posted on Google Plus in something like May of 2018)

_The UNIX-HATERS Handbook_

 

Edited by Simson Garfinkel, Daniel Weise, and Steven Strassmann

 

_The UNIX-HATERS Handbook_ dates from 1994.  I read it when it came out or very shortly thereafter, I think.  I was a lot more invested in operating system wars back then.

 

Almost twenty-five years later I decided to revisit it.  From today's perspective, it's an interesting cultural artifact.

 

The tl;dr is:

 

This book has not aged well.  As a book it's incoherent.  It's a bunch of loosely-agglomerated chapters about things people hated about Unix in the late 1980s and early 1990s; most of it is drawn from the UNIX-HATERS mailing list starting in about 1987.

 

The thing it reminded me most of, to be frank, was some dreadful book my late grandfather-in-law had about Obama.  That book devoted a whole lot of energy to How Horrible The Negro-In-Chief was without ever stopping to consider that if he was a secret Muslim then he probably wasn't taking orders from a honkey-hating Christian minister, and if his wife was the brains and brawn behind their marriage then he probably wasn't a mastermind of the Black Illuminati.  Like that, this thing is a litany of Things Someone Hates About Unix, whether or not those things are mutually contradictory.

 

From a two-decades-plus-later perspective, the gripes can be filed into one of just a few categories.

 

The first is, "no, you're wrong.  This actually was a sensible way of doing it."  That applies to things like "files are just streams of bytes" and "pipe things together."  I mean, it's not like we haven't had our share of pipeline systems that dealt with things at the object level.  The two I happen to know reasonably well are Powershell and CMS-PIPELINES.  Both of those have much, much more complicated interfaces.  That makes them somewhat more powerful (in that you don't have to explicitly serialize your stream before passing records or objects to the next stage) but also way, WAY harder to use and to document, because you have to care what your input records are.  Now, I adore CMS PIPELINES, and Powershell is...OK, I guess?...but the cool part about Powershell isn't that you're passing complex objects around, it's that you have access, from the shell, to all the DLLs in the system, and thus every single library call.  (Apparently you can sort of fake this on Linux (and other Unix?) systems with D-Bus.)

The second category is "yeah, that was annoying, and in the intervening time it got fixed."  That applies to the "the GUI sucks" category (I'm writing this on a Mac OS box, and you probably have either an Android or an IOS device in your pocket, don't you?).  It applies to the "the shell is clunky" category--and already did by 1994.  I remember vividly having to get the muscle memory for tab completion switched over from esc-completion when I started using bash on Linux systems rather than csh on SunOS (or whatever) systems.  The Berkeley Fast File System is another target, and, yeah, it has limitations, so we got ext2-and-3-and-4 and reiserfs and ZFS and all the experimental file systems of the last 25 years.  But that's also the third category.

 

There were a lot of things assumed to be essential features of Unix that, in retrospect, were only Unix-adjacent.  Sendmail and Usenet are the big two in this particular book.  Sendmail is instructive.  Yes, sendmail.cf is utterly horrific, and the m4 macros designed to make it suck less were only kind of better.  And then we had qmail, which, well, Dan Berenstein and speaking of toxic personalities, and then the world settled down on Postfix, written by someone who was a fairly nice guy, and configurable in a fairly straightforward manner.  I myself stayed with Exim, because Phil Hazel was awesome and I understood Exim syntax. And now in the 201xs, it doesn't matter anymore because to a first approximation everyone outsources their mail to Google or Microsoft. (not me!  I still run my own Exim system and do my own spam filtering and boy howdy is it wretched since I don't have Google's training corpus)

 

And finally there's the fourth category: things the book is right about.  Yeah, NFS file locking is still terrible, even now.  Like, literally the project I am working on right now has to do local locks, which of course means that two people on different machines better not edit the same file at the same time.  But twenty-five years later I feel like we can definitively state that distributed filesystems are indeed pretty hard. Another completely reasonable observation of _The Unix Hater's Handbook_: Unix man pages are prickly, incomplete, inconsistently designed, and not very helpful if you don't already know what you're looking for.  And while not every system did it better, well, Multics, TOPS-20, and VM/CMS all certainly did, so the dire state of Unix documentation is a fair criticism.

 

If you want a chapter-by-chapter critique, I will recommend that you read Eric Raymond's review of _The Unix Hater's Handbook_ from 2008: http://esr.ibiblio.org/?p=538 .  I'm not a big ESR fan in the general case, but he pretty much gets this right.

 

There's another thing about this book that is only clear from a modern perspective.  When it was written (though perhaps not when it was published), it looked like Unix was likely to win but it wasn't a _fait accompli_.  (In the mid-to-late 90s it looked like Windows might manage to strangle all the Unices.)

 

From the vantage point of 2018, well, Unix won.  Unix (which I mean in a broad sense, specifically one that includes Linux) won everything but the corporate desktop.  Anything running in the cloud or any service at a data center?  Probably Unix.  Your smartphone?  Almost certainly either IOS or Android.  The kernel might or might not be Unix, but the programming model and userland?  Unix.

 

You're probably stuck using Windows at work.  But hell, these days, Windows 10 comes with a Linux compatibility layer.  Google just released gVisor, which is basically a Linux-syscall proxy layer written in Go. Plop that on top of Fuchsia and you can suddenly run a great many Linux applications, unmodified, on top of a much, much simpler underlying system.  So even if you don't *want* to run a modern Unix from a resource perspective--it's what your developers are developing to.

 

But this is a very strange book, even for 1994.  It makes no mention of Linux, which, OK, I guess that's on the edge of acceptability.  It makes no mention of Windows, and that's a little weirder.  Most of what it seems to be bemoaning is that Unix was winning in the early 90s, and not a descendant of something better.  Now it reserves a bit of spleen for VMS, so "something better" seems to mostly mean "TOPS-20, ITS, WAITS, Multics, or a LISP Machine."

 

DMR, may he rest in peace, addressed this his Anti-Forward:

 

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

 

And at this juncture something is fairly easy that wasn't when ESR wrote his review, and wasn't even possible when the book was written.

 

I've installed TOPS-20, ITS, and Multics on emulators so that I can evaluate for myself how true this is.  I have not emulated a LISP Machine, alas.

 

You'll note that the first two of those only ever ran on DEC-10s, which were never cheap machines.  ITS was pretty much an MIT-specific environment running on a single machine, and WAITS was its Stanford counterpart.  Nifty, but of limited reach (although greatly influential in later development of systems).  Likewise, Multics was only ever available on extremely large, expensive, and, let's be frank, also-ran machines.  I'd love to have a Symbolics LISP machine but they didn't react fast enough when Sun cut the floor out of the workstation market.

 

So, in a nutshell:

 

People aren't kidding about Multics.  It's a very nice-feeling system, with useful online help.  I can absolutely see how if you wanted to kind-of-replicate the Multics experience on the very, very much cheaper hardware of a PDP-11, you'd end up with something like early Unix.  But that, of course, is one of the points that _The UNIX-HATER's Handbook_ resolutely fails to acknowledge.  A whole lot more people had access to PDP-11s than to GE-645s.

 

TOPS-20 is also kind of nice.  The command editing is well-done.  The help system is, once again, definitely superior to Unix's.  I can understand why someone would prefer it to early Unix.

 

A brief parenthetical aside: I found it slightly curious that the retrospectives on the personal computers of my youth (C-64, ZX Spectrum, Amiga, et al) always focussed on games.  I mean, sure, those are generally the most visually appealing things on the system, and of course you wouldn't want to try to use those systems' productivity software now, while their games are still fun.  And then I found myself installing all these ancient large-computer systems, and what do I run on them?  Adventure.  Zork.  Moria.

 

And then we get to ITS.

 

Seriously, people?  This is the embodiment of the dark side of the MIT attitude expressed as software.  A system that gives you the hardware debugger as its shell, proudly calls its userbase "lusers", and is very forthrightly smug about "if you don't already know everything there is to know about the PDP-10 architecture as modified at MIT, die in a fire."  This is a command environment that not even a mother could love.  The user experience is dreadful.  Sure, I know that Macsyma and Scheme and Zork all came out of here, but...sheesh.  This is not merely unusable in the 21st century, it's the epitome of a user-hostile environment.

 

So, from my brief experiments: sure, there were a few systems around prior to Unix that were better in many ways.  They also existed only on extremely high-end and expensive machines and so were inaccessible to the vast majority of people who _could_ afford a PDP-11.  ITS is just horrific to use.

I've enjoyed writing this on Emacs on MacOS, which is to say, an editor that first appeared on ITS, but was rather quickly ported to Unix. MacOS is a Mach microkernel with a BSD Unix userland on top of it.  I get a perfectly adequate GUI, and I also have a bunch of terminal windows open in which I can do all the traditional Unixy stream-of-bytes pipeline stuff.  One of the things about the worse-is-better not-much-there-there model is that it's pretty easy to port things to a Unix/C world, and so it's easy to grab an editor from a different OS lineage and get it working in the Unix model.

 

This book was whiny and ludicrous when it first came out.  It has only gotten more so since.  It's still got a few valid criticisms of Unix, but the really interesting thing is how much of what its authors complained about turned out to not be intrinsic at all, and to get fixed rather quickly.  I still believe, and the state of computing in 2018 seems to bear this out, that Unix was a good compromise, that gave usability and an easily-articulated-and-implemented philosophy, on top of (relatively) cheap hardware.

 

Note that this doesn't explain Linux's hegemony.  For that we would need an analysis of Free Software and a discussion of the Unix Wars, and this review isn't the place for that.  But it does explain why DMR was right, and the authors of _The UNIX-HATER's Handbook_ were wearing rosy-tinted goggles and exercising very selective memory when loudly and inaccurately proclaiming that the world was so much better when they were immersed in the cesspit of ITS.