A lot of people are saying stuff like "DIPC is a small, self-contained
patch. Its just like a device driver. Its a compile time option, so
if you don't use it, just say no" With respect, this isn't like a
device driver at all. It is an API, more like, say, Berkley sockets.
Now as we all know, while Berkley sockets are primarily a network API,
you almost always need them even if you're not on a network, because
lots of client/server stuff won't run even on a single box without
them. This is because a lot of developers say, "Why should we bother
with unix domain sockets? If we use Berkeley sockets for our
client/server communications, we don't have to worry whether the
client and server are on the same host or not". So, a single host
becomes a kind of degenerate case of a network. In the case of
sockets, talking over BSD sockets on the localhost is nice and fast
and doesn't hurt the OS, so it works fine.
Now think about DIPC. Aren't developers going to say "Hell! This
DIPC is a good idea, because I can just write my app using DIPC and
not worry about whether the machine is part of a cluster or not".
Thus, we may get a situation where, even if you're not part of a
cluster, you need DIPC to run certain software, because the APIs
"transparency" and usefulness have led developers to think about a
single host as just a degenerate case of a cluster. This is why I
care, and this is why I say DIPC as is shouldn't go in. If a new API
has to go in the kernel (and there are a lot of good userspace
solutions that suggest that something doesn't have to go in the
kernel), its should work well, because if we provide a useful API,
people will use it, and soon you may not be able to "just say no" and
still run the apps you want to.
A lot of people have been posting stats about performance and saying,
in essence "Well, hardware's getting faster all the time, so who cares
if stuff is slow". Basically 15 years ago, I punched cards on the
biggest computer in our country which took up a whole building and had
64K of core. Now I have a pocket organiser that has 3Meg. Am I
satisfied with the RAM in my organiser? Of course not! Why? Because
people's expectations rise even faster than hardware improvements can
keep up with. Good design doesn't have to look for improvements in
hardware to solve the performance degradation it causes, because it
doesn't cause any. Thinking that new hardware is going to solve your
code's performance problems is a very dangerous idea, as anyone who's
had a Sun IPX "upgraded" from SunOS to Solaris can tell you.
I've been accused of FUD. Asking people to justify design ideas and
think the implications of those decisions isn't FUD. It's called "peer
review", and can be found in any book about software engineering best
practise. In fact, one of the reasons that linux is as good as it is,
is that we have kick-ass peer review. The best I've ever experienced.
It happens on this list.
Finally, I've been accused of making "an emotional appeal against
mediocrity". I sure as hell do get emotional about mediocrity. I
think that's a good thing. If anyone's perfectly happy with
mediocrity, then I don't think I have anything further to discuss with them.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/