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.
Not many people live on sailboats. Things may be better these days, but back in 2014 sailboat dwellers had to contend with lag-prone, intermittent, low-bandwidth internet connections. Dominic Tarr decided to fix the problem of keeping up with his friends by developing a delay-tolerant, fully distributed social-media protocol called Scuttlebutt. Nearly twelve years later, the protocol has gained a number of users who have their own, non-sailboat-related reasons to prefer a censorship-resistant, offline-first social-media system.
Recently, the FreeBSD Foundation has been making progress on improving the operating system's support for modern laptop hardware. The foundation is now looking to expand testing to encompass a wider range of hardware; it has announced a laptop integration testing project to allow the community to easily test FreeBSD's compatibility with laptops and submit the results.
With limited access to testing systems, there's only so much we can do! We hope to work together with volunteers from the community who want FreeBSD to work well on their laptops.
While we expect device hardware and software enumeration to be a fully automated process, we feel that manually-submitted comments about personal experience with FreeBSD are equally valuable. We plan to highlight this commentary on our "matrix of compatibility" webpage for each tested laptop.
We are striving to make it as easy as possible to submit your results. You won't have to worry about environment setup, submission formatting, or any repo-specific details!
See the project repository and testing instructions for more.
Connexion