Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site elsie.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!hplabs!hao!seismo!rlgvax!cvl!elsie!mark
From: mark@elsie.UUCP
Newsgroups: net.unix
Subject: Re: How do Unix and VMS compare?
Message-ID: <981@elsie.UUCP>
Date: Thu, 28-Jun-84 09:07:12 EDT
Article-I.D.: elsie.981
Posted: Thu Jun 28 09:07:12 1984
Date-Received: Mon, 2-Jul-84 00:14:49 EDT
References: <1000@sri-arpa.UUCP>
Organization: NIH-LEC, Bethesda, MD
Lines: 91

<>
David Chase (followed by others) have been involved in UNIX (AT&T Bell Labs 
Trademark) vs DEC's VMS OS (DEC Trademark). I'll try not to go over old
ground (bless you, 'e' option), but there are a few points I would like to make.

>	When the next minor version of VMS comes out, your programs will
>still run.  When the next major version of VMS comes out, your programs
>will still run.  We are still running (under 3.6) programs that were
>linked under 2.5, and these programs are linked against a user-written
>library full of change-mode vectors.  Of course, the library is installed
>as a shareable image, so it has been changed many times.
...
>	A stinking minor version change breaks the whole world.  Already
>there are two different Unixes.

I.e., VMS is backward compatible. This means that every design glitch in the
original version of VSM must be carried forward forever, or until DEC
decides to no longer support VMS. This also means that if you get sloppy and
lose your source code VMS will cover for you until the stray gamma ray comes
along and zapps you. This also means that if new idea comes along (e.g. a
new filing system, or object code format) you may not be able to install it
unless backward compatibility can be maintained. Eventually things become
set in concrete and you're left with an obsolete dinosaur.
	I maintain that losing source or bit tiddeling object code (so you
have no source) is a major programming sin. One should recompile ones programs
regularly (at least those installed system wide) to be sure they still
compile and run. If, every few years, a new version of the OS comes out
that requires recompiling or relinking of all code, and *THAT RESULTS IN A
MAJOR IMPROVEMENT IN SYSTEM PREFORMANCE*, then I for one am willing to spend
the few hours of compile time and the few weeks of system shakedown to bring
the new system up. Of course then, we're not a bank.

>	Unix encourages C, and that is bad.  C is just assembly language
>with pretensions.

This is the only truly ridiculous statement in Mr. Chase's entire article.
Yes, C is a glorified assembler. A device independent assembler. And, I
believe, most compilers, at some point, produce assembly code before
churning out machine code. C is also highly portable, concise, and powerful.
It ain't perfect, to be sure, but it's better than most.

>	If I miss a keystroke, I type "rm *>CKP".  This is very bad.

Amen. But isn't it possible to miss a key stroke and do something very bad
in VMS also. Surely some new user must have figured out a way by now :-)

Now, M. Kenig writes:

>If Unix had more machine specific code, it would be more difficult to port.
>Unix "can be moved across machines with architectures and capabilities" 
>easily because it seems the people who move it CHOSE TO IGNORE THE UNIQUE
>CAPABILITIES and ARCHITECTURES OF THOSE MACHINES. Case in point: the VAX.
>Ignore the FPA and the Virtual memory and what have you got?  Right, a 
>PDP-11/40.  Whoopee! It's even more cruel to do this to a larger machine
>like a Cray.  Says Unix-porter, "Nothing easier if we ignore the vectorizing."
>Giving the power of an 11/70 to an IBM-PC is a noble thing, giving it to a
>VAX reminds me of a Ben Franklin quote:  "Calling a steer a 'bull' is a
>compliment; he's grateful for the compliment, but he'd rather have restored
>what's rightfully his".

Bunk. There are good ports and bad ports. A new machine will usually come up
with the minimum possible UNIX. Remember U/32? With time the OS for that
system will improve. This is true of all (most?) OS's. Look at 4.2 bsd;
compare 2.0 VMS with the latest version. With C you can take advantage
of machine architectures and maintain portability with the use of #ifdefs.
I.e.:
	#ifdef VAX
	...vax assembler here via the asm() mechanism; e.g. mov3()
	#else
	...portable C code here..
	#endif

But, a system intimately tied to VMS, or any other proprietory OS, will be
forced to run only on DEC machines running VMS. That is, after all, on of
the reasons they give you VMS when you buy a VAX. They want to make sure
your next computer will also be a VAX (or something compatible). That's just
good business, and that's also one reason DEC used to fight you when you
tried to bring UNIX up on one of their machines (that was back in the dark
ages and is certainly no longer true).

>All opinions and statements expressed herein are solely mine, and in
>no way may be construed as reflecting the official or unofficial
>opinions or attitudes of either my contractee, or my employer.

Ditto.

-- 
Mark J. Miller
NIH/NCI/DCE/LEC
UUCP:	decvax!harpo!seismo!umcp-cs!elsie!mark
Phone:	(301) 496-5688