 
|
|||||||||
Athena Linux Differences: Athena Linux vs. Stock Red Hat Linux
Introduction
Athena Linux is not a new operating system, nor even a new distribution of Linux. Instead, it is a repackaging of Red Hat Linux with additional applications, services, configurations, and bug fixes.
Athena Linux is intended to simplify use and reduce the system administration burden. It achieves these goals by:
- providing a baseline install image common to all installations;
- incorporating bug fixes of importance to users;
- integrating applications of value to users;
- adding new and important user services;
- setting defaults most comfortable and appropriate to the MIT community of users, and to the MIT IT environment;
- accounting for and resolving configuration conflicts;
- offering an automatic update system;
- permitting rich user customization of the install image;
- enabling both coarse and fine-grained control of the update process.
Athena adds in excess of 200 RPMs to stock Red Hat that are either additional services, or variant versions of the stock RPMs. For each Athena release, the intent has been to make the minimum number of changes required to gracefully migrate existing customers to the new MIT standard Linux version. Since Athena Linux originated as part of the comprehensive "all things to all users" Athena release, there have been many legacy and compatibility variances from stock Red Hat Linux.
This document describes the additional RPMs included in the Athena Linux Release and the rationale behind their inclusion. Also included is a description of the work that could be done to bring the Athena Linux release closer in line with stock Red Hat Enterprise. This information is current as of Athena 9.3 which is based on Red Hat Enterprise WS Linux 3.0.
The sections below outline::
- Services: An overview of services added to Red Hat Linux. This section includes links to a more technical page containing greater detail.
- Variant Packages: Describes Athena-modified versions of existing Red Hat Linux packages.This section includes links to a more technical page containing greater detail.
- Work Areas: Potential areas to eliminate differences between stock Red Hat Linux and Athena Linux.
An appendix provides an Alphabetically arranged list of all current Athena-specific RPMs along with their summary descriptions.
Services
Athena provides a number of services beyond those provided by a standard Red Hat release. The Athena Linux Differences: Services Detail page describes these new services. They have been organized into four main categories:
- Network Services which enhance the user experience in an integrated networked environment:
- User Services to provide a standard desktop experience with a managed login session, and to allow the user to access files and software from the network:
- Administrator Services to allow low-cost, low-maintenance system administration:
- Support for Athena System Developers
Variant Packages
A number of Athena packages are modifications of existing Red Hat packages. The Athena Linux Differences: Variant Packages Detail page describes them. They have been organized into three main functional areas:
- Libraries and Infrastructure, the pieces of the system that underlie the user experience:
- User Services, the applications and services used by users:
- Other Tools, Applications, and Services, individual subsystems with Athena variants:
Work Areas
Athena introduces in excess of 200 new or variant packages beyond stock Red Hat Linux. Although that seems like an intimidatingly large fraction of a Red Hat install, every one of those packages is there for a reason. This section affirms that a cost benefit tradeoff was made before creating the difference, and that analysis is re-addressed frequently.
Fixing Software In-house
As the Athena Variant Packages Detail section
said, the biggest single contributor is the 50+ RPMs that constitute GNOME. Those make it easy to:
- incorporate crucial bug fixes in a vastly complex set of libraries;
- diagnose user bug reports about GNOME;
- craft fixes and submit them upstream to gnome.org.
In matters of software infrastructure, MIT always faces the choice: build it, buy it, or join the development effort. Project Athena was a "build it" effort aimed at creating scalable, secure, client/server computing. Now that the project is over, the question remains: How much development effort should MIT expend?
At present we buy Red Hat Enterprise Linux, and minimize the number of locally built and patched components. We have elected to build GNOME and Mozilla in-house, and submit patches to the development organizations when required. We take an even more active role as a member of OpenAFS.org. We periodically re-examine and adjust our level of involvement in external development efforts.
Smoothing Over Differences
The next biggest share of variances exist to smooth out differences across
platforms or to allow compatibility with legacy behavior. At any time, the decision could be made to ask users to "tough
it out" in these areas. Athena started
with a large system development team that invented modes of authentication and user interface that became, to one extent
or another, standard in the industry. At the present time, a small group works to pick a few areas where it seems customers
are best served by a little coding work to smooth over a difference. The extent to which we continue in this business
is an ongoing decision.
Athena-unique Services
Finally there are Athena-unique services like serial reusability, install, update,
the Zephyr instant messaging system, and the discuss meeting and archiving system.
Consensus seems to be building that migrating off discuss onto shared IMAP folders might be cost effective.
Zephyr, though it invented client/server instant messaging, never kept pace with the ease of use offered by later IM systems. Still zephyr offers explicit security and well-defined server scalability in an enterprise. Fully migrating off Zephyr is not advisable until comparable security is offered by its replacement. Some present Zephyr traffic has less stringent security requirements and could benefit from a better user interface. A potential solution could be a multi-protocol jabber translation server that would allow customers use the familiar AIM client to interface to MIT Zephyr, but further investigation is necessary to determine feasibility in the Athena environment.
Install and Update the Athena Way
When Athena invented scalable client/server computing, it was necessary
to invent a method to install and update what were expected to be large numbers of machines. The Athena install system
enables a new machine to receive a baseline operating system and application set with minimal human intervention. The
Athena update system performs highly customizable software updates with minimal disruption.
While the Athena update and install systems were developed for clusters of general use computers, demand for automatic update and minimizing administrative effort is far broader. Many workstation and server owners currently benefit from the Athena reduction in system administration workload -- particularly security updates. In recent years, mainstream operating systems such as Windows and Mac OS have added automatic software update services. Interestingly, these update services closely resemble early versions of the Athena update and might benefit from incorporating some Athena methods and concepts.
Now that Linux update via Red Hat Network is running side-by-side with the Athena install and update, a clear comparison will be possible. Opportunities to enrich industry standard offerings will emerge, as will a strong sense of which aspects of legacy support are truly appropriate to abandon.
Acknowledgements
We are indebted to Rebecca Frankel who was handed the list of 200+ Athena RPMs and asked to describe why they exist by talking to members of the Athena Release Team. She produced the first draft of this document.
