|
My vision for Athena -- by Bill Cattey |
| Contact information: | wdc@mit.edu |
|---|---|
| On this page: | Purpose | Today's Context | Linux Athena | Athena User Interface | Private Athena | Athena and Windows 2000 |
As the leader for Service and Delivery of Athena, I am responsible to Vijay Kumar, the Assistant Provost for Academic Computing, and the end-users of Athena. I believe I best serve Vijay and the users by having a dialog with them and evolving a vision of Athena. The purpose of this page is to more clearly express that vision as it evolves. It is my hope that most will find my vision represents how they would see Athena go. If not, I hope they will email me and contribute to the evolution of the vision.
Here in February of 2000, there are three projects in progress that relate to Athena, and reshaping it for the future:
I've had hallway chat with many people who are excited that Linux, user interface considerations, and the needs of private workstation owners are at long last visibly influencing Athena. Everyone I've talked to expects that a particular kind of change is coming as a consequence of these influences. I decided to write this white paper because the particular expectations expressed by different people were rather different from one-another. I decided to express a vision and a set of principles that are being distilled from these influences, and from the experience of implementing the vision.
At MIT we have a hallowed tradition of disagreement. Everyone has good strong opinions about everything. By stating my vision, I am sticking my head in the lion's mouth, and must now prepare to have it bitten off. As you prepare to email me and tell me why I am wrong, please try and remember these things:
In other words, please try to be kind, and please understand that I'm doing the best I can, even if it's obvious to you that I've committed a ghastly error somewhere.
This document will ALWAYS be a work in progress.
Synergy is a word that has lost most of its meaning because of its being used in too much hype and fluff. Yet synergy is the term that best describes my vision of Linux Athena.
Project Athena in the early 80's bet that Unix workstations would succeed in the marketplace. They would displace clunky DOS systems, and would be what universities used ubiquitously after the Macintosh showed what was possible on a small scale. Academics rarely get their marketing right. PC's and Macs were purchased by the zillion. They caught up to and surpassed UNIX systems in end-user functionality. Athena had a tough time responding to end-user demand for PC and Mac functionality because those very functional very inexpensive systems could not be deployed and administered with the ease that UNIX could. MIT Academic computing had to simultaneously port Athena services to microcomputer platforms, and add personnel to do the much more labor intensive maintenance and deployment that was going to be avoided through Athena UNIX.
I remember many conversations with smart grad students demanding that Athena abandon UNIX workstations and port to some sort of PC platform. The reason why that effort was put off for so long was that the cost of administering the PC's was so high. In fairness, the developers working on Athena never liked how Apple and Microsoft did operating systems. It was really very hard to get the infrastructure as reliable as under Unix. In the back of many of our minds was the hope that some day there would be an operating system like our beloved UNIX on an inexpensive PC platform.
Eventually there were PC UNIX variants, but by then, there was a new constraint: The Athena machines had a suite of third party software, and so a mainstream OS was required. Eventually Windows and Mac OS became more popular with software providers, and some began to look upon Athena UNIX as a dinosaur.
Then came Linux. Linux was not as clean inside as other versions of PC UNIX. But it was good enough for many of the keepers of the UNIX flame to buy into. Most importantly, it became perceived by the marketplace as sufficiently main stream that a significant number of third party applications were ported to it.
Linux was something that ran a critical mass of the supported Athena third party software, that was reliable enough for production use, and was close enough to the other Athena UNIX ports that little work was required to create an bona fide Athena Workstation based on Linux. The biggest third party chunk of Athena is Transarc AFS, the MIT-wide file-system. Finally a production-quality port of AFS became available under Linux. Linux appealed to end-users because it ran popular software. It appealed to developers because it was what they liked to work with. It appealed to sponsors because it was an inexpensive platform that could be adopted at low cost.
But there was one more advantage to Linux that few saw: Since it was easy to port to it, and since there was no installed base of Linux Athena systems, there was an opportunity to do some low-cost rewriting, nay re-architecting. On the outside, Linux Athena looks the same as Sun Solaris Athena, or even DEC Vax Athena. But on the inside is an improved architecture that allows follow-on work to radically change and improve the user interface, and how the systems can be privately administered.
So the first 10 Linux Athena Public workstations have been made to act and look just like the Athena systems of old. You install from the net with a floppy. You log in and get Dash. Don't bother to ask what's different right now, because there isn't any difference. It was designed to look the same and act the same -- for now. Instead look to the other projects to be PROTOTYPED under Linux Athena first because it's easiest platform to try out changes.
Now we come to the next assumption people make: Most people have understood that we re-architected things inside Linux Athena, so they expect improvements in the user interface and in the operation of the Private Athena Workstation to be confined to the Linux platform. Not so.
Discovering a thing is possible is often much more difficult than repeating a thing. Linux Athena was architected to explore radical changes to the user interface and to how install, update and administration were done. But the developers are very familiar with making changes in a way that harmonizes with the existing code base. Once we understand what people really need, and have a good implementation in hand, we will integrate the work into the Athena source tree so that specific bits of new architecture can be back ported to the Sun and SGI without a lot of work. Expect any face lift to the Athena user interface to be on ALL platforms. Expect gradual but steady improvement in how install, update, and administration work on at least the Solaris platform in addition to the Linux platform.
I said above that PC's and Mac's surpassed UNIX end-user functionality, and that there is a class of developers who don't like the insides of microcomputer operating systems like Windows and Mac OS. Many people have asked me, "Is Linux Athena fighting against Project Pismere?".
I think that there is some competition, but that it is friendly competition. Everyone has their favorite implementation platform. You invest yourself in an implementation platform because you believe it will help you do what you need to do. Both Linux Athena and Project Pismere are taking different routes to do the same thing: To give MIT users a robust, useful, cost-effective infrastructure. Both platforms have strengths and weaknesses. It is very easy to fall into the trap of thinking one must win and one must lose, or that computer programmers are more interested in coding on their pet platform than in serving the needs of their sponsor. Reality is much more complex than that.
And my own stand? I classify myself as a UNIX true believer. My biggest source of prejudice in favor of UNIX is that I have a much more difficult time seeing how to implement things under the other platforms. I am most productive with the platform I'm most familiar with, and that most often tends to be UNIX. But I use Macintosh, Windows, and Unix, all three all the time. I tend to install a lot of end-user Windows software at home and then pray that it gets ported to Unix so it will crash less often. The experiences I, myself have had with Microsoft operating systems have been unpleasant. So it would be convenient for me if UNIX displaced Windows. I've been trying out the heretical notion in my own mind, "Would I accept Windows more if it crashed out from under me less often, and I was less often called upon to fix things?" Maybe. But I have always enjoyed being an insider. Fundamentally the only real Windows insiders are Microsoft employees. To win my heart I'd have to have an easy time getting inside Windows and having the kind of familiarity I have now with UNIX. That's a big gap of knowledge, and access that I simply don't expect ever to be bridged. Twenty three years is a fair bit of experience to replicate in a new platform. But stranger things have happened! Maybe we'll see an O'Riley book: Windows for Unix Wizards.
Politically, the theme for the present Athena User Interface Discovery Project seems to be, "Don't get caught doing the right thing for the wrong reason." Phrased more positively: "It is important that what gets built is what users will perceive as an improvement, and what sponsors will perceive as most worthwhile."
As I said in the previous section, the end-user functionality of PC's and Mac's outstripped what was available under UNIX. When Athena shifted from an experiment to an official piece of MIT infrastructure in 1990, it delivered software and services that balanced between many factors:
The priorities followed were:
So user interface was the low man on the totem pole. With constrained resources, it was the last priority to be addressed. The Athena user interface really had only three major changes since it's experimental phase:
Actually with dash came a logout button, and with SGI there came the option of using the SGI look and feel on that platform instead of the Athena look and feel. But I feel that these don't count as major user interface efforts.
Over time, perception by users of the Athena user interface shifted from innovative, to ordinary, to clunky, to backward. The UNIX platform occupied a market segment that focused much less on user interface, and so replicating under UNIX certain applications and user interface standards and styles proved difficult. The process was further harmed by "the toolkit wars" where the different UNIX vendors refused to cooperate on a common platform in a timely fashion. By the time the different vendors had agreed on a common platform, and actually implemented it, the PC and Mac interfaces had the market sewn up. There was insufficient market share expected to justify projects to make UNIX user interfaces like microcomputer interfaces. The number of UNIX applications started to go down.
When UNIX finally appeared on microcomputers, the UNIX tradition of balkanization seemed about to win out again and keep the UNIX community forever behind the microcomputer community.
Personally I don't understand why the marketplace perceives Linux to be one coherent product that can be compared sensibly with Windows or Mac OS. There are almost as many subtly different distributions of Linux, as there are Balkan states of Microcomputer UNIX, as there are Balkan states of UNIX on other platforms. For whatever reason, Linux has achieved a critical mass of market acceptance and is now considered a large enough market segment to justify porting software to. This factor has helped greatly in lowering the cost to close the gap between end-user functionality between Unix and the PC and Mac platforms.
GNOME supplies an important missing piece: a user interface development toolkit. Critically, it is rich enough to provide functionality that meets or exceeds current standards and styles. Although it is not 100% certain, the trend seems to be that it is achieving enough market share to become the recognized common toolkit platform. Although GNOME started under Linux, ports to the other popular UNIX platforms exist. Athena has, under test, complete GNOME distributions for Sun, SGI, and Athena Linux.
Bottom line on all this history: Over the past ten years the need to evolve the Athena UNIX application suite and user interface to meet or exceed the end-user functionality available under Windows and Mac OS has grown steadily. The resources to do the work were in short supply. This year, the nature of the problem changed such that the value could be delivered for significantly less cost.
Few outside the community of Linux developers were aware of the evolving situation with Linux and GNOME. The history of platforms, toolkits, and market segmentations bred a justifiable skepticism that real change was on the horizon. But a few of us decided it was time to try and believe again, and make a push to redo the Athena user interface, with GNOME to close that ten year old gap.
The champion for this effort came out of the Athena development team. As I shopped this idea around to managers and directors around IS, the most common advice I got was, "make sure that this is something that's validated with customers, not just something that developers want."
In essence, everyone with political experience was concerned that this project was at risk of being perceived as one of those, out of control projects you hear about so often: a technology in search of a problem to solve, championed by engineers who invest a lot of emotion in the project, consuming a lot of effort, but never delivering anything that the customer actually values.
Vijay Kumar, the sponsor of the project, put a really positive spin on the concern. He said that making sure the customers wanted what was being developed was crucial to success. My sense is that the effort itself is at risk because of different stake-holders having different views of what is adequate validation of customer desire.
Here is a slightly overstated inventory of principle viewpoints:
| Developer: | We are talking with customers. We should not have to go to great lengths to create elaborate justifications to managers what the customers and we have hammered out together. Still, it would be nice if we didn't have to translate so much from uninformed user input to what will really be acceptable. |
|---|---|
| Director: | Everyone and his cousin is second-guessing how IS should spend its funding. It would be very bad if we let any resource-intensive projects get out of control. |
| Cynical User: | If the developers get it right, I'll use it, but if what they ship isn't right, I'm going to insist they start over. |
| Naive User: | I'll tell you what I want, but I don't understand why it's not already that way. |
| Experienced User: | Now that I finally understand how to use the system as it is, you want to change it? I don't want to have to go to a lot of trouble to accommodate the new system. |
I think all these viewpoints can be accommodated successfully if:
This sort of rule-of-thumb sense of the development task is what I worked through in my mind that led me to believe that the redo of the Athena user interface could succeed. The users don't have the kind of background to suggest a detailed and workable user interface, but they should be able to validate an 80% prototype either is or is not comfortable. For an application, the user is the expert. But for a general-purpose user interface, the human-factors engineer is the expert, and all directly supplied user-input needs to be translated from what the user thinks he is doing to what he is actually doing.
To me, the most difficult part of the whole Athena User Interface Discovery project is validating that we're in the right ball-park. It would be a tremendous sink-hole of resources to:
A hand full of developers have guessed at some significant gaps in the Athena user interface that can be bridged without a lot of work. Let's code an 80% prototype and find out if we're on the right page.
The real stumbling blocks to people outside the team accepting this project vision are:
You know what? The deliverables identified informally by the Athena Release Team and published in the minutes of the 29 September 1999 meeting look spot-on-the-money, even if I can't rigorously tell you why. Look for yourself:
What Athena has now:
- menus (Dash)
- initial xterm
- window manager (mwm)
- console window
- logout button
What we want:
- aesthetic appeal / modernization *
- tool-bar (with menus, applets, etc) *
- menus *
- more stuff in system menus
- easier for users to add things
- logout button in tool-bar *
- file manager (like we have on the SGI's) *
- with icons for removable media
- should use "delete", not "rm"
- should know about AFS acls
- should know about lockers?
- window manager (still Windows-like enough to be obvious) *
- Help browser that pops up on first login to be helpful *
- console window (can't really get rid of it, at least at this stage) *
- maybe rewritten in GTK "with doodadery"
- initial xterm (probably) *
- Athena control panel
- "gkerberometer"
- GNOME/GTK versions of other apps
- OLC (a student has been working on this) *?
- Discuss
- Zephyr (send/receive/zctl)
*ed items are things we'd like to have in the prototype
Issues:
- Dash allows documentation attached to menu items. GNOME Panel
allows "tips", but they're more obtrusive, especially if they're
very large.
- GNOME still has stability problems...
- Athena Documentation vs. GTK Themes. ("the picture shows a red bar
with a gray X, but all I have is this black bar with a white X!"
As the example suggests, this may just be paranoia...)
- GNOME Terminal vs xterm vs eterm
- "Days to login" (how slow is it on the slowest machines)
- Some software only likes 4Dwm
|
There are certainly additional functions that would also be very helpful. The Athena Forum identified a strong desire for a drag-and-drop interface to floppies and zip disks. Unfortunately we don't yet understand how to provide that at low cost. The work above is a clear prerequisite.
There are issues of resource consumption for migration, and there are concerns that the newly deployed software actually work. Certainly these issues are crucial to the delivery phase of the project. But the central question of the Discovery effort is: Do we know rigorously enough that the above is true that it is worth the risk of putting resources into this project?
The real tragedy of the Athena User Interface Desktop project is that with the departure of Dan Winship and Karl Ramm, the project will have to wait a year for delivering any relief to people struggling with the old Athena user interface. Karl was the champion. He could foster the energy to do unpleasant tasks like talk to end users and make sense of their uninformed opinions. Dan was signed up for the lion's share of coding and debugging. The planned 80% prototype cannot be built until these resources are restored.
The only bright side to this delay is that it gives us a chance to watch and confirm that GNOME will become as well-accepted and as robust a platform as we forecast.
I've continued to look for ways to make the facelift of the Athena User Interface happen even with the dearth of resources presently available. I've been helping write the Final Report of the Discovery Project with an eye to providing a good list of recommendations that can just be picked up and done as resource become available. This has required a clear sense of what needs to be done and at what cost.
It turns out that the major task is "Debugging the GNOME toolkit components and applications critical to the Athena User Interface." The Discovery Team estimated that this effort would be 20% of two developers for six months. This is a significant resource expenditure and opens the question, "Is this project about taking a broken toolkit and investing too many resources to fix it?"
It is important that any effort that involves debugging an acquired program be carefully considered. For example, the Athena port to Solaris 2.1 involved significant effort at debugging user-critical aspects. The resulting Solaris 2.1 Athena was in place for two years and it delighted customers. Solaris turned out to be a very viable platform, and the debugging effort was focused, and added real value at the early stages of deployment of what has turned out to be a central and long-lived Athena platform.
The risks associated with expending our resources in GNOME debugging are:
The possible value associated with expending resources in GNOME debugging are:
The critical question is: Is the expected value high enough, to justify expending the resources here rather than elsewhere. I think we should pursue the GNOME-based facelift of Athena, at least in prototype form because:
Perhaps the best approach is for the Athena User Interface Discovery team to recommend taking inventory of the bugs, but leaving fixing them to a separate delivery phase.
Historically, the major focus of Athena development has been on making the systems deployed to the Public areas stable and robust. Making sure that everything is appropriately cleaned up for each successive walk-up user has been primary. Then making sure that all systems get appropriate updates from the central system image has been the next primary goal. The design and implementation has focused on the Public workstation. Customers with other needs have not been well served.
If what you want to do is own a system that diverges even a bit from what is on the central system image, our support has not been good. In fact, many would believe that the architecture of the Athena Public Workstation release is fundamentally unable to meet such needs. I disagree. I think it is possible, but we've heretofore failed to deliver because certain crucial implementation details kept being done incorrectly:
My vision of the Athena install is that it provides a sensible short-cut for installation and administration of a computer. The computer could be a desktop system, or a server. To end users, and even support personnel from the vendor, an Athena-installed system should not be distinguishable from a vendor-installed system.
When that vision is implemented, the number of people dedicated to system administration can decrease. That is a good thing because there is demand for more systems than there are available people to administer them. I believe that Athena-installed systems are a big contributor to the solution to this shortage of administrators. Anywhere a server is needed, it may well be that a simple Athena network install will do the trick.
It is a common misconception that the present Athena install somehow completely obliterates the usual vendor operating system with something we cooked up. In fact, the operating system is the vendor-supplied operating system, just installed in an unusual way. With the upcoming Athena release 8.4, we will have redone the install of the operating system to use the vendor-supplied installer on all platforms. At long last, the system will look like a vendor-installed system. The great advantage then will be that an Athena-installed system will be a consistent load of the vendor operating system.
By a consistent load, I mean this: A vendor installation procedure has to account for many different configurations. Each person performing an install answers many questions about what is and is not installed. Sometimes a site can get into trouble if systems installed by different people have different answers supplied to the sets of configuration questions. So an Athena-installed system always starts with the same set of answers to the vendor installer's configuration questions.
The fundamental questions to be answered by a reasonable Athena Private Workstation product are:
In the past, the answers to all these questions was "no". The Athena Private Workstation Discovery project surveyed to determined if there were more questions than these. It turned out that none other than these turned up.
So now the Athena Release team has started work on amendments to the way Athena is installed and update to make the answers to questions 1 and 2 be "yes". The Discovery Project Team will be recommending work to help make the answer to question 3 be "yes".
The reason why I believe the Athena Release Team will succeed is that a different set of update policies is to be implemented for Athena installs:
With regards to package updates:
So with the coming of Athena 8.4, it will at long last be possible to offer customers a customizible and understandable system that is Athena-installed.
As I stated above, I'm much more comfortable in the UNIX universe than in the Windows universe. Because of this comfort, my prejudice is the hope that Windows will go away, and that UNIX will triumph as the main infrastructure platform. Prejudice and comfort are not reality.
The reality (which I also stated above) is that the microcomputer platforms of Windows and Macintosh offer end users a better experience than the UNIX platform for a wide range of activities, and that the UNIX community has been, in many senses its own worst enemy in changing this situation. The fact of the matter is that MIT users have a real and valid need to run software that exists solely on the Windows platform.
The evolution of the Windows and Macintosh user environments made them initially inappropriate for deployment in Athena. The ability to clean up after successive users at one machine was first on Athena's priorities, and last on the microcomputer developers priorities. Same with central administration of large numbers of machines. So the core skill of Athena developers was making reusable, centrally managed systems. Deploying microcomputers to those specifications was anathema. No significant microcomputer deployment was going to be made unless the administration issues were dealt with. Some agency other than Athena could (and did) take responsibility for helping MIT users deploy and administer microcomputers.
Over time, Windows and MacOS evolved to allow better cleanup and administration. When Microsoft NT version 5 was announced, its features finally measured up to the Athena reusability and administration requirements. Initiatives to attempt on the NT platform what had been successfully executed on the UNIX platform was begun. This initiative is now known as "Project Pismere".
Having decided on a course of action, events sometimes conspire to make fools of us all. There evolved to be four goals for Windows deployment at MIT:
From my position on the outside, the vision of Project Pismere seems to be,
Hit a home run by doing an integration of Microsoft Windows NT 5 (now called Windows 2000), Athena services, and techniques for reusability and central management pioneered by Athena, but appropriately recast for the Windows platform.
I think this was quite a reasonable vision, and would meet all three of the goals. After having understood the issues well enough to do a proper integration, it would be trivial to produce packages to layer Athena services on individually installed and administered Windows machines. The tragedy of Project Pismere (and in fairness the Athena User Interface Project has a tragic aspect as well) is that the timing of the delivery has not been what anyone wanted.
Again, from the outside, and with my UNIX-centric prejudices, I fault Microsoft. Many times through the history of Project Pismere, the question was raised, "Do we want to continue on the whole integration or do we want to switch over to packaging Athena services separately?". At each point, it seemed like the full integration was within reach. Yet, time after time, the shifting sands of Windows 2000 introduced show-stoppers in the integration.
Should the project have changed to offer nicely packaged Athena services for individually administered Windows systems? Is the vision of a full Athena-style integration for Windows foolish? I think the answer to both questions is no.
The primary goal is to make it easier for MIT customers to run software on the Windows platform, not to provide Athena services. The hard problem that most importantly and urgently needs to be addressed is reducing the number of persons required to take care of the computers MIT needs to run. It is unfortunate that the packaging of Athena services for individual Windows systems is inconvenient, or in some cases nonexistant. But the correct course of action is being taken.
Mind you, my conclusions here are in line with my own having presided over a prolonged period of acting against providing convenient installers for Athena services on individually deployed UNIX systems. Ultimately, my high-sounding vision is consistent with my prejudices, and justifies my past behaviors. Even now, I have had to prioritize production of Layered Athena packages. Again they are below the cutoff line at my present level of staffing.
The tradeoff is: We build reusable, scalable infrastructure first. We craft convenient installers for our components second. If there is a conflict, the second task gets chopped. Sorry.
(c)1999 William D. Cattey All rights reserved.