Mason Freed and Dominik Röttsches have published a document with a timeline and plans for removing Extensible Stylesheet Language Transformations (XSLT) from the Chromium project and Chrome browser:

Chromium has officially deprecated XSLT, including the XSLTProcessor JavaScript API and the XML stylesheet processing instruction. We intend to remove support from version 155 (November 17, 2026). The Firefox and WebKit projects have also indicated plans to remove XSLT from their browser engines. This document provides some history and context, explains how we are removing XSLT to make Chrome safer, and provides a path for migrating before these features are removed from the browser.

LWN covered the Web Hypertext Application Technology Working Group (WHATWG) discussion about XSLT in August.

Version 2.3.0 of the Lightweight Qt Desktop Environment (LXQt) has been released. The highlight of this release is continued improvement in Wayland support across LXQt components. Rather than offering its own compositor, the LXQt project takes a modular approach and works with several Wayland compositors, such as KWin, labwc, and niri.

Linux has many security features and tools that have evolved over the years to address threats as they emerge and security gaps as they are discovered. Linux security is all, as Lennart Poettering observed at the All Systems Go! conference held in Berlin, somewhat random and not a "clean" design. To many observers, that may also appear to be the case for systemd; however, Poettering said that he does have a vision for how all of the security-related pieces of systemd are meant to fit together. He wanted to use his talk to explain "how the individual security-related parts of systemd actually fit together and why they exist in the first place".

Version 1.3 of the Open Container Initiative (OCI) Runtime Specification has been released. The specification covers the configuration, execution environment, and lifecycle of containers. The most notable change in 1.3 is the addition of FreeBSD to the specification, which the FreeBSD Foundation calls "a watershed moment for FreeBSD":

The addition of cloud-native container support complements FreeBSD's already robust virtualization capabilities, particularly the powerful FreeBSD jails technology that has been a cornerstone of the operating system for over two decades. In fact, OCI containers on FreeBSD are implemented using jails as the underlying isolation mechanism, bringing together the security and resource management benefits of jails with the portability and ecosystem advantages of OCI-compliant containers.

Security updates have been issued by Debian (bind9 and gimp), Fedora (chromium, fastapi-cli, fastapi-cloud-cli, gherkin, libnbd, maturin, openapi-python-client, python-annotated-doc, python-cron-converter, python-fastapi, python-inline-snapshot, python-jiter, python-openapi-core, python-platformio, python-pydantic, python-pydantic-core, python-pydantic-extra-types, python-rignore, python-starlette, python-typer, python-typing-inspection, python-uv-build, ruff, rust-astral-tokio-tar, rust-attribute-derive, rust-attribute-derive-macro, rust-collection_literals, rust-get-size-derive2, rust-get-size2, rust-interpolator, rust-jiter, rust-manyhow, rust-manyhow-macros, rust-proc-macro-utils, rust-quote-use, rust-quote-use-macros, rust-regex, rust-regex-automata, rust-reqsign, rust-reqsign-aws-v4, rust-reqsign-command-execute-tokio, rust-reqsign-core, rust-reqsign-file-read-tokio, rust-reqsign-http-send-reqwest, rust-serde_json, rust-speedate, rust-tikv-jemalloc-sys, rust-tikv-jemallocator, and uv), Mageia (golang and libavif), Red Hat (bind9.16, pcs, and qt6-qtsvg), SUSE (colord, ffmpeg, govulncheck-vulndb, jasper, openjpeg, poppler, qatengine, qatlib, runc, sccache, and tiff), and Ubuntu (keystone, libssh, linux-hwe-6.14, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-nvidia-tegra-igx, linux-raspi, runc-app, runc-stable, squid, squid3, and unbound).

Version 6.18 of the Incus container and virtual-machine management system has been released. Notable changes in this release include new configuration keys for providing credentials to systemd, BPF token delegation, VirtIO support for sound cards, the ability to export ISO volumes, improvements to the IncusOS command-line utility, and more.

Julia is a modern programming language that is of particular interest to scientists due to its high performance combined with language features such as Lisp-style macros, an advanced type system, and multiple dispatch. We last looked at Julia in January on the occasion of its 1.11 release. Early in October Julia 1.12 appeared, bringing a handful of quality-of-life improvements for Julia programmers, most notably support, though still experimental and limited, for the creation of binaries.

