Slashdot Mirror
HURD For 'Big Iron'?
Julian Stoev wrote in with this query: "Recently I've seen quite a lot of conversation about Linux on 'big iron' and talk about a possible fork due to the fact that the Powers That Be do not want to include the necessary features that are necessary. A guy from IBM in an interview sounds a little desperate. He sounds like IBM is not very
happy with Linux's direction to small devices. The guy is cautious not to make kernel people angry and does not speak directly about kernel fork. But why don't they (IBM, SGI, et al) grab HURD and add to it all the things they find important for 'big iron' support?"
"HURD is not good for smaller machines because it needs more memory, but for big machines/clusters it can be very promising design. Why don't these vendors who moan about the lack of 'big iron' features start a 'HURD foundation' to help uplift the sleepy project? They could add compatibility for Linux binaries for compatibility, even which would be great as there would then be a powerful kernel (HURD) for 'big iron' and Linux for smaller and embedded systems.
Yes, HURD needs quite a lot of work to become stable, but large vendors have the resources to give it a push. In this way they will prove that they really appreciate open source by helping a project which is going through some hard times right now."
"What about the Alan Cox series?"
Ok. Apart from the Alan Cox series, Linux has never had a Code Fork in all of it's long existance.
"There are the L4Linux, L4KALinux and MkLinux microkernels."
Ok, ok! Apart from the L4Linux, L4KALinux and MkLinux microkernels, and the Alan Cox series, Linux has never had a code fork in all if it's long existance.
"There are patches from SGI (XFS, kernel profiling), IBM (JFS), and various other developers (timing patches, nanosecond clock patches, reiserfs, ext3fs, gfs, the international patches, freeswan, etc)"
OK!! So, apart from the patches, the microkernels, the Alan Cox series, Linux has never had a code fork in all of it's long existance.
"What about the UserLand Kernel?"
SHUT UP!
(Apologies to the Monty Python crew for this horrible bastardization of their excellent Roman sketch in Life of Brian)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
imagine big vendors trying to get along with RMS...
Vendor: "Hey Ricky darling! We're writing a killer App which will make everyone want to use Hurd.
RMS: "Are you going to let everyone copy it for free?"
Vendor: "No, but we're making the file format public domain. We're also explaining how the algorithm works in detail so that the GNU can make a free version if they want. We're supplying the source to anyone who wants to write a patch for it, or reverse engineer it. We just aren't allowing people to pirate copies of it."
RMS: "You're all evil scum. You have no right to make a profit from your work by restricting others from making a profit"
Vendor: "But they can make a profit. They just have to write their own version"
RMS: "You should give it away for free"
Vendor: "But we spent time and money developing this. We deserve a profit"
RMS: "You don't deserve anything"
Vendor: "Oh, sod this. We've changed our mind. We're going to make it secret closed source, with a restrictive license. Anyone who tries to compete we'll sue into oblivion"
The Hurd rocks, but it's not "rock solid". And not yet ported to anything else but i386, according to what I've heard. I had troubles installing it; first my ne2000 card gave troubles, then something as yet unidentified went wrong.
Added to this, it's a microkernel system. Big Iron doesn't need microkernels. They're a little bit slower by nature, but you get the advance of a small, configurable "mostly user-space" kernel. That's pretty cool for palmtops and everyday PC's but not Big Iron, I'd say. That's why QNX doesn't run on mainframes.
If Linux can't do the "big iron" thing, I think BSD would be a more serious alternative for now. NetBSD runs on almost every platform, so its kernel should be portable. And I hear rumours that BSD can do some things that Linux can't as of yet. (And vice versa, of course; that's not the issue. The issue is, maybe BSD will just be able to do the trick.)
GNU's Not Unix: this sentence is more important than you may think.
The HURD microkernel can be set up to listen to POSIX if you wish, but it can also listen to other stories. So here's a possibility to move away from ugly ol' POSIX in a decent manner, without having to completely abandon the ship like e.g. BeOS does, providing only POSIX as a portability layer.
The HURD microkernel allows you to mount filesystems in a "new, radical" way which takes away the requirement of seperate "/usr" dirs, etc. (The mounted fs will be mapped on top of the current one, IIRC.) The HURD microkernel allows for user space device drivers and kernel modules, which I think can in the end make the "UNIX experience" a lot less harder.
So I think that when it's finished, the HURD will be there for the common people and will supply more ease of use and programming freedom than Linux or BSD do now, because it's very flexible and can be set up very friendly towards the user (in my imagination, anyway). It will slowly move to liberate us from the less nice UNIX inheritance, as well.
But I simply do not think that Big Iron is a target of the HURD.
But I'm not very afraid about Linux loosing Big Iron. All we need is an open source kernel (isn't Caldera opening UnixWare?) for it. I don't care if it's a fork, has a different name or implementation. That's what standards are good for. All the tools and gears are here already, so it would be "easy" for e.g. Debian to make a Big Iron port, just as they did a Hurd and FreeBSD port once.
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Now which of these does HURD offer?
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.