Brief items

White paper: Vendor Kernels, Bugs and Stability

Ronnie Sahlberg, Jonathan Maple, and Jeremy Allison of CiQ have published a white paper looking at the security-relevant bug fixes applied (or not applied) to the RHEL 8.x kernel over time.

This means that over time, the security of the RHEL kernels get worse and worse as more issues are discovered in the upstream code and are potentially exploitable but fewer and fewer of the fixes for these known bugs are back-ported into RHEL kernels.

After reaching RHEL 8.7, the theory is that the kernel has been stabilized, with a corresponding improvement in security. However we still have an influx of newly discovered bugs in the upstream kernel affecting RHEL 8.7 that are not addressed. Each minor version of upstream is released on an approximately quarterly basis and we can see that the influx of new bugs that are unaddressed in RHEL is growing. The number of known issues in these kernels increases by approximately 250 new bugs per quarter or more.

Comments (147 posted)

Kernel release status

The 6.10 merge window remains open; it can be expected to close on May 26.

Stable updates: 6.9.1, 6.8.10, 6.6.31, 6.1.91, 5.15.159, 5.10.217, 5.4.276, and 4.19.314 were released on May 17.

Comments (none posted)

Axboe: What's new with io_uring in 6.10

Jens Axboe describes the new io_uring features that will be a part of the 6.10 kernel release.

Bundles are multiple buffers used in a single operation. On the receive side, this means a single receive may utilize multiple buffers, reducing the roundtrip through the networking stack from N per N buffers to just a single one. On the send side, this also enables better handling of how an application deals with sends from a socket, eliminating the need to serialize sends on a single socket. Bundles work with provided buffers, hence this feature also adds support for provided buffers for send operations.

Comments (none posted)

AlmaLinux forms engineering steering committee

The AlmaLinux project has announced the formation of the AlmaLinux Engineering Steering Committee (ALESCo):

[It] is dedicated to guiding the technical direction of the AlmaLinux distribution on a day-to-day basis within the guidelines set forth by the board, ensuring its robustness, reliability, sustainability, and relevance in the open-source ecosystem. ALESCo will work collaboratively with, and oversee relevant technical-focused Special Interest Groups (SIGs) to achieve these goals. It is "air traffic control" for engineering matters.

The initial members of ALESCo appointed by the AlmaLinux OS Foundation board are Andrew Lukoshko, Ben Thomas, Cody Robertson, Elkhan Mammadli, Jonathan Wright, and Neal Gompa. The AlmaLinux Wiki has more information on the committee's activities and how to get involved.

Comments (2 posted)

Alpine Linux 3.20.0 released

Version 3.20.0 of the Alpine Linux distribution has been released with initial support for 64-bit RISC-V. Other important changes include updates to GNOME 46, KDE Plasma 6, and replacing Redis with Valkey due to Redis's adoption of a non-free license model. See the release notes for more on this release.

Comments (none posted)

Distribution quote of the week

IMO the Python stack is the *best* example of how to provide multiple versions of something in Fedora, and for how transitions to new major versions are handled in Rawhide. (And any remaining Python vs. Python 3 confusions are an orthogonal problem.) Being able to use both newer and older versions of Python on different branches of Fedora is *awesome*, for example for running tests against different Python versions with tox.

— Fabio Valentini

Comments (none posted)

Neovim 0.10 released

Version 0.10 of the Vim-based text editor Neovim is now available. This release includes a new default color scheme, enhanced support for rendering multibyte characters, support for hyperlinks, system clipboard synchronization, and more. Many features have been deprecated in 0.10 and will be removed in future release. Neovim core contributor Gregory Anders has written a summary of some of the highlights and thoughts on upcoming releases:

We follow a "fun driven development" paradigm: for the most part, contributors and maintainers work on things that are personally interesting to them. Because of this, it can be difficult to predict what will happen in future releases. If there is a feature you want to see implemented, the best way to do it is to take a crack at it yourself: many of the features mentioned in this very blog post were contributed by users that are not part of the "core" maintenance team!

Comments (5 posted)

Development quote of the week

The point is - we need a much better signal to noise ratio here. I bet the number of patches in the CommitFest that actually need review is something like 25% of the total. The rest are things that are just parked there by a committer, or that the author doesn't care about right now, or that are already being actively discussed, or where there's not a clear way forward. We could create new statuses for all of those states - "Parked", "In Hibernation," "Under Discussion," and "Unclear" - but I think that's missing the point. What we really want is to not see that stuff in the first place. It's a CommitFest, not once-upon-a-time-I-wrote-a-patch-Fest.

— Robert Haas

Comments (none posted)