[5685] in Release_7.7_team
Athena 9.9 prototyping wrap-up
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Jan 11 12:53:39 2007
Date: Thu, 11 Jan 2007 12:53:30 -0500
Message-Id: <200701111753.l0BHrULT022200@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
X-Spam-Score: -2.598
X-Spam-Flag: NO
At the last meeting it was suggested that we wrap up Athena 9.9
prototyping for now and write up what we learned from it. So:
* Base operating system: We evaluated SUSE Linux Enterprise Desktop
10 and Ubuntu. We did not fully evaluate RHEL 5, but assume that
it is substantially similar to RHEL 4. Of the systems we
evaluated, SLED 10 appeared to be the best basis for a desktop
Linux system. They do the best job of licensing and packaging up
non-free components with the system, they appear to do the best
job with hardware compatibility, and they appear to have the best
64-bit story. Unfortunately, they appear to have the worst
package update system of the above three (theirs is slow, buggy,
and inscrutable) but we can work around that.
Currently MIT has licensed and is still recommending RHEL 4 for
Linux desktop systems, but is piloting SLED. We will of course
continue to follow this situation to avoid a splintering of vendor
relations and support resources.
* Package updates: Since our favored base operating system currently
has a bad package update system, we would likely be in the market
for a third-party package update system. Yum appears to be the
most attractive candidate, though we didn't do an in-depth
evaluation.
* Login system and Kerberos: We have verified that the native PAM,
NSS, and Kerberos components shipped with any major Linux
distribution can be configured to perform Athena-style logins
using Kerberos and Hesiod, and there is no longer any compelling
need to build our own Kerberos libraries and login interfaces.
We also did some prototyping of using gnome-session to replace the
bulk of our login session script; see release-77 [5519] for
details.
* Desktop environment: GNOME continues to have issues with AFS and
with the concept of shared home directories in general, and we
have so far had little success gaining traction with upstream
developers to address these issues. Current Athena contains its
own build of GNOME with local modifications to address these
issues, but keeping that build up to date has become too much
work. We have two paths out of this swamp:
- We've developed tools around Subversion to maintain local
modifications to an upstream SRPM like we'd get from Red Hat or
SUSE, rather than to an upstream tarball like we'd get from
gnome.org. This means we can modify a few native system RPMs
instead of maintaining a complete build of the GNOME sources.
- Novell has expressed interest in partnering with us to push our
local changes upstream. Many of our changes are not suitable
for upstream inclusion in their current form, but with their
help and enough work we might be able to reduce the number of
local modifications needed to zero.
* AFS: If we go with SLED, we will have a slightly nicer way of
deploying OpenAFS which will continue to work across most kernel
upgrades. We've tested that mechanism and it works.
