Spork Bomb

A thread by opengl_cpp on the Ubuntu forums got me thinking about, well, why Hurd? Why Arch Hurd? I posted a short answer in that thread but now I'll try to answer more in depth here.

I always wonder why gnu project uses mach microkernel as its design basis. since there was a lot of advances to microkernel design such as l3 and l4 microkernels, it may not be a good decision to insist on old mach.

it has been proved that mach has some performance drawbacks in addition to its complex design, since l4 kernel is by far easier to understand and implement and also has performance superiority over mach.

Well, I don't know much about the variety of microkernels out there. In case you (reader, not opengl_cpp) didn't know, there have been ports of Hurd to different, or even completely new, microkernels, such as l4 and viengoos. They seem to have fallen out of favour with the Hurd dev community, though, so it seems we're stuck with Mach for the time being.

A reason for that could be inertia—so much effort has gone into writing Hurd for Mach it would be a pain to get everybody to learn the l4 or viengoos way of doing things. Which is a shame, really, if a different kernel could improve Hurd, it should really be given a fair try rather than just being an offshoot project with a handful of developers hoping it'll be an improvement.

blur xc asked a few questions about the Hurd and Mach itself:

1- What will the Hurd kernel offer than the Linux kernel lacks, besides the more fitting title "GNU Hurd" to the operating system?

Well, probably not much. The Hurd is a great idea, and they're doing brilliantly given the near-total lack of interest amongst open source users (not so amongst the Free Software crowd though). We can all, as Allan so brilliantly put it, bask in microkernally goodness. And, of course, we can play around with it—it's different, that's fun—but it probably won't offer much to us, for a while at least.

2- Driver support. Will the Hurd kernel need completely new drivers for all the hardware that's already running well under the Linux kernel? I understand the open source drivers could be ported across, but that's still a lot of work to do for a lot of hardware.

Currently, the Hurd uses drivers from Linux 2.6.0. Unfortunately, these are ancient, so it doesn't support fancy modern technology such as, oh I don't know… SATA. A problem, obviously, I can't even boot it on my laptop as it uses (to my surprise) a SATA HDD. I can boot it in a virtual machine, though.

There is work by Zheng Da to port DDE Linux26 to the Hurd from L4. This will, theoretically, bring support for Linux 2.6.29 drivers without any patching or rewriting needed. This also bring the possibility of, one day, having a DDE FreeBSD, or for any other OS, able to run their drivers in Mach.

OS-specific DDEs (Device Driver Environment) are a lower-level interface between what the OS drivers expect, and what DDEKit, the higher level driver abstraction layer, provides. As the OS-specific DDEs are only dependent on DDEKit, there is the possibility of porting DDEKit to another OS, and having all of the OS-specific DDEs come with it. Now that would be something wonderful.

3- w/ RMS being a FOSS zealot- does that mean there won't be any proprietary drivers permitted for hardware that doesn't have acceptable open source drivers?

I don't imagine RMS has supreme absolute control over the Hurd (well, I suppose he does, but you know what I mean…); third-party developers would still be able to develop non-free drivers, even if RMS did influence them away from the main Hurd distribution.

I don't imagine he'd be too happy about it… but I don't really imagine companies will begin porting their proprietary drivers to another OS, though in theory the DDE layer would allow you to run the Linux ones with Hurd just fine.

4- Same deal as above- but regarding Flash. Does this mean no adobe flash?

Heh, nor can I really see Adobe porting Flash any time soon.

5- in the end- what does that gain us?

A new kernel to play with, a new set of distributions to play with, and a great way to waste time. Isn't playing with the OS why most of us like Linux in the first place?