cbspt002@abnjh.UUCP (Marc E. Kenig ) (06/25/84)
<(*RSET NIL)> I hate articles like this, and am sure that the original author can rebut as well as I, but I'd like to jump into the argument anyway. ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) writes: >...which Dave has obviously misunderstood in his defense of VMS over >UNIX, and that I think are quite important to keep in mind........ "VMS OVER Unix", I'm sorry, but I thought it was a comparison. Why are Unix bigots always so damned defensive? >>VMS tends to get more performance out of its hardware, through >>clustering, asynchronous IO, and good paging. These things can be tuned >>for a particular installation, though they can also be mistuned. >......if they wrote machine-specific code, they could usually get gobs >of performance improvements on their machine. And only on it. Unix >can be moved across machines with architectures and capabilities as >widely differing as an IBM-PC, a VAX 11/780, and a Univax 1180., Oh my. I seem to have heard all this before. Let me rephrase the first point: If Unix had more machine specific code, it would be more difficult to port. Unix "can be moved across machines with architectures and capabilities" easily because it seems the people who move it CHOSE TO IGNORE THE UNIQUE CAPABILITIES and ARCHITECTURES OF THOSE MACHINES. Case in point: the VAX. Ignore the FPA and the Virtual memory and what have you got? Right, a PDP-11/40. Whoopee! It's even more cruel to do this to a larger machine like a Cray. Says Unix-porter, "Nothing easier if we ignore the vectorizing." Giving the power of an 11/70 to an IBM-PC is a noble thing, giving it to a VAX reminds me of a Ben Franklin quote: "Calling a steer a 'bull' is a compliment; he's grateful for the compliment, but he'd rather have restored what's rightfully his". YOU explain to your average MBA type why all the complaints about performance on the machine HE approved. See how much OS theory he understands. >C will be around long after Unix is used as an obsolete example in...CS courses Sounds like prophesies of PASCAL from circa 1975, ALGOL 68 from 1969, etc. See how right they were.....If your right, I'll learn Japanese. >...commands--which should, rightly, be compared to both command and OS >bugs on VMS combined, since so much of a "traditional" OS has been >moved from the kernel to external commands in Unix. A quick look on SYS$SYSTEM: will obviate the same is the case for VMS. Commands on VMS are also (and always have been) external to the kernal.... >I want to emphasize that Unix is immature, and has growing pains. But >the quite different concepts embodied in Unix make comparing it with mature, >traditional OS's a task that should be undertaken with more care than, >say, comparint PR1MOS IV with VMS... *foof, sputter, buzz* Excuse me, but Unix is OLDER than VMS. If you want Try comparing UNIX to true siblings, say TOPS-20 or RSX, for a revelation. WHEN IS UNIX GOING TO GROW UP? David and I seem only to agree on one specific point worth reiterating strongly: All opinions and statements expressed herein are solely mine, and in no way may be construed as reflecting the official or unofficial opinions or attitudes of either my contractee, or my employer. M. Kenig (" Share and enjoy") ...abnjh!cbspt002
ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) (06/26/84)
Marc Kenig has submitted a rebuttal to my comments on this topic, which I think points out that I must not have given clear or concise reasons behind my statements; so I guess I'll waste some bytes one last time, and try to be a little clearer: >>...which Dave has obviously misunderstood in his defense of VMS over >>UNIX, and that I think are quite important to keep in mind........ >"VMS OVER Unix", I'm sorry, but I thought it was a comparison. >Why are Unix bigots always so damned defensive? Sorry, but please reread the article. By the time it's done, it definitely degenerated into the old argument of "OS X offers this, OS Y that." Those few instances where Unix was favorably mentioned weren't even centered on the kernel itself, but rather utilities. As to Unix bigot, pardonnez moi; I've worked on OS's from S370, and Exec 8 through Multics, GCOS 6, PR1MOS IV, and lowly CP/M and MS/DOS. There are things on various of those systems I miss sorely, such as asynchronous I/O requests. I've worked on custom R/T systems, and miss features offered in that environment. It just so happens that I've been working mostly in the UNIX environment for the last few years, and can answer criticisms on the same. I've therefore worked on operating systems ranging from the "big boys", in both batch and timeshare environments, to the smallest of dedicated systems that were little more than round-robin schedulers with todo-lists. In addition, operating systems happen to be a topic of interest with me, such that I do make an effort to be current in work in the field. Please, before making such statements as "Unix bigot", perhaps you could find out where I'm coming from. I don't like perjoratives. >>>VMS tends to get more performance out of its hardware, through >>>clustering, asynchronous IO, and good paging. These things can be tuned >>>for a particular installation, though they can also be mistuned. >>......if they wrote machine-specific code, they could usually get gobs >>of performance improvements on their machine. And only on it. Unix >>can be moved across machines with architectures and capabilities as >>widely differing as an IBM-PC, a VAX 11/780, and a Univax 1180., >Oh my. I seem to have heard all this before. Let me rephrase the first point: >If Unix had more machine specific code, it would be more difficult to port. >Unix "can be moved across machines with architectures and capabilities" >easily because it seems the people who move it CHOSE TO IGNORE THE UNIQUE >CAPABILITIES and ARCHITECTURES OF THOSE MACHINES. Case in point: the VAX. >Ignore the FPA and the Virtual memory and what have you got? Right, a >PDP-11/40. Whoopee! It's even more cruel to do this to a larger machine >like a Cray. Says Unix-porter, "Nothing easier if we ignore the vectorizing." >Giving the power of an 11/70 to an IBM-PC is a noble thing, giving it to a >VAX reminds me of a Ben Franklin quote: "Calling a steer a 'bull' is a >compliment; he's grateful for the compliment, but he'd rather have restored >what's rightfully his". >YOU explain to your average MBA type why all the complaints about performance >on the machine HE approved. See how much OS theory he understands. Sorry, but you've heard it all before, and will hear it all again. That's the basis of the Unix problem. VANILLA Unix is "portable". By allowing such, you are not tied to your IBM (or DEC, or Plexus) family of computers when it's time to step up; but since you don't know what machine your headed for, you can't use its nifty <whatever>. In point of fact, any good "Unix porter" will first get a 'vanilla' system running, then take advantage of specific advantages of the machine in a modular manner. What's that? Just keep the machine-specific whistles'n'bells localized and well-documented both in function and effect on data structures. But this will only go so far--for instance, embedded assembler statements in common routines to make use of a particularly snazzy instruction on your machine is in poor form, even though it speeds execution. Capiche? As for the MBA, if he (or she, of course) approved the machine without getting opinions from at least two or three different 'tech types' who DO understand OS theory, then he didn't get an MBA diploma, he got extremely coarse toilet paper. HIS job was to juggle the different opinions of the 'experts' to extract just exactly what he really wanted in a machine, and was this machine going to do it. >>C will be around long after Unix is used as an obsolete example >>in...CS courses >Sounds like prophesies of PASCAL from circa 1975, ALGOL 68 from 1969, etc. >See how right they were.....If your right, I'll learn Japanese. Get studyin', it's a fun language. This is a different type of prophesy. It's already got roots in fact. There have been far more 'languages of the future' than PASCAL--remember them all? PL/1? ALGOL-60? ALGOL-68? Bloody APL? And how about threaded languages like FORTH. In all cases, the important first step was to see such languages embraced extensively outside the academic community, either by the research community, or by industry, or both. This never happened to any great extent with any of the above, for a number of reasons. 'C', however, has not only been seized upon by countless educational institutions--thereby guaranteeing a crop of graduates who already know the language--but also many industrial concerns have already embraced it as an acceptable compromise between the speed and efficiency of assembler and the portability of a higher-level language. THIS is why this prophecy is different than the others, wakarimasu-ka? >>...commands--which should, rightly, be compared to both command and OS >>bugs on VMS combined, since so much of a "traditional" OS has been >>moved from the kernel to external commands in Unix. >A quick look on SYS$SYSTEM: will obviate[sic] the same is the case for VMS. >Commands on VMS are also (and always have been) external to the kernal.... I'm not just talking about commands. I'm talking about all the stuff that has been carried in more traditional operating systems, such as code to format the contents of the system clock, or to interpret N-thousand types of file records. Specifically, code that is not uniquely and totally involved with administration of critical and/or sharable system resources does NOT belong in the Unix kernel. (For my tastes, they went too far in many cases in vanilla Unix--there should, for instance, be some way to describe a generic record for a file without having to know the record's structure, in order to allow reasonable record locking for database applications. Not to mention user buffer purging, and device allocation, and...) Many of the functions provided in the kernel code of other OS's has been moved to the routines described in section 3 of the Unix Programmer's Manual. And many of the user-level commands are simple these calls with a user interface grafted on. I won't say the right things were always moved from the kernel; but I will say this is a reasonable approach to getting the critical kernel code down to something that can reasonably be understood and bulletproofed. >>I want to emphasize that Unix is immature, and has growing pains. But >>the quite different concepts embodied in Unix make comparing it with mature, >>traditional OS's a task that should be undertaken with more care than, >>say, comparint PR1MOS IV with VMS... >*foof, sputter, buzz* Excuse me, but Unix is OLDER than VMS. If you want >Try comparing UNIX to true siblings, say TOPS-20 or RSX, for a revelation. >WHEN IS UNIX GOING TO GROW UP? I maintain that VMS comes from a tradition of OS design that is far older and more 'developed' than the basic precepts of Unix; and in that manner, is 'older' than Unix. The two systems are trying to accomplish a similar task, but with very different goals and priorities; and Unix started from scratch in many ways. Unix couldn't grow up until its owner could see some reason to listen to the outside world and incorporate the requests coming from it. Until that happened, as long as it was good enough for internal use, if it was useful to others, well, that's nice. With AT&T's emergence as a true competitor in the market place, I've already seen an entirely different thrust to their Unix development efforts. And as they get more familiar with this new environment, I expect Unix to grow up in short order. (I just hope it doesn't become a juvenile delinquent...) I hope I've explained some of my expressed opinions to your satisfaction; but I think this is enough verbiage for the net at large. I welcome private mail concerning this issue; and if/when we come up with items of general import or interest, we can digest and submit to the net. I'm sorry if this sounds too much like a 'defense' of Unix; but the original article has led me to somewhat take the role of 'Advocatus Diaboli'. Oh, well... As always, all opinions and statements expressed herein are solely mine, and in no way may be construed as reflecting the official or unofficial opinions or attitudes of either my contractee, or my employer. Dave Ihnat ihuxx!ignatz
henry@utzoo.UUCP (Henry Spencer) (06/28/84)
>..............................................................If you want >try comparing UNIX to true siblings, say TOPS-20 or RSX, for a revelation. >WHEN IS UNIX GOING TO GROW UP? I have no experience with TOPS-20, but comparing Unix to RSX is indeed informative. As a realtime system, RSX may be all right (after all, that's what it was designed to be). As a timesharing system, there's no contest: Unix wins every time. Unix may not have grown up yet, but RSX has never gotten out of the cradle. A friend of mine (who was one of the first non-DEC people to see VMS) described VMS as "like a nightmare about RSX-11M". I've never seen any reason to quarrel with this description. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
bill@haddock.UUCP (07/07/84)
#R:abnjh:-70200:haddock:16700025:000:756 haddock!bill Jul 5 18:34:00 1984 >A friend of mine (who was one of the first non-DEC people to see VMS) >described VMS as "like a nightmare about RSX-11M". I've never seen any >reason to quarrel with this description. Having worked on one of the Unix emulators which runs under Vms, I would like to offer a parable: Defenders of Vms make much of logical names; indeed, try to imagine VMS without them! However, to redirect via SYS$INPUT, the translated value could be 63 characters long, maximum (at least in VMS 3.n. I've been away from it for a while) Since a VMS pathname can easily be 120+ characters, a user could end up S.O.L. VMS is incoherent; Unix is coherent. If the software base appeals to you, get VMS. I wouldn't touch it with a ten foot pole.