Linux, Unix, /etc

Danger Will Robinson! You are now entering a condescending Unix user zone!

The Unix Haters Handbook

Blurb

Hands up who didn't do a double-take at that title! In the first installment of The Essential Linux Bookshelf , several aeons ago, I took a look at The Unix Programming Environment. This time round, in the seventh and final episode, lest I be accused of being a Unix zealot, I'll come in from the opposite side. You haven't heard the last of me, by the way; I'm beginning a new column of book reviews, called "RTFM" (original or what?).

What This Book Means To Me

This book has become quite well-known as a sustained anti-Unix rant. It is an offspring of the Unix-Haters mailing list (now invitation only), a place where poor devils who were forced to use Unix could gather to share their woes; perhaps they still do.

Reading this in 1994 when I'd been running Linux for only a few months, large parts of it were a puzzle to me. Linux simply wasn't like the Unix the book described, or parodied. Indeed, it is ironic that the book was published in 1994, the first year I think that Linux was usable by a non-hacker.

Outline of the Book

Part 1: User Friendly?

The first three chapters of this part are the best of the book. The writers are on firm ground, compiling from the UNIX-HATERs mailing list a selection of horror stories. Even in this part, though, we see again and again people shooting themselves in the foot and then blaming the gun.

1 Unix

"The world's first computer virus".

2 Welcome

The best example of "foot-shooting" is here; the poor wretch who typed

cc -o doit.c doit

instead of

cc -o doit doit.c

The compiler did exactly what he told it to. The problem here is...?

Unix is lambasted as positively user-UNfriendly. Well, I think that is inaccurate. Not "user-indulgent", perhaps.

3 Documentation?

OK, so the on-line help isn't great. What else are O'Reilly books for?

4 Mail

5 Snoozenet

Now, these two chapters seem to me to go off on tangents. What has sendmail to do with Unix? It's an application program, but it doesn't only run on Unix, nor is it the only Unix MTA. So what's the beef? Perhaps it is true that the sendmail way represents in a nutshell everything that's bad about Unix — but our authors don't prove this, they assume it. The same applies for the next chapter. Usenet? What does that have to do with Unix? As much as it has to do with MS Windows, which is I suppose the OS most newsreaders run on. That is to say, nothing. The authors admit as much — so why have the chapter at all? They do score some points at the expense of Unix news-reading software, but blaming Unix for Usenet is silly. That said, the chapter on sendmail is worth it just for that classic error message:

sendmail: "not a typewriter"

6 Terminal Insanity

