quanstro@beowulf.acc.stolaf.edu (flash) (01/14/91)
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.eduguy@auspex.auspex.com (Guy Harris) (01/15/91)
(Perhaps this should move to "comp.os.misc". I've sent followups there; if you disagree, remember to send your posting and any followups elsewhere.) >Plan 9 (an experimental system from AT&T) is better, but not worth >considering, as it is a research effort at the moment. Not worth considering from what standpoint? Not worth considering as something to buy for a site with N different vendors' machines, perhaps, as it's probably not available for them. I think it's worth considering as a source of ideas on how to make a good widely-available OS, though (along with many other OSes). >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. Yup - and it *does* on some versions of UNIX, e.g. S5R4 and, I think, the later Research versions. >It also eliminates the need for a program to get rid of unwanted processies: >just use the utility which removes files (rm). Well, maybe. I don't think the Research "/proc" did that, and I seem to remember that they didn't consider it the right way to go. I'm not sure why, but *do* note that there isn't a UNIX program "to get rid of unwanted processes" that I know of - there's a program to send an *arbitrary* signal to a process or set of processes, but not one to simply "get rid" of them (you can send SIGTERM with "kill", which lets the process clean up before exiting, but isn't a guaranteed kill; you can send some signal that causes a core dump, which may not let it clean up but may give it a core dump, but that's not guaranteed either; you can send a SIGKILL, which will kill anything not stuck in some unbreakable wait). >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. Exactly like a file being accesses sequentially, anyway. If you send "seek" messages to cope with random access, it won't look like a file to the guy on the other end, as they'll have to interpret those messages....
hp@vmars.tuwien.ac.at (Peter Holzer) (01/16/91)
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 |
ts@cup.portal.com (Tim W Smith) (01/16/91)
< 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 Programmers are cheap compared to end-users. The operating system needs to minimize end-user time. Tim Smith