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 former 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. 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).1 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 bridge2 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-space3 implementation of RSTP.4
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:5 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.8 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.9
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:10
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.11 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.12 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.13 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.14
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.15
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.16
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.17 Some topologies can take a bit more time to recover
when the root bridge becomes unavailable.18
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 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.
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.1 Honestly, except for Radia Perlman reading
her poem,2 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!
I thought automated tools would produce this video in a couple of
hours. In the end, it was another rabbit hole and it took me more than 12. ↩
The audio was extracted from a Youtube video and cleaned up. ↩
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.
As I am writing this, there is a vote ongoing in the Debian
project on how to deal with AI in general and AI-assisted contributions to Debian specifically. Massive discussions
have happened in debian-vote and other locations. I have also asked
questions there and offered my perspective. IMHO now is the time to summarize that, after all the discussions
that I've had with people on multiple sides of this debate both online and offline, and explain how I will be
voting and why. Hopefully that will be helpful to someone else as well. None of this has been compiled with AI
assistance, but only because I think that forming opinions is not something where AI can really be helpful.
Spellcheck was used though.
So, first I will describe how I see each of the 8 proposals, then what my vote will be, and then a bit more
detail on the reasoning and thinking behind this. WARNING - this went long.
Proposal A(1) - Action: ban all AI-assisted contributions via Social Contract amendment, except from upstreams
(so not rolling back the Linux kernel and other software to "pure", pre-AI state). Claims that copyright/licensing
status is unclear, quality is bad, community is being destroyed, web resources see extra load and that training
consumes "staggering" resources. Needs 2/3rd majority to pass. - IMHO worst and most inconsistent. If copyright
and licensing of AI products is unclear, then be consistent - ban ALL software with AI contributions, fork Linux
kernel and other software from pre-AI versions, reject all security fixes of issues found with AI. Quality section
lists problems that have not existed in the real world since at least a year of rapid AI coding development. Community
section assumes that now all Debian contributions will be drive-by AI slop and no one will learn anything anymore.
Ethics section mixes up effects of badly configured systems (AI web load is no different from load from a badly
configured Perl script) with claimed "resource" usage without any context, taking on trust project ambitions of
startups and assuming exponential growth. And then concludes that delivering less is in the interest of our
users somehow.
Proposal B(2) - Action: allow AI-assisted contributions, with conditions of: legality, accountability, disclosure,
no uncoordinated bulk actions, privacy. Concerns on quality and legal status as well as environmental impact
and scraper load are noted, but not really addressed beyond labelling them as concerns. - IMHO it is an ok starting
position as it establishes that each contributing person must still be fully responsible for their
contribution (both legally and technically) and for that has to also understand (and review) what they submit.
Disclosure lets others know to watch out for other classes of problems when code was changed with AI assistance.
Prior discussion for bulk changes just says that the (already established) practice should not be neglected
just because now large changes are easier to do. And the privacy part warns against accidentally sending private or
confidential data (like a not yet published security bug) to a public service where it could become public.
Personally I would have liked a stronger statement to encourage use of environmentally responsible AI services
and local AI tools. Possibly a preference for open-weight models with a clear path forward to preferring truly
free AI models, when such a category of products could be clearly delineated and established.
Proposal C(3) - Action: reject AI-assisted contributions at Code of Conduct level. Claims all the world's evils come
from LLMs and that "Ethical and safe use of this technology is almost impossible". Goes as far as banning any
use of LLMs even in Debian mailing list emails and Debian Planet blog posts - if you do, it's a CoC violation
and may result in exclusion from the project. Additionally mandates the disclosure of the usage ... presumably
to ban you more efficiently for it. - IMHO truly a dictatorial nightmare option. Zero actual reasoning or
basis for such a decision. Zero sources. Nothing claimed in this option's rationale is even close to reality and
nothing claimed there is in any way related to the actual technology being discussed. Like, an "LLM" does not
automagically commit "fraud" when you use it, like this proposal claims, as if that was a well-known fact.
LLMs are not all "owned by horrible people and companies". Even if some include a (prominent Debian user,
long-time supporter and sponsor) Google into "horrible companies" (which is what this proposal implies!),
there are plenty of LLMs owned by all kinds of companies all over the world and there are plenty of open-weight
LLMs that are not really owned by anyone. Most invasive and dishonest option on the ballot.
Proposal D(4) - Action: allow AI-assisted contributions, with conditions of: legality, accountability,
disclosure, privacy. IMHO same as B, just shorter. Adds a "we don't recommend" towards others developing software
with AI assistance. Seems pretty weird to add that and then immediately accept Debian contributors doing so.
Assumes that the bulk change bit of B is implied as AI is just tooling, so bulk changes should be pre-discussed
just like today - so no change and thus no point in mentioning that. Fair. D is a bit more explicit on expected
technical details - like that the "person" submitting the change is supposed to sign it, not AI. Notable is
the complete absence of resource usage or the environment from concerns. IMHO it would be better to have that
and also recommendations on how to avoid causing environmental damage when using AI.
Proposal E(5) - Action: no action as such - AI-assisted contributions must follow the same rules as all other
contributions and those rules are sufficient. IMHO despite its length this is a very well-worded position
statement that describes how and why AI-assisted contributions already work perfectly fine in the Debian context
when all the same rules that apply to all contributions are also consistently applied to AI-assisted
contributions. It describes how the same legality, accountability, no bulk change and privacy requirements
are already in place and still apply and how AI-assisted contributions can and must still satisfy them. I could
add again that some guidance would be nice here for both legal and environmental decisions when using AI,
but in this case it does not really belong in this proposal itself. We as Debian do not have a document that
requires that our non-AI-assisted contributions be made with only sustainably sourced electricity, for example.
So why should AI be special one way or another? IMHO Debian should have a datacenter sustainability policy,
regardless of the AI discussion.
Proposal F(6) - Action: discourage AI, but allow it based on existing processes (similar idea to E). Dances a bit
around the question of disclosure of AI use (as a courtesy) and accepting that some people may still ban
all contributions where any AI was involved in any way. Which in turn discourages disclosure to avoid pointless
rejection of valuable contributions (like security patches). IMHO this option is ok, but so watered down that
it is bound to bring up further discussions and conflicts on details.
Proposal G(7) - Action: ban non-humans from directly contributing to Debian. IMHO - another bizarre and
self-contradictory option. It bans all Debian interactions with AI assistance, including email messages to
Debian mailing lists and (supposedly) blog posts on Planet Debian. It "reminds" people who "use such tools
assistively" of the DFSG and Social Contract - isn't that a threat of a ban and expulsion similar to C? The
proposal does take pains to delineate where a contribution comes from AI as output (bad) vs when you are
assisted by AI in the process of exploring, researching or maybe even reviewing the code, but you
actually type all the code yourself and use the AI just as a taskmaster with a whip (good). And just like A
or C it completely ignores how this inherently evil and unstable AI-generated code becomes perfectly fine and
good as soon as someone develops that outside of the Debian project. Even if the same person then packages
it for Debian the next day. It is hypocritical, unsustainable and ignores the needs of our users. Just like
C it also bans someone writing an email or bug report in their native language and using a modern translation
tool or service (that uses LLMs nowadays for better grammatical clarity) to translate that to English before
sending it to a Debian mailing list or BTS. Heavy-handed and invasive. And the only reasoning provided
for this is some unnamed "concerns" of "extra work" being borne by "other people"? Kind of does not feel
right to bear such draconian restrictions for some unspecified concerns.
Proposal H(8) - Action: condemn usage, but not actually ban anything. And then it goes on to claim
(without any evidence or elaboration) that LLM usage accelerates the destruction of "planet earth" (sic).
IMHO this proposal is at the same time the loudest ("The planet is burning") and also the one that demands the
least action. It dances a really twisty line between raising "significant" concerns in all areas and even
claiming that use of LLMs destroys the planet, flies by explicit condemnation of LLM usage and then suddenly
collapses with not condemning LLM users and swinging to lamentations that it is actually impossible to impose
policies on LLM usage or even detect when an LLM was used (which kind of directly contradicts bad quality
claims from A, C and G) and lands on "encouraging" contributors not to use LLMs (where practical) and otherwise
do nothing else. It's like this is a 5th draft that started off with the rationale and total ban like in C,
but then got defanged so far that its action side no longer matches the rationale stated.
With all the above considered I will vote like this (earlier options are preferred over later options):
Proposal E(5) - solid hack of integrating AI into already existing Debian rules and conventions
Proposal B(2) - explicit and detailed
Proposal D(4) - lower because of discouragement to others on what we agreed to do ourselves
Proposal F(6) - I am not a fan of dancing around with disclosures
Further discussion(9) - I do not want any option below this to succeed as they would do more harm than good
Proposal H(8) - loud, but not doing anything actually
Proposal A(1) - at least this one does not set rules for emails
Proposal G(7) - at least this one allows an AI overseer to tell you what to write with your own fingers
Proposal C(3) - the most draconic and invasive one that explicitly wants to kick people out of the project
Details on rationale
Hypocrisy - I find any proposal that would ban AI-assisted contributions to Debian, but at the same time not
ban including AI-assisted contributions from upstream projects to be inherently hypocritical. If LLMs
and AI are the very incarnation of evil (a puppy-killing machine, as the analogy went in some emails), then
any rational proposal would involve excluding any and ALL code contaminated by this evil from the project. What
does it matter if puppies were killed in writing the debian subfolder of the source code or the src subfolder?
No proposals went there because everyone knows that such a ban would be the death of the relevance of the project
for the future. Debian would be frozen on some old version of the Linux kernel forever and other software would be
falling to the same problem too, for example as projects on GitHub start enabling AI-supported reviews with patch
suggestions. Soon the "development" of Debian could just be stopped as there is nothing to develop without any
upstreams.
Assumptions - a lot of proposals mention various "concerns" with at most one word, like "practical" or "community"
without an explanation of what exactly they mean by that. The proposers assumed that everyone lives in the same info
bubble as they do and already know everything that they mean and already agree to that. That is false.
Proposal A was a positive stand-out in this area. Debian has contributors all over the world with very different
exposure to different information sources and very different world views. If you want to convince the project as a
whole that LLMs are bad because of "ethics", then you do really need to explain what you mean by that and give
links to sources, at least as well as Proposal A did. All other proposals were really weak in this area.
Copyright - the question on how copyright law interacts with training LLMs and their outputs is still not settled
law. The closest legal statements we have so far are that - just because an LLM is trained on copyrighted material
does not make that LLM itself be a derivative work of the training data (you, however, cannot just create and
distribute a "library" of copyrighted materials just because you plan to train LLMs on it). The output of the LLM
might not be subject to copyright law at all, like a photo taken by a monkey. It would then be public domain and
thus can be modified and then licensed by the user of the LLM. It might also be a derived work of the context
of the inference (so for software - if you refactor a GPL project, the refactoring itself is likely GPL too).
Any stricter interpretations would break a lot of existing copyright doctrine, such as raising questions like:
"does the output of any programmer now become a derived work of the programming manual books they read in college?".
In any case it is really not up to Debian to legislate the nuances of copyright law. And I strongly disagree with
the concept that an author can tell me how I am allowed to use the learnings that I gained by reading their work.
That is not how either copyright or society works. I can look at 10 pictures of a sunset and draw my own,
inspired by the ones I saw. No one can forbid me that expression. The same must be true for a machine learning and
replicating patterns.
Ethics - I've re-read all proposals and emails and the only real specifically ethical concern I could find was
the complaint that some LLMs (or their training farms) are running their web scrapers too aggressively and that
causes extra load on services. Like that is not an LLM problem. Scraping the web is not an inherent part of
the LLM training or inference process. It's just a few misconfigured scripts. We saw the exact same thing in the
early days of web search engine proliferation. Then we banned/blocked the misconfigured engines and the
survivors learned that obeying robots.txt is one of the rules for surviving. Literally the exact same problem
and it will be solved the same way. Did we ban all search engines back then just because some of them were
misconfigured? No.
Some claims (like in Proposal C) are just bombastic hyperbole ("hazards to users' mental health", "fraud", ...)
and on top of that have zero relevance to the topic at hand - AI-assisted contributions to Debian. What
"hazard to users' mental health" is created when a Coderabbit spots that a lock is not taken before accessing
a resource in a particular function and suggests an AI-generated patch to fix it? What "fraud" is committed by
this? There is no sane answer. I get that some people are very busy fighting some culture wars and sometimes,
some AI-bros happen to be on the other side of one such war, so it is useful to label everything coming
from the AI sphere as "bad" in all possible and impossible ways. You do you. In private. Why pull Debian into
that? Why force your position on everyone else in the project? Why deny everyone in the project access to
useful tooling, just because you have strong feelings about some of the people promoting some of those tools?
This seems to me a repeating pattern here - blaming the technology as a whole or blaming all providers
of this type of technology for failings (ethical or technical) of some of those providers. Like refusing
to wear all shoes and condemning all shoemakers and sellers, just because some American billionaires figured
out a way to make and sell cheap shoes by killing puppies. Not refusing and condemning those providers,
but condemning all for the actions of a few.
Resource usage - this is a big topic for many and it has reasonable points to it. The LLM and AI technology
has no inherent need to be damaging to the environment in any way for it to function. It does not need to
burn oil or dig up cobalt. It does not need to sacrifice a ton of water to the Gods. It is perfectly
possible to run AI (both inference and training) purely from green, electrical energy and cool data centers
in equally sustainable ways, like with simple air-source heat pumps (also known as air conditioning) or even
use it beneficially (many data centers are used for heating surrounding buildings via district heating).
However, some AI companies do use non-green power for their data centers, some do use locally-limited
fresh water for evaporative cooling (evaporated water still rains down as rain, it is not really lost, but
that may happen in another location so lack of water can still happen locally). Some even run unlicensed
natural gas turbines in their data centers to provide them with power. And those specific providers can
and should be shunned and condemned. Not the other ones, who are doing the right things. Not the technology
or its users or its outputs.
There is a very wide spectrum of options on how an AI system could be powered: starting from local execution
on already existing private hardware powered by one's own local solar power (good), to a data center stuffed with
borrowed AI-only cards powered by a gas turbine or coal power station that operates solely to supply this
data center (bad). Proposals that talk about ecological impact, but do not even consider where on that (very
wide) spectrum to draw the line between "good", "acceptable", "discouraged" and "bad" — well, I cannot see
those proposals being actually serious about the environment to begin with. It feels like they just refer
to it for points.
And if we go into the power question deeper, well the grid dynamics and economics become very, very complex and
often also non-intuitive. Like, all large software companies with data centers (that also happen to provide
AI services), like Google, Meta, Apple, Microsoft and others do actually care about sustainability (in part
because their customers care and vote with their wallets) and so all of them use 100% green energy for their
data centers (including AI data centers) .... "on an annual scale". Wait, what does that mean?
Well, the electrical grid is special - the amount of electricity produced and consumed on the whole electrical
grid together has to match almost exactly every second. If there is just a single second where there is
significantly more energy consumed from the grid than is produced, the frequency will plummet and you get
a brownout and risk a grid collapse. The same is true in reverse - that causes a voltage swell. So grid operators
manage energy flows every second and command power stations to increase and decrease generation all the time.
Some power stations are easier to regulate dynamically than others. In the end, all that means is that
even if your data center has a contract for 100% green energy with your power company, at some seconds
across the year there might not be enough green energy in the grid to fully supply ALL people and companies
that have 100% green energy contracts. This gets compensated in other seconds, so that across the year
("on an annual scale") for each kWh that your data center pulled from the grid, the same amount of kWh of
100% green energy flows into the grid. But it might not happen at the exact same second. Pedantic
companies, like Google, take that discrepancy and count that as CO2 emissions for themselves. And then
they and the power companies (they have contracts with) invest billions into new green energy projects,
better grids and better batteries so that eventually this discrepancy goes down to zero. In this way
green AI data centers with their increasing consumption of green energy are actually doing a lot
of good work in making our electrical grid more green. They are making more resources than they are
consuming. And that is just the tip of the iceberg. This is a deep topic that really abhors generalizations
like "more consumption = bad".
I've heard similar discussions in the context of electric cars - "so you got an electric car? you'd have fewer
emissions if you drove no car at all!". That might be so. And I would also reduce my emissions to zero
if I stopped breathing, but I really do not want that kind of thinking to be propagated further, especially
when impressionable young people are around who may take it to its logical (but wrong!) conclusion. Instead
I talk about how early adopters use electric cars to gather experience and achieve volume to start the
network effects working. Once network effects of many electric cars on the roads are sufficient, it becomes
an economically logical choice to get an electric car. People who cannot avoid having a car start
to switch over. And at the point of mass switchover the reduction of emissions is so massive that those
early adopters failing to go all the way to riding a bicycle becomes a rounding error.
But surely that does not apply to LLMs? They are only increasing consumption and bring no benefit?
Benefit - and here we have to actually talk about benefits. Because you cannot make any cost-benefit
analysis if you do not actually fully investigate the benefits. Are there environmental benefits from
running those AI models? Yes, in a lot of very diverse ways. Hard to measure, however. There are projects
that are easy to quantify - like that Google AI project on contrail avoidance. An advanced, special model
trained and executed in Google AI data centers was able to predict where in the air contrails would be
produced and could generate proposed course adjustments to commercial flights to avoid specific heights
in specific locations at specific times. This stopped these aircraft from creating contrails and those
contrails did not make a further contribution to global warming. That benefit in a year was many times higher than
the environmental cost of training and running that AI model. And it can keep running for many years
accumulating further benefits.
On a personal scale, I've had problems that I bashed my head (and computer
and CI resources) against without much success years ago solved with a few minutes of compute. Having
a good enough candidate solution quickly is much cheaper from a resource perspective than spending days
trying different things, running my PC for it, trying different patches on CI executions, doing different
rebuilds. I've seen very significant benefits in AI-assisted development in enterprise environments
where code way more complex than what is in Debian (especially in Debian tools and packaging) gets
analysed, reviewed, modified or even refactored or rewritten in another language with AI assistance.
And it generally works. The commonly mentioned "hallucinations" are a thing of last year in the coding
context. Nowadays the AIs work in special coding harnesses and use real tools as foundational facts.
You cannot "hallucinate" an API call or parameter if you have to run and pass the unit tests and
integration tests by your harness before you can return "success" to the caller. I've personally
seen high-level AI models read very complex software projects across multiple repositories and point
out a very specific design consideration that was encoded in the code logic, but never mentioned in
comments or documentation. It was so obscure that even I did not immediately know what it was
talking about (and I wrote that code). Only on close inspection of code interaction across three repos
did I remember that there was indeed that bug 2 years ago that I fixed by doing the change that
this AI picked up (it wasn't in the history of this git repo due to repo migration). It mentioned
this because it was very relevant to the task I initially gave it to review.
These LLMs in a proper harness with proper system instructions and usage approach are not just fancy
spell checkers or auto-complete. They function more like very advanced pattern matchers. They have learned
millions of patterns from training data. When they look at the code, they see hundreds or thousands of
overlapping patterns. When you ask them to make or change something, they pull out a pattern (or ten)
from their training and apply those patterns to the context of your program. You get something that
looks just like the surrounding code, same style choices, same language, same comment voice, but it
implements something new there, based on other patterns learned. If you've studied design patterns
in your CS class, this will be familiar. But people can learn and remember maybe 20-30 patterns, while
an LLM can have a million patterns and can combine them when needed. So it takes a pattern of
Python code, pattern of standalone script, pattern of parsing command line parameters, pattern of
classes, pattern for background threads, pattern for file tree traversing, pattern for pipes, ... and
squishes them together to make a solution for your query. And then tries to debug it with compilation,
tests and execution until it works as expected. Even if there is zero LLM development going forward, it
will take many years to fully appreciate the benefits we can extract from the already trained models.
They don't even have to be retrained - for existing languages they just keep working. For new
language variations, like a new Python version, you can feed the changelog into context and they will
be able to work with a Python version that they never saw in training. And patterns are mostly abstract,
so not really specific to any language - human or programming.
This is another big enabler that LLMs have created that we have not really explored yet. LLMs have
created really free software. People can actually create software that is perfectly suited just
for them and no one else. They don't even have to know how to program and don't even need to speak
English. I've seen people writing prompts in their native language and LLMs creating and then adjusting
web apps or Android/iPhone apps and deploying them to the user's own phone. It was too buggy to work last
year, but this year it is actually very functional for simpler use-cases. And the code looks just
fine too - I've seen external contractors in a business setting deliver far worse. If you start with
a good initial system prompt, the project will have architecture documentation, use-case documentation,
unit tests, integration tests, deployment harness, testing and production deployments, audit logs,
monitoring, clear git commits, CI validation on commit, ... Modern AI systems have the capabilty
to deliver software freedom to people who are not coders. I really can not overstate the consequences
this may have on the world.
Community - I find the concerns that new people will be using LLMs so much that they will no longer
be understanding the actual code they are contributing a bit regressive. I don't see any significant
difference between this and people relying on compilers, on high-level languages or on debhelper.
Writing modern debhelper packaging feels more like writing configuration and not writing code. It
takes really significant effort to dig down through layers of abstraction to find what actually
is being executed in debian/rules. AI does not really make this worse. In fact, I find that AI
can make it much easier to understand arcane syntax because you can ask an LLM to explain what is
happening in any part of the code and it will do a pretty good job of it, digging down through
the layers of abstraction for you. All the pro-AI proposals include the requirement that each
human contributor needs to understand and stand behind their AI-assisted contribution and I
believe that is a good requirement and also a sufficient requirement. Modern LLMs not only produce
clear and concise code, but they are also capable of producing good comments explaining why the
code is how it is, good commit messages explaining the change and reason behind it and also
making corresponding changes to test suites and documentation. You know - the housekeeping stuff
that is often skipped because it slows down the actual feature development, but then its lack
becomes a problem for future contributors. Responsible use of AI assistance is a great chance
to actually strengthen our community and make our software easier to maintain.
That said, I have no qualms about flat-out rejecting contributions that do not make sense. And
it does not matter if they are made with or without AI assistance. If the contributor will not
explain their patch, it might be they do not understand what their AI produced or it could be
that the contribution is deliberately hiding a backdoor being planted. It is also quite common
for a contribution of a new feature to be rejected because the author/maintainer does not believe
that it is a good fit for the project. Featuritis is a real disease. AI or not. There have always
been drive-by contributions to various projects. They will continue to exist. Each of them should
be evaluated on its merits - is this feature valuable to our users and is the added complexity
(if any) worth the functionality? A lot of security bug reports are "drive-by" contributions as
well. And many of them nowadays are discovered, exploited and patched with AI assistance. We
could reject them, but that just leaves us holding the bag on the now-known exploits.
And the New Maintainer process should be able to figure out if an upcoming Developer has actually
understood the nuances of Debian packaging or not. A contributor with upload rights to the
archive has to be able to create a basic package with no support tooling (maybe even without
using debhelper?) and be able to understand and modify more complex packages (possibly with
tooling support). IMHO that is a separate discussion that is worth having, involving experts from
the educational sector.
Conclusion
IMHO the Debian project should not restrict what tooling individual contributors use to contribute.
Expecting high-quality contributions and that contributors understand what they are contributing
(as a first level of review) is enough.
However, Debian should provide its contributors (internal or external) with guidance on how
to contribute in the best way possible. That could include:
information on which AI services have Terms and Conditions that make them problematic for free
software development, legally speaking
information on which AI services do (or do not) achieve a sufficient level of sustainability to be
worth recommending (and then do the same for other data centers we already use)
information on which local AI models were trained in sustainable ways
base-level prompts to set technical expectations on various types of contributions, like bug
reports or patches to packaging or translations
default configuration for AI-assisted code reviews on Salsa that projects could enable and
supplement with their own instructions on top
In addition to that it would be helpful for Debian, as a project, to reach out to AI service
providers to:
encourage them to improve sustainability (where needed)
investigate and fix problems causing excessive scraping load on systems
provide AI resources for Debian usage, for example in CI infrastructure or to provide equal
development support opportunities for Debian developers who cannot afford paid AI services
improve coding outputs of their models in the Debian context if/when systematic deficiencies
in the output are found by us
A new minor release 0.4.28 of RProtoBuf
arrived on CRAN today. RProtoBuf
provides R with bindings to the
Google Protocol Buffers
(“ProtoBuf”) data encoding and serialization library used and
released by Google, and deployed very widely in numerous projects as a
language and operating-system agnostic protocol. The new release is also
already as a binary via r2u.
This release corrects a really old bug. Troy found, when working on
gRPC based extensions, which is in and by
itself exciting, that a small part of our interface surface (for service
descriptors) was just wrong confusing single and double underscores.
adjusts to a change upstream. This has been corrected. I updated a few
of the usual continuous integration parts, updated a help page for a
newly-added nag by CRAN, and
also got a last-minute round of noodling in as the JSS paper vignette
was still referencing OmegaHat which the CRAN URL checker objected to. I
created a quick one-off repo to serve pdf files should the need arise
again, and rebuilt the vignette linking to it. No other changes.
The following section from the NEWS.Rd file has all details and
links.
Changes in
RProtoBuf version 0.4.28 (2026-08-21)
Standard maintenance of continuous integration
The type help page has received a usage section
Cleanup of several methods for ServiceDescriptor, correct several
other declaration (Troy Hernandez in #117
fixing #116)
Adjusted vignette reference to Omegahat paper to alternate
location
Following on the rationale of the previous post, here is how I create
a development VM based on ready to use disk images made by the debian cloud team.
I could as well install the VM myself using an ISO, but why download a collection of packages in a ISO only to copy them right onto a disk image ?
From the list of images available at https://cloud.debian.org/images/cloud/
we will start with the generic qcow2 disk image, it has cloud-init, which allows initial automatic configuration, and snapshots of the VM via the qcow2 disk format.
As for the virtualization, I am using virshvirt-install and virt-manager, which are part of the libvirt framework. Libvirt offers an excellent API accessible over qemu/KVM via shell (virsh), GUI (virt-manager) and Web (cockpit) .
To use libvirt, properly you need to make sure your standard user is member of the libvirt group, and the libvirt default network is started via virsh net-autostart default.
Also make sure you set export LIBVIRT_DEFAULT_URI=qemu:///system to use the system wide instance of libvirt, which is needed for the default bridged networking.
Once the VM is created you have now three ways to access it:
# open a serial console to the VM
$ virsh console dev-vm
# access the graphical console
$ virt-manager
# Access the VM via SSH with the precreated cloud user "debian"
$ virsh domifaddr dev-vm
Name MAC address Protocol Address
-------------------------------------------------------------------------------
vnet7 52:54:00:23:e6:61 ipv4 192.168.122.225/24
$ ssh debian@192.168.122.225
In the next blog post we will see how to configure the IDE (vscodium) to run confortably in the VM.
things running directly in my workstation will require either to come from a trusted source (Debian package that is) or run in a sandboxed infrastructure (Podman rootless is the best thing here, followed by Flatpaks)
everything else, will run in a Libvirt VM based on Debian cloud images. For me it will be mostly in the beginning the VSCodium editor, with its myriad of extensions.
I am aware of whole blown solutions like QubeOS however I don’t indent to reinstall the whole OS, and QubeOS does not run on ARM64 which is one of the environment I am using.
I will try to document this setup in two blog posts, one about the VM creation using Debian Cloud Images, the second one about running a graphical env in the VM with some filesystem passthrough. Stay tuned !
I have just sent an open letter to the Board of the Wikimedia Foundation, the umbrella organisation for Wikipedia (and a number of other projects), expressing my support for Wiki Workers United and the unionisation effort by WMF staff.
Here is the letter:
To: Board of Trustees, Wikimedia Foundation
via Wikimedia_Foundation_Board_noticeboard and WWU
published at https://diziet.dreamwidth.org/21442.html
Re: My support for Wiki Workers United
Dear Trustees
Wikipedia has become one of the pillars of the free and open Internet.
Across the world, reliable sources of information are under attack.
I'm proud to have played my very small part in the community of
editors of English Wikipedia for the last 20 years. I am also proud
of my contributions to the Free Software movement, including
especially Debian. Debian, whose constitution and package installer I
originally wrote, has become one of the technological foundations of
the open Internet.
Unfortunately, there are signs that the Wikimedia Foundation is not
performing its proper role as bulwark against attacks on democracy,
including from moneyed interests. Recent events at WMF have been very
alarming to me, and seem to form part of a disturbing trend.
As a Trustee Director of a UK charity myself, I understand that WMF
Trustees must defend the interests of the Foundation. But that cannot
mean taking actions that undermine the Foundation's mission. Nor can
it mean the deplorable, and even dishonest, practices, that WMF
appears to have been engaging in.
As a Wikipedian, as a Free Software activist, and as a citizen of the
planet, I stand in solidarity with Wiki Workers United. Union-
busting must stop immediately. The Foundation should immediately
formally recognise the unions in the UK and the US.
Further, WMF is an international organisation. Collective
decisionmaking needs to be transnational too. WMF should recognise
WWU as a negotiating partner worldwide, even if thresholds for formal
legal recognition are not met in individual national jurisdictions.
Wiki Workers are not the WMF's enemy. WMF needs capable and
ideologically committed staff to maintain and operate its highly
complex systems, in the face of constant attacks. Staff with
principles and a mission are WMF's biggest asset.
I’m really enjoying getting back into ice skating, but I can only get to the
rink once a week (at least over the summer -- I'm aiming for twice weekly once
Schools re-open) and I have the itch to do more skating than that.
Where I live we’re blessed with a seaside park with lots of smooth paths, a
recently resurfaced beachside promenade, and a newly-built
pedestrian/cycle path stretching up and down the coast: all great surfaces for
roller skates. I convinced myself to buy some inline skates whilst the weather
is good.
I wanted something as close to my ice skating experience as possible. Bauer
actually make an inline version of my ice boot, but the chassis is an unusual
composite plastic thing which put me off. (here's a great video of a fantastic
inline skater trying out the chassis).
CCM have a new inline range for 2026, but sadly (much like their Jetspeed ice range)
the fit wasn't good for me.
I found a clearance pair of Bauer vapors from the previous generation: the Bauer Vapor x4. Very
similar to my Fly30, but the difference in quality between the tiers is very
apparent: boot stiffness, the comfort and quality of the liner.
They fit well (possibly better), the rolling motion is
really smooth (I think that's the bearings) and they looked pretty good to me:
yellow highlights instead of the red used across the ice range.
I've done a couple of miles in them so far. Time will tell if they prove useful
for off-ice training! Many inline hockey players buy ice skates and convert
them to inline. If I end up not using them enough I could consider doing the
opposite.
Last month, I attended DebConf 2026 in Santa Fé,
which was my 5th DebConf. As always, it was an amazing experience, and I
met a lot of great people there.
For those unfamiliar with the event, it takes place over the course
of two weeks. The first week is called DebCamp and is geared more
towards hacking and organizing the event itself, while also offering a
great opportunity to discuss ideas with others. The second week is the
DebConf. We still have the hacklabs, but the talks and workshops are the
main focus.
My Activities during DebCamp
My main activity was working on the python-click
transition that I started in May. There were only a few packages
left, and with the help of Guilherme Puida, we managed to work through
all the remaining bugs.
I plan to talk in details about this transition in another blog post,
where I will focus on the tools I used and my experience with mass
rebuilds and mass bug filing.
There was a lot of manual, repetitive work and false positives, so I
eventually moved on to some other, more fun stuff.
I also learned a few thinks about kernel live patching while talking
to David Tadokoro. I had to work on the Ubuntu Kernel package recently
as part of my job, so we exchanged some ideas, and the conversation was
really helpful.
He also taught me two commands that I wasn't familiar with, since I'm
a newbie in kernel development. Here are the commands:
$ b4 am https://lore.kernel.org/lkml/20240730071904.1047-1-sergiosacj@riseup.net/
$ b4 diff *mbox
By the way, this is the first and only patch I have submitted to the
Linux Kernel. I worked on it during DebConf 2024, when I attended the
workshop Helen Koike runs to help newcomers submit their first patch to
the Linux Kernel.
Another great interaction was with Marcos Talau. He showed me his
remote access setup, which he is using to help students make
contributions to Debian without the struggle of setting up the
development environment.
Another cool thing is that Puida showed me the command:
$ gbp clone vcs-git:typer
After that, I decided to read the gbp manpage because these little
details really improve the overall experience.
I also had many other amazing interactions. I just decided to write
down the ones that I felt made the most sense for this kind of "blog
report" post.
My Activities during DebConf
I gave a talk
about dh-make-vim, a
tool I have been working on sporadically. An interesting detail is that
one of the video team volunteers for the talk, Piotr, spoke to me about
his tool, pypi2deb, which is similar but aimed at the Python ecosystem.
There are many tools of this kind in Debian, and they are all
interesting pieces of software. I plan to write more about them in the
future.
I attended several talks and participated in a few BoF sessions, and
they were all great. But something that really stood out to me was the
workshop on the Debian Installer, led by Alper Nebi Yasak. I didn't know
anything about the Debian Installer, and I liked the way he approached
the subject and showed the specific details.
Another maintenance release of RcppMsgPack
got onto CRAN today. MessagePack itself is an efficient
binary serialization format. It lets you exchange data among multiple
languages like JSON. But it is faster and smaller. Small integers are
encoded into a single byte, and typical short strings require only one
extra byte in addition to the strings themselves. RcppMsgPack
brings both the C++ headers of MessagePack as well as clever code (in
both R and C++) Travers wrote to access MsgPack-encoded objects directly
from R.
This release is once again chiefly maintenance. Besides standard
upkeep to the README.md and continuous integration setup we had to add
one #include. The clang++-23 compiler, when
also running with its own library, now now needs the
type_traits.h header file (in the upstream MessagePack code) so we added that. No
other changes, so no user-facing changes. Details follow from the NEWS
file.
Changes in version 0.2.5
(2026-08-19)
Explicitly include header "type_traits.h" to appease
clang++-23
Standard maintenance updating continuous integration, adding
minor helper script, and updating README.md
In a post to oss-security, my (Debian) co-developer Russ Allbery
stated that "open source software [OSS] is coming face to face with a
motivation crisis that has been building for a long time". His point
is essentially that large language models (LLMs1) are making the
existing OSS community crisis worse. For him, it's the flood of code
reviews, but he argues that varies according to people's desires, for
others it's security issues and so on.
I think Russ is right, but I would argue there's something much bigger
than our open communities going on here, and it's about the entire
field of computing. This pressure is on all of us, regardless of
whether we work on open source software or not.
How people use models
People using LLMs in their workflow have radically changed how
programming works, even for people who claim to avoid
vibe-coding. And I'm sorry to single out one poor maintainer here:
it's not you, Brian, you're just one example among many. But this is
typical use of those models nowadays:
Once it’s done, I’ll use /code-review and let Claude spawn
sub-agents to do a full review of the new code. This usually finds
some problems, even problems that the “main” Claude instance didn’t
find during its validation. I usually keep running /code-review
again and again after finding and fixing issues, until there aren’t
any left.
Think about what that means for a minute. This is automation built to
fire up dozens of agents crunching at a problem for minutes if not
hours of GPU compute time, in parallel. This is essentially a couple
of shelves in a datacenter rack, totally maxed out on power and
cooling, abstracted behind a cute little /code-review command.
The author, here, is rightly concerned that "Anthropic could pull the
rug out and require API pricing", which is perhaps a code word for
"charging something closer to actual costs". Brian also pays lip
service to environmental and societal costs but those are largely
abstracted away, so let's keep that conversation aside here as well,
as we have discussed it before anyways.
But clearly, this way of working has an (externalized) cost, to
say the least.
Paying for non-free tools
For decades my work has been focused on free and open source
software. I've long stopped using proprietary operating systems like
Windows or Mac, and even before that switch, I was mostly using free
software on those platforms, partly out of principle, but also because
I was too poor. So the tools of my trade are free, and I build free
tools with them.
It feels like we're going backwards: when I was in school, a millennia
ago, my classmates didn't have access to a compiler and were wondering
how they would scrape the money to buy a compiler like Borland's
or Microsoft's. I had a compiler built into my operating system
(FreeBSD at the time), so that wasn't a problem for me. For them,
it was a significant expense, but at least those expenses (or more
shady sourcing of programs) were a one-shot deal.
Fast forward 30 years, and software is rented: you pay monthly for
Adobe's Photoshop and Microsoft's office suite just like you pay for
Netflix, Disney+ or Spotify2. And now you need to add dozens (if not
hundreds of dollars) of monthly credits to access LLMs on top of that.
So, now we have to pay to get anything done? This is peak
enshitification of our job: first they steal our work to train their
models, and then they sell it back to us at a profit.
Attacking the engineers
AI is coming for our jobs, as engineers, if not everyone, according
to the narrative. For a while now, our job market has deteriorated:
less jobs, for less pay. Lots of skilled engineers looking for work
and finding crap jobs then still looking while working.
This is not by accident.3 We engineers have a lot of power, it is not
organized, but that's just a couple of unions away (easy!). Tech
overlords know this, so they are attacking our profession, directly,
by forcing us to train and use models that they can control.
Even in environments where programmers are not forced to use LLMs,
the mere pressure of other people's LLM-generated work is huge. One can
be forced to review LLM outputs, or just peer pressured you into
producing more.
We're now supposed to accelerate delivery, because models can
presumably do things so much better and faster. With supply chain
security becoming such a large vector that we now have worms crawling
around developers accounts on NPM, increasing the delivery cadence
seems like a really bad idea.4
The LLM hype is part of the larger wave of cyberwar against workers,
against water, against the Earth, against all the people. This is not
a matter of individually "adapting to the reality" or personal choice,
but a political, social, hard problem we need to address collectively.
I again prefer the term LLM to "AI" because models do not
possess intelligence. I did use it in the title because
click baiting is apparently important, but I stopped short of
calling this one "Rage Against the Machines" because that would be
the title of every blog post I have ever made.↩
Yes, I know that Visual Studio is kind of free now, but I
wouldn't be surprised if they turn that into a rental as well,
because why not.↩
Beyond sabotaging the job market, Sam Altman event wants to
sell "intelligence as a utility" something that is just a
really bad idea but especially shows how megalomaniac those
people are.↩
This brings back memories of another era, walking us
back decades in terms of computer security.↩
A couple of weekends back, I upgraded my home sever. It failed to restart after running apt dist-upgrade
The only update that was performed was to the kernel, it went from 6.12.88+deb13-amd64 to 6.12.100+deb13-amd64. I had previously performed an apt-get upgrade, and rebooted the machine, so I was pretty sure that this was to blame. This blog entry (is a late) attempt to document how I went about finding a fix for this issue so that next time I don’t need as much hand holding as I did this time around :-)
(1) Having my machine not boot following an upgrade is pretty rare, but has happened before. Usually it is because I have done something wrong so as always confirming I haven’t broken something by accident is always my first step…
I plugged in a keyboard an monitor to the machine and watched it boot. Being a server this takes a long time (I guess because at this stage of system initialisation we want to test things sequentially)
Watching the system boot I see the usual BIOS/UEFI stages for this machine, followed by the grub menu and the the local screen showed:
Loading Linux 6.12.100+deb13-amd64 ...
Loading initial ramdisk ...
Nothing else. That was it. OK that looks like I have a broken system all right, and at very early stage of the boot process process.
(2) Breaking into the grub menu and removing the quiet option yields a little more information (but not much):
Loading Linux 6.12.100+deb13-amd64 …
Loading initial ramdisk ...
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID d
evice path
EFI stub: Measured initrd data into PCR 9
and nothing else.
(3)Initial debugging
Confirmed that I could still boot the machine with the old kernel 6.12.88+deb13-amd64 (During boot select Advanced options from the grub menu followed by the kernel image wanted)
Yes – the system starts happily with the previous kernel
Checked that /boot had enough space
Yes – plenty of space
Is anyone else reporting this problem?
Nothing jumps out on Debian’s bug tracker
Actually not mush referenced for my search “EFI stub: Measured initrd data into PCR 9 apart” other than the usual rantings to “turn off secure boot” (on this server that currently isn’t turned on – bad me)
(4)Triage
Start looking for where the fault first occurred. At this point I needed help, and given that Sledge was visiting I asked if he would sanity check what I was doing. His initial thoughts were that that /boot had run out of space, but replaying my step (3) with him acting as a ‘rubber duck’ showed that this was something other than PBKAC
Sledge had a quick look, then informed me that between kernel images 6.12.88+deb13 and 6.12.100+deb13 Debian stable has only had shipped .90 .94 .95 and .96 kernels. We could easily try them all:
wget each kernel package then install (dpkg -i) followed by an update-grub, checking that there was sufficient space on disks especially my small /boot partition)
I started with image 6.12.95+deb13 and this worked
6.12.96+deb13 yielded the same lock up on boot as 6.12.100+deb13
OK I now have the first kernel image that doesn’t boot on my system, time to raise a bug…
Up until now I have been walking to my garage where the server is located and standing in front of a rack with a monitor and keyboard plugged into the machine. However this machine supports IPMI so I spent a little time getting that up and running so that I can continue from the relative comfort of my desk (with lights, a chair and not needing to hold the keyboard with one hand)
Great I can now grab screen shots from the confort of my desk (unfortunatly they are only screen shots not text files, but at least we can seen the early stage of boot, Post, grub menu and then initramfs before system log happens)
(5) Collating information for the initial bug report
Sledge had mentioned my problem in irc/#debain-kernal where iam_tj suggested that we try appending ‘debug earlycon=efifb’ to the kernal command line. This yielded 15 seconds worth of messages before the system locked up the last few messages being (vmlinuz-6.12.96+deb13-amd64):
[ 14.663477] RCU Tasks: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. [ 14.750474] RCU Tasks Rude: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. [ 14.838024] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20. [ 14.929752] NR_IRQS: 524544, nr_irqs: 584, preallocated irqs: 16 [ 15.016814] rcu: srcu_init: Setting srcu_struct sizes based on contention. [ 15.104011] Console: colour dummy device 80×25 [ 15.191236] printk: legacy console [tty0] enabled [ 15.278249] printk: legacy bootconsole [efifb0] disabled
Booting the working kernel with the same kernel options yields the SAME messages with slightly differing times, but then continues to login prompt:
[ 14.697466] RCU Tasks: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.784936] RCU Tasks Rude: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.872067] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.964000] NR_IRQS: 524544, nr_irqs: 584, preallocated irqs: 16
[ 15.051482] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 15.226079] printk: legacy console [tty0] enabled
[ 15.313751] printk: legacy bootconsole [efifb0] disabled
[ 15.400831] ACPI: Core revision 20240827
[ 15.401415] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
[ 15.401464] APIC: Switch to symmetric I/O mode setup
... and so on
iam_tj also suggested adding keep_bootcon – with ‘debug earlycon=efifb keep_bootcon’ on vmlinuz-6.12.96+deb13-amd64: We get a LOT further – and we see a crash / trace-back:
I raised bug #1143721 and followed it up with screen captures of the boot sequence (captured from the IPMI client) and files containing the output of dmidecode, lscpu and lspci to kive the kernel team as much information as possible:
The problem with this type of bug is that it is hardware (class) specific, whilst the kernel doesn’t boot on my system, it clearly has worked on machines used by the kernel team, the Debian test and build infrastructure, (otherwise this kernel would never have been released) and everyone else who has upgraded to the newer kernel before I did (otherwise we would be drowning in fails to boot bug reports). Carnil’s excellent response to my bug: Message #15 (and help in IRC) provided me with a detailed step by step guide in how to track down the individual git commit that fails on my system. I had already (with Sledge’s suggestion) made a clone of the stable branch, but was struggling to follow the steps in the Debian Linux Kernel Handbook to re-build a duplicate kernel because I didn’t understand how to obtain the same configuration that Debian used to build the kernel; Carnil’s email provided me the missing steps (Highlighted).
git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.12.95
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_def
test 6.12.96 to ensure this is "bad"
git checkout v6.12.96
make my_defconfig
make -j $(nproc) bindeb-pkg
… install the resulting .deb package and confirm it fails to boot and triggers the NULL pointer dereference.
Right I can now start to Bisect the problem:
git bisect start
git bisect good v6.12.95
git bisect bad v6.12.96
Rather than use the half step point’s git bisect suggested I was advised in irc to jump straight to the a given commit that from the git log was suspected as the culprit:
git checkout 977855894bca4b87afa50d21e3f3e85a5a0e901f build and install…. fails… git bisect bad
git checkout 977855894bca4b87afa50d21e3f3e85a5a0e901f~1 ## ~1 is the commit beforehand build and install…. fails… git bisect good
The entire test tree can shown with git bisect log and this was submitted as an email to the bug report, we have found our smoking gun :-)
Finally I would like to thank Carnil, Iam_tj for their time patience and fantastic support in guiding me through finding this regression. Right now kernel bugs are coming in thick and fast with a lot of AI assisted bug hunting, the increased numbers of bugs mean that the kernel team are especially busy. Hopefully our paths will cross and I’ll be able to buy you some beers (or whatever) soon. thank you. Sledge also deserves thanks for putting up with me and pointing me in the right direction (as ever). Lucky for me that he lives nearby so I can provide beers on a regular basis :-)
LLMs have finally made it to the ultimate stage of Debian’s governance processes, a General Resolution of all the project’s full governing members (DDs).
There are a lot of options on the ballot, and they all have a different structure and approach the question in a different way. It can be hard to see the wood for the trees. I have made a summary table to try to capture the main differences, both in effect, and sentiment.
Before voting, I encourage you to read the passionate rationales in options H and A, or at least the summary in my option C.
Few of the LLM defences in the discussion threads, and none of the LLM-positive proposals, provide answers to any of these profound ethical concerns, many of which ought individually to be a deal-breaker. Instead, these crucial questions are simply dismissed or even ignored.
Some will tell you we should “keep politics out of software” but as we can see in the world around us, software is political - now more than ever. Debian’s mission is a highly political one: developing a fully-free operating system, and defending its freeness as we do, is far from neutral!
And of course many of LLMs’ harms affect Debian directly.
I have tried to present the options in semantic order, with most LLM-negative proposals to the left, and the most LLM-positive to the right.
I have not quoted the one-line titles for the options. These have generally been provided by the proponents of each option, and, unfortunately, some of them are IMO quite misleading.
Note that, unfortunately, the voting software likes to assign numbers to options but also to preferences. Be mindful of this possible confusion when casting your vote. For clarity I quote only the option letters.
Some of the proposals acknowledge the uncertain legal status of LLM output. But all of them implicitly or explicitly assume that LLM output is or can be DFSG free. So none of the proposals forbid upstream projects with LLM-generated contents.
None of the proposals would require us to go back to pre-LLM versions of the upstream projects we use, and attempt to fork and maintain them. I very much think there is room in the world for people to try to do that, but I don’t think the Debian project can be that effort.
Given that the conclusions are the same in each case, whether the matter is discussed does not seem to me to be a significant difference. I have therefore not included a column for it.
My proposal has a specific paragraph (7) explicitly permitting teams to set a “no LLM” policy. The other proposals do not discuss this point specifically. During the discussion, it seemed that most participants agreed that even options which explicitly permit LLM use generally do not prevent a team from setting its own more restrictive LLM policy.
Few of the permissive texts are absolute or unconditional. To summarise I have necessarily left out some nuance.
So for example when an entry says “permitted”, that generally means “permitted with conditions which are believed by LLM users to be readily satisfiable” (for example, DFSG-compatibility - see above).
Proposal B does mention that there are “concerns” about LLM use. But it fails to make an explicit statement about whether these concerns are justified.
It then proceeds exactly as if they are not justified. IMO “disregarded” is a relatively mild term for such a rhetorical technique.
Edited 2026-08-18 09:02 UTC to make the proposal letters in the table be links.
For human developers, using coding LLMs magnifies their difference in skill levels.
I am one that rarely thinks things are always black and white. Back in March, I wrote Artifial Intelligence: Shades of Gray. Since then, I’ve had more of a chance to experiment with LLMs myself. I also happen to work for an employer that is taking a very pragmatic approach to LLMs: teams and individuals use it as they see fit, but if they are causing considerable expense, they have to justify it.
In various settings, I have seen the egregious examples of AI slop we all know about. As I wrote in March, “I have seen it both waste more time than it saves, and save a ton of time.”
I have come to see that, as a tool, it is most valuable when it is running under the supervision of an experienced engineer. It is at its worst when it has no such supervision; the “vibe coding” and other low-quality slop we see.
A coding agent is like a junior developer or research assistant. When properly supervised, they help projects move along more quickly by letting a senior developer focus on the more difficult, less mundane aspects of the project. But one couldn’t expect a junior developer to consistently deliver high-quality code and architecture on their own.
Let’s put a pin in this idea and look at the story in Debian.
LLM use in Debian
There is a vote happening in Debian around the use of LLMs. In typical Debian fashion, there are 8 options to choose from, many of them similar. Most of these proposals acknowledge there are different types of tasks done in Debian, but the proposals don’t differentiate between them well. Let me do so here. These are some of the LLM-relevant tasks people in Debian perform:
Packaging upstream software for Debian (by far the largest task)
Writing Debian-specific code (eg, apt or the Debian installer)
Maintaining Debian infrastructure (build systems, for instance)
Writing documentation and translations
I’m going to focus my remarks here on packaging upstream software for Debian, since this is by far the most time-consuming developer task project-wide.
It matters to our users that we get this right, and packaging quality is one of the things that sets Debian apart from other distros. Packaging things for Debian requires knowledge of some specific tools, such as debhelper, that aren’t widely used anywhere else. In most cases, it is fairly rote time-consuming work. In other words, by its design, it requires people with senior-level skills to do grunt work.
I can’t overstate how massive a burden this grunt work is. I maintain some packages for Go and Rust. By Debian policy, all of those packages’ dependencies must also exist as Debian packages, and be used to build against. When upstream adopts a newer version of some library, it can unleash cascading dependencies that can take hours to sort out. Worse, the Rust team and the Go team use entirely different ways of managing packages (Go uses one Git repo per package, while Rust has a monorepo with specialized scripts to import Cargo packages and generate Debian ones). On top of that, we can’t just modify things like usual; we have to use quilt. And on top of that, I’m also a backports maintainer, so all the work (and usually even more) has to be done there also.
Now let’s pull on that pin from the earlier conversation. This is exactly the kind of scenario that a well-supervised coding LLM is most effective in. I could see a seasoned developer saving hours, maybe even days, by turning over the mundane tasks of managing trees of cascading dependencies over to a coding tool — and verifying and directing the process. (Yes, I have been using em-dashes for years; LLMs have copied people like me, not the other way around! This post was not written with any AI assistance.)
Actually, this is almost a dream scenario for a coding assistant. The result is time-consuming to formulate but easy to review, which is the opposite of the way these things often go.
I can assure you with 100% certainty that humans aren’t adding a lot of value in this process. It would be wrong to believe that a human is carefully reading every line of code in dozens of updated or new library packages. The problem set is too big, the time too short, and the code too varied and complex.
Coding agents seem to be most effective when there are strong test suites that they can test changes against. Debian builds, especially of modern packages, tend to have this property. Many packages have test suites that are run during build. And, if the package builds in an isolated environment (and especially if its downstream dependencies do also), then there is a decent chance that it’s fairly correct. Maybe needing some manual tweaking here and there, but generally a successful build is a reasonable indicator.
You can argue that it would make more sense for Debian to just include dependencies in source packages, along with some version information to support security rebuilds, and I’d tend to agree with you. But we are where we are. This would be one of the more significant leaps forward in developer productivity, but it complicates things like copyright reviews.
Where are LLMs run? What is the environmental impact?
Most of the proposals seem to make the assumption that LLMs must always run in some large, hosted datacenter. As I noted in my March article, I have had credible results on even an older GPU running on solar power.
That said, it is undeniable that LLMs are fueling a datacenter boom, and this in turn is producing a significant new demand for resources. Most notably for the global scale: electricity, which is sometimes generated using carbon-emitting technologies.
Bill McKibben, who has been a leading voice in the fight against climate change since the 1980s, has made some interesting points recently: he’s noted that solar power is the fastest kind of generation we can build, and a number of large AI companies are investing heavily in solar, even to the point of fully offsetting new datacenter’s needs. On the other hand, he’s also noted that some companies are buying inefficient and dirty gas turbines. It is decidedly a mixed bag. The heavy investment in solar can have knock-on positive effects for infrastructure. Obviously, not every picture here is rosy. This analysis doesn’t touch on the real land and water use situation, either.
On the other hand, if an LLM allows me to do in an hour what I would have done in a day, that’s a day of not heating or cooling the work area — generally not sustaining a human for the purpose of writing code for Debian. HVAC energy consumption dwarfs my GPU, and I’d imagine probably also the slice of LLM energy used.
Holistically, I would have to conclude the picture is mixed. It is possible to use LLMs in a pretty green way, and also in a pretty dirty way.
Assuming Conditions Never Change
A flaw in most of these proposals is they assume that the conditions at this present moment will always hold. In fact, that the conditions at the present moment will not continue is something both AI cheerleaders and AI skeptics agree on.
For instance:
Ed Zitron has done a ton of research into the financing side of AI, and has concluded that the current model is unsustainable and headed for a significant bubble burst. I’m not positioned to personally evaluate those claims, but if that happens, what is the result? Perhaps it is a steeply increasing cost of inference for the frontier models, slower pace of training/evolution for them, etc.
In a recent episode of Oxide and Friends, Simon Willison discussed the open weight models that are now available. They have been making remarkable strides in efficiency and capabilities, to the point where $50,000 of hardware can now run high-end open weight models with capabilities that are at least in the same ballpark as the American frontier models. This puts running high-end models locally squarely within reach of universities and small- to medium-sized businesses, with power requirements that can be met with standard commercial solar and wind installations.
The lack of nuance in the more restrictive proposals is particularly concerning. Proposal A doesn’t allow “the use or assitance of… LLMs”. So it bans my solar-powered GPU. It bans using LLMs to find security issues. It bans all sorts of things that don’t seem to be ban-worthy, alongside the things that do. And it codifies it in the very hard-to-change social contract.
That proposal, and some like it, seem to imply that all LLM output is bad. I grant you that AI slop is a real and legitimate concern, and many Open Source projects have to deal with it. On the other hand, we have all seen first-hand how the security of the Linux kernel has benefited dramatically from AI analysis. It is certain that black hats are using these tools. If we refuse to use modern security tools, our security will be compromised (and what is the environmental and social impact of THAT?)
I find the statement “Generative AI is characterized by producing output of a nature that would ordinarily be produced and consumed by humans” to be particularly interesting. The same was once said of compilers.
The Real Concerns
You might think from reading this that I am some AI cheerleader. I’m not. I share the ethics of the FLOSS movement, and have for decades. I abhor the power and lack of ethics that many big names in the field are running with at the moment. I’ve had to put up Anubis on this blog, for instance.
I have personally experienced the effects of AI slop, especially at review time. This is a real problem, though I don’t think the more draconian policies are likely to help (the looser “you must disclose” stand a fighting chance, but I’m not sure they would help, either.) Done poorly, AI threatens developer burnout by overwhelming them with poor code and verbose but useless explanations. Done well, AI can help prevent developer burnout by automating tedious and low-value tasks.
Shouldn’t our goal be that humans submit work to Debian, using tools they prefer, and take responsibility for it? Does it matter if someone uses ed, vim, emacs, or vscode? If they use LSP or just run gcc manually? I’d say we benefit from the diversity. Wouldn’t we be better off to benefit from the diversity here, and judge work as we always have: on its merits, not what tools were used to create it?
Fundamentally, a GR is a long and arduous process. It’s not easy to reverse later. Amending the Social Contract is even longer and more arduous (I should know; I may have been the first one to try). The LLM landscape is fast-moving. None of us can really predict where it will be in a year. Will the current market leading companies even still exist? Will it be at all credible to refuse to use AI-assisted security tools? What is the most effective way to deal with AI slop? What level of utility will we be able to achieve with models run locally?
Some of these proposals would make sense if drafted in some way short of a GR, which would allow more maneuverability as the landscape changes.
Brief analysis of the options
Considering the proposals:
Proposal A: seeks to amend the social contract, which I am opposed to for reasons already laid out above. It names some real concerns about AI that I agree with, but implies that all LLM uses and models are guilty of the problems, which is not the case with all of the claims. It also sets us behind the curve on security and stability by forbidding the use or assistance of those tools, even if run by others. It requires us to ignore reports of actual security bugs, or correct fixes, if those reports were generated with the assistance of an LLM, which I find to be absolutely untenable.
Proposal B: This is the “AI with accountability” approach. It notes the real concerns with LLMs without painting with an overbroad brush. It strikes me as level-headed and sensible.
Proposal C: It paints with an over-broad brush and makes some non-binding requests. Then it winds up largely like proposal B, though while it is worded more strongly, has fewer binding requirements (for instance, it lacks proposal B’s prohibition on transmitting sensitive information to untrusted providers)
Proposal D: Seems broadly similar to proposal B, an “AI with accountability” approach. I’m not really clear why we need both.
Proposal E: Largely the status quo. It is like proposals B and D in that it says humans are accountable for their contributions. It encourages disclosure of LLM use, but does not mandate it. Like proposal B, it prohibits disclosing sensitive information to third-party AI services. Note that both proposals B and D have an appropriate nuance: a local model is fine, a third-party one is not.
Proposal F: This seems really similar to proposal E. I’m not sure why we have these two.
Proposal G: Disallows “the output of generative AI as direct contributions to Debian.” This is something of a weakened proposal A; it doesn’t seek to amend the social contract, nor does it ban all use; it simply bans the use as a direct contribution.
Proposal H: Ban due to climate impacts. “How is this even an argument” is disrespectful to reasoned conversation. I have already noted that LLMs can be and are used in ways that are not climate-harming. It explicitly contains no binding requirements at all, and is effectively a rant. While I agree with the sentiment that climate change is an urgent problem, and that some LLMs are exacerbating it, I disagree with that all LLM usage does so and therefore disagree with the conclusion.
In favor of nuance
I find that black-and-white thinking is almost always something to be avoided. I see it too often. I see it in politics, I see it in our software, I see it in discussions around AI. Are there deeply unethical things happening in AI? Absolutely. Are they doing some impressive things? Also yes.
We have accepted this nuance in other areas. For instance, almost all the hardware Debian runs on has closed-source hardware, and has components manufactured or assembled in countries with some of the worst human rights records on the planet. I’m not saying this is a great state of affairs. It is something we should speak up about and act upon. But the worse state of affairs would be “no Debian because the hardware is impure”.
It has now been thirty-three years since the Debian project was announced to
the world by Ian Murdock, on August 16, 1993. This anniversary is an
opportunity to reaffirm the goals, characteristics, and qualities of the
Debian project: it’s an association of individuals who have made common cause
to create a free operating system. Our distribution is characterized by a
commitment to software freedom, as enshrined in the Debian Social Contract
and the Debian Free Software Guidelines. It focuses on security and
stability. This stability is crucial to Debian position in the free software
ecosystem.
With our users as our priority, Debian makes special efforts regarding
accessibility with Debian-Accessibility and diversity with our Outreach
Programs.
Debian Day is a great opportunity to get together, whether for a local meetup,
or simply to grab a coffee with other members of the Debian community. Check
out the Debian Day wiki to see if there is a celebration near you. And if
there isn't, maybe you can organize it next year!
Today is also an opportunity for you to start or resume your contributions
to Debian. For example, you can install the how-can-i-help package and
see if there is a bug in any of the software that you use that you can help
to fix, contribute small tips on how to install Debian on your machines to our
wiki pages, or put a Debian live image in an USB memory
and give it to some person near you, who still didn't discover Debian.
Thanks to everybody who has contributed to develop our beloved operating
system in these 33 years, and
Happy birthday Debian!
I made another minor release with several enhancements: handling non-Debian
origin vulnerabilities, improving data caching, and sharing the cache
between the debvulns CLI and the exporter. Additionally, there are a few
improvements on the dashboard front. Here is a breakdown of what changed.
Handling Vulnerabilities in Non-Debian Origin Packages
During the previous release, I noticed that the grafana package—which is
not in Debian and was installed via an upstream repository—was reported as
vulnerable with multiple issues. Looking into why this happened, I found that
all the CVEs reported in the dashboard were indeed listed on
security-tracker.debian.org, but without a fixed version or status
description. The logic assumed no fix was available and marked the package
as vulnerable on the dashboard.
How Did I Solve This?
Google maintains a distributed vulnerability database for open-source
projects called osv.dev. I checked the generic vulnerability
data for those CVEs on OSV (unbound to any specific distribution) and found that
the issues were already fixed in the upstream version I was running. What I
needed was a way to differentiate native Debian packages from non-Debian
packages, which corresponds to the Origin field in APT metadata.
Pitfall
The AI-generated code initially attempted to differentiate package origin using
apt_pkg.PackageRecords and its origin field. However, many native Debian
packages were incorrectly flagged as non-Debian. On closer inspection, when an
upgrade is available for a package, the installed version's origin field can be
unset. I had to resolve this by detecting available upgrades and inspecting the
candidate version's origin instead, which was implemented in this patch.
This solution was proudly crafted by me ;-) (partly because I ran out of API
limits and had to wait 6 hours for the next reset).
Caching OSV Data
Initially, the AI implemented the exporter to re-download the entire OSV dataset
on every run, which was unnecessary. Since vulnerability data does not change
rapidly once published, caching it on disk for longer than the standard 24-hour
Debian/EPSS cache makes sense. OSV vulnerability data is now cached for 7 days
before a refresh is triggered.
All cache expiration thresholds remain configurable via CLI flags.
Catch
One caveat with this approach: I have not yet verified whether every upstream CVE
is tracked on security-tracker.debian.org. In the case of grafana, the
entries existed. This feature operates on the assumption that
security-tracker.debian.org indexes CVE metadata regardless of whether the
package is native to Debian. I plan to re-evaluate this and add fallback handling
if that assumption fails.
Unified Cache Directory for CLI and Exporter
Another issue was cache segregation: the debvulns CLI utility defaulted to
/var/cache/debvulns, while the Prometheus exporter used
/var/cache/debvulns-exporter. While harmless when running only one tool,
installing both led to duplicated cache storage and redundant network requests.
Since the core evaluation logic is identical across both tools, they now share a
unified cache directory to eliminate duplicate downloads.
Dashboard Changes
During the initial dashboard rollout, my test environment (my laptop alongside
Debian 11 and Debian 12 VMs) reported a high aggregated vulnerability count.
It was not immediately obvious whether these were distinct vulnerabilities or the
same CVEs replicated across all three machines. This mirrors common questions
raised during vulnerability reviews:
How many unique vulnerabilities are present across the fleet?
Which unique packages are affected?
The dashboard has been redesigned to surface unique vulnerability counts
alongside affected package lists. The updated dashboard is shown below:
What's Next?
A few planned items remain to make debvulns a comprehensive vulnerability
reporting toolkit for Debian systems:
Kernel Vulnerability Handling: Currently, installing a patched kernel
marks the vulnerability as resolved, even if the system has not rebooted into
it. The system remains exposed while the vulnerable kernel is executing in
memory. Factoring in running kernel versions is crucial.
Reboot and Service Restart Tracking: Similar to kernel upgrades requiring
a reboot, userland library and binary fixes require running services to be
restarted. This is typically detected via needrestart. Integrating this
behavior directly into debvulns will provide complete visibility in a
single dashboard metric.
Debian Packaging: Once the above features are stable, the final step is
packaging debvulns for Debian so it can be installed directly from the
archive.
I was pondering for the past three years if I should give some sort
of TLS basics talk at FrOSCon. I finally stepped up this year
and gave that talk today, with the title
"TLS, mTLS, SNI, ECH, CAA, HTTPS, PKI, Zertifikate und ein bisschen PQC".
I was too optimistic with my 50 slides, and had to drop the
Post Quantum Cryptography part at the end. Still got positive feedback from
Zugschlus and others - thanks a lot for that <3 - and was asked for the slides.
It's not a piece of art, but maybe it helps to release the LibreOffice odp file
as well, so others can use it as a base for other events or corp internal talks.
So here is the
froscon-tls-2026.pdf
and
froscon-tls-2026.odp,
both released under the CC BY-NC license.
The video is also available at
media.ccc.de if you want to watch it.
Thanks to everyone who made FrOSCon happen for the 21th time!
On 2026/08/10 at 2:11 am Australian eastern standard time (2026/08/09 16:11 UTC) someone created a post titled “Hacked by Chinafans” on my documents blog [1]. The person in question created an account named “67965e42a3c3” on that site with the email address 67965e42a3c3@google.com associated with it (I tried emailing that address and it bounced).
At 04:28:41am Australian eastern standard time (18:28 UTC) I was sent an email titled “Have you been hacked” by a reader of my blogs who subscribed to the RSS feed of my documents blog (a blog that I never expected anyone to read by RSS). Along the lines of “the wisdom of crowds” should we have “the unexpected observation and problem reporting of crowds”? I appreciate the notification, I might not have noticed until the next time I watched an unusually good movie otherwise.
The account in question was apparently created on 2026-07-21 at 16:43:47 (presumably UTC) even though at the time I believe creating accounts was not permitted. As an aside the timestamp of account creation is stored in the user_registered column of the wp_users table in the database, there doesn’t appear to be a way to access this in a standard WordPress installation other than doing a SQL query.
Above are the relevant sections of my dpkg log showing the WordPress versions in use. I was running version 7.0+dfsg1-1 at the time the account was apparently created. I am confident in the accuracy of the dpkg logs and believe that they did not compromise the OS, I am not sure whether they ran hostile SQL code to change fields in the MySQL database so had to consider the possibility that the account creation time could have been set to a deliberately misleading value. I checked backups of the MySQL database stored off-site and found that the account in question was not in the 2026-07-21 backup (which was done before 16:43) but in the 2026-07-22 backup.
The WordPress release history [2] has version 7.0.1 released on 2026-07-09 and version 7.0.2 released on 2026-07-17. So presumably the attacker diffed the code on those releases, found an exploitable bug, and used it to create an account on my blog with admin privs. Then they waited a few weeks to see if I would notice and published a blog post when I didn’t notice.
WordPress Deficiencies
WordPress doesn’t seem to store the version it’s running at the time of operations. So anyone who doesn’t have a suitable external log of versions deployed (such as the dpkg.log file for a Debian managed installation) won’t know for sure which version was running. It supports automatic updates but you can’t be sure that they happened soon after the release.
There is no log of IP addresses used for operations. There are apparently some 3rd party modules to log such things and web pages documenting how to modify the PHP to add it but nothing in the standard distribution.
Software should have a standard distribution with some support for logging of security relevant data. The typical situation is that people don’t plan for logging such things until after they have been attacked so the data should be recorded without users going out of their way to log it.
A log of security relevant data should be stored in a database table with only insert access (no update, delete, or drop).
Ideally a CMS would support different database accounts for different purposes. Someone from an internal network or VPN could talk to an instance of the web server which has a database username and password giving full access. Everyone from outside the trusted range gets an instance of the web server with database access only allowing to read the posts and appearance configuration and to enter comments. If the database didn’t allow the account used for public access to create new admin users or create posts then it would be a lot harder for attackers.
Ideally for everything that stores user account data there would be an easy way of getting a list of users in a plain text format to allow running diff. The design of WordPress has two tables, one for users and one for encoded metadata about users of which one will be the access level. The following SQL command will give a list of all users that aren’t subscribers (everyone above the minimum level of access which is typical for new users) along with their encoded password and access level. This could be used in a monitoring system to alert about new privileged users. The TABLE_PREFIX variable is for the prefix for WordPress tables, which is “wp_” by default but can be any legal value.
select $TABLE_PREFIXusers.user_login, $TABLE_PREFIXusers.user_pass, $TABLE_PREFIXusermeta.meta_value from $TABLE_PREFIXusers join $TABLE_PREFIXusermeta on $TABLE_PREFIXusers.id = $TABLE_PREFIXusermeta.user_id and meta_key='$TABLE_PREFIXcapabilities' and meta_value != 'a:1:{s:10:"subscriber";b:1;}';
What Next?
The blog post they created had a couple of links to Telegram which could presumably be used to contact them. If anyone involved in computer security wants a copy of the original post to do so then they can contact me by any of the usual methods.
I am interested in communication with the attacker if they wish, Telegram is not a service I use but I presume that anyone capable of doing this sort of attack is also capable of finding other ways of contacting me.
I have also idly considered other platforms for blogging such as Lemmy. I don’t know if Lemmy is better than WordPress for security and updates, but there are plenty of free instances running where it wouldn’t be an issue I have to work on.
For a while I’ve been having issues with AMD GPUs, video locking up periodically. I blogged about this late last year but I first had noticeable problems early last year [1]. The problems hadn’t only concerned my workstation but also my home server which is also used as a workstation. I’ve recently upgraded my machines to Debian/Testing, my home server has been generally OK but my workstation has been crashing a lot. Every second day when on kernel 7.1.6 and then when on 7.1.7 it crashed at least once a day.
The AMD GPUs I have are “[AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev e5)” in my main desktop workstation, “[AMD/ATI] Lexa [Radeon 540X/550X/630 / RX 640 / E9171 MCM] (rev c1)” in my build server, and “[AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev cf)” in my home server. They aren’t new GPUs, but also aren’t really old and they all support 4K and better resolution.
Chat GPT Was Useful
When I googled the errors I was seeing I found nothing useful. On the suggestion of a friend I tried asking ChatGPT. Generally I don’t recommend asking LLMs about such things, but it can be a last resort as long as you know what you are doing. ChatGPT asked me to run a number of commands to get information for it to make more informed decisions. I know that the output of lspci and similar commands isn’t a risk, but a novice could be tricked into running commands that expose sensitive data.
ChatGPT did give me some useful information, not a solution but an indication that the problem was due to driver bugs.
Upgrading to Experimental
Debian/Experimental is for packages that are expected to have problems and generally aren’t recommended even for the people who usually use Debian/Unstable. It’s commonly used for packages that are needed to develop other packages, EG new libraries that aren’t fully usable but which are needed to package newer versions of applications.
I upgraded my workstation to the Debian/Experimental kernel 7.2~rc7-1~exp1 after having tried every other convenient option. Generally I wouldn’t recommend that anyone run an Experimental kernel without a really good reason, but crashing more than once a day is a fairly good reason. That kernel has now given me over 4 days of uptime on a system that previously wouldn’t last a day. I installed it on my dual-socket build server that has an old AMD GPU in it for test purposes and that also hasn’t crashed since. I installed it on my ML test machine which has an Intel B580 Battlemage GPU with 16G of VRAM and was repeatedly getting a kernel panic related to the GPU a few seconds after boot and now it also works correctly.
It seems that the 7.1.x kernels have bugs in the AMD video drivers and in some part of the code that affects Intel video drivers and that the bugs in question are fixed in the tree that will become 7.2. I would not recommend anyone who has a 7.1.x kernel working fine for them try 7.2 RC kernels at this time, but anyone who has GPU related problems (particularly Intel and AMD GPUs) should definitely test it out.
I also don’t recommend upgrading any system with an AMD GPU to Debian/Testing or Debian/Unstable at this time unless you are also prepared to install an Experimental kernel if it becomes necessary.
There are a several kernel log dumps related to this after the break (which won’t be in RSS feeds). This is mainly for Google so that other people who have such issues can get more useful results out of Google searches than I got.
Future Support Options
Separate from the issue of whether commercial LLMs like ChatGPT can be useful for solving technical problems there is the issue of whether they are desirable. I think that we really don’t want people solving problems in FOSS systems with closed-source LLMs. This leads to loss of privacy, loss of the control users deserve to have over their own systems, and an implied promotion of non-fee software.
I think that the ideal would be to have a cross distribution effort to generate training data for a support LLM system which can then be further trained by each distribution for a greater emphasis on distribution specific issues.
2026-08-11T09:33:33.473855+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00024802
2026-08-11T09:33:33.473871+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:33.473871+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-11T09:33:33.473873+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F048002
2026-08-11T09:33:33.473873+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 63) at page 2048, write from 'TC0' (0x54433000) (72)
2026-08-11T09:33:33.473874+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00004802
2026-08-11T09:33:33.473874+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:33.473875+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-11T09:33:33.473876+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E048002
2026-08-11T09:33:33.473876+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 63) at page 2048, read from 'TC0' (0x54433000) (72)
2026-08-11T09:33:35.481863+10:00 xev kernel: amdgpu 0000:02:00.0: Dumping IP State
2026-08-11T09:33:35.481875+10:00 xev kernel: amdgpu 0000:02:00.0: Dumping IP State Completed
2026-08-11T09:33:35.481875+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] AMDGPU device coredump file has been created
2026-08-11T09:33:35.481876+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] Check your /sys/class/drm/card0/device/devcoredump/data
2026-08-11T09:33:35.481877+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 146 0x0110040c
2026-08-11T09:33:35.481877+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:35.481878+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000022
2026-08-11T09:33:35.481879+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E00400C
2026-08-11T09:33:35.481879+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x0c, vmid 7, pasid 63) at page 34, read from 'TC3' (0x54433300) (4)
2026-08-11T09:33:35.489845+10:00 xev kernel: amdgpu 0000:02:00.0: ring gfx timeout, signaled seq=5123619, emitted seq=5123621
2026-08-11T09:33:35.489853+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:35.489854+10:00 xev kernel: amdgpu 0000:02:00.0: GPU reset begin!. Source: 1
2026-08-11T09:33:35.493839+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] ERROR Failed to initialize parser -125!
2026-08-11T09:33:35.737848+10:00 xev kernel: amdgpu: cp is busy, skip halt cp
2026-08-11T09:33:35.897842+10:00 xev kernel: amdgpu: rlc is busy, skip halt rlc
2026-08-11T09:33:35.897852+10:00 xev kernel: amdgpu 0000:02:00.0: BACO reset
2026-08-11T09:33:36.485849+10:00 xev kernel: amdgpu 0000:02:00.0: GPU reset succeeded, trying to resume
2026-08-11T09:33:36.485859+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] PCIE GART of 256M enabled (table at 0x000000F402000000).
2026-08-11T09:33:36.485860+10:00 xev kernel: amdgpu 0000:02:00.0: VRAM is lost due to GPU reset!
Errors on Battlemage
Aug 11 17:01:47 ami kernel: ------------[ cut here ]------------
Aug 11 17:01:47 ami kernel: xe 0000:23:00.0: [drm] DMC 1 mmio[0]/0x5f074 incorrect (expected 0x96fc0, current 0x0)
Aug 11 17:01:47 ami kernel: WARNING: drivers/gpu/drm/i915/display/intel_dmc.c:696 at assert_dmc_loaded+0x275/0x430 [xe], CPU#0: kworker/0:3/215
Aug 11 17:01:47 ami kernel: Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common xe(+) skx_edac snd_h>
Aug 11 17:01:47 ami kernel: msr i2c_dev configfs efi_pstore efivarfs autofs4 btrfs libblake2b raid6_pq xor mpt3sas raid_class scsi_transport_sas megarai>
Aug 11 17:01:47 ami kernel: CPU: 0 UID: 0 PID: 215 Comm: kworker/0:3 Not tainted 7.1.7+deb14-amd64 #1 PREEMPT(lazy) Debian 7.1.7-1
Aug 11 17:01:47 ami kernel: Hardware name: HP HP Z4 G4 Workstation/81C5, BIOS P61 v03.00 04/15/2026
Aug 11 17:01:47 ami kernel: Workqueue: sync_wq local_pci_probe_callback
Aug 11 17:01:47 ami kernel: RIP: 0010:assert_dmc_loaded+0x291/0x430 [xe]
Aug 11 17:01:47 ami kernel: Code: 24 10 e8 f2 e5 a3 ce 48 8d 3d bb 85 0d 00 8b 54 24 0c 45 89 e9 45 89 e0 48 89 c6 52 8b 4c 24 2c 51 8b 4c 24 30 48 8b 54>
Aug 11 17:01:47 ami kernel: RSP: 0018:ffffd27ac0b87b80 EFLAGS: 00010282
Aug 11 17:01:47 ami kernel: RAX: ffffffffc1743dfd RBX: ffff8c5b80e54000 RCX: 0000000000000001
Aug 11 17:01:47 ami kernel: RDX: ffff8c5b81df5a10 RSI: ffffffffc1743dfd RDI: ffffffffc1605860
Aug 11 17:01:47 ami kernel: RBP: ffff8c5b86955000 R08: 0000000000000000 R09: 000000000005f074
Aug 11 17:01:47 ami kernel: R10: 0000000000000000 R11: 0000000000091050 R12: 0000000000000000
Aug 11 17:01:47 ami kernel: R13: 000000000005f074 R14: 0000000000000001 R15: 0000000000000000
Aug 11 17:01:47 ami kernel: FS: 0000000000000000(0000) GS:ffff8c673e172000(0000) knlGS:0000000000000000
Aug 11 17:01:47 ami kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 11 17:01:47 ami kernel: CR2: 00007ffed1fdcd00 CR3: 0000000ae942a003 CR4: 00000000003706f0
Aug 11 17:01:47 ami kernel: Call Trace:
Aug 11 17:01:47 ami kernel:
Aug 11 17:01:47 ami kernel: intel_dmc_enable_pipe+0xe4/0x290 [xe]
Aug 11 17:01:47 ami kernel: ? drm_crtc_vblank_reset+0x4d/0x120 [drm]
Aug 11 17:01:47 ami kernel: intel_modeset_setup_hw_state+0xb50/0x1e10 [xe]
Aug 11 17:01:47 ami kernel: ? intel_display_driver_probe_nogem+0x138/0x1a0 [xe]
Aug 11 17:01:47 ami kernel: intel_display_driver_probe_nogem+0x138/0x1a0 [xe]
Aug 11 17:01:47 ami kernel: xe_display_init_early+0xb2/0x140 [xe]
Aug 11 17:01:47 ami kernel: xe_device_probe+0x3c8/0xb50 [xe]
Aug 11 17:01:47 ami kernel: ? xe_pm_init_early+0x152/0x160 [xe]
Aug 11 17:01:47 ami kernel: xe_pci_probe+0xc26/0x1150 [xe]
Aug 11 17:01:47 ami kernel: local_pci_probe+0x3e/0x90
Aug 11 17:01:47 ami kernel: local_pci_probe_callback+0x16/0x20
Aug 11 17:01:47 ami kernel: process_one_work+0x19d/0x3a0
Aug 11 17:01:47 ami kernel: worker_thread+0x1af/0x320
Aug 11 17:01:47 ami kernel: ? __pfx_worker_thread+0x10/0x10
Aug 11 17:01:47 ami kernel: kthread+0xe3/0x120
Aug 11 17:01:47 ami kernel: ? __pfx_kthread+0x10/0x10
Aug 11 17:01:47 ami kernel: ret_from_fork+0x2b2/0x340
Aug 11 17:01:47 ami kernel: ? __pfx_kthread+0x10/0x10
Aug 11 17:01:47 ami kernel: ret_from_fork_asm+0x1a/0x30
Aug 11 17:01:47 ami kernel:
Aug 11 17:01:47 ami kernel: ---[ end trace 0000000000000000 ]---
The diffoscope maintainers are pleased to announce the release of diffoscope
version 328. This version includes the following changes:
[ Chris Lamb ]
* Don't require python3-guestfs in the autopkgtests on 32-bit architectures.
(Closes: #1144372)
[ Jochen Sprickerhof ]
* Use the XML comparators for SVG vector image files. (Closes: #1144242)
I have some pending, encrypted mails to answer. And some of my answers for
the next few days (particularly to what pertains to the current
in-discussion vote on LLM usage in
Debian) will be unsigned, even
though I’d like otherwise.
My desktop system at work is showing some data corruption, and I’m slowly
backing up my data. Fortunately, it seems I haven’t lost any data, but
still, given I’m letting rsync run until it starts spewing I/O errors,
then power down and let the machine cool a bit, and start again… it is a
potentially long process.
And yes, this makes me somewhat angry. Why angry? Because I’m working on a
brand-new computer (well, have used it for slightly over six months),
custom-built to specs requested by my workplace. Specs that I don’t really
need, this machine is an utter luxury (i.e. an AMD Ryzen 9 9950X processor
with 16 real cores / 32 threads; 128GB RAM in this day and age of RAM
shortage, quite recent 32GB GPU, and lots of shiny lights seen in its huge
fishbowl cabinet, liquid-based cooling…). The specs came not from me, but
from people who had no idea what we would use them for. And yes, I expect
the little fortune spent on this machine to be good for my use for probably
a decade, as my previous computer was, but the amount paid
was… exorbitant.
But still, what I learned recently is that the 4TB nVME SSD it has (a
T-Force TM8FFJX34T) is… a very cheap brand, bought because it was close
to half the price of other offerings similar in capacity. According to
smartctl’s output, th SSD operates with a Warning Comp. Temp. Threshold:
90 Celsius and Critical Comp. Temp. Threshold: 110 Celsius, which sounds
sensible, even too high for my standards (my last two laptops have been
fanless… yes, an ARM system is very different from a high-end gaming
machine). I’m right now typing from my laptop, which shows 78°C and 82°C
for warning/critical thresholds.
And as expected, under heavy sustained reads (backing up to my NFS server),
the desktop’s smartctl shows Temperature: 83 Celsius and, further down,
Temperature Sensor 1: 107 Celsius and Temperature Sensor 2: 82 Celsius
(don’t know which of these would make the threshold jump). The SSD has
sustained Media and Data Integrity Errors: 20 and Warning
Comp. Temperature Time: 21 (although Critical Comp. Temperature Time: 0). At least one of my colleagues have shrugged and installed a SATA SSD,
laying the huge nVME basically to waste.
Anyway… I also learned I am not the first, but the fourth person to
notice this kind of issues in this system (out of ten similar purchased
systems AIUI). It is completely unacceptable, and I’ll be pushing our
Institute’s authorities to demand the provider to provide either good
component quality for this very expensive system that has many luxury
items, or to fix the system’s build in a way the nVME does not heat as much
as it currently does.
Anyway, sigh, I only wanted to say, please excuse me for not using my
cryptographic keys for a couple of days 🙃
PS- I’m also currently not connected to IRC and Jabber (and some similar
technologies), as my bouncer runs from my usual workstation.
Since I wrote about my fly30 ice skates, I'd continued to battle pain
around the navicular bone in my feet. The action that seems to have finally
fixed it was to perform a "punch out": a very localized remoulding of the
area of the boot that presses against the sore area.
I narrowed down the exact spot by borrowing some lipstick and transferring it
from my navicular bone to the boot lining, then making that more permanent with
a sharpie.
My punch was a spare part from a radiator valve which I packed with US cents
(I couldn't fit any UK coins in). For the receiving-end, I tried another part
from the radiator valve but I think it wasn't sufficiently larger than the punch
to work well, so I swapped that out for a spoon.
take 2
I didn't have a temperature sensor I could use and I used a heat gun rather than
a hairdryer, so I YOLO'd it a little. Some of the wrap on one of my boots is now
distorted from where I didn't move the heat gun enough. It only took a minute or
two to get the boot hot enough to be flexible. I set a 15 minute timer once the
clamp was in place.
I've only skated one session since I did this but the pain seems to have gone!
It's remarkably freeing to be skating without constantly trying to manage pain.
Now I can focus on technique.
Inspired by some recent reverse-engineering, here are some things I
find wild by the original PlayStation GPU:
VRAM is a flat 1024x512 16-bit image (555 + 1 bit alpha).
You want more than just a framebuffer? Figure out yourself what goes where.
Yes, that means you'll need to allocate two framebuffers
and double-buffer everything yourself.
Quads are common. No “triangles only” business here.
Vertex coordinates are screen-space x/y integers. No floats or fixed-point. (I'm ignoring the GTE here,
plus higher-level libraries.)
Wait, where's z? There's no z. So there's no perspective correction.
(This one is pretty famous)
OK, so how do you give in subpixel coordinates? You don't. There's no AA after all.
Texture coordinates (u/v) are uint8_t. There's no texture filtering either;
everything is nearest-neighbor only.
OK, so that means you can't have textures larger than 256x256
(pretty common in that era), but how do you give in the handle to the
texture?
You don't, it points directly to the 1024x512 VRAM. You manage yourself
what goes where, remember?
So can you an only have textures in the top-left 256x256? Hah, no,
we give you a bit-packed “texture page” system that offsets
all your u/v coordinates.
Most textures are paletted to save VRAM (so instead of 555+1, your
pixels now mean something like “two palette indexes”). Where does the palette live?
Well, duh, that's a 256x1 (or 16x1, or whatever) area of VRAM too.
The GPU does not care, you can use another texture's pixels as a palette if
you feel like it.
OK, so you said there's no z, how do you do z-buffering? You have a
z-buffer, right… right?
Yeah, sure, we're not cavemen. We have an “ordering table” that is
your Z-buffer, drawn back-to-front. If you want 256 levels of Z,
you just allocate an array of 256 linked-list pointers, and then
you put your polygon into the one corresponding to the correct right Z.
But, eh, what if my polygon is not completely flat in Z-space?
This event is happening soon — see below for registration instructions!
We are extremely pleased to announce the upcoming Reproducible Builds summit, which will take place from September 22nd—24th 2026 in the city of Gothenburg, Sweden.
This year, we are thrilled to host the tenth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Vienna (2025), Hamburg (2023—2024), Venice (2022), Marrakesh (2019), Paris (2018), Berlin (2017), Berlin (2016) and Athens (2015).
If you’re excited about joining us this year, please make sure to read the event page which has more details about the event and location. As in previous years, we will be sending invitations to all those who attended our previous summit events or expressed interest to do so. However, even if you do not receive a personal invitation, please do email the organizers and we will find a way to accommodate you.
About the event
The Reproducible Builds Summit is a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort. During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving.
Schedule
Although the exact content of the meeting will be shaped by the participants, the main goals will include:
Update & exchange about the status of reproducible builds in various projects.
Improve collaboration both between and inside projects.
Expand the scope and reach of reproducible builds to more projects.
Work together and hack on solutions.
Establish space for more strategic and long-term thinking than is possible in virtual channels.
Brainstorm designs on tools enabling users to get the most benefits from reproducible builds.
Discuss how reproducible builds will be usable and meaningful to users and developers alike.
Logs and minutes will be published after the meeting.
Now that Ubuntu 26.04 LTS has been released, I’ve been getting back to the GSS-API key exchange package split in our OpenSSH packaging. Once I started testing my draft openssh-gssapi source package, I realized that I needed to make some changes in the main openssh source package first in order to support it. The dependency from openssh-server to openssh-client was awkward, as was the (related) fact that openssh-client contained shared documentation for other OpenSSH binary packages. After some thought, I created a new openssh-common binary package, moved shared documentation and the ssh-keygen program to that, and dropped dependencies on openssh-client which were no longer necessary (fixing #699473 and #1070098 in the process).
This caused a couple of regressions (#1141420 and #1141550) that I had to fix, and more subtly it also caused a number of autopkgtest regressions in other packages because openssh-client is no longer in base images as a result of a dependency from openssh-server. I believe I have fixes for all of these either pending review or merged (one of which I did in August rather than July):
With support from a Freexian customer, I reviewed, tested, edited, and merged a patch to add VLAN support. I described the details of what I did in a comment.
This has been vaguely on my to-do list since, er, about 2014, so it was very satisfying to get it sorted out.
Dan Poltawski pointed out in a Fediverse post that the project history didn’t list Sruthi as the current DPL. I fixed that, although it doesn’t look as though the fix is in the published version yet.
DebConf 26 organization, by Lucas Kanashiro, Santiago Ruano Rincón, Stefano Rivera and Antonio Terceiro
The 27th Annual Debian Conference was held in
Santa Fe, Argentina, and several Freexian fellows were quite busy by being
involved in the organization team.
Santiago continued helping with duties related to the local team, e.g.
preparing or proof-reading some announcements, reviewing the proposed food and
the menus for the different diet required.
During the conference, Kanashiro and Santiago also carried over tasks related
to the content of the conference, including updating the schedule as it became
necessary during the event.
Stefano worked within the core video team, setting up equipment in talk rooms
and coordinating the live video streaming. Stefano also supported the front desk
and local organisers as a website developer and conference book-keeper.
Antonio kept working on website maintenance, specially in support of the
content team. During DebConf he also ran a hands-on workshop to help interested
contributors get started with developing the DebConf websites.
d-i VLAN support, by Colin Watson
In environments that use IEEE 802.1Q VLANs,
some hosts (such as routers attached to “trunk” ports) may need to apply VLAN
tags themselves rather than relying on switches to do so. There has been a
long-running request to add support for these
to the Debian installer with a proposed patch set put together by several people
over the years, and a Freexian customer asked us to help get this over the line.
Colin reviewed the latest version of the patch set, applied a number of
corrections, added Netplan support, spent some time testing a variety of
possible paths through the installer, and landed this. There’s also now
documentation
for this in the next version of the installation guide.
Carles, using po-debconf-manager:
reviewed 2 packages, submitted 2 packages
Carles organized Catalan translation update. Created a Debian Wiki
page to have an
overview of the work / coordination during next months.
Reviewed and submitted some pages.
Thorsten did another upload of hplip to fix RC bugs. He also spent some time
taking care of older bugs. Most of the time such bugs had been fixed in a
previous upload but haven’t been closed in the BTS. He also uploaded a new
upstream version of foomatic-db. Last but not least, he gave some user support
with the package epson-inkjet-printer-escpr. There seems to be a new software
available for Epson printers. Unfortunately the license is not compatible with
DFSG and so this software will never make it into Debian.
During DebCamp 26, the Golang team had a
dedicated Sprint to
transition the Golang toolchain (namely on dh-golang) to make builds aware of
the module defined upstream with the aim of solving important issues. To help
in these efforts, Santiago made changes
in the Salsa CI pipeline and
documented on how to use it
to check if a package requires adjustments after the toolchain update.
Santiago continued co-mentoring Aryan Karamtoth on the Linux livepatching
project, specifically providing feedback about the implementation of
dlp-tools.
Stefano reviewed and merged a migration of Debian reimbursements from
wkhtmltopdf to weasyprint, unblocking an upgrade to Debian trixie.
Antonio has done quite some work on Debian CI, including rebuilding the
Debian CI armhf/armel worker VMs, and releasing
debci 4.2,
implementing a backup scheme, and several improvements to the codebase such as
improving the incus-lxc backend in preparation for switching to the upcoming
switch to using it by default as announced in the latest
bits from the ci.debian.net operators.
Emilio helped with transitions, particularly with Python 3.14 as default and
Perl 5.42. During the Perl transition, an issue was identified with how britney
schedules autopkgtests for binNMUs, and that testing was reverted for the time being.
Colin restructured openssh-* binary packages to better support the upcoming
GSS-API package split. This caused several autopkgtest regressions in other
packages because openssh-server no longer depends on openssh-client, all of
which have fixes either pending review or merged now.
Lucas started a discussion around the creation of a Debian packaging video
course for newcomers in the context of the Outreach team.
Lucas reviewed some contributions to ruby3.4 and provided feedback.
Anupa worked with Jean-Pierre Giraud on the point release announcements for
Debian 13.6 and Debian 12.15.
Anupa joined Jean-Pierre Giraud to prepare the Micronews for DebConf 26 press
coverage.
On Saturday 25 July 2026, the annual Debian Developers and Contributors
Conference came to a close. The Debian Press
team would now like to share this personal and beautiful message from the Santa Fe
Local Team.
Words from DC26 Local Team
DebConf26 is over, and those of us who were part of the Local Team are trying
to return to “normality”, if such a thing exists after organizing a DebConf.
This event changed our lives and would not have been possible without the help
of many great people.
We would especially like to thank everyone who became part of our extended
local team. Our endless thanks go to Gunnar —who also instigated this whole
adventure—, Santiago, Nattie, Stefano, and Olasd. Thank you for supporting and
guiding us, sharing your experience, and helping us find solutions throughout
the entire process.
It was also made possible thanks to the great work, strong support and patience
of international teams: Fundraising, Bursaries, Content, Video, Treasury, Visa,
Website, Accommodation, Front Desk, Cheese and Wine, Publicity as well as all
the other teams and individuals who contributed. We apologize if we have
forgotten to mention anyone; many people helped make this event possible.
Our deepest thanks also go to everyone who joined us in working on the event,
especially Fer, José, and Julián, who showed great commitment and took
responsibility for several important tasks.
We would also like to extend our gratitude to FICH, the Universidad Nacional
del Litoral, the institutions, organizations, sponsors, suppliers, and everyone
who contributed in one way or another to welcoming the Debian community to
Santa Fe.
And finally, a very special thank you to our families, to whom we dedicated
little time these past few weeks, who supported us on this adventure, enduring
the exhaustion, the calls and messages at all hours, and the occasional
stressful situation. Always giving us that much-needed, encouraging hug with so
much love.
These were very intense weeks, during which we tried to give our best so that
everyone could enjoy their stay and so that the Debian community had the
necessary conditions to meet, work, share knowledge, and continue creating the
magic that characterizes community life and the development of Debian.
As happens at every DebConf, there were difficulties, unexpected situations,
and challenges that required us to improvise, learn, and perform a few juggling
acts. There were also moments that will certainly remain as memorable
anecdotes: the “antisocial room”, some gas heaters worthy of a museum, and
newly unlocked powers for negotiating with suppliers.
We have no evidence, but also no doubt, that for many people the Conference
Dinner was one of the best moments of the event.
A few ingredients we had hoped would happen naturally were missing, such as
more wine nights and at least one in-person football match.
During the two weeks of DebConf, we experienced every kind of weather and a
wide range of emotions. Above all, however, we saw people enjoying themselves
and building friendships, which fills us with pride.
Thank you very much to everyone who came and helped DebConf26 leave such a
beautiful mark on our hearts.
We hope our paths cross again somewhere in life.
Best regards,
Leonardo, Emmanuel, Mariano, Pablo, and Martín
DebConf26 Local Team
About Debian
The Debian Project was founded in 1993 by Ian Murdock to be a truly free
community project. Since then the project has grown to be one of the
largest and most influential Open Source projects. Thousands of
volunteers from all over the world work together to create and maintain
Debian software. Available in 70 languages, and supporting a huge range
of computer types, Debian calls itself the universal operating system.
About DebConf
DebConf is the Debian Project's developer conference. In addition to a
full schedule of technical, social and policy talks, DebConf provides an
opportunity for developers, contributors and other interested people to
meet in person and work together more closely. It has taken place
annually since 2000 in locations as varied as Scotland, Bosnia and Herzegovina,
India, Korea, France. More information about DebConf is available from
https://debconf.org/.
I enjoy reading The Guardian's monthly round-up of new SF novels, which can be
found in their Science Fiction
Books section, and can also
be read via feed.
Since the round-up is of new books, at the time the round-up is published
they're usually only available in hardback.
When it comes to choosing a book to read, these days I am tending towards
paperbacks: I've largely ran out of room for hardbacks. So I decided to apply
a time delay to their feed. Six months is roughly enough that a
book mentioned in a round-up should be shortly available in paperback.
The first obstacle was that The Guardian only publish roughly the
last six months of articles in their feed, and so the posts I want have
disappeared. However, my Feed Reader
(FreshRSS) had older copies stored in
its database, and I am able to re-publish those
using User Queries.
(This also gives me an opportunity to filter out non-roundup articles
from the Guardian's feed).
It's then a nice short piece of scripting (this time, using Ruby) to filter the
republished feed on the publication date. To make the most recent articles appear new, I
also modify the metadata for filtered entries to appear 6 months newer than they are.
#!/usr/bin/ruby
require 'rss'
# replace with the user query feed URI
uri = 'https://www.theguardian.com/books/science-fiction/rss'
now = Time.now
sixMonths = 6 * 30 * 24 * 60 * 60
feed = RSS::Parser.parse(uri)
feed.items.select! do |item|
item.date + sixMonths < now
end
feed.items.collect! do |item|
item.date += sixMonths
item
end
puts "Content-Type: text/xml\r\n\r"
puts feed
I stuck that up on my private web server, subscribed to it in my FreshRSS
and voila, a time-delayed list of books to read, most likely available in
paperback.
I will organize sessions on two days after the conference program to exchange
PGP fingerprints for keysigning to improve the kernel's web-of-trust (but of
course everyone is welcome).
For details see my announcement on
LKML. Note
the registration deadline at 2026-09-27 08:00 UTC.
When you need to install something directly from PyPI, Python virtualenvs have
been my go-to for over a decade.
A quick virtualenv intro
Most of my readers are probably already familiar with virtualenvs, but for
completeness, I'll give you a brief introduction. A virtualenv (short for
"virtual environment") is an isolated distribution of Python packages, where
you can independently install packages without disturbing your system packages
or other virtualenvs.
You can set one up like this, assuming you are using Python 3.3 or higher:
python3-mvenv~/.venv/my-virtualenv
The directory specified here is just a convention. I keep all my virtualenvs in
the .venv folder in my home directory, but you can pick whatever location you
like.
To use the virtualenv, you must activate it:
source~/.venv/my-virtualenv/bin/activate
This activation script is a special shell script that configures your current
shell, pointing at all the right paths in order to use the virtual environment.
source runs this script in your current shell session to set it
up. You will notice that this adds (my-virtualenv) to the beginning of your
shell prompt, reminding you that the "my-virtualenv" virtualenv is active. Now
when you pip install amazing-package, the software will only be available in
this virtual environment.
When you're done, you can deactivate it like so:
deactivate
Wonderful!
Managing many virtualenvs gets annoying
Over time, I end up accumulating many virtualenvs, which can become harder to
manage. Maybe something like this:
$ls~/.venv/
my-virtualenvcool-projectsnakes-ahoy
I also don't want to type source ~/.venv/my-virtualenv/bin/activate every
time I use the virtualenv, because it gets very repetitive—only the name
of the venv is really needed.
But luckily, we can write a little bit of bash to make managing this less
annoying. (Or you can use one of many Python developer tools that are designed
to manage this, like pipx, but when I merely want to consume Python
software, I might not have a development environment set up. So that's beyond
the scope of this post!)
If you add the following shell function to your ~/.bashrc or
~/.bash_aliases file, it will nicely wrap our activation command:
setup-venv(){source"$HOME/.venv/$1/bin/activate"}
Now all we need to run is
setup-venvmy-virtualenv
So much quicker!
Spicing it up with tab completion
The first thing I noticed after writing this wrapper was that I started hitting
tab on the virtual environment name, but... nothing happened. Wouldn't it be
nice to know what virtualenvs I had available, and to not have to type out the
whole long thing?
Well, we can write it ourselves 😄
If for some reason you don't already have bash completion installed, on a
Debian-based system, you will need to install it with
aptinstallbash-completion
In order to configure our bash completion, we will create a new file,
/etc/bash_completion.d/venv, with the following contents:
This file defines another shell function order to determine how to
autocomplete the options for our setup-venv function.
$opts is where we define the options for our function. We generate it with a
find command—looking at the .venv folder in the current user's home
directory, then only including child folders (excluding the current directory
itself, .venv, in our results) by using the min/max depth and type arguments,
and printing just the individual directory names, deliminated by spaces using
our print formatter.
Everything else is the standard scaffolding required to use bash completions.
Once you save this file and reload your shell, you'll see that you are able to use completions as expected!
In our reports, we try to outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not.
If you are interested in contributing to the project, please visit the Contribute page on our website.
diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 324, 325 and 326 to Debian:
Fix tests to work with zipdetails 4.0008. (#1141359)
In addition, Paul Spooren made changes to allow trailing garbage in Gzip files […] and Vagrant Cascadian added an external tool reference for the pedump binary to use the mono package under GNU Guix. […]
disorderfs is our FUSE-based filesystem that deliberately introduces non-determinism into system calls to reliably flush out reproducibility issues. This month, Christelle Gloor added the option to sort by ctime as returned by the lstat(2)syscall. […], which Chris Lamb uploaded whilst bumping the Standards-Version to version 4.7.4 […]. Bernhard Wiedemann also updated disorderfs to version 0.7.0 in openSUSE.
Yet again, there were a number of improvements made to our website this month as well. For example, Chris Lamb, by request of Digital Ocean, changed the target of a referral link so that they can manage incoming referrers […] and pushed a number of changes to the Tools page […].
We present VCAligner, a content-based alignment methodology that constructs inverted indexes over VCS histories to precisely map released artifacts to their originating commits, independent of fragile version tags. We evaluated VCAligner on a dataset of 2,984 verifiable PyPI packages derived from the 4,000 most-downloaded projects linked to public GitHub upstreams. Our results reveal a critical weakness in conventional tag-based heuristics: while they appear effective on 85% of the dataset, the residual 15% failure rate generates a catastrophic downstream audit workload of over 10.3 million commits. In contrast, VCAligner reduces this burden by two orders of magnitude (≈ 158×), bounding the total workload to under 65,000 commits. Furthermore, we provide the large-scale characterization of “Packaging Noise,” classifying artifact divergence into structural additions (Path Phantoms) and content mutations (Blob Phantoms), thereby isolating the distinct attack surfaces of malicious injection and code tampering.
Python has become the default language for interacting with AI, with packages being distributed through registries like the Python Package Index (PyPI). This creates a need to analyse supply chains comprising such packages. One such analysis is to rebuild packages in order to identify compromised builds injecting malware. Independent rebuilds in hardened environments have the added advantage that they can generate and record provenance in order to increase the trustworthiness of packages. Two tools that are designed to automate such rebuilds and run them at scale are macaron and oss-rebuild. We study 12,180 popular releases from PyPI and find that the byte-for-byte equivalence rate is generally low. We analyse the reasons why they produce different wheels, and find that equivalence between the original and rebuilt wheels can often still be established, preserving most of the guarantees users expect from rebuildable releases. We present and evaluate daleq4py, a tool to establish the equivalence of Python wheels through the kernel of a normalisation function that is based on provenance-preserving datalog rules. Experimental results show that daleq4py substantially expands the set of rebuilds that can be accepted as equivalent. Although only 15.4% of macaron rebuilds and 19.1% of oss-rebuild rebuilds are byte-for-byte identical to the published PyPI wheels, daleq4py establishes wheel equivalence for 60.2% and 78.9% of source-equivalent rebuilds, respectively.
The security of open source applications benefits considerably from the possibility of rebuilding their source and verifying the output. F-Droid, a prominent distribution for open source Android applications, systematically rebuilds them from source and tests their bitwise reproducibility at app publishing time. However, F-Droid offers no guarantee that app reproducibility will continue to hold in the future. As software ecosystems evolve, reproducibility may degrade, with potential negative consequences for software preservation and security. We present the first empirical study of build reproducibility in the F-Droid app ecosystem. Analyzing historical reproducibility logs, we find that the overall bitwise reproducibility rate has been steadily increasing over time (as new versions of apps are published). We then evaluate how reproducibility holds in time for fixed app versions, by attempting to rebuild 18 904 app versions that F-Droid had previously confirmed bitwise reproducible, published between September 2018 and February 2026, achieving an 83% rebuild success rate, and identify missing dependencies as the dominant cause of failure, accounting for 76% of non-rebuildable cases. Among successfully rebuilt apps, 94% are also bitwise reproducible-i.e., they still yield bitwise identical artifacts upon rebuild. Together, these results show that while bitwise reproducibility largely holds for apps that can be rebuilt, rebuildability itself is highly sensitive to temporal decay.
Patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:
Reproducible builds remove trust in the builder: anyone re-derives the same artifact from the same source, byte for byte. The same shape applies one layer over, to a retained record. Most record-keeping regimes (the EU AI Act’s Article 12 logging is the current example) require that events be recorded and logs retained, but not that a retained log be verifiable, by a party who was not present, as unaltered and existing when claimed. That leaves an integrity obligation resting on trusting the party being audited.
Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
This was my hundred-forty-fifth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.
During my allocated time I uploaded or worked on:
[DSA 6402-1] hplip security update to fix two CVEs in Trixie related to privilege escalation and/or arbitrary code execution. I sent the debdiff to the security team, which resulted in this DSA.
[DLA 4689-1] libnfs security update to fix one CVE in Bookworm and Bullseye related to an integer overflow.
[DLA 4699-1] hplip security update to fix two CVEs in Bookworm and Bullseye related to privilege escalation and/or arbitrary code execution.
[ELA-1775-1] libnfs gimp security update to fix one CVE in Buster and Stretch related to an integer overflow.
[ELA-1784-1] hplip security update to fix two CVEs in Buster and Stretch related to privilege escalation and/or arbitrary code execution.
Unfortunately the number of assigned hours was rather low this month. So besides doing some days of FD at the end of the month, where I also had to process a new package list for ELTS, and a review of the rsync package (prepared by Sylvain), not much happened here.
This month I continued the upload of lomiri packages with new upstream versions. Thanks to the help of my other colleagues, this project could be finished now.
Next month I intend to upload new upstream versions of all Osmocom packages. As far as I can tell, these uploads will happen without soname changes. I like that :-).
misc
This month I uploaded a new upstream version or a bugfix version of:
On Saturday 25 July 2026, the annual Debian Developers and Contributors
Conference came to a close.
Over 270 attendees representing 35 countries from around the world came
together for a combined 90 events (including some which took place during
the DebCamp) including more than 27 Talks, 21 Short Talks,
29 Birds of a Feather sessions ("BoF" – informal meeting between developers
and users), 8 workshops, and activities in support of furthering our
distribution and free software, learning from our mentors and peers, building
our community, and having a bit of fun.
The conference was preceded by the annual
DebCamp hacking session held 13
through 19 July where Debian Developers and Contributors convened to
focus on their individual Debian-related projects or work in team sprints
geared toward in-person collaboration in developing Debian.
As has been the case for several years, a special effort has been made to
welcome newcomers and help them become familiar with Debian and DebConf
by organizing a sprint "New Contributors Onboarding" every day of Debcamp,
followed more informally by mentorship during DebConf. Half a dozen new
contributors joined the sessions and learned about Debian, free software,
packaging and much more.
This year, a week-long DebCamp session was dedicated to auditing,
patching, and modernizing the Go ecosystem in Debian and enable the
transition triggered by the recent upload of dh-golang enabling GO111MODULE=on
by default in Experimental.
In order to make the conference more accessible for local participants,
a local language track was included in the schedule for talks in Spanish,
as was done at DebConf19 in Brazil.
The actual Debian Developers Conference started on Monday 20 July 2026.
In addition to the traditional "Bits from the DPL" talk, the continuous
key-signing party, lightning talks, and the announcement of next year's
DebConf27, there were several update sessions shared by internal projects
and teams.
Many of the hosted discussion sessions were presented by our technical
core teams with the usual and useful "Meet the Technical Committee", three
talks about Linux Kernel, early boot and improving Debian’s kernel and
installer support for Chromebooks, and about twenty BoFs and talks about
Debian packaging policy, Debian infrastructure, security and privacy.
This year, and echoing ongoing discussions within the Free Software community,
Artificial Intelligence and Age Verification have been the subject of
several talks. The Python, Perl, Ruby, Go, and Rust programming
language teams also shared updates on their work and efforts.
More than 17 BoFs and talks about community, diversity, and local outreach
highlighted the work of various teams involved in not just the technical but
also the social aspect of our community
The schedule
was updated each day with planned and ad hoc activities introduced by
attendees over the course of the conference. Several traditional activities
took place: a poetry performance, the traditional Cheese and Wine party, the
Group Photos, and the Day Trip.
For those who were not able to attend, most of the talks and sessions were
broadcasted live and recorded. One can find the seventy hours of recorded
videos available via the conference
schedule,
or alternatively through this
link.
Almost all of the sessions facilitated remote participation via IRC and Matrix
messaging apps or online collaborative text documents which allowed remote
attendees to "be in the room" and ask questions or share comments with the
speaker or assembled audience. DebConf26 saw over 341 T-shirts, a day trip,
and up to 130 meals planned per day.
All of these events, activities, conversations, and streams coupled with our
love, interest, and participation in Debian and F/OSS certainly made this
conference an overall success both here in Santa Fe, Argentina and online
around the world.
The DebConf26 website
will remain active for archival purposes and will continue to offer
links to the presentations and videos of talks and events.
Next year, DebConf27 will be held
in Asahikawa, Hokkaido, Japan, from Sunday September 5th to Saturday
September 11th, 2027. As tradition follows before the next DebConf the
local organizers in Japan will start the conference activities with DebCamp
with a particular focus on individual and team work towards improving the
distribution.
Debian thanks the commitment of numerous
sponsors
to support DebConf26, particularly our Platinum Sponsors:
Infomaniak, and
Proxmox,
and our Gold Sponsors : Freexian, and
Viridien.
We also wish to thank our Video and Infrastructure teams, the DebConf26
and DebConf committees, our host nation of Argentina, and each and every
person who helped contribute to this event and to Debian overall.
Thank you all for your work in helping Debian continue to be "The Universal
Operating System".
See you next year!
About Debian
The Debian Project was founded in 1993 by Ian Murdock to be a truly free
community project. Since then the project has grown to be one of the
largest and most influential Open Source projects. Thousands of
volunteers from all over the world work together to create and maintain
Debian software. Available in 70 languages, and supporting a huge range
of computer types, Debian calls itself the universal operating system.
About DebConf
DebConf is the Debian Project's developer conference. In addition to a
full schedule of technical, social and policy talks, DebConf provides an
opportunity for developers, contributors and other interested people to
meet in person and work together more closely. It has taken place
annually since 2000 in locations as varied as Scotland, Bosnia and Herzegovina,
India, Korea, France. More information about DebConf is available from
https://debconf.org/.
About Infomaniak
Infomaniak is an independent, employee-owned
Swiss technology company that designs, develops, and operates its own cloud
infrastructure and digital services entirely in Switzerland. With over
300 employees — more than 70% engineers and developers — the company reinvests
all profits into R&D. Its public cloud is built on OpenStack, with managed
Kubernetes, Database as a Service, object storage, and sovereign AI services
accessible via OpenAI-compatible APIs, all running on its own Swiss
infrastructure. Infomaniak also develops a sovereign collaborative suite —
messaging, email, storage, online office tools, videoconferencing, and a
built-in AI assistant — developed in-house and as a privacy-respecting
solution to proprietary platforms. Open source is central to how Infomaniak
operates. Its latest data center (D4) runs on 100% renewable energy and uses
no traditional cooling: all the heat generated by its servers is captured and
fed into Geneva's district heating network, supplying up to 6,000 homes in
winter and hot water year-round. The entire project has been documented and
open-sourced at d4project.org.
About Proxmox
Proxmox develops powerful, yet easy-to-use
open-source server solutions. The comprehensive open-source ecosystem is
designed to manage divers IT landscapes, from single servers to large-scale
distributed data centers. Our unified platform integrates server
virtualization, easy backup, and rock-solid email security ensuring seamless
interoperability across the entire portfolio. With the Proxmox Datacenter
Manager, the ecosystem also offers a "single pane of glass" for centralized
management across different locations. Since 2005, all Proxmox solutions have
been built on the rock-solid Debian platform. We are proud to return to
DebConf26 as a sponsor because the Debian community provides the foundation
that makes our work possible. We believe in keeping IT simple, open, and under
your control.
The first issue I raised was “Now it’s not uncommon to have separate remote controls for the TV, VCR, DVD player, and the Cable TV box – a total of four remote controls” which seems to have alleviated. VCRs seem to have almost entirely gone away. The VHS Wikipedia page [2] is worth reading for everyone who hasn’t seen a VCR in operation, which I expect to be more than a few readers now and an increasing number over the next 18 years. I personally don’t have Cable TV, I own a DVD player which isn’t connected to my TV because I haven’t used it for years, I don’t own a VCR, and I don’t watch free to air TV. So I have one remote control for the TV which I use for Netflix and sometimes YouTube.
When viewing YouTube on TV there are significantly more adverts and longer adverts. I presume that is because installing an ad-blocker on my TV isn’t a viable option for me and it’s a total impossibility for most users. Generally my desktop PC is a much better platform for YouTube than my TV, it has a better quality display, is more user friendly (my previous post addressed the difficulty of getting to the data source that’s desired), and doesn’t require entering search terms via a slow on-screen keyboard. Netflix on Linux is limited to 720p at low bitrate which is obviously of low visual quality while on the TV it’s in 4K. I have Netflix so I use that only on the TV.
In my previous post I wrote a thought experiment on how to use a cheap laptop ($500 at the time – equivalent to $777 in 2025 money according to the Reserve Bank of Australia) to control a $5000 TV ($7770 in 2025 money). Now you can buy a new 65″ 4K TV for under $800 and a new laptop capable of 4K output for under $400 so the options are very different. For a $800 TV the manufacturer isn’t going to develop a remote control interface and Google (who develops the software the TVs run) won’t do it because it could reduce their advertising revenue. But a typical home user could setup a cheap laptop connected to their TV via HDMI providing a familiar and efficient user interface for themselves and visitors. For a Windows laptop 4K Netflix should work and for a Linux laptop the options of a laptop for everything apart from Netflix and the TV for Netflix are bearable, two controls are worse than one but better than the 3+ that used to be common.
In my previous post I raised the issue that “it’s often the case that you don’t want to stop watching one show while trying to find another”. This is still an unsolved problem and is not addressed in modern software. I am not aware of a Linux music player that supports such functionality and this would be much easier for a music player than for a video player where the screen would have to be shared between the interface for finding the next thing to play and the space for playing the end of the current one. Maybe I should file a bunch of wishlist bugs against music players asking for this.
I suggested that “cable modem” and “cable TV box” could be integrated into a single device. That has not happened, in fact it’s got worse. A relative who has Foxtel has a cable modem, a cable TV box, and a Wifi AP with VOIP to provide landline phone service and to make it more exciting the latter two both have bugs that require a periodic hardware reset to fix. Hopefully cable TV will go away in the next 18 years.
Regular PCs have become less noisy in recent years. I am currently using a HP Z640 to write this post and I have HP Z840 and HP Z4G4 systems behind me running as servers and the background noise is still very low. The allegedly 8K TV [3] that I have in my lounge room has cooling fans that make more noise than those three high-end HP computers combined. Using a quiet PC like one of those HP systems to drive a TV is a very viable option and I did just that for a couple of years. Kogan has currently got a selection of refurbished Lenovo ThinkStation systems on sale for under $400, they are quiet and would do well for this, it’s also nice that Kogan is selling systems with ECC RAM at home user prices.
TV does seem to be going away. YouTube and streaming services seem to get more watching time and many people don’t use TV at all.
Since my previous post the number of streaming services has increased so torrenting offers increasing benefits as no-one wants to subscribe to 6+ services. For anyone who wants to get all the content that interests them while paying the user interface situation is much worse now than it used to be in 2008.
If you use KDE on a PC then the kconnect program allows a phone to be used to remotely control some aspects of a PC and has a good interface for pause/resume of a video and seeking 10 seconds forwards/backwards. The interface for controlling volume is hard to get to and doesn’t work on my installation. If you want to use a keyboard to start something playing and then a phone for pause control then kdeconnect is a decent option. A comment on my previous post by Michael Croes raised the issue of remote control which is now a solvable problem. Justin also wrote a comment suggesting a Nokia N800 as a remote.
Jason suggested a programmable remote, which would be a good option for a power user and a viable option for someone setting things up for their grandparents. But the amount of pain is greater than I’m interested in as lounge room TV isn’t an important thing to me. It may appeal to more people than having a dedicated lounge room PC though.
One of the most important inputs one can have when designing a response
strategy against a security attack is a good characterization. This article
describes a relatively newly described attack mode (subscription bombing),
hypothetizes on the motivations that can lie behind it, and presents some
countermeasures that can be taken by different actors to reduce its impact.
At its core, suscription bombing is a classical reflection attack: it uses
a third party service so that the answer to a relatively simple request is
amplified and results in a distributed denial of service (DDoS) for the
victim. And, as with most DDoS attacks, its effectivity lies in that there
is not much a person can do against traffic coming from seemingly random
different providers all around the world.
The core differentiatof for subscription bombing is that the attack’s
victim is not a network port, but an individual’s e-mail address. The
attacker builds a database of service providers that allow interested users
to sign up for newsletter on their activities, or a mailing list, or even
just to create a new account on a given Web system. This action will
generate a (seemingly legitimate) confirmation mail sent to the victim. But
the attacker scripts together hundreds of thousands of such request,
creating a deluge of confirmation mails sent to the unsuspecting victim.
The authors explain the goals an attacker might pursue by performing this
kind of attack. They suppose this can be due to harassment (a disgruntled
employee being denied a salary raise, a political adversary, or even a
romantic ex-partner wanting to inconvenience the victim’s use of their
e-mail). More worryingly, the attack can be used as a distraction: by
sending a high volume of mails in a controlled timeframe, the attacker can
reduce the probability of the victim noticing a specific attack warning
them of, i.e., financial fraud, unwanted purchases, or break-in attempts
into their accounts. Attacks targetting mailboxes at private mail servers
can also lead to overloading an account’s limit, causing it to reject
mails after the attack is delivered and before the folder is cleaned. And
it can also pave the way for follow-up, targetted deception attacks, where
the attackers call the victim pretending to be the company’s IT department,
and get them to install a remote desktop monitoring and management tool,
with which they can effectively seize control of the victim’s data.
To do this, they present a study they made over 24 cases of victims, from
which 47,970 total e-mails were received between October and December 2024,
with individual attacks receiving between 81 and 3,387 e-mails per hour,
from where they presented several descriptive analysis.
The authors explored cyber criminal’s offers on underground websites,
comparing flooding services and pricing schemes.
Finally, mitigation strategies are discussed. Mitigation is quite
problematic, as none of the mail servers is acting in either a hostile way
or lacking permissions — they are performing just the task they should. The
authors suggest four mitigation strategies for mail server operators to
reduce the burden on their users, although none of them is easily
automatizab (rate-limit the number of emails a given inbox can receive from
previously unseen senders; educate users about this kind of attacks; group
similar newsletter or account reset mails during active attacks; and
automatically unsubscribe or bounce newsletter messages when a surge is
detected). They also recommend newsletter providers and services accepting
the unrestricted creation of user accounts to provide some hardening to
increase the effort wrongdoers need to spend to abuse their services, such
as requiring CAPTCHAs or requiring users to take several steps before
requesting a subscription, although they recognize this adds friction to
the process providers are most interested in providing; filtering and
triaging known-good and known-bad domains, although this is hard to
implement on a preemptive fashion, and adhering to easy unsubscription
standards, such as easily identifiable headers with which mass
unsubscription could be performed more easily victims, instead of hunting
for the right places to click, potentially even in mails written in an
unknown language.
The described problem is interesting, and properly tackling it can be a
game changer for many users who will suffer this kind of abuse, and the
article is easy to read and soundly supports its claims.
I am not sure what happened, but my interests have changed significantly, and… I
haven’t blogged, I haven’t done any open source work, and didn’t even process
any pictures for the entire year. Not because anything went bad, just… new
stuff, new interests, life changes.
However, still alive, and still struggling with sports, and with sleep :)
On the positive side, on a recent mid-length flight, I thought — I haven’t done
any work on Corydalis, since last year I closed quite of a few of my “must have”
features, so probably, nothing else to do for now, right? I opened an editor and
started thinking about ideas, and surprised! One hour later, I had written down
enough ideas for a couple of months of work. So now just need to find the time…
but can’t wait for the planned things!
Found the right tab in chromium, paused playing, sleep works again.
My sleep was a good half an hour overdue, and all I got for it was to write
this blog post.
Of course Gnome could have shown me its inhibitor list instead of doing
nothing, since it has that information, but it didn't.
What I really would expect is that if I intentionally click a suspend button,
audio and video playing wouldn't inhibit the suspend. Maybe in a future version
of Gnome?
Some time ago I worked in the IT department of a company that had a corporate standard of two 27″ FUllHD (either 1920*1080 or 1920*1200) monitors for the desktop. I was pushing to make the standard be one 32″ 4K monitor or the two cheaper monitors. They ended up making one 27″ 4K monitor an option which was still a better option for many users than two FullHD monitors due to having twice the pixels even though it had half the screen area. It was a surprise to me when hardly anyone took up that option.
One man who worked there brought a wide curved monitor from home and ran with one of the FullHD monitors on each side of that. As an employee in the IT department I had concerns about expensive personal equipment being used in the office regarding who’s going to pay the bill if it gets broken. But I was assured that it was his old monitor that he didn’t need after buying a better one for gaming at home and he wouldn’t be too upset if something happened to it.
This isn’t the only time I’ve witnessed such problems of companies paying large salaries for skilled people and providing poor equipment for them to do the work. One previous time I raised a OH&S issue because the outdated monitors were so blurry but the company determined that the monitors wouldn’t cause health problems and spending $150 per employee on better replacements was a waste of money.
Computer hardware tends to become cheaper over time and one thing that has become really cheap recently is portable monitors. Kogan has a 15.6″ FullHD monitor with USB-C and mini-HDMI inputs for $89 [1]. It wouldn’t be difficult for someone to put one of those on each side of the monitor or monitors that their employer provides and put them in a desk drawer at the end of the day to minimise risk. The same Kogan page has a 16″ monitor with 2560*1600 resolution for $189.
I don’t think that adding such portable monitors will directly help the majority of workers. I think that to maximise performance and efficiency we need to chase the long tail of improvements. Big monitors, really big monitors (65″ at a larger distance), multiple monitors, standing desks, and whatever else people want.
There was some research from Microsoft some years ago (back when 27″ was a really big monitor) showing that some tasks had a 50% increase in performance with a larger monitor. Now that 27″ is about the smallest monitor size commonly available the potential for improvement is reduced. Probably most workers now already have monitors that provide the benefits to them that the “big monitors” in Microsoft research provided. But there will always be some portion of the user base who will benefit. If you can get a 50% performance boost for 1% of the users that’s really worth doing. If you can get a 0.5% benefit for 100% of the users that is also worth doing and will theoretically give equal benefits.
Costs of Employees
It is claimed that the total cost of an employee including all overheads of management and providing office facilities etc amounts to twice their base salary. If that is the case then a minimum wage employee in Australia costs $100k per year, someone at the low end of the IT pay scale costs $200k, and someone at the high end of the IT scale is around $400k. It seems clearly worthwhile to spend $1000 in hardware purchases for a $100k employee who declares that it will really help their work, anything which is noticeable to the user is going to be more than a 1% difference in performance.
For someone at the high end of the IT pay scale spending $40,000 on hardware to improve their performance could pay for itself. This is not only due to direct return on investment but because the people who do such work are often in key roles in important projects. If there’s too much work for one person on minimum wage to do then you just hire another person. You can’t hire another senior IT person and have them just do the work, it can take months to get up to speed.
But as management in corporations seems unable to recognise this cheap hardware employees can afford to buy with their own money can bridge the gap.
Job Interviews
In future when interviewing for jobs I’ll ask about the hardware that’s to be used. I won’t say “I’m not interested in this job offer because you don’t respect your employees enough to buy adequate hardware”, but I may make it a condition of working at a company that the hardware on my desk will not be obsolete.
R and the CRAN repositories maintain a very
high level of what we might call “quality assurrance” by requiring that
newly-added code does not break any existing dependencies. This is
frequently called a “reverse-dependency check”. For any given CRAN package one can quickly
determine it reverse dependencies. Calling
tools::package_dependencies(pkgName, reverse=TRUE) will for
a scalar or vector-valued argument return a named list with the reverse
dependencies. It is then a matter of looping over this list. There are
helper functions in base R as well as in contributed packages on and off
CRAN. I also wrote my own with
package prrd which,
while possibly a wee bit specialised and under-documented has served me
well to check on Rcpp and
related packages which can indeed have a large number of
reverse dependencies.
I recently looked into one of these contributed runner packages, and
while I will refrain from naming its implementation language let me just
mention that the term “cargo cult” may be a real thing
here. What go me interested in this was the fact that if one
has a simple-to-use runner then the fact that r2u makes it “fast, easy,
reliable: pick all three” (to borrow its slogan) to deal with actual
depencies if Ubuntu has indeed been selected as the host. We will
maintain the position that if you can in fact integrate with
the system-wide package management then any alternative per-repo package
management approach not doing so will likely be dominated by an approach
that does integrate with the system facilities. Which is what precisely
what r2u does, and
offers. And why it is used enough to by now have shipped eighty eight
million binary packages. So I tested it for the reverse-dependency check
task.
What I learned by looking into the (much more complicated) runner was
that it at the end of the day it hands the actual task of running the
reverse dependecies off to a helper function rev_check that
is part of the xfun package
by Yuhui. I quickly found that besides xfun we would also need its
suggested dependency tinytex which in turn
would error unless the tlmgr binary was present. So as the
sole requirement (on an Ubuntu system with r2u) turns out to be
where we do it all in one apt call (as root
in the container). (Given r2u we could also call
install.packages(c("xfun","tinytext")) followed by
apt install texlive-base but it is simpler for this setup
step to be just one call).
With that we are basically done. I did this (twice) using a
rocker/r2u container with r2u preinstalled, mounting
a local work and scrap directory for the container. In it we expand the
package to be tested (i.e. tar xaf pkgName_*tar.gz for a
given source package pkgName from CRAN) and then just call with the
package name and expanded direcrtory. I.e. I used this call to test my
package AsioHeaders (which has just three reverse
dependencies) to both name it and to point to the expanded source
directory created for this purposed:
>system.time( res <- xfun::rev_check("AsioHeaders", src="AsioHeaders") )## ... earlier output omitted for brevity here ... user system elapsed 35.7323.333149.683> res httpgd ipaddress websocket 000>
and about a good two minutes later I would get the timing result and
the summary in variable res. As I checked the current CRAN version, the check was as
expected free of concerns or issues.
To support this, r2u
did indeed go off and install about sixty seven binary packages (and the
total includes all binary dependencies fully resolved) delivering on the
‘just works’ promise by the r2u documentation.
As another check, I did the same for RcppAnnoy which has
seven reverse dependencies and needed about two hundred CRAN packages to be installed. The
full test took just over four minutes with the timing function reporting
some nice gains from parallelisation as total user compute time was on
the order of just under eight minutes. Again, test results were clean
and free of worries as expected:
>system.time( res <- xfun::rev_check("RcppAnnoy", src="RcppAnnoy") )## ... earlier output omitted for brevity here ... user system elapsed 471.765378.220266.855> res bbknnR bigANNOY blocking scDHA Seurat uwot VectrixDB 0000000>
Overall this was a rather useful quick excursion as it demonstrates
that - existing functions can be used to orchestrate a reverse
dependency check - with ‘reasonable’ dependency scale we can do this on
a single machine quite easily taking advantage of parallel computing on
multi-core machines - using r2u gives us fast,
easy, reliable package installation making testing of packages we
might not otherwise use or know a breeze - doing this in an ephemeral
Docker container facilitates easy build-up of required resources and
leaves no side effects behind which might affect our normal development
environment
After seeing a video a few months ago demonstrating how a
proprietary CAM solution uses machine learning and large language
models to automatically generate CNC instructions, and successfully
testing it on a real CNC, I began wondering if the same could be
achieved with free software. I still do not know the answer, but I may
be getting closer to finding out. Two weeks ago, I came across the
video "I Connected
Claude AI to FreeCAD (And It Models Parts Like an Engineer)" by
Make Form, which introduced me to the
FreeCAD MCP
project. Even though the video creator apparently believes it is
acceptable to download and run random binaries from the Internet on a
local machine (his setup uses UCX), I do not. I would probably have
left the project alone entirely if I had not noticed that all of its
dependencies are already available in Debian. This significantly
boosted my motivation, so I set out to test it using packages built
from source on Debian rather than relying on untrusted binaries.
The first hurdle was that
the MCP SDK for
Python was not present on my Debian Forky test machine. I
initially believed it was missing from Debian altogether, but it has
been available in Debian Unstable for about a month and is only absent
from Forky because some automated tests fail on architectures like
riscv64 and s390. Fortunately, backporting it was straightforward
using `apt-get source -b python3-mcp`. The next hurdle involved an
outdated version of the
Validators Python
library. Since I am a member of Debian's Python team, which
maintains this package, updating it to a sufficient version for
FreeCAD MCP was relatively easy. I could not upgrade to the latest
upstream release due to a new dependency on an Ethereum-related
library, so I settled on a 2024 version.
With those dependencies in place, I proceeded to create a Debian
package for FreeCAD MCP. I had previously submitted a
request for packaging of
FreeCAD MCP to gauge interest while deciding whether to prioritize
maintaining it myself. Because salsa.debian.org blocks access from
Tor users like myself, I published my draft packaging scripts in a Git
repository on Codeberg as the
Debian FreeCAD
MCP project and got it working with the FreeCAD 1.1 version in
Forky. I initially struggled with the button controls for the MCP
feature, which led me to submit a pull request titled
"Fixed
startup sync of checkable toolbar buttons" proposing a fix. Once
this confusion was resolved and the MCP setup was enabled via the GUI,
I was able to run FreeCAD completely headless using `xvfb-run` on a
machine without an X server to generate models. I am using a private
LLM service running the
Debian package of llama.cpp with the Qwen 3.6 model downloaded
from Hugging Face, configured with a maximum context window of 105k
tokens. I also tested the Bonsai model on my test laptop; initially,
its context window was too small (8k and 16k could not accommodate the
FreeCAD MCP instructions), but even after increasing it to 32k, it
proved useless for generating FreeCAD models so far. I've used Claw
Code, Aider and Open Code with my server so far, and for this test I
ended up with OpenCode because it was easy to set up to use an
MCP. Because none of my LLM services are set up to be multimodal
(capable of processing both text and images in this case), I
configured the MCP to return only textual feedback from FreeCAD. I am
unsure if this is a major limitation, though I suspect it might
be.
My testing experience remains limited, with no clear successes
yet. Part of the issue likely stems from my ability to provide
effective instructions for modeling 3D objects (I am relatively new to
FreeCAD, English is not my first language, and I lack a precise
vocabulary for describing construction features to an
LLM). Nevertheless, the LLM has demonstrated the capacity to create 3D
models in FreeCAD. In one of my first tests, I asked it to generate a
cube and then produce CAM/G-code instructions for a CNC machine. It
did output G-code (which remains untested), but I was surprised to
find that it bypassed FreeCAD's built-in CAM module entirely and
instead generated an external Python script to produce the code. This
was not quite what I intended, though my instructions were probably
unclear. The Qwen model with OpenCode seems to strongly prefer
programming directly; it frequently executes Python snippets inside
FreeCAD to achieve its goals rather than using the standard
sketch-and-extrude workflow I am accustomed to. In another test, I
asked the LLM to create a parameterized pipe assembly to see which of
FreeCAD's parametric tools it would choose, but found no evidence of
traditional parametric features in the output. When prompted, the LLM
explained that the parameters were embedded directly in the Python
script used to generate the model, rather than in native FreeCAD
features. With more explicit instructions, it eventually created a
FreeCAD spreadsheet to manage the parameters. The resulting model
looked much closer to my expectations and could have been useful with
further refinement. My so far last experiment was less successful: I
asked it to design a pipe clamp, but the LLM repeatedly failed to
position the clamping screws in a way that would actually secure the
brackets around the pipe. It is unclear whether this limitation lies
with the model, my prompt, or other factors.
Based on my testing so far, I am uncertain whether FreeCAD MCP is
merely a fun toy or a genuinely useful tool. I will only commit time
to maintaining it in Debian if it proves to be practically valuable. I
would welcome feedback from anyone who has experience with the
project, preferably via the original request-for-packaging mailing
list thread. Alternatively, I am available in the FreeCAD and Debian
AI IRC channels for further discussion.
I first heard of Plan 9 from my friend Vajra in 1999 or so, as we were distro-hopping on early Linux distributions and trying to find our way. Vajra is now a Nebula Award-winning science fiction author - have a look at his work. We had just been through Tom's Root Boot, a UNIX-like operating system crammed into a single floppy, and through it discovered a whole new world outside of DOS 6.22. Combing through old UNIX manuals, we went in search of the perfect OS, through Slackware, Caldera, TurboLinux, SUSE and Red Hat. I finally settled on Debian, which lived up to everything I stood for.
Plan 9 was distinct. It came out of the Computing Sciences Research Center at Bell Labs, built by Rob Pike, Ken Thompson, Dave Presotto and Phil Winterbottom, with Dennis Ritchie heading the department. The name is a joke at their own expense, borrowed from Ed Wood's 1959 Plan 9 from Outer Space, routinely nominated as the worst film ever made. Thompson and Ritchie had, of course, built the original UNIX; it almost seemed as if they were building a new OS from the lessons learnt from building it - which was in turn built on the lessons from Multics. I remember the awe I felt playing around with Plan 9, and I've not been able to replicate it since.
Plan 9 was different in a couple of fundamental ways: per-process namespaces, and a protocol that abstracted locality of resources to processes. As a consequence of these core primitives, the OS surface area was distinctly small. The entire system from the core kernel, to the system call interface, to the compiler, linker and shell was reduced to a form small enough that a single developer could hold it in their head. Lessons from the implementation of UNIX helped the designers make the system leaner, and in Ken Thompson's words, it's the "best operating system out except that it doesn't have the apps that everybody demands" [1].
It also took the concept of "everything is a file" in UNIX to a whole new level. The network stack is a filesystem (/net), processes are files, the display is a file (/dev/draw). Because every resource speaks 9P and every process has its own namespace, you can mount another machine's /net into your namespace and your program makes network calls through that machine's stack without knowing or caring. No sockets API, no RPC layer, just ordinary file system operations through a simple system call interface.
Some would say that OS research is dead, and that backwards-compatibility and POSIX killed it. Rob Pike himself argued as much in his 2000 talk, "Systems Software Research is Irrelevant" - but we didn't care at the time. There was so much happening that we didn't have time to take it all in. And then Linux happened, and Software Freedom became a focal point (more on that in a later post).
In the summer of 2020, with the world deep in Covid lockdowns, I decided to build a toy operating system, just to try my hand at the the thing that I had always wanted to do. I spent three feverish months working on Odyssey and, looking back, it is perhaps the most fun I have ever had. I would not dare compare it to the magnum opus that is Plan 9, but it gave me perspective: how hard it is to build an OS from scratch, and above all, how fun it is to build an OS from scratch, and why the original creators kept coming back to the same problem. The highlight of those three months was booting the OS and watching it render "The Great Wave off Kanagawa". Nothing in my professional achievements to date captures what that meant to me.
Odyssey displaying "The Great Wave Off Kanagawa"
Decades on from the first time I booted Plan 9, I look back with nothing but awe and respect for the creators of this little operating system and marvel at the foresight that went into it. While many readers will not have heard of Plan 9, they have almost certainly worked with the ideas that came from it: 9P (if you ever used the Windows Subsystem for Linux), UTF-8 (if you ever used any modern operating system), per-process namespaces (if you've ever run a container), Go (whose assembler still uses Plan 9 syntax).
Plan 9 still lives on in 9front, a community-maintained fork. Separately, Yoann Padioleau [2] has produced a set of annotated books at principia-softwarica.org, presenting the Plan 9 source in the spirit of Donald Knuth's literate programming - an admirable effort to introduce new readers to the art of operating systems engineering.
Pike thought systems research had become irrelevant, and Thompson thought Plan 9 would never "make it" [1]. Both were right about the industry, but may have been pessimistic about the impact. The system lost as a product but won as a set of ideas, assimilated one at a time by modern operating systems. Success is not always measured by popularity. The mark that Plan 9 left behind is greater than what's reflected in its current user base.
To me, Plan 9 will always be the OS that punched above its weight class, the little OS that could.
Even more surprising that behavior is actually standards-compliant,
even mandated by RFC 3986.
The underlying motivation is relative reverences.
If some resource reachable by "https://example.com/foo/bar"
references another resource relatively as "../../baz" then
this is of course the intended result.
Getting from this problem to what RFC 3986 suggests
might be surprising in the result, but somewhat understandable if you
look at the consequences of that problem:
Giving the path components ".." (and ".")
special meaning at the start of the relative reference means that if you allowed
them in absolute URLs those would be impossible (or at least very convoluted)
to address as relative URLs.
So RFC 3986 describes a way to handle them everywhere:
Just join the path of the base URL and the path of the relative reference
and normalize the result. Or normalize the absolute on either side if only
that is to be taken.
This makes things very convenient:
Multiple reference URLs can just be joined without special handling for
relative references starting with dots, making writing applications handling
them easier.
Programmers don't have to care how to handle relative references and can
just join everything in whatever way they want.
For maximum elegance there is still some corner case left:
What happens if an absolute URL has a path starting with double-dot components?
Or an relative path starting with more of them then the base URL's path has components.
You just ignore them:
With that last point every URL is valid and has well-defined meaning.
Handling relative references and relative paths is very easy and convenient.
So this shows a high regard for simplicity, elegance and convenience.
And a total and uncompromising disregard of security.
After all the most convenient it is for an attacker;
If they are allowed to supply a path component for a request a system
does in their behalf, then they can easily escape anything they were supposed
to be limited to.
The ignoring of dots at the start means they don't even have to know
exactly how deep their request is:
So even if the resource server securely handles request
(unless you consider not having any way to lower your permissions for one request to a specific subset),
your fully RFC conforming client library will already request the permission they should not have permission for.
Even worse dots are usually not characters you can easily forbid so once slashes are to be allowed things get complicated.
There also would have been a simple, elegant and secure way:
Consider every path element ".." or "."
in an (absolute) URL an error.
Define a reference resolution that allows the relative reference to only start
with "./" or one or multiple "../" and
consider every appearance of a dot or two dots as path components after than an error.
Everything joining two paths has to either use an implementation of that path joining
algorithm, but only if they want to joins paths in the potentially dangerous
way allowing leading "../". Otherwise they can just use the normal
join and even if an attacker gets those dots that will just cause the generated URL
to be rejected as invalid.
Of course using a secure implementation is now even more inconvenient thanks to RFC 3986 being around:
If you have no control over the generator of relative references, it is always possible
that they generate relative references with ".." components after non-dot
components.
And if you check all code to properly filter out "/../",
keep in mind that convienence does not stop there.
After all it is not unheared of for server implementations to helpfully normalize
unicode characters, too, or translate them to their nearest ASCII equivalents.
Or translate percent escaped characters back before doing path splitting.
Or you might think there was some unicode codepoints between those two dots,
but they that those were some meaningless control characters that can be omitted.
So you need some really restrictive allow lists...
1981 was a different time for computing. It was expensive (both hardware and software), and it was far from a given that machines from one vendor would be able to talk to those from another. In fact, Columbia University had just such a problem, so in 1981, Frank da Cruz and Bill Catchings designed a serial protocol they called Kermit. Because of the many quirks of the DEC-20 and IBM mainframes, the Kermit protocol was highly adaptable from the start: able to handle systems that had trouble processing more than 96 bytes of data at once, able to transfer 8-bit files over 7-bit links, able to translate between character sets (ASCII and EBCDIC then; now also various Unicodes), and of course, handling of error-prone serial links.
Kermit spread rapidly; by 1982, Kermit had been ported to MS-DOS and Unix. Eventually, C-Kermit (an implementation of Kermit in C) became the flagship Kermit. It gained TCP support, an interactive CLI, a powerful scripting language (with features from the shell, Lisp, and expect), and optimizations for today’s high-speed links, such as jumbo packets, sliding windows, and streaming modes. Along the way, Kermit flew on the International Space Station, ran data collection from sensors during hurricanes, and many other uses including postal systems, Boeing 787 manufacturing, and more.
Today, I use it as a powerful ssh wrapper (letting me easily transfer files through multiple nested ssh, sudo, su, etc. commands), a BBS client, to exchange data with me HP 48GX calculator, and so on. It’s also used today to transmit firmware updates to embedded devices. And, of course, anyone that works with vintage systems is likely to use Kermit at some point.
It wouldn’t be until the late 1990s that the TCP/IP stack was finally adopted by most OS vendors, establishing something of a common basis for communication. Of course, we assume this today. Though transferring large files between OSs (say, Linux, Windows, MacOS, Android, iPad, etc.) is still a challenge, even though they all speak TCP/IP! I find that the easiest way to get large files from two computers is to spin up Kermit (see ckwin for a Windows fork of C-Kermit) and just set up a TCP connection over the LAN. In fact, I added a new show interfaces command in C-Kermit 11, making it easy to see your system’s local IPs.
For most of its history, Columbia’s Kermit project was self-funded. Columbia charged for commercial use, which limited its inclusion in Linux distributions. In 2011, 30 years after its founding, Columbia canceled the Kermit Project and released C-Kermit as Open Source under a BSD license. Frank da Cruz, who had still been working with the Kermit project all those years, volunteered to continue maintaining Kermit outside Columbia, and continued development with alpha and beta releases through his retirement from the project in 2025.
I dive into this C codebase
As Debian maintainer of Kermit, I noticed some areas where it wasn’t matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year.
I’ve worked with old C codebases before, such as Varnish. I’ve generally hated it. You usually find a mix of bad and terrible practices, unclear memory management, and so forth.
But I’ve been living in the C-Kermit codebase for a few months now, and I enjoy it. Yes, this thing is still designed to build on VMS, OS/2, and with compilers that haven’t heard of ANSI — and those that require modern practices. (That em-dash was mine; I knew how to use them before LLMs existed and I’m not going to stop just because LLMs have copied people like me! No AI was used for this post.)
The there is an elegance in all of that. As I worked, I fixed a bunch more potential security issues, both with memory safety and with protecting against a malicious remote in roughly the same manner that some patches to scp did a few years back. I added IPv6 support, of course conditionally compiled because some systems C-Kermit builds on have never heard of IPv6 and never will. (And, of course, with fallback algorithms at runtime for systems that have IPv6 support but not IPv6 connectivity.)
I added unit tests and Python-based end-to-end tests, running nearly 2000 test cases in total. Along the way, I found and fixed a number of bugs going back decades. I learned about FIONREAD being broken on macOS, about NetBSD’s bugs in the pty driver, and fixed bugs in the Kermit protocol implementation itself. I added compatibility tests with the gkermit and ekermit (embedded) implementations, as well as the last full release, C-Kermit 9.0.302 from 2011 (which was difficult to get compiled on a modern system).
There is an extensive changelog describing all the improvements in C-Kermit 11.
C-Kermit development had never really used a VCS at any point, though Kermit veteran Jeffrey Altman imported historical releases into a Git repo, along with some patches that hadn’t made it into a release (which I also pulled in.) There was a lot of disabled code behind #ifdef COMMENT, along with commentary describing why it was no longer used. With Git, we would now generally just remove the old code and explain why in a commit message. I went through and did so with a lot of it, meaning that, at last check, C-Kermit actually has fewer lines of code now than it used to.
Towards a new release
It became apparent pretty quickly that I was making more changes than would make sense as a Debian patch series. Not only that, but they would be more widely applicable to more than just Debian and Ubuntu users. As Linux and BSD distributions were running everything from the last non-beta release (2011’s 9.0.302) to the last beta release (about 1.5 years ago), depending on their different policies about running betas, even sharing patches in a useful fashion was going to be quite difficult.
So, I spun up a project at Open Kermit to coordinate future development in the open and keep Kermit going.
With modern CI, I run that test suite on Linux (x86_64 and arm64), macOS, FreeBSD, NetBSD, and OpenBSD. It builds binary releases on all those platforms, plus a statically-linked Linux binary built with musl libc.
Frank da Cruz was directly involved with Kermit for 44 years. I’m not aware of any other Open Source project founder being involved for so long. Richard Stallman started working on GNU Emacs in 1984, 3 years after Frank started working on Kermit, but Richard hasn’t been in that role since around 2008.
Accordingly, C-Kermit 11 bears this dedication:
I dedicate this release of C-Kermit to Frank da Cruz.
Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long.
When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so.
Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines.
As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit.
Yesterday, I uploaded Term::ANSIColor v6.0.0-TRIAL to CPAN for early
testing. This release will raise the minimum required Perl version to
5.12, dropping support for Perl 5.8 and 5.10. When I did the same with
podlators a couple of years ago, it upset a few people and one of them
asked me to make this sort of test release in the future. Hopefully this
will help.
I have not run the normal release machinery and haven't archived this
release in the normal places, since I intend it to be transient. It's only
on CPAN, where people can retrieve it for testing. Once v6.0.0 is
released, few traces of this TRIAL release will be left. This doesn't
appear to be how other people use the TRIAL mechanism, but it felt more
comfortable to me. If I have to make substantial changes, I'll consider
changing my approach.
I plan on turning this into the v6.0.0 release in about a month or two,
hopefully with only documentation changes.
Term::ANSIColor is a "very upstream" core module with a lot of
dependencies, and CPAN (unlike some of the archives that followed it, such
as PyPI) doesn't support conditionally retrieving packages based on the
current Perl version. This release may therefore be disruptive for people
who are still trying to support Perl 5.8 and 5.10, since CPAN installation
tools may attempt to install an incompatible Term::ANSIColor version. I'm
sad that this will be the result, since I know some people still care
about those versions.
I'm pressing forward with updating my Perl modules anyway, though. I
realized that honoring other people's desire for stability to such a
degree that I was unable to use Perl features added more than 15 years ago
was destroying my motivation to work on these Perl modules at all. So I've
decided on a very slow and gradual approach where I'm going to keep
pushing the minimum supported version forward but try to give people a lot
of warning.
Personally, I think it's time to let ancient versions of Perl go and
follow the
Lyon Amendment about supported Perl versions. When we're talking
installing new modules for software released more than 15 years ago, we're
talking about special limited environments and retrocomputing more than
what I would consider routine software maintenance. Those tasks should
expect to need different tools and a different workflow so that they can
pin historical versions. Since this isn't something I'm personally
interested in, my willingness to expend time and energy to assist is
limited.
As you can probably tell, I still feel nervous about pressing forward in
this way, but I think this is the approach that lets me continue to enjoy
maintaining these Perl modules. It's been 29 years for Term::ANSIColor,
but I still enjoy fixing bugs in it and putting out a new release from
time to time, particularly if I can clean up the code a bit each time I
touch it.
How to Steal a Galaxy is a far-future science fiction caper short
novel (maybe a novella?) and the sequel to Full Speed to a Crash Landing. You don't have to remember the
details of the previous book to enjoy this one. There's an excellent
inline summary at the start of this installment.
After an annoying negotiation with people who keep trying to preach at her
about causes, Ada Lamarr has a new contract. She is going undercover,
after a fashion, at a charity gala and auction on Rigel-Earth. While she's
there, she's going to steal something. What, precisely, she keeps a
mystery from both the other characters and from the reader until the end
of the story.
Government agent Rian White is working security at this charity gala. Due
to its link with the plot of Full Speed to a Crash Landing, he was
fairly certain Ada would be there, as indeed she is. What she is planning,
however, is maddeningly unclear. Also maddening is how good Ada looks in a
dress.
As with the previous book, How to Steal a Galaxy is told by Ada in
the first person using the same teasing tone and constant misdirection
that she uses when verbally fencing with Rian and the other characters. I
found this novella even more entertaining and satisfying than the previous
one. The charity gala is supposedly intended to benefit the poor people of
Earth, and is run with exactly the sort of condescension and disguised
capitalist looting typical of such exercises in elite charity. Ada's
narration is scathing in a deeply relatable way.
Also, there is a trillionaire tech-bro fake philanthropist who is smug and
condescending and accustomed to getting exactly what he wants.
"I don't think anyone should have enough personal wealth to decimate a
large country's income just because he's going through a midlife
crisis."
Ada's interactions with Strom Fetor are an absolute delight. He is so sure
of himself that he is incapable of registering her as a threat, and she
effortlessly deceives him by hiding in plain sight.
"You really shouldn't be talking about this," Rian starts.
Fetor waves aside his concerns. "We're all friends here."
"Not me," I say. "I hate you. Remember?"
Fetor laughs in a tone I'm sure he thinks is charming.
Fetor's complete inability to realize that a beautiful woman might both
sincerely not like him and not be flirting with him is perfect. I was
cackling through half of this book.
Like any good heist story, there are twists and turns, surprises, double
agents, unexpected complications, and a delightful amount of verbal
fencing. I adore the narrative tone Revis uses for these stories. Ada has
just the right mix of idealism, cynicism, professionalism, and irreverence
to carry off the feeling that she's a step ahead of everyone else.
Underneath the bones of a delightful plot is a character who cares deeply
but is very aware of her limitations, and therefore has taught herself to
laugh at and be ruthless with her own emotions. I am finding it an
incredibly compelling type of competence porn.
I enjoyed the first book of this series, but this one was so much better.
These stories are exactly the right length to keep the reader engrossed
throughout and satisfied but wanting more at the end. How to Steal a
Galaxy ends on a cliffhanger of sorts, to be resolved in the next and
final book. I can hardly wait to start it.
).
.
Odyssey displaying "The Great Wave Off Kanagawa"
![[RSS 1.0 Feed]](common/rss10.png){kind=small}
![[RSS 2.0 Feed]](common/rss20.png){kind=small}
![[Atom Feed]](common/atom.png){kind=small}
![[FOAF Subscriptions]](common/foaf.png){kind=small}
![[OPML Subscriptions]](common/opml.png){kind=small}
![[Hacker]](common/hacker.png){kind=small}
![[Planet]](common/planet.png){kind=small}