[13] in SIPB_Linux_Development
daunted by resnet
daemon@ATHENA.MIT.EDU (Joe Harrington)
Mon Jul 5 02:21:50 1993
Date: Mon, 17 May 1993 23:51:27 -0400
From: jh@flolab.mit.edu (Joe Harrington)
To: sipb@mit.edu
Cc: jh@mit.edu
Reply-To: jh@mit.edu
I'm really excited about the resnet project, since it's been 6 1/2
years since the first five experimental Athena clusters got installed
and the concept of a machine in each student's room got a serious try
at TDC. Supporting the living groups was what I did as a Watchmaker.
I'm also a bit concerned that I/S and SIPB are going to be swamped with
unforseen or underestimated things to deal with as people try to put
their machines on the net and do useful things with them.
If we're providing Linux system packs that people can load their
machines with, many people who really don't know much about Unix
system management will be using it and depending on it for everything
they do with their computer. My concern is that people will then
depend on us for more than we can provide in terms of support, and
there will be potential academic pain involved for those who need the
current Linux maintainers' time when they're swamped with Junior Lab
or Unifried. I don't want to be "man who say something impossible to
one doing it", but I do think a heavy dose of consideration and prior
thought should go into any aspect of SIPB's resnet-related services
where someone's whole computing environment could depend on us at a
critical time. We're entering a realm where most of the important
issues are NOT technical, they're logistical.
Some specific thoughts:
-How much load can we share with I/S for supporting Athena/Linux? If
we take on the role of the supported operating system vendor (which
Athena likes to have someone else do), can they do the port and thus
actually support (at the consulting level) the Athena software? Or
even, can we hand them the whole thing and train them, and load-share
the support with olc? This will ensure more continual coverage and
perhaps a more unified structure from the user's point of view. ("I
have an Athena problem only for this one I call SIPB, I think, or
would this happen on a real Athena machine? or...")
-Can we distribute the Athena port in a manner following the Layered
Athena model? Perhaps the people involved in the Layered project
could be contacted to see if the design needs to be modified to allow
several independent layering providers. Or, perhaps we can make our
stuff available through the same service system that they use.
-No matter how it's distributed, let's be extremely explicit about
what level of support people can (not) demand from SIPB.
At the base of all this is the feeling that, although supporting Linux
and porting things to it may be a very cool project, providing that
level of service to that potential number of people may be a bigger
task than we currently recognize. It's definitely in Athena's best
interest to provide a layered Athena for Linux, because the other
option (if we don't cover their butts by providing it ourselves) is
dialups so swamped by resnet folks that the current levels of use will
look light, and that means spending a lot more for clusters of dialup
machines. (For those who don't read the cluster-managers' list,
outsiders logging into departmental clusters is a major problem
already.)
--jh--
