Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!agate!eos!shelby!msi.umn.edu!noc.MR.NET!nic.stolaf.edu!beowulf.acc.stolaf.edu!quanstro
From: quanstro@beowulf.acc.stolaf.edu (flash)
Newsgroups: comp.arch
Subject: What constitutes a good OS?
Message-ID: <1991Jan14.042520.18150@acc.stolaf.edu>
Date: 14 Jan 91 04:25:20 GMT
Sender: news@acc.stolaf.edu
Reply-To: quanstro@beowulf.acc.stolaf.edu (flash)
Organization: St. Olaf College; Northfield, MN
Lines: 112

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:

GENERAL PURPOSE:

One of the important goals of an OS should be to minimize the
programmers time and the code size. Programming is expensive to
everyone involved: it is programming time, not CPU cycles that's
really important. Computers are cheep; programmers are not. It is
difficult to write good programs. It is almost impossible to write
bug-free code and then maintain that code.  It is even more difficult
to ask the right questions, to find an efficient framework to consider
the problem. The key is reusablilty.  Code should be reused as much as
possible, and hence the concepts like a pipe is a very useful and
efficient one. A pipe saves extra programs---ones that YOU might have
to write, or have written for you. 
	An operating system should provide very general tools in which
the most problems can be addressed with the fewest and sparest
programs. I think of "features" as a bad word. As I consultant last
year, one guy I worked with put it nicely: "this damn thing has a hundred
thousand `features,' and not the one I want." No programmer can forsee
every feature that might be desired. I think that if a program is
properly conceived, that features only serve to muck up the code,
obfuscate the core of the problem, and consume disk space.
	The grep family (grep, fgrep (fixed-string grep), egrep
(extended grep)) are a reasonable example of general purpose
utilities.  The beauty of this type of program is that they can be
used to solve problems which had not been dreamed about when the
program was being written. I have written complete implementations of
the grep family, and worked with them daily over the past 2 years.
From this experience, I think that they are not trivial; in fact, I
think they provide too many features. For example, from the UNIX man
page on grep:

 -b   Precede each line by the block number on which  it  was
      found.  This is sometimes useful in locating disk block
      numbers by context.

Not only is this unnecessary, but it is also easy to break
programs/scripts that use this feature because block size
changes from computer to computer. In addition, extra makes it difficult
to reuse the function in other programs without recoding the whole
thing yourself. This is most inefficient use of resources.

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. 

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. 

PORTABLE:

For an OS to be really viable, it needs to be as hardware independent
as possible. Of course, there is a concomitant preformance penality.
However, this is really unimportant. We are not using PDP-11s with
paper tape any more, a few extra bytes and a few extra clock cycles
won't kill us. In fact, I'd doubt that we'd really notice. Consider
UNIX and MS-DOS. Because MS-DOS and finder were tied to a
particular chip at the outset, it cannot realize the full potential
other any other chip. Sure it is possible to run MS-DOS on a i486 and
it will run faster, although it will not use any of the capabilities
peculiar to the i486. Now try porting it to a RISC machine, or even an
68k based system. No way. It would be easier to start from scratch
(which implies starting again with all the applications programs as well).
UNIX, on the other hand, was recoded in C at a very early stage. This
has made it quite easy to port to just about any machine with memory
management facilities (absolutely essential for any computer that does
not live inside a toaster). With the progress being made in the
microprocessor arena, this has given UNIX an enormous advantage in
the leading edge of computing hardware.

EWQ
quanstro@stolaf.edu