new kids ask for help

[Laws at SRI-AI.ARPA]

From:  Ken Laws <Laws at SRI-AI.ARPA>

Welcome to the net.  It's good to have more AIers.

I assume that the discussion you refer to is the VMS vs. UNIX
vs. TOPS-20/TENEX melee on Human-Nets (now @RUTGERS) during
November of 1981.  It may also have been on Unix-Wizards; I
wasn't tuned in to them.

I have saved some pieces of the discussion, but they won't be
of much help to you.  The participants were comparing user
interfaces rather than system services and efficiency, and
there was no concensus on a winner.  You will find a few slams
against VMS (not all true, I might add) and almost an equal
number of messages defending VMS as an elegant system.  The
attacks against the Unix user interface were even more telling.
(I've saved a copy of Don Norman's lengthy treatise on the
unhuman engineering of Unix.)  Much of the debate centered
on whether command-name and argument completion are essential
in a modern operating system.

I have experience with both Unix and Eunice, and am currently
using Eunice on a sister system to the one at ETL.  I don't
have timing statistics handy, but the Eunice interface is not
noticeably slower than for a pure Unix system.  Sprouting
of processes (and executing associated initialization files)
is a little slow on either operating system, but other things
seem to happen instantaneously.  The overhead in converting
a Unix system call to a VMS system call is negligible.  Some
things, such as image I/O, happen much faster on a VMS/Eunice
system than on a Berkeley Unix system.

The Eunice user interface is the Unix interface, with very
few exceptions.  Two years ago Eunice went through a complete
rewrite (from VMS macros into C code) and very few bugs have
turned up since.  I may get a Eunice error message once in
three or four months, but essentially all problems have been fixed
in the code that I use to get my work done.  When bugs are
discovered, it is often because	of errors in the supplied
Unix code (e.g., dependence on the storage order of two scalars)
that happen to work on a Unix C compiler but fail on the VMS
C compiler; this really can't be blamed on Eunice.

You may also use the full VMS operating system interface wherever
it is more useful -- and you don't even have to switch out of your
Unix-style environment to use it.  Some people prefer the VMS dumper
to the tar command (which tends to be very sensitive to bit errors);
they can have it.  Others want a command to change files foo.* to bar.*;
VMS supplies it.  If you have programs that will only run under VMS,
Eunice lets you run them.

In addition, Eunice has some improvements over either Unix or VMS,
by virtue of having selected from the the best techniques of both.
Many users would like to have VMS/TWENEX-style multiple file versions
in a Unix-style environment, so Eunice makes that available via a
switch in your login file.  (I don't use this capability, but I seem
to be a minority of one here.)  Eunice also gives you the option of
circumventing Unix filename length restrictions.  A version of
EUNICE now under development emulates TWENEX operating system services
as well as those of Unix, so you can run TWENEX-style argument
completion, help facilities, and programs such as the MM mailer.

Well, in what way then is either Unix or VMS alone better than
a Eunice system?  Since I'm content, I may not be the right person
to ask.  I would say, though, that either system alone is bound to
be simpler than the combination; thus I wouldn't recommend Eunice
for sites with a continuing preponderance of novices.  Eunice is
also more difficult for the system manager and the system wizards
since they really do have to understand the dual nature of the
system.  Other users will typically stick with VMS commands or with
Unix commands and won't be aware of the split personality.  Only
very rarely are bits of VMS magic needed to do unimplemented Unix
functions, and those situations seem to be getting fewer all the
time.  I have been using Eunice for several years now and I don't
remember how to write a VMS DCL script -- I don't need to.

					-- Ken Laws
-------