shaun@sauron.OZ (Shaun ARundell) (08/04/86)
Pyramid is not the only vendor to offer a Dual ported UNIX.
Gould's UTX/32 (releases 1.3 and above) offer a similar
facility, as do a number of other vendors.
Any body who has worked in a post sales position in the last
year or so will see why this is necessary, at least from an
economic standpoint.
A large number of the tenders that have come out recently have specified
a particular version of UNIX as a mandatory. Most Universities
and DOD sites specify BSD4.2 has necessary and a lot of commercial
sites specify S5V2 as becessary. This means that a vendor has the
choice of offering one varient and losing business or offering
A - S5 and BSD4.2 seperately
B - A superset
C - A Dual port
Choice A is usually ruled out as too difficult to maintain (every support
site would need access to two machines or have to reboot to move
from one UNIX to the other)
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.
Having worked on Pyramids, Goulds and single SV5 and BSD4.2
machines, I favour choice C. Choice A is unweildy. Choice B is 98% ok,
but those 2% of commands that behave funny cause real headaches.
It is really fairly easy to do a dual port. Both Pyramid and Gould
started off with a BSD kernal added some S5 support (mainly IPC) and
then just wrote two lots of system libaries. All the different /bin,
/usr/bin, /usr/ucb, etc. just compile straight in. If your carefull
how you do your kernal, updating to BSD4.3 and S5V3 is fairly straight
forward. There are a few gray areas with signals and terminal handling
but both Pyramid and Gould have solved these issues in a workable
fashion.
Anthor real problem is init, ttys (and some other /etc stuff).
Pyramid has done a superset, Gould stuck with the BSD stuff.
I see the real point as offering the USER (both system supervisor
and general user) not just both lots of commands but a choice.
With the current length of stay for UNIX programmers being 7 months
he bounces between S5 and BSD systems on a regular basis. With a
dual port he has all the tools and facilites he is use to.
A dual port also allows the vendor to go for all the
UNIX tenders not just his particular varient.
\XX Shaun Arundell ARPA: munnari!sauron.oz!shaun@SEISMO
\X Technical Support UUCP: seismo!munnari!sauron.oz!shaun
XXXXX \XXXX GOULD COMPUTERS ACS: shaun@sauron.oz
XXXXX /XXXX
/X Telephone STD: (02) 957-2522
/XX ISD: +61 2 957-2522 gwyn@brl-sem.ARPA (Doug Gwyn ) (08/09/86)
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.
guy@sun.uucp (Guy Harris) (08/09/86)
> A - S5 and BSD4.2 seperately > B - A superset > C - A Dual port > > 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. > > Having worked on Pyramids, Goulds and single SV5 and BSD4.2 > machines, I favour choice C. Choice A is unweildy. Choice B is 98% ok, > but those 2% of commands that behave funny cause real headaches. At this point, it seems the term "dual port" covers a multitude of implementations; the definition, I guess, is "any system that has two versions of 'tr'" or something like that. The question is whether you have duplicate versions of *every* command, or just the ones where they are incompatibly different, not just where one can be made into a superset of the other by adding the (possibly null) set of additional features from the other. For instance, keeping two versions of "fgrep" is just dumb; the main difference between them is that the 4.2BSD version derives from the version supplied with an addendum to V7, and thus has a bug fix that the S5 version, which seems to derive either from the original V7 version or a later version that still predated the V7 addendum, does not. The same question applies to things like "stat"; if you read the S5 manual page, the 4.2BSD version of "stat" is 100% compatible with it, so there's no good reason to revive the 4.1BSD "stat" call and use it in the S5 environment. There are some S5 programs that incorrectly assume that "st_atime" and "st_mtime" are contiguous (this is NOWHERE stated or implied in the S5 manual page, and in fact the S5 "lint" library entry and manual page entry for "utime" make pains to ensure that you do NOT pass "&st_atime" to "utime"), but those programs ("cpio", "pack", and "file") should be fixed. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)