fidzu : Fedora

Putting on my Planet GNOME editor hat for a quick PSA!

Planet GNOME is a convenient aggregator for personal blogs by members of our community. While all content must follow our Code of Conduct, the views expressed in these posts are solely those of the individual authors.

They don't represent or reflect the opinions of the GNOME Project as an entity or community.

To help highlight this, we've added a "Voices of the community" tagline to the website header. It links directly to our "Add feed" section, which also emphasizes that Planet collects the latest posts from personal blogs.

Enjoy the personal insights and variety of perspectives!

23 Jul 2026 7:01am GMT

If you want to start a fight, bring up the topic of closing unresolved issues. People have strong opinions on this topic, and for good reason. To maintainers, open issues can be overwhelming. They represent a backlog of work that will never get done. To users, issues represent a real pain point. If bug reports reports are contributions - and they are - then opening an issue is often the first (or only) contribution a particular person will make to the project. A bad bug reporting experience is a bad contributor experience, and it may chase someone away for good.

Just about everyone would agree that there are some cases where closing an unfixed issue makes sense. Not everyone will agree on where to draw the line, though. In general, the best approach is to have a clear, well-communicated policy and to close issues with respect for the time that people put into filing them. The rest of this post has my suggestions for how to approach closing issues. You, of course, can set whatever policy you want for your project.

Types of issues and how to close them

• Spam. Close these immediately, no comment necessary. If your issue tracker supports hiding or removing issues, make these go away. They add no value except as something you might want to track.
• Duplicate. close these immediately. If your issue tracker supports linking it to the original issue, do that. Otherwise, comment with a link to the original issue.
• Invalid reports
  • Upstream bug. Leave these open with a link to the upstream bug report until a fix reaches your project. Some projects will ask the reporter to file upstream bugs themselves, but I prefer to do it myself so that I can provide project context the user might not know and because I'll want to be informed when it's fixed anyway.
  • Downstream bug. This is rarer than the upstream bug case, but it happens somewhat frequently in the case of distro-packaged software. In this case, directing the reporter to the downstream issue tracker in a closure message is sufficient.
  • Unsupported version. If your project has a defined support policy, you can close reports filed against an unsupported version. You can choose to close these immediately with a reference to the supported versions, but it's friendlier to leave it open to give the reporter a chance to test a supported version.
  • Not a bug. If the issue describes intended behavior, you can close it immediately. Consider whether or not this is actually a bug in your documentation.
• Out of scope. This generally applies to feature requests more than bugs. If someone asks for something that's not what you intend for the project, close the issue.
• Not reproducible. If neither you nor the reporter can reproduce an issue, close it. In this case, I recommend leaving it open for a period of time (say 30 days or so) in order to give other people a chance to find a reproduction case.
• Unresponsive reporter. If you lack the information necessary to address an issue and the reporter doesn't reply to your questions, you can close the issue. As with the "not reproducible" case, you should give people a reasonable amount of time to answer. 30 days is a good starting point. Ideally, people would answer within a day or two, but they have lives just like you do.
• Stale. This is a distinct category from "unresponsive reporter" and the one most likely to make people upset. If there's a valid report with sufficient information but no one has touched it, leave it open. Autoclosing these is not only user-hostile, but it encourages noisy behavior when people leave a comment just to keep the issue open.

Not included in the list above are resolved issues: fixed bugs and implemented feature requests. There's no question that these should be closed. The only question is "when?" I'm partial to closing these when the fix or feature is in a shipped release. The tooling doesn't always make that easy. Fedora has some automated connections between its update system and Bugzilla that will move reports through automatically. GitHub-hosted projects tend to close issues when a commit or pull request that says "fixes #12345" lands in the primary branch. There are ways to queue closures for when a corresponding release lands, but it tends to be more effort than most maintainers are willing to set up (myself included).

This post's featured photo by Neringa Hünnefeld on Unsplash.

The post How to close issues appeared first on Duck Alignment Academy.

22 Jul 2026 12:00pm GMT

22 Jul 2026 11:56am GMT

Hoy me puse a experimentar con la arquitectura de MicroVMs en QEMU y libvirt, y la neta me quedé impresionado.

Si tú me has seguido por acá, sabes que en varios escenarios de migración desde entornos legacy (como VMware) a clusters hiperconvergentes de 3 nodos con libvirt y Ceph, el reto clásico siempre ha sido la eficiencia: las máquinas virtuales tradicionales tardan entre 30 y 90 segundos en arrancar y tragan gigabytes de RAM nomás para estar paradas.

Hoy te voy a enseñar cómo armé un motor de compilación efímero que arranca una máquina virtual aislada por hardware en menos de 200 milisegundos, compila tu código o empaqueta un RPM, guarda los artefactos y se destruye sin dejar rastro.

# repos
zawertun/crystal

# build_deps
crystal
shards
libssh-devel
gc-devel
pcre2-devel
openssl-devel
gcc
make

<!-- microvm_build.xml -->
<domain type='kvm'>
  <name>microvm-source-builder</name>
  <memory unit='MiB'>128</memory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='microvm'>hvm</type>
    <kernel>/boot/vmlinuz-current</kernel>
    <initrd>/var/tmp/microvm-initrd.img</initrd>
    <cmdline>console=ttyS0 quiet reboot=k panic=1 pci=off</cmdline>
  </os>
  <features>
    <acpi/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
  </devices>
</domain>

#!/bin/sh

# microvm_init.sh
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs none /dev

printf "\n[GUEST INIT] MicroVM kernel booted successfully!\n"

# Procesar fuentes externas de repositorios (repos)
if [ -f /etc/build_workspace/repos ]; then
    printf "[GUEST INIT] Procesando repositorios externos...\n"
    while IFS= read -r line || [ -n "$line" ]; do
        case "$line" in
            \#*|"") continue ;;
            https://*|http://*)
                printf "[GUEST INIT] Descargando repo: %s\n" "$line"
                curl -sSL -o "/etc/yum.repos.d/$(basename "$line").repo" "$line"
                ;;
            *)
                printf "[GUEST INIT] Habilitando COPR: %s\n" "$line"
                dnf -y copr enable "$line" &> /dev/null || true
                ;;
        esac
    done < /etc/build_workspace/repos
fi

# Procesar paquetes de dependencias de compilación (build_deps)
if [ -f /etc/build_workspace/build_deps ]; then
    printf "[GUEST INIT] Instalando dependencias de compilación...\n"
    deps="$(grep -v '^#' /etc/build_workspace/build_deps | tr '\n' ' ')"
    if [ -n "$deps" ]; then
        dnf -y install $deps &> /dev/null || true
    fi
fi

printf "[GUEST INIT] Ejecutando carga de compilación...\n"

if [ -x /bin/builder ]; then
    /bin/builder --version
    /bin/builder
fi

poweroff -f

#!/usr/bin/bash

# run_microvm_build.bash
set -euo pipefail
IFS=$'\n\t'

readonly ScriptDir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly ResultsDir="${ScriptDir}/results"
readonly DomainName="microvm-source-builder"
readonly XmlTemplate="${ScriptDir}/microvm_build.xml"
readonly InitTemplate="${ScriptDir}/microvm_init.sh"
readonly TmpDir="$(mktemp -d --tmpdir=/var/tmp microvm-gnu-poc.XXXXXX)"
chmod 755 "$TmpDir"

