🚀 go-pugleaf

In article <61209@mimsy.umd.edu>, hoel@umiacs.umd.edu (Erik Hoel) writes:
|> I recently had a very heated discussion with a peer concerning the relative
|> strengths and weaknesses of VAXes and workstations, as well as VMS and UNIX.

|> each must offer various advantages relative to each other otherwise they
|> would have died off long ago.  My friend on the other hand was vehament in
|> his assertions that both workstations and unix were clearly superior...
|> 

Gads.

I'm going to consider myself qualified to comment on this; I started my career
as a VAX system manager just in time to watch Unix/RISC begin to take over the
world.  I manage VMS and Unix systems; I have CISC platforms downstairs in the
lab, and a RISC on my desk.

I've *never*  understood the mentality that dictates that any O.S. other than
somebody's pet favorite can't have *anything* good going for it.  I agree
with Erik.  Both Unix and VMS have their strengths and weaknesses. 

I think Unix is a nifty little beast.  I love the power that it gives a 
knowledgeable user at the command line, what with piping and redirection
and a bazillion little utilities for slicing and dicing information.  Its
programming and file system interface is nice and simple, which is its 
greatest strength and greatest weakness.  Security?  Enough holes to leave
anyone responsible for security quivering in the corner.

VMS, on the other hand simply has more features in the O.S.  Security is much
more robust.  Privileges are not an all-or-nothing affair.  The Filesystem
is nowhere near as limited -- file structures can be more complicated than
a stream of bytes with an EOF.  File and resource access can be controlled on
an individual user basis.  Ever try under Unix to give only Joe and Fred and
Mary access to a file?  Without creating a group and sticking them in it?
Remember a user can only be in 16 groups under Unix.  But programming VMS
is relatively complicated if you want to make use of the features.  The VMS
programming manual set has 9 or 10 binders.  The Unix programming manual
sets I have are 2 binders.  And DCL simply won't do some things as nicely
as one of the Unix shells.

VAXes got a bad name in the last several years because they didn't keep 
getting faster at the same pace as the RISC boxes.  That's DEC's fault.
VMS, I think, got a bad name because it's associated with VAXes.  Unix
got a good name because it was running on fast, sexy new RISC processors 
that people were plonking on their desktops.  (Unix Fast.  VMS Slow.  Ugh.
Unix good.  VMS Bad.)  Tried running on one of the newer 6000 or 4000 
series machines?  They perform quite well anymore.  DEC has made big, big
improvements with the VAX processors since the late 80's.  We'll see how
Alpha does for them.

IMHO, Unix is *not* as prolific as it is because it's the easiest to learn,
or the most suited for business environments, or somehow "the best" operating
system out there.  It's so prevalent becuase it was (Captain, sensors 
indicate flames approaching!) expedient.  Unix was designed from the get-go
to make very few assumptions about the platform it's running on, and the
source code was easily obtainable.  So in the mid-late eighties, it was easy
for the vendors to get a license from AT&T, a source tape from Berkeley,
munge a few thousand lines of C and/or assembly.  Poof!  Instant operating
system for your blazing new 15-mip RISC processor.

Also IMHO, RISC will not continue to dominate the processor field the way
it has.  As stuff like caching and superpipelining that started with RISC
works its way into CISC and other processor technology, the lines between
them will blur until they are meaningless.  Reducing the size of the 
instruction set was a cute trick that got MIPS up, and helped produce some
good new technologies, but a reduced instruction set will not continue to
be key to increasing performance.

My $0.02 worth.

------------
David Cowley, Unix/VMS System Manager, Pacific Northwest Laboratories
PO Box 999 MSIN K7-53	               Voice:	(509) 375-2260
Richland, WA 99352                     Internet: de_cowley@pnl.gov