Xref: utzoo comp.arch:20677 alt.religion.computers:2366
Path: utzoo!utgpu!cs.utexas.edu!wuarchive!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.arch,alt.religion.computers
Subject: Re: Computers for users not programmers
Message-ID: <20752:Feb714:42:0891@kramden.acf.nyu.edu>
Date: 7 Feb 91 14:42:08 GMT
References: <409@bria> <13252@lanl.gov> <27A97D37.4346@tct.uucp>
Followup-To: alt.religion.computers
Organization: IR
Lines: 35

Followups to alt.religion.computers, as this stuff shouldn't be diluting
comp.arch.

In article <27A97D37.4346@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
> According to jlg@lanl.gov (Jim Giles):
> >... asynchronous I/O ...

Yes, Jim, UNIX in general does not have truly asynchronous I/O. Why not?
Because it simply doesn't matter on machines smaller than your Crays.
The worst overhead we get for I/O buffering on the fastest machine here
is 5-10%; it's negligible on anything smaller than a big Sun.

> >... automatic crash recovery ...
> >... error recovery ...

Checkpointing handles these problems. The main reason I wrote my poor
man's checkpointer (pmckpt, available via anonymous ftp to
128.122.128.22, new version appearing soon) was because I was so sick of
hearing you rave that UNIX can't checkpoint files. It can, and I wish
you would stop.

> >... reconnect ...
> These are *kernel* features, unrelated to the UNIX tool philosophy.
> (Though they can sometimes be emulated incompletely; Dan Berstein's
> pty tool allows reconnection after hangup.)

Actually, to give credit where credit is due, Steve Bellovin designed
the UNIX session manager, and pty's session management facilities are
only slightly more general. The session manager provides reconnection
facilities more powerful than in VMS or any other widely used operating
system. I disagree with Chip's statement that reconnect is a kernel
feature; the fact that it can be implemented at the user level is a
perfect example of the tool philosophy.

---Dan