From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.research
Subject: A challenge
Date: 9 Apr 92 19:09:12 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
Originator: osr@ftp


Gee, reading this newsgroup is more fun than whacking a hornet's nest with
a baseball bat.

I am quite unconvinced.  While I could go after each of the comments posted
here in the past couple of days, I will resist the temptation.  Instead,
for the second act, I hereby challenge all the people who have commented
on my list to do better.  List what YOU consider the five most important things
we have learned about distributed operating systems in the past 20 years.
If you don't think we have learned five things, a shorter list will have to do.
A short statement followed by a short explanation will do nicely.
If you don't think we have learned anything at all, be brave enough to
state that publicly, and hope NSF and DARPA don't read this newsgroup.

The challengees are:

Arindam Banerji
Ken Birman
Steve Chapin
Geoff Collyer
Crispin Cowan
Gary Craig
Mark Day
Fred Douglis
Dick Dunn
Amr El-Kadi
Martin Fouts
Glenn Kasten
Husam Kinawi
J.P.Knight
Ari Lemmke
Jacob Levy
Andy Lowry
Richard M. Mathews
Larry McVoy
Ronald G Minnich
Peter Moylan
Andrew Mullhaupt
Michael O'Dell
Thomas Page
Jehan-Francois Paris
Craig Partridge
Rob Pike
Boris Putanec
Marcus J.  Ranum
Dave Safford
Nirad Sharma
Niranjan G Shivarat
Charles Shub
Charles Bennett Smith
Stephen P Spackman
Henry Spencer
Dave Stow
Werner Vogels
Brent Welch
Phil Winterbottom
Brian Witt
Victor Yodaiken
(And of course, everyone else who has not yet put in his or her 2 cents worth.)

I'll be a sport and go first.

                              THE TOP FIVE

   1. Microkernels are the way to go.
         For the system to work, the kernel has to be reliable.  Putting the
      file system and other user services inside makes it harder to get right
      and less flexible.  The performance loss is (guess) less than a factor
      of two.  If you worry about factors of two, I humbly suggest you write 
      all your code in assembler henceforth.

   2. Synchronous (blocking) communication is easier to use than asynchronous.
         Starting a send, then going off to do something, followed by getting
      an interrupt when the send is done is a nightmare to program.  If you
      must do something while waiting for the reply, put that code in another
      (synchronous) thread.  The biggest problem in the computer industry is
      not slow machines, but hairy, unreliable software.  Using asynchronous
      communication just makes the problem worse.

   3. RPC is a good idea to base your system on.
         SEND/RECEIVE primitives make I/O your central paradigm.  RPC makes
      procedure call, an abstraction mechanism, your central paradigm.
      Abstraction is a key tool for mastering complexity.  We need all
      the help we can get.

   4. Atomic group communication (broadcast or multicast) is highly useful.
         Not all communication is two party.  For replicated servers and many
      other applications, being able to send a (synchronous) message to
      everyone and know they all get it in the same order without loss makes
      programming easier and programs more reliable.  A real win.

   5. Distributed shared memory in one form or another is a convenient model.
         Even better than communicating synchronously is not communicating
      explicitly at all.  Just let the programmer think there is shared
      memory, be it page-based, object-based, or other.  Let the system
      do the work.  There is an obvious analogy with virtual memory.


As you can see, all of my points relate to one theme: making it easier to
build and use distributed systems. I think this is the real issue of the coming
decade, not squeezing another factor of two out of the hardware.  Improvements
in technology will take care of that.

Andy Tanenbaum (ast@cs.vu.nl)