In Rust, types either possess a constant size known at compile time, or a dynamically calculated size known at run time. That is fine for most purposes, but recent proposals for the language have shown the need for a more fine-grained hierarchy. RFC 3729 from David Wood and Rémy Rakic would add a hierarchy of traits to describe types with sizes known under different circumstances. While the idea has been subject to discussion for many years, a growing number of use cases for the feature have come to light.

Shor's algorithm is the main practical example of an algorithm that runs more quickly on a quantum computer than a classical computer — at least in theory. Shor's algorithm allows large numbers to be factored into their component prime factors quickly. In reality, existing quantum computers do not have nearly enough memory to factor interesting numbers using Shor's algorithm, despite decades of research. A new paper provides a major step in that direction, however. While still impractical on today's quantum computers, the recent discovery cuts the amount of memory needed to attack 256-bit elliptic-curve cryptography by a factor of 20. More interesting, however, is that the researchers chose to publish a zero-knowledge proof demonstrating that they know a quantum circuit that shows these improvements, rather than publishing the actual knowledge of how to do it.

Many people dislike the proliferation of Large Language Models (LLMs) in recent years, and so make an understandable attempt to avoid them. That may not be possible in general, but there are two new forks of Vim that seek to provide an editing environment with no LLM-generated code. EVi focuses on being a modern Vim without LLM-assisted contributions, while Vim Classic focuses on providing a long-term maintenance version of Vim 8. While both are still in their early phases, the projects look to be on track to provide stable alternatives — as long as enough people are interested.

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.

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.

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.

Brian "bex" Exelbierd has published a blog post exploring follow-up questions raised by the recent debate about the use of the LLM-based review tool Sashiko in the memory-management subsystem. His main finding is that Sashiko reviews are bi-modal with regards to whether they contain reports about code not directly changed by the patch set — most do not, but the ones that do often have several such comments.

Hypothesis 1: Reviewers are getting told about bugs they didn't create. Sashiko's review protocol explicitly instructs the LLM to read surrounding code, not just the diff. That's good review practice — but it means the tool might flag pre-existing bugs in code the patch author merely touched, putting those problems in their inbox.

Hypothesis 2: The same pre-existing bugs surface repeatedly. If a known issue in a subsystem doesn't get fixed between review runs, every patch touching nearby code could trigger the same finding. That would create a steady drip of duplicate noise across the mailing list.

I pulled data from Sashiko's public API and tested both.

Discussion of a memory-management patch set intended to clean up a helper function for handling huge pages spiraled into something else entirely after it was posted on March 19. Memory-management maintainer Andrew Morton proposed making changes to the subsystem's review process, to require patch authors to respond to feedback from Sashiko, the recently released LLM-based kernel patch review system. Other sub-maintainers, particularly Lorenzo Stoakes, objected. The resulting discussion about how and when to adopt Sashiko is potentially relevant to many other parts of the kernel.

Rust's compiler team has been working on a long-term project to rewrite the trait solver — the part of the compiler that determines which concrete function should be called when a programmer uses a trait method that is implemented for multiple types. The rewrite is intended to simplify future changes to the trait system, fix a handful of tricky soundness bugs, and provide faster compile times. It's also nearly finished, with a relatively small number of remaining blocking bugs.

BPF programs can run in both sleepable and non-sleepable (atomic) contexts. Currently, sleepable BPF programs are not allowed to enter an atomic context. Puranjay Mohan has a new patch set that changes that. The patch set would let BPF programs called in sleepable contexts temporarily acquire locks that cause the programs to transition to an atomic context. BPF maintainer Alexei Starovoitov objected to parts of the implementation, however, so acceptance of the patch depends on whether Mohan is willing and able to straighten it out.

