Notes for workshop talk Problems of Scale at Project Athena 28 January 1984, Zurich [Transcribed from handwritten notes] 1. Slight shift of gears I proposed to talk about networking of personal computers. After sending my proposal I took a new job, Technical Director of MIT Project Athena. Liba asked me to talk about that new responsibility But I've been there only three months, so don't have anything finished to report. So I will offer my assessment of the problems! 2. What is Project Athena? Several 1-line descriptors: a. MIT + IBM + DEC --> $70M total b. [Personal Computers + Networking] in support of [Undergraduate Education] c. 2 parts - Instant deployment, Development for the future | | 900 U/G use it now (25%) 2000+ next semester (50%) d. Strategy 0. Clusters of mini-TSS's [200 keyboards] 1. Serially reusable computers + Servers [2000 keyboards] 2. Student-owned computers + public computers + servers [5000 keyboards] e. Most development is application level, by faculty f. goals: 1) improved education 2) integration with fabric of university 3) 'coherence': ease of use (from educ. point of view) should move forward a generation The hard problems 1. UNIX is the best starting point we can find (malleable, VM, multilingual) but it is absolutely awful. Solution: evolve a new application environment. 2. Massive inputs required to track 4000 students; must integrate with other administrative systems quickly - but they are unprepared. (This problem appears despite the apparent decentralization of personal computers. 1) Is this student registered for that subject, so it is OK to use the subject's "courseware"? 3. Physical installation of a big network is hard. It takes time, it is expensive, and it requires people with mind-set of the telephone office, not of the computer hacker variety. Attention to detail/documentation; attention to fire safety rules; scheduling around a myriad of other activities of a university. + No off-the-shelf technology can hack it, so you have to do your own engineering gateways, topology, alternate path design, etc. --> Interesting problem, attracts the wrong kind of people! 4. Distributing software to 2000 computers is a hassle. They are hard to keep identical. Especially when some are made by DEC and some by IBM. Some have lab interfaces, some have better displays, etc. 5. Mail for serially-reusable workstations not off-the-shelf. In fact, almost nothing is. How are you sure the OS wasn't broken by the previous user? Reboot from where? (local disk may have been overwritten) 6. No one knows how to deliver the promise of Smalltalk and the LISP machine without forcing you to Smalltalk or Lisp. [Graphics and windows look more promising, though.] 7. Danger of ambush from behind: 20% of our undergraduates already own their own (smaller, usually) PC's. They need a way to "plug in" to participate. Non-problems - Seamless, network-wide file system w/ high transparency [would probably help some problems but a less seamless tapestry is still very usable] Current view of storage model: Goal - maximum utility w/ minimum development 1. Student files: floppy disk - Responsibility for backup is clear - eliminates quota concept - student does housekeeping or buys more 2. Student work area: Winchester cache --> for performance + central locker --> to allow using machines in lab, leave data for tomorrow or work at home 3. System programs, notices: central server --> centralized distribution +winchester cache --> performance 4. Class programs & data notices: class server, like system servers --> under control of faculty member 5. bulletin boards, mail: queued service 6. student-to-student communication: e-mail, ftp.