From: werner@inesc.inesc.pt (Werner Vogels)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 13 Apr 92 14:46:19 GMT
Article-I.D.: darkstar.32800
Organization: INESC - Instituto de Engenharia de Sistemas e Computadores, Lisboa, Portugal
Originator: osr@ftp

In article <32507@darkstar.ucsc.edu>, ast@cs.vu.nl (Andy Tanenbaum) writes:

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

1) Real distributed operating systems are hard to find. 

   There are no distributed operating systems that fully offer the support for
   fault-tolerance, transparency, state sharing and scalability needed to build 
   distributed systems and applications in a way we want it.

   Most of the new systems carry the burden of support for non-distributed
   monsters like BSD4.3 of System V r4 (even binary compatibility). The support
   for these hides most of the benefits of (minimal) support for distributed 
   operations.
   
2) Communication speed is the dominant requirement for distributed computing.

   Achieving high-performance even if the components of your application are at 
   different locations is the key issue in distributed systems. 

   The high level approaches to give application developers correct tools are
   worth nothing if they are not based on support systems that provide low
   latency and high throughput. My view is that these support systems should
   exploit the network technology where ever possible. Different classes of 
   protocols are needed to exploit the low-error rate, high availability, low 
   delivery delays, multicasting facilities, etc that are common in most of
   the widely used LANs and MANs.

3) We should learn more from the real-time world.

   We tend to divide the world into those that do real-time and those that don't.

   But it will be hard to find a distributed application that not requires some 
   form of timeliness or synchronization control, areas in which the real-time
   people have a lot of experience. 

   Using Gigabit Networks, multiprocessor workstations with many mips, 
   multimedia support (hardware?) will give us an environment in which we will 
   desperate be needing to knowledge that seems now exclusive to real-time 
   researchers. If we want are applications to be "responsive" we need more
   integration.

4) Simple RPC isn't good enough.

   There are many different application requirements that can not be solved 
   in an elegant way by RPC. You will need extended RPCs to support a-synchronous
   support (or multiple threads to keep them blocking, but achieve the same) and
   then you will need multiple addressing to handle replicated serves, and the 
   different agreement modes to handle Quorum, all-or-none etc, and then .......

   RPC is a good, simple and powerful method but I think that there are many
   situations in which the application developer would want different methods 
   in which he can control replication, competition and cooperation.

5) Any paradigm is good.

   As long as it meets the needs of the class of applications you are trying
   to build, it doesn't matter if is client-server, processes, files or group.
   
   Although structuring decentralized activities around groups of participants
   for reasons of consistency, user-friendliness, performance and dependability
   seems very attractive to me, I believe that there are many other paradigms 
   that satisfy the philosophy of other developers and therefore have reasons
   of existence and are entitled to be supported.

-- 
Werner Vogels

INESC - Distributed Systems and Industrial Automation Group
        Tel: +351 1 3155150 ext 280, Fax: +351 1 525843
	e-mail: werner@inesc.pt / C=pt;A= ;P=inesc;S=werner