Dual BSD/S5 UNIXES

[Doug Gwyn]

In article <156 at sauron.OZ> shaun at 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.