[9] in Layered Athena
comments
daemon@ATHENA.MIT.EDU (Joe Harrington)
Wed Nov 11 12:52:14 1992
Date: Wed, 11 Nov 92 12:51:49 -0500
From: jh@oobleck.mit.edu (Joe Harrington)
To: layered-athena@MIT.EDU
Cc: jh@MIT.EDU
Reply-To: jh@MIT.EDU
it's gratifying to see that the years and millions of dollars spent on
Athena research will finally come back to the MIT community's own
computers in ways that are useful and under our control. i hope you
get the monetary and personnel support from MIT and I/S to carry this
project through meaningfully, and keep it going as a basic service.
some comments:
1. athena must act as any other third party. take this attitude and
you will win a lot. this will be tough, because you will have to keep
up with a lot of non-convergent development on various vendors'
platforms.
2. expect that doing automatic updates of partly-layered research
machines, potentially hacked by their owners, will be a nightmare and
that few if any people will want it. they'll either go whole-hog and
make their machines be fully athena workstations, or they'll want to
control what and when they get stuff. few will want to control what
but not control when. make the autoconfig database a low-priority
item, to be dealt with after you get the actual subsets defined and
working.
3. different vendors' kernels and operating systems will need
different amounts of enhancement from athena. as an example, some
machines like NeXTs don't have X, while others do. you can't just add
X to every machine that already has it because
a. it takes up too much space to have it twice
b. there are extensions in many vendors' implementations that
you might not be able to get sources to, or even be
allowed to redistribute (e.g., DEC's 3D hardware and
display postscript).
c. users may prefer to have their OS vendor's versions of
open applications for any number of reasons, including
reliability and support (e.g., there are bugs in xterm
and several X servers that athena has ignored, but DEC
fixed).
so subsetting will have to be done carefully to make sure that DEC
users don't get X by default, while NeXT users do, or at least that
the DEC users get a strict superset of their current capabilities.
this will also be true of AFS in the kernel, and i expect that will be
a still harder problem.
4. start by "productizing" your existing code in source form and
making it available for ftp. most things aren't there yet.
prioritize by function, with the stuff in the kernel first, the stuff
on the root next, etc. it's a lot more important to us users to be
able to attach athena homedirs (not via the translator), use kerberos,
and get sipb via afs than it is to get things like zephyr. and once
we get the basics, we can get the rest just by attaching the right
server.
5. how will you keep up with all the os releases from the various
vendors? this will affect your kernel development especially. you
will have to support the last several releases of vendor OS and be a
beta site for their newest versions, or researchers will not want to
add athena layers because it will hold their OS upgrades up. these
upgrades are often required to support new hardware.
--jh--
