Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!smoke!g...@BRL.ARPA
From: g...@BRL.ARPA (VLD/VMB)
Newsgroups: net.unix-wizards
Subject: Re: merging 4BSD and SysV utilities
Message-ID: <2711@brl-smoke.ARPA>
Date: Thu, 31-Jul-86 10:25:11 EDT
Article-I.D.: brl-smok.2711
Posted: Thu Jul 31 10:25:11 1986
Date-Received: Sat, 2-Aug-86 04:12:53 EDT
Sender: n...@brl-smoke.ARPA
Lines: 15

I think the folks who are trying to figure out how to best maintain
two versions of everything are on the wrong track.  There is no good
reason not to combine versions for nearly all the regular UNIX
command utilities.  Usually this is a matter of finding the least
buggy version and then folding in the extra options from the other
version.  The only remaining problem is then to get AT&T and UCB to
"buy back" the improved merged version so that this work doesn't
have to be repeated by everyone into the indefinite future.

The C library is a different matter, since there are many semantic
differences between 4BSD and SysV, especially with system calls.
However, there is also no good reason for all UNIX C environments not
to include all functions required for X3J11 and 1003.1 conformance.

Let's try to improve the UNIX environment, not hobble it.

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!im4u!ut-sally!seismo!rochester!cornell!gvax!jqj
From: j...@gvax.cs.cornell.edu (J Q Johnson)
Newsgroups: net.unix-wizards
Subject: Re: merging 4BSD and SysV utilities
Message-ID: <459@gvax.cs.cornell.edu>
Date: Wed, 6-Aug-86 15:41:13 EDT
Article-I.D.: gvax.459
Posted: Wed Aug  6 15:41:13 1986
Date-Received: Sat, 9-Aug-86 03:35:22 EDT
References: <2711@brl-smoke.ARPA>
Reply-To: j...@gvax.cs.cornell.edu (J Q Johnson)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 29


Doug Gwyn argues:
>  There is no good
>reason not to combine versions for nearly all the regular UNIX
>command utilities.  Usually this is a matter of finding the least
>buggy version and then folding in the extra options from the other
>version.  The only remaining problem is then to get AT&T and UCB to
>"buy back" the improved merged version so that this work doesn't
>have to be repeated by everyone into the indefinite future.

Although I agree in principal with Doug, I think he's underestimating
the difficulty of the endeavor.  This is, for example, exactly what
Gould tried to do in their early versions of 4.2BSD.  They gave up
and have gone back to a straight 4.3BSD version, mostly because of
customer complaints.  Sure the Sys V tr is much nicer than the 4.xBSD
version of that utility, but it's incompatible, and using it breaks
many 4.xBSD shell scripts.  It is a LOT of work to find all such
induced bugs and fix them.  Implementing two Universes probably cost
Pyramid an order of magnitude less person time than a really good merger
would have.

Now, if you aren't trying to market a complete system then the cost
calculation is different.  It is more cost effective to lobby with your
least favorite vendor to adopt the "better" version of any one utility.

Unfortunately, UCB seems no longer to be in the business -- I'll be
surprised when 4.4BSD is released!  So you have to sell not to just AT&T
and UCB, but to AT&T, SUN, DEC, and IBM, plus Gould, Pyramid, Apollo,
ad nauseum.

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!sri-spam!nike!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: merging 4BSD and SysV utilities
Message-ID: <5975@sun.uucp>
Date: Fri, 8-Aug-86 14:22:02 EDT
Article-I.D.: sun.5975
Posted: Fri Aug  8 14:22:02 1986
Date-Received: Sun, 10-Aug-86 20:14:29 EDT
References: <2711@brl-smoke.ARPA> <459@gvax.cs.cornell.edu>
Organization: Sun Microsystems, Inc.
Lines: 17

> Although I agree in principal with Doug, I think he's underestimating
> the difficulty of the endeavor.

Not by all that much.  There's this wonderful tool called "diff" that makes
it much easier - the 4.3BSD version, which can be told to ignore differences
in white space, makes it easier still.

> It is a LOT of work to find all such induced bugs and fix them.

Not *all* that much work - mostly tedium.  It's considerably less work if
you're reasonably familiar with the UNIX command/library/system call set and
with the various tweaks that different development organizations have made
to it.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	g...@sun.com (or g...@sun.arpa)

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!caip!princeton!allegra!ulysses!mhuxr!
mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!wombat
From: wom...@ccvaxa.UUCP
Newsgroups: net.unix-wizards
Subject: Re: merging 4BSD and SysV utilities
Message-ID: <2000042@ccvaxa>
Date: Wed, 13-Aug-86 21:21:00 EDT
Article-I.D.: ccvaxa.2000042
Posted: Wed Aug 13 21:21:00 1986
Date-Received: Fri, 15-Aug-86 20:04:07 EDT
References: <2711@brl-smoke.ARPA>
Lines: 16
Nf-ID: #R:brl-smoke.ARPA:2711:ccvaxa:2000042:000:763
Nf-From: ccvaxa.UUCP!wombat    Aug 13 20:21:00 1986


As John said, Gould decided to give up on a merged BSD/ATT system.  It did
take some extra work (and a good memory for trivia and history) to maintain
the merged system, but I for one didn't mind because I *liked* the merged
system.  Unfortunately, enough customers didn't that we are switching to a
split 4.3BSD / System V view of the world. By putting /usr/5bin in your
$PATH you can pick up System V commands, but compiling something that wants
both BSD and ATT library routines is tricky.


