km@emory.UUCP (Ken Mandelberg) (01/09/86)
I am trying to do a multi-hop file transfers between a combination of
System V systems, and a single 4.2BSD systems. The problem is that
while the latest release of System V uucp supports multi-hops, 4.2BSD
uucp does not. On the other hand 4.2BSD has uusend for multi-hops,
while System V does not.
In one direction I am lucky. Originating from sys5a, I can say
uucp <path-on-sys5a> sys5b!bsd!<path-on-bsd> which works.
However, I don't know a way to simulate:
uucp <path-on-bsd> sys5b!sys5a!<path-on-sys5a>
I would prefer not to use "mail" for the transfer for a variety
of reasons (some files are binary, some files are large- uuencode
makes them larger, mail may be forwarded at the destination, etc).
Does anyone have a suggestion?
--
Ken Mandelberg
Emory University
Dept of Math and CS
Atlanta, Ga 30322
{akgua,sb1,gatech,decvax}!emory!km USENET
km@emory CSNET
km.emory@csnet-relay ARPANETgnu@hoptoad.uucp (John Gilmore) (01/13/86)
In article <1564@emory.UUCP>, km@emory.UUCP (Ken Mandelberg) writes: > I am trying to do a multi-hop file transfers between a combination of > System V systems, and a single 4.2BSD systems. The problem is that > while the latest release of System V uucp supports multi-hops, 4.2BSD > uucp does not. On the other hand 4.2BSD has uusend for multi-hops, > while System V does not. You just have to treat multi-hop uucp as if it didn't exist. Sorry. Use compress on the sending end, uuencode, and mail to the recipient. If they don't have compress, mail them the source for it too. (Compress is a PD program 10* as fast as compact that gets like 60% squish.) With luck the compress will cancel the uuencode. [Begin political commentary.] It's a shame that ATT won't let BSD adopt stuff from sysV so this could be made to work. (The problem is all the BSD sites that have pre-sysV licenses. ATT won't let them get sysV derived code.) So much for ATT working to unify the unixverses.
kre@munnari.OZ (Robert Elz) (01/13/86)
In article <425@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > It's a shame that ATT won't let BSD adopt stuff from sysV so this could > be made to work. (The problem is all the BSD sites that have pre-sysV > licenses. ATT won't let them get sysV derived code.) So much for ATT > working to unify the unixverses. I don't think that's really the problem - for some time now Berkeley have made it plain that at some future time, a SysV licence would be a requirement for some unknown future unspecified Berkeley release. The problem at the minute is that SysV licences aren't interchangable, AT&T in their infinite wisdom have decided that if you have a 68K Sys V licence (for example) than you cannot be given code derived from a Vax Sys V. This is (I believe) the major hurdle at the minute preventing Berkeley from requiring Sys V licences - which Sys V licence would it be? Of course, that's simple, Berkeley would have to require a Vax Sys V licence, but can you imagine the conversation... Person: "Here's my Sys V licence, signed Berkeley licence (2 copies), and your $$$, can I have a BSD tape please?" Berkeley: "No" Person: "Why?" Berkeley: "Your Sys V licence is for a 68k, not a vax" Person: "But I don't have a Vax, I have a 68K!" Berkeley: "Talk to AT&T... It will cost you another $48,000" This is absurd, rather than unifying the "unixverses", AT&T seem to be specifically diversifying them. Wierd! Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov
honey@down.FUN (Peter Honeyman) (01/14/86)
john gilmore's "political commentary" aside, there is the option of purchasing honey danber, which supports forwarding (although it's incompatible with old system v forwarding (for good reason)). peter
kwan@smeagol.UUCP (Richard Kwan) (01/15/86)
In <1032@munnari.OZ>, Robert Elz presents a scenario, including:
> Berkeley: "Talk to AT&T... It will cost you another $48,000"
IS THIS REALLY THE CASE NOW? I remember a different pricing structure
to license source on an additional machine. But my information is from
the days of System III.
Will someone please set me straight? Perhaps someone from AT&T?
Mail will suffice since this has nothing to do with UUCP.
Rick Kwan
JPLdave@lsuc.UUCP (David Sherman) (01/15/86)
The poster of the question may have realized this anyway, but... You can transfer through a multihop path with the co-operation of only every other site. So, if your (and intervening) UUCPs don't support multihop transfers, and you need to get from here to there via the path here!a!b!c!there, all you need is help from someone on b. You type uucp file a!file Your friend b!user types uucp a!file file and, at some later time, uucp file c!file and your recipient can then type uucp c!file file Dave Sherman The Law Society of Upper Canada Toronto -- here!a!b!c!there!lsuc!dave
csg@pyramid.UUCP (Carl S. Gutekunst) (01/16/86)
In article <1035@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: >The poster of the question may have realized this anyway, but... >You can transfer through a multihop path with the co-operation >of only every other site. Hmmm.... Sounds more like a good way to cut back on UUCP connections.... :-) Copying from me!a!b!c!you with only the cooperation of site B will certainly piss off the administrators at sites A and C since it will leave them with a file eating up space in PUBDIR. (There's no way to remotely rm files, for good reason.) Unless they have a script to clean up PUBDIR periodically, they probably won't find it until they run out of disk space.... -- Carl S. Gutekunst {allegra,cmcl2,decwrl,hplabs,topaz,ut-sally}!pyramid!csg Pyramid Technology Corp, Mountain View, CA +1 415 965 7200
jmc@ptsfa.UUCP (Jerry Carlin) (01/16/86)
In article <647@down.FUN> honey@down.FUN (Peter Honeyman) writes: >john gilmore's "political commentary" aside, there is the option of >purchasing honey danber, which supports forwarding (although it's >incompatible with old system v forwarding (for good reason)). > Having to live with that incompatability every day, I can state that whatever the 'good reason' it is NOT good enough. Note that people upgrading from old System V to Honey-Danber (aka AT&T BNU) will have their multi-hop uucp break unless they upgrade all their machines at the same time. Of course, not all vendors offer Honey-Danber uucp so --gotcha--. One hack around it is to ignore multi-hop uucp and write a separate forwarder that lives on each machine and which works the way mail/rmail works (you would not uucp a!b!c you would then "foo a!b!c" in the same way you now "mail a!b!c"). -- voice= 415 823-2441 uucp={ihnp4,dual,qantel}!ptsfa!jmc
guy@sun.uucp (Guy Harris) (01/17/86)
> Having to live with that incompatability every day, I can state that > whatever the 'good reason' it is NOT good enough. If the reason is a security reason (a lot of the changes in Honey Danber were done for security reasons), it is quite good enough, considering the number of security holes in vanilla UUCP. (I'm sure Peter can tell us more than we wanted to know about this.) > Note that people upgrading from old System V to Honey-Danber (aka AT&T BNU) > will have their multi-hop uucp break unless they upgrade all their machines > at the same time. Of course, not all vendors offer Honey-Danber uucp so > --gotcha--. Not all vendors offer the System V UUCP either, so even if Honey Danber didn't exist there would be no guarantee that UUCP forwarding would work. > One hack around it is to ignore multi-hop uucp and write > a separate forwarder that lives on each machine and which works > the way mail/rmail works (you would not uucp a!b!c you would then > "foo a!b!c" in the same way you now "mail a!b!c"). This was such a good idea that Mark Horton hopped into Larry Wall's DeLorean and invented it several yars ago. It's called "uusend" and comes with 4.xBSD. Of course, *it* only works if all the hosts in the path have "uusend" *and* have their "uux" configured to execute it - and considering that the V7, 4.1BSD, and System III UUCP's lists of "uux"able commands was *compiled in*, it may be difficult to reconfigure some hosts to support it.... Guy Harris
bruce@stride.UUCP (Bruce Robertson) (01/30/86)
In article <1032@munnari.OZ> kre@munnari.OZ (Robert Elz) writes: >Person: "Here's my Sys V licence, signed Berkeley licence (2 copies), >and your $$$, can I have a BSD tape please?" > >Berkeley: "No" > >Person: "Why?" > >Berkeley: "Your Sys V licence is for a 68k, not a vax" > >Person: "But I don't have a Vax, I have a 68K!" > >Berkeley: "Talk to AT&T... It will cost you another $48,000" > This is no joke; we went through this EXACT conversation, except that it turns out it only costs you an additional $16,000 to upgrade your 68k license to include the VAX. ~sigh~ -- Bruce Robertson UUCP: cbosgd!utah-cs!utah-gr!stride!bruce ARPA: stride!bruce@utah-gr.arpa
mats@fortune.UUCP (Mats Wichmann) (02/08/86)
As if more confirmation was needed, you do indeed need the right flavor
of license to get the BSD source. We were lucky - AT&T told me about this
in a conversation with an account rep; I figured since they just came
up with it Berkeley might not have heard about it yet, so I quickly
rushed our order through and received the BSD tape, even though we
had a 68k license only. I can talk about it now because we went ahead
and got the VAX license within a couple of months, so it is all square
(this was at my previous company, by the way, not Fortune).
The point is, AT&T decided that processor families are different for
purposes of code sharing. If you buy a 16000 family (National; I
know they cal it 32000 these days, but s does AT&T with the WE chips..)
you can't give your derived source to somebody with an Intel family
port, and neither of you can get the BSD code which is Vax-derived.
I excerpt the following "Q&A" dialog from the latest AT&T $echo
magazine, which covers the topic:
Question: If I am approached by another licensee to exchange source
code, what are my restrictions?
Answer: Both licensees must be licensed in the same family of
technology (i.e., VAX, 3B, Motorola, etc.), and at the same version
and release level. For example, System V Release 2 Version 1 is
not the same as System V Release 2 Version 2. The company
supplying the source should call the AT&T UNIX Software Sales and
Licensing organization to verify the licensing status of the
recipient's status within the United States and written verification
for all other countries.....(bla, bla, bla).
Notice that this really means that to get BSD you need only to have
something later than 32V (as long as it is for the VAX), since a
later release entitles you to receive source based on an earlier one.
Don't you just love it?
Mats Wichmann
Fortune Systems
{ihnp4,hplabs,dual}!fortune!matsddl@tardis.UUCP (02/13/86)
I don't quite see how requiring an exact match of machine/version/ revision allows you to get and source from an older version. These two statements would seem to be contradictory. Is it something like I can get your source iff: (my machine) == (your machine) && (my version) >= (your version) && (my revision) >= (your revision) ? What if (my version) > (your version) but (my revision) < (your revision) (with (my machine) == (your machine), of course)? Does anyone know the real answer? Shouldn't we all be griping rather loudly to AT&T about this? This doesn't seem to have anything to do with uucp, maybe net.legal? Or net.flame.att? Dan Lanciani ddl@tardis.*
jc@sdcsvax.UUCP (John Cornelius) (02/17/86)
All of this broo ha ha over license is puzzeling. If BSD can only be licensed on a VAX, how does one port to something else? Are there any lawsuits yet? John Cornelius Western Scientific
phil@amdcad.UUCP (Phil Ngai) (02/19/86)
In article <1425@sdcsvax.UUCP> jc@sdcsvax.UUCP (John Cornelius) writes: >All of this broo ha ha over license is puzzeling. If BSD can only be licensed >on a VAX, how does one port to something else? Are there any lawsuits yet? It is not the case that BSD can only be licensed on a VAX. Here's the way it really works. A few years ago, if you bought the source to Unix from ATT, you had the choice of PDP-11 or VAX. Since the machines were so much alike, ATT treated them identically as far as licensing rights. Then microprocessors like the 68000, the 80286, and the WE32000 came out. ATT decided to support them also. Although Unix is more portable than most operating systems, this was still a substantial amount of work. You need a new compiler, assembler, linker, loader, etc. Then you get to do the hard work! As is their right, ATT wants to recover the cost of this (as well as charging what the market will bear). So if you already have VAX source and want the 68000 source to get their software tools, you have to pay an additional $16,000. Or vice-versa. Now let's talk about BSD. BSD is based on ATT source so the BSD license requires an ATT license as a preq. In particular, the BSD code is based on the PDP-11/VAX ATT source. If you have a 68000 license, that does not entitle you to receive VAX source or anything derived from VAX source. If you have VAX source you are free to modify it to run on a 68000. But you will have to write your own software tools. I believe this is what Sun has done. In fact, I suspect many vendors have VAX licenses since they probably started their ports before the different CPU versions of Unix. By the way, did you know that if you pay the right fees to ATT you can get additional CPU source licenses for $1,000 each and object (1-2 users) for $60? But you have to pay $84,000 first. -- Real men don't have answering machines. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com