The Unix Haters Handbook

ISBN 1568842031 (but out of print)

Online at http://research.microsoft.com/~daniel/unix-haters.html (DeadLink)

from the preface ...

Modern Unix is a catastrophe. It's the "Un-Operating System": unreliable, unintuitive, unforgiving, unhelpful, and underpowered. Little is more frustrating than trying to force Unix to do something useful and nontrivial. Modern Unix impedes progress in computer science, wastes billions of dollars, and destroys the common sense of many who seriously use it. An exaggeration? You won't think so after reading this book.

HaHaOnlySerious

DennisRitchie wrote this in the anti-Foreword::TheUnixHatersHandbook "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."

DennisRitchie was a GoodSport? for writing the anti-foreword but you can really tell that he was sort of PO-ed about it.

Oh, if I had only read this book before I wrote wiki I might not have made the mistake of using tab in the formatting rules. (see Spelling Whitespace [SpellWhiteSpace].) -- WardCunningham

I'm a UnixLover?, but I love this book because I thought it was hysterically funny. Many of the war stories are similar to experiences I've had myself, even if they're often flawed as a critique of Unix itself for one reason or another. But other UnixLovers? I've loaned the book to found it annoying rather than funny, so YMMV.

BTW the core group of contributors to this book were more Symbolics Lisp Machine fans than ITS or Windows fans. ITS had certain technical features superior to Unix, such as PCLSRing as mentioned in WorseIsBetter, but having used it a bit myself, I can't see that ITS was superior to Unix across the board. The Lisp Machine on the other hand, although I never used it, was by all accounts a very sophisticated environment for programmers. -- DougMerritt

The ExtremeProgramming people on this wiki have the skill, ability, and tools to write the next KillerOperatingSystem. Shall we encourage and write StoryCards for it? -- ChrisGarrod... Never mind, I think PlanNineFromBellLabs is the KillerOperatingSystem now that it's out in OpenSource.

Overall, PlanNine is an extremely timid OS design that failed miserably in its own design goals (e.g., Uniformity and Connectedness). For example, it is impossible to fork a process in PlanNine simply by copying the representation of that process. And processes' name spaces are disconnected from each other (see NameSpace). And when it comes down to it, just about nothing is novel in PlanNine, though a great many things in it may be novel to UnixGeeks?. -- rk

Please give examples of the ways in which Unix is "underpowered" and "unreliable". Unforgiving and unhelpful, well yes. Saying that it's "underpowered" and "unreliable" sounds like a rant to me. Sorry, but I'm not quite old enough to remember whatever OS was around before Unix that was so much better. Besides, MyOperatingSystemWillBeatYourOperatingSystem. ;-)

Please give examples of the ways in which Unix is underpowered

When this book was written, VMS was superior to Unix technically in many ways: clustering and stability, for example. Thing is, VMS was extremely hacker-unfriendly. Which is why data-center administrators loved it, which is why most programmers hated it, which is why it died.

On Unix/VMS and hacking: Unix's file-system is both part of its weakness and part of its success. Unix files are just buckets of bits. VMS likes to treat files in terms of records. This can make VMS very nice if you're doing straightforward businessy apps in something like CobolLanguage or PascalLanguage, but it doesn't allow for the kind of free-form expressionistic file-IO work that's done in, say, PerlLanguage.

Unix is written in a high-level assembly language. This is not a "way in which Unix is underpowered". It might be an explanation for Unix being underpowered; or it might be an explanation for Unix not being worse than it is. But in itself it says nothing about how Unix is for its users. Arguments have been made that if Unix were written in SmalltalkLanguage then applications written in Smalltalk would be better integrated with Unix and thus not have to pay such a big performance penalty (CeeLanguage applications would). That's possible. And applications written in CommonLisp or MlLanguage or JavaLanguage or HaskellLanguage or anything else other than Smalltalk would have to pay a big performance penalty. Matching clever languages to C is painful. Matching clever languages to each other is probably more painful.

