Anti-foreword to the Unix haters handbook by dmr
pastebin.com
pastebin.com
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.
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.
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."
As they said in the UHH, Unix doesn't have a philosophy, it has an attitude. :)
If you try to process source code with the unix tools built with the "just lines of text" model, you won't get very far.
If you use a parser with rich data types -- you can do so much more.
Unix is not just a kernel -- Unix includes the "application programs" and criticizing their weakness is criticizing Unix itself.
"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.
`rm` is still an irreversible operation
C programmers still have to deal with manual
memory management...
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.
Many of it's sections criticism what were at the time implementation limitations or bugs, only some of it really criticises Unix itself.
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.
Yes, GC can be the best option for system software.
No mechanism is best in all circumstances.
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).
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 do complain that copy and paste don't work very well in X. There seem to be several incompatible intermediates stores for the cutted texts.
But it's still strange, that marking text does a different copy than Ctrl-C in Chrome, which gives a different thing than M-W in Emacs.
For example, from the preface:
“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 PARCI 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...
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.