Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-smoke!smoke!gwyn@BRL.ARPA From: gwyn@BRL.ARPA (VLD/VMB) Newsgroups: net.unix-wizards Subject: Re: ULTRIX futures? Message-ID: <755@brl-smoke.ARPA> Date: Sat, 8-Feb-86 00:35:34 EST Article-I.D.: brl-smok.755 Posted: Sat Feb 8 00:35:34 1986 Date-Received: Tue, 11-Feb-86 06:07:44 EST Sender: news@brl-smoke.ARPA Lines: 149 Barry has made some very good points, most of which I agree with. ATTIS *has* made an unfavorable initial impression on the UNIX technical community, for example (although the recent 3B2/400 appears to be significantly improved over earlier models, and the next major release of UNIX System V is slated to incorporate substantial improvements, beyond what 4.3BSD can match. In many ways, UNIX System V is already more useful than 4BSD, although it does currently lag in networking support). By the way, Barry, I was told that RFS can link disparate machines, but given UNIX code quality to date, I am skeptical. I really hope AT&T will make an effort to teach their programmers how to code more portably. The main reason I think UNIX's commercial future lies primarily along the System V path is not so much that AT&T is pushing it; rather, it's because the *customers* are starting to demand it. Several federal agencies now mandate UNIX System V, for example. Even more significantly, in my estimation, is the fact that the standardization efforts for both UNIX and C follow System V semantics very closely. (I even technically agree with this; every time I find myself working in a native Berkeley environment, it is not long before I start cursing their primitive software development tools. The main motivation of the BRL UNIX System V emulation project was to provide the nicer, uniform, System V environment everywhere I have to work. Many of my users appreciate it, too.) Besides better user-mode libraries and utilities, which 4BSD could pick up, there are also many aspects of the UNIX System V kernel that are better designed and implemented than in 4.2BSD; memory management is one notable example. This is not to say that there are not problems with UNIX System V; Guy Harris and I have posted perhaps a hundred bug reports and there are many others we have fixed without telling the net. It is important to realize that the same thing would have been observed for 4.2BSD, except I avoid improving it because I don't use much of their user-mode software. (What I do use often suffers from the famous "Berkeley Brain Damage", which I attribute to the designers deciding on a single usage model and doing a lot to help that particular usage, to the detriment of other more general possible uses. Gee, I could have had a V8!) The reason that this issue is drawing increasing attention is that, unless AT&T really botches it, the next major release (3.0) of UNIX System V will be significantly better than any previous publicly- available version of UNIX (although it may be some time before this becomes generally apparent), and some of the new features will be difficult to fit into 4BSD-based kernels without major overhaul. What one would hope is that the folks at Berkeley would be willing to change their system to closely track UNIX System V, except in those cases (if any) where it is clear that a major loss of functionality would result. It was mentioned that DEC's Ultrix product was based on 4.2BSD and had attained some degree of System V compatibility through the use of the BRL UNIX System V emulation package. Actually, the current situation is somewhat different, in that DEC (like most of the other major 4BSD-based kernel vendors) has felt the pressure from the marketplace for System V compatibility, and they have been responding. Many (maybe even most) of these vendors obtained the BRL UNIX System V emulation package and used it as a base for their initial System V compatibility offering. (No, I will not disclose names. Just name one; they're probably included.) The trouble with the BRL UNIX System V emulation is that I could not emulate all aspects of UNIX System V semantics perfectly without making changes to the 4.2BSD kernel, which was off-limits for the purposes of my project. The 4BSD-based kernel vendors, however, do not have such a constraint, and what many of them have done is to incorporate into their kernels those System V features that are hardest to do in user mode, leaving the rest to a compatibility library very much the way I did the whole emulation. This approach has allowed 4BSD-based kernel vendors to provide System V functionality (yuck, I hate that word -- is there a better one?) to those customers who want it. DEC, for example, now advertises Ultrix as meeting all the specs of the System V Interface Definition (AT&T's official published System V semantic specification); I have no idea how much (if any) of my original work is still in the Ultrix product (I hope the bug fixes are). The problem with such a hybrid system, or even with a parallel- universe one such as Pyramid and Apollo offer, is that it gets progressively harder to maintain a split personality as the two base systems diverge. There are already possible security problems due simply to the different ideas the two UNIX variants have about such things as chown, process groups, terminal ioctls, signals, etc. if both semantics are provided on the same system. (Remember, security is an aspect of how everything fits together.) Merged systems have a similar problem; we use one here, and both the 4BSD and System V camps have found its behavior irritating. On a strictly functional basis, which version is better? For a long time, 4BSD adherents claimed: 4BSD supports demand-paged virtual memory - So does System V, more cleanly, and shared memory is provided (and is rumored to even work) 4BSD provides networking support - I agree that UUCP and 3Bnet don't qualify - SVR3 streams will be a boon to networking - TCP/IP is available for System V; soon with AT&T's blessing (I don't know if a stream- based TCP/IP will be released; Wollongong may provide essentially the Berkeley implementation) 4BSD has vi, termcap, and curses - System V picked these up, and improved termcap into terminfo (which really is better) 4BSD has csh - In many ways, the SVR2 Bourne shell is better - One can run ksh, which is Bourne shell compatible and offers more than csh (except for job control); there have been (unsubstantiated) rumors of ksh being supported in a future release of UNIX System V - I don't put shl in the same class as job control - I use a 5620 DMD, what do I care. DMDs are great! - As usual, Berkeley implemented the wrong thing; I thought those guys were supposed to talk with the folks at Murray Hill (maybe they don't listen) 4BSD has dbx - System V's sdb is comparable - I hope pi will arrive with SVR3.n (for small n) 4BSD is faster - UNIX System V is at least as fast for typical loads - The 4.2BSD fast file system is indeed faster under some circumstances, at the cost of other resources (CPU cycles and main memory) 4BSD has universities developing software for it - AT&T has Bell Labs, so there, nyaah, nyaah - AT&T has substantial development resources - I agree that AT&T moves more deliberately - That can be a Good Thing too In other words, these arguments used to be mostly valid (that's why we chose to run 4BSD on the BRL VAXes), but UNIX System V has rapidly improved -- faster than 4BSD is improving. If any die-hard 4BSD hackers have read this far, I would be glad for you fellows to keep playing around and coming up with useful ideas. I like good ideas. But I sure don't want you using me, as a commercial *user* of the system, as your guinea pig. The production folks really do want improvements, but they want them introduced in a controlled manner, to minimize operational headaches. So far, AT&T has done a much better job of that than Berkeley has.. ..but nobody's perfect Finally, a plea: Let's not start one of those pointless "My system is better than yours" debates. The topic is, where is UNIX headed in the near future? I say: clearly System V, so far as the commercial marketplace is concerned. Feel free to dispute this, based on facts or perceptions.