cleanup() {
    local exit_code=$?
    printf "[CLEANUP] Limpiando dominio %s y directorio %s...\n" "$DomainName" "$TmpDir" >&2
    virsh -c qemu:///system destroy "$DomainName" &> /dev/null || true
    virsh -c qemu:///system undefine "$DomainName" &> /dev/null || true
    rm -rf "$TmpDir"
    exit "$exit_code"
}
trap cleanup EXIT

# ... preparación de fuentes e initrd ...

run_microvm_poc() {
    local -r runtime_xml="$TmpDir/runtime_domain.xml"
    local -r exec_log="$JobResultsDir/logs/microvm_source_build.log"

    virsh -c qemu:///system define "$runtime_xml" &> /dev/null
    virsh -c qemu:///system start "$DomainName" &>> "$exec_log" || true

    cp -f "$TmpDir/src/hello" "$ArtifactsDir/gnu-hello"
    chmod +x "$ArtifactsDir/gnu-hello"
}

results/
└── microvm-shellmin-builder/
    └── job-20260722-060942-2579/
        ├── artifacts/
        │   └── shellmin
        └── logs/
            ├── build.log
            └── microvm.log

22 Jul 2026 11:00am GMT

Due to the increase in AI-generated security vulnerability reports, it is time for some changes in how GNOME manages vulnerability reports.

These policy changes intentionally do not distinguish between reports that contain AI-generated content and those that do not. Following the same rules for all vulnerability reports is simpler than having two different ways of doing things. Reporters rarely disclose AI use, and it's nice to not have to guess whether the issue report is AI-generated or not; it's normally obvious, but not always. Also, vulnerability reports that are not discovered by AI are becoming increasingly rare. Non-AI reports are now moderately unusual, so it really doesn't make sense to optimize for them.

Reduced Disclosure Deadline

Traditionally, I have applied a 90 day disclosure deadline to all security issues reported to GNOME Security. 90 days is an industry standard timeline, but it doesn't work particularly well for GNOME. In practice, almost all GNOME maintainers handle vulnerability reports in one of two ways:

• The project maintainer fixes the issue quickly, typically within 1-3 weeks after it is reported.
• The project maintainer does not fix the issue at all. The issue report eventually reaches the 90-day disclosure deadline, at which point I unset confidentiality.

The 90-day deadline is intended to allow project contributors time to fix the issue before it becomes public, but in practice, maintainers do not actually make use of most of this time. I disclose the issue report and request a CVE when it is fixed or when the disclosure deadline is reached, whichever comes first. Once a CVE is assigned, contributors who are not regular project maintainers will sometimes attempt to fix it. Accordingly, keeping the issue reports confidential for 90 days only introduces a delay that is not useful.

Some other projects, notably the Linux kernel, have implemented an immediate full disclosure policy for issue reports that seem to be AI-generated, on the basis that a vulnerability that can be discovered by AI is presumably already known to attackers. But this policy seems pretty extreme, and is certainly unkind to maintainers who might feel pressured to urgently fix the issue. Immediate disclosure would not work well for GNOME.

Instead, I will switch to a 30 day disclosure deadline for issues reported on August 1, 2026 or later. This seems like a good compromise. The shorter deadline would probably work better for GNOME even if not for the increase in AI-generated issue reports.

Procedure for Projects that Prohibit AI-Generated Content

If a project prohibits issue reports that contain AI-generated content, I will no longer forward security issues reported to GNOME Security to the project's issue tracker, since the overwhelming majority of vulnerability reports contain AI-generated content and would violate the project's policy. Instead, I will immediately close the issue report in the GNOME Security issue tracker, then ping the project maintainers to let them know about the existence of the report. If you prefer to receive vulnerability reports in your project's issue tracker, then please change your project's AI policy to make an exception for vulnerability reports.

Unfortunately, GNOME maintainers don't have access to confidential issues in this issue tracker, and GitLab does not allow CCing individual developers on confidential issue reports. I had been planning to adopt immediate disclosure for these issues only, but perhaps we should instead expand the permissions to allow all GNOME developers to see the issue tracker. Opinions welcome.

Moving On

I have been managing GNOME security issue tracking since November 2020. (Thank you to Red Hat for supporting this work.) Security tracking is largely a secretarial duty: I keep track of issues when they are reported and when they are closed, disclose them when the deadline is reached, and request CVEs when appropriate. It is not a huge amount of work, but I am getting tired of it, so it's time for a change. I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

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.

20 Jul 2026 1:20pm GMT

TL;DR https://codeberg.org/cryptomilk/crane-wyoming

Where I started

I use Home Assistant, and for text-to-speech (TTS) I've been running Piper through Wyoming Piper.

Piper is a fast, local neural TTS engine originally built for the Rhasspy project and now maintained by the Open Home Foundation. It's designed to run entirely offline, even on modest hardware like a Raspberry Pi.

Wyoming is the open protocol Home Assistant uses to talk to voice components like TTS, speech-to-text, wake word, voice activity detection (VAD, which decides when someone has started or stopped speaking) over the network, so any service that speaks Wyoming can be plugged in as a satellite. Wyoming Piper just wraps Piper so it can be served this way.

Both work well and I have no complaints about reliability. My issue is quality: the German voices aren't great. Piper depends on open datasets for training, and good open German speech data is scarce, so the German models lag behind the English ones. I also run TTS locally on my desktop for event reminders, so voice quality matters to me beyond just Home Assistant.

Looking for something better

I wanted better output quality, so I started looking at alternatives and found Crane, a Rust inference
framework built on Candle.

An "inference model" is a trained neural network used to actually produce output like text, speech, an image, rather than to learn from data (that's "training"). An "inference framework" is the software that loads such a model and runs it efficiently: managing GPU/CPU memory, batching requests,
and exposing an API around it. Piper and Crane are both inference frameworks.

Crane already had Qwen3-TTS support, and its Serena voice's German output sounded noticeably better. I also wanted to try Voxtral-4B-TTS-2603, Mistral's open-weight TTS model, so I added support for it. Voxtral TTS produces expressive, natural-sounding speech across 9 languages including German, with low time-to-first-audio and streaming support. It is a good fit for a voice assistant that needs to start speaking quickly.

Adding Wyoming support

Once Voxtral was working in Crane, I built crane-wyoming, a standalone Wyoming protocol server, so Home Assistant could use these models as its TTS service. To make that possible, I added the Tts trait and the surrounding TTS abstractions to Crane, since there was no stable interface for driving a TTS model on its own, separate from Crane's full inference engine (tokenizer/LLM/VLM machinery). Those abstractions have since been merged upstream: lucasjinreal/Crane#44.

crane-wyoming depends on Crane only for that Tts trait and the concrete model types it needs to construct, not Crane's engine crate. So it carries its own small TTS-only model runtime (one dedicated worker thread per loaded model) and its own on-disk response cache.

The project grew into a small Cargo workspace. Besides the Wyoming server
itself, it now has cw-say, a standalone CLI client for scripting.

It also has sd_crane_wyoming, an output module for speech-dispatcher. speech-dispatcher is the common Linux TTS abstraction layer that screen readers like Orca, and other accessibility tooling, talk to. It launches output modules as subprocesses and speaks to them over stdin/stdout, using its own line-oriented, SMTP-style protocol. sd_crane_wyoming translates that into Wyoming requests against a running crane-wyoming server. That way, the same server process and cache serving Home Assistant can also serve the desktop. After registering it in speechd.conf, spd-say -o crane "..." works. So does anything else built on speech-dispatcher, like Firefox's "Read Aloud" or Orca itself. All of it gets the same voice quality as Home Assistant, without running a second TTS backend.

What's next

• Speech-to-text. I've added Qwen3-ASR support for utomatic speech recognition (ASR) into Crane. This needs to be wired in crane-wyoming next. Also Voxtral-Mini-4B-Realtime-2602 is interesting.
• VAD. Crane already has a Silero VAD implementation. Adding it for STT is straight forward.
• Wake word. Once VAD is in place, add Open Wake Word support or similar.

With all of that implemented, you'd have a complete self-hosted Wyoming voice stack with no cloud dependency.

Current limitations

The catch is that you need a GPU to run it well.

If you only need TTS for occasional things like reminders, short announcements, running it on CPU with caching is enough, since repeated phrases just get served from cache instead of resynthesized.

All of this is for advanced users and hackers right now. There's no polished packaging yet. Systemd units exist for both system and user services, including socket activation, but you still have to build from source.

However testing and feedback are welcome.

https://codeberg.org/cryptomilk/crane-wyoming

20 Jul 2026 1:09pm GMT

Another week, another saturday post recaping things. :)

