Aucbvax.5935
fa.info-vax
utcsrgv!utzoo!decvax!ucbvax!info-vax
Sat Jan 23 18:17:30 1982
Interesting patch available, and a comment on UNIX/VMS
>From FONER@MIT-AI Sat Jan 23 18:12:07 1982
A couple of comments.  For those who don't own EMAC or VMS, read ahead
for a continuation of the UNIX vs VMS brouhaha.

For those of you who use Gosling's EMACS and are annoyed by the fact
that the VMS TTDRIVER assumes NOBROADCAST when PASSALL is in effect
(meaning that EMACS users, who must run in PASSALL, can't get SENDs
and other broadcast messages), I have a simple patch to TTDRIVER for
VMS 2.3 that eliminates this behavior.  Setting your terminal
NOBROADCAST explicitly still works, of course, but it won't get
implicitly set tht way when PASSALL is in effect.

I can download the patch to this machine and mail it to anyone in a
week if anyone is interested.  I can mail just the patch (and not how
it works, etc) immediately if somebody's in a rush.  I don't
guarantee, of course, that this patch will work for VMS 2.4, and you
should remove it before instaling 2.4.  Once we install our own 2.4,
I'll make a possibly revised patch available if anyone wants it.

The patch itself, interestingly enough, is a single bit.  The problem
is that \finding/ that bit took several hours of looking.

As for the merits of UNIX vs VMS, I don't really want to jump into
this with blowtorch at the ready.  I'll merely make some comments.
Note that I am a novice UNIX user and do system programming for VMS.

I tend to like VMS for several reasons.  It supports version numbers
for files, which makes sense, especially for commercial users.
Research users find that disk space is always at a premium, but
commercial user, who have more money generally, find that accidentally
losing an important file will pay for \many/ disks due to the increased
amount of file storage due to multiple versions of files sometimes
being around.  UNIX users, from my experience, tend to be more cramped
for disk space and thus find the lack of version numbers not a
particular disadvantage anyway---it helps cut down on space use.

VMS also supports a very good set of diagnostics.  As far as I know,
UNIX does not even try to log device errors in any convenient or
consistent way.  VMS keeps a record of any errors that a device
encounters and thus allows system managers and programmers to look at
the log for a device that is about to fail (memory or a magtape drive,
for instance).  This has proved invaluable at the sites I use, for
instance.  And has anyone ever heard of remote diagnostics for UNIX?
I certainly haven't, but most commercial sites to my knowledge have
remote diagnostics from DEC that can save a LOT of time in tracking
down problems...  the hardware guy can show up with what he needs most
of the time under this system and won't have to go back.

VMS also allows you to layer other software on top of it, if
necessary.  For instance, on our 11/750, we have EUNICE running on top
of VMS.  (We're also trying out true Berkeley UNIX for the next week
on that machine, also, to see if some of our software will run under
UNIX but not EUNICE and try to figure out some problems.)  I have
never heard, however, of anything like VMS being layered on top of
UNIX.

VMS is also very good for unsophisticated users.  A colleague of mine,
who is also a UNIX novice and is trying to figure out the fairly
inscrutable user documentation, has commented that one of the major
problems with UNIX is that you really tend to need a UNIX guru for the
first two or three days to steer you through the system---it's far too
easy to get thoroughly lost by yourself.  In this respect UNIX is very
much an expert system.  (Unfortunately for us, we don't have have a
local guru inhouse...  so we're learning our Berkeley UNIX on our own
unless we break down and call on the distributor.)

VMS, as well as giving very useful and verbose error messages (which
\are/ very useful), also gives me many feet of manuals to explain
itself.  I haven't noticed this from the UNIX folks (though apparently
Berkeley UNIX is better than most).

The ability to actually change the operating system is actually not
very important, at least at my sites.  The patch I mentioned above is
absolutely the FIRST time anyone here has needed to change the
operating system.  Almost everything you might want to can usually be
done without actually \changing/ anything...  you can just add more
code elsewhere.  This helps to make the system maintainable, since it
resembles almost every other VMS in the world and DEC can (and does)
update it for this reason.  This is despite the fact that we'reusing
some of our VMS systems for some damned strange applications and with
some very unusual hardware.

Also, I have heard from people who have taken the VMS Internals course
at DEC that the internal organization of VMS is very clean and very
well thought out.  I have heard just the opposite about UNIX (any
version) because it has grown by bits and pieces, mostly of the hack
variety.  This \must/ have something to do with the maintainability and
essential correctness of the system.

Please don't interpret this as unbridled enthusiasm for VMS.  There
are many things that it could do better.  I think many people on this
list have touched on the places that could do with improvement.
But here are also several areas that can be important to certain
classes of users that make it very useful to them, too.  Not needing a
system programmer on the payroll is one reason.  (We have a couple around
because we are constantly hanging strange hardware off the machines,
for one thing.)  Not needing a guided tour throught the first time is
another reason.  And being \supported/ by a manufacturer can be very
nice for reporting bugs and such, unlike many UNIX systems which are
essentially reliant on their local gurus (and whatever skills they may
or may not have) for fixing.  Not every site can afford to pay someone
who can deal with ALL possible bugs in the operating system.

Also, as this same colleague of mine has suggested, the fact that UNIX
is strongly used by university and research types means that hacks and
other useful information is easily propagated by lots and lots of
interaction between sites and conversations in the halls.  Commercial
users don't talk to each other as easily, because they're often doing
things that they may not want anyone else to know about.  Furthermore,
it's more obvious that it took MONEY to come up with whatever useful
software they may have, and thus that it's to their own competitive
advantage to retain that software and not proliferate it.  University
users have a very different perspective, almost an opposite one.

If I've stepped on toes, I'm sorry.  This is my opinion, biased by
systems programming in a VMS environment for a couple of years and
being fairly unfamiliar with UNIX (especially at the systems
programming level).  It's pretty certain that many people may disagree
with me---the ARPAnet is composed mostly of university computers, and
most university VAXen run UNIX rather than VMS.  If the net were
composed of mostly commercial users doing number crunching and
database handling, the bias of this discussion would be very
different.

                                               <LNF>

-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <[email protected]>
of http://communication.ucsd.edu/A-News/


This Usenet Oldnews Archive
article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.