This is a short chapter, which is strange, because Unix terminal handling is kinda crufty (especially to someone who's never had to work with any other kind: try an old IBM System/38 with those IBM 5250s (I think they were called); then tell me again how awful Unix terminals are).

7 The X-Windows Disaster

I found this chapter telling. X isn't the greatest, is it? But again, what are we comparing it to? In 1994, are you telling me that Win 3.11 was the alternative? What, then?

Part 2: Programmer's System

8 csh

They make some good points about arcane shell syntax, undocumented behaviour, and power tools with a distinct lack of built-in safety features. Some of the examples, though, are simply foolish. For example, on p. 169 we find the following reasonable requirement:

"I wanted to find all .el files in a directory tree that didn't have a corresponding .elc file. That should be easy."

And so it is. The basic shell script is thus:

#!/bin/sh
for i in $*
do
    if [ ! -f "$i"c ];
    then
	echo "$i";
    fi
done

And to run it on a directory tree, just do:

for i in `ls | grep /`
do
	cd $i
	[other script here]
	cd ..
done

How hard is that? (Answer for the Unixly-challenged: not hard at all). It needs a little more work to protect against wierd filenames and empty directories, but for most cases, it will do. Why, therefore, the poor fellow who had this need to find his uncompiled elisp files spent three printed pages on various arcane find(1) command lines beats me. Maybe it was the only command he knew. They say if the only tool you have is a hammer, every problem looks like a nail. Unix gives you a wide and varied collection of software tools, but of course it's up to you to use them properly. One poster to the list quotes with an air of approval the findings of an article in an academic journal. Solemnly, and with a great air of "I told you so", he quotes the following:

"Only experts could successfully produce composite commands that required use of the distinctive features of Unix (e.g. pipes and other redirection symbols)."

Yeah, and back in the real world, it takes about five minutes to teach someone about standard input, standard output, where they go by default, and how to send them someplace else. Are we really being told that

mail -s 'Work from Home!' bigaliaslist > spamfile

takes an expert?

9 Programming

Their criticism of the Unix programming environment relies a lot on out-of-context sniping: such as saying that the few trivial examples given in a Kernigham and Mashey article they quote (a sort of Unix Programming Environment In A Nutshell) completely exhaust the resources of Unix as a Programmer's work space. Yeah, right. This is a shame, as there are valid criticisms to be made here. They do make some telling comparisions with advanced features of boxes such as the Lisp Machine that are still not in Unix, dropping into the debugger instead of dumping core, for example. Generally, the case case is spoiled by exaggeration. I know for sure that I've used other programming environments, which sucked mightily when compared with Unix. I did like the piece about C++; but then, there are plenty of Unix people around who would agree with it whole-heartedly. Once more, what is it doing in the Unix -Haters Handbook? Programming in Plato's Cave "Well, the other day we were looking for all uses of the min function in the BSD kernel code." And so they used

grep min netinet/ip_icmp.c

Hmmm. Obviously, the following shell script (ten minutes work, if that. These guys ARE supposed to be programmers, right?) was beyond them.

#!/bin/sh
#findfunc: another tiresomely simple rebuttal of a silly objection to
#Unix in the "Unix Hater's Handbook"
#bug: `findfunc puts' finds fputs as well
pattern='[A-Za-z_]*[^A-Za-z_]*'$1'[^A-Za-z_]*('
grep "$pattern" $*

OK, so this finds fputs as well if asked to find puts - I can live with that. In the real world, things don't have to be 100% pure and correct. This script does the job well enough - it finds where the function it is given is used.

12 Security

Yes, the Unix security model is... well, let's just say Unix wasn't planned with security in mind. There are better models. Moving right along...

13 The File System

Well, I must admit that I have no experience of "old" Unix files systems, such as the "Fast Filesystem" much lambasted in this section. In these days of ext2 and ext3 and ReiserFS and (what's that IBM thing called again?), It seems like history to me, anyhow.

14 NFS

Now, this chapter baffled me. Not once is it mentioned that NFS is NOT a Unix file system / protocol; that is was explicitly developed NOT to be such; nor that it displaced a far superior Unix-specific network file system. But no-one say anything; we might spoil their fun. Unix Haters, take a hundred lines: NFS is NOT a Unix-specific network file system.
NFS is NOT a Unix-specific network file system ...

Part 4: Et Cetera

A Epilogue

B Creators Admit C

If you haven't heard of this, read it. It is one of the best things in the book. Downright funny.

D Bibliography

Why This Book Is Important

The book has an air of being written by undergraduates, or people who haven't ougrown that sheltered mentality. The criticims of sendmail are mendacious. Some mature words from Eric Allman: "...sendmail took the approach that it should try to accept, clean up, and deliver even "crufty" messages instead of rejecting them because they didn't meet some protocol... It was harder to do, but after all, the goal was to communicate, not to be pedantic." Exactly. And yet, despite the exaaggerations, the omissions, the unabashedly-partisan approach, this book is valuable in several ways. Firstly, in reminding us of the way things were, or seemed, before Linux. OK, Linux is only a part of the solution: the FSF and the various *BSDs played a big part in fixing these things. Secondly, in letting in some fresh air into our Unix cave. Because indeed, Unix isn't perfect. A quote worth thinking about from the Preface: "Unix survives only because everyone else has done so badly." [xvii] In summary, this book is an entertaining read, but badly out-of-date, flawed by an eagerness to ascribe the faults of other software to Unix, and prone to exaggeration. Again and again, I'm wondering what they are comparing Unix with — other than bloody LISP machines, which seem to be mentioned time and time again. But then wasn't Richard Stallman an original MIT LISP guru? And if Unix is so bad, how come he ended up rewriting it? It's hard to fault Ritchie's "anti-forward": "...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!"

How To Get This Book

Sorry about this, but the book is out of print. I've given the details anyway; I'm sure there are plenty of second-hand copies floating around. Bits of it are on the web: try http://ecco.bsee.swin.edu.au/unix/uh/ and http://catalog.com/hopkins/unix-haters/handbook.html .

Title: The Unix Haters Handbook
Author: Simson Garfinkel, Daniel Weise & Steven Strassmann
Publisher: IDG Books
ISBN: 1-56884-203-1
Price: $16.95
Pages: 329
Date: May, 1994

Check my Amazon marketplace — I might have a copy of this book for sale.
Paul Dunne 2000

[back to Linux, Unix, /etc]