The kernel's asynchronous io_uring interface maintains two shared ring buffers: a submission queue for sending requests to the kernel, and a completion queue containing the results of those requests. Even with shared memory removing much of the overhead of communicating with user space, there is still some overhead whenever the kernel must switch to user space to give it the opportunity to process completion requests and queue up any subsequent work items. A patch set from Pavel Begunkov minimizes this overhead by letting programmers extend the io_uring event loop with a BPF program that can enqueue additional work in response to completion events. The patch set has been in development for a long time, but has finally been accepted.

In 2019, researchers published a way to identify which file-backed pages were being accessed on a system using timing information from the page cache, leading to a handful of unpleasant consequences and a change to the design of the mincore() system call. Discussion at the time led to a number of ad-hoc patches to address the problem. The lack of new page-cache attacks suggested that attempts to fix things in a piecemeal fashion had succeeded. Now, however, Sudheendra Raghav Neela, Jonas Juffinger, Lukas Maar, and Daniel Gruss have found a new set of holes in the Linux kernel's page-cache-timing protections that allow the same general class of attack.

There has been ongoing discussion in the Internet Engineering Task Force (IETF) about how to protect internet traffic against future quantum computers. So far, that work has focused on key exchange as the most urgent problem; now, a new IETF working group is looking at adopting post-quantum cryptography for authentication and certificate transparency as well. The main challenge to doing so is the increased size of certificates — around 40 times larger. The techniques that the working group is investigating to reduce that overhead could have efficiency benefits for traditional certificates as well.

Python has a unique approach to static typing. Python programs can contain type annotations, and even access those annotations at run time, but the annotations aren't evaluated by default. Instead, it is up to external programs to ascribe meaning to those annotations. The annotations themselves can be arbitrary Python expressions, but in practice usually involve using helpers from the built-in typing module, the meanings of which external type-checkers mostly agree upon. Yet the type system implicitly defined by the typing module and common type-checkers is insufficiently powerful to model all of the kinds of dynamic metaprogramming found in real-world Python programs. PEP 827 ("Type Manipulation") aims to add additional capabilities to Python's type system to fix this, but discussion of the PEP has been of mixed sentiment.

Jujutsu is an increasingly popular Git-compatible version-control system. It has a focus on simplifying Git's conceptual model to produce a smoother, clearer command-line experience. Some people already have a preferred replacement for Git's usual command-line interface, though: Magit, an Emacs package for working with Git repositories that also tries to make the interface more discoverable. Now, a handful of people are working to implement a Magit-style interface for Jujutsu: Majutsu.

On February 12, Yeoreum Yun posted a suggestion for an improvement to the security of the kernel's BPF implementation: use memory protection keys to prevent unauthorized access to memory by BPF programs. Yun wanted to put the topic on the list for discussion at the Linux Storage, Filesystem, Memory Management, and BPF Summit in May, but the lack of engagement makes that unlikely. They also have a patch set implementing some of the proposed changes, but has not yet shared that with the mailing list. Yun's proposal does not seem likely to be accepted in its current form, but the kernel has added hardware-based hardening options in the past, sometimes after substantial discussion.

The 7.0 merge window closed on February 22 with 11,588 non-merge commits total, 3,893 of which came in after the article covering the first half of the merge window. The changes in the second half were weighted toward bug fixes over new features, which is usual. There were still a handful of surprises, however, including 89 separate tiny code-cleanup changes from different people for the rtl8723bs driver, a number that surprised Greg Kroah-Hartman. It's unusual for a WiFi-chip driver to receive that much attention, especially a staging driver that is not yet ready for general use.

The closed-source chat platform Discord announced on February 9 that it would soon require some users to verify their ages in order to access some content — although the company quickly added that the "vast majority" of users would not have to. That reassurance has to contend with the fact that the UK and other countries are implementing increasingly strict age requirements for social media. Discord's age verification would be done with an AI age-judging model or with a government photo ID. A surprising number of open-source projects use Discord for support or project communications, and some of those projects are now looking for open-source alternatives. Mastodon, for example, has moved discussion to Zulip. There are some alternatives out there, all with their own pros and cons, that communities may want to consider if they want to switch away from Discord.