"Linux Gazette...making Linux just a little more fun!"

Review: The Unix-Hater's Handbook

by Andrew Kuchling [email protected]

I've written a review of an old (1994-vintage) book that may be of interest to Linuxers. While even just its title will annoy people, there actually is material of interest in the book to Linux developers and proponents.

Andrew Kuchling
[email protected]
http://starship.skyport.net/crew/amk/

Summary: A sometimes enraging book for a Linux fan, but there are valuable insights lurking here.

In his Anti-Forward to this book, Dennis Ritchie writes "You claim to seek progress, but you succeed mainly in whining." That's a pretty accurate assessment of this book; it's one long complaint about work lost due to crashes, time wasted finding workarounds for bugs, unclear documentation, and obscure command-line arguments. Similar books could be written about any operating system. Obviously, I don't really agree with this book; I wouldn't be using Linux if I did. However, there is informative material here for people interested in Linux development, so it's worth some attention.

The book describes problems and annoyances with Unix; since it was inspired by a famous mailing list called UNIX-HATERS, there are lots of real-life horror stores, some hilarious and some wrenching. The shortcomings described here obviously exist, but in quite a few cases the problem has been fixed, or rendered irrelevant, by further development. Two examples:

* On the Unix file system: "...since most disk drives can transfer up to 64K bytes in a single burst, advanced file systems store files in contiguous blocks so they can be read and written in a single operation ... All of these features have been built and fielded in commercially offered operating systems. Unix offers none of them." But the ext2 file system, used on most Linux systems, does do this; there's nothing preventing the implementation of better filesystems.

* "Unix offers no built-in system for automatically encrypting files stored on the hard disk." (Do you know of any operating system that has such capability out of the box? Can you imagine the complaints from users who forget their passwords?) Anyway, software has been written to do this, either as an encrypting NFS server (CFS) or as a kernel module (the loopback device).

There are some conclusions that I draw from reading this book:

First, when the book was written in 1994, the free Unixes weren't very well known, so the systems described are mostly commercial ones. Proponents of free software should notice how many of the problems stem from the proprietary nature of most Unix variants at the time of writing. The authors point out various bugs and missing features in shells and utilities, flaws which could be *fixed* if the source code was available.

Better solutions sometimes didn't become popular, because they were owned by companies with no interest in sharing the code. For example, the book praises journalled file systems such as the Veritas file system, because they provide faster operation, and are less likely to lose data when the computer crashes. The authors write, "Will journaling become prevalent in the Unix world at large? Probably not. After all, it's nonstandard." More importantly, I think, the file system was proprietary software, and companies tend to either keep the code secret (to preserve their competitive advantage), or charge large fees to license the code (to improve their balance sheets).

The chapter on the X Window System is devastating and accurate; X really is an overcomplicated system, and its division between client and server isn't always optimal. An interesting solution is suggested; let programs extend the graphics server by sending it code. This approach was used by Sun's NeWS system, which used PostScript as the language. Unfortunately NeWS is now quite dead; it was a proprietary system, after all, and was killed off by X, which was freely available from MIT. (Trivia: NeWS was designed by James Gosling, who is now well-known for designing Java. Sun seems determined not to make the same mistake with Java... we hope.)

Second, many of the problems can be fixed by integrating better tools into the system. The Unix 'find' command has various problems which are described in chapter 8 of the book, and are pretty accurate, though they seem to have been fixed in GNU find. Someone has also written GNU locate, an easier way to find files. It runs a script nightly to build a database of filenames, and the 'locate' command searches through that database for matching files. You could make this database more than just a list of filenames; add the file's size and creation time, and you can do searches on those fields. One could envision a daemon which kept the database instantly up to date with kernel assistance. The source is available, so the idea only needs an author to implement it...

Chapter 8 also points out that shell programming is complex and limited; shell scripts depend on subprograms like 'ls' which differ from system to system, making portability a problem, and the quoting rules are elaborate and difficult to apply recursively. This is true, and is probably why few really sizable shell scripts are written today; instead, people use scripting language like Perl or Python, which are more powerful and easier to use.

Most important for Linux partisans, though, it's very important to note that not all of the flaws described have been fixed in Linux yet! For example, most Linux distributions don't really allow you to undelete files, though the Midnight Commander program apparently supports undeletes. As the authors say, 'sendmail' really is very buggy, and Unix's security model isn't very powerful. But people are working on new programs that do sendmail's job, and they're coding security features like the immutable attributes, and debating new security schemes.

For this reason, the book is very valuable as a pointer to things which still need fixing. I'd encourage Linux developers, or people looking for a Linux project, to read this book. Your blood pressure might soar as you read it, but look carefully at each complaint and ask "Is this complaint really a problem? If yes, how could it be fixed, and the system improved? Could I implement that improvement?"