Security updates have been issued by Debian (dcmtk, geographiclib, gimp, pure-ftpd, and ruby-rack), Fedora (dotnet9.0), Oracle (expat, kernel, tigervnc, xorg-x11-server, and xorg-x11-server-Xwayland), Red Hat (git, mariadb:10.5, multiple packages, osbuild-composer, pcs, sssd, and tigervnc), SUSE (kernel and redis), and Ubuntu (google-guest-agent).

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!

The Project Zero blog explains that, on 64-bit Arm systems, the kernel's direct map is always placed at the same virtual location, regardless of whether kernel address-space layout randomization (KASLR) is enabled.

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.

Barry Warsaw, writing for the Python steering council, has announced that PEP 810 ("Explicit lazy imports") has been approved, unanimously, by the four who could vote. Since Pablo Galindo Salgado was one of the PEP authors, he did not vote. The PEP provides a way to defer importing modules until the names defined in a module are needed by other parts of the program. We covered the PEP and the discussion around it a few weeks back. The council also had "recommendations about some of the PEP's details, a few suggestions for filling a couple of small gaps", including:

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).

Version 6.0 ("Excalibur") of the systemd-averse Devuan distribution has been released. It is based on Debian 13 ("trixie"), and includes some of the significant changes from that release, including the merged /usr hierarchy. See the release notes for details.

The kernel's namespaces feature is, among other things, a key part of the implementation of containers. Like much in the kernel, though, the namespace API evolved over time; there was no design at the outset. As a result, this API has some rough edges and missing features. Christian Brauner is working to straighten out the namespace situation somewhat with this daunting 72-part patch series that, among other things, adds a new system call to allow user space to query the namespaces present on the system.

Joel Severin has announced the availability of his port of the Linux kernel to WebAssembly; one can go to this page and watch it boot in a browser.

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

Security updates have been issued by AlmaLinux (.NET 8.0, .NET 9.0, and webkit2gtk3), Debian (ruby-rack, strongswan, ublock-origin, and wordpress), Fedora (firefox, kea, openapi-python-client, openbao, python-uv-build, qt5-qtbase, ruby, ruff, rust-astral-tokio-tar, rust-attribute-derive, rust-attribute-derive-macro, rust-backon, rust-collection_literals, rust-get-size-derive2, rust-get-size2, rust-interpolator, rust-manyhow, rust-manyhow-macros, rust-proc-macro-utils, rust-quote-use, rust-quote-use-macros, rust-reqsign, rust-reqsign-aws-v4, rust-reqsign-command-execute-tokio, rust-reqsign-core, rust-reqsign-file-read-tokio, rust-reqsign-http-send-reqwest, rust-tikv-jemalloc-sys, rust-tikv-jemallocator, samba, skopeo, sssd, Thunar, unbound, uv, vgrep, and xorg-x11-server-Xwayland), Mageia (bind, libtiff, sope, and transfig), Oracle (compat-libtiff3, kernel, libtiff, redis, redis:6, and redis:7), Red Hat (kernel, kernel-rt, libssh, xorg-x11-server, and xorg-x11-server-Xwayland), Slackware (seamonkey), SUSE (bind, chromedriver, chromium, colord, coreboot-utils, git-bug, ImageMagick, java-11-openj9, java-17-openj9, java-21-openj9, java-25-openj9, kea, libmozjs-115-0, libmozjs-140-0, libssh, libtiff-devel-32bit, nodejs18, ongres-scram, poppler, python311-starlette, rav1e, squid, strongswan, webkit2gtk3, xorg-x11-server, and xwayland), and Ubuntu (linux-gcp-6.14 and linux-hwe-6.8).

Linus has released 6.18-rc4 for testing. "Last week in fact felt *so* calm that I was surprised to notice that rc4 isn't really smaller than usual: all the stats look very normal, both in number of changes and where the changes are."

The relatively small 6.17.7, 6.12.57, and 6.6.116 stable kernels have been released; each contains another set of important fixes.

Julian Andres Klode has announced that the Debian APT package-management tool will acquire "hard Rust dependencies sometime after May 2026. "If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port."

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.