Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!caip!brl-adm!brl-smoke!brl-sem!gwyn From: gwyn@brl-sem.ARPA (Doug Gwyn ) Newsgroups: net.unix-wizards Subject: Re: Dual BSD/S5 UNIXES Message-ID: <405@brl-sem.ARPA> Date: Fri, 8-Aug-86 19:11:58 EDT Article-I.D.: brl-sem.405 Posted: Fri Aug 8 19:11:58 1986 Date-Received: Tue, 12-Aug-86 12:47:22 EDT References: <156@sauron.OZ> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 74 In article <156@sauron.OZ> shaun@sauron.UUCP (Shaun ARundell) writes: >Choice B was the track that GOULD had first taken (with the help of >the BRL emulator). This caused a lot of flack from system adminstrators. >Some commands behaved in fashion that was neither pure >BDS 4.2 or pure System V. > >Choice C is Gould's current strategy. There is a /usr/bin and a /usr/5bin >a /usr/lib and a /usr/5lib a sv and a bsd command, etc. Shaun's UTX/32 history is partly wrong. The BRL UNIX System V emulation did not contribute to UTX/32 Release 1.2 or earlier (has anything after 1.2 been released yet?), although it was included on some of the "D4" user-contributed software tapes and is recognizably the inspiration for the method taken by what Shaun calls "Choice C". The early releases of UTX/32 were Gould's (Compion's) attempt to merge the two major UNIX variants (4BSD and SysV) into a single environment. It is true that there were customer complaints due to incompatibilities between the merged version and whatever native version the user preferred. This doesn't prove that a merged version is unworkable, however, although it indicates that individual vendors may not be able to make their own private merged version stick. Customers really don't want a third UNIX variant; two is already one too many. The desire is to CONSOLIDATE the variants, and few vendors are in a position to do this for more than their own processor product line. I think the key points are first of all to take great care to form a true superset whenever possible (Gould could have done better on this), and secondly to get the merger BOUGHT BACK by the "owners" of the UNIX variants, namely Berkeley and AT&T. The main hope I see for this at present is the AT&T-Sun agreement; if AT&T UNIX System V Release N (N > 3.0) incorporates the majority of this work, then there would be little reason to continue evolution of the Berkeley variant as a contender in the commercial marketplace (as opposed to research and educational uses). One force in this direction is the fact that 4BSD is not very close to conformance with evolving official industry standards, whereas System V is; if one were to alter a 4BSD system to conform to the standards, the result would be much the same as a 4BSD- SysV merger anyway. Some vendors such as DEC who started out with 4BSD have been assimilating portions of UNIX System V, while others have split into two simultaneous environments a la Pyramid or the BRL package. If the two environments diverge much more, my feeling is that 4BSD would lose further ground in the marketplace. (Much of its current position in the science/engineering market is due to the early spread of VAX UNIX in the days when 4BSD was the only good version available for the VAX.) As the author of the BRL UNIX System V emulation for 4.2BSD, I should point out that it was designed as a means of obtaining an approximation of the eventual standard environment NOW on 4BSD kernels, so that local programmers could develop software with an assured future within a SINGLE environment. (Not everyone at BRL picked up on this idea, but several did.) Lack of network support in pre-Release 3 UNIX System V forced some reliance on 4BSD facilities, but as of SVR3 even this can be merged (the TLI library functions noticeably resemble BSD socket calls; I suspect sockets could be emulated using streams but not vice-versa). I never intended that the, to me comparatively primitive, 4BSD environment be perpetuated without improvement into the indefinite future! The improvement that I hope(d) to see in 4BSD includes picking up AT&T library and utility developments made since the 1979 reference point (UNIX/32V) that 4BSD was derived from. AT&T has picked up some of the Berkeley enhancements, and I also hope that this will continue, although in many areas SysV is now technically ahead of 4BSD. Vendor kernel gurus are usually aware of just how much either major UNIX variant could stand to be improved. Much of the innovation I now see is being done by vendors of systems with unusual (multi-processor, etc.) architectures; I would urge them too to share their improvements as much as possible. If the UNIX subindustry can cooperate, there is more than enough potential money in it for everybody. The real "enemy" is not the "other UNIX variant", but rather the traditional DP shop concept of computing (and, these days, the approaches taken by some primitive micros). In case you hadn't noticed, often when the UNIX forces go out to do battle against the philistines, they are laughed out of the game because "UNIX people can't even agree on what a UNIX system is". An unnecessary state of affairs; rather than splitting into camps, let's get our act together.