Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!sdd.hp.com!spool2.mu.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <5461@auspex.auspex.com>
Date: 23 Jan 91 19:24:29 GMT
References: <42346@nigel.ee.udel.edu> <5427@auspex.auspex.com> <42488@nigel.ee.udel.edu>
Organization: Auspex Systems, Santa Clara
Lines: 97

>Sure. But I contend that that program to do either 2) or 3) with keyed
>files is easier than the program to do either 2) or 3) without keyed
>files.  I'm not insisting that you give up bytestream files, you know.
>(If you really want to know, the passwd file was edited by a special
>editor, so it falls under category 2. However, that editor did quite
>a few integrity checks that you don't get with the UNIX passwd editor :0)

Note that I referred to 3) as "the 4.3BSD solution"; it uses the keyed
file mechanism native to V7 and 4.xBSD, namely "dbm" or "ndbm".  I'm not
saying keyed files aren't useful; I'm saying that you can get somewhere
between 90 and 99% of the benefit of them without having to have them as
deeply "integrated" as you seem to want - i.e., going back to the
complaints about Plan 9, you could port the "dbm" or "ndbm" stuff, or
some B-tree package, or whatever to Plan 9 and that would answer almost
all the complaints about the lack of keyed files in Plan 9....

>The menus specific to the application are in the application's code.

That could be done with a separate file - or with *multiple* separate
files, one per language, each containing menu information for that
language, which seems a bigger win on a multi-user system *OR* on a
single-user system getting the application from a file server.  You
don't need to have the notion of a "resource fork" for this....

>A better example (because of the way menus are handled on the Mac) is
>"what file are the font resources associated with?"  Fonts that are
>available to every program are in the "system" file (vmunix
>equivalent).  Fonts that are available only within the specific
>application are in the application's executable file. Fonts that are
>available only within a particular document (say, that has been sent
>from somebody else (who knows you don't have that font) to you) are in
>the resource fork of that document.

The fonts attached to the application's executable could be in separate
files, with no loss that I can see.  The ability to link a font to a
document would be nice for the example you give of giving a document to
somebody else, although I'm not convinced that it needs two-fork files
or that two-fork files was the best solution.

>Another example: the window border is drawn by a WIND resource (or
>something like that). If you want a particular application to have a
>different-looking window, simply replace the WIND resource in that
>application file and it will override the one found in the system
>file.

See the comment above concerning menus; I'd rather not modify the
application file, especially if I'm sharing the file with somebody else.

>>I suspect that in most cases you wouldn't *want* to access them
>>randomly; tapes aren't known for their speed of random access....
>
>True. But again, you are making a pointless restriction.

It's pointless only if there's minimal software cost to allowing tapes
to be accessed as keyed files; if the keyed-access mechanism has to
"know" whether it's accessing a disk file or a tape file and requires a
significant amount of device-dependent code to handle the two cases, or
if some tape-handling software below the keyed-access mechanism has to
do a significant amount of work to hide the difference, the point of the
restriction is to avoid doing that development work for something that
seems like little benefit.

No, the point of the restriction is to simplify the
keyed-access-mechanism implementation, or the tape "driver"
implementation.  Either the keyed access mechanism has to know whether
it's dealing with a disk file or a tape file, and use the appropriate
lower-level operations for the medium it's using, or the tape "driver"
implementation - i.e., whatever the keyed access mechanism sits atop -
has to hide that difference.

>Most of your objections seem to be of the form "Well, I don't
>work that way, and here is how to get around the problem of
>which you speak."  I'm not trying to make you work my way.
>I'm just pointing out that there are other possibilities.

And I'm just trying to point out that the existence of the workarounds
means that it's not "obvious" that you need the mechanisms you're
advocating.  I.e., to go back again to the original complaints about
Plan 9 that started this thread, it's not clear that Plan 9 should be
worrying about the things you said they should, given that there are a
finite number of things they can actually do something about and they
have to choose which problems they want to solve, and that the problems
you cite can be dealt with.

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.

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 "acces
methods" atop such a platform, perhaps with some small additions made to
the platform.