[3247] in Release_7.7_team
Re: Dealing with Linux Athena and restricted packages.
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Apr 26 16:49:06 2002
From: Greg Hudson <ghudson@MIT.EDU>
To: Bill Cattey <wdc@mit.edu>
Cc: release-team@mit.edu
In-Reply-To: <1019851623.23181.24.camel@tokata.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 26 Apr 2002 16:48:58 -0400
Message-Id: <1019854138.5738.16.camel@error-messages.mit.edu>
Mime-Version: 1.0
I don't think we can get rid of all the restricted packages. Some
options for dealing with those we can't get rid of:
* Remove the restriction on the binary packages, reasoning that no one
is likely to complain. (IBM no longer cares about AFS and presumably
wouldn't care about pre-OpenAFS vos sources anyway; it's unclear whether
Adobe would care about an old version of Transcript; the synctree author
mostly just didn't want his reputation damaged by what Stan did to his
source code.)
* Provide an install option where people can use their Kerberos
password to get tokens before reading the RPMs.
* Provide an install option where the restricted packages are locally
removed.
On Fri, 2002-04-26 at 16:07, Bill Cattey wrote:
> 1. Eliminate Transcript, the proprietary voldump (in favor of
> OpenAFS version, I expect), and the Motif libraries from the Athena
> Linux install.
Transcript provides the popular "enscript" binary as well as some useful
if less popular binaries like psnup and pslpr. It also dumps a bunch of
files into /usr/athena/share/ps whose purpose I never really understood
(I can ask bert, who might remember). There is a free replacement for
enscript, but I don't know about the rest.
voldump is a modified version of "vos dump" which can dump a volume
without talking to the VLDB. Garry says he never uses it, but Jonathon
might still care about it. We could certainly replace it with a free
version based on OpenAFS source, but it would be actual work.
third/motif provides mwm on Linux. We can't get rid of that for four or
five years. I also imagine some small number of customers would be
unhappy about the libraries going away.
> 3. Begin coding a synctree replacement.
A long time ago I worked on this; the leavings are in
~ghudson/projects/tsync. My idea was to:
1. Provide a free replacement for synctree (so it had to do what
synctree does).
2. Provide a reasonable replacement for track (so it had to support
statfiles).
3. Solve the problem that tracking /os and then tracking /srvd would
wind up copying and re-copying files which existed in both places.
I was going to solve this by providing multiple source
specifications, where later sources would override earlier ones.
Since then, goal #3 has become unimportant, though goals 1 and 2 remain
valid. What I found during the implementation was that the operation of
"update a single file" is irritatingly complicated, and that's where I
lost motivation.
At any rate, we could either finish that work (simplifying things by
eliminating goal #3 and perhaps goal #2), or we could inventory our uses
of synctree and see if they can't all be switched over to rsync or some
other standard tool.
> I remember people around the table discussing free Athena worrying that
> unrestricted deployment of Linux was going to be a big problem because
> we could expect so many more Linux users than Solaris users. More than
> a year into it, I've measured equal numbers of Suns and Linux boxes.
> Still, if we make the easy-to-use installer available, the number of
> Linux Athena systems may at long last take off.
I don't think our current installer provides anything which SIPB hasn't
provided more or less since the start.