Just out of curiosity... Are there any efforts at the moment to recreate Unix in an even higher-level language than CeeLanguage, and improve the documentation at the same time?

Its standard filesystems are not LoggingFileSystems, and all three implementations of LoggingFileSystems are a DesignHorror? at first glance. Is logging-ness as such important? Or do you mean things like "A system crash can wipe out a filesystem, and even if it doesn't it may make the machine very slow to boot because it has to spend time checking filesystems"? Having a clean LoggingFileSystem is crucial since that is the first step towards Orthogonal Persistence. More importantly, changing one's mind is an integral part of human thinking and human behaviour. Unix forbids it.

It's not possible to unmodify recently modified files.

It's not possible to easily perform or retrieve backups.

Its filesystem is barely usable; it isn't possible to have multiple hard links to directories and thus there is no way to have multiple logical containment (SymbolicLinks are a horrible hack). Do you mean that you don't like the way in which SymbolicLinks are implemented, or that something's wrong with the semantics? There is something deeply wrong with the semantics. If you have a HardLink to a file then you own that file and someone else's removing their link to that file will not affect you, whereas if you have a SymbolicLink to a file and the owner decides to remove their link to it then you are screwed.

Actually, even normal HardLink semantics are deeply flawed. First, any links in the system should be bidirectional. Second, they should be directed (i.e., with an Up side and a Down side). And third, the 11+ permissions on links in a Unix FS are useless. Some of them don't even make any sense in most contexts. Example: what does it mean exactly to execute a file representing a network connection? For what reason does executing the contents of a file require different permissions from reading a file? And this is without getting into the fact that User/Group/World is an AccessControlList scheme and so is inherently flawed and useless.

: It is possible to have multiple hard links to directories. It is just usually forbidden for someone else than the admin to create them, since they are so dangerous. There actually point several hard links to most directories: One from the parent, with the name of the directory, another in the directory itself with the name '.' and one from every subdirectory with the name '..'.

Special cases do not count.

Actually, it's not a special case to have multiple hard links to directories. Originally, the Unix kernel allowed any hard links to any file, directory, or special file that you wanted. However, since having cycles in the filesystem was a problem for 64k programs trying to traverse the file system (e.g., find), some extra conditions were enforced in command line utilities such as ln and mkdir to limit directory hard links to only the cases that didn't cause insanity.

In other words, you could write a program to do any linking you liked, bypassing the ln sanity checks. I did this myself under version 6 Unix just to screw around. Since then, various versions of Unix have migrated the sanity checks into the kernel itself (into the mknod system call) precisely to make sure that people don't write random programs that can add circularity to the filesystem.

So go ahead and dislike the end result all you like, but don't think that it's because Unix doesn't have the power to do more; it's just that it worked better in practice to go to some extra effort to reign in the full power.

Incidentally, it's often been suggested that filesystems should indeed be graphs with cycles, and just have traversal schemes automatically detect cycles on the fly. This is attractive at first, but causes enough secondary difficulties that it is rarely sighted in the wild in any OS or in any filesystem. Even in programming languages, people tend to prefer adding "weak links" to indicate circularity; it just tends to help avoid problems compared with raw unbridled cycles.

And this is another thing; Unix is wildly inconsistent since directories have backlinks named '..' (and what a cruddy and unoriginal name) while files have no backlinks. And the names of backlinks are unchangeable while the names of forelinks are changeable.

