Favorite operating systems query

[Chris Torek]

[I deleted net.decus and net.usenix from the Newsgroups: header; both
seem rather irrelevant here.]

In article <452 at geowhiz.UUCP>, larry at geowhiz.UUCP (Larry McVoy) writes:
>I think that the main complaints with Unix from VMSites are
>
>1) the BSD fortran compiler is the worst excuse for a compiler the world has 
>   ever seen (reports of 4 to 400 times slower than VMS fortran).

`Fixed in 4.3'...?  Well, not quite.  Many of the performance
problems and most (I may never again dare to say `all') of the bugs
have been removed.  For the hard-core VMS FORTRAN fan, there is
the Ultrix port of VMS FORTRAN, about which I know nothing.  In
particular, many of the math library routines now use more of that
beloved hand-tuned Vax assembly code.

>5) Real time support.

This is a valid criticism.  To do VMS real-time code, one writes
a driver and installs it with system privileges; the driver then
has direct access to the hardware---or rather, that is my understanding
of the process.  It is a task of approximately the same complexity
as writing and installing a Unix kernel driver, but one need not
reboot, and driver bugs are less likely to cause catastrophe, as
the VMS driver is somewhat insulated from the rest of the system.

In other words, it is somewhat safer to trust anyone with random
kernel-level hacking on VMS than it is on Unix.  Somewhat. . . .

>6) File system.  Why, oh, why, must the Unix file system be so fragile?  VMS
>   never loses your files.  And it's faster to boot up.

Except through my own stupidity or catastrophic hardware failure
(head crashes and RA81 HDA glue problems), I have not lost a file
for five years.  Fragile?  For that matter, most of our 785 boots
take about six minutes:  about three and a half for the console to
load the WCS and the boot loader, and another two and a half before
the terminals come awake and print `login: '.  After a crash, a
file system analysis and repair (as VMS puts it) takes perhaps an
extra 25 minutes.  (It used to be 15, until we turned an Eagle into
an RA81 [the Eagle was needed by a Sun file server]).  These crashes
are usually due to power failures or other hardware problems.

>7) IPC.

This is indeed a serious problem, and one that I think (as does
the CMU group, obviously) really requires a complete tear-out-the-
guts-and-start-over approach.  Along the way it will be helpful to
simplify things, as is being done in Mach.

>8) Robustness.  VMS almost *never* crashes.  Unix crashes all the time.

It does?  (I would run a `ruptime', but we had a power failure
today that brought down everything in the building.  Poor gyre also
has an Emulex SC41/MS board with a bug that crashes it about every
other day; I may kludge the driver to avoid it, if I can figure
out how.  It is somewhat difficult to write drivers without
documentation.)

(All right, 4.2BSD was quite buggy.  I heard a rumour that there
was a clause attached to the DoD funding that said that Berkeley
had to ship 4.2 by some particular date.  So, on that date, it was
`grab a snapshot of whatever is there and ship': certainly not good
practise, but money does help keep CSRGs going.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu