Over on the AboutCode blog, lead maintainer Philippe Ombredanne writes about an agentic LLM system porting the ScanCode Toolkit to Rust. In the process, the LLM (or the people behind it) infringed the ScanCode trademark, stripped copyright and license notices, "and started an outreach campaign, without ever engaging the AboutCode community". Ironically, the toolkit is used to scan source code and binaries in order to figure out licensing and copyright information; it also reports on package dependencies, vulnerabilities, and more.

This is worth repeating: A comprehensive test suite, decent documentation, and curated datasets is what makes automated porting possible. It is also what makes a codebase easier to replicate without understanding it.

The agent's initial approach, using an existing Rust license-detection library, failed to match ScanCode's output quality. The agent then did what any translator would do when a loose paraphrase fails: it copied the original more closely. The final port reproduces ScanCode's core algorithms, code organization, and data-driven architecture in Rust, not because the agent understood them, but because it had enough training data and test feedback to converge on equivalent code.

Many organizations require US Federal Information Processing Standard (FIPS) certification of the crypto code they are running. The certification process is lengthy, but the bigger problem is that the way the crypto subsystem is built into the kernel makes the result unable to be reused across kernel updates. I have proposed a patch series that decouples the crypto subsystem into a standalone loadable module, allowing a certified crypto module to be reused with multiple kernels and, thus, requiring fewer lengthy recertification delays.

In a filesystem-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Amir Goldstein wanted to discuss his proposed documentation on adding new filesystems to the kernel. There are a number of unmaintained and untestable filesystems already in the kernel, which are a burden to VFS-layer developers who are trying to make sweeping changes, such as switching to folios and the "new" mount API. Goldstein's document is an attempt to head off the addition of filesystems that may increase that burden down the road.

In a plenary session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, the state of patch review using large language models (LLMs) was discussed. It is a topic that has been swirling around in the kernel community for much of the year. The plenary, which was led by Roman Gushchin, Chris Mason, Josef Bacik, and Sasha Levin, resulted in a quite bit of discussion, so much that a second filesystem-track-only (though others surely sat in) slot was used to continue it later in the day.

The Software Freedom Conservancy (SFC) published a news item on May 18 about its response to violations of the AGPLv3 by Bambu Lab in its 3D printers. The company has not provided the source code to its modifications to a 3D "slicer" program that was released under the AGPLv3 and it has also threatened Paweł Jarczak who created a fork of a different slicer (Orca Slicer) released under AGPLv3 in order to interoperate with his Bambu printer. Based on that, the SFC has created the baltobu project aimed at reverse-engineering and reimplementing the Bambu code while also hosting the Orca Slicer fork.

Bambu has behaved badly for years and made multiple, provably false public statements regarding the AGPLv3 and its requirements. The recent aggressive behavior toward Paweł Jarczak was a last straw for us: we have decided to launch a multi-pronged effort that will assist consumers and users in the short-term, and also work toward a long-term strategy to improve the software right to repair for all 3D printer consumers.

Security updates have been issued by Debian (atril, evince, gnutls28, haproxy, haveged, jq, kernel, krb5, libgcrypt20, nodejs, and thunderbird), Fedora (aw-server-rust, awatcher, bind, bind-dyndb-ldap, chromium, composer, docker-buildkit, docker-buildx, dotnet10.0, dotnet8.0, dotnet9.0, evince, firefox, httpd, kernel, nodejs-aw-webui, nss, perl-Apache-Session-Browseable, pie, python-pulp-glue, python-requests, and python3.15), Slackware (kernel), SUSE (apptainer, chromium, cockpit, dnsmasq, google-guest-agent, hauler, iproute2, jfrog-cli, kernel, libecpg6, libsolv, libzypp, zypper, mcphost, oci-cli, perl-YAML-Syck, python-lxml, python-urllib3, python311-impacket, rqlite, rsync, util-linux, and xz), and Ubuntu (evince, linux-azure, linux-azure-5.4, linux-azure-fips, linux-azure-4.15, linux-azure-fips, linux-fips, linux-gcp-5.15, linux-lowlatency-hwe-5.15, linux-oracle-6.17, node-path-to-regexp, and rclone).

In back-to-back sessions at the start of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit (which spilled over into a third slot), the atomic-buffered-writes feature was discussed. In the first session, Pankaj Raghav and Andres Freund set the stage with an introduction to the problem, along with a use case for its solution: the PostgreSQL database system. In the second, Ojaswin Mujoo described a potential way forward for the feature using an approach based on writethrough, which effectively means that the kernel immediately writes the data to disk instead of waiting for writeback from the page cache to occur. As might be expected, there was quite a bit of discussion among the assembled filesystems and storage developers during the combined sessions for those tracks.