It remains probably one of the best books on the subject of operating system design, and all the better for being insanely opinionated.
Fundamental objections included:
* It was user hostile (still is)
* It didn't handle text very well (still doesn't)
* The "de-facto standard" mentality where bugs are promoted as features (still present)
* Lines of text are a bad model for program composability. (If you believe this is false, ask why perl exists.)
If you want to see alternatives to the "lines of text" mentality, you can look back in time to LISP machines, or just play with powershell on a windows box.
Last I checked almost all source code is "just lines of text". Convention is what gives speech / words / code / user interfaces meaning. The Unix command line interface was designed for programmers, and in particular systems programmers; as the old joke goes Unix _is_ user friendly, it's just particular about who its friends are.
In the end though Unix doesn't concern itself with lines of text, it could hardly care, what Unix cares about (at the user interface as opposed to the kernel interface) is files with a stream of bytes. "lines of text" belongs in the domain of application programs.
A lot of the criticisms of UNIX in the UHH come from LISPers with fond memories of the LISP Machine which (like HyperCard) had virtues orthogonal to the virtues of most programming environments today.
Much of the remaining criticism is of its command-line interface. The people who wrote the book were and are very much programmers and systems engineers, so the "UNIX is to 133t for too" argument is off-point. This isn't a bunch of people who think learning Microsoft Word is computer science complaining than reading man pages is too hard.
E.g. I don't know of _any_ UNIX user who hasn't been bitten by a typo with rm.
Anyway, UHH is a fun book to read, and it was nice to be reminded of Ritchie's anti-forward.
I love this line from Don Norman's actual forward:
"Unix survives only because everyone else has done so badly."
I think you misunderstand me. Program composability is the property of being able to compose programs together, not to write a program from scratch. And the philosophy of unix command line is that pretty much everything is a CSV or fixed-width data file. Which is fine until you try to do something with a config file. Basically, the unix toolchain has a really nasty text processing gap between awk and yacc, which perl, to a certain extent, filled. Filled at the expense of throwing away the unix philosophy.
As they said in the UHH, Unix doesn't have a philosophy, it has an attitude. :)
This has always been my favorite part of the whole book:
"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."
It's quite a good book--the modern world of computing has been so strongly shaped by Unix that it's easy to forget that there are other ways. Of course, it makes me giggle when I read Lisp Machine programmers complaining about the size of Emacs (come on, guys, your machines took an hour to boot--I don't think your environments were especially small either), but it's nice to get some perspectives from outside the Gulag :) Reading the UHH led me to go poking around with old systems like ITS and TOPS-10 and VMS--mostly they just annoyed me, but I also learned some interesting things.
It's interesting to see which parts of the handbook are dated, and which are not. Surely nobody these days would criticize Unix for crashing every few days, or complain that copy and paste doesn't work in X, or about a "massive 3/4 megabyte binary", or `ed`... but `rm` is still an irreversible operation (and versioned filesystems still esoteric). Pipes still suck, even if all the alternatives are worse. C programmers still have to deal with manual memory management...
It does what it's supposed to; it gets rid of the file while freeing up space. If you don't like it, then use "git rm" instead of "rm".
C programmers still have to deal with manual
memory management...
Manual memory management is still required because of our current reality. A garbage collector for instance creates a fake reality, one in which you deal with memory as if it is unlimited and extremely fast. This simply does not work for system software. It is possible and it's a romantic notion too, but just as with micro-kernels, people kind of fake it (as in, putting lipstick on a pig) otherwise you're not getting anything useful done.
I do hate Unix operating systems, but the alternatives are much worse. I also liked this quote from the article:
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.
> A garbage collector for instance creates a fake reality, one in which you deal with memory as if it is unlimited and extremely fast.
Actually no, GC does not suggest that memory is unlimited let alone imply anything about its speed. Systems with GC will happily punish anyone who makes those assumptions, just like any other memory management scheme.
GC merely says that a given address may become available for reuse after the last identifiable reference goes away.
I think he meant that GC is a "solution" to the problem of memory management only if you consider memory to be unlimited and fast; in other cases, it incurs a penalty and isn't really a "solution". You took is comment far too literally.
Manual memory management isn't "required" - it's merely the best option in some cases. However, GC is the best option in some others. (Every memory managment mechanism, including manual and even static, has costs.)
Yes, GC can be the best option for system software.
I would really like `rm` to just deprioritize the space taken by the file, so if enough time passes and space is needed, old deleted files are reclaimed.
That is, institutionalize the idea of "undelete" -- but still allow `rm` to make a good trade-off between space reclamation and irreversibility.
Manual memory management is still useful for some things, but it seems you're implying GC is wrong in every situation? I'd say the vast majority of software today is better served by GC'd languages (That does not include many forms of systems programming, however).
I actually like the fact that rm deletes files permanently. But then again I'm the kind of person who HATES the recycle bin/trash can system with a passion, and disable it wherever I can.
When I delete something, I want it GONE. Not later when the system runs out of space. Not after I do a second "empty trash" operation. NOW. If something's important to me, I'll make a backup.
I founded the unix-haters mailing list that the book was based on, and these days I like to say that Unix went from being the worst available operating system to the best available operating system without getting significantly better. (and yes, in the spirit of the list this is no doubt unfair, biased, mean, etc.)
Security ("Oh, I'm sorry, sir, go ahead. I didn't realise you were root") still reads pretty well today. Vi might no longer read its conf file from the CWD, but the standard toolkit has plenty of SUID=0 programs: this vanilla Debian has 17 of them in /bin:/usr/bin. Of these, only sudo really benefits from being architected in this way. Cf. http://lwn.net/Articles/199004/ for another approach.
“I liken starting one’s computing career with Unix,
say as an undergraduate, to being born in East Africa.
It is intolerably hot, your body is covered with lice
and flies, you are malnourished and you suffer from
numerous curable diseases. But, as far as young East
Africans can tell, this is simply the natural condition
and they live within it. By the time they find out
differently, it is too late. They already think that the
writing of shell scripts is a natural act.”
— Ken Pier, Xerox PARC
I have a copy of UHH, and it's a funny read. It even points out some pitfalls to watch out for, at least back in the day. That said, Ubuntu now works pretty darn well, and with "Netflix in a box" devices, we're almost Windows-free at home.
I wonder what Ken Pier thought of something like NOS on CDC-Cyber back in the 80s? Now that was a rough system. "Find the program" (... OK, done, ....) ... "Now, actually run it" (2 steps!); "Compile my program" "oops, 'rewind' the binary output target" (WTF?!?) "Now compile my program so that I see the current result". And so on...
Eloquent rant... that is unfortunately as applicable to itself as to its intended object.
Unix has its good qualities, but anyone who is not aware that systems before it had other good ideas that have been lost, is sadly ignorant of history.
It remains probably one of the best books on the subject of operating system design, and all the better for being insanely opinionated.
Fundamental objections included: * It was user hostile (still is) * It didn't handle text very well (still doesn't) * The "de-facto standard" mentality where bugs are promoted as features (still present) * Lines of text are a bad model for program composability. (If you believe this is false, ask why perl exists.)
If you want to see alternatives to the "lines of text" mentality, you can look back in time to LISP machines, or just play with powershell on a windows box.