Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!harpo!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!young@uci-icse.ARPA
From: young@uci-icse.ARPA (Michal Young)
Newsgroups: net.micro
Subject: What Unix needs is ...
Message-ID: <9998@brl-tgr.ARPA>
Date: Tue, 16-Apr-85 15:45:12 EST
Article-I.D.: brl-tgr.9998
Posted: Tue Apr 16 15:45:12 1985
Date-Received: Thu, 18-Apr-85 07:54:21 EST
Sender: news@brl-tgr.ARPA
Lines: 23


  Many recent messages have asserted or conceded weaknesses in the basic
design of Unix.  Let's get concrete and start listing operating system
properties and/or facilities that we want, and that Unix doesn't provide.

For starts:
  An operating system should provide a flexible and efficient method for 
processes to communicate.  The Unix `pipe' mechanism has the great advantage
of simplicity,  but it is not efficient for some kinds of interaction.  
For instance, consider the case of the C compiler divided into several 
passes that communicate via pipes.  One correspondent to this bboard suggested
that it should be reconstituted as a single monolithic process, but that 
would be a workaround rather than a solution.  If a stronger communication
system were available, which allowed for instance sending large data structures
by sending pointers (for instance, by mapping parts of the address space of 
one process into that of another), then you could have the modularity of the 
Unix small-process model with the efficiency of the monolithic approach.
  Most modern compiled languages have visibility rules based on nested 
scopes.  How hard would it be for an operating system to support similar
rules for address spaces of processes?

--Michal Young, UC Irvine 
  young@uci