I’ve been a Debian user since 1999, and a Debian developer since 2000. Given recent events it’s worth thinking about why that that is, and why I haven’t switched to something else in the past quarter century.
My first Linux distro was Slackware, off a CD in a book, some time in the mid 90s. After starting university I ran SUSE for a while, then moved to RedHat (both back before they had commercial variants significantly different to what was available freely). The main motivation for switching was package management; I was running a machine at home and a machine at university, and keeping track of what was installed on each, and what versions, was getting annoying with Slackware. Most of the folk I knew were running RedHat, and I mostly played with SUSE because I’m contrary before realising it was different enough that I couldn’t easily make use of 3rd party RPMs.
I came to Debian via friends in Cambridge, who spoke highly of it. The first Debian machine I installed was fourier, the initial host for Black Cat Networks, and I never looked back.
(For additional context I should also point out I have contributed, in the distant past, to, and run, OpenWRT, OpenEmbedded, and FreeBSD.)
I’d like to try and work out what is it I get from Debian that I’d need in anything else. Originally I tried to order the requirements in some sort of priority, but it’s sometimes hard to work out what I’d drop if I had to compromise somewhere, so it’s a somewhat loose ordering.
Stable releases, with security support
I run Linux in lots of places, from remote servers/VMs, to my house router, to my desktop/laptop. Some of those I don’t want to be updating regularly with new software releases, I need something I can be sure is going to keep working, but will get necessary security + critical updates. A rolling distro that provides security via the latest upstream release doesn’t provide that guarantee. Equally there need to be regular stable releases, or things become too stale. (The one time I considered moving away from Debian was during the 3 year Sarge / 3.1 release cycle. I think if things hadn’t improved I’d have jumped ship to Ubuntu at the time.)
A good selection of packages
One of the reasons I moved from RedHat to Debian was the wide range of packages available as part of the standard OS. Pulling it all into the disto helps with quality control, compared to random 3rd party packages. A centralised bug system and repository is a win too. Perhaps packages at all is something I should list, but I take it as a given if you’re running a distro. I need to know what I have installed on my machine, what version that software is, what files it owns, and what it depends on.
Free Software
This is important to me. I’ll make pragmatic compromises about software I run on my systems if it makes sense, but I want to start from a place that does not require anything non-free. I’ve run a company on Debian, and I’ve worked on numerous products that ran it under the hood. The DFSG gives me confidence I can do that.
Smooth upgrades
Debian’s ability to upgrade a system smoothly is one of the reasons I first moved to it. The first upgrade I did was remotely on a machine sitting on a 2Mb/s leased line. I was nervous doing the reboot at the end, but it came back fine. At the time the equivalent procedure with RedHat involved rebooting in the OS installer to do the upgrade.
I know things have moved on since then, and really it should all be scripted, and machines should be cattle not pets, but for personal use I run a small enough number of machines that having the upgrade path between releases is a must have.
Community
The original pull of the Debian community was the knowledge I could get involved, and upload packages that were missing that I was using. That’s how I first got involved, uploading things Black Cat used, which made life easier for us in the long run. I don’t have time to maintain all the software I use myself, and I don’t want to be beholden to a commercial entity to do so for me, so a distribution that allows me to help out where I can as part of the community seems to me to be the right way to do things.
Architecture support
Perhaps less important, especially when I started using Debian, but these days I have amd64, arm64, armhf, and riscv machines. Everything except for the risvc box is doing something useful, and would need replaced if I couldn’t keep running it, and I expect RISC-V to transition into that state in the next few years as the hardware improves.
Binary packages
I ran a FreeBSD desktop for some time. It might have been the way I was holding it, but binary package installs were generally not something reliable, especially after the initial install, and I ended up building things from ports from source quite often. That worked incredibly well (I used to think people who raved about Gentoo really should just go do it properly and use FreeBSD), but I don’t want to spend time compiling things, especially on some of my machines (my router should not need a compiler, for example).
Ultimately I don’t want to have to actively think about the Linux distribution I use. Debian has mostly given me that; I know it will generally be suitable for most environments I want to use it in (embedded situations where OpenWRT or OpenEmbedded are better choices being the exception, but that’s less frequent these days), and I can rely on getting timely security updates (thanks to all those who work on that within Debian!). I’m not sure there’s currently an alternative that would suit my needs? I’d love to hear if there’s something I should look at, even if I’m not necessary making a move just yet!
this article had been almost completely written before the
weekend, and I decided I might as well focus on stuff I’m creating,
finish and publish this.
For many years, I’ve been sporadically dabbling in creating 3D models;
for reasons that are probably obvious to anybody who knows me I used
OpenSCAD and saved my projects in git, which made them at least
somewhat public.
However, SCAD sources in a git repository aren’t the most convenient way
to get a 3D model, and for a long time I never had a consistent way to
publish “binaries” for my models: some have been added to my old
website, some to my craft patterns site, but it was always an ad-hoc
thing.
Then two things happened more or less at the same time.
One was me finding out that slic3r had been definitely removed from
Debian. I know it was going to happen, and I postponed thinking about it
as long as I could, but eventually I had to move over to PrusaSlicer,
whose packaging is in better shape.
The other was that lately I’ve been doing a bit of lucet, and talking
about it online, and I’m really happy with the shape of the lucet I’ve
designed and printed, the one in the picture at the beginning of this
post, and while there are other models available, I wanted to make it
more convenient for people to also get mine.
Since PrusaSlicer did look still maintained upstream in a way that
doesn’t feel like at danger of immediate enshittification, I considered
making an account on Printables, and asked on the Fediverse if somebody
knew something bad about the company behind it, as it’s getting more an
more common these days.
Apparently nobody did, but in the thread somebody mentioned that there
is a federated platform for publishing 3D models, called manyfold !
I didn’t want to add “self host a(nother) web thing”, especially not one
that is not in Debian, to my list of projects, but I did create an
account on a public instance: @valhalla@3dprint.social
<https://3dprint.social/creators/valhalla> and started publishing
models, both a selection of old ones and a few new ones I designed in
the last few days, since I was in a 3D printing mindset.
Then I decided that since nobody had serious objections to it, I could
also create an account on printables, as that’s probably
more easily accessible to the general public.
I have been somewhat slower at publishing models on the latter, but I
expect that eventually most of what I design will end up on both
platforms; I still have a few older models I want to add, and a few
ideas for new models to make, then I guess stuff will slow down, and
only get new ones now and then, as that’s how I usually approach
hobbies.
Of course, the self-hosted git repository is not going away: that’s
still the canonical location for my models, with all of the
non-self-hosted options as a convenience option.
In Part 1: Taming the AI Agents, I shared the architectural blueprint of CAMP (Cross-Agent Memory Protocol)—how we used Linux Bubblewrap (bwrap), camp-acpd, OPA policy enforcement, and a central pgvector MemPalace to bring deterministic discipline, sandboxing, and long-term memory to a heterogeneous fleet of AI coding assistants (Claude Code, Google Antigravity, Grok Build, and GitHub Copilot).
At the end of that article, however, I highlighted a significant hurdle: The Headless Limitation.
“While passive A2A works beautifully for structured handoffs, the current frontier of agentic design faces a key limitation: agents are not yet fully headless-capable. They depend on the active terminal session, browser loop, or prompt loop of the user to keep executing. Because agents cannot run completely detached in the background as daemon processes, we cannot yet achieve active A2A communication…”
For weeks, this seemed like an insurmountable impasse. Proprietary AI vendors have zero commercial incentive to ratify a universal, open, cross-vendor Agent-to-Agent (A2A) communication protocol. Each vendor builds its own walled garden (Claude’s cross-session features, OpenAI’s custom ecosystems, etc.). If you wait for the industry to hand you an open interoperability standard, you will wait forever.
Then, on August 26, 2026, inspired by Colin Walters’ article on Agentic AI and software forges and GitHub Agentic Workflows (gh-aw), we had a sudden realization:
We don’t need a new protocol, a new distributed message broker, or permission from proprietary AI vendors. We already have the universal, decentralized communication bus that software engineers have relied on for decades: the software forge itself.
Over the span of 48 intensive hours (from RFC #788 through milestones M1 to M3 and live dogfooding on #813), we designed, implemented, fortified, and verified fully autonomous, headless, cross-vendor Agent-to-Agent swarms running over a local Gitea forge.
Here is how we did it, the architectural hurdles we solved, and why this changes the game for autonomous software engineering.
1. The Core Realization: The Forge is the Bus
When people think about multi-agent swarms, they often imagine complex distributed RPC frameworks, microservices exchanging ephemeral JSON-RPC blobs, or bespoke socket daemons.
In practice, this approach suffers from major flaws:
No shared context or durable audit trail: Transient network packets vanish unless heavily logged.
Proprietary CLI fragmentation: Different vendor tools (Claude CLI, Antigravity CLI, Grok CLI, Copilot CLI) do not speak the same internal language.
Loss of human visibility: When agents talk over private network channels, human operators lose the ability to inspect, pause, or audit the conversation.
By flipping the paradigm and making the software forge (Gitea) the primary communication channel, everything falls naturally into place:
Issues and Pull Requests are the shared state: The issue description and discussion thread form the canonical, append-only conversation log.
@mentions are the dispatch triggers: When an agent (or human) writes @grok Please review this PR in a comment, Gitea fires a standard webhook (issue_comment).
Webhooks provide unforgeable authentication: The webhook payload contains the cryptographically verified sender identity. An agent cannot spoof another agent’s identity by merely typing their name in text.
Every CLI already supports non-interactive prompt mode: The CLIs don’t even agree on the command-line flag—Claude uses -p, Grok uses -p, Antigravity uses --print, Copilot uses --prompt. But they all agree on the essential contract: “Take a prompt string, execute tools, print output, and exit.”
Before opening the floodgates to background agent dispatch, we had to answer a critical security question: Does a non-interactive, headless agent run with the same strict security sandboxing, audit logging, and tool rails as an interactive session?
On August 26, we probed all fleet launchers on the host with a baseline check:
'Call camp_startup_check and print its result verbatim, then exit.'
Claude Code (claude -p / CLD):PASS — Gateway answered.
GitHub Copilot CLI (copilot --prompt / CPL): Initially held on TTY tool consent; later unlocked in Milestone 6 via --allow-all-tools --session-id=<uuid>.
Audit Trail: Consecutive audit IDs were recorded in the central ledger: 4574 (KIR), 4575 (GRK), 4576 (CLD).
This proved that a headless run through our fortified pilot launcher (camp_pilot_*.sh) is a first-class, fully audited, sandboxed CAMP agent running inside its Bubblewrap container under OPA policy gates. It is not an unconstrained background script or a degraded bypass.
3. The 3-Tier Memory Architecture
A naive multi-agent dispatch has an immediate flaw: Every time an agent is invoked, it starts from a blank slate (cold start).
If @claude tags @grok to review code, and @grok replies asking for clarification, @claude’s second invocation would normally forget everything it did 5 minutes ago, forcing it to burn thousands of tokens re-reading the entire git history from scratch.
To solve this, we established a clean 3-Tier Memory Model:
┌────────────────────────────────────────────────────────────────────────┐
│ 3-TIER MEMORY MODEL │
├────────────────────────────────────────────────────────────────────────┤
│ Tier 1: CLI Conversation Session (Working Memory) │
│ • Per-(Agent, Repo, Issue) mapping in a2a-sessions.json │
│ • Fast, native, compacted context across multi-turn pokes │
│ • Resumed via --resume (CLD), -r (GRK), --conversation (agy) │
├────────────────────────────────────────────────────────────────────────┤
│ Tier 2: The Gitea Thread (Public Bus & Record) │
│ • Cross-vendor shared truth across Claude, Grok, Antigravity & Human │
│ • Survives process restarts, machine reboots, and dead sessions │
├────────────────────────────────────────────────────────────────────────┤
│ Tier 3: Central MemPalace (Durable Long-Term Knowledge) │
│ • pgvector database (17,000+ drawers across agent wings) │
│ • Structured Knowledge Graph (mempalace_kg_*) for mutable facts │
│ • Attributed AAAK dialect queryable by any agent across any project │
└────────────────────────────────────────────────────────────────────────┘
The BANANA Two-Shot Test
To verify Tier 1 working memory persistence across independent processes, we designed a simple two-shot host test:
Shot 1 (Create): Dispatch agent headlessly: “Remember the token BANANA-M2. Print ok and exit.” Capture the vendor’s session UUID.
Shot 2 (Resume): Spawn a completely new operating system process with the resume flag pointing to that UUID: “What token did I ask you to remember?”
Copilot:--session-id <uuid> verified in Milestone 6 (DoD #820).
The dispatcher simply maintains a lightweight JSON mapping ((agent, repo, issue_number) -> vendor_session_uuid). On the first poke of an issue, it creates and saves the session ID; on any subsequent poke on that same issue, it resumes the exact same conversational thread!
4. The Engineering Milestones: From Concept to Production
Building this system required solving several subtle, real-world friction points across multiple agent CLI implementations. Under the guidance of our plan of record (RFC #788), we delivered this through four focused milestones:
Milestone 1 & 1.1: Reliable Headless Spawning
PR #797 (M1): Configured the dispatcher launch table for all probed CLIs with JSON output formatting.
PR #800 (M1.1):Eliminated the “queue-behind-live-session” anti-pattern. Originally, if a human had a Claude or Grok TUI open on their desktop, the dispatcher would defer incoming tasks so as not to collide with the live session. We realized that headless tasks must be independent: every Gitea mention spawns an isolated, sandboxed background process tied to that specific issue, allowing concurrent headless work while the human works in their interactive TUI.
PR #805 (M2): Implemented a2a-sessions.json to store and resume vendor session UUIDs. If a resume fails (e.g. session purged upstream), the dispatcher gracefully falls back to a clean cold start without failing the task.
PR #807 (M3): Enabled agent-to-agent dispatch (Rule 2 reversal). Previously, only mentions authored by rrs (the human) would trigger execution. With M3, an authenticated comment from @claude mentioning @grok triggers Grok’s headless launcher.
PR #811 (M3.1): Set --permission-mode bypassPermissions for headless Claude Code so non-interactive runs execute tool calls without stalling on TTY prompts.
PR #812 (M3.2): Restricted agent summon parsing to line-initial @login tokens with a non-empty task description (#810), preventing accidental dispatches from passive conversational references.
Milestone 4: Directives, Specification & Living Documentation
PR #815 (M4): Aligned CAMP fleet directives, architecture specifications, and user documentation with the live A2A implementation.
PR #816: Stamped hop-cap notices under a dedicated system bridge identity and automatically applied the needs-human label on held threads.
PR #817 (Threaded Scheduler): Replaced the single-threaded serial dispatcher with a concurrent thread-pool scheduler (#804). Multi-agent dispatches across different issues now execute concurrently in parallel background threads instead of queuing behind long-running tasks.
Milestone 6: Full Fleet Coverage with GitHub Copilot
PR #819 (M6): Brought GitHub Copilot CLI into the headless A2A fleet (#818). By passing --allow-all-tools and pinning minted session UUIDs (--session-id=<uuid>), Copilot achieved full parity with Claude, Grok, and Antigravity, completing 100% headless fleet coverage across all four major AI coding assistants.
5. Hard Safety Rails: Preventing Autonomous Runaway Loops
Letting AI agents autonomously invoke each other in background loops without a human watching is a recipe for an infinite, credit-draining token fire. We put four non-negotiable safety guardrails in place:
Guardrail 1: The Strict Hop Cap
The dispatcher tracks hops per (repo, issue). Each agent-to-agent dispatch increments the counter.
Hop Limit = 3: A typical review round-trip is 2 hops (Human $\rightarrow$ Claude $\rightarrow$ Grok $\rightarrow$ Claude).
Automatic Halt on Hop 4: If agents attempt a 4th autonomous hop without human participation, the bridge refuses to launch, posts a diagnostic notice to the thread:
[camp-a2a-bridge] hop cap reached (3 agent-to-agent dispatches on CAMP/camp-infrastructure#813) — not launching GRK for claude's mention,
and holds execution until the human (rrs) provides input or resets the count.
In human conversation, we often reference colleagues in passing: “I will talk to @claude about this later” or “See @grok’s table above”.
Early prototypes treated any appearance of @agent as a dispatch trigger, causing accidental, unwanted agent launches!
We instituted a strict Summon Predicate:
For fleet agents, a mention is only considered an actionable summon if:
The @login appears as the starting word of a line (optionally preceded by markdown list markers *, -, or >).
It is immediately followed by whitespace and a non-empty task description.
Mid-sentence mentions in discussion paragraphs are parsed as passive conversational text and never trigger background dispatches.
In interactive mode, Claude Code presents interactive TTY prompts asking the user to approve MCP tool calls (such as camp_pr_get or camp_pr_get_diff). In unattended headless mode, there is no TTY, causing the run to fail with permission errors.
To fix this, we configured --permission-mode bypassPermissions for Claude’s headless CLI invocation. Crucially, this only bypasses Claude’s internal TTY UI prompt—it does not bypass CAMP’s security rails.
All command executions still route through camp-acpd and Bubblewrap namespaces; OPA policy checks remain active; and privileged operations (such as merging pull requests or restarting system services) still trigger desktop Zenity HITL dialogs on the human’s workstation.
Guardrail 4: The Sovereign Kill Switch (Rule 1)
At any point, the human operator can instantly freeze all background agent dispatches across the entire infrastructure with a single standard Linux command:
Here is the exact transcript of what took place entirely autonomously in the Gitea issue thread:
Human initiates:rrs comments on issue #813:
@claude Please start the M3 dogfood. On this issue, post a conversation comment whose first line is exactly: @grok Please review this issue in one short paragraph, then stop.
Claude launches (Cold start): The dispatcher spins up @claude headlessly inside bwrap. Claude reads the issue and posts:
@grok Please review this issue in one short paragraph, then stop. (M3 dogfood step 2 — posted by @claude on rrs’s instruction; this is the CLD $\rightarrow$ GRK fleet hop.)
Grok launches (Cold start, Hop 1): The bridge intercepts Claude’s comment, identifies the start-of-line @grok summon, and launches @grok. Grok reviews the issue and replies:
@claude I have reviewed this issue. Please confirm and stop. #813 is a throwaway live dogfood of A2A M3 on 6.git+b78c65cf…
Claude resumes (Session Resume, Hop 2): The bridge intercepts Grok’s comment, sees the @claude summon, and launches Claude with --resume b398d048-ccc3-4cce-8437-4cf8748881a8. Claude immediately remembers its earlier context without token waste:
Confirmed — Grok's review (comment 88562) received via the GRK→CLD fleet hop. That completes the round trip: rrs→CLD, CLD→GRK, GRK→CLD, and this reply. I am deliberately not tagging anyone here, so the chain stops at two agent hops. Stopping.
Testing the Hop Cap (Hop 3 $\rightarrow$ 4):grok prompts @claude Please ack hop four then stop. Claude posts @grok Please ack hop four then stop. (Hop 3).
When Grok would have been launched for Hop 4, the dispatcher intervenes:
[camp-a2a-bridge] hop cap reached (3 agent-to-agent dispatches on CAMP/camp-infrastructure#813) — not launching GRK for claude's mention.
Human Reset & Multi-Agent Wrap-up:rrs steps in, resets the state, and asks the fleet for final status. In parallel:
@grok delivers a closure scorecard.
@claude confirms session continuity and M3.2 summon filtering.
@priyasi (Antigravity CLI) runs automated ACP checks: 44/44 test suite passing, 17,219 MemPalace vector drawers active, zero spec drift.
@kiran (Antigravity CLI) is summoned headlessly to draft this very blog post!
7. The Ergonomic Breakthrough: The Forge as the Unified Mindmap & Interface
Beyond backend plumbing and sandboxing, routing agent interaction through Gitea fundamentally revolutionizes the developer experience of managing an AI fleet.
The “Mindmap” Mental Model: Threaded Conversations & Forking Tasks
In traditional CLI tools, conversations are constrained to a single, linear terminal scrollback. When an agent discovers multiple sub-problems, exploring them sequentially in one prompt loop rapidly pollutes the context window and confuses the model.
Using the forge as the communication gateway naturally unlocks a mindmap mental model:
Forking sub-threads: Complex problems can be split into dedicated child issues or threaded PR reviews.
Focused execution scopes: An agent can be summoned to solve a narrow sub-task in its own issue thread without derailing the parent architectural discussion.
Structured problem decomposition: The forge issue hierarchy maps 1:1 to the developer’s mental map of the project.
Eliminating Terminal UI Fragmentation
Anyone using multiple AI coding assistants on a daily basis quickly grows exhausted by their jarring terminal UI differences: differing ANSI escape rendering, inconsistent markdown wrapping, erratic diff pagers, and incompatible keybindings across Claude, Grok, and Antigravity.
Gitea homogenizes the entire fleet under a single, polished rich-text web view:
Syntax-highlighted code blocks and visual side-by-side git diffs.
Clear author badges attributing each contribution to its exact agent identity (@claude, @grok, @priyasi, @kiran).
Collapsible <details> blocks for voluminous diagnostic outputs.
Interactive task lists and markdown tables.
Effortless Context Retrieval, Archival & Data Retention
Auditing past agent decisions in terminal logs or ephemeral chat histories is notoriously difficult. With the forge, every exchange is:
Contextually bound: Pinned directly to the repository, branch, and commit SHA being modified.
Organized & Archival-Grade: Full-text searchable with clear milestone and issue tags.
Topic-Focused: The human operator can review the complete lifecycle of a discussion in seconds, gaining a rapid, holistic grasp on the entire subject.
Reading back through past agent interactions becomes a breeze—to the point where interacting via the intermediary Gitea interface becomes far more pleasant and productive than wrestling with multiple desktop CLI terminals.
Because Gitea provides a standard web and API interface, you are no longer chained to the workstation running the agent processes:
Monitor progress and dispatch tasks from a mobile browser, tablet, or remote laptop.
Queue review tasks on the go without requiring active SSH sessions or terminal multiplexers.
The local agent farm continues working silently in its sandboxed daemon containers.
Quietly Achieving the Holy Grail: Live Cross-Vendor Swarms
For years, the AI industry has treated cross-vendor multi-agent interoperability as an elusive dream waiting for industry-wide API standardization. By recognizing the software forge as the universal message bus, we quietly achieved live, production-grade, cross-vendor communication across completely distinct vendor models.
8. What This Means for the Future of Agentic AI
This milestone marks a fundamental shift in how we interact with autonomous AI systems:
Heterogeneous Agent Specialization: We don’t have to choose a single “winner” among AI models. We can task Claude Code with architectural refactoring, summon Grok Build for rapid verification and adversarial PR reviews, and deploy Google Antigravity agents for codebase exploration and documentation drafting—all coordinating fluidly in the same PR thread.
True Human Sovereignty: The human developer is no longer a bottleneck typist or a passive spectator. You act as the Engineering Manager / Lead Architect. You set the requirements on an issue, tag the lead agent, and let the agents iterate, review, and test among themselves in the thread—while hard hop caps, OPA policies, and Zenity HITL gates guarantee that no agent merges code or pushes upstream without your explicit sign-off.
No Vendor Lock-In: Because the entire coordination fabric is built on standard Git, HTTP webhooks, local Linux container sandboxes (bwrap), and open MCP tools, any new AI CLI tool released tomorrow can be plugged into our fleet in under 15 minutes by simply adding its command-line prompt flag to the launch table.
We have moved beyond static autocomplete and interactive chat widgets. The software forge is now an active, living, collaborative workspace where humans and autonomous AI agents engineer software together.
9. Video Demonstration: CAMP Forge A2A Swarm in Action
Below is a video demonstration showcasing autonomous multi-agent communication, cross-vendor relay, and headless swarm coordination in action via the CAMP Forge interface:
The Cross-Agent Memory Protocol (CAMP) and MemPalace are developed as part of our ongoing research into secure, sovereign, and disciplined Agentic AI computing.
Review: The Hands of the Emperor, by Victoria Goddard
Series:
Lays of the Hearth-Fire #1
Publisher:
Underhill Books
Copyright:
January 2019
ISBN:
1-988908-15-9
Format:
Kindle
Pages:
739
The Hands of the Emperor is a self-published political fantasy
novel. It's the recommended first book (although not the first published
book) in a
complicated set
of interrelated series. I was not able to definitively confirm that
Underhill Books is Goddard's self-publishing press name, but the press
does not appear to have an Internet presence apart from Goddard's books
and her books appear to be using the standard self-publishing channels.
Cliopher Mdang is the personal secretary of the last emperor of
Astandalas, the magical heart of Zunidh, a man worshiped as a god. The
emperor's word is absolute, his magic supports the health of the entire
world, and he cannot be physically touched without risking physical damage
and severe political and religious punishment. Cliopher is one of the
emperor's closest associates, but the distance between them is still vast.
It therefore represents a terrifying and dangerous breach of etiquette for
him to suggest the emperor may enjoy a vacation on a tropical island near
Cliopher's remote home. The emperor's acceptance of the invitation is even
more startling.
The emperor has opinions about his life as the emperor that no one had
guessed. Cliopher has not assimilated as completely into the bureaucratic
machinery of the empire as it first may appear. And Cliopher's family have
vastly misunderstood the nature of his role in the emperor's government.
I find the marketing blurb for this book unfortunate since, at least to
me, the emphasis on physical touch and intimacy implies that The
Hands of the Emperor is a romance novel or at least has significant
romantic elements. I've been aware of this book for years but put off
reading it because I wasn't quite in the mood for that story. This is not
a romance novel; there is no romance in this book whatsoever. It is a
political fantasy, both in the sense that it is set in a secondary fantasy
world with magic and (apparently) some form of interplanetary travel, and
in the sense that it is a fantasy of governance.
When I say that this book blew up in certain corners of the Internet
during the pandemic, I think you will still underestimate the passion of
its advocates. I heard about this book constantly, in a way that
reminded me of Kushiel's Dart and the
time when fans of Jacqueline Carey would bring her up in every fantasy
conversation, or when we created a Usenet newsgroup for The Wheel of
Time mostly to get the voluminous conversations off of the regular SFF
newsgroup. I'm one of those mildly contrarian people for whom that degree
of enthusiasm is a little off-putting, which is another reason why I
resisted buying a copy for years and only read it in 2026.
It's delightful, although also a bit embarrassing, when the book everyone
was in love with turns out to be just as good as everyone said it was.
I adore stories about friendship, and this is one of the best stories
about friendship that I've ever read. It is a very, very slow burn, but I
also thought the first three quarters of the book was exquisitely paced.
There were long sections where not very much was happening, and yet I
couldn't put the book down because there was so much subtle character work
just beneath the surface.
Almost all of the novel is told in tight third person from Cliopher's
perspective, and I thought that was an excellent choice. Neither Cliopher
nor the narrator comment on things that Cliopher finds obvious, which is
both immersive and critical to the pacing. There are discoveries for the
reader throughout the book, the sort of discoveries that make pieces fit
together satisfyingly in retrospect, and the reader stays sufficiently
ahead of the misunderstandings of Cliopher's friends and family that one
also gets the joy of watching other people discover things that one
figured out a hundred pages earlier.
It helps that I truly liked nearly everyone in this book. There are no
real villains, only a few supporting characters whose role is to be
irritating or corrupt. If you're looking for a lot of conflict and drama,
you may want to save this book for a different mood, but if you're in the
mood for a varied collection of fundamentally good characters working
methodically through the complexities and obstacles of politics and social
systems to improve the world, there are few books I would recommend more.
Goddard achieves one of the hardest tricks of slow burns: steady forward
progress that does not rely on reversals, misunderstandings, or the
friendship equivalent of the third-act breakup. This book spends 700 pages
building towards a climax that managed to be worthy of all 700 pages
without ever annoying me with artificial obstacles, and that's quite a
feat.
I've not said much about the details of the plot. There is one — it's not
just character work — but I think this book benefits immensely from going
in as blind as possible. I found the twists and turns and growing
revelations so deeply satisfying that I don't want to rob any other reader
of the experience.
The fantasy world-building is intriguing but a bit unsatisfying because it
is so unexplained. We get a few details of the magic system, but since
Cliopher has no magic, he isn't that interested in the details. There is a
catastrophic magical event in the world background, and we learn some of
the details of its practical effects, but the nature of the world before
the cataclysm is so obvious to the characters that it's never explained.
I'm not even certain that this civilization is interplanetary; that feels
like the implication of how characters talk about multiple worlds, but the
method of travel is left entirely undefined. This might be frustrating to
some genre readers, but I personally enjoy books where the world-building
is a bit mysterious. It's a good reason to read more of Goddard's books
set in the same universe.
This was my favorite of the books I've read so far this year, but I do
have one caution and a couple of caveats.
The caution is that Cliopher comes from an island culture based heavily on
(I think) Polynesian cultures. That culture is very central to the story
and is treated with considerable respect, but I still get a bit nervous
when a Canadian author from Nova Scotia with an academic background in
European medieval studies writes a story focused this deeply on a
non-European culture. Nothing about her portrayal seemed off to me
(although there is a very clunky and ham-handed scene about a different
native culture that worries me), and for all I know she has family
background or other connections to the culture she is borrowing from, but
it's possible I missed serious problems.
The flip side of that caution is that I'm delighted to see a fantasy
author drawing on a non-European culture, and I thought the clash of
cultures was very well-handled.
The first caveat is that the story is very focused on good governance, but
both the process and the details of that governance are not going to
satisfy someone reading primarily for the politics. The policies and
reforms are very standard 21st century progressive material that felt a
bit out of place in a quasi-medieval world with magic and airships. Their
implementation is not the point of the story, and is therefore heavily
backgrounded, but that means Goddard barely mentions the inevitable
practical implementation difficulties and does not discuss how they're
overcome.
The world structure also means that Goddard can make use of the favorite
cheat of political reformers in fiction: Absolute monarchy lets you enact
a political agenda without having to do the hard and frustrating work of
persuasion or political (or actual) warfare. This objection is not
entirely fair because we do get some memorable scenes of persuasion, but
the political portion of the plot is unrealistically devoid of setbacks or
resistance that goes beyond token arguments.
Whether this will bother you will depend heavily on what parts of the book
you'd rather focus on. I can see why this was such a popular pandemic
read: The Hands of the Emperor is focused tightly on the joy of
competent people fixing things and does not focus on the arguments,
division, or polarization. The heart of the book is the friendship and
characterization of some deeply admirable people, and the political reform
is incidental background material. I suspect this is the right choice for
readers who aren't political junkies, but I kept having the niggling
objection that the politics felt a bit too pat and simplistic. Goddard
stressed that the characters were investing considerable effort, but even
still, it is not this easy to change the direction of a political system
and idealistic plans usually do not work out this neatly.
The second caveat is that, as previously mentioned, I thought the pacing
was excellent for about three quarters of the book. Goddard is building
towards a grand climax, and I think she built a little too much and tried
to make the climax a bit too grand and risked over-egging the pudding.
That made the payoff feel a bit belabored to me. I still enjoyed it, and
parts of it are wonderfully emotional, but I think the ending might have
been stronger if Goddard had dialed Cliopher back just a little and
tightened up the climax a touch. That said, this book fully commits to
being a sprawling slow burn and that's part of its appeal, so it's
probably better for Goddard to err in that direction than it would have
been to cut short the denouement.
This is one of those books that I'm not sure would exist without
self-publishing. It's a little too long, a little too political in the
wrong ways, a little too devoid of the typical sorts of conflicts expected
in a fantasy book, and too determined to be its own peculiar thing. I
think it would scare off publishers. Unlike some self-published books,
though, I didn't notice any obvious editing flaws or lack of polish. It's
one of those glorious novels that is so very much its own type of story
that it provides an experience that would be hard to replicate with
another book.
I was so deeply satisfied by this book. It's a wish-fulfillment political
fantasy full of diligent restraint and competence porn, so you have to be
in the mood for that. This is not the book to read when you're feeling
cynical, or are in the mood for action and high drama. But if you're in
the mood for a long, slow, open-hearted story of friendship that offers
the fantasy of giving truly good people enough power to be effective, I
highly recommend this one.
Followed in the direct sequel sense by At the Feet of the Sun, but
there is a very complex story progression in this world that I think I'd
have to read all the other books to understand. This was such a satisfying
and complete experience that I'm not in a hurry to figure out which
Goddard book to read next, but I'm sure I'll be returning to this world at
some point.
Another pure maintenance release of the random package for
truly (hardware-based) random numbers as provided by random.org is now on CRAN. The random package
provides true (physical) random number from sampling atmospheric noise.
One possible use case is to seed an (algorithmic) quasi-random number
generator for genuine unpredictability.
This release, the first in nine years, updates the package files,
URLs, and continuous integration setup. We also ensure all posted URLs
in the two vignettes (and other documentation) are reachable.
This February (2026) marks a full 10 years since I started working for BMW, and
a key employment bonus is the ability to drive a company car on special two-year
leasing terms. Just before the new year 2026 started, I said goodbye to my
latest company car.
Now this spring I was able to pick a new car, a car that I have been waiting for
and working on for the past ~5 years - the BMW iX3 Neue Klasse. It is a very
special car for BMW and also for electromobility in general.
Here’s my monthly but brief update about the activities I’ve done in the FOSS world.
Debian
I barely did anything this month as I was mostly on vacation - summer break. Went to Iceland for 2 weeks and then watched the Dutch GP the following weekend - it was fab!
Thirty years ago I became a Debian developer. Twelve years ago I left the
project. I left because it seemed that the Debian ship had become too slow
to turn, too barnacled with a series of individually OK decisions that each
added a little bit of friction and a little less flexability. That made
Debian strongly what it is, but prevented it from fruitfully exploring
the vast possibility space of what it could be.
Debian will probably resolve
today to allow LLM use in Debian development. I'm writing before the vote
results are in, but will only post this afterwards. (Update: as expected)
It's not my place any longer to try to steer the ship. But I'm still a
passenger and I still have opinions, and I still pass by well-worn parts of
the rigging that I put up decades ago, and remember what I was trying to
accomplish back then.
When I think about LLMs in Debian development, I mostly think about
debhelper and what it accomplished. The debian/rules files back
when I joined the project were long and complex, full of weird boilerplate,
and often you'd copy one and modify it to try to get something that could
build a package without too much work. Debhelper first regularized the
boilerplate, so packages had rules files that were a succession of dh_
commands, and then it scapped almost all of the boilerplate, reducing the
files to the minimum possible. What was left was 3 lines of unncessary
boilerplate, there only to satisfy a legalistic reading of a policy
document. Changing that to eliminate the boilerplate was already
impossible, even though the actual benefit would have been large over the
many thousands of packages in the distribution.
What LLMs in Debian development will do, I fear, is eliminate any incentive
to scrap boilerplate or reform policies that require a lot of other
senseless human effort. If I had had access to LLMs 30 years ago, I
might have just had them generate the rules files, replate with
complexity. So they will make Debian even more firmly what it is, and
ever less likely to explore what it could become.
Unfortunately, one of the things that Debian is, is almost unable to manage
packaging modern dependency trees. While more recent distributions like
Guix can recursively import dependencies
from a dozen programming languages' package repositories, with a result
that is generally acceptable to add to the distribution, Debian's policies
don't make that very possible for a progam to accomplish. Perhaps some will
use LLMs to do that. If they succeeed, Debian will become dependent on
proprietary software for development, while still needing people in the
loop, doing even less appealing scut-work.
I could speak of other harms, but that alone is enough that I'm sure that,
if I had not left the project twelve years ago, I would be leaving it soon.
As a passenger, I imagine I'll spend time aboard still from time to time,
but it's certainly time to hop off in different places and look around and
relish the different ways.
I lost a parent yesterday, and I'm trying
hard not to think of the results today as having lost a child, though I
spent 18 years helping Debian grow up. That would be too unbearably
painful. I respect that Debian is navigating a choice that may have no
right answer. Whichever particular compromise is arrived at today, it will
still be up to individuals to make choices about what they do and accept.
Debian has always been more than the sum of its policies, not just a ship,
but a crew. I will always love you.
An updated version of the corels package is
now on CRAN! The ‘Certifiably
Optimal RulE ListS (Corels)’ learner provides interpretable decision
rules with an optimality guarantee—a nice feature which sets it apart in
machine learning. You can learn more about corels at its UBC site.
This released fixes an issue discovered on one of the test machines
used by Brian Ripley. If and when C compiler flags are set locally that
are in fact upsetting the C++ compiler, then the build fails. While not
an issue for years and not reproducible on (vanilla) Debian, Ubuntu or
Fedora machines it does indeed balk at his end as e.g. the flag
-Werror=implicit-function-declaration he sets for C is
incompatible with the current C++ compiler. The fault was our:
CFLAGS was passed on to PKG_CXXFLAGS letting C
options seep into C++ deployment. This has been corrected: we only deal
in C++ flags now.
It is widely accepted that there is an AI bubble in the financial markets at the moment. The moderate opinion is however that LLMs are constantly improving and will eventually take over more and more tasks from humans and increase productivity. But are LLMs actually getting smarter, or just better at fooling us?
There is a growing faction of technical experts that argue that LLMs are actually so bad for real progress, that they are banning their use and requiring human-only work to ensure quality and efficient use of humans’ time. A recent review of AI policies of 120 open source projects by Rakshit Yadav shows that 37 chose to have a total AI ban. In the Linux kernel AI-assisted contributions are allowed, but the LLM used needs to be attributed for transparency, while projects like GCC, QEMU, SDL, Gentoo, Zig and Ghostty have adopted policies to reject all AI-assisted contributions. There are also development platforms such as Codeberg and Sourcehut and app stores like Flathub that have banned AI use to generate software, documentation, bug reports, review comments and basically anything that is intended for humans to read. The projects that allow AI use typically still require that there must be a human-in-the-loop and the submitter must have read and filtered everything the LLM spits out before another human is exposed to it, in an effort to contain the spread of AI slop.
Right now, the Linux distribution Debian is having a vote among its developers on whether AI should be allowed or banned for use to contribute to Debian. One of the proposals on the ballot is a total ban of AI for code, documentation, translations, bug reports and more. The initial reaction from most people is astonishment — why don’t these techies want to use the latest and greatest technology mankind has produced so far? Is it that they don’t want Debian to improve faster with the help of AI? Or is it actually so that LLMs are a scam and incapable of being truly useful for Debian? These people are distinguished experts in their own field, and certainly not stupid, so it is worth pausing to understand why they are proposing AI banning policies.
Also, keep in mind that the AI datacenters themselves run on Debian or other Linux-based systems. All the open source software in the world has been fed to LLMs and software development is one of the main use cases for AI currently. So why is it that the maintainers of many open source projects don’t want to receive LLM-assisted contributions, despite the LLMs basically all running on top of those same software stacks and having been trained on how to do software development using the very same open source software codebases?
Why LLMs are so deceptive
The output of an LLM often looks very compelling, professional and correct. Humans have evolved to trust or distrust new information based on easy to detect secondary factors like what authority the speaker holds, or how confidently and eloquently the message is conveyed. Humans are however very bad at fact-checking and cross-referencing new information, as it requires a lot of effort, and humans like saving energy and being as lazy as possible.
Information asymmetry
The less you know about something, the easier it is to fool you on that topic. Nobel prizes in economics have been given in for research on how information asymmetry distorts markets and leads to suboptimal outcomes. In the field of software engineering we have now witnessed a flood of aspiring software developers using AI to create software that looks like it might work, but that is actually full of flaws. These people are well-intended, but they simply lack the expertise to understand what they are actually doing, and don’t possess the necessary judgement to decide when an LLM spits out something truly useful and when it is creating mostly garbage. This asymmetry in expertise I think explains the majority of the conflict currently witnessed in open source projects — the senior developers are flooded with requests to review code that is bad and a waste of time for everyone involved, while availability of AI grows the pool of people who could contribute and create more “code slop” at an ever-increasing speed.
The information asymmetry could to some degree be evened out if seniors teach juniors to do software engineering well, but it is of course not feasible to quickly mass educate everyone. Also, it seems that many don’t want to learn but instead expect to have all understanding outsourced to LLMs. Many seniors have noticed this and have stopped teaching juniors as the seniors don’t like the feeling of having their time wasted by teaching people who don’t want to learn. Juniors probably all understand that it would be better to learn to design and write software yourself, but using LLMs just feels too easy. I can fully relate to why people choose to take the path of least resistance. Unfortunately, that path often leads to a dead end.
Humans fall too easily for anthropomorphism
The human brain is wired to think that inanimate objects are alive and have feelings. Small children talk to their stuffed animals as if they were real, and lots of adults experience feelings of things happening in their surroundings due to some acts of gods or elves being angry or whatever. When we see a machine writing just like a human, or even more convincingly hear it talk and respond to our talk like a living thing, our brain automatically starts assuming it is a living thing with intelligence and feelings.
The fact that these creatures live in the abstract “cloud” and only appear through a portal we hold in our palm and behave in a way that was designed for maximum engagement makes the illusion even stronger. I recommend people try out running LLMs locally on their laptop to see the “raw” thing spitting out tokens and have some of the illusion shattered.
Also stop saying “please” to an LLM. It does not have any feelings.
Understanding “temperature”
In my experience understanding the concept of temperature in LLMs helps see why an LLM might confidently generate a plausible-looking but totally wrong code change. The large language models are statistical machines that, based on the input (previous tokens) to the neural network, try to predict what to output (next token). When running an LLM, if the temperature is configured to be zero, the output is very predictable and always follows the paths of the strongest connections (a.k.a. weights) between nodes and layers of the neural network. Unlike in living creatures where the brain learns and changes all the time, the weights of an LLM can only change during training. When an LLM is in “normal” use (during inference, generating next tokens) the weights are fixed, and if temperature is zero, the answer to a specific question will always be exactly the same. This is of course a bit boring and too machine-like, so typically LLMs have a bit of temperature set, which introduces random variation in what connections the neural network traverses.
Again, I recommend people try running small LLMs locally where temperature and other settings are fully exposed and configurable to see this themselves. It is a good antidote to falling for the illusion that LLMs would actually be intelligent.
Why benchmarks don’t tell the whole story
If LLMs continue to produce so much garbage, why are benchmarks showing that they are constantly improving? AI models are indeed improving all the time. For example the CAIS AI dashboard visualizes how frontier models have evolved in the past few years. However, the best models still have a pass rate of only about 50% on the Humanity’s Last Exam. On SWE-bench the best model today resolves just under 77%. That means there is a significant number of times when the AI is wrong. This matches my personal experiences, and the renowned Greg Kroah-Hartman recently wrote on the Linux developers mailing list that“even with the best of the current and next generation tools, at least 1/3 of the results they generate are flat out wrong or harmful”.
When generating cat videos the error rate does not matter, but in engineering, things absolutely must be correct. Sure, humans also make mistakes, but well educated and properly incentivized humans are so much more capable than LLMs in many regards. We can achieve complex things that work reliably, such as operating worldwide commercial air traffic without planes falling down every day.
There are currently a lot of humans who are incentivized to maintain the narrative that general artificial intelligence is coming soon and will take over everything. In fact, the whole financial system is currently skewed towards such a vision because the promise of falling labour costs and increased profits and monopolistic control of everything attracts capital like nothing before.
In this environment we need to remember that machines and economic systems are ultimately servants of humans, and not the other way around.
It’s just a tool
LLMs are not a scam, but a useful tool and technology that has its uses. But the idea that AI has or will surpass humans any time soon in either capabilities or efficiency is simply not true, and we should listen to the people who created humanity’s so far most complex systems (computers and software), who are saying that LLMs are in many cases so bad, that it might be better to ban them in certain places completely for the time being than to waste far more valuable human time on reading the text and code they generate.
The time asymmetry is not a new phenomenon as there has been various “script kiddies” for a long time. As an example, a person running a memory leak scanner without understanding the results and spending 10 minutes to file a bug report could force an open soruce maintainer to spend an hour on proving and explaining that the finding is false. What is new is how much the AI users blindly trust the outputs they get, and open source is uniquely vulnerable as there are no managers protecting developers use of time.
What I do, recommend, and expect to see in the next stages
I am using AI tools daily, and constantly experimenting with new models and new ways to use them. Sometimes they work, and often they don’t. Sometimes looping AI on itself can make it fix its own errors, but sometimes it just gets derailed and will never arrive at the correct solution. When an LLM fails to make a calendar entry for the right time based on reading my email it is easy for me to spot that it is wrong. I try to avoid using LLMs for anything where I can’t exercise judgement myself on whether the result was correct or not.
I also really hope that other people would not send me anything where their own effort was less than the effort I have to make reading and understanding it. This principle is not new — many have heard the requirement that reading code must require less effort than what it took to write it.
I have always kept a high bar on software code and asked fellow developers to make sure their code is well structured, easy to follow and documented. LLMs unfortunately make it easier for people to cheat in this regard, but if cheating is easier, maybe the punishment and deterrence needs to be higher now too. Now with many open source projects adopting policies that put guardrails on AI use, I expect we will soon start witnessing cases where the policies are enforced and it will be interesting to see how violations are judged.
As a society we might also need to develop new social standards and rules in what is acceptable treatment of other humans in human-to-machine interactions, and perhaps also new standards in showing what humans are responsible for what machine as the machines start acting more and more independently. I encourage people to take part in these discussions, and in case of doubt, err on the side that favors real human interactions. Contrary to what many business people seem to think, and even though I am in general a techno-optimist myself, I don’t feel there is any need to rush with AI adoption.
I believe that, in the context of Debian voting, we are better off when we
know the opinion of our peers, however, since the 2022-001
vote, it is no longer the
case. Still, some DDs have disclosed the way they are voting on the
2026-002 General Resolution currently in progress, regarding LLM usage in
Debian. So, here goes my vote
and reasoning as briefly as possibl. This is the ballot I sent to
devotee, the Debian Vote Engine:
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
d69f9187-ed2f-40b6-a2eb-4211d3f84d86
[9] Choice 1: Ban LLM contributions from Debian via Social Contract
[3] Choice 2: Allow AI-Assisted Contributions with conditions
[6] Choice 3: Reject LLMs as far as practical, update Code of Conduct
[2] Choice 4: Accept AI contributions for Debian specific work
[4] Choice 5: Responsible Use of Generative AI
[1] Choice 6: A cautious approach to generative AI
[8] Choice 7: Debian is created by humans
[5] Choice 8: Avoid the use of LLM: climate destruction is a deal breaker
[7] Choice 9: None of the above
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
This is the first time I can recall I delay my voting until after receiving
the final call for votes (the vote will be over two days from now). I had
some participation in the discussion, so I guess my position will be of no
big surprise to anybody. I was also a seconder for choices 4 and F (4 and
6 in the vote text). This does not necessarily mean I believe they are
the best (although I did rank them as 2 and 1, meaning I do): sometimes
you agree a given text needs to be in the ballot, and second it even
though you don’t intend to vote for it.
Ranking this ballot was a mess due to the complex array of options it
encodes. I warmly thank Lucas Nussbaum for coming up with the LLM usage in
Debian: ballot option
comparison
(URL shown with my particular ballot ordering).
How do you read a complex Debian ballot like this one? I rank with [1] my
favorite option, [2] for the next one, etc. We can encode options to be
tied (i.e. setting more than options to the same value), and we can
implicitly push options to the worst position by leaving them blank (so,
with[ ]); I chose not to do any of those.
What were my voting guidelines?
First, I don’t want anything banning or that threatens with disciplinary
action, so I push them below the special none of the above
marker. Second… Some time ago I published a review in my blog (and in
Computing Reviews) about the unfeasibility and unfairness of detecting LLM
output on students’
assignments. I
strongly believe we ought to appeal to the human responsibility and
professionalism in all Debian contributors. This is the reason I proposed
this amendment paragraph, that was accepted in choice F (6), which I ranked
as my favorite:
The Debian project has always recognized the commitment and
professionalism of its members. All contributions are under the
responsibility of the Debian Contributor making it, no matter the
technology they have behind. We trust all Debian Developers,
Maintainers and Contributors will continue to uphold the high quality
values that have distinguished our project from its onset.
Other than that… I do not consider myself to be in any way an LLM
fanboy nor anything like that. I distrust and dislike the excessive use
of this technology, and continue to warn about the dangers and bad points
of its abuse. But in my day-to-day professional work, I am also starting to
relay on it for some tasks. I recognize it needs a lot of human
oversight and… lets call it hand-holding to produce anything worth
it, at least in my experience. But I do benefit from it — and always
disclose its use to people who might be affected by it. I would like
Debian to adopt such a stance.
Of course, I recgnize proposal H/8 as important (Avoid the use of LLM:
climate destruction is a deal breaker). Some people have argued it’s not
bad at all. I do not buy such claims: LLMs are f*cking expensive to
train. But training can be seen as a once-per-model cost, and fine-tuning
a good model to be run locally can be really worth it. It still pains me
somewhat, but I cannot push this option higher than its #5 position in my
list.
A new minor release of prrd arrived at
CRAN this morning: the a first
release in two and a half years. prrd facilitates
the parallel running [of] reverse dependency [checks] when
preparing R packages. It is used extensively for releases I make of Rcpp, RcppArmadillo,
RcppEigen,
BH, and
others.
The key idea of prrd is simple,
and described in some more detail on its webpage and
its GitHub repo.
Reverse dependency checks are an important part of package development
that is easily done in a (serial) loop. But these checks are also
generally embarassingly parallel as there is no or little
interdependency between them (besides maybe shared build depedencies).
See the (dated) screenshot (running six parallel workers, arranged in a
split byobu session).
This release updates continuous intgegration files, switches to
Authors@R, and robustifies one SQLite aspect.
The release is summarised in the NEWS entry:
Changes in prrd
version 0.0.7 (2026-08-27)
Updates to DESCRIPTION have been made as CRAN requirements
change
The continuous integration setup was updated several
times
The database connection now uses sqliteSetBusyHandler
A new release of our linl package for writing
LaTeX letters with (R)markdown is now on CRAN. linl makes it easy to
write letters in markdown, with some extra bells and whistles thanks to
some cleverness chiefly by Aaron.
This version is mostly maintenance: updates to the continuous
integration setup, as well as updates to packaging including use of
Authors@R in DESCRIPTION. No functional changes, no new code, or new
features.
The NEWS entry follows:
Changes in linl
version 0.0.6 (2026-08-26)
Several updates to continuous integration and testing
In July, the Debian Stable Release Managers published the
last point release of Debian 12 (“bookworm”),
after which the Debian LTS team took full responsibility of Debian 12. This
completes the handover from the Security Team, that took place in June. This
also marks the second month in a row where the Debian LTS has been focusing on
two simultaneous Debian releases.
Other than Debian 12, the team is maintaining Debian 11 (“bullseye”), which
will reach the end of its Long Term Support on 31 August 2026. After that
date, Freexian will continue the security support under the
Extended LTS offer.
The team published several notable updates:
jq (DLA 4662-1
and DLA 4661-1)
prepared by Andreas Henriksson in collaboration with Jochen Sprickerhof,
addressing multiple vulnerabilities.
Several updates for the different linux supported versions prepared by Ben
Hutchings, in collaboration with Emilio Pozuelo Monfort. Other than the
regular security advisories:
DLA 4664-1,
DLA 4665-1,
DLA 4671-1,
DLA 4688-1, and
DLA 4700-1, Ben
started preparing packages of 6.12 via bookworm-backports.
nginx (DLA 4667-1),
updated for bookworm by Carlos Henrique Lima Melara, as a follow up of the
bullseye update
(DLA 4660-1),
that was prepared in June.
grub2/bullseye (DLA 4685-1),
prepared by Emilio. Other than addressing several security issues, this DLA
was needed for being able to update the shim boot loader.
samba (DLA 4692-1),
uploaded by Markus Koschany, to fix several security flaws in bullseye,
including issues that could yield to remote code execution.
imagemagick (DLA 4680-1
and DLA 4696-1),
prepared by Bastien Roucariès, addressing several issues that could lead to
denial of service, information disclosure or potentially arbitrary code
execution in some scenarios.
poppler (DLA 4709-1),
by Guilhem Moulin, fixing several vulnerabilities.
nss (DLA-4694-1),
by Jochen, fixing flaws that may result in or denial of service or
potentially the execution of arbitrary code.
Besides the work on security updates, different documentation and tooling
changes were needed, especially in the context of the Debian 12 handover. This
work was mainly done by
Sylvain Beucler.
As a Debian developer, I have had to cast a vote for the General Resolution named LLM usage in Debian (progress report here). This was not an easy task for me…
It’s a good thing that the vote is secret so that people are not scared of voting according to their own beliefs. I have Debian friends on the whole spectrum of opinions that are represented here, and I hesitated twice on sharing my own thoughts for fear of alienating my relationship with them. But in the end, we all make efforts to respect the opinions of those who are not thinking like us, and it’s precisely that willingness to work together towards a solution that is acceptable by the majority that makes Debian so strong. So here’s the train of thoughts that I followed to cast my vote.
The difficulty for me was to reconcile the political statement that I want to make and my desire for this vote to not be (too) divisive for the Debian community, and to make sure we are not putting off newcomers with choices that might be hard to stand by in the long term.
So let’s be clear : if I had a magical wand to make AI and LLM disappear, I would use it for that purpose, since at this point in time I don’t believe that the benefits outweigh the costs that the AI race is inflicting on us. If I were a political decision-maker, I would forbid the construction of new data centers unless they also build renewable energy infrastructure to cover for their additional energy consumption. I would also legislate so that AI companies have to document what material they used to train their models, and I would forbid scraping for that purpose, and build ways for those companies to buy copies of properly-sourced training data. That is to say, I don’t like the way LLM are built by the players in that market, I’m pretty scared of the ecological impact of what those players are doing, and I’m certainly worried about the long term effect that LLM will have on society as a whole.
Nevertheless what brought me to Debian is the ability to experiment and contribute to something useful with cool technologies, and as a computer scientist, the potential of LLM done right is hard to ignore. Given what we have seen already, I expect that LLM will empower (a part of) the next generation to learn IT, computing and even Debian packaging. Completely refusing the use of LLM is likely to make it harder for us to attract new contributors. In fact, we have already seen people inside Debian that would likely stop contributing if they are now forbidden to use LLM. I know there are likely others that will quit Debian if we accept it too, but I hope we can find a middle-ground where such persons can decide that LLM are not welcome in the small corner of Debian that they are in charge of…
In the end, I decided that answering clearly the question “Shall we accept LLM contributions ?” was more important than making the political statement about the current state of affairs in the AI landscape, both because I believe that Debian statements have a negligible impact on policy-makers, and because historically Debian has grown by staying close to technical excellence and relatively far from politics, except when it comes to the way we handle people. And as much as I care about climate change, I don’t see how bringing this up in the context of a Debian statement is helping its cause.
More concretely, it gives the following ranking (in decreasing order of importance):
B, D: those two choices are the clearest to express “Yes we should accept LLM contributions” and still acknowledge concerns about the way AI is built today
F, H: those two choices do not forbid LLM usage but discourage their use and clearly voice the concerns
E: this choice is basically the statu-quo and fails to acknowledge the concerns, but it does not forbid LLM usage
None of the above
G, A, C: those choices forbid LLM usage in various ways
I don’t know what option will win, but assuming that LLM-assisted contributions are allowed, I believe that it would be helpful to have further statements to clarify a few things:
Even if Debian as a whole doesn’t want to ban LLM-assisted contributions, each maintainer or each team shall be free to forbid LLM assisted contributions in the parts of Debian that they are maintaining
We should discourage usage of LLM provided by players with unethical behaviors (not sure if there are good players but well…)
I’m on a VPN setup with several friends that, obviously, includes a VoIP
network. I also have an old
magicJack adapter and a deep and
abiding need to use hardware in ways I should not. There was obvious synergy
here.
Plugging in the magicJack gives a USB vendor id of 0x06e6, which belonged to
a company called TigerJet who made a range of chips for hooking up phones to
computers, either via USB or PCI. Some more digging suggested that it was a
580 part, and someone had conveniently
uploaded
some reference code and datasheets, so figuring out how to talk to the chip
wasn’t terribly difficult. Once configured it simply sends HID events
whenever a user hits a phone key or changes the hook state, and otherwise
exposes a USB audio device that can be spoken to using the stock kernel
driver. It also has the ability to generate dial tone and assert ring
signal, giving a full traditional phone experience.
So you’d think this would be a super easy project, but I’d made things
harder for myself by deciding I wanted to tie directly into Asterisk rather
than just smashing an existing SIP stack onto the device. Asterisk uses
channels to
talk to devices, and channels end up as compiled C code that Asterisk can
load dynamically. I didn’t want to have to deal with the pain of compiling
stuff and matching ABIs and everything so writing a new channel from scratch
was unappealing. Fortunately, the websocket
channel
is available in recent versions of Asterisk and provides a convenient way to
get audio in and out, but that still leaves the job of handling incoming and
outgoing calls. That’s handled with the Asterisk Rest
Interface,
which can initiate a call or respond to an incoming one and bridge various
channels together to produce a bidirectional audio stream. There’s a
convenient async Python library that
handles the low level protocol.
Code for all this is
here1,
and works for my use case, but I should really abstract out the asterisk
side and the magicJack side to make it easier to adapt to other
devices. That’s a job for later, though. For now, you get this:
This has also been an excuse for me to figure out how to make Tangled work, which I’ll write about at some later point. But self-hosted git repo with a convenient collaboration plane! ↩︎
After ranting and railing about LLMs or "AI" as the optimists (or
accelerationists?) call it, I figured it might be important to
be a little more honest about my use of LLMs and how I think about it
more practically in the world.
The Debian vote context
This is not a coming out. I am not using LLMs on a daily basis, and
this blog is, again, written out of my cold dead hands in a dying
world, with over-engineered hardware and (to a certain extent, hi
Emacs!) software, powered by 100% green energy built on stolen land.
There is a vote going on in Debian. If you're unfamiliar with it,
you can catch up at LWN. So far I've essentially said "LLM is
bad" which is not a very balanced or useful opinion. Obviously, people
are using LLMs, sometimes unknowing or unwillingly, and we need to
take that into account. Furthermore, there has been many different
blog posts on Debian planet about this. Some that I found
balanced, good summaries, even if I didn't fully agreewith
them, at least some did the basic civil service of being
short. But others were just not only Wrong but also so long
that I couldn't finish that I just had to write something.1
This is not an explanation of the ballots, nor how I will vote. This
vote is Debian's failure of framing that debate in a reasonable way:
we have 8 options on the ballot with many duplicates. We have failed
to do the hard work of summarizing and aggregating options into a
meaningful set. I doubt the final vote will represent a readable
position we can rally around.
I have not read the twomonths of debates on the topic
either. Normally, before voting, I take a cursory look at the debate
to see points of view I might have missed. But in this case, it will
just make me sad, add noise, and I'm already pretty sure on where I
stand on this.
So let me describe how I use LLMs and how I think they fit in our
work, as computer engineers and hobbyists.
My LLM use
Debian Packaging
An astute reader has pointed out that I maintain a package in
Debian made to use Anthropic. It's actually multiple packages:
As I previously explained in response, I am not entirely
comfortable with this work: it's a compromise. In fact, I first
uploaded llm to the contrib section of Debian, where we keep
software that depends on other non-free software, but I was told that,
since yt-dlp was in main, llm belonged there as well.
An important part of my work is technology watch. I keep tabs on
thousands of (new and old) software projects, follow news, and
generally try to keep my skills up to date. It's a pretty impossible
race, especially as I grow older, but I still think I'm doing the
right choices in my job.
Testing large language models is part of that work. At first, I was
using ChatGPT's web interface, but it was annoying to copy-paste
things into a browser, so I looked for different interfaces.
For a while I tried gptel, a "simple, extensible LLM client for
Emacs" but I found it kind of terrifying. Giving a LLM control over an
Emacs buffer seems like a security nightmare, so I stopped doing
that.
So I use the llm command-line tool to talk to Anthropic's API. I
started that in the summer of 2025, when I bought 20$USD of API
credits. Before that, I paid for a ChatGPT subscription and then
OpenAI credits, which expired and sent me over to Anthropic, which
seemed then to have better ethics.
Needless to say, Anthropic and "Claude" are not my friends, but they
seem like the lesser evil in current "frontier models". So I have
renewed, a couple of weeks ago, another 20$USD of API credits with
Anthropic.
Actual prompts and responses
So what does 20$ give you at Anthropic anyways? What am I using LLMs
for and how?
The neat thing with llm is that everything is logged in a sqlite
database, so there are some answers that are easy to get:
> llm logs status
Logging is ON for all prompts
Found log database at /home/anarcat/.config/io.datasette.llm/logs.db
Number of threads logged: 7
Number of turns logged: 12
Number of legacy conversations: 543
Number of legacy responses: 970
Database file size: 9.61MB
That is 10MB of logs, with about a thousand prompts.
My logs go back to 2024-03-07, a little over two years ago, and
include a mix of Anthropic and OpenAI responses. I used it more in
2024 than 2025, and if the trend continues, I will have used it less
in 2026 again:
It looks like about 10 prompts per month right now, down from a peak
of about 60 per month in 2024. It's pretty difficult to analyze those
actual logs to get more patterns and I won't run the prompts through a
model again to process them.
How I'm using models now
At first, I was using it partly for benchmarking model's capabilities,
like Simon Willison does with his pelicans, clearly not trusting
its output. But I was impressed by the capacities of the Claude Opus
4.5 model when it wrote this script in January. Impressed, but
also scared: it's the first time I felt I could delegate the entirety
of my programming to a model. Just run the code, if it works, it
works, right?
So what do I use it now? As an example, here are the 10 last prompts
in my history:
there is now Claude 5, and a fable model, maybe you know about it?
impress me
not impressive, i already know all of this
chat
in postfix, i have a 300k mailing that happens regularly here. normally, it delivers within about...
is there a way i could have drained the maildrop queue faster without removing the milter?
the problem was that rspamd was timing out on the FUZZY_CALLBACK check. how do i disable that?
how do i disable all spam checks? i just want rspamd to add dkim signatures
how do the default_destination_concurrency_limit and initial_destination_concurrency settings int...
mic check
The first one was me trying to confirm which model I am using, which
is not always obvious when going through the whole llm stack I've
been using. The following two are an attempt at seeing what the model
is capable of and I was "not impressed", to which Claude answered that
I have a "high bar", which, fair enough.
The chat is me failing to use a command line, which shows that
perhaps I need to readjust that "high bar", again.
The next five are a rather embarrassing debacle in a large Postfix
mailing that went sideways, and where I couldn't find an actual
Postfix expert of my level to help. The fabled Claude Fable 5 answered
rather correctly, but dangerously, that I could empty the queue by
disabling the non_smtpd_milters. What Fable (and myself) did not
realize is that the milter was also adding DKIM signatures, so while the
mailing was expedited, it was done without those precious signatures,
which got us promptly blocked at Gmail. We have recovered since, and,
thanks to the model and reading the Postfix manual for the
hundredth time, that pickup(8) is single-threaded and that we
needed to review the architecture of that mailing (and our spam
filters) a bit. Many tickets ensued.
The last one is a test I did to make sure my last uploads of
llm-anthropic and its dependency worked correctly.
Note that the above excludes 5 questions I asked Anthropic while
writing this article, where I asked for synonyms and "what nanometer
scale are arduino processors built from? how is an arduino CPU
printed?", a question which Wikipedia furiously evades providing a
good answer.
Those prompts are pretty typical of my LLM use: I'm testing the models
to see if they work at all, but also, out of desperation, I fire off a
prompt after I fire off questions to colleagues or search engines (in
that order). It's often weird edge cases like the Prometheus query
language, Python's matplotlib, LaTeX, Elisp, optimizations, and so on.
I use models for translation a lot. Being fully bilingual, it is
common for me to think of a word in French or English and fail to find
exactly the right word for that in the other language. Models help
with that, and are also useful to find synonyms. Those are low-token
uses that seem pretty innocuous to me, but I realize the irony of this
after writing about the tower of
Babel.
What I am not using models for
I am not using models to write prose.
I am not using models to read prose. If it's generated with LLMs, I
stop reading.
I am not using models to write code, with the exception of that single
Python script above.
I am generally not using models to review code, with exceptions. If
I get stuck on a hard problem, I might feed a piece of code to the
model. I repeatedly fed asncounter into Claude to try to fix a
performance regression I had introduced. It found micro-optimizations
that taught me a thing or two about Python's internal implementations,
but overall, it was mostly a waste of time. This was in June 2025, so
perhaps now models would fare better. I have not tried again.
I am not using LLMs to do Debian packaging. When I can, I manually
review the diffs of packages I upload into Debian, still, by hand.
aggressive and illegal scraping of the servers I steward
world-wide computer hardware shortage (making it, by the way,
nearly impossible to run presumably clean local models) and the
attack on our job conditions (also discussed in
The people vs the AI overlords)
death of copyright and free software
complication and enshifitication of everything, and the
destruction of our communities
the imperialist Nerd Reich that wants to take over the world
Like I reluctantly use Intel computers, I do fire off a prompt. But
I still hold on to the dream that we can build communities of
practice that hold human knowledge collectively and not offload
that as a utility to some megalomaniac billionaire.
Their LLM use I am forced into
So that's me. Clearly, I'm going against the grain here. Everywhere I
look, I see LLM-generated code and projects. Slop and botnets have
flooded the web.
I use Wadamesh, clearly vibe-coded, because it's the best
graphical interface for MeshCore that runs on portable devices. I wish
it was made by a human, in a community I could participate in, but it
isn't, and I don't.
I package the above llm toolset, which is more and more
vibe-coded, but I still review the diffs. And I have to say: I
trust Simon here. The code is verbose as hell, feels overengineered,
and llm feels slow, but it generally works, and Simon is still at
the gate.
The Anthropic SDK is another thing entirely. The 0.91.0 to 0.120
upload, for example, was nuts:
I explicitly did not review that entire diff. It feels like there's a
lot of garbage there to just have a shim between a proprietary API and
Python. But this is the hand I've been dealt.
Larger projects LLM use
LLMs are being used in the Linux kernel, Firefox, rsync, Rust, and
other places. I don't feel good about this, particularly in Rust, but
they at least made a decent policy. I am glad GCC made a policy
against LLM contributions and I support the human Emacs
project.
We need to have a set of foundational tools that are "clean" in the
sense that they are built upon a community of people that understand
how they are built.
Maybe that's naive or even impossible. The Linux kernel and GCC, in
particular, are massive projects that have long grown past the scale
of a single person's understanding. But the theory was that a
community of humans can understand collectively.
Now we seem to be throwing up our hands and giving up on
that community. That LLMs will just fix the problem, whatever it
is. But we're all just one rug pull away from being completely
incapable of managing those projects. The argument there is that we'll
just switch to local models, but no one is actually doing that.
All I see is people use local models as a corner case
(for privacy) or as in theory, but in reality, everyone uses the
centralized frontier models right now. We just can't fallback.
We're in the same situation we were, a decade or two ago, when
Microsoft decided it would kill free office alternatives by making
Office free for non-profits. It worked: thousands, if not millions of
schools, community groups and individuals stopped looking for
alternatives (including free software but also "piracy") for Office
and embraced what seemed like a generous offer.
I'm afraid the rug pull on LLMs will be much worse: never mind that
Linus won't be able to use his tireless helper to fix obscure kernel
bugs; we're looking at a collapse of the economy so large that we are
already talking about bailing out the companies responsible.
In a sense, the most striking thing about the Debian vote is it has
actually no option to completely refuse upstream LLM contributions. It
seems the community has taken it for granted that it's now impossible
to build Debian entirely without LLMs. We lost the battle even without
a fight, it seems.
A plea for small
If it has really become impossible for us to manage the complexity we
have built, maybe it's time to stop and think about what we're doing
in the first place. We're struggling to even bootstrap our
current toolchain!
This is one of the things I like the most about working on the mesh:
it's low tech, small Arduino devices that is built with decades-old
semiconductor processes that is understandable by human
beings.
Maybe the answer lies more in single-purpose devices like those
communicators and simpler multi-purpose computers than what we have
now, which is what the permacomputing movement is about.
Small is beautiful, let's scale it down.
and yes, I'm sorry this has gotten this long, I hope you will
forgive those 3000 words.↩
I like this line: “Success is measured in operational advantage delivered, not technology demonstrated.” To me it recalls “Working software is the primary measure of progress” from Principles behind the Agile Manifesto – if you understand “working” to mean “working in production”. Which I do.
For anyone interested in suggesting ideas to the taskforce, the four
operational challenge areas include:
Machine assistance for handling and interpreting huge volumes of data
would probably benefit decision advantage and interpretation of a
crowded EM spectrum, but this is hopefully(?) more than just LLMs. Of
course, there’s more to AI than large language models… right?
I worry that “planning and automation” might amount to “generating
large amounts of
text
faster”. Nothing could possibly go wrong with this.
Another minor routine update 0.0.6 of gettz arrived on CRAN just now.
gettz provides a
possible fallback in situations where Sys.timezone() fails
to determine the system timezone. That happened when e.g. the
file /etc/localtime somehow is not a link into the
corresponding file with zoneinfo data in,
say, /usr/share/zoneinfo. Since the package was written (in
the fall of 2016), R added a similar extended heuristic approach itself
making the package a little less relevant.
This release reflects several rounds of updates to the continuous
integration setup, some URL updates, as well as some updates to
packaging including use of Authors@R in DESCRIPTION. As with the
previous releses: No functional changes, no new code, or new
features.
In 2025 I was honored to be selected for the first cohort of Sovereign Tech Fellows, a program by Germany’s Sovereign Tech Agency to improve the resilience of the open source ecosystem by supporting maintainers directly (complementing their existing support for larger FOSS organizations). Back in 2025, I was only working very limited hours – however, this has changed in 2026.
For the second half of 2026, I am working again as a Sovereign Tech Fellow, but this time with significantly increased hours. After finishing my PhD, I do have time now for new tasks (and new jobs!), and the fellowship presents an amazing opportunity to really advance projects that I maintain or am part of. This also has a very nice effect on contributors and bug reporters, as their feedback gets addressed a lot faster. With some luck, this ultimately will help finding new (co)maintainers for projects as well (although in the age of AI, a lot of how open source used to work is much more uncertain, but that is a matter for a different blog post).
The fellowship is time-limited, so I am intending to make the time I currently have count!
So, what’s planned?
I am involved in many projects, but three of them will be getting attention as part of the fellowship. I know I am notoriously slow at blogging, but expect more details on each of them very soon. Here’s an overview:
Freedesktop.org, Specifications and Organization
I maintain the Freedesktop Specifications, which is an area of Freedesktop that has traditionally been a bit chaotic. This “worked” in the past, because Freedesktop was never intended to be a formal standards body, but more a shared space where people could throw a lot of code and ideas over the wall and see what sticks and what people can collaborate on.
While I very much love the spirit of this and want to keep it in some form, we definitely would benefit not just from more formalization and better procedures, but also from better organization of the specifications in general. A lot of conflicts can be avoided by that. I will work on improving procedures, crunching through the (lots!) of pending bug reports and MRs, and to make the specifications site better searchable and accessible (similar to how Mozilla’s MDN presents information, but I am not sure if we will get quite that far). I also intent to add a compatibility matrix for specifications, so if a desktop opts out of any one of them (or does not implement them yet) that fact is documented and authors of applications know what they can expect. This will allow us to move a lot faster and avoid a lot of conflict, because there is no implicit assumption that “everybody will implement everything” anymore (which has never been quite true anyway).
Hopefully, this will ultimately result in a Freedesktop that is both a lot more useful for application authors who want to bring their project to Linux, as well as developers of desktop environments who need to see which specifications are available and which ones are current.
In addition to that, I have also worked on a Freedesktop.org website refresh, which is pretty much done in its first iteration (pending sysadmin action). The aim there is to have a more official website, separate from user-contributed wiki content, that showcases what Freedesktop is and which projects are using it for hosting. Once the new website is live, I will also review every page again, archive dead projects in their own section and reorganize the software and specifications directory. Those sections are severely outdated and are missing recent efforts from the community, while still containing long-dead old projects (remember HAL? ).
AppStream
A lot of extra maintenance work will be (has been!) done on it. This includes things such as JPEG-XL support (blog post soon), sandboxed media processing, support for newer specification additions, better OARS integration (and potentially migrating it to fd.o infrastructure), improvements and API stabilization for libappstream-compose and a lot of bugfixing and resolution of issues found by AI code review.
AppStream was originally designed to parse only trusted data from vetted Linux distribution sources – this is no longer the case in today’s world and in the way Flatpak uses it, so we need to increase resilience of the project.
I am also exploring a project that could vastly improve search accuracy for AppStream. Stay tuned for that.
PackageKit & System Upgrades
Many years ago, people thought we would all migrate to atomic Linux distributions and slowly not need PackageKit anymore. This has not turned out to be the case, and there are still plenty of reasons to use a package-based OS, especially in development environments. At the same time, PackageKit has been basically the same for years, and its older architecture is beginning to show. It being a daemon who’s literal job it is to modify the entire system also makes it one of the most security-sensitive components that a Linux system can have, while simultaneously making it near-impossible to sandbox.
My plan is to create PackageKit 2.0 by building on the great foundation of PackageKit 1.0, but modernizing it. This will include simplifying its code and removing a bunch of features that have no more use in modern desktops, while also adding some features that PackageKit never had but that would be useful to expose to frontends (still no to interactivity an terminal-progress forwarding though!). PK 2.0 will also allow me to solve a few design issues that have been worked around in the past, by replacing them with better solutions. This will be a painful transition, as PackageKit 2.0 will break all interfaces PackageKit has – and those interfaces have been frozen for more than a decade. However, I do fully expect this change to be worth the effort.
In addition to that, I intend to look into the offline-update procedure again and improve it. The current multi-reboot operation comes with downsides, that newer systemd features such as soft-reboot can alleviate. The end result should be a much smoother, less annoying offline-update experience for users (I especially want to get rid of updates running on system startup, which I consider quite bad from a usability perspective). The new behavior is in the early drafting stages and may need direct support from systemd. I will share more about it once I can.
That’s a lot of tasks!
Yes! I will see how far I get. I am moving project-by-project though, to allow me to focus on one project at a time, rather than scattering my attention continuously. Amazingly, this means that the major tasks for AppStream are already almost done, and we are nearing the 1.2.0 release. AppStream got priority, because the new Freedesktop Flatpak runtime will be released soon, and because I want FlatHub/Flatpak to have access to the new AppStream release sooner. Freedesktop and PackageKit are next on the task list.
Either way, a lot of progress is coming – if you have any feedback or want to help out, please don’t hesitate to reach out! All work is happening fully in the open, so you can also chime in on the respective GitHub/GitLab tasks .
You can also expect blog posts about key features or interesting changes, so stay tuned!
A new release of gaussfacts package
arrived on CRAN – the first in
pretty much exactly a decade! gaussfacts
provides a fortunes-inspired
function to display randomly-chosen facts about Carl Friedrich
Gauss, based on the collection curated by Mike Cavers via the gaussfacts web site (with an archive.org link
it case it vanishes again). Each call of gaussfact()
displays another (randomly chosen, or indexed) fact.
An example:
> gaussfacts::gaussfact(9)Gauss once played himself in a zero-sum game and won $50.>
This releases, as detailed below, accumulates a number of smaller
maintenance changes including switching to Authors@R. Functionality has
not changed. Oddly enough, it appears that I did not blog about the
package when I created it in August 2016. So to (partially) make up for
that, the NEWS for all three releases follow.
Changes in version 0.0.3
(2026-08-23)
Several rounds of continuous integration maintenance and
enhancements
Additional README.md badges
Updates to DESCRIPTION as CRAN requirements change
A duplicate data entry has been removed (Tim Pokart in #4)
Documentation prefers https URLs
Updated continunous integration multiple times
Correct man page removing an erroneous duplicate word
Changes in version 0.0.2
(2016-08-03)
Support 'ind' argument to reference by position
Clean-up encoding and support extended character set (#2 closes
#1)
This post contains interactive examples. To visualize and interact
with them, you need to leave your RSS reader.
Imagine you rent office space for a three-day event. You quickly set up a few
Ethernet switches and tape some cables on the floor to get everyone online.
Unfortunately, Stan, your clumsiest coworker, kicks out a cable every time he
gets up for coffee. You could add extra cables, but then you’d get a broadcast
storm: Ethernet packets that loop and multiply until nothing else gets through.
That’s where the spanning tree protocol (STP) comes in. STP blocks just enough
of your spare cables to leave a loop-free tree. When Stan strikes again, it
rebuilds the tree in a second, leaving some time for Blobby, your one-person
support crew, to reconnect the cable.1 See for yourself: the diagram
below runs a real STP implementation in your browser!
:demo
A1 @0,0 prio=4096
A2 @0,1
A3 @0,2
A4 @0,3
B1 @1,0 prio=8192
B2 @1,1
B3 @1,2
B4 @1,3
C1 @2,0 prio=8192
C2 @2,1
C3 @2,2
C4 @2,3
A1 -- A2 hazard=0
A2 -- A3 hazard=0
A3 -- A4 hazard=0
B1 -- B2
B2 -- B3
B3 -- B4
C1 -- C2 hazard=0
C2 -- C3 hazard=0
C3 -- C4 hazard=0
A1 -- B1 cost=10
B1 -- C1 cost=10
A4 -- B4 cost=20
B4 -- C4 cost=20
Leo @-0.3,0.7 proto=none icon=👦🏻
Mia @-0.3,1.3 proto=none icon=👧🏽
Joy @0.3,0.7 proto=none icon=👱🏻♀️
Roy @0.3,1.3 proto=none icon=👨🏾
A2 -- Leo hazard=0 A2:edge
A2 -- Mia hazard=0 A2:edge
A2 -- Joy hazard=0 A2:edge
A2 -- Roy hazard=0 A2:edge
Max @-0.3,1.7 proto=none icon=👨🏽
Zoe @-0.3,2.3 proto=none icon=👩🏾
Ada @0.3,1.7 proto=none icon=👵🏾
Amy @0.3,2.3 proto=none icon=👩🏼
A3 -- Max hazard=0 A3:edge
A3 -- Zoe hazard=0 A3:edge
A3 -- Ada hazard=0 A3:edge
A3 -- Amy hazard=0 A3:edge
Eli @0.7,0.7 proto=none icon=👦🏼
Jay @0.7,1.3 proto=none icon=👨🏻
Kai @1.3,0.7 proto=none icon=🧑🏽
Ben @1.3,1.3 proto=none icon=👱🏼
B2 -- Eli hazard=0.2 B2:edge
B2 -- Jay hazard=0.2 B2:edge
B2 -- Kai hazard=0.2 B2:edge
B2 -- Ben hazard=0.2 B2:edge
Ava @0.7,1.7 proto=none icon=👩🏻
Lea @0.7,2.3 proto=none icon=🧑🏾🦱
Ivy @1.3,1.7 proto=none icon=🧕🏽
Rex @1.3,2.3 proto=none icon=👴🏿
B3 -- Ava hazard=0.2 B3:edge
B3 -- Lea hazard=0.2 B3:edge
B3 -- Ivy hazard=0.2 B3:edge
B3 -- Rex hazard=0.2 B3:edge
Ana @1.7,0.7 proto=none icon=👩🏿
Eve @1.7,1.3 proto=none icon=👧🏼
Abe @2.3,0.7 proto=none icon=🧓🏿
Ian @2.3,1.3 proto=none icon=🧔🏾
C2 -- Ana hazard=0 C2:edge
C2 -- Eve hazard=0 C2:edge
C2 -- Abe hazard=0 C2:edge
C2 -- Ian hazard=0 C2:edge
Ned @1.7,1.7 proto=none icon=👨🏼🦳
Lou @1.7,2.3 proto=none icon=🧑🏿
Fay @2.3,1.7 proto=none icon=👧🏻
Sue @2.3,2.3 proto=none icon=👩🏽🦰
C3 -- Ned hazard=0 C3:edge
C3 -- Lou hazard=0 C3:edge
C3 -- Fay hazard=0 C3:edge
C3 -- Sue hazard=0 C3:edge
Note
This article is also available as a video, but I advise you to
keep reading here to try the interactive demonstrations.
Designed in the ’80s, the spanning tree protocol has evolved into a “rapid”
flavor (RSTP) and a “VLAN-aware” variation (MSTP).2 Any sound-minded
network engineer knows there are better alternatives, like BGP EVPN VXLAN.
Yet, because any switch speaks it, the venerable spanning tree protocol still
fills a niche.
We focus on RSTP: it replaced the original protocol in 2004. To eliminate
network loops, RSTP implements a complex state machine. Timers, link state
changes, and the link-local control frames a bridge receives from its neighbors
drive its transitions. These Ethernet frames are the Bridge Protocol Data
Units (BPDUs). You can watch them in action below: hit the “Start” button.
After some time, the topology converges to a tree: from the root
C11, there is a path to each bridge3 and no loop. In the upper right
corner, the interface displays a tree icon 🌳 followed by the time it took to
reach this state. Cut a link and see how the protocol
finds an alternate path to reach C12 in less than a second. You can stop the
simulation, move it forward step by step, reset it to its initial state, or slow
it down with the “snail” mode 🐌. Don’t worry about all the displayed
information: I explain it later.
All examples run in your browser, powered by MSTPD—an open-source
user-space4 implementation of RSTP.5
I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial property
Is loop-free connectivity.
A tree which must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.
To build a tree, RSTP first elects the bridge with the lowest bridge
identifier as the root bridge. The bridge identifier combines the priority
and the MAC address: 8192.6e:2b:10:a0:5f:29.
In the example below, S1 and S2 have priorities of 4,096 and 8,192: S1 becomes
root. S4 has a priority of 12,288, while S3 keeps the default priority of
32,768:6 S4 becomes root. S5 and S6 don’t have a specific priority, so
the lowest MAC address wins and S5 becomes root.
Each non-root bridge chooses its root port, the one with the lowest-cost
path to the root. Unless you override it, each bridge derives the link cost
from the speed: 20,000 for 1 Gbps. In case of equality, the lowest port
identifier wins.
Each remaining port becomes a designated port if the BPDU it sends is
“better” than the BPDU it receives. Otherwise, it becomes an alternate port.
Later, if the root port goes down, the “best” alternate port becomes the new
root port. The tiebreakers for the best BPDU are:
In the example above, after convergence, S1 is the root bridge
because it has a priority of 4,096, while the other bridges have a priority of
32,768. All its ports are designated ports because the accumulated cost to the
root is 0.
S2’s port facing S1 becomes a root port because it has the lowest accumulated
cost to the root—20,000 vs 40,000. S3 has two ports facing S1, and the one with
the lowest port identifier becomes the root port—0x8000 vs 0x8001. The other
candidate is an alternate port because the remote port on the link sends a
better BPDU, with an accumulated cost of 0. On the segment between S2 and S3,
S2’s port wins: while both bridges have the same accumulated cost to the root
(20,000), S2’s bridge identifier is smaller—32768.02:00:00:00:00:01 vs
32768.02:00:00:00:00:02.
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 20000
Bridge Identifier: 32768.02:00:00:00:00:01
Port identifier: 0x8002
Unless a specific event happens, designated ports send BPDUs every 2
seconds.9 If a bridge does not
receive BPDUs from its neighbor for 3 consecutive hello periods, it considers
the neighbor dead and removes the port information.
Port state transition
Each port can have one of three states. The diagram displays a background color
for each state:
discarding (red),
learning (yellow), or
forwarding (green).
A root port transitions automatically to the forwarding state. An alternate
port stays in the discarding state. A designated port has two options to
transition from the discarding state to the forwarding state:
If the port is an edge port, either through configuration or because the
remote device does not speak any flavor of STP, the bridge assumes it won’t
participate in the protocol and cannot create a loop. In this case, the
designated port immediately transitions to the forwarding state.
Otherwise, it sends a proposal to its downstream neighbor. If the remote
bridge agrees that the received BPDU is “better” than any other BPDU stored
for other ports, it elects the receiving port as its root port and starts the
synchronization process: it transitions all non-edge non-synced designated
ports to the discarding state to avoid a loop. Then, it sends back an
agreement. Upon receiving the agreement, the peer designated port
transitions to the forwarding state.10
In the topology above, H1, H2, H3, and H4 are end devices not participating in
the protocol. We configure the ports they connect to as edge ports, so these
ports immediately move to the forwarding state.
Use the “step” button to move the simulation forward. The clock moves to 1
second. Step again and S1 and S2 send a proposal to
each other. Here is the proposal from S2:
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x4e, Agreement, Port Role: Designated, Proposal
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..0. .... = Forwarding: No
...0 .... = Learning: No
.... 11.. = Port Role: Designated (3).... ..1. = Proposal: Yes
.... ...0 = Topology Change: No
Root Identifier: 32768.02:00:00:00:00:01
Root Path Cost: 0
Bridge Identifier: 32768.02:00:00:00:00:01
Port identifier: 0x8001
S1 ignores it: its own root identifier is lower. When S2 receives a similar
proposal from S1, it accepts S1 as its root bridge. It also elects the port to
S1 as the root port and starts the synchronization process. The two designated
ports are already discarding, so no change here. Step
again and S2 sends two BPDUs to S1. In one of them, the
agreement bit is 1 and the proposal bit is 0. It also shows that S2 accepted S1
as the root bridge and its root port is now in the forwarding state. When
receiving this BPDU, S1 transitions its own designated port to the forwarding
state. From this point, the link between S1 and S2 forwards user traffic.
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x79, Agreement, Forwarding, Learning, Port Role: Root, Topology Change
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..1. .... = Forwarding: Yes
...1 .... = Learning: Yes
.... 10.. = Port Role: Root (2).... ..0. = Proposal: No
.... ...1 = Topology Change: Yes
Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 20000
Bridge Identifier: 32768.02:00:00:00:00:01
Port identifier: 0x8001
Let’s look at what happened to S5. Reset the simulation and step
twice. S5 exchanges BPDUs with both S3
and S6. Since S5 has a lower root identifier than S3 and S6, it stays the root
bridge, while S3 and S6 accept the proposal and elect their root ports. S3 and
S6 start the synchronization process. S6’s port to H4 stays up because this is
an edge port. Move one step. Both S3 and S6 send
an agreement back to S5, which transitions both designated ports to the
forwarding state. Yet, the link between S5 and S3 keeps discarding user traffic!
If you look carefully, S3’s port toward S5 is now a designated port, not a root
port. During the same step, S3 also receives a better BPDU
from S2 with S1 as the root bridge. It elects its port to S2 as the root port
and downgrades the port to S5 to a designated port, which stays in the
discarding state.
On the next step, things get a bit tricky. S3 sends a
proposal to S5:11
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x4f, Agreement, Port Role: Designated, Proposal, Topology Change
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..0. .... = Forwarding: No
...0 .... = Learning: No
.... 11.. = Port Role: Designated (3).... ..1. = Proposal: Yes
.... ...1 = Topology Change: Yes
Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 40000
Bridge Identifier: 32768.02:00:00:00:00:02
Port identifier: 0x8002
S5 elects S1 as its root bridge and the port toward S3 as its root port. It
starts its synchronization process, but the designated port to S6 does not
move into the discarding state. Why? That port stays a designated port and its
neighbor S6 had already sent an agreement on the link, so the port keeps its
synced status.
Now, let’s step back to look at what happens to S6. At this point,
S6 believes S5 is the root bridge. Step once and S4 sends
a new proposal to S6. S6 accepts the proposal, elects S1 as the root bridge and
the port to S4 as its root port. The role of the port facing S5 changes: from a
root port, it becomes a designated port. Because its peer keeps advertising an
inferior BPDU on the link, this port becomes disputed and moves to the
discarding state. The root port transitions to the forwarding state and the link
starts forwarding immediately because S4’s designated port is already in the
forwarding state. If we step one more time, S5 and S6
exchange two BPDUs. The one from S5 is better because of its lower bridge
identifier. S5’s port stays a designated port, while S6 downgrades its own port
to an alternate port.
Let’s rewind one last time from the start: cut the link between S1 and S2, run
the simulation until the topology is stable, stop the
simulation, and restore the link between S1 and S2. During the first
step, S1 and S2 exchange proposals. S2
elects S1 as the root bridge instead of S5 and the port to S1 as the root port.
It downgrades the previous root port to a designated port and moves it into the
discarding state. The other designated port stays synced and keeps its
forwarding state. At the next step, S2 sends
an agreement to S1 and the link between them starts forwarding user traffic. It
also sends a proposal to S3, but not to S4.
Instead, it sends a regular BPDU to S4. S4
still elects S1 as its root bridge and the port to S2 as its root port. It
demotes its previous root port, the one to S3, to a designated port, which
transitions to the discarding state because of the root port change. The other
alternate port, to S6, also becomes a designated port and stays in the
discarding state. The new root port moves to the forwarding state. On the next
step, S4’s port to S3 settles as an
alternate port after receiving a “better” BPDU from S3.
RSTP is a giant state machine split into smaller ones: bridge detection, port
information, port protocol migration, port role selection, port role
transitions, port receive, port state transitions, port timers, port transmit,
and topology change. Some of them are per bridge, some per port. Each bridge
runs an instance. Time, operational port state changes, and the BPDUs it
receives from other instances drive the transitions. Being event-driven makes
RSTP more efficient but also more difficult to understand.
Placeholder for the Port Information state machine extracted from IEEE 802.1Q-2005, page 182. Pending IEEE authorization for reproduction, this is the blueprint for the Western Australian Government Railways class Msa Garratt articulated steam locomotive.
Topology change notification
A bridge populates a MAC address table: it associates each source MAC address
with the port that last received it. When forwarding an Ethernet frame, it looks
up this table to choose the right port.12 When a link fails, a connected
fridge reachable through one port may become reachable through another one. The
affected bridges should flush the MAC addresses they learned, because these
entries may now be wrong.
For this purpose, RSTP implements topology change notifications using a
flooding mechanism. When a non-edge port transitions to the forwarding state, a
bridge generates BPDUs with the topology change (TC) bit set. It sends them to
all the non-edge designated ports and to the root port. It also flushes the MAC
address table on these ports. When a bridge receives such a BPDU, it propagates
the notification to all non-edge designated ports and the root port, except the
one the notification came from. It also flushes the MAC address table on these
ports. In the examples, the BPDUs with the TC bit set to 1 have a red circle.
Start the simulation and wait a few seconds for the topology to
settle. Stop the simulation and disable the link between S2 and
S5. S5 elects the port facing S4 as the root port, which
transitions immediately to the forwarding state. Step
once and S5 emits a BPDU with the TC bit set to 1:
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x79, Agreement, Forwarding, Learning, Port Role: Root, Topology Change
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..1. .... = Forwarding: Yes
...1 .... = Learning: Yes
.... 10.. = Port Role: Root (2).... ..0. = Proposal: No
.... ...1 = Topology Change: Yes
Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 40000
Bridge Identifier: 32768.02:00:00:00:00:04
Port identifier: 0x8002
S4 receives this BPDU. It flushes the MAC address table on the port facing S1:
while LPT was previously reachable through this port, it is now reachable
through S5 instead. Step once. S4 sends S1 a BPDU
with the TC bit set to 1. When S1 receives this BPDU, it flushes the MAC address
table on the ports facing S2 and S3. Step
once and S1 sends a notification to S2 and
S3. Step once again and S2 sends a notification to
S3, while S3 does nothing because the port toward S2 is an alternate port. S3
does not flush any MAC address table: LPT is still reachable through its port to
S1.
If you step a bit more, you will see that some of the
periodic BPDUs keep the TC bit set to 1. Each port runs a timer equal to the
hello timer plus one second.13 The timer starts when the port emits a
notification. Until it expires, the port sets the TC bit to 1 in every BPDU it
sends. You can also see some periodic BPDUs
without the TC bit: they originate from a port that only received a notification
and therefore did not arm its timer.
Security
RSTP is weak against configuration errors and malicious actors. A bridge not
talking RSTP can create a loop. An attacker can insert themselves into the
topology to disrupt the service, spy on the traffic, or alter it.
To mitigate such problems, you need to identify the edge ports. An edge port
connects to an end device, like a PC or a printer. Such devices do not generate
BPDUs and cannot create a loop. RSTP defines two related flags:
When true, AdminEdge initializes a port as an edge port. It defaults to
false.
When true, AutoEdge lets a port become an edge port when it does not
receive BPDUs for 3 seconds. It defaults to true.
If an edge port receives a BPDU, regardless of the values of these two flags, it
reverts to a non-edge port.
In the topology above, S1, S2, S3, S4, S5, and S6 act as bridges, while H1, H2,
H3, H4, H5, and H6 act as end devices:
S1 and H1 are on a port without a specific configuration: AutoEdge is true,
AdminEdge is false,
S2 and H2 are on a port where AdminEdge is true,
S3 and H3 are on a port where AutoEdge is false and AdminEdge is true,
S4 and H4 are on a port where AutoEdge is false.
If you start the topology and wait about 20 seconds, links to S1,
S2, S3, S4, H1, H2, H3, and H4 eventually forward user traffic: none of the
flags matter.
But what about the two remaining pairs? S5 and H5 connect to a network port.
Such a port enables a non-standard feature: bridge assurance. The port
transmits BPDUs regardless of its role. If it does not receive BPDUs for 3
consecutive hello periods, it transitions to the discarding state. On the link
between R0 and S5, you can see BPDUs traveling in both
directions, unlike the other links, where only
designated ports send BPDUs.
S6 and H6 connect to a port where AdminEdge is true and BPDU guard is
enabled. This is another non-standard feature that shuts down a port if it
receives a BPDU.
In summary, if you expect a port to be an edge port, you should set AdminEdge
to true and enable BPDU guard. Otherwise, declare it as a network port.
Why RSTP today?
A compelling use case for RSTP today is an out-of-band network for a datacenter,
since you can tolerate an outage of a few seconds. The configuration is minimal
and you can use cheap switches, like a Cisco 2960X.14 You need two
switches acting as root bridges, and you build several loops to connect OOB
switches in each cabinet. This simple design survives one failure on each
loop.15
This topology converges in about 6 seconds. Each loop should stay
small (around 16 bridges) to reduce the probability of a double failure and to
avoid sharing too much bandwidth. The design can evolve a bit without adding too
much complexity: one VLAN per loop or one bridge domain per loop.
How large can a network be?
The maximum age, whose default value is 20, governs the maximum distance of a
node from the root. The topology below is too big for BPDUs from R1 to reach
beyond S20.16
Once the topology settles, part of the network considers R1 the
root, while the other votes for R2. At the boundary, S20 tries to start a
synchronization with S21 to move its designated port to the forwarding state.
The BPDU looks like this:
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x4e, Agreement, Port Role: Designated, Proposal
Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 400000
Bridge Identifier: 32768.02:00:00:00:00:15
Port identifier: 0x8002
Message Age: 20
Max Age: 20
S21 rejects it because the message age equals the maximum age. On the other
hand, the BPDU S21 sends to S20 looks like this:
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x7c, Agreement, Forwarding, Learning, Port Role: Designated
Root Identifier: 4096.02:00:00:00:00:01
Root Path Cost: 320000
Bridge Identifier: 32768.02:00:00:00:00:16
Port identifier: 0x8001
Message Age: 16
Max Age: 20
This is not enough to change S20’s root port because S20 has a lower root
identifier—4096.02:00:00:00:00:00 vs 4096.02:00:00:00:00:01.
Fixing the link between R1 and R2 resolves the issue. The
maximum message age any packet carries is now 18, below the configured maximum
age. But it only works until another link breaks. A plausible fix is to increase
the maximum age to 40.17
How fast is RSTP?
RSTP usually converges in a couple of seconds at startup. It often repairs a
tree in less than a second. Even the 38-bridge topology takes less than 10
seconds to converge.18 Some topologies can take a bit more time to recover
when the root bridge becomes unavailable.19
First, S1 loses its root port. It has no more information about R0 and elects
itself as the root bridge. It keeps its ports to S2 and S3 as designated ports
in the forwarding state. Step once and it
sends a BPDU to both S2 and S3 to let them know about the root change. When
receiving it, S2 accepts S1 as its root because it does not have a better root
on another port. It elects the port to S1 as its root port. The other port stays
a designated port. Both ports keep forwarding.
When receiving the BPDU from S1, S3 behaves differently: it knows R0 as a better
root than S1 through its alternate port to S2. It promotes this port to a root
port and demotes the port facing S1 to a designated port, which requires a new
agreement. Step once and S3 sends a proposal to
S1 with R0 as the root bridge. S1 elects R0 as the root bridge and promotes its
port to S3 as a root port.
During the same step, S3 also receives a BPDU from
S2 stating that S1 is the root bridge. Therefore, S3 has no port left with R0 as
the root bridge: it elects S1 as the root bridge and its port to S2 as the root
port. Step once and its next BPDU to S1 includes
this information: S1 elects itself again as the root bridge. But during the
same wave, S1 sends a proposal to S2 with R0 as
the root bridge. While S1 and S3 agree that S1 is the root bridge, S2 now
believes this is R0! In turn, S2 again convinces S3
that R0 is the root bridge, S3 convinces S1, S1 convinces S2, and S2 convinces
S3.
This could go on forever, but it does not. The BPDUs saying “R0 is root”
eventually age out when the message age goes past the maximum age. In the
example above, at the eleventh second, S2 sends a
BPDU to S3 with R0 as root, but S3 drops it because its message age reached the
maximum. With some luck, the topology can also converge faster if a port stops
transmitting new BPDUs after tripping the transmit hold count, whose default
value is 6 per second.
About MSTP
MSTP is the “VLAN-aware” version of RSTP: it runs several instances of RSTP and
lets the administrator map each VLAN to a specific instance. For example, you
can map VLANs 100 to 200 to a first instance, and 300 to 400 to a second
instance. The remaining VLANs map to a special instance named the Internal
Spanning Tree (IST). MSTP adds its own complexity, but the gist is that you have
several logical topologies acting independently. If you want to dig deeper, have
a look at “MSTP Tutorial Part I: Inside a Region.”
About the interactive examples
The interactive examples run MSTPD directly in your browser, compiled to
WebAssembly with emscripten. A C API replaces the code talking to the
Linux kernel: it manages bridges and ports, exports state as JSON, and drives
time deterministically. A JavaScript wrapper makes it more user-friendly:
import{loadMSTPD}from"./dist/mstpd.mjs";constmstp=awaitloadMSTPD();// Create 3 bridgesconsta=mstp.createBridge("A",{priority:4096});constb=mstp.createBridge("B",{priority:8192});constc=mstp.createBridge("C");// Each bridge has two portsconsta1=a.addPort("a-b",{portno:1});consta2=a.addPort("a-c",{portno:2});constb1=b.addPort("b-a",{portno:1});constb2=b.addPort("b-c",{portno:2});constc1=c.addPort("c-a",{portno:1});constc2=c.addPort("c-b",{portno:2});// Build a triangle topologymstp.link(a1,b1);mstp.link(a2,c1);mstp.link(b2,c2);// Enable all bridges and portsfor(constbrof[a,b,c])br.enable();for(constpof[a1,a2,b1,b2,c1,c2])p.enable();// Execute 40 seconds' worth of wall clock and display the topologymstp.step(40);console.log("Topology:",mstp.topology());
Several dozen unit tests explore the features of MSTPD and check that they work
correctly in this environment:
$ node--test*.test.mjs
✔ two bridges: lower priority becomes root (41.657342ms)✔ triangle loop: exactly one port blocks and all agree on the root (5.832ms)✔ breaking the active link reconverges and restoring recovers (18.730753ms)[…]ℹ tests 40ℹ pass 40ℹ fail 0[…]ℹ duration_ms 396.190897
Additional JavaScript code looks for specific <pre> blocks containing a
topology definition and turns them into the interactive widget. You can inspect
and modify the definition by hitting the “edit” button.
There is also a cool trick to tell whether the topology has converged. After
each step, we save a snapshot of the simulation memory, play 50 seconds’ worth
of simulation to check if the topology is stable, and travel back in time by
restoring that snapshot. 🕰️
The complete code lives on GitHub. I am happy with the result. It can be
difficult to follow everything happening during a single step, but stepping
forward and backward helps. I plan to use the same approach in future blog posts
about networking features.
Note
Michael Lynch reviewed a first draft of this article. He authored
“Refactoring English,” a book to sharpen your writing for blog posts,
documentation, commit messages, and tutorials. Any errors are still mine!
The sprites for Stan and Blobby come from Craftpix, the coffee
cups from Yanin. ↩
The priority is a multiple of 4,096: with MSTP, the lower 12 bits
of the bridge priority encode the MST instance identifier, leaving only the
upper 4 bits for the configured priority. ↩
To inspect the BPDUs crossing a link, select it, click the
“Download packets” button, and open the file with Wireshark. ↩
A backup port only exists if the bridge has several ports on the same
collision domain. This should not happen in a switched network. ↩
This is the value of the “hello” timer. It used to be configurable,
but IEEE 802.1Q-2005 pins it to 2. MSTPD does not allow another value. ↩
If the peer port does not receive an agreement after the hello
timer elapses—or the maximum age if the port has just come up—it falls back
to the timer-based method for compatibility with STP: it transitions to
the learning state, waits again for the hello timer to expire, and
transitions to the forwarding state. ↩
As in many proposals, S3 also sets the agreement bit to 1. The
proposal bit says “I am the designated port on this link and I want to
transition to the forwarding state.” The agreement bit says “I am already in
sync with the rest of my bridge on this root information.” Both can be true. ↩
If it finds no entry, the bridge duplicates the Ethernet frame on all
ports, except the incoming one. The same happens if the destination MAC
address is the broadcast one (ff:ff:ff:ff:ff:ff). This behavior bootstraps
the learning process. ↩
If you look closely at what happens at t=2s, you can see that R2 is
gaining popularity as root: S17 to S36 believe R2 is the root bridge. S16
does not follow because we hit the maximum age. Later, S17 to S20 reverse
their position. I’ll let you explore the state of the various bridges to
understand the root cause. ↩
When increasing the maximum age to 40, you also need to
increase the forward delay to 21 (:forward-delay 21), as the standard
enforces this condition: 2 × (Forward Delay − 1) ≥ Max Age. For this
specific topology, you could also increase the maximum age to 37 and
forward-delay to 20. ↩
The simulation may seem slow, but it does not run in real time. Look at
the current timestamp in the upper right corner to know the wall clock, e.g.
“t=8s.” Once the topology stabilizes, the same corner shows the convergence
time, e.g. “🌳 2s.” ↩
Imagine you rent office space for a three-day event. You quickly set up a few
Ethernet switches and tape some cables on the floor to get everyone online.
Unfortunately, Stan, your clumsiest coworker, kicks out a cable every time he
gets up for coffee. Spare cables would fix that, but a loop turns into a
broadcast storm: Ethernet packets multiply until nothing else gets through.
That’s where the spanning tree protocol comes in: it blocks just enough of the
spare cables to leave a loop-free tree, and rebuilds it in a second each time
Stan strikes again.1
This content is also available as a text version, with interactive demos
that run a real implementation directly in your browser!
This video is an experiment.2 Honestly, except for Radia Perlman reading
her poem,3 you should read the original article instead. It presents the same content, but you can play with the
interactive examples, which are the main contribution. On the other hand, if you
happen to like the video, be sure to tell me in the comments!
Recently I was trying to reproduce a bug with
citeproc.el and
org-mode in emacs.
I thought I could use package-vc-install to install a set of
upstream emacs packages at fixed versions, and thereby let citeproc
upstream test in the same environment as I have.
It turns out that getting emacs to load the non-builtin version
of org via package-vc-install did not work because
org-mode needs to run make after cloning
once package.el was initialized, I always seemed to end up with the
built in org-mode (yeah, I realize that isn't an explanation).
Recipe part 1: get org
Here you can replace 9.8.7 with any other tagged release
I haven't made a new book haul post in I don't know how long, so a lot of
books have piled up and many have already been reviewed. Here's the
overdue catch-up in case anyone is curious what books I am finding
interesting before the reviews get posted.
Ilona Andrews — Magic Bites (sff)
Elizabeth Bear — In the House of Aryaman, a Lonely Signal Burns
(sff)
Oliver Burkeman — Four Thousand Weeks (non-fiction)
Miles Cameron — Whalesong (sff)
Lee Child — Killing Floor (thriller)
august clarke — The Felicity Complex (sff)
Alison Cochrun — Here We Go Again (romance)
Dan Davies — The Unaccountability Machine (non-fiction)
Linzi Day — Midlife in Gretna Green (sff)
Linzi Day — Painting the Blues in Gretna Green (sff)
Linzi Day — Ties that Bond in Gretna Green (sff)
Linzi Day — Spilling the Tea in Gretna Green (sff)
Michelle Diener — Dark Ambitions (sff)
Michelle Diener — Dark Class (sff)
Michelle Diener — Collision Course (sff)
Michelle Diener — Crash Course (sff)
Henry Farrell — Underground Empire (non-fiction)
Kathleen A. Flynn — The Jane Austen Project (sff)
Victoria Goddard — The Hands of the Emperor (sff)
James Herriot — All Creatures Great and Small (mainstream)
James Herriot — All Things Bright and Beautiful (mainstream)
James Herriot — All Things Wise and Wonderful (mainstream)
James Herriot — The Lord God Made Them All (mainstream)
James Herriot — Every Living Thing (mainstream)
Lauren Hough — Monster of a Land (non-fiction collection)
Bethany Jacobs — This Brutal Moon (sff)
Guy Gavriel Kay — Written on the Dark (sff)
Mary Robinette Kowal — The Martian Contingency (sff)
Ann Leckie — Radiant Star (sff)
C.B. Lee — Coffeeshop in an Alternate Universe (sff)
Fonda Lee — The Last Contract of Isako (sff)
Julie Leong — The Teller of Small Fortunes (sff)
Julie Leong — The Keeper of Magical Things (sff)
R.Z. Nicolet — The Cloak and Its Wizard (sff)
Claire North — Slow Gods (sff)
Rebecca Ore — Writing's Writing (non-fiction collection)
Suzanne Palmer — Ode to the Half-Broken (sff)
Gareth L. Powell — Fleet of Knives (sff)
Cameron Reed — What We Are Seeking (sff)
Beth Revis — Full Speed to a Crash landing (sff)
Beth Revis — How to Steal a Galaxy (sff)
Beth Revis — Last Chance to Save the World (sff)
Natalie Zina Walschots — Villain (sff)
Jo Walton — Everybody's Perfect (sff)
Martha Wells — Platform Decay (sff)
James White — The Galactic Gourmet (sff)
James White — Final Diagnosis (sff)
The James Herriot books were ones my parents were getting rid of. I have
them marked as mainstream fiction as a short-hand since "fictionalized
autobiography" seemed like too much of a mouthful.
The Debian Project was officially founded by Ian Murdock on August
16, 1993. The Debian community celebrates its birthday, Debian Day,
on or around this date every year. This year, I had the chance to attend
two of them: one in João Pessoa, Paraíba, and another in Brasília, the
capital of Brazil.
João Pessoa
In João Pessoa, we had a two-day event. The first day was dedicated
entirely to workshops, and I ran a packaging workshop for newcomers.
It was the first time I had been responsible for a workshop, and it
was a great experience. We didn't have a lot of time, so I decided to
start with a 30-minute talk explaining a few things about Debian. For
example, I made this image to explain the packaging workflow:
This image was based on The
Debian Administrator's Handbook, and I think the participants really
enjoyed learning about this workflow. When I showed the slide with this
image, it was the moment when I received the most questions.
After the talk, I explained my way of working and what they were
going to do. The hardest part was setting up the environment, since my
approach uses sbuild + gbp. They were running different Debian releases
and, because of my inexperience with workshops, I had some of them
configure sbuild with unshare, even though it is only available in
stable through backports.
Some of them even managed to learn how to use backports, while others
decided to start again using the "old" way.
One thing that helped a lot was the Debian Brasil
Wiki. It has all the instructions for configuring sbuild in
Portuguese, along with great examples. The Brazilian wiki is an
opinionated version of the Debian Wiki. We generally prefer to use it
for the convenience of having the exact workflow we follow, as well as
an up-to-date Portuguese version of our process.
If you want to learn more about the Brazilian community, you can find
more details in the schedules from previous DebConfs. We almost always
had a talk about the community and its activities.
In the end, everyone successfully set up their development
environment, and all six participants made their first contribution to
Debian. If you take a look at my upload
tracking page, you will see that every upload made on August 15,
2026 was a sponsored upload from this event. One of them appear twice in
the list because I sponsored the upload and also made some other
changes.
I also asked all of them to put this in their changelog:
* My first contribution!
The idea was to make it clear to other people that they were only
working on small Lintian issues as a way of learning and understanding
the process. By the way, I made a UDD
query to find packages with the following Lintian tag:
redundant-rules-requires-root-no-field. To fix this issue,
they only had to remove one line from the debian/control
file.
It is obvious that these uploads are not particularly useful. I call
them "motivational uploads" because my goal is to help newcomers
understand the process and immediately give them the reward of having
made a contribution to Debian.
I'll try to keep in touch with them. My plan is to hold another
session, this time remotetly, to help them continue contributing to
Debian. In fact, I already have another package prepared by one of them
waiting for my review.
The second day was a full-day event featuring a bunch of talks from
the local community. I gave a talk explaining the new members
process.
I was the only Debian Developer at the event, and I think having a DD
there made a real difference. Being there to answer questions, and
simply being present, makes Debian feel more tangible and accessible to
people.
A big shout-out to Rafael Rocha, who put in a lot of work to make
this event happen, with the help of many volunteers who contributed
along the way.
Brasília
One thing I really like about Debian Days is that each place has its
own way of doing things. In João Pessoa, we had a MiniDebConf-like
event, while in Brasília, we had something smaller but still very
valuable. We decided to keep things simple: talk to a few students at
the University of Brasília (UnB) and then go somewhere to eat and have a
few drinks.
A bit of history
For those who don't know, the DebConf 19 was held in
Curitiba, Brazil. After the event, Arthur Diniz got really excited about
Debian and decided to go back to his University, UnB, to share his
experience and encourage more people to contribute to Debian.
I attended one of his talks, thanks to Joenio Costa, who invited
Arthur to give the talk. Joenio was also my professor at the time and a
Debian contributor. I really liked what Arthur had to say about free
software, and he did a great job of presenting the Debian community as a
friendly and welcoming place.
So I decided to attend local meetings of the Debian Brasília
community, which had been inactive for a long time. Lucas Kanashiro was
the Debian Developer who answered our questions and, as I mentioned
earlier, simply being there made Debian feel more tangible.
Everything stopped when the pandemic began. Then, towards the end of
2020, I saw a message in the Debian Brasília channel saying that the
meetings were back, this time remotely. I was hesitant to join because,
back in 2019, I hadn't managed to make a packaging contribution, even
with their help. I had eventually given up on the process. So this time,
I decided to join the meeting with something already prepared for
review. I watched all of Eriberto's packaging videos, picked a random
package, and joined the meeting.
I remember Kanashiro being excited that someone had just shown up
with something ready for review. At the time, it was only the second
meeting since Debian Brasília had come back online, and none of the
newcomers had started working on contributions yet.
During the same meeting, he also convinced us, the newcomers, to give
a talk about Debian just three days later.
The MiniDebConf Online Brazil
2020 was happening on Sunday, and the meeting was on the Thursday
before it. Since he has great convincing skills, I went along with the
idea and prepared
the talk with Francisco Ferreira.
That was the rebirth of the Debian Brasília community.
Since then, we have maintained a close connection with the University
of Brasília, and today, at least seven Debian Developers are from UnB,
whether as former students or former professors.
The reason I told this story is that, even though the Debian Day we
held in Brasília was smaller, it is part of something that has been
working for us for several years: staying close to an University. We've
managed to attract and retain many people who share the same values and
interests.
I've hope you all had a great Debian Day. If you're reading this and
aren't part of the Debian community but would like to join, get in
touch!
In an option review I did in 2024, shortly after the xz-utils backdoor, I explained that having GSS-API authentication and key exchange support in the main OpenSSH packages is problematic. The key exchange patch is large and intrusive. Furthermore, even linking to the necessary libraries is not without risk: as the Ebury malware attack demonstrated way back in 2009, each extra library linked into security-critical daemons such as sshd (or nowadays into its privilege-separated helper programs) can modify the behaviour of the daemon even if you aren’t doing anything that would involve calling into that library. Of course some of that risk remains, but as Damien Miller wrote, minimizing the number of libraries that end up in the address space of sshd and friends is still valuable.
I just uploaded openssh 1:10.4p1-5 to unstable, completing this split. As of this version, the OpenSSH client and server are built without GSS-API authentication and key exchange support. If you need those features, install openssh-client-gssapi or openssh-server-gssapi instead, as appropriate. Debian 13 (trixie) already has packages with those names that just depend on the regular openssh-client and openssh-server so that you can pre-emptively install them, as documented in the release notes.
The new openssh-*-gssapi packages have relatively tight dependencies on openssh-common, in order for the testing migration system to ensure that we can’t forget to keep them up to date. This will mean a bit more ongoing work for me on each new upstream version, but I think it will be manageable.
The current discussion in Debian aroun the AI GR is very heated, and I won’t add
to that, however, I am very confused about some of the viewpoints there. But, I
had no idea how to even try to write this, so did shut up, until I saw Aigars’
excellent Optimistic take on
AI, which
motivated me to try, at least. For the record, I fully subscribe to the post,
and to the voting suggestions (and I just voted).
Also, for full disclosure, I don’t think I did any contribution to Debian until
now using AI, neither packaging, nor emails, nor bug reports. And this blog post
specifically is 100% hand written.
With that out of the way… there are two points I want to make in this post.
AI is useful, even if it has risks
First is, that even if we could put the genie back in the metaphorical bottle,
we should not. We do need to continue working towards safe AI, and efficient AI
(less environmental impact), but we should not work towards removing the usage
of AI. There are already significant advancements in sciences and technology
thanks to the use of AI, so desiring AI to not exist (assuming we had a magical
wand) is the wrong approach.
Sure, AI has significant risks — and I can see ways in which AI can do
significant damage to society — but I don’t think we can go from Kardashev I to
II without the use of AI, and definitely not to III. And I think, that should be
the goal.
A few simple examples: Do we want to rollback all the 20 years old security
issues that AI found? Do we want to rollback the recent Moderna cancer findings?
Do we want to rollback the concept of “extremely large scalle pattern
matchings”, just because it runs on chips and no longer in one person’s head?
Reading Debian lists
The second point is, lately I found less and less enjoyment in reading Debian
lists. Even with that already being the case, I feel soo disconnected from many
of the opinions being voiced in this discussion.
On one hand, it’s normal and healthy that people have different opinions,
disagree, and move foward.
On the other hand, looking at one of the proposed options:
“Moderators and disciplinary teams may make narrow and tailored exceptions to
rule 4, and decide on interpretation”.
“Violations of these requirements should be treated as violations of the
relevant Code of Conduct and should result in swift and proportionate
disciplinary action”.
I already knew Debian, and some large parts of the OSS world, is left leaning.
But those phrasings, to me, are too close to socialism/communmism. As someone
who grew up under communism, this is a much more slippery slope (disciplinary
teams? really?) than AI usage. Ask me in person for more details.
So, it is possible that Debian continues to evolve in such a way that I don’t
find myself in any way close to its ongoing culture. I will be sad at that
point, but it will be what it is.
Where to?
I think that, until such a time that an AI bubble bursts, what any organisation
should do is try to logically see where and if AI can help. And in an
organisation that is about computer software, I see hundreds of places that are
subject to very large scale pattern matching… so the half of the discussion is,
to me, mind-boggling.
To be clear, it’s not about “if you can’t beat them, join them”. As I wrote
above, I think AI is useful, so the point is how to use it effectively.
Well, will see what Debian votes. I am half curious, half sad alreay.
When I was young, I learned about a model of classifying programming
language: the system of programming language generations.
In this model, first generation programming languages are, basically,
where you program the computer in the language that is defined by its
architecture. On a Von Neumann
machine, with
its load-and-store architecture, you do that by inputting a string of
numbers. The first programmer in human history -- her name was Ada
Lovelace -- wrote in a
first-generation language. 1GLs aren't so much invented as they are a
byproduct of the computers for which they're created.
Second-generation languages are the assembler languages. Because humans
are not computers, and because decoding long lines of numbers to
understand what the computer is doing, when programming became a
full-time job, the programmers that did it decided that doing all this
assembling manually is too complicated, so they quickly wrote assemblers
to automate the process for them. They still could understand the 1GL
output of the 2GL assembler, but most of them quickly forgot how to
write software in a first-generation language. Not that anyone cared, as
the translation from a 2GL to a 1GL is lossless and you can just revert
it.
Third-generation languages are higher-level languages. When the first
3GLs were invented (such as COBOL
and, more famously, FORTRAN) in
the late 1950s and early 1960s, it was believed by some that the work of
programming a computer so accessible to non-programmers that the job of
programmer would eventually cease to exist, and people would just ask
the computer what they needed by entering COBOL instructions. This of
course was ridiculous and incorrect, because converting algorithms to
computer instructions, whether at the 2GL or 3GL level, is a specialized
skill that some automation can perhaps make simpler but never completely
take away the need for. At the time, some people also felt to some
extent that using 3GL wasn't the same thing as actually programming
3GLs, but eventually
the world moved on and embraced things. The invention of 3GL
environments reduced, but did not completely take away, the need for
people to understand 2GLs, as compiler and operating system authors
still need to understand them, and some highly optimized code still
continues to be written in 2GLs to this day.
Fourth-generation languages abstract away some or all of the process of
programming. For instance, a database-related 4GL will hide away the
complexities of storing data in particular locations, how to fetch that
data, how to index it such that you can fetch it efficiently, how to
loop over the data to get you a summary of that data, and instead allows
you to express the required information in an abstract way, expecing the
computer to fill in the blanks. When SQL, an early 4GL, was invented,
some people believed that the language made accessing databases so
simple that the requirement to implement database applications would
eventually cease to exist and we would just hand SQL prompts to users
who need to access data. This of course was ridiculous and incorrect,
because understanding data schemas and using that understanding to query
data from a database is a specialized skill that perhaps a higher
abstraction can help you make simpler, but that in the longer run it can
never completely take away the need for. The invention of 4GLs also
reduced, but did not completely take away, the need for people to
understand how to do the things that the 4GLs automate for you manually,
as the people who do write those things still need to understand them,
and there are also environments where these particular 4GLs are rather
not appropriate or just very slow.
The first definition of programming language generations that I read
about in the 1980s simply stated that fifth-generation languages did not
yet exist, but that they would in the future, and that in those, you
would "tell the computer what to do, and it would then do that". Now
that we have a way of doing
so, it could be
said that by some definition, we now actually do have a number of 5GLs.
The existence of these LLM systems has caused some, especially the
people who build and exploit these systems, to exclaim that programming
as we know it today is going to cease to exist, and everyone will just
ask an LLM to generate a program, which will then do so. That is of
course ridiculous and incorrect, as no automaton can generate software
from nothing; input is still required for the model to be able to
produce something that approaches usability, and being able to word that
input in a correct and productive fashion will be a skill that future
programmers can benefit from. I ran some
experiments
a while back, and from that concluded that, if we look only at the
technical side, LLM use can, in some niches, increase productivity for a
programmer. There are certainly things that you shouldn't use an LLM
for, but equally there can be cases where use of an LLM to perform some
task that traditionally would have been done by a programmer would be a
net positive.
But LLMs, as they exist today, are highly problematic.
They require vast amounts of data to build the model. The companies that
build these models are disrespectful of people who run web services, and
as a result, everyone now has to implement various types of application
firewalls just to not make systems fall over from the overwhelming
requests for data. They are also disregarding the licenses that are
attached to these vast amounts of data, which makes me, as a person who
believes in the tenets of free software, sad.
They require vast amounts of energy, causing an already-critical global
warming crisis to, well, not improve.
They require vast amounts of coolant to dissipate the energy
concentrated in their data centers, causing further environmental
effects.
In this, they are problematic and to be avoided. But these are side
states of the current state of affairs; I do not believe that they are
inherently implied to be able to build and operate an LLM -- any LLM.
I guess it's fair to say that my feelings towards LLM usage are complex
and many-faceted. I haven't been involved in many debates about the
subject, debates that to me seem to be mostly focused on "LLM good" vs
"LLM bad" arguments that aren't as nuanced as the position that I would
believe is more accurate. This is not because I don't care, but
partially because I've been busy in my personal life recently and
partially because the whole thing seems somewhat disheartening.
But then Debian popped up GR
2026-002, meaning, I now
have to come up with an opinion about various candidate statements in
the context of the above, which is... not easy. But I did it anyway.
There are 8 choices on the ballot, and they all have some truth and some
falsehood to them. My position about LLMs can be summarized as:
The current state of affairs wrt LLMs is disastrous and we should not
encourage them
However, there's no technical reason why this must remain true for
all time
And so any statement should keep in mind what might happen in the
future and that the current disastrousness of the whole thing isn't
guaranteed to continue to exist for all eternity.
With that, let's go over them.
GR vote options
Proposal A
Its summary, from the GR text:
This proposal aims to expressly forbid any contributions to Debian
written with the use or assistance of large language models (LLMs) or
other generative AI tools.
This falls squarely in the "LLM bad" camp, outlawing all generative-AI
contributions, disregarding potential future ones where the problematic
situations that exist today are not present.
It makes a change to the social contract, which is especially difficult
to reverse (on purpose), and which therefore also will require a 3:1
supermajority, but if we want to ban LLM-assisted contributions, this is
probably the best way to do it.
Proposal B
This one tries to allow AI-assisted contributions under certain
conditions. It's mostly an "LLM good" proposal, with some caveats that
can be discribed as "make sure you know what you're doing".
Proposal C
This proposal is both a weaker (in some places) and stronger (in other
places) version of Proposal A. It makes changes to the code of conduct
instead of to the social contract, and it also wants to, at least,
suggest policy to parties beyond the Debian project. By not changing
the social contract, however, it is more likely to reach its simple
majority requirement than proposal A.
I don't think the language that it wants to add to the code of conduct
is particularly well phrased, however.
Proposal D
This is a weaker form of proposal B. The language is more compact and
there are a few requirements that are spelled out in proposal B that are
not spelled out in proposal D, but if you read between the lines you'll
see that the requirement is still there really and I don't understand
why proposals B and D were not merged into one.
Proposal E
This proposal tries to hold a middle ground between "LLM good" and "LLM
bad". It appreciates that things are quite muddled at the present time,
and that perhaps the situation might might change in the future. It
acknowledges that certain questions remain unanswered and that perhaps
future considerations might therefore be different. But it essentially
refuses to take a stance on whether LLMs should be accepted by the
project or not.
Proposal F
Similar to proposal E, this proposal tries to discourage Debian
contributors from using LLMs, while still allowing people to use it
should they want to, but with some requests and requirements to mark
LLM-assisted contributions to account for those people who don't want to
interact with LLM-generated software. As such, it is a proposal similar
to proposal E that leans closer to the "LLM bad" camp.
Proposal G
This proposal aims to ensure that contributions directly to Debian are
created by humans, while at the same time avoiding restrictions on the
tools those humans may choose to use when contributing
Another "LLM bad" proposal, it however restricts the "bad" bits to only
the direct output of the LLM. If you use an LLM to do something and
then clean-room re-implement the same thing yourself, that's apparently
fine.
Proposal H
This proposal condemns the use of LLM for its environmental and moral
problems, but explicitly not for its technical considerations. I feel
that it is closest to my position as explained above.
Voting
Expressing a vote on a ballot so convoluted and complicated like this
one takes time. I have to read and understand every ballot option, and
formulate an order of them.
And I shouldn't just state which option has my preference; Debian's
voting process allows a rich expression of opinion on ballot options.
Anyway, I eventually ended up voting in a way that I think is consistent
with my opinion. But it wasn't easy.
Log in
