chris@umcp-cs.UUCP (Chris Torek) (07/04/86)
In article <121@radha.UUCP> sanand@radha.UUCP (Sanand Patel) writes: >As an aside, I don't see how uucp *could* get the login name with >out searching /etc/passwd for the current UID. The only other (very >unreliable) way is to find the major/minor of standard-input and search >/dev and then search the 'who' file (utmp?). I *don't think* DEC would >do this. It is not unreliable, and in fact is rather common. There is a C library routine, getlogin(), to do this. Incidentally (in re the recent commotion in net.bugs.4bsd), this defeats the effect of `su', but not that of `rlogin'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
bradbury@oracle.UUCP (Robert Bradbury) (07/26/86)
In article <976@decuac.DEC.COM>, avolio@decuac.UUCP writes: > > 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
hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (07/28/86)
I assume you aren't serious about V7 UUCP? Berkeley's UUCP has had a lot of 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@sun.uucp (Guy Harris) (07/28/86)
> 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. 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 guy@sun.com (or guy@sun.arpa)
csg@pyramid.UUCP (Carl S. Gutekunst) (07/29/86)
[In a previous followup to one of Guy's postings (ranlib on a Pyramid), I made 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>
csg@pyramid.UUCP (Carl S. Gutekunst) (07/29/86)
In article <459@oracle.UUCP> bradbury@oracle.UUCP (Robert Bradbury) writes: >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>
ssl@ptsfa.UUCP (Sam Lok) (07/29/86)
In article <5431@topaz.RUTGERS.EDU> hedrick@topaz.RUTGERS.EDU (Charles Hedrick) writes: > >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@sun.uucp (Guy Harris) (07/29/86)
> 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. 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 {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
mac@tflop.UUCP (Michael McNamara) (07/30/86)
In article <5561@sun.uucp> guy@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@sun.com (or guy@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@ames.arpa | ---------------------------------+--------------------------------------------
guy@sun.uucp (Guy Harris) (07/30/86)
> 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 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. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
henry@utzoo.UUCP (Henry Spencer) (07/31/86)
> Are uucp standards documented in the SVID? Should they be?
No. Yes.
--
EDEC: Stupidly non-standard
brain-damaged incompatible Henry Spencer @ U of Toronto Zoology
proprietary protocol used. {allegra,ihnp4,decvax,pyramid}!utzoo!henryguy@sun.uucp (Guy Harris) (08/01/86)
> 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@sun.com (or guy@sun.arpa)