Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!yale.edu!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.os.misc
Subject: Re: UNIX vs. the world (again) (was: Compilation listing from Sun ...)
Message-ID: <26086@lanl.gov>
Date: 20 Jun 91 17:17:36 GMT
References: <1991Jun15.143436.5574@cunixf.cc.columbia.edu> <25791@lanl.gov> <RI0CQT5@xds13.ferranti.com>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 66

In article <RI0CQT5@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes:
|> [...]
|> The basic design of the *interface* that is the real core of UNIX is realy
|> quite good. [...]

To be sure, the system interface is much better than the shell/tools 
level of the system (I regard _both_ levels as part of the system
because _both_ are meant by most UNIX supporters).  But, there are
_obvious_ deficiencies:

  No way to bypass the system's I/O buffers - even though sophisticated
     users often need to do so for efficiency. This also makes real-time
     programming a bitch.

  No asynchronous I/O.  Though this is a common _extension_ to UNIX,
     no two extensions do this the same way.  And the most common UNIXes
     don't allow it at all.

  The lseek() call is a separate system call.  So, programs doing random
     I/O must spen roughly twice the system overhead by making _two_
     system calls for each I/O request.  (The seek address should be
     an optional argument to the read/write system calls.)

  Signals are not stacked.  That is, if more than one of the same signal
     arrives before the program has a chance to handle one, the program
     will only recieve _one_.

  Most security people I know regard the very _concept_ of SUID to be
     inherently insecure.  Apparently, any new SUID program added to a
     system will invalidate a B-level security rating until you're
     recertified with the new SUID program in place.

  Etc..  The list is _long_.

|> [...]
|> I don't know of any other system on micros that provides usable multiuser
|> support.  [...]

I _still_ don't.  The idea of more than one user on a microprocessor
version of UNIX is ludicrous - and irrelevant to this discussion.
If you're comparing single-user systems, UNIX loses because it's got
so much system overhead and allows so little user freedom (ie. the 
system does lots of scheduling abd other decisions that a single-user
system should let the user have some control over).  If you're talking
multi-user systems, UNIX is just not as good as several of the other
mainframe systems available - including some with UNIX look-alike 
kernel interfaces (which, thankfully, can be bypassed on such systems
to get at some _real_ power).

|> [...]
|> Yes, your DOS PC doesn't require as much support, so long as you just leave
|> it in isolation. But then it doesn't do much.

Depends on what you mean by "doesn't do much".  It does _more_ as a
single-user system.  There are (I'm told - I've never seen them) tools
available on UNIX to do text manipulation and other things as well as
my DOS system at home does them.  They are all expensive, second-source
tools.  Most of them are actually transplants _from_ DOS or Apple/MACs.
The same software is cheaper for the DOS machines and does the same job.

For real horsepower, I might use my Sun (except that I have Crays at
my disposal).  But, for this kind of application, UNIX is more a burden
than a blessing.  I want to get around it more often than use the "tools"
I'm intended to use.

J. Giles