18 Jul 2026 5:48pm GMT

Across the various Fedora working groups, a primary shared focus is the execution of the Fedora 45 Mass Rebuild, which aligns with widespread efforts to modernize core toolchains, system defaults, and developer environments. Another major cross-team initiative is the ongoing infrastructure migration from Pagure to Forgejo, requiring coordination across FESCo, Release Engineering, Design, and Docs. Artificial intelligence and automation have also emerged as a prominent, dual-sided theme: while teams like AI & ML, Security, and Release Engineering are actively developing AI agents to automate nightly compose log analysis and vulnerability scanning, Infrastructure and Release Engineering are simultaneously deploying defensive measures-such as retaining the Anubis system and disabling web-based git blame-to mitigate aggressive AI web scrapers. Finally, there is a strong, unified push toward improving community governance and the contributor experience, evidenced by the drafting of new usage and conflict of interest policies, the creation of the Docs Captain pilot program, and the development of modernized onboarding materials.

Announcements

For Fedora contributors, the Fedora 45 Mass Rebuild has officially started, and maintainers are encouraged to track build failures on Koji. Related to package maintenance, a list of long-term FTBFS (fails to build from source) packages has been published; these packages have failed to build since Fedora 42 and will be retired in early August unless they are fixed or exempted. On a celebratory note, the latest Fedora Podcast (episode 056) highlights the 2026 Fedora Contributor Recognition Program winners, featuring a great conversation with Justin Forbes and Ankur Sinha about keeping the project running and welcoming.

Several new self-contained Change Proposals have also been announced for Fedora 45. The distribution's default databases are slated to be updated to the latest LTS releases, MySQL 9.7 and MariaDB 12.3. The ODBC stack is being modernized to replace static driver registrations with auto-generated configurations using per-driver drop-in snippets. LibreOffice will see two major packaging improvements: the introduction of upstream-sourced hunspell dictionaries for better version syncing, and a switch to HTML-based, noarch help files to significantly reduce repository space. Finally, to simplify Fedora CoreOS provisioning, a proposal aims to enable Ignition to natively accept Butane YAML configurations directly at first boot, removing the need for a separate transpilation step.

Council

During the bi-weekly meeting, the Council reviewed the draft Conflict of Interest Guidelines and agreed to publish the document on Discourse for a two-week public feedback period, offering a key opportunity for community engagement before the rules are formalized. The Council also discussed the upcoming Fedora Forge Usage Policy, focusing heavily on the proposed rules for archiving inactive repositories. To avoid disruptive surprises for existing contributors, the Council formally took ownership of the policy's publication but decided to delay its release until a consensus is reached on how to handle repository archiving. Additionally, members were reminded of an open ticket regarding the Fedora logo license, which will be closed as the license cannot be changed.

On the forums, the discussion surrounding the Fedora Innovation Lifecycle continued with a focus on re-imagining "Initiatives." Members proposed a lightweight, self-managed alternative to the Sandbox process that would allow contributors to showcase multi-release work without strict deadlines or approvals, relying instead on simple "heartbeat" checks to ensure the projects remain active.

Decisions

• The Council will publish the drafted Conflict of Interest Guidelines on Discourse for a two-week public feedback period before making any formal decisions.
• The Council formally took over the finalization and publication of the Fedora Forge Usage Policy, but will resolve the ongoing debate regarding the archiving of inactive repositories before publishing it under the Policy Change Policy framework.

Learn more about the Council team.

FESCo

This week, FESCo processed a massive wave of System-Wide Change proposals for Fedora 45, establishing a clear theme of modernizing core toolchains, system defaults, and developer environments. Significant proposals under review include switching the default Secrets Service to oo7, disabling DNF vendor changes by default, and updating major stacks like LLVM 23, Ruby on Rails 8.1, and MySQL 9.7. During their weekly meeting, the committee discussed the upcoming Forgejo distgit migration, agreeing to wait for a published roadmap to ensure proper community feedback on permissions, push rules, and CI integrations before proceeding.

FESCo also addressed late-arriving changes impacting the mass rebuild schedule. While the GNU Toolchain Update was approved to proceed, the Shadow Stack enablement was postponed due to unresolved concerns about breaking third-party applications and Rust-based packages. Other common work topics this week included infrastructure housekeeping (such as updating election policies and issue templates) and routine package maintenance, including handling non-responsive maintainers and retiring inactive software projects.

Decisions

• Approved the GNU Toolchain Update Change proposal.
• Approved the Grub EFI For Confidential Computing Change proposal.
• Approved the Lazarus with multiple widgetsets Change proposal.
• Approved the LLVM 23 Change proposal.
• Approved a one-off incompatible update request for rust-routinator.
• Approved adding new co-maintainers to the ledger package following the non-responsive maintainer process.

Learn more about the FESCo team.

Workstation / GNOME

In a brief follow-up to the Fedora Workstation Working Group meeting minutes, it was confirmed that the group will be taking a short break from their regular meeting schedule. Due to members traveling to the GUADEC conference and other scheduling conflicts, all meetings for the remainder of July have been called off.

Decisions

• All Fedora Workstation Working Group meetings for July are canceled. The next meeting is scheduled to take place on August 4, 2026.

Learn more about the Workstation / GNOME team.

Server

The Server Working Group held a weekly meeting (with the agenda and summary posted to the mailing list) focusing on release testing, documentation, and the Fedora home server spin-off. To make F45 release testing more accessible for contributors, the team introduced a new project board and ticket system, which will eventually be automated. For the home server spin-off, a contributor volunteered to set up and document a local Kiwi development environment so others can easily join the effort. The group also discussed updating the contributor's guide to remove outdated Pagure links and welcomed upcoming documentation contributions regarding mDNS and Ansible usage on Fedora.

Decisions

• The working group agreed to begin F45 release testing using the newly created ticket system, adapting the tickets as necessary throughout the testing process.
• A server-specific documentation style guide will be drafted to track styling and phrasing decisions that deviate from or add to the main Fedora Docs Style Guide.

Learn more about the Server team.

Infrastructure

The Fedora Infrastructure team kicked off the F45 mass rebuild on July 15th, ensuring autosigning was enabled for the f45-rebuild tag. A significant portion of the week's effort was dedicated to migrating various infrastructure hosts and virthosts to RHEL10, which involved careful timing to minimize builder outages. On the mailing list, the team discussed the effectiveness of the Anubis anti-scraper system. Contributors concluded that Anubis remains absolutely critical for preventing infrastructure outages and managing CPU load, even if some modern AI agents can bypass its proof-of-work challenges.

