Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <42792@nigel.ee.udel.edu>
Date: 25 Jan 91 18:43:03 GMT
References: <5461@auspex.auspex.com> <42617@nigel.ee.udel.edu> <5510@auspex.auspex.com>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 116
Nntp-Posting-Host: snow-white.ee.udel.edu

In article <5510@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>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....

OK.  So I exagerated a little.  The keyed text files were not the only
reason for having keyed files, tho.  So far, I have *still* not seen 
a good reason for putting it in the user-level libraries instead
of the kernel. All you have said (as far as I remember) is that
"Many people don't need it."

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

Ah, but in Amoeba, the Bullet server is not the only file server. There
is *also* a logfile server, a UNIX file server, and a database file server.
This kind of flexibility is what I think is lacking in Plan-9's
filesystem.

>"Data bases can
>be subdivided over may subdivided over many smaller Bullet files, for
>example based on the identifying keys.")

I agree that this is using the wrong tool. However, Plan-9 does not
let you do your own "right" tool.

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

But my objection is how the "filesystem" keeps you from making available
all reasonable operations because it insists on a bytestream model.
Note that processes, files, memory segments, etc are *all* in the
"filesystem" of the Amoeba system, in the messages-to-capabilities sense.

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

See my followup in which I discuss why I want this stuff in the kernel.

>>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.... :-)

They are, if that is how they implement their database. Actually,
maybe not, because the semantics of the Bullet server don't
require lots of overhead.  You could look at each bullet file
as a record or as a whole file, as you see fit, because you
don't need to name them, you can put direct references into
the other files, and so on.  But I would still prefer a 
database server.

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

That was my original intent in my complaints about Plan-9.  It just
came out wrong. 

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

Yes.  The Amoeba bullet file server is less complex than the UNIX
system, with the benefit of extreamly good performance. The disk-block
server allows sophisticated file structures to be built in user
libraries with minimal fuss.

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

Database backend filesystems.  CP-V filesystems.  PICK-OS file
systems.  Amoeba database filesystems. In all these cases, programming
was easier and more robust than trying to do the same thing under UNIX
because the kernel had more info and more control over the filesystem.

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

That doesn't answer the question of why UNIX did *not* put it in
libraries.   Amoeba did, and there are clear benefits to doing so.
Why not put TCP/IP in user libraries and just give people write-permission
on the ethernet hardware?  Why did UNIX make those choices, and why
do so many people defend those choices without actually stating
any benefits of having made those choices and not others?
	      -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee, Amigas -----
              =+=+=+ Let GROPE be an N-tuple where ... +=+=+=