From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 13 Apr 92 00:13:28 GMT
Article-I.D.: darkstar.32796
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Originator: osr@ftp

In article <32708@darkstar.ucsc.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>1. A distributed operating system should look, to the customer, just like
>a non-distributed operating system, apart from the possibility of more
>creative failure modes.  Cleverness should go into hiding its distributed
>nature, not exposing it.

I disagree.  A distributed system should make it easy to build distributed
applications.  Many of these are distributed because thats where the machines
are.  And, in such cases, pretending the system isn't distributed is missing
the point.  Instead, it makes much more sense to acknowledge the distributed
nature of the environment and ask "what can we do for the people who have
genuine distributed applications"?

I really think that OS researchers have gotten stuck thinking that the
machine on their desk and the file system down the hall, and the person
across the hall with whom they are writing a paper (on distributed systems,
no doubt) are a "typical" distributed application.

If you follow the business section of your local newspaper, you will have
read about applications like these:

   EJV.  A consortium of banks and brokerages building a system that will
   span 500 sites with 5-150 workstations each (an estimated total of 10,000
   initially).  They need to present a whole collection of coherent, reliable
   services in this setting.

   Motorola's Iridium project: 77 satellites with perhaps 20 to 50 ground
   stations providing cellular communication services to hundreds of millions
   of callers simultaneously.

   MIT's Haystack project: a few dozen fully automated monitoring systems
   deployed around the arctic circle for various earth-sciences experiments.

   CERN's new accelerator: it has literally hundreds of beam focusing
   magnets, each associated with a local processor to control it, all
   coordinated (fault-tolerantly, one would hope).

   The fancy hospital of your choice: they would like a system that
   would beep the right doctor when the X-ray results come in, tell her
   where to find a room with nobody in it and an X-ray compatible display
   device, run an interactive application to gather the doctor's impressions,
   accept treatment "rules" from any point of access and guarantee that
   the treatment will carry these out.... try asking UNIX where something
   is sitting, where the doctor is located, where the closest X-ray
   display might be found...

This is just a few examples of "real" distributed systems projects that
I have heard about recently.  I could extend this list to literally hundreds
spanning every possible application of computers.  I should also say that
each of these applications goes beyond what I know how to solve with Isis,
so this list isn't for purposes of self-promotion.

Also, notice that in each of these cases, the distributed nature of the
application is what makes the distributed system interesting.  Hiding the
distributed nature of these systems is not a helpful approach.

He's my advice: if you didn't want a distributed system in the first place,
we pretty well understand how to provide you with an emulation of a
non-distributed system.  Go for it.  The emulation won't be flawless, 
though.  So, you'll end up concluding that distributed systems are sort
of like irritating, slightly flakey, non-distributed ones.

But, if you are interested in doing OS research, I think these are the sorts
of applications that point to the direction future work should take.  John
Ousterhout says "we don't need new abstractions, just better implementations
of the few abstractions that really work".  Well, I'll accept the part about
needing good implementations, but the business about not needing new
abstractions is totally misguided.  John doesn't have a clue concerning
these kinds of applications.  What we need, specifically, ARE new abstractions,
and new ideas, and whatever it will take to show successes in these sorts
of applications.

>2. Unix filesystem semantics -- resources organized in a tree structure
>named by ASCII names, and operated on by open/close/read/write -- work
>just as well in a distributed system as in a non-distributed one, unlike
>most of their competitors.
>
>3. Most resources are used by only one customer at a time, so it is
>important to streamline the *un*shared case while handling the shared
>case gracefully.
>
>4. Pipes are an excellent interprocess-communication method, superior
>to most of their competitors in flexibility and distributability (is
>that a word? :-))... provided you have some way of establishing them
>between unrelated processes, and preferably some way of passing them
>between processes dynamically.
>
>5. Most distributed-OS designers would rather design something new and
>weird, in hopes that everyone will say "oh, how wonderful, we must
>rewrite all our programs to use this at once", than observe point #1
>above and build a distributed implementation of the same old thing,
>on which all that software will run without change.

On what basis do you make these claims?  Patterns of resource usage at
University of Toronto Zoology?  Are you sure this is how the massive
distributed environments of the future will look?

And this last point, which seems to echo Ousterhout's silly remark,
just strikes me as negative and countrary to "progress".  If OS designers
can't be permitted the freedom to try things that are new and weird, how
can they be expected to narrow in on the things that really work, and
that will let people build the distributed applications of the future?
If the wierd stuff troubles you, wait for OSF to ship it to you; by then,
any new approaches will have been tested and justified ad tedium.  But,
I don't think you'll have much fun.

Really, this whole line of argument is very troubling to me, as a researcher.
Andy is right to raise the questions he has raised, and the community is
right to dispute some of the more far-out proposals.

But, when the party line gets sort of dour and dull and says that all
the problems we will ever encounter (including those we haven't even
encountered yet) can be solved by some technology that doesn't even work
very well 15 years after it was introduced, doesn't it seem like we have
things backwards?  Isn't there an element here of saying that Jesse
Helms knows art when he sees it, and if it doesn't look like art, the
public shouldn't be exposed to it?

What the community ought to be doing is precisely the opposite.  We should
be trying our wierd solutions on problems people haven't been able to solve
yet, and trying to understand what the solutions that work have in common,
and using this to make real progress in what our operating systems are
capable of doing!  Lets see some really novel distributed systems, and
try and understand why they work!


-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428