Hỗ trợ lâu dài cho nhân Linux sẽ bị cắt giảm khi việc bảo trì vẫn gặp áp lực
Hôm nay tại Open Source Summit Europe, Jonathan Corbett, nhà phát triển nhân Linux và biên tập viên điều hành của Linux Weekly News, đã thông báo với mọi người về những điểm mới trong nhân Linux và hướng phát triển của nó trong tương lai. Một thay đổi quan trọng sắp tới là việc giảm hỗ trợ lâu dài (LTS) cho nhân Linux từ sáu năm xuống hai năm.
Hiện tại, có sáu nhân Linux LTS – 6.1, 5.15, 5.10, 5.4, 4.19 và 4.14. Theo quy trình hiện tại, nhân 4.14 sẽ kết thúc vào tháng Một năm 2024 và một nhân khác sẽ được thêm vào. Tuy nhiên, trong tương lai, khi nhân 4.14 và hai nhân tiếp theo bị loại bỏ, chúng sẽ không được thay thế.
Vì sao? Đơn giản, Corbett giải thích: “Thực ra không có ý nghĩa gì để duy trì nó lâu như vậy vì mọi người không sử dụng chúng.” Tôi đồng ý. Mặc dù tôi chắc chắn rằng vẫn có ai đó đang chạy nhân 4.14 trong một hệ thống Linux sản xuất, nhưng không nhiều. Lý do khác, và vấn đề lớn hơn đơn giản là bảo trì LTS, theo Corbett, là các nhà bảo trì mã nguồn mở cảm thấy căng thẳng. Không phải lập trình viên là vấn đề. Các phiên bản Linux gần đây đã có hơn 2.000 lập trình viên tham gia trung bình – bao gồm khoảng 200 nhà phát triển mới gia nhập – làm việc trên mỗi phiên bản. Tuy nhiên, các nhà bảo trì – những người kiểm tra mã nguồn xem nó có phù hợp và hoạt động đúng – lại khác.
Những nhà bảo trì gặp nhiều trở ngại trong công việc của họ. Trở ngại thứ nhất: Nhiều nhà bảo trì không được trả tiền để bảo trì. Họ bảo trì mã nguồn ngoài công việc hàng ngày của họ. Ngoài ra, họ phải đối mặt với yêu cầu thời gian ngày một tăng vì thiếu nhân lực và việc sử dụng các công cụ tìm lỗi tự động. Mặc dù các công cụ này hữu ích, nhưng chúng đã phát hiện ra quá nhiều lỗi nhỏ, mỗi lỗi đều phải được kiểm tra và từ chối bởi các nhà bảo trì.
Kết quả là, như Josef Bacik đã nói, nhà phát triển và nhà bảo trì hệ thống file nhân Linux: “Những người bảo trì đang mệt mỏi vì bảo trì không phát triển.” Darrick Wong, một nhà bảo trì nhân Linux năm giàu kinh nghiệm khác, cũng nói: “Không thể tiếp tục như vậy. Chúng ta cần sự giúp đỡ.” Làm thế nào để họ có thể nhận được sự giúp đỡ? Vâng, Corbett đề xuất rằng các nhà bảo trì nên nói chuyện với nhà tuyển dụng của họ về việc trả tiền cho công việc bảo trì. Như Wong nhận xét: “Hầu hết những người bạn của tôi làm việc cho các công ty nhỏ, các tổ chức phi lợi nhuận và các chính quyền địa phương. Họ báo cáo về những vấn đề tương tự với công việc quá tải, nỗi sợ hãi và tức giận tràn lan và khó khăn để hiểu và thích nghi với ý tưởng mới tôi quan sát ở đây. Họ nhìn thấy mối liên hệ trực tiếp giữa sự thiếu thu nhập và nguồn lực của tổ chức của họ. Họ không hiểu tại sao điều tương tự xảy ra với tôi và các đồng nghiệp trong công ty đang có hàng trăm tỷ đô la.” Đó là một câu hỏi hay. Các công ty phải nhận ra rằng họ cần đóng góp vào Linux nếu muốn tiếp tục thu được lợi ích từ nó.
Một vấn đề liên quan khác: Linux hiện đang áp dụng Rust như một thí nghiệm. Mặc dù điều đó tốt trong nhiều cách – Rust loại bỏ các lỗi mà ngôn ngữ chính của Linux, C, dễ bị tấn công – nhưng nó cũng gây khó khăn cho nhà bảo trì. Sau tất cả, nếu một nhà bảo trì đã làm việc trong C trong 30 năm, yêu cầu họ trở thành một chuyên gia Rust là một yêu cầu lớn.
Ngoài ra, Rust vẫn đang phát triển. Rất nhiều bản vá Rust cần được thực hiện để ngôn ngữ hoạt động một cách chính xác và sâu sắc trong Linux. Điều đó cũng có nghĩa là bạn cần rất nhiều mã glue để Rust và Linux hoạt động tốt với nhau.
Sau đó, còn một số nhà phát triển nhân Linux không thích Rust. Như một người nói, “Có thể có một số phần của Linux được thiết kế và viết tốt chưa gặp vấn đề về an toàn bộ nhớ trong nhiều năm. Đây là một cải tiến so với những gì đã được đạt được bởi những người đã làm việc vất vả.” Tuy nhiên, Corbett tin rằng điểm quyết định – liệu Rust có trở thành một phần chính thức của nhân Linux hay không – sẽ đến sớm. Ngày đó sẽ đến khi chúng ta kết hợp tính năng đầu tiên mà người dùng phụ thuộc vào.”
Ngày đó đang sắp đến: Ba bổ sung mới quan trọng dựa trên Rust cho mã nguồn Linux đang trên đường đến, Corbett nói. Đó là việc triển khai của PuzzleFS, một máy chủ hệ thống file Plan9 đọc/ghi và – điều mà sẽ làm tiêu điểm nhất – trình điều khiển GPU Apple M1. Thực sự, các trình điều khiển Linux đầu tiên hỗ trợ OpenGL ES 3.1 của Apple M1 và M2 đã có sẵn từ cuối tháng Tám năm 2023. Với những công việc như vậy đang được thực hiện, Corbett sẽ rất ngạc nhiên nếu Rust không được áp dụng vĩnh viễn trong Linux.
Một chủ đề khác gần đây có trong tin tức là cách việc điều chỉnh giấy phép Red Hat Enterprise Linux (RHEL) của Red Hat đã khiến Oracle, SUSE và CIQ phân nhánh RHEL với
BILBAO, Spain: At the Open Source Summit Europe, Jonathan Corbett, Linux kernel developer and executive editor of Linux Weekly News, caught everyone up with what’s new in the Linux kernel and where it’s going from here.
Here’s one major change coming down the road: Long-term support (LTS) for Linux kernels is being reduced from six to two years.
Currently, there are six LTS Linux kernels — 6.1, 5.15, 5.10, 5.4, 4.19, and 4.14. Under the process to date, 4.14 would roll off in January 2024, and another kernel would be added. Going forward, though, when the 4.14 kernel and the next two drop off, they won’t be replaced.
Also: Want an elegant, user-friendly Windows alternative? Try Manjaro 23.0 with KDE Plasma
Why? Simple, Corbett explained: “There’s really no point to maintaining it for that long because people are not using them.” I agree. While I’m sure someone out there is still running 4.14 in a production Linux system, there can’t be many of them.
Another reason, and a far bigger problem than simply maintaining LTS, according to Corbett, is that Linux code maintainers are burning out. It’s not that developers are a problem. The last few Linux releases have involved an average of more than 2,000 programmers — including about 200 new developers coming on board — working on each release. However, the maintainers — the people who check the code to see if it fits and works properly — are another matter.
Maintainers face numerous obstacles to doing their jobs. Obstacle one: Many maintainers aren’t paid to maintain. They maintain code in addition to their day jobs. On top of that, they face increasing demands on their time — because of understaffing and because of the use of fuzzers to find bugs. While fuzzers are helpful, they also uncover way too many minor bugs, each of which must be examined and then dismissed by maintainers.
The result? To quote Josef Bacik, Linux kernel file system developer and maintainer: “Maintainers are burning out (because) maintainers don’t scale.” Added Darrick Wong, another senior Linux kernel maintainer: “This cannot stand. We need help.”
How can they get help? Well, for one thing, Corbett suggests maintainers talk to their employers about paying them for their maintainer work. As Wong observed, “Most of my friends work for small companies, nonprofits, and local governments. They report the same problems with overwork, pervasive fear, and anger, and struggle to understand and adapt to new ideas that I observe here. They see the direct connection between their org’s lack of revenue and resources. They don’t understand why the hell the same happens to me and my workplace proximity associates when we all work for companies that clear hundreds of billions of dollars.”
That’s a good question. Companies must realize they need to give back to Linux if they want to continue to reap its benefits.
Also: Why don’t more people use desktop Linux? I have a theory you might not like
A related issue: Linux is now embracing Rust as an experiment. While that’s good news in many ways — Rust removes entire classes of errors that Linux’s main language C is vulnerable to — it also poses problems for maintainers. After all, if a maintainer has spent 30 years working in C, asking them to become a Rust expert is a big ask.
In addition, Rust is still evolving. Many Rust patches are needed to get the language to work properly at a deep level in Linux. That also means you need lots of glue code to get Rust and Linux working well together.
Then there are some Linux kernel developers who don’t like Rust. As one said, “There are possibly some well-designed and written (Linux) parts which have not suffered a memory safety issue in many years. It’s insulting to present this as an improvement over what was achieved by those doing all this hard work.”
Even so, Corbett believes that the decision point — whether Rust becomes a mainstream part of the kernel — is coming soon. That day will come, he noted, “when we merge the first feature that users depend on.”
Also: How Google is using Rust to reduce memory safety vulnerabilities in Android
That day is near: Three important new Rust-based additions to Linux kernel code are on the way, Corbett said. These are an implementation of the PuzzleFS, a read/write Plan9 filesystem server; and — the one that will make the biggest headlines — the Apple M1 GPU driver. Indeed, the first conformant Linux OpenGL ES 3.1 drivers are now available for Apple’s M1- and M2-family GPUs, arrived in late August 2023. With work like this well in train, Corbett would be very surprised if Rust doesn’t make it permanently into Linux.
Another subject in the news lately is how Red Hat’s tweaking of its Red Hat Enterprise Linux (RHEL) license has caused Oracle, SUSE, and the CIQ to fork RHEL with the Open Enterprise Linux Association (OpenELA). Leaving aside the business and licensing complications that led to this fight, there are also Linux kernel concerns.
These concerns orbit around the question: Which kernel should you use for your Linux distribution? There are two real choices: 1) Run the latest stable kernel or 2) Run an old kernel plus backported fixes. The latter is what Red Hat, and the other enterprise Linux distributors, tend to do.
The latter also results in vendor-specific kernels. And while this offers stability, it distances these distros from community support and makes them reliant on specific vendors. It’s this last consequence — which first caused AlmaLinux and Rocky Linux to start their own takes on CentOS (Red Hat’s free RHEL clone) after Red Hat shut CentOS down in favor of CentOS Stream — that sparked the fire between Red Hat and OpenELA. What OpenELA wants is a RHEL clone, which uses the RHEL older patched kernel. Stay tuned for more developments as this conflict continues to burn.
Also: My idea for a great new beginner-friendly Linux distribution
On the other hand, Corbett noted, Android “has been pushing very hard towards this generic kernel image and has been basing this on stable updates. That’s because they find that this helps improve Android’s security. They’ve found that the vast majority of security problems are disclosed in the kernel and or even fixed in the Android kernels before they are disclosed because they were already incorporated before anybody knew that they were actually security-related bugs.”
That’s yet another issue of which Linux kernel developers are painfully aware. As Corbett explained:
“One of the interesting aspects of kernel development is that almost anything can be a security bug. And you don’t really know that it is until somebody finds a way to exploit it somehow. So an awful lot of fixes go in, and they’re not marked as security fixes. Not because the kernel community is trying to hide security fixes. I mean, sometimes there’s a little bit of sneakiness that goes on there that I personally don’t like. But most of the time, there really is just that nobody knows that this bug is a security bug. It’s only later that somebody figures this out. And so the only way to protect yourself against these sorts of bugs is to put in all of the fixes”
This is why Corbett, and anyone who really knows Linux, recommends that if you’re building a Linux distro, you always include all the patches. For older kernels, such as 4.14, that can be up to 26,799 commits. But, if you try to pick and choose what patches to use, you’ll certainly open your doors to security holes.
Finally, Corbett noted that Scott McNealy, Sun’s former long-time CEO, once said, “Open source is free like a puppy is free.” McNealy had a point. Using open-source and Linux is easy. Paying for the training it needs not to make messes on the kitchen floor, that’s harder.
.
