Bilbao, Spain – : At 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’s a major change coming: Long Term Support (LTS) for Linux kernels is going from six years to two.
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 kernel 4.14 and the following two disappear, they will not be replaced.
Linux code maintainers are burning out
For what ? It’s simple, Corbett explained: “There’s really no point in keeping them that long because people aren’t using them.”
I agree. I’m sure someone is still using 4.14 in a production Linux system, but there can’t be many.
Another reason, and a much bigger problem than just maintaining LTS, according to Corbett, is that Linux code maintainers are burning out. It’s not that developers are the problem. The latest Linux releases have involved an average of more than 2,000 programmers – including around 200 new developers – working on each release. However, for maintainers – the people who check the code to make sure it’s fit and working correctly – it’s a different story.
“This can’t last, we need help”
Because maintenance managers face many obstacles.
Importantly, many maintainers are not paid to provide maintenance. They maintain the code in addition to their daily work. On top of that, they are increasingly overloaded – due to staff shortages and the use of fuzzers to find bugs. While fuzzers are useful, they also uncover far too many minor bugs, all of which must be investigated and then discarded by maintainers.
The result ? To quote Josef Bacik, developer and maintainer of the Linux kernel file system: “The maintainers are burning out [parce que] maintainers are not scalable.” Darrick Wong, another senior Linux kernel maintainer, added: “This can’t last, we need help.”
Should you pay to maintain Linux?
How can they get help? First, 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, nonprofits, or local governments. They report the same issues of work overload. And they see the direct connection between “the lack of revenue and resources in their organization. They don’t understand why the same thing is happening to me and my colleagues when we all work for companies that make hundreds of billions of dollars.”
It’s a good question. Companies need to understand that they need to give back to Linux if they want to continue to reap the rewards.
A related question: Linux is adopting Rust. While this is good news in many ways – Rust eliminates entire classes of errors to which Linux’s main language, C, is vulnerable – it also poses problems for maintainers. After all, if a maintainer has spent 30 years working in C, asking them to become an expert in Rust is no easy feat.
The question of the arrival of Rust is another problem
Additionally, Rust is still evolving. Many Rust patches are required for the language to work properly on Linux. This also means that you need a lot of fixes to make Rust and Linux work well together.
Additionally, some Linux kernel developers don’t like Rust. One said: “There are probably well-designed and written parts of Linux that haven’t had a memory safety problem in many years. It’s insulting to present this as an improvement by compared to what has already been achieved.
Still, three significant new additions to the Linux kernel code, based on Rust, are in the works, Corbett said. It’s an implementation of PuzzleFS, a Plan9 read/write file system server, and — the most talked about — Apple’s M1 GPU driver. Indeed, the first Linux OpenGL ES 3.1 drivers are now available for Apple GPUs from the M1 and M2 families.
Another hot topic is how Red Hat changed its Red Hat Enterprise Linux (RHEL) license, prompting Oracle, SUSE and CIQ to fork RHEL with the Open Enterprise Linux Association (OpenELA). Leaving aside the business complications and licensing issues that led to this battle, there are also concerns about the Linux kernel.
These concerns revolve around the 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 fixes. This is what Red Hat and other Linux Enterprise vendors tend to do.
The latter solution also results in vendor-specific cores. While this provides 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 (Red Hat’s free RHEL clone). And this after Red Hat shut down CentOS in favor of CentOS Stream. This is what sparked the fire between Red Hat and OpenELA. 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 training needed to keep him from making a mess on the kitchen floor is harder.
Source: “ZDNet.com”