Version 1.0 of the Capability Hardware Extension to RISC-V for IoT (CHERIoT) specification has been released. CHERIoT is a hardware-software system for secure embedded devices, and the specification provides a full description of the ISA and its intended use by CHERIoT RTOS. David Chisnall has written a blog post about the release that explains its significance as well as plans for CHERIoT 2.0 and beyond:

The last change that we made to the ISA was in December 2024, so we are confident that this is a stable release that we can support in hardware for a long time. This specification was implemented by the 1.0 release of CHERIoT Ibex and by CHERIoT Kudu (which has not yet had an official release). These two implementations demonstrate that the ISA scales from three-stage single-issue pipelines to six-stage dual-issue pipelines, roughly the same range of microarchitectures supported by Arm's M profile.

We at SCI have the first of our ICENI chips, which use the CHERIoT Ibex core, on the way back from the fab now and will be scaling up to mass production in the new year. I am not allowed to speak for other folks building CHERIoT silicon, but I expect 2026 to be an exciting year for the CHERIoT project!

While it remains true that KASLR should not be trusted to prevent exploitation, particularly in local contexts, it is regrettable that the attitude around Linux KASLR is so fatalistic that putting in the engineering effort to preserve its remaining integrity is not considered to be worthwhile. The joint effect of these two issues dramatically simplified what might otherwise have been a more complicated and likely less reliable exploit.

Use lazy as the keyword. We debated many of the given alternatives (and some we came up with ourselves), and ultimately agreed with the PEP's choice of the lazy keyword. The closest challenger was defer, but once we tried to use that in all the places where the term is visible, we ultimately didn't think it was as good an overall fit. The same was true with all the other alternative keywords we could come up with, so... lazy it is!

What about from foo lazy import bar? Nope! We like that in both module imports and from-imports that the lazy keyword is the first thing on the line. It helps to visually recognize lazy imports of both varieties.

Python already has several ways to run programs concurrently — including asynchronous functions, threads, subinterpreters, and multiprocessing — but all of those options have drawbacks of one kind or another. PEP 703 ("Making the Global Interpreter Lock Optional in CPython") removed a major barrier to running Python threads in parallel, but also exposed Python programmers to the same tricky synchronization problems found in other languages supporting multithreaded programs. A new draft proposal by Mark Shannon, PEP 805 ("Safe Parallel Python"), suggests a way for the CPython runtime to cut down on concurrency bugs, making it more practical for Python programmers to use versions of the language without the global interpreter lock (GIL).

Wasm is similar to every other arch in Linux, but also different. One important difference is that there is no way to suspend execution of a task. There is a way around this though: Linux supports up to 8k CPUs (or possibly more...). We can just spin up a new CPU dedicated to each user task (process/thread) and never preempt it

The idea of automatic syntax-aware merging in version-control systems goes back to 2005 or earlier, but initial implementations were often language-specific and slow. Mergiraf is a merge-conflict resolver that uses a generic algorithm plus a small amount of language-specific knowledge to solve conflicts that Git's default strategy cannot. The project's contributors have been working on the tool for just under a year, but it already supports 33 languages, including C, Python, Rust, and even SystemVerilog.

Michael Hudson-Doyle, a member of Ubuntu's Foundations team, has announced the introduction of an "architecture variant" for Ubuntu 25.10:

By making changes to dpkg, apt and Launchpad, we are able to build multiple versions of a package, each for a different level of the x86-64 architecture, meaning we can have packages that specifically target x86-64-v3, for example.

As a result, we're very excited to share that in Ubuntu 25.10, some packages are available, on an opt-in basis, in their optimized form for the more modern x86-64-v3 architecture level.

See the announcement for details on opting in to x86-64-v3 packages.

The Universal Blue project has announced the Fall update for the Fedora-based Bazzite gaming distribution. This release brings Bazzite up to Fedora 43, includes support for additional handheld gaming systems, as well as drivers for a number of steering wheel devices, and more.