From: fouts@hplmf.hpl.hp.com (Martin Fouts)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 10 Apr 92 17:00:19 GMT
Organization: Hewlett-Packard Labs
Originator: osr@ftp

In article <32507@darkstar.ucsc.edu>, ast@cs.vu.nl (Andy Tanenbaum) writes:
|> 
|> Gee, reading this newsgroup is more fun than whacking a hornet's nest with
|> a baseball bat.
|> 
|> [...], 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. 
|>
|> 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:
|> 
|> [...]
|> Martin Fouts
|> [...]

Rather than being a hornet and taking a wack at Andy Tanenbaum's list
(with which I disagree,)  I'll accept his challenge and state the five
most important things I've learned.  What is important to you is
likely to be different:

1)  It is possible to implement a usable distributed computation
    without a distributed operating system.

To me, this is the single most important statement to make about
distributed operating systems, because by demonstrating the validity
of this statement, I demand an answer to the question:  "If I can get
two ordinary operating systems with networking facilities to cooperate
well enough to allow me to implement my application, why do I want a
distributed operating system?"  This question has a major impact on
the sort of distributed operating system I might design, and the use I
might put it to.  It defines the scope of the domain of discourse.

2)  It is sociologically desirable to implement distributed operating
    systems which allow decentralized control.

There is a large class of problems in which a centrally controlled
distributed system is an effective solution, such as airline
reservation systems.  There is another class, involving cooperative
access from workstations to shared resources, such as file and compute
servers and other workstations which require users from separate
administrative domains to cooperate for finite periods of time in a
distributed way.  This class is exemplified by the alliances which are
formed within the aerospace industry to compete for government
contracts.  A single system may concurrently and transiently
participate in a number of "distributed systems" for the purpose of
collaboration, and the distinct distributed systems may be untrusting
of each other.

3)  A useful distributed operating system is one which either enables
    solutions to problems which could not otherwise be solved or
    provides a solution which is preceived to be better than the
    alternatives.

In the light of 1, this is not as trite an observation as it might
sound, because it implies that we must implement systems which can
compete with the alternative, which is the ability to solve the same
problem without requiring a distributed OS.  As far as I now know, the
only claim that might be made to support a distributed OS rather than
a distributed computation is the potential for ease-of-use.  I don't
make ease-of-use my third claim because it hasn't yet been
demonstrated and I'm not yet certain that efficiency might not
eventually become a claim for a distributed OS over a distributed
computation.

4)  There are multiple paradigms which can be supported in building
    the abstractions for a distributed operating system, and it is
    not yet clear which should be included.

I cite the debate in this group in recent days.  It is clear that
agreement on facilities to implement or even implementation techniques
is not yet achieved.

5)  There is no one right way.  From the collection of paradigms, it
    is not possible to select a set and say this is the optimal
    solution for all users under all circumstances.
 
I believe that this is the reason for the debate in this group.  It is
not that some of us have "seen the light" and others are in the dark,
but rather that we have been looking at problems in different parts of
the problem space, and have come up with appropriate solutions to
those problems.

The theme connecting the above is that after 20 years, we do have a
problem statement.  And we do have a number of implementations to
evaluate.   Now we need to spend some more time actually using those
implementations before we generalize the solution.

Marty

-- 
Martin Fouts                  |  M/S 1U-14
EMAIL:  fouts@hpl.hp.com      |  HP Laboratories
PHONE:  (415) 857-2971        |  1501 Page Mill Road
  FAX:  (415) 857-8526        |  Palo Alto, CA 94304-1126

Nothing Left to Say (c)