[89] in Layered Athena

home help back first fref pref prev next nref lref last post

Layered Athena in 1995

daemon@ATHENA.MIT.EDU (brlewis@MIT.EDU)
Sat Jan 7 16:20:54 1995

From: brlewis@MIT.EDU
Date: Sat, 7 Jan 95 16:19:56 -0500
To: layered-athena@MIT.EDU

** Can we meet on Thursday 10am? **

A new year is a good time to stop and think about what you're doing and
why you're doing it.  I think this applies especially to the Layered
Athena team.

I'd like to revisit the original motivations of the group, according to
the requirements document (/mit/layerdev/doc/reqs.tex).

(1) to give the private workstation owner more flexibility
(2) to simplify future Athena ports

We've done very well with (1), no doubt.  But I think we need to set
realistic expectations for (2).

In some ways, Layered Athena as it is currently implemented is helpful
in new Athena ports or upgrades to new OS versions.  It provides a
convenient way of starting with a standard vendor platform, layering
Athena on top and seeing what breaks.

What it doesn't provide is quick reinstall of everything, including core
OS.  In this area, we're no closer to a new public workstation model
than we were at the beginning.

I suspect there are misconceptions floating around management, to the
effect that some team (either layer or skunks) is going to invent a
radical new model for public workstations, dramatically reducing the
development effort involved in porting to new public-workstation
platforms.

The difficult parts of any such port - login and reinstall - have not
gotten any less difficult.  Layered Athena gets around reinstall by
forcing the private workstation owner to take care of the core OS.  This
won't work in public clusters.  The SGI (skunks) model omits xlogin, but
requires that Athena login functionality be hacked into vendor login
code.

As much as I enjoy the privilege of leading a team that includes some of
the most in-demand people in I/S, I fear that this privilege is a result
of management misconceptions (either present or past, I don't know) of
what we are going to produce.

I'd like to throw out for discussion the idea that the Layered Athena
team should produce a report that includes results of the beta test,
recommendations for the future, and a writeup of what we have learned in
the "what Athena is" area.  After that report is produced (some time in
spring semester), we should stop meeting as an active team.  If a key
customer approaches us with issues that would warrant the team getting
together again, we can always schedule another meeting.

Can we meet on Thursday 10am to discuss these issues?

Also, please email your comments to the layered-athena maillist.

home help back first fref pref prev next nref lref last post