Perl and LWN Leftovers (LWN Paywall Expiry)

posted by Roy Schestowitz on Oct 22, 2026

• GNU/Linux

  • Kernel Space / File Systems / Virtualization

    • LWN ☛ The 2026 Maintainers Summit [Ed: So many women. Not. Just one. Slopping away with LLMs won't change that; it'll still be a men's club.]

      The Maintainers Summit is a one-day, invitation-only gathering of about 30 kernel developers; it is held once each year to discuss policy-related issues that are not always amenable to resolution via email. The 2026 event was scheduled for October 8 in Prague, Czechia. Unsurprisingly, the discussion there was dominated by large language models (LLMs) and their effect on the development community, but some time was also found to talk about security bugs and long-term succession planning.

      Unlike previous years, the 2026 Summit did not have a well-defined schedule with specific developers identified to lead the discussion on each topic. The conversation was rather more free-flowing, and this writeup will match that structure (or lack thereof). Some minimal reordering has been done in an attempt to provide a more coherent overview.

    • LWN ☛ Collaborating with out-of-tree tracers

      LTTng creator Mathieu Desnoyers seems a bit trapped in something of a catch-22. At the 2026 Linux Plumbers Conference (LPC), he led a discussion on the problem he is having in trying to collaborate with other tracing projects (e.g. ftrace, perf) in the kernel. The feedback he has gotten, both over the years and more recently, does not show a path that would allow him to contribute the 21-year-old GPLv2-licensed LTTng tracing framework, or, incrementally, features from it, to the mainline kernel.

      Ftrace creator (and tracing-track organizer) Steven Rostedt introduced the session as ""the least-controversial topic of today"" to audience laughter. Desnoyers said that he has been maintaining LTTng since 2005 and wanted to explore ""how we can improve collaboration between people working on out-of-tree tracer projects and [the] upstream kernel"". He said that he wanted the session to be a discussion, not a presentation, thus only had two slides.

    • LWN ☛ The [vx]swap showdown

      The kernel's swap layer has undergone some significant changes over the course of the last year and a number of longstanding problems have been addressed. One problem that has not yet been solved in the mainline is the direct tie between slots in the swap cache and space in persistent swap files, which can cause highly inefficient resource use. There are two competing solutions for this problem, neither of which has, as yet, reached readiness for merging; a lengthy discussion on possible paths forward shows ongoing disagreement over the best path forward.

      The kernel's zswap layer highlights the difficulties with the current design of the swap subsystem. Zswap intercepts folios that are to be pushed out to a swap file and, instead of writing them to that file, compresses their contents and stores the result in RAM. It is, essentially, a way of trading some CPU time for more free memory while keeping data close to hand and minimizing disk I/O. Use of zswap has become increasingly popular with current workloads.

• Free, Libre, and Open Source Software

  • GNU Projects

    • LWN ☛ GCC development with large-language models

      After much deliberation, the GCC project recently came up with a policy on the use of large language models for development of the compiler suite. It is somewhat restrictive, but still leaves room for LLMs in the development process. At the 2026 GNU Tools Cauldron, Jeff Law and Kyrill Tkachov discussed how these tools have been useful for them.

      Law began by reviewing the project's policy, which is ""to decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content"". That policy is not universally applied, though; it is specifically looser when it comes to additions to the test suite. LLMs are usable to help with understanding code, look for bugs, review patches, and more. But the project wants to avoid polluting its copyright with LLM-generated code; the law in this area is not settled, so the project is taking a conservative stance. The policy will be reviewed regularly, he said, and could be revised in the near future.

    • LWN ☛ Adding kernel control-flow-integrity checking to GCC

      While many developers are struggling to keep up with the flood of vulnerability reports, others are still focused on preventing those reports from happening in the first place. Control-flow integrity (CFI) is the term for preventing (or at least detecting) exploits that divert the flow of control from its intended paths. At the 2026 GNU Tools Cauldron, Kees Cook presented his changes to the GCC compiler suite to support forward-edge CFI for the kernel.

  • Programming/Development

    • Perl / Raku

      • Perl ☛ 2026-10-15 [Older] pperl 0.6.23 - RANT, REPL and SPEED

      • Perl ☛ 2026-10-11 [Older] ANNOUNCE: Perl.Wiki V 1.56, CPAN::MetaCurator V 1.33

    • Rust

      • LWN ☛ An update on Rust's project goals

        Tomáš Šedovič is a program manager at the Rust Foundation. He co-leads the goals team, which helps organize the Rust project's overall goals, including making sure that the people who have agreed to work on one have the support they need. At Kangrejos 2026, he provided an overview of the Rust project's goal processes aimed at ensuring that the Rust for Linux developers were aware of how the project organizes, tracks, and amends goals. The Rust for Linux project has inspired several current project goals, so he thought that getting an inside view of the process might be helpful.

        The Rust project's goals are one of several entry points to making changes in Rust, Šedovič said. If someone wants to make a change and knows how, they can just talk to the relevant team and do it. If someone wants to make a change, but they don't know where to start or who to talk to, that's where the goals team comes in. They will take a proposal, work on it in collaboration with the submitter, bring it to the right people to make the change, and follow up to make sure everything stays on track.

      • LWN ☛ Owning C types from Rust code

        Rust's system of ownership and borrowed references is convenient when it can correctly model a program's needs. The Rust for Linux project has worked to provide adapters between Rust's semantics and the existing C code in the kernel. At Kangrejos 2026, Andreas Hindborg spoke about a patch series implementing the next such adaptor: an Ownable trait for representing objects that are allocated in C code, but which Rust code is responsible for cleaning up (if not necessarily deallocating) when it is done with them. He hoped to finally reach a consensus on the patch series, after months of discussion on the mailing list.

        In the block subsystem, where Hindborg does most of his work, there is a memory pool set aside for handling concurrent requests. Each I/O request is represented by a bio structure. To make a new request, the block layer identifies an unused structure in the pool, fills it with the details of the request, and passes it to the appropriate driver. The driver handles the request, clears the request structure, and passes it back to the block layer to be reused. That design avoids the overhead of constantly allocating and deallocating for each request, but it also doesn't quite fit with the existing abstractions in the kernel's Rust code.

  • Proprietary / Vendor Lock-in

    • LWN ☛ The state of systemd: 2026 edition

      At the 2026 All Systems Go! conference, systemd maintainers Luca Boccassi and Zbigniew Jędrzejewski-Szmek delivered the traditional "state of the project" session with an overview of the systemd project's accomplishments in the past year. That was followed by a maintainer round table where Boccassi, Jędrzejewski-Szmek, Daan De Meyer, and project leader Lennart Poettering fielded questions about systemd's size, health, and if it might replace Kubernetes. (It will not.)

      I did not attend the All Systems Go! conference this year, but I watched the videos of the sessions after they were published. The "systemd: state of the project" and "systemd: round table" recordings are available in multiple video and audio-only formats via the Chaos Computer Club's media archive. The slides for the "systemd: state of the project" talk are also available.