Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!tuvie!vmars!hp
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Newsgroups: comp.arch
Subject: Re: What constitutes a good OS?
Message-ID: <2238@tuvie.UUCP>
Date: 15 Jan 91 18:53:14 GMT
References: <1991Jan14.042520.18150@acc.stolaf.edu>
Sender: news@tuvie.UUCP
Lines: 94

quanstro@beowulf.acc.stolaf.edu (flash) writes:

>There are no "right" answers to the question "what makes a good OS."
>It's just that some are better than others. I don't think that MS-DOS
>is a good operating system; neither is UNIX. Plan 9 (an experimental
>system from AT&T) is better, but not worth considering, as it is
>a research effort at the moment. Here are some of the keys to a more
>sound operating system:

You might want to look at Amoeba. It is a very elegant (IMHO)
distributed OS developed by Tanenbaum and his folks. Of course it is not
the OS you would use on your home PC: The minimum recommendet
configuration is a workstation or X terminal, a file server with >= 12
MB RAM and a few computers as ``processor pool'', all connected by
ethernet.


>GENERAL PURPOSE:

At the moment most tools in Amoeba are just Unix programs (really Minix
programs) running in a Unix-emulation. But I just have this wild idea of
a grep server which could be used by every program ...

>SINGLE NAMESPACE:

>One of the biggest shortcomings of UNIX, and the cause of many too
>many unnecessary utilities, is the fact that UNIX has forgotten its
>original premise that "everything is a file." Why is this important?
>Consider what would happened if the process table was kept in *the*
>(file system) name space. Then ls /proc to would report on which
>processies are running. It is also possible to show the parent-child
>relationship between processies in the tree structure of the
>file-system-prototyped namespace. This eliminates the need for a
>special utility (like UNIX ps) which shows the state of processies
>from a table which is hidden somewhere in the kernel. It also
>eliminates the need for a program to get rid of unwanted processies:
>just use the utility which removes files (rm). The reasons why this is
>a good idea are countablly infinite. 

I wholeheartedly agree. In Amoeba everything is a capability -- a 128bit
number. Human readable names (looking like Unix file names) are mapped
to these capabilities by a directory server.


>IPC: (links)

>I have yet to see a system to implement good IPC. MS-DOS doesn't have
>any. UNIX has pipes, fifos, sockets, ad nausium. There should be one
>type of IPC (link) which should cover all cases and work exactly like a file.
>I am not sure what type of IPC is best. But I think these are the
>three major points
>   Named:
>	IPC should be named and that name should live in the file
>	system (remember, only one name space) 
>   Transparent:
>	IPC should always work: so what if one of the programs is
>	across the  internet. Why should the user care about trivial
>	things like that? 
>   Bidirectional:
>	IPC should be bidirectional: it is impossible to have a
>	conversation if the person with whom you are talking cannot
>	respond.
>   
>	This implementation of eliminates the distinction between
>IPC a files. This has wild ramifications. First, it would cut a lot of
>cruft from the C library: it would be possable to use fopen and fclose
>to talk to a program through a link. In fact, the program doesn't even
>have to know that it's using IPC. 

Yes, after years of UNIX-programming I still haven't tried all the
possible IPC methods of UNIX. Just to rememember the right systemcalls
for every method is difficult (e.g. msgsnd is for message queues and
sendmsg has something to do with sockets ...). In Amoeba every access to
an object outside your program is an RPC (In fact the only systemcalls
are send, receive, and rpc (The names for these calls are different in
every paper about Amoeba I have read) everything else is implemented as
an RPC to the appropriate server).

>PORTABLE:

>For an OS to be really viable, it needs to be as hardware independent
>as possible. 

Amoeba already runs on 68000s 386s and VAXes and a lot of ports have
been announced.

DISCLAIMER: I have not worked yet with Amoeba, all I know is from papers
about it. Lots of info (some 20 papers, user's and programmer's manuals)
are available via anonymous ftp from ftp.cs.vu.nl.
--
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |