From: mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum)
Newsgroups: comp.os.research
Subject: Re: Andy Tanenbaum hasn't learned anything
Date: 7 Apr 92 18:49:48 GMT
Article-I.D.: darkstar.32326
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Originator: osr@ftp

henry@zoo.toronto.edu (Henry Spencer) writes:

>I'm reminded here of a recent piece from John Ousterhout in OSR, arguing
>that the customers do not *want* wonderful new abstractions -- what they
>want, mostly, is better implementations of the old ones.  Sounded good to me.

	I used to always hate philosophers who play word games, so I'll
indulge in a few myself. I believe this is an important issue. Enough
so that I'll risk stating the obvious.

	The thing that's always fascinated be about operating system and
software design is the way people (ab?)use the word "abstraction". An
"abstraction" is, roughly, a model that generalizes a concrete entity,
to make it easier to deal with and understand. In its highest form, an
abstraction serves to clarify and simplify something complex, by hiding
the details and the specifics.

	Thus, to me, a "wonderful new abstraction" is almost an oxymoron,
unless it's that someone has developed a newer, cleaner, simpler, and more
understandable way of thinking about something. This is distinct in my
mind from adding another level of indirection or "Object Orientation" as
many people advocate.

	It is hard to take a look at how operating systems do I/O over
a network, and to a local file system, and between processes, and to
come up with a single mechanism that handles them all gracefully, regularly
and consistently. A good abstraction for I/O will do this, and will
give the user an easy and consistent understanding of how the system
works in general. This is very different from, say, the XTI approach,
which is to wrap duct tape around a variety of intellectually dissonant
approaches and try to make them present a unified front.

	There's much too much of the latter taking place (because it's
easier) than the former. I think Ousterhout's remark and Henry's
amplification are right on the money. There are already existing and
excellent abstractions - what's needed is better implementations
that are more consistent and regular. The shining example of this in
my mind is Plan-9, which uses its naming space as an abstraction for
accessing many different types of objects in a consistent manner
(with the single and well-documented point-of-exception being ioctl).
This is not a "wonderful new abstraction" - it's a return to a pretty
darn good one that's been around for a long time.

	Of course, the mythical "user" doesn't really want any of
this stuff - they want to be oblivious to it, and to be able to get
their work done with the minimum amount of change and fuss. Often
that means that you have to give them Backward Compatibility - and
nothing is more deadly to a decent design than backward compatibility.

mjr.
-- 
The InterViews approach to hiding window system differences is like putting
on layer after layer of overcoats. Rob Pike's approach seems to be to dance
naked in the park.			[approximate] - USENIX, "Window Pains"


----- End Included Message -----