Better than POSIX?

Posted Mar 17, 2009 18:19 UTC (Tue) by rsidd (subscriber, #2582)
Parent article: Better than POSIX?

Your characterisation of the Unix Haters Handbook as "childish" itself seems childish. First, it was written in the days when Unix itself was proprietary (Linux and BSD were around, but barely), so there wouldn't have been much harm in another proprietary system winning (and VMS is only one of many systems the authors seem to prefer; ITS and Lisp machines were others). Second, it is alarming how much of the book rings true even today. This quote from page 19 resonates in the present context: "Unix programmers have a criminally lax attitude toward error reporting and checking. Many programs dont bother to see if all of the bytes in their output file can be written to disk. Some dont even bother to see if their output file has been created. Nevertheless, these programs are sure to delete their input files when they are finished." (This is a problem because of the "worse is better" philosophy of Unix. By the way, Gabriel's article is a later appendix here, not part of the original handbook.) And most of the chapter on filesystems is very true even today; practically all of it is true on ext2, which was the de facto Linux filesystem until recently.

Better than POSIX?

Posted Mar 17, 2009 19:33 UTC (Tue) by ncm (guest, #165) [Link] (5 responses)

At the risk of being accused myself, I will point out that the accusation above is at least equally childish. The Unix Haters Handbook made no bones about its shallowness or its sour-grapes attitude, and neither should we. Implicit in any criticism of an established target is the awareness that, were the tables turned, one's favored alternative has (or would have, had it survived and evolved) plenty to complain about. That said, a Windows Haters Handbook at a similar level of detail would be much, much longer and could be decidedly less subjective about the flaws, and therefore less fun. The difficulty of maintaining the right balance is demonstrated by how badly all UHH's imitators have done.

It's amusing to me that Gabriel's example of interruptible read() and write() system calls utterly fails to illustrate his point. The interface complexity of these system calls can be completely hidden by simple C library functions, and the code to implement them is much, much shorter than would be needed in the kernel to re-run the interrupted calls. Furthermore, a user program might well prefer to bypass such help, e.g. in case it could do something else useful before performing more I/O.

That said, Apollo's Aegis, evolved from Unix's predecessor Multics, had a much better interface to read(): it took a pointer to a buffer, but normally would return a pointer into the OS's own file buffer, usually avoiding a copy operation. Unixen didn't typically have a nonblocking read until remarkably recently, and it still doesn't tend to work well with disk files.

Better than POSIX?

Posted Mar 17, 2009 21:38 UTC (Tue) by bcopeland (subscriber, #51750) [Link] (3 responses)

> It's amusing to me that Gabriel's example of interruptible read() and
> write() system calls utterly fails to illustrate his point.

I don't see how the example undermines Gabriel's point. As far as I can tell,
he was very much arguing in favor of worse-is-better, that having the best
interface for the sake of it is brain-damaged, and so the Unix solution of
EAGAIN was superior to the MIT way, even though the interface was arguably
"worse."

Better than POSIX?

Posted Mar 18, 2009 6:23 UTC (Wed) by rsidd (subscriber, #2582) [Link] (1 responses)

He was not arguing that this is intrinsically better. He was arguing that worse-is-better spreads, the way viruses spread.

Someone else above made the point that worse-is-better was quite reasonable in the 1970s and 1980s when computers were extremely slow and people were willing to sacrifice stability for speed. (Lisp machines, I believe, literally took all morning to boot; and garbage collection was time for a coffee break. At the other extreme, completely unprotected operating systems like CP/M and MS-DOS, that let programmers do pretty much anything they liked, managed to have useful applications like WordStar that were as smooth and interactive as today's word processors. Unix machines lay somewhere in the middle.)

Also, programming was an arcane art and OS designers were willing to trust application designers to "do the right thing" (and if they didn't, the consequences were immediately noticeable).

Today's computers are a few orders of magnitude faster, but are still running operating systems built on assumptions that ceased to be valid nearly two decades ago.

Better than POSIX?

Posted Mar 18, 2009 6:58 UTC (Wed) by mgb (guest, #3226) [Link]

In the 80's a Lisp machine would start in the few seconds it took the monitor to warm up because it was almost always started from what we would now call suspend-to-disk. Loading a new image could take half an hour or more but you only did this a few times per year.

Garbage collections caused zero delay, as incremental garbage collection was supported in microcode.

Just like today, if you needed a coffee break in the 80's you had to find something huge to compile.

Better than POSIX?

Posted Mar 19, 2009 23:11 UTC (Thu) by jschrod (subscriber, #1646) [Link]

No, Dick doesn't argue in favor of worse-is-better.

He states that it is an observable fact that the worse-is-better school has a better adoption rate than the do-it-right-the-first-time school; for several reasons, only some of them technical. And that fact makes him sad, because he is very much a member of the do-it-right-the-first-time school -- you just have to read his report about CLOS to recognize that, even if you have never spoken to him personally. (I have, so this is not hearsay.)

Prerequsite for UHH

Posted Mar 19, 2009 18:15 UTC (Thu) by dmarti (subscriber, #11625) [Link]

You couldn't have a UHH without all the boasts about the elegance of Unix from otherwise mostly sensible people. Microsoft's OS products have been driven by backwards compatibility, business side demands for lock-in, and stripping out features to please antitrust regulators -- nobody is saying they're elegant, so no point writing a "hater's" handbook to rebut the claim.