UUCP USERFILE

[Michael McNamara]

In article <5561 at sun.uucp> guy at sun.uucp 
(Guy Harris) writes (>) in comment to (>>):
>
>> I would not mind having System V UUCP as an option, if there is really some
>> improvement, but I expect Berkeley's to be there if I have bought a system
>> that is claimed to be Berkeley Unix.  Pyramid, which you mention, is of
>> course the last place you would expect to find a System V UUCP mixed into a
>> 4.2 system.  They maintain separate 4.2 and System V universes.  Thus they
>> have two separate UUCP's.
>
>I very sincerely doubt that.  Maintaining two different versions of "uucico"
>would be ridiculous.  

Would it? Let one talk to HD sites, the other to 4.3 sites.
I've run into problems talking 4.2 uucp to 4.3 uucp.  Might be nice to maintain
the old 4.2 sites if I talked to any 4.2 uucp'ers.

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

>(Does Pyramid have two versions of "init", for
>instance?  You can't do that.  You have to choose one or the other, or have
>a hybrid that reads "/etc/ttys" *and* "/etc/inittab" - if that's even
>possible.)  
It is,( the hybrid) and is pretty nice, and it works.

>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?  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.  All that 
if(universe == UCB) {
	i++;
	}else{
	i--;
}
gets expensive...

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.

>
>-- 
>	Guy Harris
>	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
>	guy at sun.com (or guy at sun.arpa)

below:

Ok, let me login to our pyramid:

% rlogin cheops ( cute name, don't you think?)

cheops 1 % diff /usr/.attlib/uucp/uucico /usr/.ucblib/uucp/uucico
Binary files /usr/.attlib/uucp/uucico and /usr/.ucblib/uucp/uucico differ
cheops 2 % ls -l !*
ls -l /usr/.attlib/uucp/uucico /usr/.ucblib/uucp/uucico 
---s--x--x  1 uucp       120832 Apr  3  1985 /usr/.attlib/uucp/uucico
---s--s--x  1 uucp        98304 Apr  3  1985 /usr/.ucblib/uucp/uucico
cheops 4 % strings !:2
strings /usr/.attlib/uucp/uucico 
/usr/spool/uucp
uucico
cico.c - euid
BAD UID 
cico.c - uid
BAD UID 
cico-Myname
%.6s

...

cheops 5 % strings /usr/.ucblib/uucp/uucico 
@(#)cico.c
5.3 (Berkeley) 10/3/83
uucico
BAD UID 
%.7s
ENABLED
DEBUG
unknown flag %s
AUDIT
here
%.7s
sys-%s

...
cheops 6 %
Jeess, They look different to me!

Now, let's look at init:

cheops 6 % ls -l /etc/inittab /etc/ttys
-rw-r--r--  1 root         5855 Jul 25 11:37 /etc/inittab
-rw-------  1 root          714 Jul 19 21:02 /etc/ttys

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!
Conversely, I can get Berkeley CAD software, and make install it also.

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.

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.  However, to merge /bin & /usr/{ucb,bin}, you just run into too
many problems.  What would you do with /usr/lib ?  How about programs using
sockets? select? various networking? semaphores? shared memory?

Pyramid succeeded in presenting the user with Either a SVID or 4.2BSD
pure virgin environment.  And the user can switch anytime, at will.  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.

-- 
---------------------------------+--------------------------------------------
| Michael Mc Namara              | Let the words by yours, I'm done with mine.
| UUCP: dual!vecpyr!tflop!mac    | May your life proceed by its own design.
| ARPA: tflop!mac at ames.arpa      |
---------------------------------+--------------------------------------------