Inside this week's LWN.net Weekly Edition:

• Front: Python thread safety; Namespace reference counting; Merigraf; Speeding up short reads; Julia 1.12; systemd security.
• Briefs: CHERIoT 1.0; Chromium XSLT; Arm KASLR; Bazzite; Devuan 6.0; Incus 6.18; LXQt 2.3.0; Rust 1.91.0; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

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.

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

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

Version 1.91.0 of the Rust language has been released. Changes include promoting aarch64-pc-windows-msvc to a tier-1 platform, a new lint rule to catch dangling raw pointers from local variables, and a fair number of newly stabilized APIs.

The kernel's file-I/O subsystems have been highly optimized over the years in the hope of providing the best performance for a wide variety of workloads. There is, however, one workload type that suffers with current kernels: applications that perform many short reads, in multiple processes, from the same file. Kiryl Shutsemau has been working on a patch to try to optimize this case, but the task is turning out to be harder than one might expect.

The Python Software Foundation, earlier this year, successfully obtained a $1.5 million grant from the US National Science Foundation "to address structural vulnerabilities in Python and PyPI". The actual grant came with some strings attached though, in the form of a requirement not to pursue diversity, equity, and inclusion programs. So the Foundation has withdrawn the proposal rather than agree to terms that run counter to its own mission.

We're disappointed to have been put in the position where we had to make this decision, because we believe our proposed project would offer invaluable advances to the Python and greater open source community, protecting millions of PyPI users from attempted supply-chain attacks. The proposed project would create new tools for automated proactive review of all packages uploaded to PyPI, rather than the current process of reactive-only review.

Linus has released 6.18-rc3 for testing. "Things feel fairly normal, and in fact the numbers say it's been a bit calmer than usual, but that's likely just the usual fluctuation in pull request timing rather than anything else".

Version 0.14 of the Typst document processor has been released.

If you need to comply with accessibility-related regulations, Typst 0.14 has your back. Typst now generates accessible documents by default, with opt-in support for stricter checks. For those working with complex illustrations, PDFs are now supported as a native image format. In case you're typesetting a book, the new character-level justification will give your layout the final touch. And if you're building a website or blog, many improvements to Typst's HTML export are waiting for you.

LWN looked at Typst in September.

The Spectre class of hardware vulnerabilities truly is a gift that keeps on giving. New variants are still being discovered in current CPUs nearly eight years after the disclosure of this problem, and developers are still working to minimize the performance costs that come from defending against it. The masked user-space access mechanism is a case in point: it reduces the cost of defending against some speculative attacks, but it brought some challenges of its own that are only now being addressed.

Inside this week's LWN.net Weekly Edition:

• Front: Git 3.0 topics; Lazy imports for Python; RubyGems; LLMs for patch review; DebugFS.
• Briefs: Fedora AI policy; OpenBSD 7.8; DigiKam 8.8.0; Forgejo 13.0; KDE Plasma 6.5; RubyGems; Valkey 9.0.0; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

The Git source-code management system is a foundational tool upon which much of the free-software community is based. For many people, Git simply works, though perhaps in quirky ways, so the activity of its development community may not often appear on their radar. There is a lot happening in the Git world at the moment, though, as the project works toward a 3.0 release sometime in 2026. Topics of interest in the Git community include the SHA-256 transition, the introduction of code written in Rust, and how the project should view contributions created with the assistance of large language models.

Version 8.8.0 of the digiKam photo-management system has been released. "This version delivers significant improvements in performance, stability, and user experience, with a particular focus on image processing, color management, and workflow efficiency". Changes include an import/export feature for tag hierarchies, focus-point visualization for some camera models, automatic use of the monitor color profile, and a background-blur tool.

Security updates have been issued by AlmaLinux (.NET 8.0, firefox, kernel, kernel-rt, libssh, and perl-JSON-XS), Debian (ark and libphp-adodb), Fedora (chromium and gi-docgen), Mageia (quictls), Oracle (.NET 8.0, .NET 9.0, firefox, httpd, kernel, libsoup3, libssh, microcode_ctl, and webkit2gtk3), SUSE (go1.24, go1.25, krb5, python-ldap, and webkit2gtk3), and Ubuntu (gst-plugins-base1.0, linux, linux-aws, linux-gcp, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-oracle, linux-oracle-5.15, linux-xilinx-zynqmp, linux-fips, linux-aws-fips, linux-azure-fips, linux-gcp-fips, linux-intel-iot-realtime, linux-realtime, and python-ldap).

The 6.18-rc2 kernel prepatch is out.

End result: rc2 is on the bigger side, and we still have some of the remaining regressions outstanding, but we should be making slow progress. It's fairly early days yet, so I'm not very worried. Things on the whole look fairly normal.

There have been many discussions in the free-software community about the role of large language models (LLMs) in software development. For the most part, though, those conversations have focused on whether projects should be accepting code output by those models, and under what conditions. But there are other ways in which these systems might participate in the development process. Chris Mason recently started a discussion on the Kernel Summit discussion list about how these models can be used to review patches, rather than create them.