Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!seismo!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.unix Subject: Re: Favorite operating systems query Message-ID: <2041@umcp-cs.UUCP> Date: Tue, 17-Jun-86 00:47:11 EDT Article-I.D.: umcp-cs.2041 Posted: Tue Jun 17 00:47:11 1986 Date-Received: Wed, 18-Jun-86 04:43:46 EDT References: <339@valid.UUCP> <452@geowhiz.UUCP> Distribution: net Organization: Computer Sci. Dept, U of Maryland, College Park, MD Lines: 68 [I deleted net.decus and net.usenix from the Newsgroups: header; both seem rather irrelevant here.] In article <452@geowhiz.UUCP>, larry@geowhiz.UUCP (Larry McVoy) writes: >I think that the main complaints with Unix from VMSites are > >1) the BSD fortran compiler is the worst excuse for a compiler the world has > ever seen (reports of 4 to 400 times slower than VMS fortran). `Fixed in 4.3'...? Well, not quite. Many of the performance problems and most (I may never again dare to say `all') of the bugs have been removed. For the hard-core VMS FORTRAN fan, there is the Ultrix port of VMS FORTRAN, about which I know nothing. In particular, many of the math library routines now use more of that beloved hand-tuned Vax assembly code. >5) Real time support. This is a valid criticism. To do VMS real-time code, one writes a driver and installs it with system privileges; the driver then has direct access to the hardware---or rather, that is my understanding of the process. It is a task of approximately the same complexity as writing and installing a Unix kernel driver, but one need not reboot, and driver bugs are less likely to cause catastrophe, as the VMS driver is somewhat insulated from the rest of the system. In other words, it is somewhat safer to trust anyone with random kernel-level hacking on VMS than it is on Unix. Somewhat. . . . >6) File system. Why, oh, why, must the Unix file system be so fragile? VMS > never loses your files. And it's faster to boot up. Except through my own stupidity or catastrophic hardware failure (head crashes and RA81 HDA glue problems), I have not lost a file for five years. Fragile? For that matter, most of our 785 boots take about six minutes: about three and a half for the console to load the WCS and the boot loader, and another two and a half before the terminals come awake and print `login: '. After a crash, a file system analysis and repair (as VMS puts it) takes perhaps an extra 25 minutes. (It used to be 15, until we turned an Eagle into an RA81 [the Eagle was needed by a Sun file server]). These crashes are usually due to power failures or other hardware problems. >7) IPC. This is indeed a serious problem, and one that I think (as does the CMU group, obviously) really requires a complete tear-out-the- guts-and-start-over approach. Along the way it will be helpful to simplify things, as is being done in Mach. >8) Robustness. VMS almost *never* crashes. Unix crashes all the time. It does? (I would run a `ruptime', but we had a power failure today that brought down everything in the building. Poor gyre also has an Emulex SC41/MS board with a bug that crashes it about every other day; I may kludge the driver to avoid it, if I can figure out how. It is somewhat difficult to write drivers without documentation.) (All right, 4.2BSD was quite buggy. I heard a rumour that there was a clause attached to the DoD funding that said that Berkeley had to ship 4.2 by some particular date. So, on that date, it was `grab a snapshot of whatever is there and ship': certainly not good practise, but money does help keep CSRGs going.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu