Greg Hudson’s MIT blog

To plan out the work of the Athena 10 release, I needed to compose a fairly comprehensive list of things people expect from Athena machines beyond the base platform.

Here’s the list.  For every one of those, I get to detail how we handle it in the current Athena release and how I expect to handle it under Ubuntu without building so much third-party crud.  (Or, in a few cases, that we expect to discard that feature.)

I’m working under Ubuntu 7.04 now.  In the past I had difficulty installing it on my 17″ Macbook Pro, but I worked past that.  (Problem: the Live CD tries to use a non-encumbered graphics driver which black-screens and freezes upon starting the X server.  If you specify a resolution at install time, the X server instead crashes on startup, giving you access to a text console from which you can install and configure the encumbered fglrx package.)

It’s good except gnome-terminal appears to be buggy (has some rendering errors from time to time, which go away when you force a redraw) and occasionally text gets pasted or other mysterious things happen when I don’t want them to.  I think the latter may be due to the trackpad support causing mouse events when I do something ham-handed to the keyboard; I have yet to figure out exactly what I’m doing to cause it.  Oh, and Firefox sometimes freezes up after Flash content is displayed.
I was reminded recently that Ubuntu is not a no-brainer choice over Debian, so I thought about that a bit.  I looked over some of Bill Cattey’s Linux survey data in greater detail (it’s still not ready for release) and determined that in fact, Ubuntu does appear to have a larger user community than Debian at MIT, so I’m still comfortable with that direction.  I have some specific concerns about Debian as opposed to Ubuntu:

• It tends to have a long release cycle, which in turn often encourages people to use less stable variants in order to have access to modern software.
• Its purist approach would force us to do more work assembling the encumbered components needed to make it work acceptably to users.  (That’s my impression, anyway.)

So, what does an automated RHEL to Ubuntu upgrade look like?  The package manager isn’t going to do the job, so it has to be done at the file level (although the package managers can be used on each end to assemble a list of files that need to be considered).  Athena has past experience with file-level OS upgrades; we did them with BSD Unix, Ultrix, and Solaris.

We had enough problems with Solaris OS upgrades that we eventually started doing them from a miniroot installed in the swap partition rather than trying to do them while the target system is booted and running.  I’m not sure if we want to invent that machinery for Linux; it’s harder to do on PC hardware and it wasn’t a trivial amount of work on Sun hardware.  It might be easier to just work around the problems of doing a live upgrade for this one-time occurrance.

I’m currently putting minimal work into Athena, but have been thinking about it some. The last I wrote about Athena is here but a number of things have changed.

First, Linux survey information (not yet published) indicates that people want us to be supporting Ubuntu or Debian. Ubuntu’s most recent release supposedly does a better job of integrating the proprietary components you need for a functional desktop–proprietary video drivers, Flash, and so on. I’m still nervous about the practicality of their x86_64 support model (totally separate platform, can’t use 32-bit binary plugins to programs like Firefox), and I don’t know what an automated upgrade from RHEL 4 to Ubuntu would look like, but we’re currently leaning towards Ubuntu as the base platform for Athena 10.

I don’t know when Athena 10 is likely to happen. It won’t be this summer. This summer we are probably looking at a patch release with Firefox 2.0, proprietary video drivers on cluster machines for better graphics performance, and maybe the VMWare player if we can get permission. We’ve started getting complaints that Athena 9.4′s GNOME installation has bitrotted too far to build modern GNOME programs, and that’s only going to get worse over the coming year. So summer 2008 looks fairly likely.

In the past, we’ve tried to branch out to keep Athena relevant. I’d like to stop doing that, and just focus on making (with limited resources) a good system installation for cluster machines and quickstations, which is as close as possible to the underlying Linux distribution. I don’t think Athena can offer much to single-user desktops or laptops today, although I expect there to continue to be privately-administered Athena machines as long as we have clusters and quickstations.

So: an Athena machine is expected to be always on the network–ideally a nice, fast network. An Athena machine uses the MIT Kerberos namespace for logins and the AFS file store for user homedirs. (Some day MIT may transcend AFS, but probably not before it transcends Athena, unless a better distributed filesystem comes along. It might be possible to have clusters without shared homedirs, but I think it would be flaky and a lot of work.) Athena machines should generally take care of themselves, though a minority will be privately owned by administers who want to do their own tampering in addition to ours.

Lastly, Athena is not a concept or a set of services.  (My supervisor still talks about “Athena broadly defined,” but I’ll try to convince her to give that up.)  It’s a software installation that we’re supporting because, for the moment, MIT still seems to want to have quickstations and clusters.  It uses a set of services like AFS, MIT email, etc., but those are separate service offerings and not themselves part of Athena.