« previous 1 2 3 4 5 6 7

Appendix

The following section contains background information about the Linux kernel and its development which was already referred to with links in the main article:

Getting the Linux kernel

Linux kernels are available for download from the servers of Kernel.org; version 2.6.24, for example, is available in form of a Bzip2 compressed patch against 2.6.23 or as a complete archive from the European servers of Kernel.org. Soon after a new Linux version has been released, German mirror servers will also offer it as a patch or complete archive. Servers are allocated dynamically; it is, therefore, possible especially shortly after the release of new files that you end up on a mirror server which doesn't offer the new files yet.

If there is no specific reason for updating to a new kernel version, kernel maintenance should be left to the Linux distributor, as it requires advanced Linux knowledge and a lot of time and effort to configure a kernel yourself - especially due to the required follow-up maintenance caused by the kernel developers releasing several updated versions every month. Some of these close security holes, in which case the entire installation process needs to be repeated.

In addition, kernels of distributions occasionally contain patches or additional drivers not included in the official kernel. If these drivers are needed for the hardware of a personal compilation, they have to be searched for on the internet, downloaded, compiled and installed, which further complicates and draws out the installation of a personal kernel. The additional patches in distribution kernels may also be important. Therefore, quite a few distributions don't run as smoothly as usual or miss certain features with a self-compiled kernel.

The development branches of the respective next versions of Fedora, OpenSuse or Ubuntu often contain the current kernel version and are, therefore, usually the best choice when a new kernel is needed. If switching to such a development version just to enjoy the advantages of a new Linux kernel seems too drastic a measure, seasoned Linux users can also integrate it into the current versions of the respective distributions with a reasonable amount of effort. In Fedora, a short wait may be all that's required, since the project traditionally releases new kernel versions in a regular update for the current versions of the distribution a few days or weeks after their official release.

Version confusion

Kernel hackers are continually developing the 2.6 series Linux kernel. They are not afraid to incorporate substantial changes - it is, therefore, unlikely that a 2.7 development branch will eventually lead to a Linux 2.8.0 or 3.0.0 in the same way Linux 2.6.0 emerged from the 2.5 development branch in the near future.

The main development line consists of the versions separated by three dots (2.6.x, for example 2.6.24), which are watched over by Linus Torvalds himself. However, he gets help from many other kernel hackers with a lot of the decisions. In parallel to the main development, the administrators of the stable kernel series maintain the respective latest versions of the 2.6 series and mark their updates by adding another number (2.6.x.y, for example 2.6.22.10 or 2.6.23.8). To avoid competing with the main development line and ensure that existing flaws are corrected rather than new ones added, the administrators of the stable kernel series have imposed strict rules on themselves; patches may, for example, only be a maximum of a hundred lines long, must correct a critical flaw and should also already have been integrated into the kernel maintained by Linus Torvalds.

Current Linux versions are maintained for about five months (two development cycles), after which time users should update to a new 2.6.x version, as the administrators of the stable kernels will then no longer release any new versions of the old Linux kernel even for security reasons. However, changing to a new kernel is not without risks, since every development cycle tends to allow the occasional flaw to sneak in. For this reason, many Linux distributors maintain their kernels longer instead of supplying new versions - the Enterprise, Server and Workstation distributions of Debian, Novell and Red Hat even offer security updates for their kernels for several years. These updates may also contain a few new and improved drivers as well as some selected new features from newer versions of Linux; distributors hope to achieve better interaction with (new) hardware without subjecting users to the flaws new kernel versions may introduce.

Adrian Bunk proactively maintains the 2.6.16 series kernels according to stable kernel rules - however, he generally leaves out new drivers, to the effect that 2.6.16.y kernels usually lack drivers on new desktop PCs. Even fewer modern hardware drivers are included in the still maintained kernels of the 2.4 series; however, these kernels are interesting for servers which already have Linux installed since they are conservatively maintained and have a very low risk of introducing new problems.

Development cycle

Immediately after a new kernel version has been released, the first phase of the next development cycle, which lasts about two weeks, begins. During this phase, kernel hackers integrate more substantial changes into the development branch maintained by Linus Torvalds from which the next kernel version will eventually be developed. In the following usually about seven to ten weeks of the second development phase, the father of Linux essentially only integrates bug fixes or minor changes before another new kernel version is released after about two and a half to three months. This aims at making kernel hackers focus mainly on correcting mistakes in the second development phase and prevents complex changes from introducing new mistakes.

Many of the changes integrated as patches created with Diff in the first development phase are prepared by the kernel hackers themselves. They are usually started by individual developers who will eventually present the patches for discussion first on a subsystem-specific mailing list and then on the Linux Kernel Mailing List (LMKL). If the patch meets with enough approval it usually goes into the mm development kernel maintained by Andrew Morton for testing. Once the core developers around Linus Torvalds responsible for the respective kernel segments consider the patch as fully developed it is finally integrated into the official kernel at the beginning of the next development cycle.

This public development approach and a deep look into the coffee grinds enable the author of this article and the radar of the Linux Weather Forecast maintained by the Linux Foundation to already predict a rough outline of the following version's major changes when a new kernel version is released. However, it is impossible to predict exactly which patches will actually make it into the next kernel version. Quite often, Linus Torvalds or other important Linux developers have severely criticised new proposals rated as likely contenders for the next kernel version by experienced Linux hackers and observers. As a result, the changes get left out; they then usually find their way into the official Linux kernel one or two versions later, following more discussions and adjustments. Occasionally, however, even major new features with good integration chances were criticised and consequently vanished from view, never to return. Sometimes, on the other hand, things move fast in the first development phase of the Linux cycle, and developers integrate recently released patches directly into the official kernel after only a few days.

« previous 1 2 3 4 5 6 7