: Okay I'll bite. I've always kinda liked '.' and '..'. What's your pick? (Presumably it should be ingenious and original.)
: The name of the backlink should be anything the user chooses it to be. The backlink of a home directory might be domain of he who thinks of himself a god but by default it would probably be something easily recognizable like inverse of <forelink name> (it must be general since a decent OS should/must allow multiple parent directories).
: Whoa. I'd certainly concede originality points for that one. So in your system I'd forego the cruddy cd ../../../include, to move out of my current location in 'wherever/linux/arch/i386/kernel/', for the more easily recognizable cd lenrek/683i/hcra/include? But I had to proofread that twice just to be sure I spelled it all right. Heh. Actually, you'd do cd 'inverse of kernel/inverse of i386/inverse of arch/'. The entire point of having multiple parents is so you can make a HardLink in 'wherever/linux/arch/i386/kernel/' to 'wherever/linux/include'. And the point of having backlinks is so that when you do a listing of the latter directory, you can see the places it's linked from. You would never 'need' to go back to the top just to go down another path (or even be able to since security demands you be unable to traipse around others domains unless they specifically allow you to); you'd never have to 'get out' from anywhere. And this is quite aside the fact that with multiple parents whose names you choose, you can create backlinks called '..'. Undeclared backlinks cannot be named this by default because it's not general enough, but nothing would stop you from writing a script that renamed all of the backlinks to the boring '..' you're used to (unless you actually made use of the fact that a directory could have two parents, then you'd get collisions).

Ultimately, what the admin can do with the system is completely irrelevant compared to what the typical user can do with the system. And I don't accept that perfectly legitimate user operations should require goat sacrifices in order to appease the system god.

: Nah, for doing Unix you just need to pick the cool jobs, where they give you the root password. :-P And have enough money to buy completely separate machines to run the processes you don't trust.

It uses AccessControlLists instead of CapabilitiesBasedProtection thus making sharing of objects (files) impossible between users on different machines, between different users on the same machine, and sometimes even between the same user on the same machine (making a copy of a file is not sharing).

There is no way to create sub-users or have any kind ofFineGrainedProtection? over anything, so there is no way to give an arbitrary group of users access to just one file or set of files (without acts of divine intervention) nor any way to run a program without that program being able to destroy all of your work. The Java sandbox is complete nonsense and would be completely unnecessary for any OS with RealSecurity?.

You need to reboot the computer just to do a software upgrade. Depends on what software you're upgrading. Could you be more specific? That fragile pile of hacks called the kernel. In microkernels you'd also need to reboot to change some things (like the kernel task scheduler). Except, there are Unix implementations with modular kernels or with microkernels.

The list would go on forever if I just thought about it long enough.

The UnixArchitecture? (i.e., BigBallOfMud) has these fundamental flaws:

it's not secure
it's not uniform
it's not extensible
it's not component composable
it's not connected
it's not distributed
it's not orthogonally persistent
it's not reflective
it's not object oriented
it's not an exokernel
it's not elegant (it lacks the QualityWithoutaName)

So being an exokernel is a fundamental requirement for a decent operating system? Rather than, say, just a particular approach to OS design that appears to solve some problems well?

It depends on what you mean by exokernel. If you mean that OS components need to be able to access the bare hardware, then no. If you mean that the "kernel" only does arbitration & security and does not provide any abstraction, then yes. This is because every component of an OS must obey the same high-level semantics and thus those semantics can't concern themselves with anything beyond access and security. Totally uniform OSes converge on exokernel designs.

Unix breaks every OperatingSystemDesignPrinciple? that I know of.

Unix is impossible to learn. It is the antithesis of SmalltalkLanguage. -- rk

One unique feature of this book is that the publishers saw fit to include a Unix BarfBag inside the back cover of the book!

Yes! One of my favorite books!

To paraphrase Churchill:

Unix is absolutely the worst OS we have, except for all the others.

In a world where desktops are covered in weak OS offerings from Redmond, what else do you do? I would *love* to replace my Unix machines with something that was better designed, widespread (and hopefully portable): no such OS exists. WindowsIsUnix?

What about SqueakSmalltalk running on bare hardware?

This reminds me of the OberonOperatingSystem (Shiver), which could do this. I never actually used Squeak, but what I saw from it, it looks much nicer than Oberon. -- MarkoSchulz

The problem with Smalltalk as an OS is that it has absolutely no security. Its security model is equivalent to DOS and the Merlin OS (from what I understand, adding security to the SelfLanguage) could only hope to rise to the level of Unix insecurity. -- rk

