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

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 have to disagree with this statement somewhat.  The law of requisite
complexity requires that since a distributed system has more
capabilities than a local one (location can be important, as can
route) that it must require more facilities.  I would ammend your
statment to have the default case appear as it does on a
nondistributed system, in keeping with the law of least surprise, but
I would certainly demand access to the facilities which are present
because it is a distributed system.  Of course, if you want an ugly
problem, try maintaining unix semantics and implementing process
migration. 

|> 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.

Again, the law of requisite complexity would lead me to believe that
this statement is only true as far as it goes.  Certainly distributed
systems have name space and connectivity problems which are not the
same as standalone systems and require different resolution.  In
addition, heterogeneity may lead to a demand for typed files(?) and
the sheer volume of filenames in a reasonable distributed system
demands a better lookup mechanism than find.  Also, there are a whole
collection of version administration problems which just don't exist
in a standalone system that Unix filesystem semantics don't address.

|> 
|> 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.

Yes.  Also, most references are "local", so you have to optimize the
local case.  The vast majority of the rest are predictable, which is
one of the things that the Plan-9 design takes effective advantage of.

|> 
|> 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.
|> 

I think you need to look some more at problems which require broadcast
for solution before you draw this conclusion.  There are a lot of
distributed computing problems, especially in distributed parallel
applications for which the pipe model falls apart completely.

|> 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.
|> -- 

No.  Most distributed-OS designers are in fact going to far too support
existing models.  The optimal approach is that we should design
systems which preserve the semantics of programs which do not need to
change, as far as we can, without them getting in the way of building
distributed applications.  There is nothing wrong with providing a
"POSIX API" (sic) as long as we don't have to use it when we try to do
things it wasn't designed for.

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)