Nearly five years ago, I installed my first Linux distribution: Lycoris Desktop/LX, a “for desktops” distribution that attempted to copy the look and feel of the then-recently released Windows XP. While I found it interesting, I ultimately switched back to Windows, as Lycoris didn’t provide a very good, in Microsoft marketing speak, “user experience”; it was ugly compared to XP and lacked support for window alpha channels (causing such effects as menu fades to look fake and unconvincing), I had to fight with it for hours to change the “default browser” to Firebird, as it had no unified default browser setting as windows did, installing software was essentially impossible, and the list went on. (Now, to be fair, Lycoris was very much outdated even by 2003 standards; it still used KDE 2 while every other major distribution had already moved to version 3, and its libraries were so ancient that no package would install.)
Fast forward to one year later: having installed and used various Linux distributions on and off in the time (though still sticking with Windows XP as my primary OS), I had become much more well-versed in the ways of Linux, and felt it was time to put my newfound knowledge to some use: I decided to set up a Linux distribution as the primary operating system on my family computer. The purpose of this endeavor was to leave Linux on the computer for a week and evaluate its performance in an article I was writing for my high school newspaper. For the distribution, I decided to use Xandros, what I viewed (and still view) as one of the best of the desktop-oriented distributions available at the time.
Xandros performed quite well on the computer; for example, it proved itself capable of working with certain hardware devices without any driver installation, which Windows would require the manufacturer’s drivers. However, in one particular area, it fell flat: scanning. While its included Xsane application was functional, it didn’t work particularly well with our scanner and frequently returned very poor quality scans. With a week having gone by, I switched the computer back to XP, concluding in my article that Linux, while itself ready for the desktop, wouldn’t truly reach that stage until hardware manufacturers would pay more attention to it and release official drivers for Linux.
This brings us to the present day: desktop-oriented Linux distributions such as Ubuntu are becoming progressively more refined, Windows Vista is in many ways a step backward from its predecessor, and relatively inexpensive subnotebooks such as the ASUS Eee PC are shipping with Linux as their default operating system; the stage seems set for Linux to rocket to center stage at last. Or does it?
My original conclusion, while in a sense correct, was sadly quite naive. Indeed, hardware manufacturers were not providing the support to Linux that they devoted to Windows, and to a lesser extent, Mac OS X, but as I now know, they could not, and still cannot, provide this support even if they wished to.
For Windows, Microsoft provides several sets of standardized APIs that provide both binary and source compatibility with previous and future versions of Windows. For example, Realtek’s WDM drivers will work on any version of Windows from 98 to 2003. (While WDM audio drivers still do work on Vista, the rewritten audio stack requires newer drivers to work fully.) Likewise, Mac OS X provides some binary compatibility with drivers between versions. Linux, however, does not provide any driver binary compatibility between even minor releases, and instead takes a different approach.
On Linux, most hardware drivers are not provided as separate installs, but are present in the kernel source tree itself. This provides a few obvious benefits: namely, that Linux provides extremely good out-of-the-box hardware compatibility. (In fact, I’d argue that today’s premier Linux distributions work better immediately after install than Windows.) Additionally, all drivers included must be open source, and therefore can be supported by the kernel developers. (This can be especially useful for hardware made my companies having gone out of business.) Despite the benefits, this system presents several major flaws.
If I buy myself a USB sound card, I expect it to work with my computer, either A) out of the box, or B) after the installation of some software that came with it. On Windows or Mac OS X, such things frequently won’t work fully out of the box, but run fine after some kind of driver installation. On Linux, if your hardware doesn’t work out of the box, that’s it; your best bet is to return the item, buy a different one, and hope it works.
Now, you’re probably thinking “Well, that fault doesn’t lie with Linux; if manufacturers would just support the platform, this problem wouldn’t exist.” Granted, to a degree, this statement is true: if manufacturers would write Linux drivers, open-source them (many don’t wish to do this), and contribute them to the kernel tree, then Linux would be compatible with that hardware. Eventually. Keep in mind that a submitted driver probably won’t appear in mainstream distributions for a reasonable amount of time.
So let’s say I’m a manufacturer, and I wish to support my new hardware on Windows, Mac OS X, and Linux. Users who install my new product on Windows or Mac OS X will be able to install drivers from a CD and start using my product immediately. Because, however, Linux provides no support for installable drivers, my hardware will remain completely inaccessible to Linux users until I submit my driver to the kernel tree, it gets accepted, a new stable release of the kernel comes out featuring my driver, and users upgrade. So much for being cutting edge…
I recently installed the lastest Ubuntu beta on my Vista laptop, and it works much better than the stock OS; if a couple of remaining hardware issues are fixed in the final version, I may switch). Considering how refined the Linux user experience is today it really seems a shame that the stubbornness of the developers is, essentially, preventing it from ever truly going mainstream.