Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia <eris.discordia@gmail.com>]

> Hiding the details of the underlying resources is one of the
> functions/features of the OS, isn't it?

Bjarne Stroustrup likes to call that "data abstraction and encapsulation;"
in a different context. But the essence of it is the same. Operational
details have to be "hidden," functional ones not. You don't want your OS to
"abstract" your latest and best hardware's capabilities by dumbing it down
to 80286. You also don't want your OS to generalize at the cost of fitting
all sorts of resources into one model--it can't be done.

--On Thursday, November 13, 2008 3:25 PM +0100 gdiaz@9grid.es wrote:

> Hola,
>
> Hiding the details of the underlying resources is one of the
> functions/features of the OS, isn't it?
>
> slds.
>
> gabi
>
> -- eris.discordia@gmail.com wrote:
>>
>>> you of course know that the big difference in unix and other
>>> systems of the day was that files did not have type. this allowed
>>> a tools-based approach which was popular for many years.
>>
>> Not that type of "types." I gave an example (which Charles Forsyth found
>> to  be a bad one) to set the types of "types" apart. I mean "types" as
>> in named  pipes ("special" files) versus regular files. In my experience
>> which is  limited to "modern" UNIX clones, i.e. Linux and *BSD, you can
>> distinguish  between a number of file "types" and decide what to do
>> accordingly. You can  tell a directory, from a (character or block)
>> device, from a link, from a  regular file. These same "types" could, and
>> have been, be used to represent  some details of the underlying resource.
>>
>> --On Wednesday, November 12, 2008 6:11 PM -0500 erik quanstrom
>> <quanstro@coraid.com> wrote:
>>
>>>> Why shouldn't there be file "types" to
>>>> help better represent the details of an underlying resource?
>>>
>>> you of course know that the big difference in unix and other
>>> systems of the day was that files did not have type. this allowed
>>> a tools-based approach which was popular for many years.
>>>
>>> - erik
>>
>>
>>
>>
>>
>>
>
>