Xref: utzoo comp.arch:20275 comp.os.misc:1487
Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.arch,comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <5233@auspex.auspex.com>
Date: 14 Jan 91 19:09:53 GMT
References: <1991Jan14.042520.18150@acc.stolaf.edu>
Followup-To: comp.os.misc
Organization: Auspex Systems, Santa Clara
Lines: 43

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