Xref: utzoo comp.sys.amiga:74430 alt.religion.computers:2224 Path: utzoo!utgpu!cs.utexas.edu!know!sdd.hp.com!news.cs.indiana.edu!caen!math.lsa.umich.edu!sharkey!msuinfo!rang From: rang@cs.wisc.edu (Anton Rang) Newsgroups: comp.sys.amiga,alt.religion.computers Subject: Re: A3000UX competition Message-ID: Date: 14 Dec 90 17:37:55 GMT References: <86470@tut.cis.ohio-state.edu> <12003@hubcap.clemson.edu> <36449@cup.portal.com> <1990Dec2.153612.28555@zorch.SF-Bay.ORG> <36488@cup.portal.com> <1990Dec11.164431.819@jarvis.csri.toronto.edu> <16482@cbmvax.commodore.com> bzs@world.std.com (Barry Shein) writes: >From: martin@cbmvax.commodore.com (Martin Hunt) >>I agree with you that source code is a really great thing for those of >>us who are capable of modifying it. In an academic or engineering >>environment, it is a necessity. What I really dislike is people who >>design operating systems so poorly that simple reconfigurations >>require modifying the sources and recompiling the kernel. OS kernels >>should be like color TVs; there are no user-servicable parts inside. >> >>VMS does this fairly well... > >WHAT? I feel it does, having helped to manage a VMS system for several years, managed several UNIX systems, and written a number of system applications under both VMS and UNIX. (I also threw together a VMS device driver, but haven't done that under UNIX yet....) >How about those zillion OS tuning parameters in VMS? They're the knobs on the back of your TV set, I suppose. Sure, you can live without a tint knob, if the factory adjusted it more-or-less right. But sometimes you want to be able to change it. Hopefully, the default settings will be close to what you need; in operating systems, it really depends on your load. >More importantly, how come Unix has been able to live w/o them all >these years (just as another data point, so have IBM mainframe OS's.) Uhh, UNIX actually does have quite a few of them, they're just hidden in different places. Getting reasonable performance out of a Sun or DECstation without 16MB of memory requires poking around with desfree and the other memory management parameters. The param.c file (or your local equivalent) often requires tuning for your site (how many processes do you want? how much shared memory?). What's the difference? VMS has more, yes, but you can basically ignore them and usually still get reasonable performance, just as you can leave UNIX's desfree/lotsfree/... alone and get (usually) reasonable performance. The main difference I see here between VMS and BSD UNIX is that VMS has fewer parameters hardcoded (like the ones in the BSD process management code, commented with 'this is a magic number, you probably don't want to change it'). Lots of UNIXes have these tunable now, too. >Oh, and let's let mere mortals muck with system logical names under >VMS and see what you end up with... What does this have to do with the points above? I mean, presumably it does, but.... I wouldn't want to give 'mere mortals' write access to /vmunix's parameters on a BSD box, either. Seriously, and to try to avoid a *major* flame war (minor ones are fun and often informative), there are things about VMS's system design I'd like to see in UNIX. * System parameters should be documented and tunable. VMS gets this partly right--they document them, just often very obscurely, and they're usually tunable. I don't want to see a magic number in the code like "use a 10ms quantum because it works right on our PDP-11/07" which are likely to give less-than-optimal performance on a 30MHz 68030 machine. I think newer UNIXes are moving in this direction. * Device drivers should be easy to install into the system. AIX gets this right, according to hearsay at least. Being able to install them dynamically is good if availability is important. * At least some of the interfaces to kernel routines should be documented, so that local kernel changes are less likely to break when you do an upgrade. There are other things I'd like to see in both. * The ability to have a foreign file system installed easily. VMS can do this in theory (you write an ACP process to interpret the file system commands) but I've never seen anyone do one, and it would be a lot of work. The Apple //gs, Macintosh, and Amiga all have this. Does SVR4? (They support both SysV and BSD, at least.) I think that Mach is a good step in this direction (not just for file systems, but for VM etc. as well.) * A larger set of system management tools. 'ps' and 'ac' on the UNIX side don't do much for me. 'MONITOR' on the VMS side, and 'iostat/vmstat/pstat' on the UNIX side, let you see potential problems, but the fixes are often obscure. Performance tuning on both UNIX and VMS is a black art. Oh well. I'm curious about whether UNIX is evolving much any more, actually. VMS is changing incrementally (data file recovery is an optional product now, for instance, and access control lists are a relatively recent [ca. 1985?] addition). UNIX seems to be doing the same; neither one has many innovations in commercial versions, at least. Maybe that's not a bad thing. Or maybe it is. Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+