I always thought that the most hilarious thing about the book is, at some point it gives as an example of X's baroqueness in that it supports transparent windows. Then Windows 2000 comes out. . .

(Shrugs) Maybe Longhorn will have curved windows too?

I think desiring versioning in a filesystem is a laudable goal, but are there any modern implementations outside of research projects like PlanNine and ErosOs? I'm not dissing the idea; at the time Plan9 came out, having a massive tape library attached to your system seemed kind of impractical, but at least now one could probably implement versioning on disk without running out of space. . .

VmsOperatingSystem has versioning. OpenSolaris? has ZFS.

It seemed to me that the main criticisms of Unix were

It's not ITS.
It's not Windows.

which is funny because Windows isn't ITS, either.

So... which OS is better than Unix? And what would the requirements be for such an OS????? Unfortunately, the few contenders out there (the various big-iron OSs) seem to be withering on the vine; Windows of any sort is not demonstrably superior to Unix (especially where scalability and reliability are concerned), and the large legion of experimental OS's out there lack sufficient critical mass to be an effective replacement. (Which may be unfair, but CestLaVie.) The suggestion that a first-class OS can be made by implementing a kernel in Smalltalk/Java/etc. rather than C (and thus said OS will automatically inherit the wonderful properties of the language) is terribly naive; OS design and language design are two distinctly different disciplines.

Operating systems, LikeItOrNot?, have a very high barrier to entry; the three major paradigm shifts we have seen in the past 30 years or so (proprietary to traditional UNIX, UNIX to Windows, and now Windows to Linux) were caused as much by changes in the economics of computing as much as anything else. UNIX didn't replace the VmsOperatingSystem and the like because it was better; UNIX replaced VMS because it was cheaper, ran on cheaper hardware, and did the job well enough for many applications. Microsoft used the same strategy (along with a convenient monopoly on desktop OS's) to displace many UNIX implementations in the server room. And Linux is doing the same thing to Windows as we speak.

After Linux, what's next? The trouble is, unless a vendor pays me to run their OS, you're not going to get cheaper than Linux. The OS is rapidly becoming a commodity. The Linux development model also helps to keep the system up-to-date. And, Linux is **GOOD ENOUGH** for most tasks, and has a large variety of apps to run on it.

Unix has been rubbished above because it misses many features that certain authors feel essential. However, the marketplace seems to be getting along fine without those features. The next great OS may have those features, but unless it runs Oracle it won't be a contender.

The ExtremeProgramming people on this wiki have the skill, ability, and tools to write the next KillerOperatingSystem

ExtremeProgramming would probably be a suboptimal choice of process for this task. -- AlexeyVerkhovsky

Why do you think that?

Because (the way I see it, ignorantly perhaps) XP is damn good for rapid development of conceptually simple things whose GoldOwner doesn't know what exactly s/he wants. However, making a KillerOperatingSystem sounds like something that requires a good lot of up-front design and other ceremonia.

Put another way, I have a gut feeling that an OS developed the XP way will end up as another Linux: barely usable tarball of features. But there's already Linux, and it's not a KillerOperatingSystem. For the record: I do have a Linux installed on my PC, for the love of those features. :)

Even if I agreed that any people subscribing to ExtremeProgramming had the skill to make a proper operating system - and for the record, I don't agree at all - I would still disagree that you have the discipline to do so. Extreme Programmers are application programmers, popping away at business apps for their latest client. Yes, it pays the bills, but it's hardly going to win you a Turing Award. To be a good system programmer, you have to have an eye for detail for all of the bugs and misfeatures that the processor manufacturer introduced into their architecture, because somewhere along the line, you're going to have to delve into assembly language, and it isn't going to respond to your faffing about with programming methodologies or fluffy rainbow-coloured object abstractions.

Nice rant, but your obvious youth and inexperience betray you. ExtremeProgramming (and object abstractions) are orthogonal to systems programming and assembly language.

Unix might not be a proper operating system, but it's a pretty good platform for building proper operating systems upon. :)