[647] in SIPB_Linux_Development
Re: suggestion
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Jul 21 17:46:21 1994
To: eichin@MIT.EDU ("Mark W. Eichin")
Cc: mhbraun@MIT.EDU, mwhitson@MIT.EDU, linux-dev@MIT.EDU, netbsd-dev@MIT.EDU
In-Reply-To: Your message of Thu, 21 Jul 94 17:07:46 -0400.
<9407212107.AA00703@rt-11.MIT.EDU>
Date: Thu, 21 Jul 94 17:46:02 EDT
From: Greg Hudson <ghudson@MIT.EDU>
I hate to rain on the parade, but:
- What are going to be the hardware demands on system packs? How many
clients does Athena put on a single srvd, and do those servers do any
other AFS serving? If we decided we needed to dedicate an AFS server
to supporting this kind of load, would we be able to do that? (Either
by procuring a third AFS server, or moving all of the other AFS
volumes to a single server.)
- Last I checked, the Linux-Athena software totaled about 13MB, and
that's with all the Athena libraries (including the mh libraries)
linked static. Is there really a reason to go to a remote file server
for this? Supported versions of tex and emacs would change this, but
there's always /usr/third.
- Is this really how we want to be supporting the Linux-Athena
software? Even when we make a determined effort to keep software
stable (e.g. in the sipb locker), we've had trouble with instabilities
cropping up, and I'm wary of developing a "captive audience" of people
who get basic system software from a locker we control, rather than
choosing when to update. This approach is all very well and nice for
Athena, with a high ratio of clients to people maintaining clients and
a two-month testing cycle, but our situation is somewhat different.
I don't think srvds make enough sense in this situation to be worth
the effort, unless we're going to start putting Linux boxes in the
public clusters. They make machines slower, complicate the manual
administration of workstations, and don't seem to provide many
advantages.
--GBH
