From: wittbj@cube05.ccs.csus.edu (brian witt)
Subject: Re: A challenge
Organization: California State University: Sacramento, USA
Date: Wed, 15 Apr 1992 20:14:25 GMT

In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>  List what YOU consider the five most important things
>we have learned about distributed operating systems in the past 20 years.
>The challengees are:
>Brian Witt
>(And of course, everyone else who has not yet put in his or her 2 cents worth.)

Oh boy, a soapbox!  :-) :-) :-)
Frist a point of objects, and then my soapbox speech.

I. First from using C++ to build an OS.  It helped out, but C++ just wasn't
enough.  I want Eiffel. I want pre-conditions. I want generic lists with
a paramter type (ie, a type that performs at least a few operations).
I want descriptive verbs (for object methods)!

A point my C++ partner brought up: some C++ code has to be executed to
know definitly what it will do. Humans can't hold the more than
seven rules you need to remember!  :-)  Not the best thing to say
about a possible kernel writing language.

II. Now I would like to argue for a higher level of programming awareness...
(Such a zen comment... :-)  Perhaps synchronous communication and RPC
as "good things" today cuz we deal with "C" and Pascal as programming
languages (very vonNeuman like).  However, these languages don't really
map too well to the model of a distributed, multi-processor computer
*system* with possible shared memory and different variables having
different access semantics (access times and concurrenct requirements).

It seems your (A. Tanenbaum) points deal with implementation issues.
I think my points are more optimistic and deal with higher level issues.

III. I'd like to drop a few language names: Argus, Eiffel and Hermes. 
Microkernels are good because a small amount of code can be *proved*
correct.  Are C assertion macros enough?  I believe Eiffel's pre- and
post-conditions, looping invariants, and class (or module) invariants
provide excellent controls on validity assurance.

Should a network global variable have hard commits, or is it good enough
just to remember a value similar to the most recent update?  (This
part is from memory from a class I took last year.) Argus allows
different "stickiness" for different variables.  Monitors can be
described rather easily, and the client of some code doesn't have
to worry about these details!  Location indepedence/transparency
is something the compiler and runtime system should optimize for you.

Functions as first class objects can be very benifical in a distributed
system.  (Amoeba also has this desired feature.)  "Work" can be contracted
out to another node, where it might be closer to hardware resources.
But will it perform correctly, and will it interfere with other processes
on that remote node?  Hermes with its dataflow analysis hope to ensure
that processes will co-operate in a friendly manner.  Error recovery
sematics are never easy, but if you know them, and your language can help
out, disasters can be recovered from.

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

>Andy Tanenbaum (ast@cs.vu.nl)

I hope to see you and Robbert vonReessen at the Microkernels Conference!

-- 
======================================================================== !
   Brian Witt     [Sac State Comp Science]   "Waldo, the pariot, is dead"
   Internet:  wittbj@cube01.ccs.csus.edu               -- Agent Cooper
Newsgroups: comp.os.research