Mishkin@YALE.ARPA (01/10/84)
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
From: Vaughan Pratt <pratt@navajo>
Subject: Mishkin on Unix
I thought Henry Spencer's comeback to Nat Mishkin's latest round
of criticisms of Unix [V4#2] very a propos: Unix is ubiquitous,
standard, and good. I would add a fourth quality: Unix is
adaptable.
The longterm experience with Unix has been that it is possible
for Unix to adapt to new technology. This has been demonstrated
for >16-bit addressing, virtual memory, interactive graphics,
laser printers, networking, and distributed file systems, to name
a few items. The adaptation of Unix to most of these technologies
has been a nontrivial effort, and in some cases, notably DFS,
an ongoing effort that has resisted smooth exporting. However
Unix has demonstrated beyond all question that it is not a static
system, with respect to either porting to other machines (the
source of its ubiquity) or its adaptability to new technology.
I think portability and extensibility are being confused here. I
will grant you that Unix has proven to be very portable. But that
could simply be a result of it's simplicity. I'm not trying to argue
that Unix is not simple. I would argue that that very few interesting
extensions have been made to Unix. The virtual memory case seems
to have been how little can we do to take minimal advantage of virtual
memory hardware support. Unix doesn't support any interesting or
useful virtual memory managment tools (unless the 4.2 mapping calls
made it in -- my understanding is that they didn't). I don't know
about interactive graphics, but I don't see anything terribly
Unix-specific there. As for laser printers -- the Unix software we
got to drive our Imagen Imprint-10 is certainly nothing to write home
about (part of it was simply hashed "lpd" code which only reminds
me about the lack of files locking primitive -- yes, I know, 4.2 finally
is supposed to solve this); and the software in addition to the actual
spooling software (e.g. DVI -> Impress converter) isn't very
Unix-specific. The 4.2 networking support is perhaps the good example
of extension -- but it seems to me like it's the first major one.
Only time will tell whether it manages to break the pattern of Unix
half-solutions to problems. Unix DFS's are still too early to judge.
From: Mike Caplinger <mike@rice>
Subject: Re: Unix & Workstations
One major advantage to running 4.2 Unix on our Suns is that we
are then compatible with all the software we develop on our VAX
systems. This is a terribly important consideration if you want
to easily develop a network composed of different machines, and
yet have it appear homogeneous to the user. As more manufacturers
announce "4.2 Unix" for their new machines, this will only get
more important. (One can only hope that they will be compatible
with each other. So far, SMI and Berkeley are.)
Good criticism #1. To some extent I think the incompatibilities can
be overcome. The question came up before: exactly what degree of
compatibility does one need and to what extend are non-Unix emulations
going to be significantly poorer than supposedly "standard" Unix's
produced by different manufacturers?
I'm sure that Aegis and other new operating systems approach
networks and workstations more elegently that Unix does, but as
a proprietary system it seems unlikely that Aegis will run on
anything but Apollo machines. If that's all you have, fine, but
many are not in that position.
Good criticism #2. Buying Apollo does raise this risk. However,
there is an upside: centralized, organized, consistent development.
If you believe that the company of which you are a "captive" has a
good engineering staff and is committed to quality software, you get
the benefit that sane system development can occur. It's not clear
to me what and who the driving forces in the Unix world are going
to be. In using Unix I have many times been frustrated by the
phenomenon that many things that one would rightly expect to be part
of the exported, released, documented environment (e.g. filename
wildcard expansion routines; string routines to convert a string to
upper case) aren't there. And what's worse, in the name of portability,
people include these routines and packages as part of a particular
program rather than developing a general library because if they did
develop such a library they would (heaven forbid) have to distribute
that library when they distribute the program (BBN is the only exception
to this pattern that I have seen). With centralized AND responsive
control from a single manufacturer, order and consistency can be made
of the various ideas and packages. The ideas and packages can be
smoothed and polished and documented and become part of a real release
procedure.
From: Tague%pco@CISL-SERVICE-MULTICS.ARPA
Subject: Unix & Workstations
I agree with Randy Saunders' remarks about the Unix system and its
becoming a standard. Unix is not a bad operating system. Perhaps
its most remarkable feature is that there are so many other systems
that are much worse. I guess since the chance of getting a system
worse than Unix is still pretty high, to say that one has Unix is to
say that one meets a certain minimum standard.
I hate to sound idealistic, but I thought we (that's you and me --
the computing professionals) had some say in what becomes a standard.
Sure, real world software is sometimes driven by things other than
"quality" as determined by the "elite" of the profession. But let's
not act as if we had no say in how the world turns out.
-- Nat