Hi folks. Alan Cox here again, this time to address a serious issue that's come up recently in the Linux world.
Frankly, Linux development has become impossible of late—I spend far too much of my time and energy playing catch-up with Linus and his Lord-of-the-Flies approach to patching the Linux kernel. His criteria are based on what's shiny and novel rather than what's stable and needed. He's worse than a five-year-old in front of an Xbox. Such reckless practices threaten not only kernel stability and security but Linux mindshare as well. If we wanted to use unchecked code, we'd all be booting Windows.
For instance, just last week Linus and I both received a patch for SMP from Eric Raymond. My inclination was to fire up Pico and read through the code, gleaning what I could from comments and code-tracing, and then apply the patch to my test system and run stability tests. Eric isn't known for his programming prowess (though he'd have you think otherwise) and I'm not one to toy with such low-level chunks of the kernel. But while I was putting the new code through its paces, Linus had other ideas.
Before I could email Linus my first impression of Eric's patch, I received an instant message in ALL CAPS shouting about how he'd just committed the new code. I was incredulous, to say the least. There was no way he had time to manually parse through 384k of spaghetti code. Eric had no doubt been at the Jäger again and had made a grievous typo, having typed man(love) instead of main(). Had Linus taken the proper steps for integrating new kernel code, he would have caught that glaring error.
I am sick of cleaning up after Eric, but with Linus there is just no excuse.
Things weren't always like this. Linus used to take his time working on Linux, but when Linux started getting a lot of press coverage, he started getting sloppy. I understand the hectic schedule he had to endure with the interviews and press. But he let the fame go to his head at the expense of Linux kernel health. Going to work for TransMeta didn't help and moving up and down the West Coast only worsened the situation. Ironically, things haven't improved since he went to work for OSDL either.
After studying the GPL, conferencing with Linux vendors, and much soul-searching, I feel there's only one way improve this situation. Therefore, as of today, I am forking the Linux kernel. I will call it simply
Cox, keeping with the
x nomenclature common to Unix. And to ensure that hackers all over the world can have a stable operating system, I will be the head of Cox. I hope you, gentle reader, will support me in this ambitious new project to get Cox into users' hands as soon as possible.
The primary focus of Cox will be stability. Compared to Linux, Cox will be rock-hard. Another goal is security, and to that end Cox will fill as many holes as possible, and any bugs or viruses in Cox will be dealt with swiftly. Cox will also not leak nearly as badly as Linux does with its memory. Cox will also strain to avoid the hairy mess of incompatibilities Linux is infamous for. The net result of these improvements is that users will reach for Cox just as robust as when it first went up. Cox will also have longer uptimes than Linux.
In all honesty, Cox will likely split the Linux community in half. But the sacrifice will be worth it. Users will wonder what they ever did before they went with Cox. Linus himself will one day come face-to-face with Cox and realize what he has been missing all these years.
After speaking with Richard Stallman, another huge fan of Cox, I agreed to keep the kernel under the GPL. He assured me that the GPL was the best way to disseminate Cox. Richard seemed quite eager to install Cox in his back-end!
I hope the latent interest in Cox among Linux developers will soon become a driving obsession.