Brief items

Kernel release status

The 5.14 kernel is out, released on August 29. Linus said:

So I realize you must all still be busy with all the galas and fancy balls and all the other 30th anniversary events, but at some point you must be getting tired of the constant glitz, the fireworks, and the champagne. That ball gown or tailcoat isn't the most comfortable thing, either. The celebrations will go on for a few more weeks yet, but you all may just need a breather from them.

And when that happens, I have just the thing for you - a new kernel release to test and enjoy.

Headline features in 5.14 include: core scheduling (at last), the burstable CFS bandwidth controller, some initial infrastructure for BPF program loaders, the rq_qos I/O priority policy, some improvements to the SO_REUSEPORT networking option, the control-group "kill" button, the memfd_secret() system call, the quotactl_fd() system call, and much more. See the LWN merge-window summaries (part 1, part 2) for more details.

Stable updates: 5.13.13, 5.10.61, 5.4.143, 4.19.205, 4.14.245, 4.9.281, and 4.4.282 were released on August 26. The 5.14.1, 5.13.14, 5.10.62, 5.4.144, 4.19.206, 4.14.246, 4.9.282, and 4.4.283 updates are all in the review process; they are due on September 3.

Comments (none posted)

Realtime preemption locking core merged

The 5.15 merge window is off to a fast start; stay tuned for our usual full summary. It is worth mentioning, though, that the realtime preemption locking code has been pulled into the mainline with little fanfare. This work began in 2004 and has fundamentally changed many parts of the core kernel. With this pull, the sleepable locks that make deterministic realtime response possible have finally joined all of that other work (though the kernel must be built with the REALTIME configuration option to use them).

Congratulations are due to all of the realtime developers who pushed this project forward for nearly two decades.

Comments (10 posted)

Quote of the week

As much as I still prefer running my own kernel on my hardware, I'm having trouble motivating myself after the last 18 months of world madness due to Covid19 and feel that I should really sadly bring this patch-set to a graceful end. My first linux kernel patches stretch back 20 years and with almost no passion for working on it any more, I feel it may be long overdue.

Unfortunately I also do not have faith that there is anyone I can reliably hand the code over to as a successor as well, as almost all forks I've seen on my work have been prone to problems I've tried hard to avoid myself.

There is always the possibility that mainline linux kernel will be so bad that I'll be forced to create a new kernel of my own out of disgust, which is how I got here in the first place, but that looks very unlikely. Many of you would have anticipated this coming after my last motivation blog-post, but unless I can find the motivation to work on it again, or something comes up that gives me a meaningful reason to work on it, I will have to sadly declare 5.12-ck the last of the MuQSS and -ck patches.

— Con Kolivas calls it quits.

Comments (7 posted)

Distribution quote of the week

As I've said before, I've never been a fan of /usr-unification; I don't hate it, but I've never thought it was worth it in and of itself, other the "compatibility with the rest of the world argument". I'm not a huge fan of systemd, either, although I never hated it as much as some. But the entire Linux ecosystem has spoken, and so my personal views aren't really important at this point. Part of living in a community is realizing that one doesn't always get one's own way, and subsuming one's individual wants for the greater good.

— Theodore Ts'o

Comments (none posted)

Development quote of the week

Zink is done.

The final boss has been beaten, there’s no more versions to support, no extensions left on my todo list, definitely no bugs remaining, and performance can’t possibly improve further.

If you think you’ve found a zink bug, report it to whoever wrote the test or app you’re running, because the only thing I plan on doing for the rest of 2021 is playing Cyberpunk 2077 on Lavapipe.

Right after it finishes loading.

— Mike Blumenkrantz

Comments (none posted)

FSF copyright handling: A basis for distribution, licensing and enforcement

The Free Software Foundation (FSF) clarifies the purpose of its copyright policies and examines the impact of potential alternatives.

For some GNU packages, the ones that are FSF-copyrighted, we ask contributors for two kinds of legal papers: copyright assignments, and employer copyright disclaimers. We drew up these policies working with lawyers in the 1980s, and they make possible our steady and continuing enforcement of the GNU General Public License (GPL).

These papers serve four different but related legal purposes, all of which help ensure that the GNU Project's goals of freedom for the community are met.

Comments (67 posted)