Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 beta 4/12/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hao!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix Subject: Re: Re: marketing unix Message-ID: <2098@rlgvax.UUCP> Date: Wed, 11-Jul-84 22:33:50 EDT Article-I.D.: rlgvax.2098 Posted: Wed Jul 11 22:33:50 1984 Date-Received: Sat, 14-Jul-84 01:30:22 EDT References: <1475@pegasus.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 77 > TO Erik E Fair, > I have not personally used BSD unix so I can't make any speed claims, > BUT how upward compatable is 4.1 to 4.2?? > All AT&T BTL Unix's are upward compatable. I presume you're referring to the article which read > I'm waiting for the collective screams of those estimated 150,000 > professionals and programmers when they realize that System V on > [insert random machine] isn't as good as 4.1/4.2 BSD on their alma > mater's vaxen... > ``What do you mean, ^Z and ^W don't work here? > Why doesn't this UNIX act like the VAX at Podunk U?'' (although there was no "References:" line in your article, and you didn't bother including any relevant text from the article you were replying to - as was done above), but "isn't as good as" refers to several things here: 1) BSD UNIX supports the VAX-11 hardware far better than System V. For one thing, it correctly handles Translation Not Valid faults. The OS isn't supposed to panic when that happens, it's supposed to fetch the missing page from the disk. There are applications out there that *need* virtual memory (or, at least, run better with it than without it). 2) BSD UNIX supports most of the (conventional) devices that can be attached to a VAX-11, even those that the BTL UNIX developers don't like. Furthermore, it supports more {Uni|Mass}bus adaptor/device configurations than System III did (S3 was particularly dismal in this); S5 may actually realize that a user may want to have more than two MBAs and put some disks on one and some on another, or have two UBAs, or... but S3 sure didn't. 3) BSD UNIX's terminal driver has a superior user interface than do any of the BTL UNIXes (including V7) - the point made in the quote above. Why can't System V properly erase tab characters in ECHOE mode? Furthermore, the System V Release 2 "job control" mechanism is inadequate, because 1) there's no way to notify a program that does "funny things" to the terminal (screen editing, putting it in graphics mode, putting the keypad in application mode, etc.) that it's having control of the terminal taken away from it (so it can clear the screen, or put the terminal back in a "standard" mode that the program to whom the terminal is being given can use it) or that it's getting control of the terminal returned to it (so that it can redraw the screen or put the terminal back into the mode it was in when it left) and 2) there's no way to stop a job - all you can do is take the terminal away from it. It'd occasionally be useful to stop a job, examine it or correct an error, and restart it - which the BSD job control mechanism lets you do. 4) 4.2BSD UNIX supports networking sensibly. System V doesn't. And if the USDL people are as Berkeleyphobic as it has been claimed they are, System V isn't likely to in the near future. The Berkeley networking implementation *works*, and at least seems well designed for supporting multiple protocols (which is going to be a necessity for the forseeable future). 5) In some ways, 4.2BSD has better administrative facilities than System V. The auto-reboot stuff and "fsck -p" for preening file systems is nice, and the disk quota mechanism will come in very handy for some sites, to name two examples. I also think there are some things that System V does better. The System III/ System V "open" and "fcntl" calls are nice; so did Berkeley, as they adopted them for 4.2BSD. The shared memory is useful, although Berkeley plans to add it at some point. I personally prefer the System V "init" because it's more flexible than the old-style "init" (it's nice to be able to control arbitrary daemons from "init", and it's nice not to have to run "getty" as the login program on every terminal). The added functionality in the libraries and some of the commands are useful. "Terminfo" and Mark Horton's new "terminfo"-based "curses" are supposed to be superior to "termcap" and the earlier "curses". So how about declaring a truce, and both sides picking up the good ideas from each other? (Or developing a system which picks up the best of both worlds.) These sort of debates can be fun, just like the UNIX vs. VMS debates, but adopting the good ideas from other systems is generally more productive than playing NIH games and defending your favorite system when right and when wrong. (Are you listening, USDL?) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy