UUCP USERFILE

[Guy Harris]

> Would it? Let one talk to HD sites, the other to 4.3 sites.

OK, now what if a person running in a universe with version A of UUCP wants
to send a message to somebody with a machine running version B of UUCP.  Are
you proposing that this person (not the system administrator, but the poor
*user*) be required to keep track of what version of UUCP the other guy's
running ?

> I've run into problems talking 4.2 uucp to 4.3 uucp.  Might be nice t
> maintain the old 4.2 sites if I talked to any 4.2 uucp'ers.

OK, now what about the old UniSoft version of UUCP that didn't talk to some
other UUCPs due to a compiler bug?  Are we to keep a version of that around
as well, just in case we need to talk to them?  Are you propsing to make the
cardinality of the set of UUCPs on your system equal to the cardinality of
the set of versions of UUCP out there?

For that matter, what if your TCP/UDP/IP implementation has problems talking
to TOPS-20?  Do you keep N different TCP/UDP/IP implementations around, to
deal with every possible other implementation you'll ever want to talk to?
No, you either fix your implementation, pressure your vendor to fix it, or
pressure the other guy to get *theirs* fixed.  Yes, UUCP isn't a nicely
specified protocol like TCP, UDP, and IP are, but that's not really a very
good excuse.  If two versions of UUCP can't communicate, it's NOT because
"well, they're two different versions, we have to support both"; it's
because one or the other is BROKEN.

> See below for proof of which way pyramid's uucico & init are handled.

Note that somebody pointed out that most people pick one version of "uucico"
or the other, so it's not as if you provide both versions.  The scheme for
supporting both is a bit of a kludge, and doesn't seem to be the "normal"
way of running things.  You HAVE to choose one version of "init" or the
other.

> It is,( the hybrid) and is pretty nice, and it works.

Yes, but how many people *really* use the one of the two versions of "init"
as a pseudo-hybrid?

> >They may have two versions of the "uucp", "uux", etc. commands -
> >however, if it's possible to have versions that are a compatible superset
> >of both, *that* would be the correct thing to do, not provide a version
> that can do A but not B and a version that can do B but not A.
> I disagree. what if A & B inherently at odds?

They aren't.  The user doesn't see the queueing details of UUCP; they see
the options and arguments accepted by the commands.

> You end up with a much larger merged versiob, AB, that takes up easily
> more space than the sum of A and B in space, and probably runs slower.

Do you have any evidence for your claim that the merged version would be
"much larger", "take(s) up easily more space than the sum of A and B in
space", and "probably run(s) slower"?  I maintain that it wouldn't be - and
I've brought up a "post-4.2 version of the 4.2BSD UUCP" on a System III
system, as a replacement for the vanilla System III version.  It was bigger
because it *did more*, like run UUCP over TCP connections (*quite* useful).

> All that 
> if(universe == UCB) {
> 	i++;
> 	}else{
> 	i--;
> }
> gets expensive...

All *what* "if(universe == UCB)" stuff?  You would probably have two
versions of "uucp", "uux", etc., built from the same source with "#ifdef"s
for the few command-language differences.  The tests on which environment
you're in are done at *compile* time, which makes them quite cheap indeed at
run time.  UUCP *jobs* don't live in a "universe", so "uucico" doesn't do
any of that testing.  (Besides, even if it *did* do the testing at run time,
how do you know it'll be noticeably more expensive?  Find out at the
beginning, save the result in a local variable, and make sure you don't do
the tests once per iteration of a loop that's run frequently.  The naive
approach might be expensive, but that's why the naive approach to solving a
problem is very frequently wrong.)

> Further, I am quite stuck with this AB mosaic. 
> Say Berkeley upgrades their uucp.  Since I have source licence, I just spin
> the source of tape onto the pyramid machine.  make.  make install. All done.
> Your merged version would require heavy hacking by such as he who wrote it in
> order to make it compatible.  Further, I probably only have binaries. 
> Of course I *COULD* wait for my vendor to update the program...
> 
> With the separate universes I can by code from any vendor, and plop it on.
> 
> Jeess, They look different to me!

Yup, they are.  Do you run both?  If so, you can probably do better not
doing so.

> Of course you might call it stupid to run the world this way, but I like the
> fact that I can buy sys5 ditroff, say make install, and from my login, where
> I've defined my universe as ucb, say:
> cheops 7 % att ditroff -me file 
> and have it work!

You don't need two universes, with walls between them, to do this!  You just
need an environment in which you can build software written for an S5
environment; the 4.3 environment is closer to the S5 environment than the
4.2 environment was, and the S5R3 environment is closer to the 4.[23]
environment than the S5R2 environment was, so as time goes on this gets
simpler.

We happen to *have* "sys5 ditroff" (what you mean is DWB ditroff) on our
system.  It's been much hacked, but little if any of that has to do with
S5 and 4.2 environments.  It has more to do with the fact that lots of C
code out there tends to do dumb things like dereferencing null pointers, and
tends to have bugs in it, and with the fact that we make fairly heavy use of
those tools for doing our own documentation and needed to add some
capabilities to it.

BTW, if your "ditroff" is running in the "att" universe and is using the
"-me" macro package, it's not a very "vanilla" S5 environment since S5
doesn't come with that macro package.

> It may appear silly to keep both universes around, but disk space is cheap,
> and programmer time spent porting a 4.2 program to a sys5 environment, or
> vice versa, is NOT cheap.

There are other ways of providing two environments.  Programmer time spent
maintaining two versions of a program when one will do isn't cheap either.

> As for making one program the synthesis of programs of the two
> universes, which is I believe the direction sun is heading with their
> SYS5 4.2BSD marriage, there are gonna be too many places where it just
> won't work.  I believe pyramid combined the init's of 4.2 & sys5 into
> one superset, which as you state, is the only logical way to handle
> that.

You believe incorrectly; somebody from Pyramid stated that they provide two
versions, and you choose which to use.  I certainly didn't state that
combining them into one superset was the logical way to handle it.  What we
did at CCI was to start with the S5 version and teach it about things like
automatic rebooting.  At some point in the future it may be possible to
build a new version of "init" which isn't necessarily just like either one,
but which can replace either one reasonably well.  "init" doesn't provide
one of the critical system interfaces that zillions of *applications* depend
on, so it's not clear that making that part of the environment a program
sees is a big enough win to justify the expense.

> However, to merge /bin & /usr/{ucb,bin}, you just run into too
> many problems.

Like what?  There are a *few* programs where you can't provide a version
that is a superset of both, so you provide two directories to hold the two
versions.  You could do this with conditional symbolic links, but I don't
think all that mechanism is necessary, considering you can set up $PATH to
search additional directories.

> What would you do with /usr/lib ?

Provide two versions, and have two versions of "cc" in different directories
that use the "-L" flag (and the "-I" flag) to search in different places for
libraries, etc.

Neither of these are particularly brand-new ideas; they all appear in Doug
Gwyn's S5 emulation package.

> How about programs using sockets? select? various networking? semaphores?
> shared memory?

If you can't get at sockets, "select", the networks supported by sockets,
semaphores, shared memory, or messages (you forgot that)  from *either*
environment, your implementation is broken.  It takes no technical
sophistication whatsoever to make them available in both environments.

> Pyramid succeeded in presenting the user with Either a SVID or 4.2BSD
> pure virgin environment.

"Pure virgin"?  Oh, really?  Did you add the "-me" package to the SV
universe, as per your example above, or did Pyramid provide it since it
doesn't *break* anything to do so?  Are you so sure the environments don't
have any *compatible* enhancements from the other universe?

Also, the program development tools (compilers, linkers, assemblers, etc.)
are based on the 4.2BSD object file format.  Pyramid probably made the
*very* sensible decision that the benefits of providing two sets of *all*
tools that have to know about object file formats (given how little code
knows about object file formats) far outweighted the costs of offering two
assemblers (and probably two compilers to drive them), two linkers, etc.,
etc..

> He can also pipe data through the fabric of both universes (Please pardon
> that...).
> % (universe = ucb) 
> % eqn file | att ditroff -ms | colcrt | att cpio -ci ...
> 
> Not too bad.

Not too exciting, either.  I can do *that* on my machine, and I don't have
to stick "att" in front of "cpio".  We've had it in our systems as a
*standard* component, in "/usr/bin", since at least 2.0.

No, you can't have a single environment compatible with both 4.2BSD and S5.
But if you provide two environments, you don't have to provide two copies of
everything, either.  The two systems are both quite easily recognizable as
descendants of Research UNIX, so it's not as if there's this great chasm
between them, as some folk "wisdom" would have it.  Folk "wisdom" sometimes
has it that they're drifting apart, too; 4.3 has changed its "ctype.h"
macros to be S5 compatible, and has added some S5 library routines, while
S5R3 has picked up "mkdir", "rmdir", and the directory library, so the trend
seems to be in the opposite direction.

I suspect that within 5 years most systems will, at least, have an
environment where they more-or-less resemble System V; many will have a
number of added 4.2 features so that anything you can do on 4.2 you can do
on these systems, albeit with some small changes.  A lot of those systems
will have 4.2 environments, as well (note that the TCP/UDP/IP AT&T was
flogging for the 3Bs had a library emulating the socket system call
interface; even if the TLI library is better, the socket system call
interface is a bit of a *de facto* standard in the UNIX TCP/UDP/IP world).

By that time, though, System V will have changed, so that it'll probably be
closer to 4.[23]BSD than it is now.  (If 4.4BSD comes out, it'll probably be
closer to S5 than 4.[3]BSD is now, too, especially if requiring an S5
license ceases to be a problem.)  Most of the truly irreconcilable
differences (as opposed to the "one version has X but the other doesn't,
which is hardly irreconcilable, except for a tiny number of cases where X
requires a change that *does* introduce an irreconcilable difference) are
not major differences of philosophy, but annoying nits like the return value
of "sprintf" or the syntax of the "tr" command.  A number of others involve
the UNIX administrative utilities, several of which need enough work that
you can probably come up with something that's better than *either* one.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)