Mourning Dan Williams
There is a support
effort underway for Dan's family as they come to terms with this loss.
There is a support
effort underway for Dan's family as they come to terms with this loss.
Although often well intentioned, sharing the result of a prompt and calling it "libre software" does not make the world a better place. Codeberg is not and does not want to be a place to dump such generated single-use software that no one else will ever look at. We are a place for people to collaborate and improve software together. Within this context, the recent votes can be understood as a reconfirmation of those principles: As we want to center on human collaboration, we will not actively support or engage in the creation of LLMs and will not put our limited resources to use for storing single-use software that would pollute our FLOSS commons.
One of the features that users often miss when moving from X11 to Wayland is the ability to save and restore the position of windows between sessions. At GUADEC 2026, held in A Coruña, Spain, Adrian Vovk provided an overview of work that has gone into providing a platform-wide save and restore framework for GNOME. After two failed attempts at landing an API, he believes that the third try will be the one to succeed—though not in time for the upcoming GNOME 51 release due in October.
Python Software Foundation security developer-in-residence Seth Larson has announced that the Python Package Index (PyPI) will now reject new files that are uploaded to releases older than 14 days. The restriction is to prevent the poisoning of old releases if publishing tokens or workflows of PyPI projects are compromised.
The discussion of this behavior began during PEP 740 (Digital Attestations) back in January 2024. The discussion was restarted in March 2026 after the popular packages LiteLLM and Telnyx were compromised. These packages were compromised due to a "mutable reference" in these projects' usage of the Trivy GitHub Action.
Originally the discussion stalled due to some projects depending on this behavior to add support for new Python versions to already-published releases. To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases (bucketed by number of days since the release). Later, specifically
cp314wheels were queried for the top 15,000 packages, revealing that only 56 projects of 15,000 had published a 3.14-compatible wheel more than 14 days after a release was available.
LWN covered the LiteLLM compromise in March.
Tracepoints in the kernel are useful for a variety of purposes: debugging, active monitoring, and performance measurements, among other things. Previously, any given BPF program could only be attached to a single tracepoint. Jiri Olsa has been working to change that, and led a discussion about his progress at the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit. That work has since been merged, and can be expected as part of the 7.2 kernel.
Version 153.0 of the Firefox web browser has been released. Notable changes in this release include a change to the default local-file-access permissions for extensions, enabling LAN restrictions by default for all users, a visual indicator when a web site has access to the user's location, the ability to merge PDFs and add images as pages within PDFs, as well as experimental support for the JPEG XL image format.
See the release notes for developers for all changes that affect web developers, and security advisories for vulnerabilities fixed in this release.
The Fedora Project is known for, among other things, having a well-defined set of processes for just about everything. It has extensive packaging guidelines that deal with the complexities of creating RPMs to install software, as well as processes for managing the legal questions that arise around shipping software. Fedora also has a well-defined change process for dealing with self-contained technical changes as well as major changes to the distribution, and other issues as they arise. At the moment, though, the project seems to be experiencing a sort of midlife crisis as it re-examines several of its change processes at once to determine if they are still effective.
Michael Catanzaro, who has been managing GNOME security issue tracking since
November 2020, has written a blog post that details some changes in how he will
be managing GNOME vulnerability reports from now on due to an increase in
AI-generated security reports. He will be switching from a 90-day deadline for
disclosures to 30 days for issues reported on August 1, or later. "The
shorter deadline would probably work better for GNOME even if not for the
increase in AI-generated issue reports.
"
He also has indicated that he will be stepping away from the task of managing security issue tracking entirely by December 1, 2026, which means that there will be a gap to fill:
Currently nobody else is tracking GNOME security issues. If you are an experienced GNOME community member and you are interested in taking over this work, let me know and I will help you get started. (Security tracking is not a good task for newcomers.)
This may also be an opportunity to improve our tracking infrastructure. I use a wiki page, but this is fairly primitive and requires considerable manual upkeep. It's easy to forget to update the page when an issue report is closed, for example. Ideally, we would replace the wiki with a proper web app that dynamically updates based on the actual state of the issue.
This whole week I had the feeling that people were starting to go on summer vacation, but running the numbers shows that I must have been wrong - it all looks pretty normal."
Half a Second tells that story as one continuous narrative: the burned-out volunteer who maintained the code alone and was patiently, expertly manipulated into giving it up; the engineer whose half-second of curiosity caught the attack through a chain of luck and hard-won instinct; and the operator who built it, who has never been identified and, this book argues, may never be.
Collabora has published a blog post about its work with Valve on Holo Core, which is a port of Arch Linux to aarch64 to be used as the the operating system on Valve's 64-bit Arm Steam Frame gaming system. Collabora has released the sources, binary packages, and a container image for aarch64 devices. The post describes some of the challenges in porting Arch Linux to a new architecture, and what remains to be done:
Whilst the infrastructure developed to this point is capable of building from first principles up until a point-in-time snapshot, the next step is to build this into a system which can track Arch Linux as it is developed. This work will serve as the basis of a continuously-operating CI system capable of shadowing Arch Linux itself. We will work with the upstream Arch Linux project to help Arch with their efforts to port the distribution to aarch64 architecture and work towards automated repeatable builds.
The post also includes instructions on how to create and test an aarch64 build container on an x86_64 host, for users who would like to follow along at home but lack a 64-bit Arm device.