Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!watmath!clyde!cbosgd!ucbvax!info-vax
From: info-...@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: UUCP
Message-ID: <4834@ucbvax.ARPA>
Date: Thu, 14-Feb-85 16:58:15 EST
Article-I.D.: ucbvax.4834
Posted: Thu Feb 14 16:58:15 1985
Date-Received: Fri, 15-Feb-85 05:35:34 EST
Sender: dae...@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 42
From: Lauren Weinstein <vortex!lau...@RAND-UNIX.ARPA>
First of all, a correction. I had nothing whatever to do with
the design or implementation of Unix UUCP -- so I most definitely
am NOT "largely responsible for UUCP in the first place." I had
nothing whatever to do with it.
My own UUCP work has been based totally on my own original code and
not on Unix UUCP source code in any manner.
I've tried to keep up to date (information-wise) on what's going
on with UUCP in the VMS world. The Hughes UUCP port, I believe,
requires a Unix source license (I'm not sure which Unix version,
however).
Regarding "finishing products" -- I'll tell you all a little secret.
I'm ONE PERSON who has to work very hard (I'm a consultant so I
don't have a "regular" income) to pay the rent and meet day-to-day
expenses. This means that I have to spend most of my time on short-term
projects that can bring me money immediately, and only work on
long-term projects (often with questionable income potential) when
I have some spare time. If I had a staff of slaves, I could probably
get a lot more done. But I don't and this means that some work takes
a very long time and must sometimes be abandoned if it's becoming
obvious that market forces are making the work less valuable.
As for my own VMS UUCP, I've had to shelve it for the time being to
concentrate on work with more immediate potential. I haven't
abandoned it, but I do not have the time to proceed with it right
now. Changes in new VMS OS versions also threaten to complicate
the situation from a technical standpoint. There are other factors,
including logistical and purely practical ones, that have also
made the work much more difficult and forced me to put it on the
backburner.
I am only one person and there's only so much I can do
at any given time. If I've learned one thing, it's to at
least TRY budget my time in an efficient manner. I never again
want to find myself in the sort of financial crunch that
I had happen in the past.
--Lauren--
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!
mit-eddie!godot!harvard!seismo!brl-tgr!tgr!vortex!lau...@rand-unix.ARPA
From: lau...@rand-unix.ARPA
Newsgroups: net.unix
Subject: UUCP and me
Message-ID: <8792@brl-tgr.ARPA>
Date: Thu, 28-Feb-85 17:51:15 EST
Article-I.D.: brl-tgr.8792
Posted: Thu Feb 28 17:51:15 1985
Date-Received: Mon, 4-Mar-85 05:42:10 EST
Sender: n...@brl-tgr.ARPA
Lines: 74
I've warned people about this many times before but I'll do it again.
Those notes that were taken from my Usenix talk about UUCP are essentially
useless. They are of no value. There are two reasons for this.
The first is that I was pressured into giving that talk before I
really understood what was going on, and as such much of what I said
turned out to be incorrect or at the very least highly misleading
in light of my later experiences. It was based on some of my very early
experiments way before I had written even a partially working
private UUCP implementation. That was the last time I let somebody pressure
me into giving a talk before I felt I was really ready, believe me.
The other problem was that the person taking the notes on the talk
did so without any coordination with me, and mixed up my already
inaccurate information in the process. The end result was that
completely useless article in that old ;login.
----
It is important to realize that UUCP isn't really a protocol, it
is an EFFECT. It is a bunch of different programs that happen
to know how to speak to each other. There is no "formal" protocol
in the sense that TCP/IP is a formally specified protocol.
One reason you don't see much about how the protocol works is that
since it is embodied in trade-secret source code, it would be
illicit to read the UUCP source code to figure out the protocol
(and then use or publish that information in non-Unix-licensed environments).
I developed my own knowledge and versions of UUCP completely from the
outside, without any reference to UUCP source code. This turned out
to be a tremendously more difficult task than I had originally
anticipated. It involved almost two years of experiments and
endless experimental versions that "sorta" worked or worked only
with some sites. One of the problems was that I never had any
way to know what I DIDN'T yet know--until one day some new site
would call me and everything would stop working. Then it was
back to the drawing board.
Over a long period of time, mainly by trial and error, I've gotten
to the point where my own versions of UUCP and related programs
(mail, netnews, rdmail, etc.) seem to be compatible with all known
Unix UUCP's. I've even got 822 domain support built into my latest
versions. But when people complain that it has taken me so long
to make these available (particularly the MSDOS version) I can
only point out that it all (from the communications level to the
problems of incompatible filenames and file formats) was a LOT
of work and that I had to do everything on my own time without
any outside support.
Once the various versions of UUCP have settled down again,
I'll try get back to writing up a "formal" protocol spec, which
would include communications info, file naming and handling,
timing constraints (this turns out to be much more critical
than one would think, especially on small machines) and all the
other stuff I've learned over the last couple of years. Since
all of this knowledge was gained without looking at Unix UUCP source,
I'll be happy to share it once I can put it into a coherent
framework and I finally have some spare time.
----
Frankly, if I had all of this work to do all over again, I probably
wouldn't have started. It was simply too much work and ate a substantial
chunk out of my life. What would I have done instead? I'd have used an
automated Kermit for everything. Which is what I currently recommend to
people trying to get fancy file transfer programs going with new
machines. I am big Kermit fan.
--Lauren--
P.S. If you have any questions, please contact me directly.
I'll be happy to help. But these poor lists are already
overflowing! Let's try give them a break.
--LW--
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!
mit-eddie!godot!harvard!seismo!brl-tgr!tgr!vortex!lau...@rand-unix.ARPA
From: lau...@rand-unix.ARPA
Newsgroups: net.micro.cpm
Subject: UUCP
Message-ID: <8797@brl-tgr.ARPA>
Date: Thu, 28-Feb-85 21:02:31 EST
Article-I.D.: brl-tgr.8797
Posted: Thu Feb 28 21:02:31 1985
Date-Received: Mon, 4-Mar-85 05:44:33 EST
Sender: n...@brl-tgr.ARPA
Lines: 67
Since it is pretty widely known that I have my own versions of
UUCP that are unrelated to AT&T code, I thought I'd comment
on this general topic now to head off the direct mail that usually
gets sent to me after such queries.
---
It is important to realize that UUCP isn't really a protocol, it
is an EFFECT. It is a bunch of different programs that happen
to know how to speak to each other. There is no "formal" protocol
in the sense that TCP/IP is a formally specified protocol.
One reason you don't see much about how the protocol works is that
since it is embodied in trade-secret source code, it would be
illicit to read the UUCP source code to figure out the protocol
(and then use or publish that information in non-Unix-licensed environments).
I developed my own knowledge and versions of UUCP completely from the
outside, without any reference to UUCP source code. This turned out
to be a tremendously more difficult task than I had originally
anticipated. It involved almost two years of experiments and
endless experimental versions that "sorta" worked or worked only
with some sites. One of the problems was that I never had any
way to know what I DIDN'T yet know--until one day some new site
would call me and everything would stop working. Then it was
back to the drawing board.
Over a long period of time, mainly by trial and error, I've gotten
to the point where my own versions of UUCP and related programs
(mail, netnews, rdmail, etc.) seem to be compatible with all known
Unix UUCP's. I've even got 822 domain support built into my latest
versions. But when people complain that it has taken me so long
to make these available (particularly the MSDOS version) I can
only point out that it all (from the communications level to the
problems of incompatible filenames and file formats) was a LOT
of work and that I had to do everything on my own time without
any outside support. I'll be releasing my MSDOS uucp/mail/netnews/
remote access package, including domain support, as a complete package.
For people who don't need all that stuff (and it is a LOT of stuff)
I'll be happy to discuss unbundling UUCP itself or other parts
of the package if people really want it.
Once the various versions of UUCP have settled down again,
I'll try get back to writing up a "formal" protocol spec, which
would include communications info, file naming and handling,
timing constraints (this turns out to be much more critical
than one would think, especially on small machines) and all the
other stuff I've learned over the last couple of years. Since
all of this knowledge was gained without looking at Unix UUCP source,
I'll be happy to share it once I can put it into a coherent
framework and I finally have some spare time.
----
Frankly, if I had all of this work to do all over again, I probably
wouldn't have started. It was simply too much work and ate a substantial
chunk out of my life. What would I have done instead? I'd have used an
automated Kermit for everything. Which is what I currently recommend to
people trying to get fancy file transfer programs going with new
machines. I am big Kermit fan.
--Lauren--
P.S. If you have any questions, please contact me directly.
I'll be happy to help. But these poor lists are already
overflowing! Let's try give them a break.
--LW--