Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!husc6!harvard!panda!genrad!decvax!decwrl!pyramid!hplabs!hp-sdd!ncr-sd!ncrcae!ncsu!uvacs!edison!steinmetz!davidsen From: davidsen@steinmetz.UUCP Newsgroups: net.decus,net.unix,net.usenix Subject: Re: Favorite operating systems query Message-ID: <828@steinmetz.UUCP> Date: Tue, 8-Jul-86 13:46:43 EDT Article-I.D.: steinmet.828 Posted: Tue Jul 8 13:46:43 1986 Date-Received: Sat, 12-Jul-86 06:16:18 EDT References: <339@valid.UUCP> <175@esunix.UUCP> Reply-To: davidsen@kbsvax.UUCP (Davidsen) Organization: GE CRD, Schenectady, NY Lines: 93 Xref: utcs net.decus:406 net.unix:8548 net.usenix:650 In article <175@esunix.UUCP> loosemor@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 , 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@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"