Long-term support for the Linux kernel increases to 2 years (instead of 6)

Bilbao, Spain – : During the Open Source Summit Europe, Jonathan Corbett, Linux kernel developer and editor-in-chief of Linux Weekly News, presented some new features of the Linux kernel and its evolution.

Here is a major change coming: The long-term support (LTS) for Linux kernels is increasing from six to two years.

Currently, there are six Linux LTS kernels : 6.1, 5.15, 5.10, 5.4, 4.19 and 4.14. According to the process in force so far, version 4.14 would disappear in January 2024, and another kernel would be added. However, in the future, when the 4.14 kernel and the next two disappear, they will not be replaced.

Linux code maintainers are running out of steam

Why? It’s simple, explained Mr. Corbett: “There’s really no point in keeping them that long because people don’t use them”.

I agree. I’m sure someone is still using version 4.14 in a production Linux system, but there must not be many of them.

Another reason, and a much more important problem than just maintaining LTS, according to Corbett, is that Linux code maintainers are running out of steam. It’s not that the developers are a problem. The latest versions of Linux have involved an average of more than 2,000 programmers – including about 200 new developers – who have worked on each version. However, for the maintenance managers, that is to say the people who check the code to make sure that it is adapted and that it works correctly, it is another pair of sleeves.

“This can’t last, we need help”

Because those responsible for maintenance face many obstacles.

Above all, many maintainers are not paid to provide maintenance. They ensure the maintenance of the code in addition to their daily work. On top of that, they are increasingly in demand – because of the lack of staff and the use of fuzzers to find bugs. Although the fuzzers are useful, they also discover far too many minor bugs, all of which must be examined and then rejected by the maintenance managers.

The result? To quote Josef Bacik, developer and maintainer of the Linux kernel file system: “The maintainers are running out of steam [parce que] the maintainers are not scalable”. Darrick Wong, another senior maintainer of the Linux kernel, added: “This cannot last, we need help”.

Do we have to pay to maintain Linux

How can they get help? First of all, Mr. Corbett suggests that maintainers ask their employer to pay them for their work maintaining the Linux kernel. As Mr. Wong noted, “Most of my friends work for small businesses, non-profit organizations or local governments. They report the same problems with work overload. And they see the direct link between the lack of income and resources of their organization. They don’t understand why the same thing is happening to me and my colleagues, when we all work for companies that brew hundreds of billions of dollars”.

That’s a good question. Companies must understand that they must give Linux back what they have given it if they want to continue reaping the benefits.

A related question: Linux is adopting Rust. Although this is good news in many ways – Rust eliminates entire classes of errors to which the main Linux language, C, is vulnerable – it also poses problems for those responsible for maintenance. After all, if a maintainer has spent 30 years working in C, asking him to become a Rust expert is no easy task.

The question of the arrival of Rust is another problem

In addition, Rust is still evolving. Many Rust fixes are necessary for the language to work properly on Linux. It also means that you need a lot of fixes for Rust and Linux to work well together.

By the way, some Linux kernel developers don’t like Rust. One of them said: “There are probably well-designed and written parts of Linux that have not experienced a memory security problem for many years. It is insulting to present this as an improvement on what has already been achieved.”

Still, three important new additions to the Linux kernel code, based on Rust, are being developed, Corbett said. It is an implementation of PuzzleFS, a Plan9 read/write file system server and — the one that will be the most talked about — the Apple M1 GPU driver. Indeed, the first Linux OpenGL ES 3.1 drivers are now available for Apple GPUs of the M1 and M2 families.

Another hot topic is how Red Hat changed its Red Hat Enterprise Linux (RHEL) license, which prompted Oracle, SUSE and the CIQ to fork RHEL with the Open Enterprise Linux Association (OpenELA). If we ignore the commercial complications and licensing problems that led to this battle, there are also concerns about the Linux kernel.

These concerns revolve around the following question: which kernel should you use for your Linux distribution? Two choices are available to you :

• 1) Run the latest stable kernel
• 2) Run an old kernel with backported patches. This is what Red Hat and other Enterprise Linux version distributors tend to do.

The latter solution also translates into vendor-specific kernels. Although this offers some stability, it takes these distros away from community support and makes them dependent on specific providers. It is this last consequence that pushed AlmaLinux and Rocky Linux to launch their own version of CentOS (the free clone of RHEL from Red Hat). And this is after Red Hat closed CentOS in favor of CentOS Stream. This is what set Red Hat and OpenELA on fire. What OpenELA wants is a clone of RHEL, which uses the old patched RHEL kernel.

Finally, Mr. Corbett recalled that Scott McNealy, the former CEO of Sun, once said: “Open source is free like a puppy is free”. McNealy wasn’t wrong. Using open source and Linux is easy. Paying for the necessary training so that he does not make a mess on the kitchen floor is more difficult.

Source: “ZDNet.com “