The BPF verifier is complicated. It needs to check every possible path that a BPF program's execution could take. The fact that its determination of whether a BPF program is safe is based on the whole lifetime of the program, instead of simple local factors, means that the cause of a verification failure is not always obvious. Ihor Solodrai and Jordan Rome gave a presentation (slides) at the 2025 Linux Plumbers Conference in Tokyo about the BPF verifier visualizer that they have been building to make diagnosing verification failures easier.

The Internet Engineering Task Force (IETF) is the standards body responsible for the TLS encryption standard — which your browser is using right now to allow you to read LWN.net. As part of its work to keep TLS secure, the IETF has been entertaining proposals to adopt "post-quantum" cryptography (that is, cryptography that is not known to be easily broken by a quantum computer) for TLS version 1.3. Discussion of the proposal has exposed a large disagreement between participants who worried about weakened security and others who worried about weakened marketability.

Emma Smith and Kirill Podoprigora, two of Python's core developers, have opened a discussion about including Rust code in CPython, the reference implementation of the Python programming language. Initially, Rust would only be used for optional extension modules, but they would like to see Rust become a required dependency over time. The initial plan was to make Rust required by 2028, but Smith and Podoprigora indefinitely postponed that goal in response to concerns raised in the discussion.

Loris Cro has published a detailed YouTube video talking about the terminology used to discuss asynchronicity, concurrency, and parallelism in our recent article about Zig's new Io interface. Our article is not completely clear because it uses the term "asynchronous I/O" to refer to what should really be called "non-blocking I/O", and sometimes confuses asynchronicity for concurrency, among other errors of terminology, he says. Readers interested in precise details about Zig's approach and some of the motivation behind the design may find Cro's video interesting.

The designers of the Zig programming language have been working to find a suitable design for asynchronous code for some time. Zig is a carefully minimalist language, and its initial design for asynchronous I/O did not fit well with its other features. Now, the project has announced (in a Zig SHOWTIME video) a new approach to asynchronous I/O that promises to solve the function coloring problem, and allows writing code that will execute correctly using either synchronous or asynchronous I/O.

Greg Kroah-Hartman has announced the release of the 6.17.9, 6.12.59, and 6.6.117 stable kernels. As usual, he advises users of stable kernels to upgrade.