UUCP USERFILE
Robert Bradbury
>
> Look, I don't want to get huffy, but as I stated earlier, the problem
> IS NOT with different logins with the same UID! (And, I suggest that
> looking at the System V UUCP code is probably not going to help in
> understanding DEC's UUCP code.)
>
I don't want to get huffy either (:-)), but why do vendors (DEC,PYRAMID and
HCR come to mind) continue to distribute the old V7 UUCP code instead of
new AT&T uucp? Is there some licensing issue I'm unaware of or a desire
not to disturb the installed (deficient) program base?
We use the new uucp on our 3B2's and the new Userfile format allows much more
flexibility and eliminates some of the voodo involved with the old USERFILE.
Is everyone waiting for Berkeley to migrate to the new uucp?
Are uucp standards documented in the SVID? Should they be?
--
Robert Bradbury
Oracle Corporation
(206) 364-1442 {ihnp4!mhuxd,hplabs}!oracle!bradbury
Charles Hedrick
work done on it since V7. I don't doubt that these things could be merged
with whatever ATT has done, but our UUCP usage depends heavily on the
ability to make connections over TCP, which is a feature of newer Berkeley
UUCP's. We have only a few machines that make dialup connections. The rest
of our local machines forward everything through them, making their
connection to the relay machine via Ethernet. UUCP over the Arpanet or
CSnet can also be very useful in some cases.
As for vendor policy, there is a philosophical issue as to what you should
get when you buy 4.2 from a vendor. When I buy 4.2, I expect my users and
staff to be able to use 4.2 documentation to deal with the system. We have
a number of different machines. We do not want each machine to have a
random combination of features chosen from 4.2, 4.3, SVr2, and SVr3. 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. We use the 4.2 UUCP, so I can't tell you much
about their System V UUCP. But based on the results of "what", it looks
like a fairly recent (i.e. release 2 or release 2.2) System V version.
By the way, is the new Userfile a feature of SVr2, SVr3, or HoneyDanber
UUCP? SVr3 hasn't had time to make it out through vendors yet, and the
vendors I have talked to aren't yet sure which of the extra-cost ATT stuff
such as HoneyDanber their users are really going to want.
There may indeed be licensing problems preventing Berkeley from using System
V UUCP. I should let people who know more about this answer that question.
My only talk with someone at a managerial level in System V left the
impression that ATT had no interest in cooperating with Berkeley. (To be
fair, I have since heard rumors that are far more encouraging.)
Guy Harris
> documentation to deal with the system. We have a number of different
> machines. We do not want each machine to have a random combination of
> features chosen from 4.2, 4.3, SVr2, and SVr3.
As time goes on, you're likely to be more and more often disappointed.
There's really no point in, say, offering the old obsolete V7/4.2BSD version
of the Bourne shell with a system.
> 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. (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.) 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.
> By the way, is the new Userfile a feature of SVr2, SVr3, or HoneyDanber
> UUCP?
HoneyDanber.
> SVr3 hasn't had time to make it out through vendors yet, and the
> vendors I have talked to aren't yet sure which of the extra-cost ATT stuff
> such as HoneyDanber their users are really going to want.
From what I've read, S5R3 is already extra-cost. I think HoneyDanber is now
the standard version of UUCP in S5R3.
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com (or g...@sun.arpa)
Charles Hedrick
complete 4.2 and System V universes. I have no idea whether it is
possible or not. I can only say that they have done it. Their kernel
has a full set of 4.2 and SV system calls. This is not a case of an
emulation package being done at the library level. By and large they
have a full set of 4.2 and SV utilities. There are a few cases where
this is not true. E.g. the compilers are usually the same (but the
libraries are not, of course. So the compilers produce real ATT
programs on the ATT side and real UCB programs on the UCB site.)
Also, you get a real UCB C shell even on the ATT side. (This is in
some sense a violation of their design philosophy. Presumably they
decided that supplying a C shell where ^Z is intentionally disabled is
carrying purity too far, particularly since csh isn't really part of
SV anyway. There are separate Bourne shells.) But most things come
in both Berkeley and ATT flavors, even things like ps and who. (They
actually have separate wtmp's and utmp's, both of which contain data
for all of the jobs.) There are separate line printer spoolers (which
can run at the same time, and I think may even be able to share the
same printer), UUCP's, and mail programs. Presumably one could have a
site that had two different UUCP site names, going to the two
universes. My guess is that almost all sites run one or the other
version of UUCP.
I don't know the exact reason for doing all of this, but I can guess.
There are certainly commercial accounts who don't want any of this
Berkeley stuff. There are Universities who have no interest in ATT.
There are also middle of the road places that would like to be able to
choose a particular mix of UCB and ATT features that is appropriate
for their site, and maybe develop programs for both Berkeley and ATT
Unix with some hope that they will really run on each kind of
implementation. It is also possible to mix things, so that you can
use Berkeley job control in a program that uses SV locking, etc.
As for init, yes there are two inits. Of course you don't run them
both at once. But the system administrator gets to choose which one
he wants. They each read the set of startup and configuration files
that you would expect for that version. init and login are the
primary places where you can't have both universes active at once.
However the logins each know how to deal with both universes. They
can each start jobs in either universe. (The user can choose which he
wants.)
Carl S. Gutekunst
an utter fool of myself; in my personal apology to Guy I mentioned that he
should give me some UUCP questions 'cause those I can handle. Thanks Guy! :-)]
Just some points of information, more for other netters than for Guy or Chuck
(since they already know most of this stuff):
>> 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.
But that is exactly what we do. We are currently shipping 4.3bsd UUCP in the
Berkeley universe, and SVR2 UUCP in the AT&T universe. In a future release
we'll be supporting three: Berkeley, AT&T SVR2, and HDB.
Most customers pick one of the three, and stick with it. Using more than one
at a time is difficult because they have different queueing conventions; they
also cannot share the same control files. But you can have the AT&T uucico
service requests issued by the AT&T uux and uucp, the Berkeley uucico service
requests from the Berkeley uux and uucp, etc. With careful use of symbolic
links you can also get them to use the same dialout modems.
>(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.)
Yes and no. Yes we have two versions of init, one for Berkeley and one for
AT&T. And yes, they *both* know how to read both /etc/ttys and /etc/inittab,
and do them correctly. (Within limits. When setting the baud, for example, the
ucb init uses /etc/gettytab, and the att init uses /etc/inittab.) But no, you
can't use both simultaneously; you have to chose one or the other.
>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.
Sounds like I'm doing it the wrong way, then; sorry about that (seriously).
I'm holding to the dual-port philosophy, which means both versions of UUCP
are available for the customer to chose which he prefers. I have had a few
customer requests for a hybrid uucico that understands both Berkeley and SVR2
queueing, and for a super-uucp that did everything of both. But I don't think
it's worth the effort to write it, especially with HDB becoming available.
>> By the way, is the new Userfile a feature of SVr2, SVr3, or HoneyDanber
>> UUCP?
>
>HoneyDanber.
Which USERFILE feature? I thought the original question was about the login
name check; it was added in SVR2. (HDB doesn't have USERFILE; it's equivalent
is "Permissions" and it bears no resemblance to USERFILE at all.)
This new feature also wasn't documented anywhere. The explanation I got from
AT&T was that M.E. Lesk's original V7 document states that listing of all UUCP
logins in USERFILE is mandatory, and that all AT&T was doing was implementing
what the specification had required all along. The kicker, though, was that up
through SVR1 USERFILE was limited to 20 entries; very few sites could have
listed all of their logins! Now they've limited it to 100, which is still
probably not enough....
>I think HoneyDanber is now the standard version of UUCP in S5R3.
Correct. The current 3B release of SVR2 also includes HDB as standard. (Both
are woefully lacking in transition tools. *SIGH*) The S5R3 HDB also has a new
'e' protocol that uses TLI on streams, a small hack that is trumpted all over
the SVR3 promotional literature. I'd be curious to know who wrote it since it
doesn't look like Peter & company's work. (It's obvious from the labels that
the 'e' originally meant Ethernet.... :-))
<csg>
Carl S. Gutekunst
>I don't want to get huffy either (:-)), but why do vendors (DEC,PYRAMID and
>HCR come to mind) continue to distribute the old V7 UUCP code instead of
>new AT&T uucp? Is there some licensing issue I'm unaware of or a desire
>not to disturb the installed (deficient) program base?
By "new AT&T uucp" do you mean HoneyDanBer? Up until System VR2.4, it has been
an extra cost item, over an above the stock UUCP that comes with SVR2. HDB's
internal structure is also incompatible with the v7-derived UUCPs, and AT&T
has not bothered to provide transition aids, so there's been good reason to
not disturb the installed base.
And who says the installed base is deficient? Practically no one ships plain
V7 UUCP any more; Berkeley in particular has enhanced it a *LOT* with capabil-
ities like X.25 PAD and TCP/IP, and multiple dialer support. (See my previous
posting about the current versions Pyramid is shipping.)
However, now that AT&T is providing HDB standard, you'll see a lot more
vendors supporting it. It has a *lot* to offer in security, reliability,
friendliness, and maintainability.
<csg>
Sam Lok
>
>By the way, is the new Userfile a feature of SVr2, SVr3, or HoneyDanber
>UUCP? SVr3 hasn't had time to make it out through vendors yet, and the
>vendors I have talked to aren't yet sure which of the extra-cost ATT stuff
>such as HoneyDanber their users are really going to want.
>
Correct me if I am wrong, folks. But there is no USERFILE in SVR2 UUCP.
I beleive we are ruuning HoneyDanber on our SVR2 3B2/400, and there is
a Permissions file instead of USERFILE. The Permissions file provides
much more flexiblity than earlier verions UUCP's USERFILE.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sam Lok {ihnp4,dual,qantel}!ptsfa!ssl
Guy Harris
> Berkeley universe, and SVR2 UUCP in the AT&T universe. In a future release
> we'll be supporting three: Berkeley, AT&T SVR2, and HDB.
I'm certain that keeps the developers busy. It also means more pain for
tech support people; they have to ask which version of UUCP the customer has
chosen to use. Are you *sure* this complication was worthwhile?
> Most customers pick one of the three, and stick with it. Using more than one
> at a time is difficult because they have different queueing conventions;
> they also cannot share the same control files. But you can have the AT&T
> uucico service requests issued by the AT&T uux and uucp, the Berkeley
> uucico service requests from the Berkeley uux and uucp, etc. With careful
> use of symbolic links you can also get them to use the same dialout modems.
Exactly. You can't run them both at the same time, pretending that your
system is all things to all people, without some pain (user A makes a
request to send something across the country using one universe's UUCP, and
then user B makes a request to send something across the country using the
other universe's UUCP - you now have to make *two* phone calls where one
would suffice). How much expertise is required to make this "careful use of
symbolic links"? You've also increased the administrative hassles (the
system administrator must now keep track of two - or three - UUCPs at once),
and they have to be familiar with more than one version anyway.
At this point, UUCP administration isn't a job for the timid *anyway*; it
sounds like you'd have been better off picking one version and just having
different versions of the user commands.
> Yes and no. Yes we have two versions of init, one for Berkeley and one for
> AT&T. And yes, they *both* know how to read both /etc/ttys and /etc/inittab,
> and do them correctly. (Within limits. When setting the baud, for example,
> the ucb init uses /etc/gettytab, and the att init uses /etc/inittab.) But
> no, you can't use both simultaneously; you have to chose one or the other.
Again, my point exactly. You don't have two universes; you have one
universe (the one from which "init" comes) and part of another.
Fortunately, the signal to tell "init" to read its control file happens to
be the same in both versions of "init" (SIGHUP), but now any program that
enables and disables ports either has to have its port in the file from the
version it knows about (which means a program that knows about the other
version can't use that port) or has to look at both files (in which case it
has to be modified to know that there are two such files).
The administrator would now have to know about this quirk.
> Sounds like I'm doing it the wrong way, then; sorry about that (seriously).
> I'm holding to the dual-port philosophy, which means both versions of UUCP
> are available for the customer to chose which he prefers. I have had a few
> customer requests for a hybrid uucico that understands both Berkeley and
> SVR2 queueing, and for a super-uucp that did everything of both. But I
> don't think it's worth the effort to write it, especially with HDB becoming
> available.
With HDB becoming available, the logical choice is to ditch both V7 UUCP
descendants (although HDB is also arguably a descendant of the V7 version)
and provide one version, possibly after putting in a few bits of #ifdeffed
code so that you can build two versions of "uucp", "uux", etc. from *one*
source that provide compatible supersets of the 4.2 and S5 commands. You
now have only *one* queueing mechanism, *one* protection mechanism, etc.
now, so you don't have to have courses for all three, and maintainers for
all three, and tech support questions about which of the three you're using,
etc..
Besides, which customer gets to choose? The individual user may or may not
get a choice, depending on whether the administrator wants the headaches of
managing more than one version in parallel (see above). The administrator
gets to choose, but any UUCP administrator who can be trusted with managing
the queues him- or herself can be trusted to adapt to whatever queueing
mechanism you provide.
> >> By the way, is the new Userfile a feature of SVr2, SVr3, or HoneyDanber
> >> UUCP?
> >
> >HoneyDanber.
>
> Which USERFILE feature? I thought the original question was about the login
> name check; it was added in SVR2. (HDB doesn't have USERFILE; it's
> equivalent is "Permissions" and it bears no resemblance to USERFILE at all.)
Since they said "new Userfile", I'd assumed they meant a new file format;
they may have been thinking of the "Permissions" file.
> The S5R3 HDB also has a new 'e' protocol that uses TLI on streams, a small
> hack that is trumpted all over the SVR3 promotional literature. I'd be
> curious to know who wrote it since it doesn't look like Peter & company's
> work.
Peter & company's "UUCP on top of a network" protocol *was* called the 'e'
protocol, and like the S5R3 one it writes the file size as a printable ASCII
string first. I suspect it is the original one, modified as necessary to
use TLI.
Guy Harris
> complete 4.2 and System V universes. I have no idea whether it is
> possible or not. I can only say that they have done it.
No, they haven't, if by "complete" you mean one system can look like it has
all of both versions. As you point out later, you have to choose one
version of "init", "login", etc. and stick with it. (Also note that, as was
mentioned somewhere, if you want quotas the "chown" call becomes privileged.)
> Their kernel has a full set of 4.2 and SV system calls. This is not a
> case of an emulation package being done at the library level.
How it's done is totally irrelevant. In many cases there's no need to
provide them both as system calls; add a "old unreliable V7 signal
mechanism" bit to the "sv_flags" field of the 4.3BSD signal mechanism, and
you can implement *both* flavors of "signal" on top of *one* version of
"sigvec".
> By and large they have a full set of 4.2 and SV utilities.
Nothing special about that. Given a C library supporting the library
routines of both versions, 99% of the utilities can be built under either
version.
> There are a few cases where this is not true. E.g. the compilers are
> usually the same
Again, it's not "complete". Somebody has to make a choice - the vendor, in
this case. AT&T made the same choice when they switched from the old V7-ish
object file format to COFF; they provided conversion tools but you don't get
old-style versions of "as", "ld", etc. with S5.
> But most things come in both Berkeley and ATT flavors, even things like
> ps
Believe me, doing "ps" ain't that hard. You aren't going to run the vanilla
S5 "ps" on a kernel which is a modified 4.2BSD kernel, but you can change
the user interface of the 4.2BSD one to look like the S5 one; it's not that
hard.
> and who. (They actually have separate wtmp's and utmp's, both of which
> contain data for all of the jobs.)
Unless, of course, they get out of sync; another potential source of
headaches.
> There are separate line printer spoolers (which can run at the same time,
> and I think may even be able to share the same printer),
Again, an administrative headache. (They'd better be able to share the same
printer; painting "S5 only" and "4.2BSD only" on printers would be
unacceptable.) If they share the same printer, what happens when N jobs
from one universe are ahead of your job from the other universe? Does a
listing of the queue show both jobs? If not, I for one would be rather
annoyed; when I ask for a queue listing I expect it to give me a reasonable
idea of when I can expect my job to be printed. Since the administrator
would have to know about *both* spoolers anyway, why not just provide one
spooler, or two spoolers, capable of supporting *requests* from both command
sets? The users won't know the difference (their view of the spooler is just
"what commands do I type to make things happen" and "what do those commands
type back at me").
> UUCP's, and mail programs. Presumably one could have a
> site that had two different UUCP site names, going to the two
> universes. My guess is that almost all sites run one or the other
> version of UUCP.
I suspect any alternative would be too unwieldy.
As for "mail programs", mail *readers* isn't a problem. One would hope that
both flavors of "/bin/mail" and both flavors of "Mail" (one called "Mail",
one called "mailx") go through the same *delivery* mechanism; if aliases in
"/usr/lib/aliases" are only available in the 4.2BSD universe, that's bound
to cause a bit of confusion.
> I don't know the exact reason for doing all of this, but I can guess.
> There are certainly commercial accounts who don't want any of this
> Berkeley stuff. There are Universities who have no interest in ATT.
(If they have no interest in ATT, why are they running UNIX? *ALL* UNIXes
come ultimately from AT&T; 4.2BSD is a derivative of an AT&T UNIX. Could we
please use "4.2BSD" and "System V" when talking about these two descendants
of AT&T's Research UNIX, instead of using misleading terms like UCB and ATT?)
There are ways of providing this that don't require the full gore of a dual
port. You can sell and support two different UNIX ports; some people do
this, although it's a major support headache. You can provide one kernel
that supports both, and a "common superset" command set along with variants
for the relatively few that are irreconcilably incompatible.
> There are also middle of the road places that would like to be able to
> choose a particular mix of UCB and ATT features that is appropriate
> for their site, and maybe develop programs for both Berkeley and ATT
> Unix with some hope that they will really run on each kind of
> implementation. It is also possible to mix things, so that you can
> use Berkeley job control in a program that uses SV locking, etc.
Again, that's not hard; you just provide library routines from both
environments - and interfaces to the system calls from both environments -
in the C libraries from both environments. Of course, you can't call the
system calls for manipulating process groups "setpgrp" and "getpgrp" in the
S5 environment, but you can certainly provide them.
The point is that you *can't* hide the differences. You *have* to choose
one version of "init", for instance. And you either have to choose one
version of UUCP or have the administrator support both. It's not clear that
a 99% solution is enough better than a 97% solution to justify all the extra
gore needed to get that last 2%; the law of diminishing returns takes over.
There ain't no 100% solution.
j...@mtune.uucp
>>I think HoneyDanber is now the standard version of UUCP in S5R3.
>
>Correct. The current 3B release of SVR2 also includes HDB as standard. (Both
>are woefully lacking in transition tools. *SIGH*) The S5R3 HDB also has a new
>'e' protocol that uses TLI on streams, a small hack that is trumpted all over
>the SVR3 promotional literature. I'd be curious to know who wrote it since it
>doesn't look like Peter & company's work. (It's obvious from the labels that
>the 'e' originally meant Ethernet.... :-))
Correct. HDB is in SVR3. Actually a development of HDB uucp, with some
extra features, like the ability to split up Systems/Devices/Dialers,
and being able to specify protocols in Devices, which is the correct
place to do such things.
I think that Carl has it the wrong way round - TLI can use proto 'e',
and TLI is (in SVR3) streams-based. Fortunately I haven't seen the
SVR3 promo blurb.
I tend to agree that 'e' originally meant Ethernet, since 'e' protocol
was originally only included if the system was running UNET. Of
course, it could mean 'express' or 'extra' or enything :-). But surely
the 'e' protocol pre-dates HDB, and at least some sites are offering
it - bellcore for example. I'm sure they only mean to use it over
their X.25 links, but they do offer it if you call them.
BTW proto 'e' is *fast*, running over ISN and STARLAN on UNIX PC's I
get the following results:
9600 baud/proto g: ~750 chars per second
STARLAN/proto g: ~1700 chars per second
STARLAN/proto e: ~26000 chars per second (yes, thousand)
That's from memory - if I remembered wrong then I'll post a
retraction.
--
Jonathan Clark
[NAC,attmail]!mtune!jhc
My walk has become rather more silly lately.
Michael McNamara
(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
> g...@sun.com (or g...@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!m...@ames.arpa |
---------------------------------+--------------------------------------------
Jim Hutchison
Yet another consideration is the fact that you can write code that is portable
between the two "universes" and test this fact immediately, without 2 machines.
You can also do (pardon sudden relegious urge :-) work in the universe you
prefer for the vile universe (the one you may feel some disdain for). Being
spoiled by unclean but useful job control and such does not make me not want
to use things like streams and shared memory.
Yes, I realize pyramids don't have streams, but its the concept! Working in an
environment different from your test environment and being on the same machine.
Like sitting on a sun doing ms-dos work via cross-compiler, but without
having to change machines (or even have 2 machines).
--
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: Hu...@sdcsvax.ucsd.edu
"When you are going to die, a wombat is better than no company at all." -RZ
Mark Wallen
to implement two complete sets of utilities (i.e., 4.2 ones and
sysV ones). The first is the porting cost; if you REALLY have
a sysV system, why screw around with a 4.2 utility? Just bring
up the sysV one. And visa versa. The second is a little
recursive, but: what better way to test a sysV port that to bring
up (by simply compiling) it's idiosyncratic utilites (e.g., uucp);
if they work, you have a sysV port. If not, ???
Mark Wallen
UC San Diego
Guy Harris
> I beleive we are ruuning HoneyDanber on our SVR2 3B2/400, and there is
> a Permissions file instead of USERFILE.
The term "SVR2 UUCP", then, doesn't have a unique referent. The UUCP
distributed with SVR2 for the VAX (both Version 2 - the paged one - and
the one that isn't Version 2) is not HoneyDanBer and has a USERFILE.
Henry Spencer
No. Yes.
--
EDEC: Stupidly non-standard
brain-damaged incompatible Henry Spencer @ U of Toronto Zoology
proprietary protocol used. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
Brandon Allbery
Quoted from <5...@pyramid.UUCP> ["Re: UUCP USERFILE"], by c...@pyramid.UUCP...
+---------------
| >(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.)
|
| Yes and no. Yes we have two versions of init, one for Berkeley and one for
| AT&T. And yes, they *both* know how to read both /etc/ttys and /etc/inittab,
| and do them correctly. (Within limits. When setting the baud, for example, the
| ucb init uses /etc/gettytab, and the att init uses /etc/inittab.) But no, you
| can't use both simultaneously; you have to chose one or the other.
+---------------
That must be confusing. What of getty? One /etc/gettytab, one
/etc/gettydefs. Do you have to specify which universe a port runs in, then
change the correct getty initialization file?
++Brandon
--
---------------- /--/ Brandon S. Allbery UUCP: decvax!cwruecmp!
/ / /|\/ Tridelta Industries, Inc. ncoast!tdi2!brandon
---- -------- /-++ 7350 Corporate Blvd. PHONE: +1 216 974 9210
/ / /---, ---- Mentor, Ohio 44060 SYSOP: UNaXcess/ncoast
/ / / / / / -- HOME -- (216) 781-6201 24 hrs.
/ / / / / / 6615 Center St. Apt. A1-105 ARPA: ncoast!allbery%
---- -----~ ---- Mentor, Ohio 44060-4101 case.CSNET@csnet-relay
Bob Halloran
>In article <5...@pyramid.UUCP> c...@pyramid.UUCP (Carl S. Gutekunst) writes:
>>>I think HoneyDanber is now the standard version of UUCP in S5R3.
>>
>>Correct. The current 3B release of SVR2 also includes HDB as standard. (Both
>>are woefully lacking in transition tools. *SIGH*) The S5R3 HDB also has a new
>>'e' protocol that uses TLI on streams, a small hack that is trumpted all over
>>the SVR3 promotional literature. I'd be curious to know who wrote it since it
>>doesn't look like Peter & company's work. (It's obvious from the labels that
>>the 'e' originally meant Ethernet.... :-))
>
>was originally only included if the system was running UNET. Of
>course, it could mean 'express' or 'extra' or enything :-). But surely
>the 'e' protocol pre-dates HDB, and at least some sites are offering
>it - bellcore for example. I'm sure they only mean to use it over
>their X.25 links, but they do offer it if you call them.
Actually, I believe it means 'error-free'; it's made for use over a
channel that does its own error handling, hence the radically improved
throughput you achieved, since no error checking/correction was being
done in the software (your results edited out on this followup).
There is also an 'x' protocol module specifically for X.25 links.
Bob Halloran, Consultant
=========================================================================
UUCP: topaz!caip!unirot!halloran DDD: (201)251-7514
CSNet/ARPA: unirot!hall...@caip.rutgers.edu ATTmail: RHALLORAN
USPS: 19 Culver Ct, Old Bridge NJ 08857
Disclaimer: I speak for myself.
Quote: "History is made at night. Character is what you are in the Dark." -
Dr. Lizardo/John Whorfin, "Buckaroo Banzai"
Guy Harris
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.
Ben Cranston
> Yes, I realize pyramids don't have streams, but its the concept! Working in
> an environment different from your test environment and being on the same
> machine.
Hmm, sort of like doing your compiles under CMS and then firing up an MVS in
a virtual machine to test them? :-)
--
umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92
umd2.BITNET "via HASP with RSCS"
Jonathan Clark
proto "e"'s name is indeed given as "error-free" in the source. From a very
brief look I was unable to determine the exact differences between "e" and
"x" protocols, except that there are more DEBUG statements in "e" and more
fiddling with timeouts in "x". "x" is given as X.25. Certainly the sources
are *very* similar.
I think that "x" is meant for use over bursty, packetizing X.25 links and
"e" over non-bursty non-packetizing links but I don't really know.