The Zig project has announced version 0.16.0 of the Zig programming language.
This release features 8 months of work: changes from 244 different contributors, spread among 1183 commits.
Perhaps most notably, this release debuts I/O as an Interface, but don't sleep on the Language Changes or enhancements to the Compiler, Build System, Linker, Fuzzer, and Toolchain which are also included in this release.
LWN last covered Zig in December 2025.
Part of the "fun" that comes with curating a self-hosted music library is tagging music so that it has accurate and uniform metadata, such as the band names, album titles, cover images, and so on. This can be a tedious endeavor, but there are quite a few open-source tools to make this process easier. One of the best, or at least my favorite, is MusicBrainz Picard. It is a cross-platform music-tagging application that pulls information from the well-curated, crowdsourced MusicBrainz database project and writes it to almost any audio file format.
The Servo project has announced the first release of servo as a crate for use as a library.
As you can see from the version number, this release is not a 1.0 release. In fact, we still haven't finished discussing what 1.0 means for Servo. Nevertheless, the increased version number reflects our growing confidence in Servo's embedding API and its ability to meet some users' needs.
In the meantime we also decided to offer a long-term support (LTS) version of Servo, since breaking changes in the regular monthly releases are expected and some embedders might prefer doing major upgrades on a scheduled half-yearly basis while still receiving security updates and (hopefully!) some migration guides. For more details on the LTS release, see the respective section in the Servo book.
The last week of the release continued the same "lots of small fixes" trend, but it all really does seem pretty benign, so I've tagged the final 7.0 and pushed it out.I suspect it's a lot of AI tool use that will keep finding corner cases for us for a while, so this may be the "new normal" at least for a while. Only time will tell.
Significant changes in this release include the removal of the "experimental" status for Rust code, a new filtering mechanism for io_uring operations, a switch to lazy preemption by default in the CPU scheduler, support for time-slice extension, the nullfs filesystem, self-healing support for the XFS filesystem, a number of improvements to the swap subsystem (described in this article and this one), general support for AccECN congestion notification, and more. See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 7.0 page for more details.
in the next few release cycles". Over six years later, that promise is still present, but it will never be fulfilled. Instead, the read-only option will soon be removed, reflecting how the core of the memory-subsystem has changed underneath this particular feature.
The idea of using large language models (LLMs) to discover security problems is not new. Google's Project Zero investigated the feasibility of using LLMs for security research in 2024. At the time, they found that models could identify real problems, but required a good deal of structure and hand-holding to do so on small benchmark problems. In February 2026, Anthropic published a report claiming that the company's most recent LLM at that point in time, Claude Opus 4.6, had discovered real-world vulnerabilities in critical open-source software, including the Linux kernel, with far less scaffolding. On April 7, Anthropic announced a new experimental model that is supposedly even better; which they have partnered with the Linux Foundation to supply to some open-source developers with access to the tool for security reviews. LLMs seem to have progressed significantly in the last few months, a change which is being noticed in the open-source community.
The Free Software Foundation has published a short article on relicensing versus license compatibility.
The FSF's Licensing and Compliance Lab receives many questions and license violation reports related to projects that had their license changed by a downstream distributor, or that are combined from two or more programs under different licenses. We collaborated with Yoni Rabkin, an experienced and long time FSF licensing volunteer, on an updated version of his article to provide the free software community with a general explanation on how the GNU General Public License (GNU GPL) is intended to work in such situations.
It has been a little while since LWN last surveyed tools for managing a digital music collection. In the intervening decades, many Linux users have moved on to music streaming services, found them wanting, and are looking to curate their own collection once again. There are plenty of choices when it comes to ripping, managing, and playing digital audio; so many, in fact, that it can be a bit daunting. After years of tinkering, I've found a few tools that work well for managing my digital library: the first I'd like to cover is the fre:ac free audio encoder for ripping music from CDs and converting between audio formats.
On March 31, Kees Cook shared a patch set that represents the culmination of more than a year of work toward eliminating the possibility of silent, unintentional integer overflow in the kernel. Linus Torvalds was not pleased with the approach, leading to a detailed discussion about the meaning of "safe" integer operations and the design of APIs for handling integer overflows. Eventually, the developers involved reached a consensus for a different API that should make handling overflow errors in the kernel much less of a hassle.
The NixOS project has announced a critical vulnerability in many versions of the Nix package manager's daemon. The flaw was introduced as part of a fix for a prior vulnerability in 2024. According to the advisory, all default configurations of NixOS and systems building untrusted derivations are impacted.
A bug in the fix for CVE-2024-27297 allowed for arbitrary overwrites of files writable by the Nix process orchestrating the builds (typically the Nix daemon running as root in multi-user installations) by following symlinks during fixed-output derivation output registration. This affects sandboxed Linux builds - sandboxed macOS builds are unaffected. The location of the temporary output used for the output copy was located inside the build chroot. A symlink, pointing to an arbitrary location in the filesystem, could be created by the derivation builder at that path. During output registration, the Nix process (running in the host mount namespace) would follow that symlink and overwrite the destination with the derivation's output contents.
In multi-user installations, this allows all users able to submit builds to the Nix daemon (allowed-users - defaulting to all users) to gain root privileges by modifying sensitive files.
Connexion