Andy Tanenbaum hasn't learned anything
Ronald G Minnich
> - Distributed shared memory in one form or another is a convenient model
> Convenient for whom? This one baffles us: distributed shared memory
> is a lousy model for building systems, yet everyone seems to be
> doing it. (Try to find a PhD this year on a different topic.)
Convenient for the poor shmucks, down in the trenches, who just
want to get their distributed program running, and don't really like
RPC/whatever-current-fad as their way of sharing data.
What kind of systems is it lousy for?
You have a specific reason for the 'lousy' claim?
ron
Larry McVoy
: - Threads should be managed by the kernel, not in user space
: Better: have a decent process model and avoid this process/thread
: dichotomy.
I couldn't agree more. There is very little difference between a
thread and a process. People who like threads are really just covering
up the fact that their processes have gotten too chubby. Put 'em on a
diet, I say.
---
Larry McVoy (415) 336-7627 l...@sun.com
Henry Spencer
> False unless your only goal is to get papers published...
> - RPC is a good idea to base your system on
> Depends on what you mean by RPC...
> - Threads should be managed by the kernel, not in user space
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.
--
GCC 2.0 is to C as SVR4 is to Unix. | Henry Spencer @ U of Toronto Zoology
-Dick Dunn | he...@zoo.toronto.edu utzoo!henry
Marcus J. will do TCP/IP for food Ranum
>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 -----