1 2 next »

1. The need for freshness
2. Getting Fresher

Linux distributions need fresher drivers

by Thorsten Leemhuis

Some Linux users want to have a stable system without constant updates, while others always want to have the latest versions so they can get drivers for new hardware. A multistage approach with two "current" distributions might be a solution.

In software development, it has become common practice to improve program code, stabilise it in alpha and beta versions, and then release it. The whole process then begins again, while the released version receives small low-risk fixes as patches. Most Linux distributions pursue this strategy to coordinate the software contained within them and test the mixture. A lot of distributors are very careful in maintaining their distributions to keep the complex structure from collapsing when a new distribution is released; instead of providing updates to more recent program versions, between distribution versions they merely send out the changes that patch security holes and correct other major flaws.

While users benefit from a stable working environment that hardly changes, they are also cut off completely from improvements "upstream" – in other words, from the ongoing software programming the distributions are made of. Even when the upstream developers release a new version that corrects a number of flaws (and does not contain any dangerous changes), distributors do not automatically pass this new version on to users. Those who wait for updated distributions rather than downloading updates themselves may have to live with programming errors that developers remedied months ago.

As if that weren't bad enough, remedies are not the only thing that reach users with considerable delay. Improvements are also slow to trickle down to users. These delays are especially problematic with the Linux kernel itself, which not only handles the basic infrastructure (such as booting the system and memory/process management), but also contains almost all of the drivers.

The approach is especially troublesome for hardware manufacturers who develop open source drivers for their hardware and implement it in the standard kernel. To do so, they have to integrate drivers for new processors, graphics cards, and other chips months before these components go on sale so that the distribution used when these products are released will work smoothly with the new components. Given the quick product cycles for modern hardware, few firms are truly successful at this.

Giants like Intel do it comparatively well. For instance, Linux kernel 2.6.35, completed at the beginning of August, already supports functions, graphics chips, and mainboard chipsets for Sandy Bridge processors, which, the latest rumour has it, Intel will not even release until the beginning of next year; only in this way will distributions released at the fall, such as Fedora 14 and Ubuntu 10.10, be able to work more or less smoothly with Sandy Bridge systems when they become available. In contrast, the current openSUSE 11.3 with Kernel 2.6.34 can hardly be expected to work well with such hardware.

Yet, openSUSE will not be including any new kernels in its regular updates, nor will Ubuntu and most other distributors; openSUSE users simply have to wait for the next distribution release. In contrast, Fedora does provide kernel updates, though some of its users would like to have a more conservative update strategy. After all, the kernel is such a central component in the Linux system that new kernel versions are always good for an unpleasant surprise.

It would be wrong, however, to assume that separating drivers from the kernel might solve the problem. Such an approach would merely shift the problem, as Ubuntu shows with the proprietary graphics card drivers for AMD and NVIDIA. The drivers included in version 10.04 (Lucid Lynx) are from the spring of 2010, and since then a number of new GeForce and Radeon graphics cards requiring new driver versions have gone on sale. Such drivers in new kernels are sometimes available from (unofficial) add-on repositories. But not everyone knows about them, and sometimes the regular updates do not always jibe with those from the unofficial repositories.

And if you need both a fresh kernel and a new graphics card driver for your hardware, you will often have to coordinate them yourself – or switch to a pre-release version of the upcoming version of your distribution. But then, you will have to make do with unfinished alpha and beta versions of software that developers do not consider is ready for production environments.

Next: Getting Fresher

1 2 next »