Desktop Linux? Stick a Fork in It!

It’s over. The magic is gone. The dream is dead. The egg has fallen off the wall and no amount of “sudo” super glue can put his pieces back together again.

I’m referring, of course, to the not-so-recent departure of Con Kolivas from the Linux kernel development community. Con – that champion of all things desktop centric – hung-up his keyboard this summer, the victim of an ideological rift within the Linux community.

On one side, you have Linus Torvalds and his true Linux “geekerati” underlings. These guys are mostly concerned with promoting Linux within the enterprise – i.e. Projects involving lots of parallel CPUs, massive storage and high-end TPC results. On the other side you have guys like Con who made it their mission to bring Linux on par with Windows and Mac OS X in the desktop arena. Things like smooth playback of digital content and better memory management for interactive users are what fuel their inner Linux fires.

Con stood out from this crowd because he did more than just complain about the jittery video and sluggish virtual memory behavior of Linux. He actually went out and wrote patches for the Linux kernel that helped address these issues, for example, by altering the core scheduling algorithms to favor interactive tasks (like audio or video playback). These patches proved to be real lifesavers for users seeking a better desktop experience under Linux, and Con quickly gained a strong following within this particular sub-community.

They say you haven’t really arrived in the entertainment business until you’ve played Carnegie Hall, and any Linux developer worth his or her salt knows that a patch is just a patch until it gets accepted by the kernel development team for inclusion in the primary code tree. And try as he might, Con never could convince the powers that be that his way was the better way, this despite copious evidence of the effectiveness of his patches. Con’s concerns – and those of like-minded Linux users who appreciated the need for a better interactive desktop experience – simply weren’t shared by those at the helm.

I’m highlighting this story because I see it as another clear example of why Linux continues to fail on the desktop. Despite all the warm, fuzzy talk of open source and community development, the fact remains that, at the kernel level at least, Linux is still controlled by a small group of elitist “prigs.” And if a particular feature or function isn’t a priority to them, it isn’t a priority for Linux as a whole.

Of course, this makes life that much more difficult for the Canonicals and Novells of this world. Stick too close to the “approved” Linux path and you end up with a crappy desktop experience. Stray too far, and you risk having your customizations broken if/when the kernel team decides to take things in a new direction.

Some have argued that, for desktop Linux to succeed, the code base will have to be “forked” – that is, a separate base image for desktop and server distributions. It’s an approach that has worked in the past, most notably with Microsoft Windows NT (and later Windows 2000/XP/Vista). As the Redmond behemoth has shown, you can have your cake (robust, shared kernel architecture) and eat it (separate code bases optimized for specific runtime scenarios) too.

So I say it’s time for the Penguin-huggers to face facts: When it comes to Linux on the desktop, stick a fork in it!