chip@tct.uucp (Chip Salzenberg) (02/06/91)
[ Followups to alt.religion.computers; this isn't comp.arch fodder any more. ] According to jlg@lanl.gov (Jim Giles): >The people I'm talking have used _many_ different systems and have >switched many times. They _know_ what's involved in moving to a new >system. ... The conclusion is that UNIX does _not_ have sufficient >capability to offset those features it lacks. That conclusion would be meaningful if we knew to what purpose the UNIX computers were being used. UNIX is not right for all tasks. Those who claim so have something in common with those who claim the opposite: prejudice. >But, your point is quite accurate and explains why there's so much >resistence to change from UNIX users. I do not desire to defend UNIX users, any more than I desire to attack users of other systems. It is the UNIX system itself that I wish to defend against charges of being underpowered for serious use. UNIX is dated. But its tool-based approach has proved successful for me in my work. I cannot give any higher recommendation. If you did not have a similar experience, why bother trying to draw others away, when only their own experience will be persuasive? >... a lot of UNIX supporters have sent me examples of stuff >to "prove" how powerful UNIX is ... they all do something >trivial or useless ... An example may be trivial; but that does not necessarily imply that the thing being exemplified is trivial or inconsequential. Examples are, of necessity, limited in scope, since their purpose is not to accomplish a goal but to illustrate an approach. If the approach thus illustrated does not appeal to you, then make that point; but remember that it is nothing more or less than a matter of taste. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Most of my code is written by myself. That is why so little gets done." -- Herman "HLLs will never fly" Rubin
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/07/91)
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