Bill Hayden did the obvious: He forked AtheOS (which is technically similar to BeOS) and used its app_server and Interface Kit (without the use of X11) and rest of its kits on top of the 2.4.x Linux kernel. While the AtheOS kernel has some very nice features, by being modular, semi-microkernel, with good preemptive/multithreading support etc., it lacks a solid VM and swap support and of course, it lacks a good driver support, things that the Linux kernel provides. Bill Hayden accounced his fork on the AtheOS mailing list and made known that the "Atheos API has been merged with the BeOS API, there is PowerPC support, gcc 3.0.X compatiblity and OpenTracker/Deskbar as the desktop manager".

Well, I have to agree to a certain degree, with Hiddenbottom and KAMiKAZOW. The Linux kernel does not have a good approach to installing drivers, from the point of view of a desktop OS. Expecially when we speak of a media-oriented OS, where new hardware (heck, even new TYPE of hardware) with closed-cource drivers appear often and regularly. Now, can you imagine this scenario: company X (for example, MOTU) releases a new MIDI controller. Well, how does Linux support the device? It doesn't. Oh, of course, the next kernel will have support for it, provided that MOTU wants to open up some of the specs, provides a few header files... OK, so the next Linux kernel. Fine. WHo will want to install a new kernel? Not many musicians, I dare say. And what about recompiling it, so that it supports the symbols needed by the driver shiiped as a dynamically loadable kernel module? Because, I am afraid, this will be the next comment of a Linux evangelist: "you idiot/moron/ignorant, don't you know that Linux supports modules that don't need to be compiled into the kernel". Well, I know, but I also know that the kernel has to "know" in advance about the module.