Operational troubleshooting addressed several immediate issues, including a stalled Bodhi consumer pod that halted Rawhide and ELN updates, PR merge failures on node-exporter, and misrouted EPEL mirrors. The team is also actively improving monitoring by adjusting Zabbix checks and advancing the Forgejo deployment with new metrics templates and foundational work on private issues. Contributors looking to engage can assist with AWS IAM role configurations for projects like Testing Farm and Logdetective, or help refine Apache LoadBalancer timeouts to handle external proxy delays more gracefully.

Decisions

• Anubis will be retained across the infrastructure as a critical defense against web scrapers and bots.
• Autosigning was officially enabled for the f45-rebuild tag to support the ongoing mass rebuild.

Learn more about the Infrastructure team.

Release Engineering

The Fedora 45 Mass Rebuild was a central focus this week, with the tracker ticket coordinating readiness across toolchain updates and a meeting discussion clarifying the standard operating procedure for verifying driving changes before commencing. To improve future rebuilds, contributors are exploring ways to update the mass rebuild scripts so they automatically check Bodhi and skip packages that recently failed gating. In community tooling news, an experimental AI Agent was introduced to autonomously analyze Rawhide nightly compose logs and identify root causes of failures, offering a new way for contributors to help triage issues. Meanwhile, the migration to Forgejo continues, with the kiwi-description repository successfully moved and plans forming to replace Pagure AMQP messages with Forgejo webhooks.

Routine release engineering tasks included resolving git repository unpacker errors, setting up Koji tags for ELN image-builder, and processing side tags for the Perl 5.44 update.

Decisions

• The Robotics Spin has been officially dropped from Fedora Linux 45 and removed from the build configuration.
• The web-based git blame feature in Fedora Package Sources has been deliberately disabled to mitigate massive abuse from AI web crawlers; contributors must now clone repositories and use git blame locally.
• The .composeinfo format was updated to include a release_type field, enabling downstream Beaker automation to distinguish between Beta and Final releases.

Learn more about the Release Engineering team.

Quality

The most significant development this week is the launch of on-demand openQA testing for dist-git pull requests. Contributors can now trigger automated tests by simply commenting /openqa test on a PR, with success or failure states reporting directly back to the interface. In other tooling updates, a compose critical package generation script was merged (with Bodhi integration ongoing), openQA test coverage was extended for KDE and Workstation applications, and UI/UX improvements were applied to the testdays-web platform to clarify when events are ready for result submissions. The "Heroes of Fedora Quality Q2" report was also published to celebrate community contributions.

For ongoing contributor engagement, the QA team is calling for community validation on several new nightly composes. Testers with available time are encouraged to review and submit results for Fedora 45 Rawhide 20260718.n.0, Fedora 45 Rawhide 20260715.n.0, and Fedora-IoT 45 RC 20260713.0.

Learn more about the Quality team.

Design

The Design team is actively preparing for upcoming releases and events, including initial planning for the Fedora 46 wallpaper with community polls focusing on "U"-themed inspirational figures. Emma Kidney published a blog post detailing the new collaborative design workflow used for Flock 2026 branding. In other project updates, the team finalized the LoLa AI Package Manager mascot, resolved data issues to generate Flock 2026 YouTube thumbnails, and is working on migrating the fedora-logos repository from Pagure to the Design team's Forgejo space to streamline package updates.

For contributors looking to get involved, there are ongoing efforts to create a Contributor Onboarding Video Series, where the team is currently crowdsourcing opinions on background music. There are also open opportunities to design avatars for Fedora's Matrix bots, including Zodbot, Meetbot, Nonbot, and the new Moderation bot. Furthermore, the team is heavily refining a community onboarding poster to ensure it serves as excellent "rookie reading material" while remaining visually cohesive, accessible, and cost-effective for community members to print.

Decisions

• Community Poster Redesign: During the July 13th meeting, the team decided to remove solid color banners from the community onboarding poster layout. This decision prioritizes core alignment and spacing, improves visual cohesion, and significantly reduces ink consumption for community members printing the materials at their own expense.

Learn more about the Design team.

Docs

The Fedora Docs team is finalizing its migration away from Pagure.io ahead of the platform's July 31 shutdown, urging maintainers to move remaining repositories to Forgejo (Issue #35). Infrastructure and workflow improvements are a major focus this week, with ongoing work to refactor the local docsbuilder.sh preview script to use updated, secure containers (Issue #19) and efforts to implement automated Forgejo Actions CI monitoring to catch silent production site build failures (Issue #53). Additionally, the team is exploring a massive UI/UX overhaul to better support knowledgebase-style content in the Antora theme, and community brainstorming is highly encouraged even for those not ready to write code (Issue #51).

