Favorite operating systems query

[davidsen at steinmetz.UUCP]

In article <175 at esunix.UUCP> loosemor at esunix.UUCP (Sandra Loosemore) writes:
>I use both VMS and Un*x every day.  I do nearly all my program development
>under VMS, though, and I must admit that I like VMS a bit better.  There
>are a lot of operating systems that are a whole lot worse than Un*x though.
>(Fortunately, I don't have to use those every day....)
>
>I think the greatest advantage VMS offers over Un*x is the networked/shared
>file system.  VMS has had transparent network file access for at least 5
>years, and this is just now working its way into Un*x.  (They just installed
>this as a "local hack" on the machines at the University of Utah -- it is 
>by no means a standard feature yet.)  The VMS machines I use at work are
>clustered, so the file structure looks exactly the same no matter which
>machine I'm using.  Given the current trend towards distributed computing
>environments with personal workstations and compute servers, shared file
>systems are very important things for an operating system to support.

A cluster is a special case of a multiprocessor system in which the processors
are not allowed to share memory. I personally consider it an artifact of the
problems with the 782 which DID share memory. File sharing under VMS is about
as non-transparent as you can get! If I want a file on another machine, I type
	othermach::device:[many.sub.directories]file.typ
and to even access a file on another disk on the same machine I need an
explicit device name!

In UNIX, using NFS (public domain courtesy of Sun) or RFS (ATT) I can use a
path of the form:
	/dir/dir/dir/file
and I don't NEED to know if any level of the directory is on another drive or
even another machine far away (If it's too far for ethernet, I may guess. Page
faulting over a modem doesn't make it) connected by a logical link. NFS will
even allow me to mix UNIX and other operating systems, although I have heard
some things that make me feel there's room to improve that feature.
>
>Another thing I like about VMS is the documentation.  There is a great deal
>of tutorial information and examples in the manuals.  It seems like when
>I find I need to do something obscure with Un*x, I can never find the
>right command to do it (or the documentation is so terse that I'm never
>really sure whether it's the right command or not), and I end up having
>to ask a "wizard".  (Unix sites without "wizards" are really in trouble.)
>I also wish Un*x had on-line help on how to use the shell, instead of 
>just the utilities!

I agree that UN*X documentation is terse. I think we have the sh document on
line, although it isn't too good in 24 line chunks. The VMS online stuff is
too speciffic, as in after help <do something>, you often need to HELP SPECIFY
PERMISSIONS, HELP SPECIFY FILENAMES, and HELP SPECIFY otherstuf. Online help
frequently lacks examples.

The DEC internal manuals for things like internals, mapped sections, message
router, etc, are not BETTER than the UN*X manuals, just bigger and prettier.
>
>I don't think that either VMS or Un*x has serious problems with file system
>reliability; I've never lost a file under either OS.  File versions under
>VMS have saved me more times than I can remember, though.  Again, this is
>just another place where DEC has taken the trouble to try to "idiot-proof"
>things, and we users appreciate it.

The system manager often doesn't, though, since s/he has to purge the system
or run out of file space. The solution to this was to add disk quotas, and
make the user do the purge. If a user needs an editor which makes a backup of
a source file, fine. But to make multiple versons of the object and
executable? It's not obvious to the user how badly that eats up disk space.
>
>Of course, there are bad things about VMS too:  as others have pointed out, 
>processes are incredibly slow to start up, the mailer is not too great (but 
>neither is the Un*x mailer, for that matter), all of the DEC editors are 
>pretty awful (but so is "vi"), etc.  On the whole, though, Un*x is fine if
>you want an "open" operating system where you can tweak everything in sight,
>but if you just want to get a job done, VMS is a lot less hassle.

Actually mailx and Berkeley mail are acceptable user agents in my opinion, if
not perfect. Use of some sendmail program to handle domain addressing is
needed on any machine with complex connections. Editors are a matter of faith,
the only way to get what you want is write it. VMS has very little user help
for jobs which are trivial with pipes. It doesn't easily encourage
redirection, with "ASSIGN/USER SYS$OUTPUT filename" replacing >file. And don't
forget logical names... does this program write SYS$OUTPUT, C$OUTPUT, or
whatever.

I am not really getting into the VMS vs UNIX(tm) argument so much as pointing
out that your perceptions of the strong points of VMS are not universally
shared. Another time I'll post my list of good things in VMS for someone else
to shoot at.
-- 
	-bill davidsen

  ihnp4!seismo!rochester!steinmetz!--\
                                       \
                    unirot ------------->---> crdos1!davidsen
                          chinet ------/
         sixhub ---------------------/        (davidsen at ge-crd.ARPA)

"Stupidity, like virtue, is its own reward"