Greg Kroah-Hartman has released the 6.18.9, 6.12.69, 6.6.123, 6.1.162, 5.15.199, and 5.10.249 stable kernels. As always, each contains important fixes throughout the tree; users are advised to upgrade.

This is a major release for the project, seeing several substantive new features that users have asked for over a long period of time. Region FX, clip recording, a touch-sensitive GUI, pianoroll windows, clip editing and more, not to mention dozens of bug fixes, new MIDI binding maps, improved GUI performance on macOS (for most) ...

We expect to get feedback on some of the major new features in this release, and plan to take that into account as we improve and refine them and the rest of Ardour going forward. We have no doubt that there will be both delight and disappointment with certain things - rather than assume that we don't know what we're doing, please leave us feedback on the forums so that Ardour gets better over time. Those of you new to our clip launching implementation might care to read up on the differences with Ableton Live.

In the coming weeks, we'll begin to sketch out what we have planned next for Ardour, in addition to responding to the feedback we get on this 9.0 release.

Control-flow integrity (CFI) is a set of techniques that make it more difficult for attackers to hijack indirect jumps to exploit a system. The Linux kernel has supported forward-edge CFI (which protects indirect function calls) since 2020, with the most recent implementation of the feature introduced in 2022. That version avoids the overhead introduced by the earlier approach by using a compiler flag (-fsanitize=kcfi) that is present in Clang but not in GCC. Now, Kees Cook has a patch set adding that support to GCC that looks likely to land in GCC 17.

The Linux From Scratch (LFS) project provides step-by-step instructions on building a customized Linux system entirely from source. Historically, the project has provided separate System V and systemd editions, which gave users a choice of init systems. Bruce Dubbs has announced the project will no longer produce the System V version:

There are two reasons for this decision. The first reason is workload. No one working on LFS is paid. We rely completely on volunteers. In LFS there are 88 packages. In BLFS there are over 1000. The volume of changes from upstream is overwhelming the editors. In this release cycle that started on the 1st of September until now, there have been 70 commits to LFS and 1155 commits to BLFS (and counting). When making package updates, many packages need to be checked for both System V and systemd. When preparing for release, all packages need to be checked for each init system.

The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V. This could potentially be worked around with another init system like OpenRC, but beyond the transition process it still does not address the ongoing workload problem.

[...] As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important.

The next version, 13.0, is expected in March and will only focus on systemd.