VMS & UNIX comparison rebutal (not as long as it looks)

[Dave Ihnat, Chicago, IL]

Marc Kenig has submitted a rebuttal to my comments on this topic,
which I think points out that I must not have given clear or concise
reasons behind my statements; so I guess I'll waste some bytes one
last time, and try to be a little clearer:

>>...which Dave has obviously misunderstood in his defense of VMS over
>>UNIX, and that I think are quite important to keep in mind........

>"VMS OVER Unix", I'm sorry, but I thought it was a comparison.
>Why are Unix bigots always so damned defensive?

Sorry, but please reread the article.  By the time it's done, it definitely
degenerated into the old argument of "OS X offers this, OS Y that."
Those few instances where Unix was favorably mentioned weren't even
centered on the kernel itself, but rather utilities.  As to Unix
bigot, pardonnez moi; I've worked on OS's from S370, and Exec 8
through Multics, GCOS 6, PR1MOS IV, and lowly CP/M and MS/DOS.
There are things on various of those systems I miss sorely, such as
asynchronous I/O requests.  I've worked on custom R/T systems, and
miss features offered in that environment.  It just so happens that
I've been working mostly in the UNIX environment for the last few
years, and can answer criticisms on the same.  I've therefore worked
on operating systems ranging from the "big boys", in both batch
and timeshare environments, to the smallest of dedicated systems that
were little more than round-robin schedulers with todo-lists.  In
addition, operating systems happen to be a topic of interest with me,
such that I do make an effort to be current in work in the field.
Please, before making such statements as "Unix bigot", perhaps you
could find out where I'm coming from.  I don't like perjoratives.

>>>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.

>>......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.,

>Oh my.  I seem to have heard all this before.  Let me rephrase the first point:
>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".

>YOU explain to your average MBA type why all the complaints about performance
>on the machine HE approved. See how much OS theory he understands. 

Sorry, but you've heard it all before, and will hear it all
again.  That's the basis of the Unix problem.  VANILLA Unix is
"portable".  By allowing such, you are not tied to your IBM (or DEC,
or Plexus) family of computers when it's time to step up; but since you
don't know what machine your headed for, you can't use its nifty
<whatever>.  In point of fact, any good "Unix porter" will first
get a 'vanilla' system running, then take advantage of specific
advantages of the machine in a modular manner.  What's that?  Just keep
the machine-specific whistles'n'bells localized and well-documented
both in function and effect on data structures.  But this will only go
so far--for instance, embedded assembler statements in common routines
to make use of a particularly snazzy instruction on your machine is in
poor form, even though it speeds execution.  Capiche?

As for the MBA, if he (or she, of course) approved the machine without
getting opinions from at least two or three different  'tech types' who DO
understand OS theory, then he didn't get an MBA diploma, he got
extremely coarse toilet paper.  HIS job was to juggle the different
opinions of the 'experts' to extract just exactly what he really wanted
in a machine, and was this machine going to do it.

>>C will be around long after Unix is used as an obsolete example
>>in...CS courses

>Sounds like prophesies of PASCAL from circa 1975, ALGOL 68 from 1969, etc.
>See how right they were.....If your right, I'll learn Japanese.

Get studyin', it's a fun language.  This is a different type of prophesy.
It's already got roots in fact.  There have been far more 'languages
of the future' than PASCAL--remember them all?  PL/1? ALGOL-60?
ALGOL-68?  Bloody APL?  And how about threaded languages like FORTH.
In all cases, the important first step was to see such languages
embraced extensively outside the academic community, either by the
research community, or by industry, or both.  This never happened to any
great extent with any of the above, for a number of reasons.  'C',
however, has not only been seized upon by countless educational
institutions--thereby guaranteeing a crop of graduates who already know the
language--but also many industrial concerns have already embraced it
as an acceptable compromise between the speed and efficiency of assembler and
the portability of a higher-level language.  THIS is why this prophecy
is different than the others, wakarimasu-ka?

>>...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.
 
>A quick look on SYS$SYSTEM: will obviate[sic] the same is the case for VMS.
>Commands on VMS are also (and always have been) external to the kernal....

I'm not just talking about commands.  I'm talking about all the stuff
that has been carried in more traditional operating systems, such as
code to format the contents of the system clock, or to interpret
N-thousand types of file records.  Specifically, code that is not
uniquely and totally involved with administration of critical and/or
sharable system resources does NOT belong in the Unix kernel.  (For my
tastes, they went too far in many cases in vanilla Unix--there should, for
instance, be some way to describe a generic record for a file without
having to know the record's structure, in order to allow reasonable
record locking for database applications.  Not to mention user buffer
purging, and device allocation, and...)  Many of the functions
provided in the kernel code of other OS's has been moved to the routines
described in section 3 of the Unix Programmer's Manual.  And many of
the user-level commands are simple these calls with a user interface
grafted on.  I won't say the right things were always moved from the
kernel; but I will say this is a reasonable approach to getting the
critical kernel code down to something that can reasonably be
understood and bulletproofed.

>>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...

>*foof, sputter, buzz*  Excuse me, but Unix is OLDER than VMS. If you want 
>Try comparing UNIX to true siblings, say TOPS-20 or RSX, for a revelation.
>WHEN IS UNIX GOING TO GROW UP?

I maintain that VMS comes from a tradition of OS design that is far
older and more 'developed' than the basic precepts of Unix; and in
that manner, is 'older' than Unix.  The two systems are trying to
accomplish a similar task, but with very different goals and priorities;
and Unix started from scratch in many ways.  Unix couldn't grow up until its
owner could see some reason to listen to the outside world and
incorporate the requests coming from it.  Until that happened, as long
as it was good enough for internal use, if it was useful to others,
well, that's nice.  With AT&T's emergence as a true competitor in the
market place, I've already seen an entirely different thrust to their
Unix development efforts.  And as they get more familiar with this new
environment, I expect Unix to grow up in short order.  (I just hope it
doesn't become a juvenile delinquent...)

I hope I've explained some of my expressed opinions to your
satisfaction; but I think this is enough verbiage for the net at
large.  I welcome private mail concerning this issue; and if/when we
come up with items of general import or interest, we can digest and
submit to the net.  I'm sorry if this sounds too much like a 'defense'
of Unix; but the original article has led me to somewhat take the role of
'Advocatus Diaboli'.  Oh, well...

As always, 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