Will Mosix go into the standard kernel?
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.Daniel Ridge newt at scyld.com
Wed Feb 28 17:35:09 PST 2001
On Wed, 28 Feb 2001, Albert D. Cahalan wrote: > > The Scyld system is based on BProc -- which requires only a 1K patch to > > the kernel. This patch adds 339 net lines to the kernel, and changes 38 > > existing lines. > > Well, that explains your viewpoint and your motivation. :-) I would put this the other way around. I would say that Scyld reflects the views of its core developers -- not the other way around. Those of us who worked on the Beowulf project at NASA felt then exactly as we do today. > ALSA: driver work gets done twice It's an irrelevant detail if only one works. I've used the kernel's brand of sound support and it mostly works. I'm usually too lazy to get ALSA. I only use it when the kernel's support hasn't quite caught up to ALSA's > pcmcia-cs: this was so bad that Linus himself was unable to install > Linux on his new laptop, so now PCMCIA support is in the kernel. I often have exactly inverted problems with CardBus. It's true that external packages often start to look like geologic rock samples -- the sediment record of linux -- and that they become a record of the things that have changed. Funniest, I think, is when these packages record interfaces that merely churn without improving. Naturally, it takes work to created a supportable piece of system software that can be used on a number of platforms. I would also cite from your text above: "driver work gets done twice". > VMware: quite a pain I think I think not! Installing VMware today is a breeze. SMP or UP? No problem! Upgrade your kernel? No problem! Outstanding for a commercial third-party application that happens to be available on two different platforms. I would also add Myricom's GM package for Myrinet to the list of reasonable components that are maintained outside of the kernel. Vendors should be encouraged to provide the kind of commitment to linux that Myri consistiently demonstrates. > You are basically suggesting the often-rejected "split up the kernel" > idea. I think the linux-kernel FAQ covers this. No. I'm stipulating that I work with a really interesting piece of software that works with the Linux kernel and is available under the GPL and which we have never even bothered to 'submit' as a patch. I'm willing to suggest further that any responsible development community is suceptible to "race conditions" whereby the natural and studied development and evaluation process is end-run by attempts to 'win' and urinate on the kernel or ANSI or POSIX or whoever (with a facility or mechanism) directly. These types of 'hacks' or 'denials-of-service' play on the adage that forgiveness is easier than permission. It's hard to dispute this point in an age when SourceForge makes it possible for anyone to maintain a driver or filesystem or whatever without needing to 'hitch a ride' on an existing project (ala linux) that already has a distribution and mirroring facility. > So people should only get kernels from linux vendors? This is great > for your business I'd imagine, but one of the nice things about Linux > is that you can replace the kernel without too much trouble. No. My point was that it is possible to do a reasonable job and that building a kernel and subsytems so that the result is deliverable and supportable is very hard -- harder than building a kernel and ALSA for just yourself -- and that external components can be resonably done even in the tough vendor environment.
More information about the Beowulf mailing list