LWN is Promoting LLM Slop, Makes Excuses for "Age Verification" (Surveillance), Promotes Rust (Microsoft GitHub)

posted by Roy Schestowitz on Apr 09, 2026

• Slop Inside Kernels

  • LWN ☛ The role of LLMs in patch review [Ed: Slop entering Linux little by little]

    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.

    Morton began by saying that the current way Sashiko integrates into the memory-management workflow isn't working. He merges patches to his tree, and ""then half a day later a bunch of potential issues are identified."" Morton stated that he was going to further increase the lag between seeing a patch set on the mailing list and merging it to his tree, to give Sashiko time to produce feedback and patch authors time to respond to it. He also wanted its reviews distributed to a wider audience — partly to better determine how useful its comments are, which he is ""paying close attention to"".

  • LWN ☛ Vibe-coded ext4 for OpenBSD [Ed: Slop makes worthless code that is unmaintainable, but LWN is connected to LF, which is paid by Microsoft et al to market slop]

    A number of projects have been struggling with the question of which submissions created by large language models (LLMs), if any, should be accepted into their code base. This discussion has been further muddied by efforts to use LLM-driven reimplemention as a way to remove copyleft restrictions from a body of existing code, as recently happened with the Python chardet module. In this context, an attempt to introduce an LLM-generated implementation of the Linux ext4 filesystem into OpenBSD was always going to create some fireworks, but that project has its own, clearly defined reasons for looking askance at such submissions.

• Applications

  • LWN ☛ Pandoc: a workhorse for document conversion [LWN.net]

    Pandoc is a document-conversion program that can translate among a myriad of formats, including LaTeX, HTML, Office Open XML (docx), plain text, and Markdown. It is also extensible by writing Lua filters that can manipulate the document structure and perform arbitrary computations. Pandoc has appeared in various LWN articles over the years, such as my look at Typst and at the importance of free software to science in 2025, but we have missed providing an overview of the tool. The February release of Pandoc 3.9, which comes with the ability to compile the program to WebAssembly (Wasm), allowing Pandoc to run in web browsers, will likely also be of interest.

• Distributions and Operating Systems

  • IBM

    • LWN ☛ Objections to systemd age-attestation changes go overboard [Ed: One person from Red Hat (Joe Brockmeier) covering up for another person from Red Hat]

      In early March, Dylan M. Taylor submitted a pull request to add a field to store a user's birth date in systemd's JSON user records. This was done to allow applications to store the date to facilitate compliance with age-attestation and -verification laws. It was to be expected that some members of the community would object; the actual response, however, has been shockingly hostile. Some of this has been fueled by a misinformation campaign that has targeted the systemd project and Taylor specifically, resulting in Taylor being doxxed and receiving death threats. Such behavior is not just problematic; it is also deeply misguided given the actual nature of the changes.

      Age-attestation and -verification laws that place requirements on operating-system providers have passed in California and Brazil, and are being discussed in many other states and locations. This has led a number of Linux distributions to consider ways that they can comply with the laws if necessary. One idea that is being worked on is to add parental controls to the XDG Accounts portal which is a mechanism that allows applications to query for information about users, such as their name or avatar image. It can gather this information from various data sources, including systemd.

• Anti-Copyleft

  • Programming/Development

    • Rust

      • LWN ☛ Rust's next-generation trait solver [Ed: LWN promoting the Microsoft-controlled Rust, as usual]

        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.

• Slop, Entrapment (Microsoft GitHub) and Security Failures

  • LWN ☛ The many failures leading to the LiteLLM compromise

    This story starts with a different project, Trivy, which is a widely used security scanner, distributed under the Apache-2.0 license. As is often the case with these scanners, Trivy releases normally include tests for newly discovered vulnerabilities, so projects that depend on Trivy to detect potential security problems in their code have every reason to want to rerun their scans when a new release is made. Many projects hosted on GitHub thus set up an action so that, when a new release tag shows up for Trivy, new scans are automatically run, just in case Trivy has any new problems to point out.

    On March 20, Paul McCarty announced that Trivy had been compromised; Philipp Burckhardt wrote up a detailed report on what was done. Somebody had managed to obtain credentials giving write access to the Trivy repository. This attacker then placed commits with malware in that repository, but they did so without changing any existing branches, avoiding the notifications that would have normally gone out in response to such changes. Instead, a large number of release tags were force-pushed to point to the new commits, which was sufficient to cause other projects to perform automatic Trivy runs.

    The Trivy malware was of the information-stealing variety; whenever it ran within a project's context, it would sweep up everything it could get its virtual hands on and send it back to the attackers. Trivy itself was never the primary target; it was just a stepping stone giving access to other projects of interest. Just how many projects this exploit was able to hit may not become clear for some time.