Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 exptools 1/6/84; site ihuxx.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!ihuxx!ignatz
From: ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL)
Newsgroups: net.unix
Subject: Re: How do Unix and VMS compare?
Message-ID: <780@ihuxx.UUCP>
Date: Fri, 22-Jun-84 16:06:03 EDT
Article-I.D.: ihuxx.780
Posted: Fri Jun 22 16:06:03 1984
Date-Received: Wed, 27-Jun-84 08:27:27 EDT
References: <1000@sri-arpa.UUCP>
Organization: AT&T Bell Labs, Naperville, IL
Lines: 84

I'm sorry to add to the verbiage, but there are a couple of items
which Dave has obviously misunderstood in his defense of VMS over
UNIX, and that I think are quite important to keep in mind in this
burgeoning Unix milieu.

>VMS tends to get more performance out of its hardware, through
>clustering, asynchronous IO, and good paging.  These things can be tuned
>for a particular installation, though they can also be mistuned.

This is quite true.  What you're missing is the very important fact
that everyone involved in development of standard Unix is quite aware
that, if they wrote machine-specific code, they could usually get gobs
of performance improvements on their machine.  And only on it.  Unix
can be moved across machines with architectures and capabilities as
widely differing as an IBM-PC, a VAX 11/780, and a Univax 1180.  True,
porting to a new machine is not something you give to a summer
employee; but just try to "port", say, Univax Exec 32 to a Sun
workstation.  The premise under which people have been willing to get
less horsepower from their hardware has been Xfold:  First, hardware
is getting steadily more powerful for less money; this trend is
certain to continue.  Secondly, they now have a common environment
for their internal development, no matter what mix of machines they have,
for new employees--all those Unix-trained college graduates coming
out--and for products which simply require a "Unix environment".
All of these concerns outweigh eking a few more kips from your tired
old CPU.

>If I write something under VMS, and decide I maybe want to sell it
>or give it away, I don't have a dozen lawyers breathing down my neck.

No one else does, either, as long as you don't carelessly include
proprietary programs in your application. (Note that this does not
affect inclusion of object libraries)  I really don't see how this
applies in this instance.

>A stinking minor version change breaks the whole world.  Already
>there are two different Unixes.

What do you mean already?  There are more than two Unixes, friend, and
this can directly be traced to Berkeley's door.  I won't say they were
totally wrong to modify v32 so heavily, and encourage its proliferation,
since BTL didn't/couldn't do so with their Unix; but it certainly
didn't help. Unix is *not* a mature OS.  The final form of the kernel
won't be solidified for some time, despite what they say about System
5 R2.  Minor changes don't break the world; major ones do.  Before you
tout VMS's stability, go back to the time IT was only about 5 years
out the door, and see what it's history was like, even with a single
source.

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

This is the most incredible statement I've ever seen.  OF COURSE 'C'
is just an assembly language replacement.  A PORTABLE assembly
language replacement.  For at least the 12 years I've been in the
field, I've heard various prophets harking their various high-level
languages, and finally announcing the death of assembly language.  It
hasn't happened yet, and won't happen, for there ARE cases where you
need tight, efficient code.  Yet, using 'C', it IS possible to do
almost all of those horrible jobs that formerly required
assembler--drivers, interrupt handlers, etc.--and do it with a
portable language that gives an efficiency close enough to the native
assembler that many are willing to accept the penalty for--you guessed
it--the portability.  Use some high-level language when you need the
power it provides; use 'C' in lieu of assembler when you need tight,
fast code.  C will be around long after Unix is used as an obsolete
example in beginning CS courses.

There were several other items to which I took exception--for
instance, criticism of individual commands, or bugginess of
commands--which should, rightly, be compared to both command and OS
bugs on VMS combined, since so much of a "traditional" OS has been
moved from the kernel to external commands in Unix.  But in general, I
want to emphasize that Unix is immature, and has growing pains.  But
the quite different concepts embodied in Unix make comparing it with mature,
traditional OS's a task that should be undertaken with more care than,
say, comparint PR1MOS IV with VMS...

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.

				Dave Ihnat
				ihuxx!ignatz