Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!decwrl!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <5510@auspex.auspex.com>
Date: 25 Jan 91 00:16:12 GMT
References: <42488@nigel.ee.udel.edu> <5461@auspex.auspex.com> <42617@nigel.ee.udel.edu>
Organization: Auspex Systems, Santa Clara
Lines: 158

>Except that your applications normally contain dozens or hundreds of
>different resources, and the system file can contain thousands.  Each
>menu item, each menu, each menu bar, each window, each window type,
>each button text, each button, each dialog window, each error message,
>each informative bit of text, etc is each a different resource.
>Therefore, you would probably want to make each application a
>directory, in which to hold all these little files,

What "little files"?  Did I say that each one of those resources would
go in a file of its own?  No, I didn't.

>Of course none of this *needs* a more sophisticated access method.  
>But I'll use a system where the things I need to do my job come
>with the computer, thanks. Again, I'm not arguing that UNIX
>should have such things added to the kernel, or even that they
>should be in there in the first place. Only that when starting
>from scratch, using essentially 20 year old file access methods
>seems like a bad idea.

To what "essentially 20 year old file access method" in particular are
you referring here?

>Normally, one does not modify the application while it's running.
>Also, the Mac has only one accessor for a file at a time.  However, if
>it is built into the kernel, shared access can be mediated much more
>tightly and efficiently than if it is handled through libraries.  The
>example of the WIND resource was for somebody adding a new look for
>windows at compile-time. The same mechanism might have been used to
>implement "tear-off menus" in hypercard -- the menu handling code was
>overridden in the application code at compile-time.
>
>>Many systems, including UNIX-flavored ones such as UNIX and Plan 9,
>>provide, as a "platform", a "file system" that provides access to named
>>randomly-accessible collections of bytes, and treat text files, keyed
>>files of various sorts, and data structures of sorts often *not*
>>provided by various OS's "access methods" as applications atop that file
>>system.  It doesn't bother me that keyed files in those systems aren't
>>at the lowest level of the file system; I see little if any win to that.
>
>But Plan-9 goes much further than that, in that all accessible objects
>are accessed like files are.

That wasn't your entire original complaint against Plan 9:

	From the 15 pages I've read about it, I see Plan-9 doing all the same
	things wrong that UNIX did.  They seem to have only files which are
	byte arrays, in spite of the fact that 99.44% of programs I've seen
	want records, and most want keyed records.

That part of your complaint was the main part I objected to, and I think
I've successfully demonstrated that "most want keyed records" is correct
only if you interpret it as "most folks who like CP-V's keyed text files
want keyed records"; unfortunately, the wins of CP-V keyed text files
seem to occur only in fairly specialized cases, like folks who carry
lots of line-numbered listings around....

(And if you're going to thump UNIX there, you might want to thump
Amoeba, while you're at it; the Bullet file server is actively *hostile*
to update-in-place keyed files of the CP-V sort that you were boosting
in earlier articles, since it doesn't let you write to files - it just
let you replace files with files. 

I think that's an *extremely* interesting idea, but it's going further
away than UNIX from some of the stuff you're advocating.  In fact, the
way they talk about handing database files in "The Design of a
High-Performance File Server" resembles, in some ways, the "throw each
entry into a file of its own" scheme you thump below - "Data bases can
be subdivided over may subdivided over many smaller Bullet files, for
example based on the identifying keys.")

The later part of the complaint:

	UNIX then seems to attempt to stuff every object that *isn't* a file
	into this same mode, and poorly at that. Plan-9 seems to be going the
	same way.

I have fewer problems with.  Another poster took that notion to what I
considered a *far* too extreme notion, namely overloading UNIX-style
permission bits to indicate which signals the process is catching, and I
objected to that in my reply.

I completely agree that blindly placing all objects onto the Procrustean
bed of text file access is a mistake.  I consider using "rm" to kill
processes - or, more particularly, to *send signals to* processes, as
"kill" is somewhat of a misnomer in UNIX - somewhat extreme; I'd
consider it equally extreme to use "mv" to do process migration.

>What is the motivation for such choices, and what *should* be the
>motivation for such choices?

The criterion I'd use is "if making some particular operations doable
through the file system makes it possible to use existing UNIX tools to
perform useful functions built on those operations, *and* won't give the
developers an excuse to avoid making common operations convenient just
by saying 'well, if you don't like it, wrap some shell script around
it'", I'd say provide a file system mechanism to do the operation.

>>I haven't seen any good evidence yet that you *can't* build an
>>"object-oriented" facility for implementing objects including but *not*
>>limited to the sequential/keyed/etc. files provided by most "access
>>methods" atop such a platform, perhaps with some small additions made to
>>the platform. 
>
>Sure.  I can write recursive algorithms in FORTRAN, too. I can write
>massively parallel, distributed, object-oriented code in C.  However,
>it would be cleaner, easier to understand, easier to get correct, and
>probably even more efficient to use the right tool for the right job.

See my followup to another article, in which I discuss "containers". 
Ultimately, all that code is going to end up as 1's and 0's (barring,
say, a base-3 machine); I've not been convinced that the 1's and 0's of
a typical "conventional" computer are necessarily any worse for that
purpose than the 1's and 0's of some of the
"high-level-language-oriented" computers that have been proposed in the
past, just as I've not been convinced that the 1's and 0's in
"containers" like UNIX or Bullet files are any worse than the 1's and
0's in the disk blocks maintained by OS's that support "keyed files" or
whatever at a lower level.

>Using directories as keyed files is something I consider as "the wrong
>tool."

Well, if you consider putting parts of keyed databases into separate
files based on the key values to be part of the reason it's using "the
wrong tool", you'd better let the folks doing Amoeba know you think
they're making a mistake.... :-)

>Restricting servers to only respond to a small number of
>kinds of requests and forcing non-file-like operations to use only
>file-like operators also seems like "the wrong tool."

*Forcing*, yes.  *Allowing*, no.

>$$$$ If you want to discuss only one point further, below is
>     the point I would like to discuss: $$$$
>
>As a matter of fact, I can write the UNIX filesystem on top of the
>FORTH filesystem, wherein individual disk blocks are read and written
>by integer index (i.e., disks are just arrays of blocks).  I have yet
>to see any good reason why one should have a filesystem that goes just
>as far as the UNIX filesystem does, and then stops. I've seen several
>good reasons for (and examples of) why you would want something *less*
>complex that the UNIX filesystem,

What sort of examples are you talking about?  Are you talking about
something less complex than a bucket of bytes?

>and I've seen several good reasons for (and examples of) something
>*more* complex than the UNIX filesystem,

What sort of exmaples, again?

>but as far as something *exactly* as complex as the UNIX
>filesystem, people usually just say "Oh, put it in libraries." Why not
>put directories, access-control, allocation, and concurrency controls
>in libraries?

Directories?  Sure, why not.