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 [EMAIL PROTECTED] wrote:
Hola,
Hiding the details of the underlying resources is one of the
functions/features of the OS, isn't it?
slds.
gabi
-- [EMAIL PROTECTED] 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
<[EMAIL PROTECTED]> 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
