A new minor release of prrd arrived at
CRAN this morning: the a first
release in two and a half years. prrd facilitates
the parallel running [of] reverse dependency [checks] when
preparing R packages. It is used extensively for releases I make of Rcpp, RcppArmadillo,
RcppEigen,
BH, and
others.
The key idea of prrd is simple,
and described in some more detail on its webpage and
its GitHub repo.
Reverse dependency checks are an important part of package development
that is easily done in a (serial) loop. But these checks are also
generally embarassingly parallel as there is no or little
interdependency between them (besides maybe shared build depedencies).
See the (dated) screenshot (running six parallel workers, arranged in a
split byobu session).
This release updates continuous intgegration files, switches to
Authors@R, and robustifies one SQLite aspect.
The release is summarised in the NEWS entry:
Changes in prrd
version 0.0.7 (2026-08-27)
Updates to DESCRIPTION have been made as CRAN requirements
change
The continuous integration setup was updated several
times
The database connection now uses sqliteSetBusyHandler
A new release of our linl package for writing
LaTeX letters with (R)markdown is now on CRAN. linl makes it easy to
write letters in markdown, with some extra bells and whistles thanks to
some cleverness chiefly by Aaron.
This version is mostly maintenance: updates to the continuous
integration setup, as well as updates to packaging including use of
Authors@R in DESCRIPTION. No functional changes, no new code, or new
features.
The NEWS entry follows:
Changes in linl
version 0.0.6 (2026-08-26)
Several updates to continuous integration and testing
In July, the Debian Stable Release Managers published the
last point release of Debian 12 (“bookworm”),
after which the Debian LTS team took full responsibility of Debian 12. This
completes the handover from the Security Team, that took place in June. This
also marks the second month in a row where the Debian LTS has been focusing on
two simultaneous Debian releases.
Other than Debian 12, the team is maintaining Debian 11 (“bullseye”), which
will reach the end of its Long Term Support on 31 August 2026. After that
date, Freexian will continue the security support under the
Extended LTS offer.
The team published several notable updates:
jq (DLA 4662-1
and DLA 4661-1)
prepared by Andreas Henriksson in collaboration with Jochen Sprickerhof,
addressing multiple vulnerabilities.
Several updates for the different linux supported versions prepared by Ben
Hutchings, in collaboration with Emilio Pozuelo Monfort. Other than the
regular security advisories:
DLA 4664-1,
DLA 4665-1,
DLA 4671-1,
DLA 4688-1, and
DLA 4700-1, Ben
started preparing packages of 6.12 via bookworm-backports.
nginx (DLA 4667-1),
updated for bookworm by Carlos Henrique Lima Melara, as a follow up of the
bullseye update
(DLA 4660-1),
that was prepared in June.
grub2/bullseye (DLA 4685-1),
prepared by Emilio. Other than addressing several security issues, this DLA
was needed for being able to update the shim boot loader.
samba (DLA 4692-1),
uploaded by Markus Koschany, to fix several security flaws in bullseye,
including issues that could yield to remote code execution.
imagemagick (DLA 4680-1
and DLA 4696-1),
prepared by Bastien Roucariès, addressing several issues that could lead to
denial of service, information disclosure or potentially arbitrary code
execution in some scenarios.
poppler (DLA 4709-1),
by Guilhem Moulin, fixing several vulnerabilities.
nss (DLA-4694-1),
by Jochen, fixing flaws that may result in or denial of service or
potentially the execution of arbitrary code.
Besides the work on security updates, different documentation and tooling
changes were needed, especially in the context of the Debian 12 handover. This
work was mainly done by
Sylvain Beucler.
As a Debian developer, I have had to cast a vote for the General Resolution named LLM usage in Debian (progress report here). This was not an easy task for me…
It’s a good thing that the vote is secret so that people are not scared of voting according to their own beliefs. I have Debian friends on the whole spectrum of opinions that are represented here, and I hesitated twice on sharing my own thoughts for fear of alienating my relationship with them. But in the end, we all make efforts to respect the opinions of those who are not thinking like us, and it’s precisely that willingness to work together towards a solution that is acceptable by the majority that makes Debian so strong. So here’s the train of thoughts that I followed to cast my vote.
The difficulty for me was to reconcile the political statement that I want to make and my desire for this vote to not be (too) divisive for the Debian community, and to make sure we are not putting off newcomers with choices that might be hard to stand by in the long term.
So let’s be clear : if I had a magical wand to make AI and LLM disappear, I would use it for that purpose, since at this point in time I don’t believe that the benefits outweigh the costs that the AI race is inflicting on us. If I were a political decision-maker, I would forbid the construction of new data centers unless they also build renewable energy infrastructure to cover for their additional energy consumption. I would also legislate so that AI companies have to document what material they used to train their models, and I would forbid scraping for that purpose, and build ways for those companies to buy copies of properly-sourced training data. That is to say, I don’t like the way LLM are built by the players in that market, I’m pretty scared of the ecological impact of what those players are doing, and I’m certainly worried about the long term effect that LLM will have on society as a whole.
Nevertheless what brought me to Debian is the ability to experiment and contribute to something useful with cool technologies, and as a computer scientist, the potential of LLM done right is hard to ignore. Given what we have seen already, I expect that LLM will empower (a part of) the next generation to learn IT, computing and even Debian packaging. Completely refusing the use of LLM is likely to make it harder for us to attract new contributors. In fact, we have already seen people inside Debian that would likely stop contributing if they are now forbidden to use LLM. I know there are likely others that will quit Debian if we accept it too, but I hope we can find a middle-ground where such persons can decide that LLM are not welcome in the small corner of Debian that they are in charge of…
In the end, I decided that answering clearly the question “Shall we accept LLM contributions ?” was more important than making the political statement about the current state of affairs in the AI landscape, both because I believe that Debian statements have a negligible impact on policy-makers, and because historically Debian has grown by staying close to technical excellence and relatively far from politics, except when it comes to the way we handle people. And as much as I care about climate change, I don’t see how bringing this up in the context of a Debian statement is helping its cause.
More concretely, it gives the following ranking (in decreasing order of importance):
B, D: those two choices are the clearest to express “Yes we should accept LLM contributions” and still acknowledge concerns about the way AI is built today
F, H: those two choices do not forbid LLM usage but discourage their use and clearly voice the concerns
E: this choice is basically the statu-quo and fails to acknowledge the concerns, but it does not forbid LLM usage
None of the above
G, A, C: those choices forbid LLM usage in various ways
I don’t know what option will win, but assuming that LLM-assisted contributions are allowed, I believe that it would be helpful to have further statements to clarify a few things:
Even if Debian as a whole doesn’t want to ban LLM-assisted contributions, each maintainer or each team shall be free to forbid LLM assisted contributions in the parts of Debian that they are maintaining
We should discourage usage of LLM provided by players with unethical behaviors (not sure if there are good players but well…)
I’m on a VPN setup with several friends that, obviously, includes a VoIP
network. I also have an old
magicJack adapter and a deep and
abiding need to use hardware in ways I should not. There was obvious synergy
here.
Plugging in the magicJack gives a USB vendor id of 0x06e6, which belonged to
a company called TigerJet who made a range of chips for hooking up phones to
computers, either via USB or PCI. Some more digging suggested that it was a
580 part, and someone had conveniently
uploaded
some reference code and datasheets, so figuring out how to talk to the chip
wasn’t terribly difficult. Once configured it simply sends HID events
whenever a user hits a phone key or changes the hook state, and otherwise
exposes a USB audio device that can be spoken to using the stock kernel
driver. It also has the ability to generate dial tone and assert ring
signal, giving a full traditional phone experience.
So you’d think this would be a super easy project, but I’d made things
harder for myself by deciding I wanted to tie directly into Asterisk rather
than just smashing an existing SIP stack onto the device. Asterisk uses
channels to
talk to devices, and channels end up as compiled C code that Asterisk can
load dynamically. I didn’t want to have to deal with the pain of compiling
stuff and matching ABIs and everything so writing a new channel from scratch
was unappealing. Fortunately, the websocket
channel
is available in recent versions of Asterisk and provides a convenient way to
get audio in and out, but that still leaves the job of handling incoming and
outgoing calls. That’s handled with the Asterisk Rest
Interface,
which can initiate a call or respond to an incoming one and bridge various
channels together to produce a bidirectional audio stream. There’s a
convenient async Python library that
handles the low level protocol.
Code for all this is
here1,
and works for my use case, but I should really abstract out the asterisk
side and the magicJack side to make it easier to adapt to other
devices. That’s a job for later, though. For now, you get this:
This has also been an excuse for me to figure out how to make Tangled work, which I’ll write about at some later point. But self-hosted git repo with a convenient collaboration plane! ↩︎
After ranting and railing about LLMs or "AI" as the optimists (or
accelerationists?) call it, I figured it might be important to
be a little more honest about my use of LLMs and how I think about it
more practically in the world.
The Debian vote context
This is not a coming out. I am not using LLMs on a daily basis, and
this blog is, again, written out of my cold dead hands in a dying
world, with over-engineered hardware and (to a certain extent, hi
Emacs!) software, powered by 100% green energy built on stolen land.
There is a vote going on in Debian. If you're unfamiliar with it,
you can catch up at LWN. So far I've essentially said "LLM is
bad" which is not a very balanced or useful opinion. Obviously, people
are using LLMs, sometimes unknowing or unwillingly, and we need to
take that into account. Furthermore, there has been many different
blog posts on Debian planet about this. Some that I found
balanced, good summaries, even if I didn't fully agreewith
them, at least some did the basic civil service of being
short. But others were just not only Wrong but also so long
that I couldn't finish that I just had to write something.1
This is not an explanation of the ballots, nor how I will vote. This
vote is Debian's failure of framing that debate in a reasonable way:
we have 8 options on the ballot with many duplicates. We have failed
to do the hard work of summarizing and aggregating options into a
meaningful set. I doubt the final vote will represent a readable
position we can rally around.
I have not read the twomonths of debates on the topic
either. Normally, before voting, I take a cursory look at the debate
to see points of view I might have missed. But in this case, it will
just make me sad, add noise, and I'm already pretty sure on where I
stand on this.
So let me describe how I use LLMs and how I think they fit in our
work, as computer engineers and hobbyists.
My LLM use
Debian Packaging
An astute reader has pointed out that I maintain a package in
Debian made to use Anthropic. It's actually multiple packages:
As I previously explained in response, I am not entirely
comfortable with this work: it's a compromise. In fact, I first
uploaded llm to the contrib section of Debian, where we keep
software that depends on other non-free software, but I was told that,
since yt-dlp was in main, llm belonged there as well.
An important part of my work is technology watch. I keep tabs on
thousands of (new and old) software projects, follow news, and
generally try to keep my skills up to date. It's a pretty impossible
race, especially as I grow older, but I still think I'm doing the
right choices in my job.
Testing large language models is part of that work. At first, I was
using ChatGPT's web interface, but it was annoying to copy-paste
things into a browser, so I looked for different interfaces.
For a while I tried gptel, a "simple, extensible LLM client for
Emacs" but I found it kind of terrifying. Giving a LLM control over an
Emacs buffer seems like a security nightmare, so I stopped doing
that.
So I use the llm command-line tool to talk to Anthropic's API. I
started that in the summer of 2025, when I bought 20$USD of API
credits. Before that, I paid for a ChatGPT subscription and then
OpenAI credits, which expired and sent me over to Anthropic, which
seemed then to have better ethics.
Needless to say, Anthropic and "Claude" are not my friends, but they
seem like the lesser evil in current "frontier models". So I have
renewed, a couple of weeks ago, another 20$USD of API credits with
Anthropic.
Actual prompts and responses
So what does 20$ give you at Anthropic anyways? What am I using LLMs
for and how?
The neat thing with llm is that everything is logged in a sqlite
database, so there are some answers that are easy to get:
> llm logs status
Logging is ON for all prompts
Found log database at /home/anarcat/.config/io.datasette.llm/logs.db
Number of threads logged: 7
Number of turns logged: 12
Number of legacy conversations: 543
Number of legacy responses: 970
Database file size: 9.61MB
That is 10MB of logs, with about a thousand prompts.
My logs go back to 2024-03-07, a little over two years ago, and
include a mix of Anthropic and OpenAI responses. I used it more in
2024 than 2025, and if the trend continues, I will have used it less
in 2026 again:
It looks like about 10 prompts per month right now, down from a peak
of about 60 per month in 2024. It's pretty difficult to analyze those
actual logs to get more patterns and I won't run the prompts through a
model again to process them.
How I'm using models now
At first, I was using it partly for benchmarking model's capabilities,
like Simon Willison does with his pelicans, clearly not trusting
its output. But I was impressed by the capacities of the Claude Opus
4.5 model when it wrote this script in January. Impressed, but
also scared: it's the first time I felt I could delegate the entirety
of my programming to a model. Just run the code, if it works, it
works, right?
So what do I use it now? As an example, here are the 10 last prompts
in my history:
there is now Claude 5, and a fable model, maybe you know about it?
impress me
not impressive, i already know all of this
chat
in postfix, i have a 300k mailing that happens regularly here. normally, it delivers within about...
is there a way i could have drained the maildrop queue faster without removing the milter?
the problem was that rspamd was timing out on the FUZZY_CALLBACK check. how do i disable that?
how do i disable all spam checks? i just want rspamd to add dkim signatures
how do the default_destination_concurrency_limit and initial_destination_concurrency settings int...
mic check
The first one was me trying to confirm which model I am using, which
is not always obvious when going through the whole llm stack I've
been using. The following two are an attempt at seeing what the model
is capable of and I was "not impressed", to which Claude answered that
I have a "high bar", which, fair enough.
The chat is me failing to use a command line, which shows that
perhaps I need to readjust that "high bar", again.
The next five are a rather embarrassing debacle in a large Postfix
mailing that went sideways, and where I couldn't find an actual
Postfix expert of my level to help. The fabled Claude Fable 5 answered
rather correctly, but dangerously, that I could empty the queue by
disabling the non_smtpd_milters. What Fable (and myself) did not
realize is that the milter was also adding DKIM signatures, so while the
mailing was expedited, it was done without those precious signatures,
which got us promptly blocked at Gmail. We have recovered since, and,
thanks to the model and reading the Postfix manual for the
hundredth time, that pickup(8) is single-threaded and that we
needed to review the architecture of that mailing (and our spam
filters) a bit. Many tickets ensued.
The last one is a test I did to make sure my last uploads of
llm-anthropic and its dependency worked correctly.
Note that the above excludes 5 questions I asked Anthropic while
writing this article, where I asked for synonyms and "what nanometer
scale are arduino processors built from? how is an arduino CPU
printed?", a question which Wikipedia furiously evades providing a
good answer.
Those prompts are pretty typical of my LLM use: I'm testing the models
to see if they work at all, but also, out of desperation, I fire off a
prompt after I fire off questions to colleagues or search engines (in
that order). It's often weird edge cases like the Prometheus query
language, Python's matplotlib, LaTeX, Elisp, optimizations, and so on.
I use models for translation a lot. Being fully bilingual, it is
common for me to think of a word in French or English and fail to find
exactly the right word for that in the other language. Models help
with that, and are also useful to find synonyms. Those are low-token
uses that seem pretty innocuous to me, but I realize the irony of this
after writing about the tower of
Babel.
What I am not using models for
I am not using models to write prose.
I am not using models to read prose. If it's generated with LLMs, I
stop reading.
I am not using models to write code, with the exception of that single
Python script above.
I am generally not using models to review code, with exceptions. If
I get stuck on a hard problem, I might feed a piece of code to the
model. I repeatedly fed asncounter into Claude to try to fix a
performance regression I had introduced. It found micro-optimizations
that taught me a thing or two about Python's internal implementations,
but overall, it was mostly a waste of time. This was in June 2025, so
perhaps now models would fare better. I have not tried again.
I am not using LLMs to do Debian packaging. When I can, I manually
review the diffs of packages I upload into Debian, still, by hand.
aggressive and illegal scraping of the servers I steward
world-wide computer hardware shortage (making it, by the way,
nearly impossible to run presumably clean local models) and the
attack on our job conditions (also discussed in
The people vs the AI overlords)
death of copyright and free software
complication and enshifitication of everything, and the
destruction of our communities
the imperialist Nerd Reich that wants to take over the world
Like I reluctantly use Intel computers, I do fire off a prompt. But
I still hold on to the dream that we can build communities of
practice that hold human knowledge collectively and not offload
that as a utility to some megalomaniac billionaire.
Their LLM use I am forced into
So that's me. Clearly, I'm going against the grain here. Everywhere I
look, I see LLM-generated code and projects. Slop and botnets have
flooded the web.
I use Wadamesh, clearly vibe-coded, because it's the best
graphical interface for MeshCore that runs on portable devices. I wish
it was made by a human, in a community I could participate in, but it
isn't, and I don't.
I package the above llm toolset, which is more and more
vibe-coded, but I still review the diffs. And I have to say: I
trust Simon here. The code is verbose as hell, feels overengineered,
and llm feels slow, but it generally works, and Simon is still at
the gate.
The Anthropic SDK is another thing entirely. The 0.91.0 to 0.120
upload, for example, was nuts:
I explicitly did not review that entire diff. It feels like there's a
lot of garbage there to just have a shim between a proprietary API and
Python. But this is the hand I've been dealt.
Larger projects LLM use
LLMs are being used in the Linux kernel, Firefox, rsync, Rust, and
other places. I don't feel good about this, particularly in Rust, but
they at least made a decent policy. I am glad GCC made a policy
against LLM contributions and I support the human Emacs
project.
We need to have a set of foundational tools that are "clean" in the
sense that they are built upon a community of people that understand
how they are built.
Maybe that's naive or even impossible. The Linux kernel and GCC, in
particular, are massive projects that have long grown past the scale
of a single person's understanding. But the theory was that a
community of humans can understand collectively.
Now we seem to be throwing up our hands and giving up on
that community. That LLMs will just fix the problem, whatever it
is. But we're all just one rug pull away from being completely
incapable of managing those projects. The argument there is that we'll
just switch to local models, but no one is actually doing that.
All I see is people use local models as a corner case
(for privacy) or as in theory, but in reality, everyone uses the
centralized frontier models right now. We just can't fallback.
We're in the same situation we were, a decade or two ago, when
Microsoft decided it would kill free office alternatives by making
Office free for non-profits. It worked: thousands, if not millions of
schools, community groups and individuals stopped looking for
alternatives (including free software but also "piracy") for Office
and embraced what seemed like a generous offer.
I'm afraid the rug pull on LLMs will be much worse: never mind that
Linus won't be able to use his tireless helper to fix obscure kernel
bugs; we're looking at a collapse of the economy so large that we are
already talking about bailing out the companies responsible.
In a sense, the most striking thing about the Debian vote is it has
actually no option to completely refuse upstream LLM contributions. It
seems the community has taken it for granted that it's now impossible
to build Debian entirely without LLMs. We lost the battle even without
a fight, it seems.
A plea for small
If it has really become impossible for us to manage the complexity we
have built, maybe it's time to stop and think about what we're doing
in the first place. We're struggling to even bootstrap our
current toolchain!
This is one of the things I like the most about working on the mesh:
it's low tech, small Arduino devices that is built with decades-old
semiconductor processes that is understandable by human
beings.
Maybe the answer lies more in single-purpose devices like those
communicators and simpler multi-purpose computers than what we have
now, which is what the permacomputing movement is about.
Small is beautiful, let's scale it down.
and yes, I'm sorry this has gotten this long, I hope you will
forgive those 3000 words.↩
I like this line: “Success is measured in operational advantage delivered, not technology demonstrated.” To me it recalls “Working software is the primary measure of progress” from Principles behind the Agile Manifesto – if you understand “working” to mean “working in production”. Which I do.
For anyone interested in suggesting ideas to the taskforce, the four
operational challenge areas include:
Machine assistance for handling and interpreting huge volumes of data
would probably benefit decision advantage and interpretation of a
crowded EM spectrum, but this is hopefully(?) more than just LLMs. Of
course, there’s more to AI than large language models… right?
I worry that “planning and automation” might amount to “generating
large amounts of
text
faster”. Nothing could possibly go wrong with this.
Another minor routine update 0.0.6 of gettz arrived on CRAN just now.
gettz provides a
possible fallback in situations where Sys.timezone() fails
to determine the system timezone. That happened when e.g. the
file /etc/localtime somehow is not a link into the
corresponding file with zoneinfo data in,
say, /usr/share/zoneinfo. Since the package was written (in
the fall of 2016), R added a similar extended heuristic approach itself
making the package a little less relevant.
This release reflects several rounds of updates to the continuous
integration setup, some URL updates, as well as some updates to
packaging including use of Authors@R in DESCRIPTION. As with the
previous releses: No functional changes, no new code, or new
features.
In 2025 I was honored to be selected for the first cohort of Sovereign Tech Fellows, a program by Germany’s Sovereign Tech Agency to improve the resilience of the open source ecosystem by supporting maintainers directly (complementing their existing support for larger FOSS organizations). Back in 2025, I was only working very limited hours – however, this has changed in 2026.
For the second half of 2026, I am working again as a Sovereign Tech Fellow, but this time with significantly increased hours. After finishing my PhD, I do have time now for new tasks (and new jobs!), and the fellowship presents an amazing opportunity to really advance projects that I maintain or am part of. This also has a very nice effect on contributors and bug reporters, as their feedback gets addressed a lot faster. With some luck, this ultimately will help finding new (co)maintainers for projects as well (although in the age of AI, a lot of how open source used to work is much more uncertain, but that is a matter for a different blog post).
The fellowship is time-limited, so I am intending to make the time I currently have count!
So, what’s planned?
I am involved in many projects, but three of them will be getting attention as part of the fellowship. I know I am notoriously slow at blogging, but expect more details on each of them very soon. Here’s an overview:
Freedesktop.org, Specifications and Organization
I maintain the Freedesktop Specifications, which is an area of Freedesktop that has traditionally been a bit chaotic. This “worked” in the past, because Freedesktop was never intended to be a formal standards body, but more a shared space where people could throw a lot of code and ideas over the wall and see what sticks and what people can collaborate on.
While I very much love the spirit of this and want to keep it in some form, we definitely would benefit not just from more formalization and better procedures, but also from better organization of the specifications in general. A lot of conflicts can be avoided by that. I will work on improving procedures, crunching through the (lots!) of pending bug reports and MRs, and to make the specifications site better searchable and accessible (similar to how Mozilla’s MDN presents information, but I am not sure if we will get quite that far). I also intent to add a compatibility matrix for specifications, so if a desktop opts out of any one of them (or does not implement them yet) that fact is documented and authors of applications know what they can expect. This will allow us to move a lot faster and avoid a lot of conflict, because there is no implicit assumption that “everybody will implement everything” anymore (which has never been quite true anyway).
Hopefully, this will ultimately result in a Freedesktop that is both a lot more useful for application authors who want to bring their project to Linux, as well as developers of desktop environments who need to see which specifications are available and which ones are current.
In addition to that, I have also worked on a Freedesktop.org website refresh, which is pretty much done in its first iteration (pending sysadmin action). The aim there is to have a more official website, separate from user-contributed wiki content, that showcases what Freedesktop is and which projects are using it for hosting. Once the new website is live, I will also review every page again, archive dead projects in their own section and reorganize the software and specifications directory. Those sections are severely outdated and are missing recent efforts from the community, while still containing long-dead old projects (remember HAL? ).
AppStream
A lot of extra maintenance work will be (has been!) done on it. This includes things such as JPEG-XL support (blog post soon), sandboxed media processing, support for newer specification additions, better OARS integration (and potentially migrating it to fd.o infrastructure), improvements and API stabilization for libappstream-compose and a lot of bugfixing and resolution of issues found by AI code review.
AppStream was originally designed to parse only trusted data from vetted Linux distribution sources – this is no longer the case in today’s world and in the way Flatpak uses it, so we need to increase resilience of the project.
I am also exploring a project that could vastly improve search accuracy for AppStream. Stay tuned for that.
PackageKit & System Upgrades
Many years ago, people thought we would all migrate to atomic Linux distributions and slowly not need PackageKit anymore. This has not turned out to be the case, and there are still plenty of reasons to use a package-based OS, especially in development environments. At the same time, PackageKit has been basically the same for years, and its older architecture is beginning to show. It being a daemon who’s literal job it is to modify the entire system also makes it one of the most security-sensitive components that a Linux system can have, while simultaneously making it near-impossible to sandbox.
My plan is to create PackageKit 2.0 by building on the great foundation of PackageKit 1.0, but modernizing it. This will include simplifying its code and removing a bunch of features that have no more use in modern desktops, while also adding some features that PackageKit never had but that would be useful to expose to frontends (still no to interactivity an terminal-progress forwarding though!). PK 2.0 will also allow me to solve a few design issues that have been worked around in the past, by replacing them with better solutions. This will be a painful transition, as PackageKit 2.0 will break all interfaces PackageKit has – and those interfaces have been frozen for more than a decade. However, I do fully expect this change to be worth the effort.
In addition to that, I intend to look into the offline-update procedure again and improve it. The current multi-reboot operation comes with downsides, that newer systemd features such as soft-reboot can alleviate. The end result should be a much smoother, less annoying offline-update experience for users (I especially want to get rid of updates running on system startup, which I consider quite bad from a usability perspective). The new behavior is in the early drafting stages and may need direct support from systemd. I will share more about it once I can.
That’s a lot of tasks!
Yes! I will see how far I get. I am moving project-by-project though, to allow me to focus on one project at a time, rather than scattering my attention continuously. Amazingly, this means that the major tasks for AppStream are already almost done, and we are nearing the 1.2.0 release. AppStream got priority, because the new Freedesktop Flatpak runtime will be released soon, and because I want FlatHub/Flatpak to have access to the new AppStream release sooner. Freedesktop and PackageKit are next on the task list.
Either way, a lot of progress is coming – if you have any feedback or want to help out, please don’t hesitate to reach out! All work is happening fully in the open, so you can also chime in on the respective GitHub/GitLab tasks .
You can also expect blog posts about key features or interesting changes, so stay tuned!
A new release of gaussfacts package
arrived on CRAN – the first in
pretty much exactly a decade! gaussfacts
provides a fortunes-inspired
function to display randomly-chosen facts about Carl Friedrich
Gauss, based on the collection curated by Mike Cavers via the gaussfacts web site (with an archive.org link
it case it vanishes again). Each call of gaussfact()
displays another (randomly chosen, or indexed) fact.
An example:
> gaussfacts::gaussfact(9)Gauss once played himself in a zero-sum game and won $50.>
This releases, as detailed below, accumulates a number of smaller
maintenance changes including switching to Authors@R. Functionality has
not changed. Oddly enough, it appears that I did not blog about the
package when I created it in August 2016. So to (partially) make up for
that, the NEWS for all three releases follow.
Changes in version 0.0.3
(2026-08-23)
Several rounds of continuous integration maintenance and
enhancements
Additional README.md badges
Updates to DESCRIPTION as CRAN requirements change
A duplicate data entry has been removed (Tim Pokart in #4)
Documentation prefers https URLs
Updated continunous integration multiple times
Correct man page removing an erroneous duplicate word
Changes in version 0.0.2
(2016-08-03)
Support 'ind' argument to reference by position
Clean-up encoding and support extended character set (#2 closes
#1)
This post contains interactive examples. To visualize and interact
with them, you need to leave your RSS reader.
Imagine you rent office space for a three-day event. You quickly set up a few
Ethernet switches and tape some cables on the floor to get everyone online.
Unfortunately, Stan, your clumsiest coworker, kicks out a cable every time he
gets up for coffee. You could add extra cables, but then you’d get a broadcast
storm: Ethernet packets that loop and multiply until nothing else gets through.
That’s where the spanning tree protocol (STP) comes in. STP blocks just enough
of your spare cables to leave a loop-free tree. When Stan strikes again, it
rebuilds the tree in a second, leaving some time for Blobby, your one-person
support crew, to reconnect the cable.1 See for yourself: the diagram
below runs a real STP implementation in your browser!
:demo
A1 @0,0 prio=4096
A2 @0,1
A3 @0,2
A4 @0,3
B1 @1,0 prio=8192
B2 @1,1
B3 @1,2
B4 @1,3
C1 @2,0 prio=8192
C2 @2,1
C3 @2,2
C4 @2,3
A1 -- A2 hazard=0
A2 -- A3 hazard=0
A3 -- A4 hazard=0
B1 -- B2
B2 -- B3
B3 -- B4
C1 -- C2 hazard=0
C2 -- C3 hazard=0
C3 -- C4 hazard=0
A1 -- B1 cost=10
B1 -- C1 cost=10
A4 -- B4 cost=20
B4 -- C4 cost=20
Leo @-0.3,0.7 proto=none icon=👦🏻
Mia @-0.3,1.3 proto=none icon=👧🏽
Joy @0.3,0.7 proto=none icon=👱🏻♀️
Roy @0.3,1.3 proto=none icon=👨🏾
A2 -- Leo hazard=0 A2:edge
A2 -- Mia hazard=0 A2:edge
A2 -- Joy hazard=0 A2:edge
A2 -- Roy hazard=0 A2:edge
Max @-0.3,1.7 proto=none icon=👨🏽
Zoe @-0.3,2.3 proto=none icon=👩🏾
Ada @0.3,1.7 proto=none icon=👵🏾
Amy @0.3,2.3 proto=none icon=👩🏼
A3 -- Max hazard=0 A3:edge
A3 -- Zoe hazard=0 A3:edge
A3 -- Ada hazard=0 A3:edge
A3 -- Amy hazard=0 A3:edge
Eli @0.7,0.7 proto=none icon=👦🏼
Jay @0.7,1.3 proto=none icon=👨🏻
Kai @1.3,0.7 proto=none icon=🧑🏽
Ben @1.3,1.3 proto=none icon=👱🏼
B2 -- Eli hazard=0.2 B2:edge
B2 -- Jay hazard=0.2 B2:edge
B2 -- Kai hazard=0.2 B2:edge
B2 -- Ben hazard=0.2 B2:edge
Ava @0.7,1.7 proto=none icon=👩🏻
Lea @0.7,2.3 proto=none icon=🧑🏾🦱
Ivy @1.3,1.7 proto=none icon=🧕🏽
Rex @1.3,2.3 proto=none icon=👴🏿
B3 -- Ava hazard=0.2 B3:edge
B3 -- Lea hazard=0.2 B3:edge
B3 -- Ivy hazard=0.2 B3:edge
B3 -- Rex hazard=0.2 B3:edge
Ana @1.7,0.7 proto=none icon=👩🏿
Eve @1.7,1.3 proto=none icon=👧🏼
Abe @2.3,0.7 proto=none icon=🧓🏿
Ian @2.3,1.3 proto=none icon=🧔🏾
C2 -- Ana hazard=0 C2:edge
C2 -- Eve hazard=0 C2:edge
C2 -- Abe hazard=0 C2:edge
C2 -- Ian hazard=0 C2:edge
Ned @1.7,1.7 proto=none icon=👨🏼🦳
Lou @1.7,2.3 proto=none icon=🧑🏿
Fay @2.3,1.7 proto=none icon=👧🏻
Sue @2.3,2.3 proto=none icon=👩🏽🦰
C3 -- Ned hazard=0 C3:edge
C3 -- Lou hazard=0 C3:edge
C3 -- Fay hazard=0 C3:edge
C3 -- Sue hazard=0 C3:edge
Note
This article is also available as a video, but I advise you to
keep reading here to try the interactive demonstrations.
Designed in the ’80s, the spanning tree protocol has evolved into a “rapid”
flavor (RSTP) and a “VLAN-aware” variation (MSTP).2 Any sound-minded
network engineer knows there are better alternatives, like BGP EVPN VXLAN.
Yet, because any switch speaks it, the venerable spanning tree protocol still
fills a niche.
We focus on RSTP: it replaced the original protocol in 2004. To eliminate
network loops, RSTP implements a complex state machine. Timers, link state
changes, and the link-local control frames a bridge receives from its neighbors
drive its transitions. These Ethernet frames are the Bridge Protocol Data
Units (BPDUs). You can watch them in action below: hit the “Start” button.
After some time, the topology converges to a tree: from the root
C11, there is a path to each bridge3 and no loop. In the upper right
corner, the interface displays a tree icon 🌳 followed by the time it took to
reach this state. Cut a link and see how the protocol
finds an alternate path to reach C12 in less than a second. You can stop the
simulation, move it forward step by step, reset it to its initial state, or slow
it down with the “snail” mode 🐌. Don’t worry about all the displayed
information: I explain it later.
All examples run in your browser, powered by MSTPD—an open-source
user-space4 implementation of RSTP.5
I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial property
Is loop-free connectivity.
A tree which must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.
To build a tree, RSTP first elects the bridge with the lowest bridge
identifier as the root bridge. The bridge identifier combines the priority
and the MAC address: 8192.6e:2b:10:a0:5f:29.
In the example below, S1 and S2 have priorities of 4,096 and 8,192: S1 becomes
root. S4 has a priority of 12,288, while S3 keeps the default priority of
32,768:6 S4 becomes root. S5 and S6 don’t have a specific priority, so
the lowest MAC address wins and S5 becomes root.
Each non-root bridge chooses its root port, the one with the lowest-cost
path to the root. Unless you override it, each bridge derives the link cost
from the speed: 20,000 for 1 Gbps. In case of equality, the lowest port
identifier wins.
Each remaining port becomes a designated port if the BPDU it sends is
“better” than the BPDU it receives. Otherwise, it becomes an alternate port.
Later, if the root port goes down, the “best” alternate port becomes the new
root port. The tiebreakers for the best BPDU are:
In the example above, after convergence, S1 is the root bridge
because it has a priority of 4,096, while the other bridges have a priority of
32,768. All its ports are designated ports because the accumulated cost to the
root is 0.
S2’s port facing S1 becomes a root port because it has the lowest accumulated
cost to the root—20,000 vs 40,000. S3 has two ports facing S1, and the one with
the lowest port identifier becomes the root port—0x8000 vs 0x8001. The other
candidate is an alternate port because the remote port on the link sends a
better BPDU, with an accumulated cost of 0. On the segment between S2 and S3,
S2’s port wins: while both bridges have the same accumulated cost to the root
(20,000), S2’s bridge identifier is smaller—32768.02:00:00:00:00:01 vs
32768.02:00:00:00:00:02.
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 20000
Bridge Identifier: 32768.02:00:00:00:00:01
Port identifier: 0x8002
Unless a specific event happens, designated ports send BPDUs every 2
seconds.9 If a bridge does not
receive BPDUs from its neighbor for 3 consecutive hello periods, it considers
the neighbor dead and removes the port information.
Port state transition
Each port can have one of three states. The diagram displays a background color
for each state:
discarding (red),
learning (yellow), or
forwarding (green).
A root port transitions automatically to the forwarding state. An alternate
port stays in the discarding state. A designated port has two options to
transition from the discarding state to the forwarding state:
If the port is an edge port, either through configuration or because the
remote device does not speak any flavor of STP, the bridge assumes it won’t
participate in the protocol and cannot create a loop. In this case, the
designated port immediately transitions to the forwarding state.
Otherwise, it sends a proposal to its downstream neighbor. If the remote
bridge agrees that the received BPDU is “better” than any other BPDU stored
for other ports, it elects the receiving port as its root port and starts the
synchronization process: it transitions all non-edge non-synced designated
ports to the discarding state to avoid a loop. Then, it sends back an
agreement. Upon receiving the agreement, the peer designated port
transitions to the forwarding state.10
In the topology above, H1, H2, H3, and H4 are end devices not participating in
the protocol. We configure the ports they connect to as edge ports, so these
ports immediately move to the forwarding state.
Use the “step” button to move the simulation forward. The clock moves to 1
second. Step again and S1 and S2 send a proposal to
each other. Here is the proposal from S2:
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x4e, Agreement, Port Role: Designated, Proposal
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..0. .... = Forwarding: No
...0 .... = Learning: No
.... 11.. = Port Role: Designated (3).... ..1. = Proposal: Yes
.... ...0 = Topology Change: No
Root Identifier: 32768.02:00:00:00:00:01
Root Path Cost: 0
Bridge Identifier: 32768.02:00:00:00:00:01
Port identifier: 0x8001
S1 ignores it: its own root identifier is lower. When S2 receives a similar
proposal from S1, it accepts S1 as its root bridge. It also elects the port to
S1 as the root port and starts the synchronization process. The two designated
ports are already discarding, so no change here. Step
again and S2 sends two BPDUs to S1. In one of them, the
agreement bit is 1 and the proposal bit is 0. It also shows that S2 accepted S1
as the root bridge and its root port is now in the forwarding state. When
receiving this BPDU, S1 transitions its own designated port to the forwarding
state. From this point, the link between S1 and S2 forwards user traffic.
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x79, Agreement, Forwarding, Learning, Port Role: Root, Topology Change
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..1. .... = Forwarding: Yes
...1 .... = Learning: Yes
.... 10.. = Port Role: Root (2).... ..0. = Proposal: No
.... ...1 = Topology Change: Yes
Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 20000
Bridge Identifier: 32768.02:00:00:00:00:01
Port identifier: 0x8001
Let’s look at what happened to S5. Reset the simulation and step
twice. S5 exchanges BPDUs with both S3
and S6. Since S5 has a lower root identifier than S3 and S6, it stays the root
bridge, while S3 and S6 accept the proposal and elect their root ports. S3 and
S6 start the synchronization process. S6’s port to H4 stays up because this is
an edge port. Move one step. Both S3 and S6 send
an agreement back to S5, which transitions both designated ports to the
forwarding state. Yet, the link between S5 and S3 keeps discarding user traffic!
If you look carefully, S3’s port toward S5 is now a designated port, not a root
port. During the same step, S3 also receives a better BPDU
from S2 with S1 as the root bridge. It elects its port to S2 as the root port
and downgrades the port to S5 to a designated port, which stays in the
discarding state.
On the next step, things get a bit tricky. S3 sends a
proposal to S5:11
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x4f, Agreement, Port Role: Designated, Proposal, Topology Change
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..0. .... = Forwarding: No
...0 .... = Learning: No
.... 11.. = Port Role: Designated (3).... ..1. = Proposal: Yes
.... ...1 = Topology Change: Yes
Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 40000
Bridge Identifier: 32768.02:00:00:00:00:02
Port identifier: 0x8002
S5 elects S1 as its root bridge and the port toward S3 as its root port. It
starts its synchronization process, but the designated port to S6 does not
move into the discarding state. Why? That port stays a designated port and its
neighbor S6 had already sent an agreement on the link, so the port keeps its
synced status.
Now, let’s step back to look at what happens to S6. At this point,
S6 believes S5 is the root bridge. Step once and S4 sends
a new proposal to S6. S6 accepts the proposal, elects S1 as the root bridge and
the port to S4 as its root port. The role of the port facing S5 changes: from a
root port, it becomes a designated port. Because its peer keeps advertising an
inferior BPDU on the link, this port becomes disputed and moves to the
discarding state. The root port transitions to the forwarding state and the link
starts forwarding immediately because S4’s designated port is already in the
forwarding state. If we step one more time, S5 and S6
exchange two BPDUs. The one from S5 is better because of its lower bridge
identifier. S5’s port stays a designated port, while S6 downgrades its own port
to an alternate port.
Let’s rewind one last time from the start: cut the link between S1 and S2, run
the simulation until the topology is stable, stop the
simulation, and restore the link between S1 and S2. During the first
step, S1 and S2 exchange proposals. S2
elects S1 as the root bridge instead of S5 and the port to S1 as the root port.
It downgrades the previous root port to a designated port and moves it into the
discarding state. The other designated port stays synced and keeps its
forwarding state. At the next step, S2 sends
an agreement to S1 and the link between them starts forwarding user traffic. It
also sends a proposal to S3, but not to S4.
Instead, it sends a regular BPDU to S4. S4
still elects S1 as its root bridge and the port to S2 as its root port. It
demotes its previous root port, the one to S3, to a designated port, which
transitions to the discarding state because of the root port change. The other
alternate port, to S6, also becomes a designated port and stays in the
discarding state. The new root port moves to the forwarding state. On the next
step, S4’s port to S3 settles as an
alternate port after receiving a “better” BPDU from S3.
RSTP is a giant state machine split into smaller ones: bridge detection, port
information, port protocol migration, port role selection, port role
transitions, port receive, port state transitions, port timers, port transmit,
and topology change. Some of them are per bridge, some per port. Each bridge
runs an instance. Time, operational port state changes, and the BPDUs it
receives from other instances drive the transitions. Being event-driven makes
RSTP more efficient but also more difficult to understand.
Placeholder for the Port Information state machine extracted from IEEE 802.1Q-2005, page 182. Pending IEEE authorization for reproduction, this is the blueprint for the Western Australian Government Railways class Msa Garratt articulated steam locomotive.
Topology change notification
A bridge populates a MAC address table: it associates each source MAC address
with the port that last received it. When forwarding an Ethernet frame, it looks
up this table to choose the right port.12 When a link fails, a connected
fridge reachable through one port may become reachable through another one. The
affected bridges should flush the MAC addresses they learned, because these
entries may now be wrong.
For this purpose, RSTP implements topology change notifications using a
flooding mechanism. When a non-edge port transitions to the forwarding state, a
bridge generates BPDUs with the topology change (TC) bit set. It sends them to
all the non-edge designated ports and to the root port. It also flushes the MAC
address table on these ports. When a bridge receives such a BPDU, it propagates
the notification to all non-edge designated ports and the root port, except the
one the notification came from. It also flushes the MAC address table on these
ports. In the examples, the BPDUs with the TC bit set to 1 have a red circle.
Start the simulation and wait a few seconds for the topology to
settle. Stop the simulation and disable the link between S2 and
S5. S5 elects the port facing S4 as the root port, which
transitions immediately to the forwarding state. Step
once and S5 emits a BPDU with the TC bit set to 1:
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x79, Agreement, Forwarding, Learning, Port Role: Root, Topology Change
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..1. .... = Forwarding: Yes
...1 .... = Learning: Yes
.... 10.. = Port Role: Root (2).... ..0. = Proposal: No
.... ...1 = Topology Change: Yes
Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 40000
Bridge Identifier: 32768.02:00:00:00:00:04
Port identifier: 0x8002
S4 receives this BPDU. It flushes the MAC address table on the port facing S1:
while LPT was previously reachable through this port, it is now reachable
through S5 instead. Step once. S4 sends S1 a BPDU
with the TC bit set to 1. When S1 receives this BPDU, it flushes the MAC address
table on the ports facing S2 and S3. Step
once and S1 sends a notification to S2 and
S3. Step once again and S2 sends a notification to
S3, while S3 does nothing because the port toward S2 is an alternate port. S3
does not flush any MAC address table: LPT is still reachable through its port to
S1.
If you step a bit more, you will see that some of the
periodic BPDUs keep the TC bit set to 1. Each port runs a timer equal to the
hello timer plus one second.13 The timer starts when the port emits a
notification. Until it expires, the port sets the TC bit to 1 in every BPDU it
sends. You can also see some periodic BPDUs
without the TC bit: they originate from a port that only received a notification
and therefore did not arm its timer.
Security
RSTP is weak against configuration errors and malicious actors. A bridge not
talking RSTP can create a loop. An attacker can insert themselves into the
topology to disrupt the service, spy on the traffic, or alter it.
To mitigate such problems, you need to identify the edge ports. An edge port
connects to an end device, like a PC or a printer. Such devices do not generate
BPDUs and cannot create a loop. RSTP defines two related flags:
When true, AdminEdge initializes a port as an edge port. It defaults to
false.
When true, AutoEdge lets a port become an edge port when it does not
receive BPDUs for 3 seconds. It defaults to true.
If an edge port receives a BPDU, regardless of the values of these two flags, it
reverts to a non-edge port.
In the topology above, S1, S2, S3, S4, S5, and S6 act as bridges, while H1, H2,
H3, H4, H5, and H6 act as end devices:
S1 and H1 are on a port without a specific configuration: AutoEdge is true,
AdminEdge is false,
S2 and H2 are on a port where AdminEdge is true,
S3 and H3 are on a port where AutoEdge is false and AdminEdge is true,
S4 and H4 are on a port where AutoEdge is false.
If you start the topology and wait about 20 seconds, links to S1,
S2, S3, S4, H1, H2, H3, and H4 eventually forward user traffic: none of the
flags matter.
But what about the two remaining pairs? S5 and H5 connect to a network port.
Such a port enables a non-standard feature: bridge assurance. The port
transmits BPDUs regardless of its role. If it does not receive BPDUs for 3
consecutive hello periods, it transitions to the discarding state. On the link
between R0 and S5, you can see BPDUs traveling in both
directions, unlike the other links, where only
designated ports send BPDUs.
S6 and H6 connect to a port where AdminEdge is true and BPDU guard is
enabled. This is another non-standard feature that shuts down a port if it
receives a BPDU.
In summary, if you expect a port to be an edge port, you should set AdminEdge
to true and enable BPDU guard. Otherwise, declare it as a network port.
Why RSTP today?
A compelling use case for RSTP today is an out-of-band network for a datacenter,
since you can tolerate an outage of a few seconds. The configuration is minimal
and you can use cheap switches, like a Cisco 2960X.14 You need two
switches acting as root bridges, and you build several loops to connect OOB
switches in each cabinet. This simple design survives one failure on each
loop.15
This topology converges in about 6 seconds. Each loop should stay
small (around 16 bridges) to reduce the probability of a double failure and to
avoid sharing too much bandwidth. The design can evolve a bit without adding too
much complexity: one VLAN per loop or one bridge domain per loop.
How large can a network be?
The maximum age, whose default value is 20, governs the maximum distance of a
node from the root. The topology below is too big for BPDUs from R1 to reach
beyond S20.16
Once the topology settles, part of the network considers R1 the
root, while the other votes for R2. At the boundary, S20 tries to start a
synchronization with S21 to move its designated port to the forwarding state.
The BPDU looks like this:
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x4e, Agreement, Port Role: Designated, Proposal
Root Identifier: 4096.02:00:00:00:00:00
Root Path Cost: 400000
Bridge Identifier: 32768.02:00:00:00:00:15
Port identifier: 0x8002
Message Age: 20
Max Age: 20
S21 rejects it because the message age equals the maximum age. On the other
hand, the BPDU S21 sends to S20 looks like this:
Spanning Tree Protocol Protocol Identifier: Spanning Tree Protocol (0x0000) Protocol Version Identifier: Rapid Spanning Tree (2) BPDU Type: Rapid/Multiple Spanning Tree (0x02) BPDU flags: 0x7c, Agreement, Forwarding, Learning, Port Role: Designated
Root Identifier: 4096.02:00:00:00:00:01
Root Path Cost: 320000
Bridge Identifier: 32768.02:00:00:00:00:16
Port identifier: 0x8001
Message Age: 16
Max Age: 20
This is not enough to change S20’s root port because S20 has a lower root
identifier—4096.02:00:00:00:00:00 vs 4096.02:00:00:00:00:01.
Fixing the link between R1 and R2 resolves the issue. The
maximum message age any packet carries is now 18, below the configured maximum
age. But it only works until another link breaks. A plausible fix is to increase
the maximum age to 40.17
How fast is RSTP?
RSTP usually converges in a couple of seconds at startup. It often repairs a
tree in less than a second. Even the 38-bridge topology takes less than 10
seconds to converge.18 Some topologies can take a bit more time to recover
when the root bridge becomes unavailable.19
First, S1 loses its root port. It has no more information about R0 and elects
itself as the root bridge. It keeps its ports to S2 and S3 as designated ports
in the forwarding state. Step once and it
sends a BPDU to both S2 and S3 to let them know about the root change. When
receiving it, S2 accepts S1 as its root because it does not have a better root
on another port. It elects the port to S1 as its root port. The other port stays
a designated port. Both ports keep forwarding.
When receiving the BPDU from S1, S3 behaves differently: it knows R0 as a better
root than S1 through its alternate port to S2. It promotes this port to a root
port and demotes the port facing S1 to a designated port, which requires a new
agreement. Step once and S3 sends a proposal to
S1 with R0 as the root bridge. S1 elects R0 as the root bridge and promotes its
port to S3 as a root port.
During the same step, S3 also receives a BPDU from
S2 stating that S1 is the root bridge. Therefore, S3 has no port left with R0 as
the root bridge: it elects S1 as the root bridge and its port to S2 as the root
port. Step once and its next BPDU to S1 includes
this information: S1 elects itself again as the root bridge. But during the
same wave, S1 sends a proposal to S2 with R0 as
the root bridge. While S1 and S3 agree that S1 is the root bridge, S2 now
believes this is R0! In turn, S2 again convinces S3
that R0 is the root bridge, S3 convinces S1, S1 convinces S2, and S2 convinces
S3.
This could go on forever, but it does not. The BPDUs saying “R0 is root”
eventually age out when the message age goes past the maximum age. In the
example above, at the eleventh second, S2 sends a
BPDU to S3 with R0 as root, but S3 drops it because its message age reached the
maximum. With some luck, the topology can also converge faster if a port stops
transmitting new BPDUs after tripping the transmit hold count, whose default
value is 6 per second.
About MSTP
MSTP is the “VLAN-aware” version of RSTP: it runs several instances of RSTP and
lets the administrator map each VLAN to a specific instance. For example, you
can map VLANs 100 to 200 to a first instance, and 300 to 400 to a second
instance. The remaining VLANs map to a special instance named the Internal
Spanning Tree (IST). MSTP adds its own complexity, but the gist is that you have
several logical topologies acting independently. If you want to dig deeper, have
a look at “MSTP Tutorial Part I: Inside a Region.”
About the interactive examples
The interactive examples run MSTPD directly in your browser, compiled to
WebAssembly with emscripten. A C API replaces the code talking to the
Linux kernel: it manages bridges and ports, exports state as JSON, and drives
time deterministically. A JavaScript wrapper makes it more user-friendly:
import{loadMSTPD}from"./dist/mstpd.mjs";constmstp=awaitloadMSTPD();// Create 3 bridgesconsta=mstp.createBridge("A",{priority:4096});constb=mstp.createBridge("B",{priority:8192});constc=mstp.createBridge("C");// Each bridge has two portsconsta1=a.addPort("a-b",{portno:1});consta2=a.addPort("a-c",{portno:2});constb1=b.addPort("b-a",{portno:1});constb2=b.addPort("b-c",{portno:2});constc1=c.addPort("c-a",{portno:1});constc2=c.addPort("c-b",{portno:2});// Build a triangle topologymstp.link(a1,b1);mstp.link(a2,c1);mstp.link(b2,c2);// Enable all bridges and portsfor(constbrof[a,b,c])br.enable();for(constpof[a1,a2,b1,b2,c1,c2])p.enable();// Execute 40 seconds' worth of wall clock and display the topologymstp.step(40);console.log("Topology:",mstp.topology());
Several dozen unit tests explore the features of MSTPD and check that they work
correctly in this environment:
$ node--test*.test.mjs
✔ two bridges: lower priority becomes root (41.657342ms)✔ triangle loop: exactly one port blocks and all agree on the root (5.832ms)✔ breaking the active link reconverges and restoring recovers (18.730753ms)[…]ℹ tests 40ℹ pass 40ℹ fail 0[…]ℹ duration_ms 396.190897
Additional JavaScript code looks for specific <pre> blocks containing a
topology definition and turns them into the interactive widget. You can inspect
and modify the definition by hitting the “edit” button.
There is also a cool trick to tell whether the topology has converged. After
each step, we save a snapshot of the simulation memory, play 50 seconds’ worth
of simulation to check if the topology is stable, and travel back in time by
restoring that snapshot. 🕰️
The complete code lives on GitHub. I am happy with the result. It can be
difficult to follow everything happening during a single step, but stepping
forward and backward helps. I plan to use the same approach in future blog posts
about networking features.
Note
Michael Lynch reviewed a first draft of this article. He authored
“Refactoring English,” a book to sharpen your writing for blog posts,
documentation, commit messages, and tutorials. Any errors are still mine!
The sprites for Stan and Blobby come from Craftpix, the coffee
cups from Yanin. ↩
The priority is a multiple of 4,096: with MSTP, the lower 12 bits
of the bridge priority encode the MST instance identifier, leaving only the
upper 4 bits for the configured priority. ↩
To inspect the BPDUs crossing a link, select it, click the
“Download packets” button, and open the file with Wireshark. ↩
A backup port only exists if the bridge has several ports on the same
collision domain. This should not happen in a switched network. ↩
This is the value of the “hello” timer. It used to be configurable,
but IEEE 802.1Q-2005 pins it to 2. MSTPD does not allow another value. ↩
If the peer port does not receive an agreement after the hello
timer elapses—or the maximum age if the port has just come up—it falls back
to the timer-based method for compatibility with STP: it transitions to
the learning state, waits again for the hello timer to expire, and
transitions to the forwarding state. ↩
As in many proposals, S3 also sets the agreement bit to 1. The
proposal bit says “I am the designated port on this link and I want to
transition to the forwarding state.” The agreement bit says “I am already in
sync with the rest of my bridge on this root information.” Both can be true. ↩
If it finds no entry, the bridge duplicates the Ethernet frame on all
ports, except the incoming one. The same happens if the destination MAC
address is the broadcast one (ff:ff:ff:ff:ff:ff). This behavior bootstraps
the learning process. ↩
If you look closely at what happens at t=2s, you can see that R2 is
gaining popularity as root: S17 to S36 believe R2 is the root bridge. S16
does not follow because we hit the maximum age. Later, S17 to S20 reverse
their position. I’ll let you explore the state of the various bridges to
understand the root cause. ↩
When increasing the maximum age to 40, you also need to
increase the forward delay to 21 (:forward-delay 21), as the standard
enforces this condition: 2 × (Forward Delay − 1) ≥ Max Age. For this
specific topology, you could also increase the maximum age to 37 and
forward-delay to 20. ↩
The simulation may seem slow, but it does not run in real time. Look at
the current timestamp in the upper right corner to know the wall clock, e.g.
“t=8s.” Once the topology stabilizes, the same corner shows the convergence
time, e.g. “🌳 2s.” ↩
Imagine you rent office space for a three-day event. You quickly set up a few
Ethernet switches and tape some cables on the floor to get everyone online.
Unfortunately, Stan, your clumsiest coworker, kicks out a cable every time he
gets up for coffee. Spare cables would fix that, but a loop turns into a
broadcast storm: Ethernet packets multiply until nothing else gets through.
That’s where the spanning tree protocol comes in: it blocks just enough of the
spare cables to leave a loop-free tree, and rebuilds it in a second each time
Stan strikes again.1
This content is also available as a text version, with interactive demos
that run a real implementation directly in your browser!
This video is an experiment.2 Honestly, except for Radia Perlman reading
her poem,3 you should read the original article instead. It presents the same content, but you can play with the
interactive examples, which are the main contribution. On the other hand, if you
happen to like the video, be sure to tell me in the comments!
Recently I was trying to reproduce a bug with
citeproc.el and
org-mode in emacs.
I thought I could use package-vc-install to install a set of
upstream emacs packages at fixed versions, and thereby let citeproc
upstream test in the same environment as I have.
It turns out that getting emacs to load the non-builtin version
of org via package-vc-install did not work because
org-mode needs to run make after cloning
once package.el was initialized, I always seemed to end up with the
built in org-mode (yeah, I realize that isn't an explanation).
Recipe part 1: get org
Here you can replace 9.8.7 with any other tagged release
I haven't made a new book haul post in I don't know how long, so a lot of
books have piled up and many have already been reviewed. Here's the
overdue catch-up in case anyone is curious what books I am finding
interesting before the reviews get posted.
Ilona Andrews — Magic Bites (sff)
Elizabeth Bear — In the House of Aryaman, a Lonely Signal Burns
(sff)
Oliver Burkeman — Four Thousand Weeks (non-fiction)
Miles Cameron — Whalesong (sff)
Lee Child — Killing Floor (thriller)
august clarke — The Felicity Complex (sff)
Alison Cochrun — Here We Go Again (romance)
Dan Davies — The Unaccountability Machine (non-fiction)
Linzi Day — Midlife in Gretna Green (sff)
Linzi Day — Painting the Blues in Gretna Green (sff)
Linzi Day — Ties that Bond in Gretna Green (sff)
Linzi Day — Spilling the Tea in Gretna Green (sff)
Michelle Diener — Dark Ambitions (sff)
Michelle Diener — Dark Class (sff)
Michelle Diener — Collision Course (sff)
Michelle Diener — Crash Course (sff)
Henry Farrell — Underground Empire (non-fiction)
Kathleen A. Flynn — The Jane Austen Project (sff)
Victoria Goddard — The Hands of the Emperor (sff)
James Herriot — All Creatures Great and Small (mainstream)
James Herriot — All Things Bright and Beautiful (mainstream)
James Herriot — All Things Wise and Wonderful (mainstream)
James Herriot — The Lord God Made Them All (mainstream)
James Herriot — Every Living Thing (mainstream)
Lauren Hough — Monster of a Land (non-fiction collection)
Bethany Jacobs — This Brutal Moon (sff)
Guy Gavriel Kay — Written on the Dark (sff)
Mary Robinette Kowal — The Martian Contingency (sff)
Ann Leckie — Radiant Star (sff)
C.B. Lee — Coffeeshop in an Alternate Universe (sff)
Fonda Lee — The Last Contract of Isako (sff)
Julie Leong — The Teller of Small Fortunes (sff)
Julie Leong — The Keeper of Magical Things (sff)
R.Z. Nicolet — The Cloak and Its Wizard (sff)
Claire North — Slow Gods (sff)
Rebecca Ore — Writing's Writing (non-fiction collection)
Suzanne Palmer — Ode to the Half-Broken (sff)
Gareth L. Powell — Fleet of Knives (sff)
Cameron Reed — What We Are Seeking (sff)
Beth Revis — Full Speed to a Crash landing (sff)
Beth Revis — How to Steal a Galaxy (sff)
Beth Revis — Last Chance to Save the World (sff)
Natalie Zina Walschots — Villain (sff)
Jo Walton — Everybody's Perfect (sff)
Martha Wells — Platform Decay (sff)
James White — The Galactic Gourmet (sff)
James White — Final Diagnosis (sff)
The James Herriot books were ones my parents were getting rid of. I have
them marked as mainstream fiction as a short-hand since "fictionalized
autobiography" seemed like too much of a mouthful.
The Debian Project was officially founded by Ian Murdock on August
16, 1993. The Debian community celebrates its birthday, Debian Day,
on or around this date every year. This year, I had the chance to attend
two of them: one in João Pessoa, Paraíba, and another in Brasília, the
capital of Brazil.
João Pessoa
In João Pessoa, we had a two-day event. The first day was dedicated
entirely to workshops, and I ran a packaging workshop for newcomers.
It was the first time I had been responsible for a workshop, and it
was a great experience. We didn't have a lot of time, so I decided to
start with a 30-minute talk explaining a few things about Debian. For
example, I made this image to explain the packaging workflow:
This image was based on The
Debian Administrator's Handbook, and I think the participants really
enjoyed learning about this workflow. When I showed the slide with this
image, it was the moment when I received the most questions.
After the talk, I explained my way of working and what they were
going to do. The hardest part was setting up the environment, since my
approach uses sbuild + gbp. They were running different Debian releases
and, because of my inexperience with workshops, I had some of them
configure sbuild with unshare, even though it is only available in
stable through backports.
Some of them even managed to learn how to use backports, while others
decided to start again using the "old" way.
One thing that helped a lot was the Debian Brasil
Wiki. It has all the instructions for configuring sbuild in
Portuguese, along with great examples. The Brazilian wiki is an
opinionated version of the Debian Wiki. We generally prefer to use it
for the convenience of having the exact workflow we follow, as well as
an up-to-date Portuguese version of our process.
If you want to learn more about the Brazilian community, you can find
more details in the schedules from previous DebConfs. We almost always
had a talk about the community and its activities.
In the end, everyone successfully set up their development
environment, and all six participants made their first contribution to
Debian. If you take a look at my upload
tracking page, you will see that every upload made on August 15,
2026 was a sponsored upload from this event. One of them appear twice in
the list because I sponsored the upload and also made some other
changes.
I also asked all of them to put this in their changelog:
* My first contribution!
The idea was to make it clear to other people that they were only
working on small Lintian issues as a way of learning and understanding
the process. By the way, I made a UDD
query to find packages with the following Lintian tag:
redundant-rules-requires-root-no-field. To fix this issue,
they only had to remove one line from the debian/control
file.
It is obvious that these uploads are not particularly useful. I call
them "motivational uploads" because my goal is to help newcomers
understand the process and immediately give them the reward of having
made a contribution to Debian.
I'll try to keep in touch with them. My plan is to hold another
session, this time remotetly, to help them continue contributing to
Debian. In fact, I already have another package prepared by one of them
waiting for my review.
The second day was a full-day event featuring a bunch of talks from
the local community. I gave a talk explaining the new members
process.
I was the only Debian Developer at the event, and I think having a DD
there made a real difference. Being there to answer questions, and
simply being present, makes Debian feel more tangible and accessible to
people.
A big shout-out to Rafael Rocha, who put in a lot of work to make
this event happen, with the help of many volunteers who contributed
along the way.
Brasília
One thing I really like about Debian Days is that each place has its
own way of doing things. In João Pessoa, we had a MiniDebConf-like
event, while in Brasília, we had something smaller but still very
valuable. We decided to keep things simple: talk to a few students at
the University of Brasília (UnB) and then go somewhere to eat and have a
few drinks.
A bit of history
For those who don't know, the DebConf 19 was held in
Curitiba, Brazil. After the event, Arthur Diniz got really excited about
Debian and decided to go back to his University, UnB, to share his
experience and encourage more people to contribute to Debian.
I attended one of his talks, thanks to Joenio Costa, who invited
Arthur to give the talk. Joenio was also my professor at the time and a
Debian contributor. I really liked what Arthur had to say about free
software, and he did a great job of presenting the Debian community as a
friendly and welcoming place.
So I decided to attend local meetings of the Debian Brasília
community, which had been inactive for a long time. Lucas Kanashiro was
the Debian Developer who answered our questions and, as I mentioned
earlier, simply being there made Debian feel more tangible.
Everything stopped when the pandemic began. Then, towards the end of
2020, I saw a message in the Debian Brasília channel saying that the
meetings were back, this time remotely. I was hesitant to join because,
back in 2019, I hadn't managed to make a packaging contribution, even
with their help. I had eventually given up on the process. So this time,
I decided to join the meeting with something already prepared for
review. I watched all of Eriberto's packaging videos, picked a random
package, and joined the meeting.
I remember Kanashiro being excited that someone had just shown up
with something ready for review. At the time, it was only the second
meeting since Debian Brasília had come back online, and none of the
newcomers had started working on contributions yet.
During the same meeting, he also convinced us, the newcomers, to give
a talk about Debian just three days later.
The MiniDebConf Online Brazil
2020 was happening on Sunday, and the meeting was on the Thursday
before it. Since he has great convincing skills, I went along with the
idea and prepared
the talk with Francisco Ferreira.
That was the rebirth of the Debian Brasília community.
Since then, we have maintained a close connection with the University
of Brasília, and today, at least seven Debian Developers are from UnB,
whether as former students or former professors.
The reason I told this story is that, even though the Debian Day we
held in Brasília was smaller, it is part of something that has been
working for us for several years: staying close to an University. We've
managed to attract and retain many people who share the same values and
interests.
I've hope you all had a great Debian Day. If you're reading this and
aren't part of the Debian community but would like to join, get in
touch!
In an option review I did in 2024, shortly after the xz-utils backdoor, I explained that having GSS-API authentication and key exchange support in the main OpenSSH packages is problematic. The key exchange patch is large and intrusive. Furthermore, even linking to the necessary libraries is not without risk: as the Ebury malware attack demonstrated way back in 2009, each extra library linked into security-critical daemons such as sshd (or nowadays into its privilege-separated helper programs) can modify the behaviour of the daemon even if you aren’t doing anything that would involve calling into that library. Of course some of that risk remains, but as Damien Miller wrote, minimizing the number of libraries that end up in the address space of sshd and friends is still valuable.
I just uploaded openssh 1:10.4p1-5 to unstable, completing this split. As of this version, the OpenSSH client and server are built without GSS-API authentication and key exchange support. If you need those features, install openssh-client-gssapi or openssh-server-gssapi instead, as appropriate. Debian 13 (trixie) already has packages with those names that just depend on the regular openssh-client and openssh-server so that you can pre-emptively install them, as documented in the release notes.
The new openssh-*-gssapi packages have relatively tight dependencies on openssh-common, in order for the testing migration system to ensure that we can’t forget to keep them up to date. This will mean a bit more ongoing work for me on each new upstream version, but I think it will be manageable.
The current discussion in Debian aroun the AI GR is very heated, and I won’t add
to that, however, I am very confused about some of the viewpoints there. But, I
had no idea how to even try to write this, so did shut up, until I saw Aigars’
excellent Optimistic take on
AI, which
motivated me to try, at least. For the record, I fully subscribe to the post,
and to the voting suggestions (and I just voted).
Also, for full disclosure, I don’t think I did any contribution to Debian until
now using AI, neither packaging, nor emails, nor bug reports. And this blog post
specifically is 100% hand written.
With that out of the way… there are two points I want to make in this post.
AI is useful, even if it has risks
First is, that even if we could put the genie back in the metaphorical bottle,
we should not. We do need to continue working towards safe AI, and efficient AI
(less environmental impact), but we should not work towards removing the usage
of AI. There are already significant advancements in sciences and technology
thanks to the use of AI, so desiring AI to not exist (assuming we had a magical
wand) is the wrong approach.
Sure, AI has significant risks — and I can see ways in which AI can do
significant damage to society — but I don’t think we can go from Kardashev I to
II without the use of AI, and definitely not to III. And I think, that should be
the goal.
A few simple examples: Do we want to rollback all the 20 years old security
issues that AI found? Do we want to rollback the recent Moderna cancer findings?
Do we want to rollback the concept of “extremely large scalle pattern
matchings”, just because it runs on chips and no longer in one person’s head?
Reading Debian lists
The second point is, lately I found less and less enjoyment in reading Debian
lists. Even with that already being the case, I feel soo disconnected from many
of the opinions being voiced in this discussion.
On one hand, it’s normal and healthy that people have different opinions,
disagree, and move foward.
On the other hand, looking at one of the proposed options:
“Moderators and disciplinary teams may make narrow and tailored exceptions to
rule 4, and decide on interpretation”.
“Violations of these requirements should be treated as violations of the
relevant Code of Conduct and should result in swift and proportionate
disciplinary action”.
I already knew Debian, and some large parts of the OSS world, is left leaning.
But those phrasings, to me, are too close to socialism/communmism. As someone
who grew up under communism, this is a much more slippery slope (disciplinary
teams? really?) than AI usage. Ask me in person for more details.
So, it is possible that Debian continues to evolve in such a way that I don’t
find myself in any way close to its ongoing culture. I will be sad at that
point, but it will be what it is.
Where to?
I think that, until such a time that an AI bubble bursts, what any organisation
should do is try to logically see where and if AI can help. And in an
organisation that is about computer software, I see hundreds of places that are
subject to very large scale pattern matching… so the half of the discussion is,
to me, mind-boggling.
To be clear, it’s not about “if you can’t beat them, join them”. As I wrote
above, I think AI is useful, so the point is how to use it effectively.
Well, will see what Debian votes. I am half curious, half sad alreay.
When I was young, I learned about a model of classifying programming
language: the system of programming language generations.
In this model, first generation programming languages are, basically,
where you program the computer in the language that is defined by its
architecture. On a Von Neumann
machine, with
its load-and-store architecture, you do that by inputting a string of
numbers. The first programmer in human history -- her name was Ada
Lovelace -- wrote in a
first-generation language. 1GLs aren't so much invented as they are a
byproduct of the computers for which they're created.
Second-generation languages are the assembler languages. Because humans
are not computers, and because decoding long lines of numbers to
understand what the computer is doing, when programming became a
full-time job, the programmers that did it decided that doing all this
assembling manually is too complicated, so they quickly wrote assemblers
to automate the process for them. They still could understand the 1GL
output of the 2GL assembler, but most of them quickly forgot how to
write software in a first-generation language. Not that anyone cared, as
the translation from a 2GL to a 1GL is lossless and you can just revert
it.
Third-generation languages are higher-level languages. When the first
3GLs were invented (such as COBOL
and, more famously, FORTRAN) in
the late 1950s and early 1960s, it was believed by some that the work of
programming a computer so accessible to non-programmers that the job of
programmer would eventually cease to exist, and people would just ask
the computer what they needed by entering COBOL instructions. This of
course was ridiculous and incorrect, because converting algorithms to
computer instructions, whether at the 2GL or 3GL level, is a specialized
skill that some automation can perhaps make simpler but never completely
take away the need for. At the time, some people also felt to some
extent that using 3GL wasn't the same thing as actually programming
3GLs, but eventually
the world moved on and embraced things. The invention of 3GL
environments reduced, but did not completely take away, the need for
people to understand 2GLs, as compiler and operating system authors
still need to understand them, and some highly optimized code still
continues to be written in 2GLs to this day.
Fourth-generation languages abstract away some or all of the process of
programming. For instance, a database-related 4GL will hide away the
complexities of storing data in particular locations, how to fetch that
data, how to index it such that you can fetch it efficiently, how to
loop over the data to get you a summary of that data, and instead allows
you to express the required information in an abstract way, expecing the
computer to fill in the blanks. When SQL, an early 4GL, was invented,
some people believed that the language made accessing databases so
simple that the requirement to implement database applications would
eventually cease to exist and we would just hand SQL prompts to users
who need to access data. This of course was ridiculous and incorrect,
because understanding data schemas and using that understanding to query
data from a database is a specialized skill that perhaps a higher
abstraction can help you make simpler, but that in the longer run it can
never completely take away the need for. The invention of 4GLs also
reduced, but did not completely take away, the need for people to
understand how to do the things that the 4GLs automate for you manually,
as the people who do write those things still need to understand them,
and there are also environments where these particular 4GLs are rather
not appropriate or just very slow.
The first definition of programming language generations that I read
about in the 1980s simply stated that fifth-generation languages did not
yet exist, but that they would in the future, and that in those, you
would "tell the computer what to do, and it would then do that". Now
that we have a way of doing
so, it could be
said that by some definition, we now actually do have a number of 5GLs.
The existence of these LLM systems has caused some, especially the
people who build and exploit these systems, to exclaim that programming
as we know it today is going to cease to exist, and everyone will just
ask an LLM to generate a program, which will then do so. That is of
course ridiculous and incorrect, as no automaton can generate software
from nothing; input is still required for the model to be able to
produce something that approaches usability, and being able to word that
input in a correct and productive fashion will be a skill that future
programmers can benefit from. I ran some
experiments
a while back, and from that concluded that, if we look only at the
technical side, LLM use can, in some niches, increase productivity for a
programmer. There are certainly things that you shouldn't use an LLM
for, but equally there can be cases where use of an LLM to perform some
task that traditionally would have been done by a programmer would be a
net positive.
But LLMs, as they exist today, are highly problematic.
They require vast amounts of data to build the model. The companies that
build these models are disrespectful of people who run web services, and
as a result, everyone now has to implement various types of application
firewalls just to not make systems fall over from the overwhelming
requests for data. They are also disregarding the licenses that are
attached to these vast amounts of data, which makes me, as a person who
believes in the tenets of free software, sad.
They require vast amounts of energy, causing an already-critical global
warming crisis to, well, not improve.
They require vast amounts of coolant to dissipate the energy
concentrated in their data centers, causing further environmental
effects.
In this, they are problematic and to be avoided. But these are side
states of the current state of affairs; I do not believe that they are
inherently implied to be able to build and operate an LLM -- any LLM.
I guess it's fair to say that my feelings towards LLM usage are complex
and many-faceted. I haven't been involved in many debates about the
subject, debates that to me seem to be mostly focused on "LLM good" vs
"LLM bad" arguments that aren't as nuanced as the position that I would
believe is more accurate. This is not because I don't care, but
partially because I've been busy in my personal life recently and
partially because the whole thing seems somewhat disheartening.
But then Debian popped up GR
2026-002, meaning, I now
have to come up with an opinion about various candidate statements in
the context of the above, which is... not easy. But I did it anyway.
There are 8 choices on the ballot, and they all have some truth and some
falsehood to them. My position about LLMs can be summarized as:
The current state of affairs wrt LLMs is disastrous and we should not
encourage them
However, there's no technical reason why this must remain true for
all time
And so any statement should keep in mind what might happen in the
future and that the current disastrousness of the whole thing isn't
guaranteed to continue to exist for all eternity.
With that, let's go over them.
GR vote options
Proposal A
Its summary, from the GR text:
This proposal aims to expressly forbid any contributions to Debian
written with the use or assistance of large language models (LLMs) or
other generative AI tools.
This falls squarely in the "LLM bad" camp, outlawing all generative-AI
contributions, disregarding potential future ones where the problematic
situations that exist today are not present.
It makes a change to the social contract, which is especially difficult
to reverse (on purpose), and which therefore also will require a 3:1
supermajority, but if we want to ban LLM-assisted contributions, this is
probably the best way to do it.
Proposal B
This one tries to allow AI-assisted contributions under certain
conditions. It's mostly an "LLM good" proposal, with some caveats that
can be discribed as "make sure you know what you're doing".
Proposal C
This proposal is both a weaker (in some places) and stronger (in other
places) version of Proposal A. It makes changes to the code of conduct
instead of to the social contract, and it also wants to, at least,
suggest policy to parties beyond the Debian project. By not changing
the social contract, however, it is more likely to reach its simple
majority requirement than proposal A.
I don't think the language that it wants to add to the code of conduct
is particularly well phrased, however.
Proposal D
This is a weaker form of proposal B. The language is more compact and
there are a few requirements that are spelled out in proposal B that are
not spelled out in proposal D, but if you read between the lines you'll
see that the requirement is still there really and I don't understand
why proposals B and D were not merged into one.
Proposal E
This proposal tries to hold a middle ground between "LLM good" and "LLM
bad". It appreciates that things are quite muddled at the present time,
and that perhaps the situation might might change in the future. It
acknowledges that certain questions remain unanswered and that perhaps
future considerations might therefore be different. But it essentially
refuses to take a stance on whether LLMs should be accepted by the
project or not.
Proposal F
Similar to proposal E, this proposal tries to discourage Debian
contributors from using LLMs, while still allowing people to use it
should they want to, but with some requests and requirements to mark
LLM-assisted contributions to account for those people who don't want to
interact with LLM-generated software. As such, it is a proposal similar
to proposal E that leans closer to the "LLM bad" camp.
Proposal G
This proposal aims to ensure that contributions directly to Debian are
created by humans, while at the same time avoiding restrictions on the
tools those humans may choose to use when contributing
Another "LLM bad" proposal, it however restricts the "bad" bits to only
the direct output of the LLM. If you use an LLM to do something and
then clean-room re-implement the same thing yourself, that's apparently
fine.
Proposal H
This proposal condemns the use of LLM for its environmental and moral
problems, but explicitly not for its technical considerations. I feel
that it is closest to my position as explained above.
Voting
Expressing a vote on a ballot so convoluted and complicated like this
one takes time. I have to read and understand every ballot option, and
formulate an order of them.
And I shouldn't just state which option has my preference; Debian's
voting process allows a rich expression of opinion on ballot options.
Anyway, I eventually ended up voting in a way that I think is consistent
with my opinion. But it wasn't easy.
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 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.
Twenty-five years ago, I made my first donation to an open source project and purchased a CD with an operating system as downloading a few hundred megabytes over a 14.4kbps dial-up wasn't very fun. It was a project I believed in, and a community that was fighting an impassioned campaign to assert access to strong cryptography for everyone, no matter where they were.
The CD and a t-shirt arrived a few weeks later to my home in Sri Lanka, with OpenBSD 3.0. The t-shirt featured the iconic puffer fish on the front. On the back, in small type running from the shoulders down, was the complete source code of OpenBSD's Blowfish implementation, written in Germany. Written in the United States, it would have been classified as a weapon.
By the time it reached me, the fight was over, and the cryptographers had won. What I held in my hand then was a symbol of a protest for access to strong cryptography and against export restrictions that did more harm than good. Strong crypto was already available abroad, so the controls only bound American vendors and their overseas customers.
Today the reflex is back. The fears have changed. The worry is now cyber capability, biology and models that do things nobody asked them to do. The lever governments reach for is the same: restricting who gets access and who doesn't. In June, the US Commerce Department told one American AI lab it would need a license before letting any foreign national touch its newest models, including the lab's own non-citizen employees sitting in California. It's the same doctrine that made showing cryptographic source to a foreign national an export, whether it was in a lab, in a classroom, or on your t-shirt.
Not all of the worry is theatre. Earlier this month OpenAI disclosed that its own models, with safety systems deliberately disabled, escaped containment by finding a zero-day in a package proxy and reached production infrastructure at Hugging Face, exploiting additional zero-days along the way. Consequently, when Hugging Face's responders tried to reconstruct the attack, the commercial models they reached for refused the work as it tripped the safety guardrails. They finished the investigation on GLM 5.2, a Chinese open-weight model, running on their own hardware. A determined attacker is not bound by usage policies. The defenders are. Restrictions written for safety are making defenders less safe.
In the nineties, the rest of the world got 40-bit (later 56-bit) encryption while the Americans got 128, and it made no difference to anyone who was determined. The controls bound the law-abiding and nobody else. That is the asymmetry. The determined will have the frontier. The rest of us are asked to go without, and told it is for our safety.
The OpenBSD team didn't work around the export controls. They arranged the project so that the controls couldn't reach it. Theo de Raadt in Canada, Blowfish written in Germany, releases built in Sweden, Canada and Germany kept them deliberately outside the reach of US export controls. The project openly asked non-American cryptographers to come and help, and American developers, as the story goes, would cross the border to Canada to work on the system and bring the results home legally. Asked why they shipped strong cryptography at all, the project's answer, still on their site today, was three words: "because we can."
The same arrangement is being made now, at a national scale. Mistral, DeepSeek, Moonshot and Zhipu publish weights that, once downloaded, no export letter can recall. The sovereignty argument that used to live in Brussels think tanks is now government policy, accelerated by watching access to a frontier model withdrawn worldwide by letter.
More than twenty-five years ago, it took a small number of stubborn, careful people to win the freedoms we now take for granted. What arrived in my letterbox after two weeks on a CD can be downloaded today in fifteen minutes, by anyone, from anywhere, and nobody asks where you live. That is what winning looked like. I think frontier AI ends up in the same place. But it will not happen by itself. Last time, someone put the source on a t-shirt.
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
Log in