To decentralize documentation maintenance, the team is launching the "Fedora Docs Captain" pilot program (Issue #50). This initiative pairs subject-matter experts with experienced technical writers to revamp documentation for the Kernel, Multimedia, and AI/ML SIGs. Volunteers are actively needed to serve as sponsors or team leads for these pods. In a related effort, a community initiative is underway to consolidate scattered multimedia, hardware driver, and third-party codec documentation into a single authoritative source to improve the new user experience (Issue #58).

Decisions

• Repository settings across all docs/* repositories will soon be updated to enforce new contribution guidelines, requiring contributors to submit pull requests via forks rather than pushing directly to repository branches (Issue #46).
• The "Fedora Docs Captain" pilot program will be timeboxed and evaluated at the Fedora 45 release to determine whether to scale the initiative to other Special Interest Groups or conclude the experiment (Issue #50).

Learn more about the Docs team.

EPEL

This week, the EPEL team focused on package updates, security retirements, and early planning for EPEL 11. Notably, syncthing has been retired from EPEL 8 and 9 due to unfixable security vulnerabilities and SQLite incompatibilities; users are advised to upgrade to RHEL 10 to continue using it. Concurrently, updates for syncthing v2 were pushed to stable for EPEL 10.2 and 10.3. During the weekly meeting, the steering committee also approved incompatible updates for rust-routinator and ffmpeg, with the ffmpeg update planned to land in epel9-next first to allow maintainers time for necessary adjustments.

Looking ahead, early planning discussions for EPEL 11 have begun. A key topic of discussion is addressing feedback from enterprise users who mirror repositories directly by URL (such as with Satellite or Foreman) and were disrupted by recent changes to metalinks and baseurls. A proposal is currently being drafted to remediate this URL structure in EPEL 11-and potentially implement it smoothly in EPEL 10 as well-to ensure a more predictable experience for users.

Decisions

• Approved the incompatible update request for rust-routinator (Issue #369).
• Approved the incompatible update for ffmpeg 5 to 7, which will be introduced in epel9-next first (Issue #370).

Learn more about the EPEL team.

ELN

In the ELN meeting, the primary discussion focused on the delayed enablement of bootc images for Fedora ELN. Progress has been slow due to review bottlenecks on the Konflux side, prompting suggestions to move all ELN container builds into Konflux. By standardizing the pipeline and removing bootc as a special case, the group hopes to resolve structural build issues and improve the overall RHEL-on-Konflux experience.

The team also clarified the roadmap for future bootc images, noting that the Fedora ELN bootc image (to be hosted at quay.io/fedora/eln-bootc) will serve as a precursor to upcoming CentOS Stream 11 builds. Because CentOS Stream 11 is still in early bootstrap, contributors agreed to schedule a dedicated conference call to coordinate the integration of Konflux, pungi, and bootc configurations across both the Fedora and CentOS Stream ecosystems.

Learn more about the ELN team.

Atomic

During the Fedora Atomic Initiative meeting, progress was shared regarding Enterprise Linux Next (ELN) base images. Contributors are currently waiting on reviews for Konflux tenant configuration merge requests that will switch the setup from minimal-plus to standard, which is required to complete the ELN base image builds. Once merged, the team will need to determine the process for pushing the resulting base image to the correct namespace, presenting an area where contributors familiar with Konflux might be able to assist.

In broader news relevant to the Linux community and bootc users, an initiative is underway to split Ignition into a standalone RPM, allowing it to be included in more workflows such as bootc container image builds. Additionally, a Fedora 45 change proposal was highlighted that aims to provide native Butane configuration support directly in Ignition. If implemented, this will eliminate the need for the intermediate Butane-to-Ignition conversion step, allowing users to use Butane directly for their instances.

Learn more about the Atomic team.

CoreOS

During the CoreOS meeting, the team reviewed the Fedora 45 Release Schedule and warned that the ongoing Mass Rebuild may cause temporary turbulence and CI breakages in the rawhide stream. The change proposal to enable systemd-oomd and swap on Zram by default was finalized and moved forward in the release process. In other community news, contributors are seeking reviews on an Afterburn pull request designed to make logic less Azure-specific, and members discussed strategies for better surfacing bugs caught in the next stream before they reach stable releases.

A significant portion of the meeting focused on the ongoing need to increase the /boot partition size for new installs, an issue recently highlighted by failing tests on aarch64 rawhide. Acknowledging the complexity of this migration, several contributors volunteered to form a dedicated working group to address it, offering an excellent engagement opportunity for those interested in helping architect a solution for core system storage limits.

Decisions

• The team approved the systemd-oomd and swap on Zram change proposal and officially marked it ready for the Fedora Change Wrangler.
• A dedicated working group was formed to tackle the /boot partition size limits, with an initial action item to draft a comprehensive list of requirements for the migration effort.

Learn more about the CoreOS team.

Kernel

This week, a user reported an issue with the Rawhide nodebug kernels setup process. The repository configuration file required to set up the repo on new systems is currently missing from the server, causing the standard wiki instructions to fail.

While the .repo file is missing, the actual repositories are still present and intact on the server. This presents a quick engagement opportunity for infrastructure or kernel contributors to restore the missing file and fix the setup process for the broader community relying on these nodebug kernels.

Learn more about the Kernel team.

AI & ML

The AI & ML SIG is making strides in integrating AI into Fedora workflows, highlighted by a new proof-of-concept AI agent analyzing Rawhide nightly composes to identify failure root causes. To support these efforts, the SIG is formalizing an AI skills library and has established a new "Skills Reviewers" sub-team to curate shared, agent-neutral AI skills. On the hardware front, the SIG is addressing the growing interest in shared GPU infrastructure by initiating a draft for an Acceptable Use Policy to define trust models and access controls for Fedora's GPU hardware.

There are several immediate opportunities for contributors to get involved. The SIG is actively seeking maintainers for new llama.cpp backends (with a priority on Vulkan) and testers for the newly introduced pi-coding-agent in Rawhide, particularly on non-x86 architectures like aarch64. Additionally, developers interested in LLMs are encouraged to help expand the AI Skills Library or integrate other local LLMs into the existing coding agents.

Decisions

• Skills Reviewers Team: The SIG officially approved the creation of a skills-reviewers sub-team on Forgejo. Seeded with six initial members, the team will manage the ai-ml/skills-library repository and implement a lightweight review process requiring at least one approval before merging new Agent Skills. (Ticket #31)
• GPU Infrastructure Access: It was agreed that existing GPU infrastructure (gpu01) will be strictly earmarked for CI purposes during the F45 release cycle. General access requests will be temporarily closed as wontfix while the hardware remains in a "transitionary/exploration" phase and the formal Acceptable Use Policy is drafted. (Ticket #34)

Learn more about the AI & ML team.

RISC-V

The Fedora 45 rebuild for RISC-V is currently about 25% complete, and the team continues to make steady progress resolving remaining issues on the Fedora RISC-V tracker. Hardware capacity has expanded, with four RVA23 units-including community-contributed hardware-now active in the Fedora RISC-V Koji. Furthermore, technical discussions are actively underway with hardware vendor SpacemiT's Linux team to improve virtualization support and resolve known issues.

For those looking to get involved with the group, requirements for a potential RISC-V intern have been drafted and published, offering a new engagement opportunity for prospective contributors.

Decisions

• The team decided to optimize the F45 rebuild by importing approximately 50% of "noarch" packages directly from the primary Koji into the RISC-V Koji, which will save significant time and compute resources.

Learn more about the RISC-V team.

Security

The Security SIG held a meeting this week primarily focusing on secure development practices and how end-users can verify Fedora's security posture. The group highlighted existing safeguards like the package review process and mandatory hardening compiler flags, while also discussing the integration of automated vulnerability management tools. Notably, the conversation covered the new ProdSec scanner (Trustshell) and Hummingbird, a tool that uses AI to scan for CVEs and automatically generate pull requests for Rawhide packages. The team also explored the potential of mapping Fedora's practices against the OpenSSF baseline checklist.

Contributors looking to get involved can review the meeting agenda and logs on the forum. Several topics were deferred due to time constraints, providing an excellent opportunity for asynchronous engagement on the SIG's issue tracker, particularly regarding the Cyber Resilience Act (CRA) requirements and Linux-distros mailing list policies.

Decisions

• The discussion on aligning Fedora's security documents with the "Vulnerability and Incident Policy" CRA requirement (Ticket #14) was postponed to next week's meeting.
• The Linux-distros discussion (Ticket #13) was deferred to be handled asynchronously on the issue tracker.

Learn more about the Security team.

Gaming

David Campbell announced the release of Hnefatafl Copenhagen 6.1.1, a strategic board game with historical roots similar to Chess or Go. Linux gamers interested in trying it out can install the game by enabling the dcampbell24/hnefatafl-copenhagen Copr repository. Once installed, it can be launched directly from the application menu or by running hnefatafl-client in the terminal.

Learn more about the Gaming team.

Go

In a recent discussion, Tadej Janež sought advice on packaging docker-credential-helpers for Fedora. Because the upstream project includes macOS and Windows-specific helpers (osxkeychain and wincred), the conversation focused on excluding these unnecessary modules and their dependencies from the vendor tarball using go2rpm. Mikel Olasagasti provided a solution to remove the directories prior to archiving, which successfully cleared out the unneeded dependencies.

This process resulted in an essentially empty vendor archive, prompting Tadej to ask follow-up questions about handling SPEC file macros that operate on empty vendor sources and resolving an rpmlint error caused by a zero-length modules.txt file. Contributors with Go packaging experience are encouraged to join the thread to help resolve these final packaging hurdles.

Decisions

• The package will use pre_commands and exclude_directories in the go-vendor-tools.toml configuration to explicitly remove the OS X and Windows credential helpers (osxkeychain/ and wincred/) from the vendor archive and licensing checks.

Learn more about the Go team.

Perl

This week, the Perl group focused heavily on routine package maintenance and version updates. Michal Josef Špaček successfully merged multiple version bumps, updating perl-Test-Inter to 1.13 across PR #9, PR #10, and PR #11, as well as updating perl-HTTP-Date to 6.08 in PR #5, PR #6, and PR #7. In broader Linux community news, Michal Schorm submitted a patch to fix a Failure to Build From Source (FTBFS) in perl-SDL caused by underlying code behavior changes, which was subsequently merged by Hans de Goede. Additionally, contributors looking to engage with RHEL compatibility can review Yaakov Selkowitz's newly opened pull request for perl-HTTP-Daemon to build the package using Module::Build on RHEL.

Decisions

The group approved and merged the FTBFS fix for perl-SDL. They also officially accepted the version bumps for perl-Test-Inter (1.13) and perl-HTTP-Date (6.08) across their respective repository branches.

Learn more about the Perl team.

Other Discussions

• Hummingbird Community Meeting - 23 July 2026: Laura Santamaria announced the next Hummingbird community meeting and gathered agenda items, including a demo of Project Bluefin's factory, Red Hat Hardened Images, and agentic frameworks like Hive.
• If you're on the kernel mailing list (LKML), aren't you concerned about AI?: A user raised concerns about the surge of AI-generated code in the Linux kernel and the potential for plagiarism or training data injections, prompting a reference to Linus Torvalds' stance on the matter.
• Fedora AI/ML SIG Meeting (2026-07-16): The AI/ML SIG discussed recruiting maintainers for the llama.cpp backend, testing pi-coding-agent, establishing a Skills Reviewers sub-team, and navigating the governance of GPU hardware access for CI purposes.
• F45 Change Proposal: Enable Shadow Stack by Default on x86_64 (system-wide): A proposal to enable hardware-enforced Shadow Stack protection by default for C, C++, and Rust applications on supported x86_64 machines in Fedora 45 sparked discussions about backward compatibility, hardware support, and implementation details.
• F45 Change Proposal: Disable Vendor Change by Default (system-wide): A proposal aims to configure DNF5 to prevent automatic package vendor changes during transactions by default, ensuring system stability while allowing explicit vendor transitions via configuration rules or command-line flags.
• Looking for zig co-maintainer for Fedora and EPEL: The maintainer of the Zig package requested help, especially during release cycles and for EPEL, and received an offer of assistance for ARM64 bootstrapping and fixes.
• Help needed with matrix-synapse: A maintainer asked for help building the latest version of matrix-synapse on Fedora 44 and older, noting that an ongoing package review is currently blocking progress.
• F45 Change Proposal: LibreOffice html help (self-contained): A proposal to switch LibreOffice's embedded help system to HTML files distributed as noarch packages aims to save repository space, prompting brief discussions on how to handle systems without a web browser installed.
• Non-responsive packager check for @sham1: A non-responsive maintainer process was initiated for the ledger package, but the maintainer quickly replied, apologizing for their absence and promising to catch up on their packages.
• Non-responsive maintainer: crosa: A user initiated the non-responsive maintainer process for Cleber Rosa regarding Avocado-VT related packages, which are currently blocking Python 3.14 compatibility in Fedora 43.
• Other discussions included a list of long term FTBFS packages to be retired, an RFC on Prometheus exporters naming and configuration, an F45 proposal for LibreOffice Dictionaries, a strategy for i686 removal of leaf packages, a request to unretire sugar packages, and the announcement of on-demand openQA testing of dist-git PRs.

Orphaning packages

• Orphaning xset and xrdb: Peter Hutterer announced the orphaning of the xset and xrdb packages, inviting anyone who still has a use for them to take over maintenance.

Package updates

• Orphaned package wavemon updated to 0.9.7: A user provided an updated COPR build for the orphaned wavemon package (version 0.9.7) for Fedora 44, offering occasional future builds without committing to long-term maintenance.
• z3 soname bump: Jerry James announced an upcoming soname bump for z3 version 5.0, which will require rebuilding opam and prusa-slicer.
• Node.js rolling stream: upgrade path for current nodejs22: A discussion was started regarding the upgrade path for users currently on the nodejs22 stream in F44/Rawhide as the project transitions to a metapackage approach.
• Flint soname bump: Jerry James announced an update to flint version 3.6.0, which includes a soname bump requiring rebuilds for several dependent packages like Singular and polymake.
• libupnp soname bump: Gwyn Ciesla announced an upcoming upgrade for libupnp to 22.0.3 in Rawhide, confirming that dependent rebuilds will be handled.

New contributor introductions

• Mohab Soliman, a mechatronics engineer from Egypt with experience in 3D printers and FreeCAD, introduced themselves to the 3D printing SIG and asked for guidance on contributing.
• Jesus De Los Reyes Larraga, a QA/platform engineer, introduced themselves, offering their expertise in infrastructure, automated testing, and various programming languages to contribute to the ecosystem.
• Philip Czarnik, a software developer from Germany with experience in Angular, Java, Python, and C/C++, introduced themselves and expressed interest in volunteering 2-4 hours to start contributing.

18 Jul 2026 7:11am GMT

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.

RPMs of PHP version 8.5.9RC1 are available

• as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

RPMs of PHP version 8.4.24RC1 are available

• as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

• PHP 8.5.9RC1 available for testing
• PHP 8.4.24RC1 available for testing

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

dnf module switch-to php:remi-8.5
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

ℹ️ Notice:

• version 8.5.9RC1 is in Fedora rawhide for QA
• EL-10 packages are built using RHEL-10.2 and EPEL-10.2
• EL-9 packages are built using RHEL-9.8 and EPEL-9
• EL-8 packages are built using RHEL-8.10 and EPEL-8
• oci8 extension uses the RPM of the Oracle Instant Client version 23.26 on x86_64 and aarch64
• intl extension uses libicu 74.2
• RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
• versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

17 Jul 2026 4:07am GMT

17 Jul 2026 12:00am GMT

Hello travelers!

Loadouts for Genshin Impact v0.1.18 is OUT NOW with the addition of support for recently released characters like Sandrone and for recently released weapons like A Teaspoon of Transcendence from Genshin Impact Luna VIII or v6.7 Phase 2. Take this FREE and OPEN SOURCE application for a spin using the links below to manage the custom equipment of artifacts and weapons for the playable characters.

Resources

• Loadouts for Genshin Impact - GitHub
• Loadouts for Genshin Impact - PyPI
• Loadouts for Genshin Impact v0.1.18
  • Executable for GNU/Linux distributions
  • Executable for Microsoft Windows

Installation

Besides its availability as a repository package on PyPI and as an archived binary on PyInstaller, Loadouts for Genshin Impact is now available as an installable package on Fedora Linux. Travelers using Fedora Linux 42 and above can install the package on their operating system by executing the following command.

$ sudo dnf install gi-loadouts --assumeyes --setopt=install_weak_deps=False

Changelog

• Complete the 4-piece bonus for Disenchantment in Deep Shadow by @qorexdevs in #575
• Revisit the title case class names for weapons by @gridhead in #570
• Added Sandrone to Loadout by @Ank-22 in #578
• Added A Teaspoon of Transcendence by @Ank-22 in #579
• Review A Teaspoon Of Transcendence inclusion by @gridhead in #582
• Create separate GitHub Action for generating point releases by @gridhead in #571
• Automated dependency updates for GI Loadouts by @renovate[bot] in #566
• Disable caching while building executable binaries by @gridhead in #584
• Update actions/download-artifact action to v8 by @renovate[bot] in #583
• Stage the release v0.1.18 for Genshin Impact Luna VIII (v6.7 Phase 2) by @gridhead in #585

Characters

One character has debuted in this version release.

Sandrone

Sandrone is a claymore-wielding Cryo character of five-star quality.

Weapons

One weapon has debuted in this version release.

A Teaspoon of Transcendence

White Fairy's Queening - Scales on Crit DMG.

Appeal

While allowing you to experiment with various builds and share them for later, Loadouts for Genshin Impact lets you take calculated risks by showing you the potential of your characters with certain artifacts and weapons equipped that you might not even own. Loadouts for Genshin Impact has been and always will be a free and open source software project, and we are committed to delivering a quality experience with every release we make.

Disclaimer

With an extensive suite of over 1584 diverse functionality tests and impeccable 100% source code coverage, we proudly invite auditors and analysts from MiHoYo and other organizations to review our free and open source codebase. This thorough transparency underscores our unwavering commitment to maintaining the fairness and integrity of the game.

The users of this ecosystem application can have complete confidence that their accounts are safe from warnings, suspensions or terminations when using this project. The ecosystem application ensures complete compliance with the terms of services and the regulations regarding third-party software established by MiHoYo for Genshin Impact.

All rights to Genshin Impact assets used in this project are reserved by miHoYo Ltd. and Cognosphere Pte., Ltd. Other properties belong to their respective owners.

15 Jul 2026 6:30pm GMT

We talk a lot in open source about reputation. Individuals have a reputation. Projects have a reputation. This reputation is how we build trust with strangers from around the world. People and projects have an incentive to behave well so as to not ruin their reputation. Or do they?

Glyph

glyph@mastodon.social

@miss_rodent yeah, that's kinda what I mean. The whole industry behaves as if you have a strong incentive to behave in a particular way because we have some strongly-tracked pervasive notion of reputation. but we barely have any notion of reputation *at all* let alone a structured and carefully enforced one. if this breaks the floodgates on activism-via-RCE, that broken trust is going to take a long time to repair

2026-05-30, 3:18 am 0 boosts 8 favorites

Glyph is right. We put too much on the concept of reputation without stopping to think about what it actually means.

One way that I've seen this come up a lot is in conversations about blocking AI agents - or humans who are just a translation layer between an AI model and a project. Folks have come up with a variety of different ways to determine who is a real, trustworthy person that should be allowed to make a contribution to the project. Some, like Mitchell Hashimoto's vouch, use an explicit maintainer vouching model. Others use heuristics that look at account activity to make a guess. Both of these models can make it harder for newcomers to make those early contributions that build their reputation.

Discourse's trust levels are a pretty good model for a trust ladder in a community. The problem is that once you go to a different Discourse site, you're brand new again. Similarly, someone who has been banned from a community for repeated misbehavior can join a new community with no trouble.

In chapter three of Program Management for Open Source Projects, I talk about trust being a combination of person and role. You might trust me when I write about leading open source communities but not when I write critical software. By the same token, I'm relatively well-known in places like Fedora and the OpenSSF. But at an Erlang conference, nobody has heard of me.

If you've gone to a conference, you've probably had an experience along these lines: you chat with a friend-of-a-friend in the hallway for a few minutes, think "they seem nice", and then later you learn they invented your favorite compression algorithm. Even the biggest of the Big Names are a nobody to a lot of people.

So reputations? Not that useful. If you can build a good one, that's nice, but you can't count on it.

The problem with reputation is that it doesn't answer the question you want to answer (unless that question is "who is well-known?"). Start by figuring out what question you want answered. Then you can find the best way to answer it. And don't rely on "but you'll ruin your reputation" to prevent bad behavior.

This post's featured photo by David Clode on Unsplash.

The post The importance - or not - of reputation appeared first on Duck Alignment Academy.

15 Jul 2026 12:00pm GMT

I got behind a little in my reading and a lot in my posting because of the onrush of the end of school, the beginning of summer and holiday season, and needing to give two talks. This catch-up post is a bit longer than most, but that's partly because it represents some binge reading I did while on the beach on vacation. I accidentally gave myself a digital detox because I took my Kindle loaded with 300 unread items from Instapaper and a bunch of books and wound up using it way more than I used my phone. The winnowed down results are here and I hope you enjoy them.

Disclaimer: I work at Microsoft on upstream Linux in Azure. These are my personal notes and opinions.

AI & the future of software work

• The bottleneck has moved: redesigning the SDLC for AI

  I've always been bothered by the admonishment that you must "read every line of code" generated by an LLM. This article argues that LLMs are useful only if they boost the throughput of the whole system. That boost comes from the same place it always has: features of acceptable quality that move the codebase further toward its goals.

  Since humans aren't going to read every line of code, and never have, what do you do instead? You formalize the gating humans have traditionally used.

  Risk-based change classification is one example. Not all work requires the same level of scrutiny. Some changes are routine, well-understood, and low risk. Others carry architectural, security, or product risk that demands deeper review. Classifying work by risk profile allows scarce human judgment to be applied where it matters most, instead of spread thinly across everything.

  I found this opening comment about Agile insightful because it made me think about what its rituals should do, rather than what we built an industry to do.

  Agile wasn't primarily about being nimble or responding to change. That's the story we told about it. Agile was the industry's answer, mostly unconscious, to a single problem: how to manage a scarce, expensive development bottleneck.

• Let's talk about LLMs

  Writing code not being the hardest or most critical part of building software isn't controversial, except among those for whom writing code is pleasurable. I believe most people want to focus on the harder parts, not grinding out code. One goal of LLM coding tools is to allow anyone, experienced or not, to produce code that achieves their goal.

  It seems to be widely agreed among advocates of LLM coding that it's a skill which requires significant understanding, practice, and experience before one is able to produce consistent useful results … strong prior knowledge of how to design and build good software is also generally recommended or assumed.

  I believe I can do this, but I've been a developer. The real question is whether someone can learn to do this without ever having been a developer. More and more, I believe the answer is yes, we just haven't looked at the problem long enough in isolation. Accounting, piloting, and other professions have seen core elements of their work automated away and retooled their education systems to account for this. I believe software development can too.

• "maybe later" was a feature - arnorhs.dev

  This article provides the corollary risk. Our backlogs are filled with work that would require enough effort that we should seriously question the value of doing it. Unchecked LLM use as a way to grind through it is as bad as anything else done unchecked.

  The rule of product management is to keep builders so busy they don't have time to invent things to deliver. If LLMs accelerate development, product has to accelerate too. A company has to organize to use its people wisely, otherwise garbage from the backlog gets built.

Forking

• Open source was not ready for AI-speed contributions

• Reviving an Abandoned Open-Source Project: 6 Years of Atomic Calendar Revive

• Respectful Open Source

  Together, these three articles poked at a thought that has been in my mind for a while. We need more forks. Not the "soft fork" or "friendly fork" variety, but also not "hard forks," which, to me at least, carry a connotation of anger or social breakdown. We need forks where someone carries the patch they wrote or generated. We need forks where others can review the patches "on offer" and discuss or debate them. We need well-maintained forks that keep up with their upstream. That is inherently required if you care about your patch and the project, and it lets long-term maintenance and use signal to other forks and the upstream that your patches may be worth carrying. All of this will require an infrastructure that can surface forks usefully, something GitHub and their clones haven't figured out yet.

  A common complaint is that we are drowning in PRs with no more review capacity. Carrying your own patch in your own fork moves us toward that.

  A fork isn't "I fixed it for me." It's "I'm now responsible for fixing it for everyone." That's a much bigger sentence than it looks. - "Reviving an Abandoned Open-Source Project: 6 Years of Atomic Calendar Revive"

  The last article really drives this home: a patch not submitted may be the best solution for some things.

Open Source Sustainability

• The Quiet Renovation at Bitwarden - ByteHaven - Where I ramble about bytes

  Apparently "always free" is back at Bitwarden. But this author isn't happy about that. They've already "moved on" to a free clone. This attitude is what really bothers me.

  The "all for me, none for thee" mentality: "I am shocked that the company that creates the thing I refuse to pay for hasn't found a market to sustain itself from other people who, because they aren't me, should pay. Now it is forced to figure out a profit strategy that includes cutting costs for users like me. Instead of becoming a supporter of the thing I need, want, and claim to care about, I'll begin using an open source project that spends most of its time either repackaging the company's code or blindly reimplementing its features with little to no innovation. That'll show them!"

  It's like the argument about LLM resource usage. In aggregate, it is huge, and because that is bad, we should save some of our torches and pitchforks for use on the users, even though at a personal level it is very little. Here we see the opposite: people think code development and web hosting should be free because one free-rider user costs little, even though those costs are real in aggregate.

• Why Gentoo?

  In discussing Gentoo, the use of tools like GitHub and Codeberg is touched on:

  Sure, abandoning them would be inconvenient for us, but we can do that if need arises.

  Many make these kinds of statements and then get angry when Big Corp (tm) uses a project and doesn't contribute back. Hint: this is the exact same thought that your favorite noncontributor is having. Changing projects will be an inconvenience, but it is a calculable risk. It is the difference between "Mr./Mrs. Right" and "Mr./Mrs. Right Now."

  As a bonus, I love that they mention OpenPGP being used for the one thing it is actually good at. Shout out to The PGP problem.

Growing older and longevity

As someone rapidly becoming a man of a "certain age," and who has begun attracting the non-terminal health problems associated with that age, this roundup of articles stuck with me.

Even if you are not yet of a certain age, you should read this stuff. The challenges are coming for you too.

• Even a Little Alcohol Can Harm Your Health

  The idea that a low dose of alcohol was heart healthy likely arose from the fact that people who drink small amounts tend to have other healthy habits, such as exercising, eating plenty of fruits and vegetables and not smoking. In observational studies, the heart benefits of those behaviors might have been erroneously attributed to alcohol, Dr. Piano said.

• Are You Aging Well? Try These Simple Tests to Find Out.

  As the old saw goes, "that which is measured is managed." These tests will help you know where you are so you can decide what to do. The goal isn't to ace the test, it is to live healthier.

Social connection & talking to strangers

• The Dialogue Dividend

  Intentionally scheduling no-agenda calls with friends you can "water cooler" talk with is critical for your mental health. Professionally, it can be a bit self-reinforcing if you don't grow your network. Therefore, you should talk to strangers, as the next articles suggest.

• The stranger secret: how to talk to anyone - and why you should

  study by the University of Virginia (Talking with strangers is surprisingly informative) … "People tend to underestimate how much they'll enjoy the conversation, feel connected to their conversation partner and be liked by their conversation partner."

  You are just saying, "It's cold today, isn't it?" You are not asking someone to join you on a quest for world peace.

• Why saying hello to strangers can be good for you

  reported on studies showing that simply chatting with strangers has a lasting impact: It can make participants happy.

• The World: Aging well as an introvert

  Considering all the research around socializing and longevity, some introverts can be forgiven for feeling worried.

  I've never felt like I've had a lot of friends. This article focused on the kinds of people you know and should have in your network, even if you're someone who doesn't want or need a lot of people around. The categories really resonated with me.

  Note: This link is to a Newsletter I receive and I've been unable to find a link to it as a published article.

Economics

• Why Japanese companies do so many different things

  With the rise of LLMs, companies spend all of their time talking about how they can cut staff. In contrast, here are Japanese firms awash in labor, diversifying and growing.

• AI Agents Have Already Chosen Their Money: Bitcoin

  The Bitcoin Policy Institute found that AI agents choose Bitcoin, which is shocking(!) The prompts profess a need to be neutral about policy and then describe situations where Bitcoin is theoretically best. It is a first-class example of results seeking.

Evil is done by failures

• Hitler Was Incompetent and Lazy-and His Government an Absolute Clown Show

  There are no evil geniuses. There are charismatic fuck ups who find minions to do the dirty work (see the next article). Just because you can't find the intelligence behind the boot on your neck doesn't mean you should stop worrying about removing it.

• Actually, Democracy Dies in H.R.

  Over 20 years ago, I remember having a conversation with a friend. We were both unhappy at work and he was debating changing professions entirely. He said he was seriously thinking about joining the US Border Patrol. When I questioned this, he explained that it was known as a fast path to better government jobs and higher level positions in other agencies.

  Reading this article and looking back at 20 years of US border and immigration policy, I believe I now understand this on a whole new level.

Recently Finished Books

I've been tracking my book reading on my blog, but those notes never get surfaced anywhere. I've decided to start including links here. Head to my reading page to find detailed notes or reactions for each book, similar in style to this post.

And finally

• I Sold Out for $20 a Month and All I Got Was This Perfectly Generated Terraform

  This one has some real banger quotes, but also hits on the core issue of code as craftsmanship. In a departure from the norm, I'll let quotes drive this.

  Who was going to hire this band of Eastern European programmers who chain smoke during calls and whose motto is basically "we never miss a deadline". As it turns out, a lot of people.

  How pleasant and well-organized that code is to work with is not really a thing that matters in the long term.

  It's $7000 a year for the servers, with two behind a load balancer. That's absolutely nothing when compared with the costs of what having a team of engineers tune it would cost

  Visual imagery aside, when you buy for a deadline, you are not buying for beauty. Keep that in mind.

  I delight in craftsmanship when I encounter it in almost any discipline. I love it when you walk into an old house and see all the hand crafted details everywhere that don't make economic sense but still look beautiful. I adore when someone has carefully selected the perfect font to match something.

  "well great doesn't matter at all" effectively boils down to "don't take pride in your work" which is probably the better economic argument but feels super bad to me. In a world full of cheap crap, it feels bad to make more of it and then stick my name on it.

  So now I'm paying $20 a month to a company that scraped the collective knowledge of humanity without asking so that I can avoid writing Kubernetes YAML.

  "You know what the difference is between you and me? I know I'm a mercenary. You thought you were an artist. We're both guys who type for money."

  The companies paying for the creation of open source aren't hiring craftspeople or artists. They aren't the Medicis handing out money to support the creation of great works of art. They are hiring bands of mercenaries. The key is that most of them have used the cult of open source and the identity of developers as craftspeople and artists to avoid having to pay for quality and instead get it for free. You got hired to mulch the flower beds. You trimmed the bushes, edged the lawn, and planted more flowers for free. Maybe you did it for "the users" which is great when they are real people who really exist. However, a lot of the code we work on for commercial open source companies is being consumed by other commercial entities, not humans. They didn't care about the flowers either.

15 Jul 2026 7:50am GMT

14 Jul 2026 5:54pm GMT

14 Jul 2026 5:54pm GMT

14 Jul 2026 12:41pm GMT