[1471] in athena10
Re: extra-software
daemon@ATHENA.MIT.EDU (Tim Abbott)
Tue Mar 10 12:28:45 2009
Date: Tue, 10 Mar 2009 12:27:56 -0400 (EDT)
From: Tim Abbott <tabbott@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
cc: Evan Broder <broder@mit.edu>, debathena@mit.edu
In-Reply-To: <5B101DEF-7B9A-43D1-8423-C4BAE3F3B74B@mit.edu>
Message-ID: <alpine.DEB.1.10.0903092054390.11542@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 9 Mar 2009, Jonathan Reed wrote:
> I think we need to clarify what exactly -extra-software is supposed to be. My
> understanding was "a bunch of stuff that was historically part of the release
> in Athena 9 and should probably be installed locally". That's clearly no
> longer the case, if we're installing KDE. (Discussion on Zephyr has clarified
> that this is actually just kwm, kpanel, konsole, konqueror, and some other
> stuff, but still) I realize the barrier to entry in getting things into the
> release is a lot lower in Debathena, and that's a good thing, but it seems
> like -extra-software is heading the way of "If someone asks for it, we'll add
> it", which is not sustainable in the long term, nor is it supportable. OLC is
> not prepared to support KDE, for example.
Making things like KDE available differs from supporting them. On Athena
9, KDE is available in a locker, and some people use it. I think OLC can
reasonably take the position that running KDE isn't a supported
configuration, but it's available if you want to do the work yourself. It
seems roughly the same as the fact that Athena 9 has /bin/ksh installed,
but using it as your shell isn't supported.
I agree that we need to use discretion when installing things in clusters
to make sure they don't have unintended consequences. But I kind of like
the idea that when course staff want eclipse or some library or whatever
available for their class, it can be added the the release rather than
having the staff figure out how to build the software and install it in a
locker.
> I think moving locker software locally is a good thing, but I think
> having _all_ locker software locally is no better than having _all_
> software in AFS.
I think it is better, for a few reasons:
(1) In the common case, nobody at MIT has to do work to update local
software. Someone at MIT has to regularly do work to update locker
software.
(2) Performance is better for software intalled locally.
(3) Less setup is requires to use software installed locally. A good
example of this is trying to link software against a library installed in
a locker -- you end up having the extra step of telling the software where
the library is, rather than allowing it to use the defaults.
Obviously there's a tradeoff with installation time and network usage, but
it seems to me that adding small software packages that people want and
don't have much effect on this is fine, as long as we're clear in our
communications when installing such software that we aren't guaranteeing
to either support it or retain it indefinitely.
> debathena-extra-software depends on a set of packages that we identify as
> critical. It can then recommend everything else. On the off chance that you
> get a cluster machine that doesn't have, say, KDE installed, then you should
> report it and go find another one. But if you get a cluster machine that
> doesn't have, say, emacs, that's a problem.
That's probably fair. I would add that we don't want to add anything to
-extra-software that results in a machine running system daemons (e.g.
apache2) or other significant security model changes. One test for this
is we only include software that would be reasonable to install in a
locker.
-Tim Abbott
