> I made a post with this title a few days ago, which asked a number of
> questions and was greeted by a lot of flamage. I'd like to address
> some issues.
You didn't expect flamage? You seemed to claim that you were doing
an impartial summary of the argument, and seemed to expect that
everyone would just agree with you and shut up. That is not likely.
> 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.
No, actually not. The existing SysV IPC API is used.
> 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.
This is the first time a reasonable fear has been expressed.
There is nothing to worry about though. From the man page:
: normal Linux kernels are not affected by DIPC programs,
: meaning that the there is no need to change and recompile these
: programs when they are to be executed in single computers with
: no DIPC support.
That is, you won't need to worry about DIPC.
> 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
One expectation is ease of software development. Your pocket organiser
is not programmed in assembly language.
> 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.
Why must you dictate what other people do in userspace? The kernel
(not mediocre) supports plenty of mediocre userspace software.
Scripts are slow... shall be remove binfmt_script to fix that?
-
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/