"Our first order of business will be to find a deranged alchemist, which
should not be very difficult. China," said Master Li, "is overstocked
with deranged alchemists."
Barry Hughart, *Bridge of Birds*		Wombat
					Gould CSD / Urbana
					ihnp4!uiucdcs!ccvaxa!wombat

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: merging 4BSD and SysV utilities
Message-ID: <6233@sun.uucp>
Date: Fri, 15-Aug-86 23:42:50 EDT
Article-I.D.: sun.6233
Posted: Fri Aug 15 23:42:50 1986
Date-Received: Sun, 17-Aug-86 10:49:54 EDT
References: <2711@brl-smoke.ARPA> <2000042@ccvaxa>
Organization: Sun Microsystems, Inc.
Lines: 13

> By putting /usr/5bin in your $PATH you can pick up System V commands,
> but compiling something that wants both BSD and ATT library routines
> is tricky.

I presume you meant "both 4.2BSD and S5 versions of incompatible routines";
compiling something that wants both "socket"/"connect"/...  and
"shmget"/"shmat"/...  is not difficult at all on a system that's done right.
(The same applies to commands; you should not have to put "/usr/5bin" in
your path to get "cut", "paste", "cxref", "cflow", ....)
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	g...@sun.com (or g...@sun.arpa)

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.unix-wizards
Subject: Re: merging 4BSD and SysV utilities
Message-ID: <3122@brl-smoke.ARPA>
Date: Mon, 18-Aug-86 06:54:13 EDT
Article-I.D.: brl-smok.3122
Posted: Mon Aug 18 06:54:13 1986
Date-Received: Tue, 19-Aug-86 04:06:42 EDT
References: <2711@brl-smoke.ARPA> <2000042@ccvaxa>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29

In article <2000042@ccvaxa> wom...@ccvaxa.UUCP writes:
>... but compiling something that wants
>both BSD and ATT library routines is tricky.

Yes!  That's the worst single problem we have with split environments at BRL.
One has to maintain two versions of most libraries, since for example the
data structures included via <stdio.h> differ between the two environments.
If one acquires a commercial package, for instance a data base manager, in
just one environment, then it may be difficult or impossible to use it from
the other environment.  We actually run through this exercise about once a
quarter when we get source software from a System V environment that uses a
commercial DBMS which we have only in a 4.2BSD environment.

Another, relatively less severe, drawback to split environments is the
extra storage space required to maintain two copies of everything.

Split environments are a relatively painless way for a system implementor
to quickly get into a position to support both System V and 4BSD customer
bases, but the long-term goal of the UNIX community should be to merge
the strengths of these environments while gradually leaving their
weaknesses behind.  As I said previously, no single vendor (other than
AT&T and possibly Sun) is in a position to accomplish this merger on their
own.  I would like to see 4BSD-based system vendors pick up Sun's merged
system as a basis for theirs, if Berkeley doesn't take back the result;
clearly Sun's direct competitors have a problem with this, but if Berkeley or
Sun will cooperate with this approach, we'll all be better off in the near
term.  Once the systems are effectively merged throughout the industry, other
vendors can again go their own way (but if they want to sell to me they
better support the standard environment, no matter what else they offer).

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!pyramid!decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: merging 4BSD and SysV utilities
Message-ID: <6313@sun.uucp>
Date: Tue, 19-Aug-86 04:11:32 EDT
Article-I.D.: sun.6313
Posted: Tue Aug 19 04:11:32 1986
Date-Received: Wed, 20-Aug-86 08:32:23 EDT
References: <2711@brl-smoke.ARPA> <2000042@ccvaxa> <3122@brl-smoke.ARPA>
Organization: Sun Microsystems, Inc.
Lines: 43

> One has to maintain two versions of most libraries, since for example the
> data structures included via <stdio.h> differ between the two environments.

Not on my machine, they don't!  Both environments use the 4.3BSD FILE
structure.  The "_flag" is a "short", and includes _IOSTRG; this is
necessary since FILE structures are "malloc"ed except for "stdin", "stdout",
and "stderr" and _NFILE no longer exists (4.3ism).  The "_bufendtab" array
is superfluous, since there's a "_bufsize" element in the FILE structure;
the only reason the USDL didn't stick it in also was probably that they
wanted to allow old ".o" files to be linked with the new library.  Since all
our old ".o" files were built with the 4.[23]BSD structure, this didn't
apply to us.

Most of the code of the standard I/O library actually comes from S5R2,
modified as necessary to work in our environment.  For the few routines that
behave differently, two versions are provided in two different libraries.

Any code written to conform to the SVID will work, since it won't be mucking
with the innards of standard I/O.  Any code that mucks with the innards of
standard I/O is taking its chances; other implementations, now or in the
future, may not have the same innards.

> Another, relatively less severe, drawback to split environments is the
> extra storage space required to maintain two copies of everything.

Then don't maintain two copies of *everything*, just of the stuff that's
incompatibly different.  We supply only one version of most commands.

> but the long-term goal of the UNIX community should be to merge
> the strengths of these environments while gradually leaving their
> weaknesses behind.

Some systems may still have to provide a "4BSD compatiblity library and
command set", for things like old scripts that use "tr" and old programs
that assume "sprintf" returns a pointer to its first argument.  (Neither of
these, BTW, are the direct result of anything Berkeley has done; one version
of AT&T UNIX, namely V7, worked one way, and 4BSD is derived from that.
Both were different in S3 and S5; the first because S3/S5 had the older V6
version, and the second because it was changed from the V7 version.)
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	g...@sun.com (or g...@sun.arpa)