ExcitingAds! Planet Debian

Dirk Eddelbuettel: linl 0.0.6 on CRAN: Maintenance

Wed, 26 Aug 2026 18:06:00 +0000

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

Switch to Authors@R in DESCRIPTION

Courtesy of CRANberries, there is a comparison to the previous release. For questions or comments use the issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

Raphaël Hertzog: Debian’s General Resolution on AI and LLM

Wed, 26 Aug 2026 16:04:10 +0000

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…)

Ian Jackson: Debian LLM GR - Summary of the options

Wed, 26 Aug 2026 09:11:35 +0000

Debian LLM GR - Summary of the options

Introduction

LLMs have finally made it to the ultimate stage of Debian’s governance processes, a General Resolution of all the project’s full governing members (DDs).

There are a lot of options on the ballot, and they all have a different structure and approach the question in a different way. It can be hard to see the wood for the trees. I have made a summary table to try to capture the main differences, both in effect, and sentiment.

A plea to the undecided voter

Suspending briefly my attempt to be neutral:

Before voting, I encourage you to read the passionate rationales in options H and A, or at least the summary in my option C.

Few of the LLM defences in the discussion threads, and none of the LLM-positive proposals, provide answers to any of these profound ethical concerns, many of which ought individually to be a deal-breaker. Instead, these crucial questions are simply dismissed or even ignored.

Some will tell you we should “keep politics out of software” but as we can see in the world around us, software is political - now more than ever. Debian’s mission is a highly political one: developing a fully-free operating system, and defending its freeness as we do, is far from neutral!

And of course many of LLMs’ harms affect Debian directly.

Table

	A	G	C	H	F	D	B	E
LLM harms	Robustly discussed	Discussed	Robustly summarised	Robustly discussed; especially re climate	Summarised	Accepted as inevitable	Disregarded [1]	Ignored
Direct contributions of LLM-generated code	Forbidden	Forbidden	Strongly discouraged	Strongly discouraged	Discouraged	Permitted	Permitted	Permitted
Direct use of LLM output in communications (bugs, mailing lists, etc.)	Forbidden	Forbidden	Forbidden (with possible exceptions)	Strongly discouraged	Discouraged	Permitted	Permitted	Permitted
LLM use where LLM output does not end up in the code/message	Forbidden	No position, so permitted	Strongly discouraged	Strongly discouraged	Discouraged	Permitted	Permitted	Permitted
Disclosure of LLM use	LLM use forbidden	LLM use largely forbidden, no further disclosure requirement	Disclosure required	Disclosure encouraged	Disclosure encouraged	Disclosure required	Disclosure required	Undisclosed LLM use is OK
Use of LLMs by upstreams			Condemned			“Not recommended”
Positive statements about LLMs						“Here to stay”	Moderate	Strong

Notes

Ordering

I have tried to present the options in semantic order, with most LLM-negative proposals to the left, and the most LLM-positive to the right.

I have not quoted the one-line titles for the options. These have generally been provided by the proponents of each option, and, unfortunately, some of them are IMO quite misleading.

Note that, unfortunately, the voting software likes to assign numbers to options but also to preferences. Be mindful of this possible confusion when casting your vote. For clarity I quote only the option letters.

Upstream LLM code contributions

Some of the proposals acknowledge the uncertain legal status of LLM output. But all of them implicitly or explicitly assume that LLM output is or can be DFSG free. So none of the proposals forbid upstream projects with LLM-generated contents.

None of the proposals would require us to go back to pre-LLM versions of the upstream projects we use, and attempt to fork and maintain them. I very much think there is room in the world for people to try to do that, but I don’t think the Debian project can be that effort.

Given that the conclusions are the same in each case, whether the matter is discussed does not seem to me to be a significant difference. I have therefore not included a column for it.

Ability of individual teams to set their own rules

My proposal has a specific paragraph (7) explicitly permitting teams to set a “no LLM” policy. The other proposals do not discuss this point specifically. During the discussion, it seemed that most participants agreed that even options which explicitly permit LLM use generally do not prevent a team from setting its own more restrictive LLM policy.

I have therefore not tabulated this aspect.

Exceptions and nuances

Few of the permissive texts are absolute or unconditional. To summarise I have necessarily left out some nuance.

So for example when an entry says “permitted”, that generally means “permitted with conditions which are believed by LLM users to be readily satisfiable” (for example, DFSG-compatibility - see above).

[1] Footnote re proposal B

Proposal B does mention that there are “concerns” about LLM use. But it fails to make an explicit statement about whether these concerns are justified.

It then proceeds exactly as if they are not justified. IMO “disregarded” is a relatively mild term for such a rhetorical technique.

Edited 2026-08-18 09:02 UTC to make the proposal letters in the table be links; 2026-08-26 09:11 UTC to fix typos.

comments

Matthew Garrett: Hooking an old magicJack adapter to modern Asterisk

Wed, 26 Aug 2026 04:04:17 +0000

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 here¹, 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:

Your browser doesn't support HTML5 video. Here is a link to the video instead.

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! ↩︎

Tim Retout: TF RAID

Tue, 25 Aug 2026 20:38:53 +0000

My hobby: following GOV.UK to look for interesting announcements. Today was an update on the MOD’s Rapid AI Delivery Taskforce which was previously announced in June during London Tech Week.

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:

Understanding and decision advantage
Electromagnetic and information advantage
Planning and automation
Autonomous systems

Yesterday’s announcement of UK access to Ukraine’s Avengers AI Labs database seems incredibly relevant to that last point.

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.

Antoine Beaupré: A more nuanced view of LLMs

Tue, 25 Aug 2026 16:07:58 +0000

Also in this series:

The Four Horsemen of the LLM Apocalypse

The people vs the AI overlords

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 agree with 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.¹

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 two months 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:

llm: a CLI utility and Python library for interacting with Large Language Models, with OpenAI as its default API backend
llm-anthropic: a plugin for llm which allows me to talk to Anthropic's API instead of OpenAI
anthropic-sdk-python: the SDK llm-anthropic requires to do its work

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.

So I moved it to main, alongside similarly controversial tools like llama.cpp or the python-openai library.

OpenAI and Anthropic usage

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.

As it turns out, Anthropic is also happy to work for the US military (which is a big red line for me). Anthropic also won't let you talk about the genocide in Gaza, it is destroying physical books, and is blackmailing us to use their product for security coverage.

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:

> llm logs list -n 0  --json | jq -r .[].datetime_utc | sed 's/-.*//' | sort | uniq -c 
    527 2024
    357 2025
     98 2026

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.

I do this for the reasons outlined in The Four Horsemen of the LLM Apocalypse, because I refuse to be complicit in the:

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:

 806 files changed, 72281 insertions(+), 1478 deletions(-)

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.

Now Microsoft pulled the plug and Over 170,000 Nonprofits Lost All Their Data.

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.↩

Dirk Eddelbuettel: gettz 0.0.6 on CRAN: Maintenance

Tue, 25 Aug 2026 14:01:00 +0000

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.

Thanks to my CRANberries, there is a diff to the previous release. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

Matthias Klumpp: Sovereign Tech Fellowship for Freedesktop Tasks

Mon, 24 Aug 2026 21:00:40 +0000

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!

Dirk Eddelbuettel: gaussfacts 0.0.3 on CRAN: Maintenance

Mon, 24 Aug 2026 19:04:00 +0000

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)

Updated continunous integration (#3)

Changes in version 0.0.1 (2016-06-19)

Initial version and CRAN upload

Thanks to my CRANberries, there is a diff to the previous release. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

Vincent Bernat: An interactive introduction to the spanning tree protocol

Mon, 24 Aug 2026 15:00:00 +0000

Warning

This post contains interactive examples. To visualize and interact with them, you need to leave your RSS reader.

That’s where the spanning tree protocol (STP) comes in. STP blocks just enough of your spare cables to leave a loop-free tree. When Stan strikes again, it rebuilds the tree in a second, leaving some time for Blobby, your one-person support crew, to reconnect the cable.¹ See for yourself: the diagram below runs a real STP implementation in your browser!

:demo

A1 @0,0 prio=4096
A2 @0,1
A3 @0,2
A4 @0,3

B1 @1,0 prio=8192
B2 @1,1
B3 @1,2
B4 @1,3

C1 @2,0 prio=8192
C2 @2,1
C3 @2,2
C4 @2,3

A1 -- A2 hazard=0
A2 -- A3 hazard=0
A3 -- A4 hazard=0
B1 -- B2
B2 -- B3
B3 -- B4
C1 -- C2 hazard=0
C2 -- C3 hazard=0
C3 -- C4 hazard=0

A1 -- B1 cost=10
B1 -- C1 cost=10
A4 -- B4 cost=20
B4 -- C4 cost=20

Leo @-0.3,0.7 proto=none icon=👦🏻
Mia @-0.3,1.3 proto=none icon=👧🏽
Joy @0.3,0.7  proto=none icon=👱🏻‍♀️
Roy @0.3,1.3  proto=none icon=👨🏾
A2 -- Leo hazard=0 A2:edge
A2 -- Mia hazard=0 A2:edge
A2 -- Joy hazard=0 A2:edge
A2 -- Roy hazard=0 A2:edge

Max @-0.3,1.7 proto=none icon=👨🏽
Zoe @-0.3,2.3 proto=none icon=👩🏾
Ada @0.3,1.7  proto=none icon=👵🏾
Amy @0.3,2.3  proto=none icon=👩🏼
A3 -- Max hazard=0 A3:edge
A3 -- Zoe hazard=0 A3:edge
A3 -- Ada hazard=0 A3:edge
A3 -- Amy hazard=0 A3:edge

Eli @0.7,0.7 proto=none icon=👦🏼
Jay @0.7,1.3 proto=none icon=👨🏻
Kai @1.3,0.7  proto=none icon=🧑🏽
Ben @1.3,1.3  proto=none icon=👱🏼
B2 -- Eli hazard=0.2 B2:edge
B2 -- Jay hazard=0.2 B2:edge
B2 -- Kai hazard=0.2 B2:edge
B2 -- Ben hazard=0.2 B2:edge

Ava @0.7,1.7 proto=none icon=👩🏻
Lea @0.7,2.3 proto=none icon=🧑🏾‍🦱
Ivy @1.3,1.7  proto=none icon=🧕🏽
Rex @1.3,2.3  proto=none icon=👴🏿
B3 -- Ava hazard=0.2 B3:edge
B3 -- Lea hazard=0.2 B3:edge
B3 -- Ivy hazard=0.2 B3:edge
B3 -- Rex hazard=0.2 B3:edge

Ana @1.7,0.7 proto=none icon=👩🏿
Eve @1.7,1.3 proto=none icon=👧🏼
Abe @2.3,0.7  proto=none icon=🧓🏿
Ian @2.3,1.3  proto=none icon=🧔🏾
C2 -- Ana hazard=0 C2:edge
C2 -- Eve hazard=0 C2:edge
C2 -- Abe hazard=0 C2:edge
C2 -- Ian hazard=0 C2:edge

Ned @1.7,1.7 proto=none icon=👨🏼‍🦳
Lou @1.7,2.3 proto=none icon=🧑🏿
Fay @2.3,1.7  proto=none icon=👧🏻
Sue @2.3,2.3  proto=none icon=👩🏽‍🦰
C3 -- Ned hazard=0 C3:edge
C3 -- Lou hazard=0 C3:edge
C3 -- Fay hazard=0 C3:edge
C3 -- Sue hazard=0 C3:edge

Note

This article is also available as a video, but I advise you to keep reading here to try the interactive demonstrations.

The basics

Designed in the ’80s, the spanning tree protocol has evolved into a “rapid” flavor (RSTP) and a “VLAN-aware” variation (MSTP).² 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.

:protocol rstp
:tx-hold 10

A1 @0,1
C11 @1,0 prio=4096 icon=🌳
C12 @1,2 prio=4096 icon=🌳
C21 @2,0 prio=4096 icon=🌳
C22 @2,2 prio=4096 icon=🌳
A2 @3,1

H1 @0,0.2 proto=none icon=💻
H2 @0,1.8 proto=none icon=🖨️
H3 @3,0.2 proto=none icon=📠
H4 @3,1.8 proto=none icon=📺

A1 -- C11
A1 -- C12
A2 -- C21
A2 -- C22
C11 -- C12
C11 -- C21
C11 -- C21
C11 -- C22
C12 -- C21
C12 -- C22
C21 -- C22
A1 -- H1 A1:edge
A1 -- H2 A1:edge
A2 -- H3 A2:edge
A2 -- H4 A2:edge

After some time, the topology converges to a tree: from the root C11, there is a path to each bridge³ 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-space⁴ implementation of RSTP.⁵

Historical interlude

Radia Perlman, an inductee of the Internet Hall of Fame in 2014, summarized the ancestor of STP she invented at DEC with this poem, later included in a US patent:

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.

― Radia Perlman, Algorhyme.

Electing the root bridge

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:⁶ S4 becomes root. S5 and S6 don’t have a specific priority, so the lowest MAC address wins and S5 becomes root.

:protocol rstp

S1 @0,0 prio=4096
S2 @0,1 prio=8192
S1 -- S2

S3 @1,0
S4 @1,1 prio=12288
S3 -- S4

S5 @2,0
S6 @2,1
S5 -- S6

Initially, each bridge advertises itself as root:⁷

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: 8192.02:00:00:01:00:01
    Bridge Identifier: 8192.02:00:00:01:00:01

Once a bridge receives a BPDU advertising a better root bridge, it propagates this new information to its neighbors.

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
    Bridge Identifier: 8192.02:00:00:00:00:01

Assigning roles to ports

The second step is to assign a role to each port. RSTP defines five roles, each denoted by a letter:

root (R),
designated (D),
alternate (A),
disabled (X), or
backup (B).⁸

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:

the lowest root bridge identifier,
the lowest accumulated cost to the root,
the lowest bridge identifier, and
the lowest port identifier.

:protocol rstp

S1 @1,0  prio=4096 icon=🌳
S2 @0,1
S3 @2,1

S1 -- S2
S1 -- S3
S1 -- S3
S2 -- S3

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

If you cut the active link between S1 and S3, S3 promotes the “best” alternate port to root port. If you also disable the second link, S3 chooses the remaining alternate port as a root port. But if you disable the link between S1 and S2, S2 needs a bit more work to elect a new root port because it does not have an alternate port.

Unless a specific event happens, designated ports send BPDUs every 2 seconds.⁹ 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.¹⁰

:protocol rstp

S1 @1,0 prio=4096 icon=🌳
S2 @1,1
S3 @0,2
S4 @2,2
S5 @0,3 prio=8192 icon=🪾
S6 @2,3
H1 @0,1.2   proto=none icon=🖨️
H2 @2,1.2   proto=none icon=📠
H3 @2.5,1.3 proto=none icon=📺
H4 @2.5,2.3 proto=none icon=💻

S1 -- S2
S2 -- S3
S2 -- S4
S3 -- S5
S4 -- S6
S4 -- S3
S5 -- S6

S3 -- H1 S3:edge
S4 -- H2 S4:edge
S4 -- H3 S4:edge
S6 -- H4 S6:edge

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:¹¹

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.¹² 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.

:protocol rstp

S1 @1,0 prio=4096 icon=🌳
S2 @0,1
S3 @1,1
S4 @2,1
S5 @1,2
LPT @0.1,2 proto=none icon=🖨️

S1 -- S2
S1 -- S3
S1 -- S4
S2 -- S3
S2 -- S5
S4 -- S5
S5 -- LPT S5:edge

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.¹³ 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.

R0 @1.5,1.5 prio=8192

# AutoEdge=true, AdminEdge=false, bridge
S1 @3,1.58
R0 -- S1

# AutoEdge=true, AdminEdge=false, end device
H1 @2.84,2.18 icon=🖨️ proto=none
R0 -- H1

# AutoEdge=true, AdminEdge=true, bridge
S2 @2.18,2.84
R0 -- S2 R0:edge

# AutoEdge=true, AdminEdge=true, end device
H2 @1.58,3 icon=💻 proto=none
R0 -- H2 R0:edge

# AutoEdge=false, AdminEdge=true, bridge
S3 @0.68,2.76
R0 -- S3 R0:edge R0:no-auto-edge

# AutoEdge=false, AdminEdge=true, end device
H3 @0.24,2.32 icon=📠 proto=none
R0 -- H3 R0:edge R0:no-auto-edge

# AutoEdge=false, AdminEdge=false, bridge
S4 @0,1.42
R0 -- S4 R0:no-auto-edge

# AutoEdge=false, AdminEdge=false, end device
H4 @0.16,0.82 icon=📺 proto=none
R0 -- H4 R0:no-auto-edge

# Network port, bridge
S5 @0.82,0.16
R0 -- S5 R0:network S5:network

# Network port, end device
H5 @1.42,0 icon=☕ proto=none
R0 -- H5 R0:network

# AdminEdge=true, bpdu-guard=true, bridge
S6 @2.32,0.24
R0 -- S6 R0:bpdu-guard R0:edge

# AdminEdge=true, bpdu-guard=true, end device
H6 @2.76,0.68 icon=💡 proto=none
R0 -- H6 R0:bpdu-guard R0:edge

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.¹⁴ 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.¹⁵

:protocol rstp
:tx-hold 10

# Root bridges
R1 @0,1 prio=0
R2 @0,2 prio=4096
R1 -- R2 cost=200 R1:network R2:network
R1 -- R2 cost=200 R1:network R2:network

# First loop
C1  @1,0 icon=🗄️
C4  @2,0 icon=🗄️
C7  @3,0 icon=🗄️
C10 @4,0 icon=🗄️
C12 @5,0 icon=🗄️
C13 @5,3 icon=🗄️
C15 @4,3 icon=🗄️
C18 @3,3 icon=🗄️
C21 @2,3 icon=🗄️
C24 @1,3 icon=🗄️
R1  -- C1  R1:network C1:network
C1  -- C4  C1:network C4:network
C4  -- C7  C4:network C7:network
C7  -- C10 C7:network C10:network
C10 -- C12 C10:network C12:network
C12 -- C13 C12:network C13:network
C13 -- C15 C13:network C15:network
C15 -- C18 C15:network C18:network
C18 -- C21 C18:network C21:network
C21 -- C24 C21:network C24:network
C24 -- R2  C24:network R2:network

# Second loop
C2  @1,0.5 icon=🗄️
C5  @2,0.5 icon=🗄️
C8  @3,0.5 icon=🗄️
C11 @4,0.5 icon=🗄️
C14 @4,2.5 icon=🗄️
C17 @3,2.5 icon=🗄️
C20 @2,2.5 icon=🗄️
C23 @1,2.5 icon=🗄️
R1  -- C2  R1:network C2:network
C2  -- C5  C2:network C5:network
C5  -- C8  C5:network C8:network
C8  -- C11 C8:network C11:network
C11 -- C14 C11:network C14:network
C14 -- C17 C14:network C17:network
C17 -- C20 C17:network C20:network
C20 -- C23 C20:network C23:network
C23 -- R2  C23:network R2:network

# Third loop
C3  @1,1 icon=🗄️
C6  @2,1 icon=🗄️
C9  @3,1 icon=🗄️
C16 @3,2 icon=🗄️
C19 @2,2 icon=🗄️
C22 @1,2 icon=🗄️
R1  -- C3  R1:network C3:network
C3  -- C6  C3:network C6:network
C6  -- C9  C6:network C9:network
C9  -- C16 C9:network C16:network
C16 -- C19 C16:network C19:network
C19 -- C22 C19:network C22:network
C22 -- R2  C22:network R2:network

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.¹⁶

:protocol rstp
:tx-hold 10
:max-age 20

R1 @0,0 prio=4096 icon=🌳
R2 @0,5 prio=4096 icon=🪾

S1  @1,0
S2  @2,0
S3  @3,0
S4  @4,0
S5  @5,0
S6  @6,0

S7  @6,1
S8  @5,1
S9  @4,1
S10 @3,1
S11 @2,1
S12 @1,1

S13 @1,2
S14 @2,2
S15 @3,2
S16 @4,2
S17 @5,2
S18 @6,2

S19 @6,3
S20 @5,3
S21 @4,3
S22 @3,3
S23 @2,3
S24 @1,3

S25 @1,4
S26 @2,4
S27 @3,4
S28 @4,4
S29 @5,4
S30 @6,4

S31 @6,5
S32 @5,5
S33 @4,5
S34 @3,5
S35 @2,5
S36 @1,5

R1  -- S1
S1  -- S2
S2  -- S3
S3  -- S4
S4  -- S5
S5  -- S6
S6  -- S7
S7  -- S8
S8  -- S9
S9  -- S10
S10 -- S11
S11 -- S12
S12 -- S13
S13 -- S14
S14 -- S15
S15 -- S16
S16 -- S17
S17 -- S18
S18 -- S19
S19 -- S20
S20 -- S21
S21 -- S22
S22 -- S23
S23 -- S24
S24 -- S25
S25 -- S26
S26 -- S27
S27 -- S28
S28 -- S29
S29 -- S30
S30 -- S31
S31 -- S32
S32 -- S33
S33 -- S34
S34 -- S35
S35 -- S36
S36 -- R2
R1  -- R2 cost=200 down

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.¹⁷

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.¹⁸ Some topologies can take a bit more time to recover when the root bridge becomes unavailable.¹⁹

:protocol rstp

R0 @1,0 prio=0
S1 @1,1 prio=4096
S2 @0,2 prio=8192
S3 @2,2

R0 -- S1
S1 -- S2
S2 -- S3
S3 -- S1

In the topology above, start the simulation, wait for convergence, hit stop, and cut the link between R0 and S1. The topology is already optimal, but RSTP has a hard time converging again.

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";
const mstp = await loadMSTPD();

// Create 3 bridges
const a = mstp.createBridge("A", { priority: 4096 });
const b = mstp.createBridge("B", { priority: 8192 });
const c = mstp.createBridge("C");

// Each bridge has two ports
const a1 = a.addPort("a-b", { portno: 1 });
const a2 = a.addPort("a-c", { portno: 2 });
const b1 = b.addPort("b-a", { portno: 1 });
const b2 = b.addPort("b-c", { portno: 2 });
const c1 = c.addPort("c-a", { portno: 1 });
const c2 = c.addPort("c-b", { portno: 2 });

// Build a triangle topology
mstp.link(a1, b1);
mstp.link(a2, c1);
mstp.link(b2, c2);

// Enable all bridges and ports
for (const br of [a, b, c]) br.enable();
for (const p of [a1, a2, b1, b2, c1, c2]) p.enable();

// Execute 40 seconds' worth of wall clock and display the topology
mstp.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. ↩
STP was introduced in IEEE 802.1D-1990. It is still present in IEEE 802.1D-1998 but was withdrawn in IEEE 802.1D-2004 in favor of RSTP, introduced in IEEE 802.1w-2001. MSTP was introduced in IEEE 802.1s-2002 and merged into IEEE 802.1Q-2003. Both of them are part of IEEE 802.1Q-2022 along with SPB~~—a protocol I had never heard of until writing this article~~. ↩
From here, I use “bridge” instead of the more common word “switch.” ↩
The Linux kernel only runs STP. It delegates the other protocols to user space. ↩
MSTPD implements the state machine from IEEE 802.1Q-2005, but on Linux it runs RSTP only. Linux 5.18 added support for forwarding multiple spanning tree, but MSTPD does not use it yet. See PR #150 for progress on this front. ↩
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. ↩
This timer makes RSTP resistant to packet loss. ↩
You can get them for less than US$100 through a broker. All the ports run PVST+ by default and automatically fall back to plain RSTP. ↩
An alternative would be Ethernet Ring Protection Switching (ERPS)—another protocol I had never heard of until researching this article. ↩
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.” ↩
Khaled Elmeleegy, Alan Cox, and Eugene Ng formalized this phenomenon in “On Count-to-Infinity Induced Forwarding Loops in Ethernet Networks” and later in “Understanding and Mitigating the Effects of Count to Infinity in Ethernet Networks.” They propose a fix that did not find its way into a standard. ↩

Vincent Bernat: A non-interactive introduction to the spanning tree protocol

Mon, 24 Aug 2026 14:59:00 +0000

Imagine you rent office space for a three-day event. You quickly set up a few Ethernet switches and tape some cables on the floor to get everyone online. Unfortunately, Stan, your clumsiest coworker, kicks out a cable every time he gets up for coffee. Spare cables would fix that, but a loop turns into a broadcast storm: Ethernet packets multiply until nothing else gets through. That’s where the spanning tree protocol comes in: it blocks just enough of the spare cables to leave a loop-free tree, and rebuilds it in a second each time Stan strikes again.¹

This content is also available as a text version, with interactive demos that run a real implementation directly in your browser!

This video is an experiment.² Honestly, except for Radia Perlman reading her poem,³ 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!

The sprites for Stan and Blobby come from Craftpix. The background music is “Sonatina No. 2 in G Major – III. Allegro” by Aaron Dunn. ↩
I thought automated tools would produce this video in a couple of hours. In the end, it was another rabbit hole and it took me more than 12. ↩
The audio was extracted from a Youtube video and cleaned up. ↩

David Bremner: Reproducing Org mode configuration

Mon, 24 Aug 2026 10:30:00 +0000

Context

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

  EMACSHOME=$(mktemp -d)
  git clone https://git.sr.ht/~bzg/org-mode ${EMACSHOME}/org
  git -C ${EMACSHOME}/org reset --hard release_9.8.7 
  make -C ${EMACSHOME}/org autoloads
  emacs -Q --batch -L ${EMACSHOME}/org/lisp --eval "(progn (require 'org) (message (org-version)))"

This should print 9.8.7, not the version of built in org-mode.

Recipe part 2: add-on packages

Now to test some add-on packages, run

    emacs -Q --init-directory ${EMACSHOME} -L ${EMACSHOME}/org/lisp

  (progn
    (require 'org)
    (package-initialize)
    (package-vc-install "https://github.com/emacs-straight/queue")
    (package-vc-install "https://github.com/joostkremers/parsebib" "6.7")
    (package-vc-install "https://github.com/rejeep/f.el" "0.21.0")
    (package-vc-install "https://github.com/magnars/s.el" "1.13.0")
    (package-vc-install "https://github.com/akicho8/string-inflection" "1.0.16")
    (package-vc-install "https://github.com/andras-simonyi/citeproc-el" "0.9.5"))

You can then run your tests in that emacs right away, or restart the environment with

  emacs -Q --init-directory ${EMACSHOME} -L ${EMACSHOME}/org/lisp

Freexian Collaborators: Monthly report about Debian Long Term Support, July 2026 (by Santiago Ruano Rincón)

Mon, 24 Aug 2026 00:00:00 +0000

The Debian LTS Team, funded by [Freexian’s Debian LTS offering] (https://www.freexian.com/lts/debian/), is pleased to report its activities for July.

Activity summary

During the month of July, 23 contributors have been paid to work on Debian LTS (links to individual contributor reports are located below).

The team released 52 DLAs fixing 2159 CVEs.

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.

Contributions from outside the LTS Team:

Guillem Jover prepared the dpkg update, released as DLA-4673-1 by Arnaud.
Nicholas Guriev released a rlottie security update (DLA 4675-1)
Bernhard Schmidt prepared the openvpn updates for both bookworm and trixie, released as DLA 4666-1.

The LTS Team has also contributed with updates to the latest Debian releases:

Bastien also proposed two updates for imagemagick. The first one released as DSA 6383-1, and the second as a trixie point update proposal (#1142554).
python-httplib2 by Emmanuel Arias, and released by the security team as DSA 6441-1 in August.
hplip (DSA 6402-1), prepared by Thorsten Alteholz, to address privilege escalation and arbitrary code execution related flaws.
libnfs trixie update (#1142351), by Thorsten
patool update for trixie #1141607, by Abhijith PA

Other contributions:

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.

Individual Debian LTS contributor reports

Thanks to our sponsors

Sponsors that joined recently are in bold.

Platinum sponsors:
- Toshiba Corporation (for 130 months)
- Civil Infrastructure Platform (CIP) (for 98 months)
- VyOS Inc (for 63 months)
Gold sponsors:
- F. Hoffmann-La Roche AG (for 141 months)
- CONET Deutschland GmbH (for 124 months)
- University of Oxford (for 81 months)
- EDF SA (for 52 months)
- Dataport AöR (for 27 months)
- CERN (for 25 months)
Silver sponsors:
- Domeneshop AS (for 145 months)
- Nantes Métropole (for 139 months)
- Akamai - Linode (for 135 months)
- Univention GmbH (for 131 months)
- Université Jean Monnet de St Etienne (for 131 months)
- Ribbon Communications, Inc. (for 125 months)
- Exonet B.V. (for 115 months)
- Leibniz Rechenzentrum (for 109 months)
- Ministère de l’Europe et des Affaires Étrangères (for 93 months)
- Dinahosting SL (for 80 months)
- Upsun Formerly Platform.sh (for 75 months)
- Moxa Inc. (for 69 months)
- sipgate GmbH (for 66 months)
- OVH US LLC (for 64 months)
- Tilburg University (for 64 months)
- GSI Helmholtzzentrum für Schwerionenforschung GmbH (for 56 months)
- THINline s.r.o. (for 28 months)
- Copenhagen Airports A/S (for 22 months)
- Conseil Départemental de l’Isère (for 8 months)
- CEOS GmbH
Bronze sponsors:
- Seznam.cz, a.s. (for 146 months)
- Evolix (for 145 months)
- Linuxhotel GmbH (for 143 months)
- Intevation GmbH (for 142 months)
- WAAYS (for 141 months)
- Megaspace Internet Services GmbH (for 140 months)
- Greenbone AG (for 139 months)
- NUMLOG (for 139 months)
- WinGo AG (for 138 months)
- Entr’ouvert (for 130 months)
- Adfinis AG (for 127 months)
- Plat’Home (for 124 months)
- Laboratoire LEGI - UMR 5519 / CNRS (for 122 months)
- Tesorion (for 122 months)
- Bearstech (for 114 months)
- LiHAS (for 114 months)
- Catalyst IT Ltd (for 108 months)
- Demarcq SAS (for 102 months)
- Université Grenoble Alpes (for 88 months)
- TouchWeb SAS (for 80 months)
- SPiN AG (for 77 months)
- CoreFiling (for 73 months)
- Observatoire des Sciences de l’Univers de Grenoble (for 65 months)
- Tem Innovations GmbH (for 59 months)
- WordFinder.pro (for 59 months)
- CNRS DT INSU Résif (for 58 months)
- Soliton Systems K.K. (for 53 months)
- Alter Way (for 51 months)
- SOBIS Software GmbH (for 25 months)
- Tuxera Inc. (for 17 months)
- OPM-OP AS (for 8 months)
- LU-CIX Management G.I.E.

Russ Allbery: Long delayed haul

Sun, 23 Aug 2026 21:29:00 +0000

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.

Sergio Cipriano: Two Debian Days in one week

Sun, 23 Aug 2026 18:22:15 +0000

Two Debian Days in one week

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!

Colin Watson: GSS-API support split out from main Debian OpenSSH packages

Sun, 23 Aug 2026 17:16:11 +0000

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.

Iustin Pop: Another optimistic take on AI

Sun, 23 Aug 2026 16:19:40 +0000

Disclaimers

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.

Wouter Verhelst: Programming and GR 2026 002

Sun, 23 Aug 2026 14:02:13 +0000

Programming language generations

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.

Aigars Mahinovs: Optimistic take on AI

Sat, 22 Aug 2026 19:30:00 +0000

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

Questions? Feedback? Just ask here or here.

Russell Coker: Links August 2026

Sat, 22 Aug 2026 16:05:00 +0000

This YouTube video about the Cashier Girl Meme is interesting in the context of AI systems that generate images of people and can communicate with people, hotter than any real human is an achievable goal [1].

Stand Up Maths has an interesting Youtube video about LLMs solving maths problems which I highly recommend watching (it does not require any real knowledge of maths), I think this opens the door to attacks on well established cryptologic systems [2].

Adam Conover made an insightful YouTube video about how and why Hollywood is now unable to make good sitcoms and why this is bad for society [3].

Sky Croeser wrote an interesting and insightful blog post about topics covered at the “Digital and sexual citizenship in an age of social media bans: Interrogating the rights of children and young people conference” [4].

Zane wrote a very informative blog post about reverse engineering a trojaned Android projector with Claude Code [5]. We need much better security on home networks to break the business model for this sort of thing.

Renee Stonebraker’s article “Puritans Wouldn’t Eat Pussy, So They Invented the Western” has a lot of interesting information about early days of colonising the US, and not much about eating pussy [6].

IFLScience has an interesting article about brinicles, icicles of brine that form under sea ice [7].

Nautilus has an interesting article about the Silurian Hypothesis [8].

The Conversation has an intersting article about the pros and cons of no-till farming [9].

Cold War is a 365tomorrows story about bio-warfare which raises several disturbing possibilities we need to guard against [10].

Scott Santens wrote an insightful article describing how a land value tax would reduce rent and solve the housing shortages [11].

Positive News has an interesting article about using OnlyFans to teach people about climate change [12].

The Conversation has an interesting article about cultural safety in healthcare, sounds good, and while we are at it lets deal with sexism [13].

Doctoreww has an interesting web page about ways of displaying different strings to humans and machines, this could result in you running a different command to what you thought you copied from a web site or defeating tools designed to block hostile content [14].

Cory Doctorow wrote an insightful article “Commentary Hell is Other People” about the way rich people want to use AI to replace all people [15]. Also psychologists who help rich people accept being greedy are worthy of a Luigi

The research article “Worship me at the office altar: Why narcissistic leaders resist remote work” is interesting, yet another reason to get rid of narcissistic executives [16].

Renew Economy has an interesting article about clean up costs for mining (which is usually left for the government to pay) and how this could impact renewable energy production facilities [17].

Elvira Bary wrote an insightful article on the Russian financial collapse that is happening now [18].

The Guardian has an interesting article about Afro-American women who travel to South Korea for healthcare because of problems with racism and sexism in American hospitals [19].

The Conversation has an interesting article about the potential for disabled people to be more productive in space than non-disabled people [20].

Krebs has an interesting article about LG banning residential proxy code from apps after the LG store was found to have such code in 42% of it’s apps [21].

Robert B Shpiner wrote an insightful article for The Guardian about the death of democracy in the US [22].

[1] https://www.youtube.com/watch?v=TCn7bA1eg_0
[2] https://www.youtube.com/watch?v=ZJ8KThKAfbs
[3] https://www.youtube.com/watch?v=gpSghW4J3ws
[4] https://tinyurl.com/28b6jclu
[5] https://zanestjohn.com/blog/reing-with-claude-code
[6] https://tinyurl.com/2y2b6a58
[7] https://tinyurl.com/2awjppn5
[8] https://tinyurl.com/2y89gftt
[9] https://tinyurl.com/2b27vo8o
[10] https://365tomorrows.com/2024/03/27/cold-war-2/
[11] https://tinyurl.com/2aqkn4z6
[12] https://tinyurl.com/2dy5vy8g
[13] https://tinyurl.com/25rld7v3
[14] https://doctoreww.github.io/EvilFontTool/
[15] https://tinyurl.com/2c2guu89
[16] https://tinyurl.com/27kq4qqu
[17] https://tinyurl.com/2blp477w
[18] https://tinyurl.com/27aybgge
[19] https://tinyurl.com/29covbrp
[20] https://tinyurl.com/27qdj6co
[21] https://tinyurl.com/22pxub8v
[22] https://tinyurl.com/25zf4hnp

Dirk Eddelbuettel: RProtoBuf 0.4.28 on CRAN: Small Updates

Sat, 22 Aug 2026 12:24:00 +0000

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

Thanks to my CRANberries, there is a diff to the previous release. The RProtoBuf page has copies of the (older) package vignette, the ‘quick’ overview vignette, and the pre-print of our JSS paper. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

Emmanuel Kasper: Create a development VM using Debian cloud images

Sat, 22 Aug 2026 08:39:33 +0000

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 virsh virt-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.

Download the debian cloud image:

$ wget https://cloud.debian.org/images/cloud/trixie/daily/latest/debian-13-generic-amd64-daily.qcow2

Add the disk image as a libvirt volume:

$ export SIZE=$(stat -Lc%s debian-13-generic-amd64-daily.qcow2)
$ virsh vol-create-as default dev-vm $SIZE --format qcow2
$ virsh vol-upload --pool default dev-vm debian-13-generic-amd64-daily.qcow2

Create a VM with the root password set to “root”:

$ echo root > password.txt
$ virt-install --name dev-vm --memory 4096 --noreboot \
	--os-variant detect=on,name=linux2024 \
	--disk vol=default/dev-vm \
	--import \
	--boot uefi \
	--cloud-init root-password-file=password.txt,clouduser-ssh-key=$HOME/.ssh/.ssh/id_ed25519,disable=on

At the point libvirt will create a VM (a domain in libvirt parlance) and start it.

Starting install...
Allocating 'virtinst-ns9oa7_i-cloudinit.iso'                | 368 kB  00:00     
Transferring 'virtinst-ns9oa7_i-cloudinit.iso'              | 368 kB  00:00     
Creating domain...                                          |         00:00     
Connected to domain 'dev-vm'

BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0)

Booting `Debian GNU/Linux'

Loading Linux 6.12.101+deb13-amd64 ...

Loading initial ramdisk ...

EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: UEFI Secure Boot is enabled.
[    0.000000] Linux version 6.12.101+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Debian 6.12.101-1 (2026-08-05)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.12.101+deb13-amd64 root=PARTUUID=2b4578e2-9d2e-4b32-b6a4-b5b2ca607ef6 ro console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0
...

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.

Emmanuel Kasper: Moving software development to separate VM to reduce credential scavenging

Fri, 21 Aug 2026 11:09:18 +0000

Rationale:

I was remembered via https://unit42.paloaltonetworks.com/chaindrop-npm-worm-analysis/ (linked from https://anarc.at/blog/2026-08-18-people-vs-ai-overlords/) of the risk of downloading untrusted packages in a dev environment. If you read the blog post above you will see that it is way to easy do have a random npm, or even python package in a dev environment scavenge your long running credentials from your workstation, either on disk, or reading from memory !

I will thus move to the following set up:

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 !

Reproducible Builds (diffoscope): diffoscope 329 released

Fri, 21 Aug 2026 00:00:00 +0000

The diffoscope maintainers are pleased to announce the release of diffoscope version 329. This version includes the following changes:

[ Jochen Sprickerhof ]
* Handle missing cpio and qemu-img in autopkgtests. (Closes: #1144617)

You find out more by visiting the project homepage.

Ian Jackson: Open Letter to the Wikimedia Foundation Board

Thu, 20 Aug 2026 20:58:51 +0000

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.

Dr Ian Jackson
Cambridge, UK
20th August 2026

comments

Jonathan Dowland: Bauer X4 inline skates

Thu, 20 Aug 2026 09:54:51 +0000

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.

Sergio Cipriano: My experience at DebConf 2026 in Santa Fé

Wed, 19 Aug 2026 23:02:02 +0000

My experience at DebConf 2026 in Santa Fé

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.

I also helped with de Golang Sprint. I worked on a few packages and experimented with the dak API to generate a list of packages that needed manual action.

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.

I'll take some time to read the Debian Installer internals documentation. I was not familiar with udebs or with the fact that the Debian Installer uses debconf under the hood.

Wrap up

It was an amazing event. Unfortunatly, a lot of people I know were not able to attend for different reasons, and they were missed.

There were many other things that I enjoyed during this trip. Here are a few more highlights:

World Cup matches
A day trip around Santa Fé
The Cheese & Wine party
Empanadas!!

Dirk Eddelbuettel: RcppMsgPack 0.2.5 on CRAN: Minor Maintenance

Wed, 19 Aug 2026 20:07:00 +0000

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

Courtesy of my CRANberries, there is also a diffstat report for this release. For questions, suggestions, or issues please use the issue tracker at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

Antoine Beaupré: The people vs the AI overlords

Wed, 19 Aug 2026 14:14:42 +0000

Also in this series:

The Four Horsemen of the LLM Apocalypse

A more nuanced view of LLMs

In a post to oss-security, my (Debian) co-developer Russ Allbery stated that "open source software [OSS] is coming face to face with a motivation crisis that has been building for a long time". His point is essentially that large language models (LLMs¹) are making the existing OSS community crisis worse. For him, it's the flood of code reviews, but he argues that varies according to people's desires, for others it's security issues and so on.

I think Russ is right, but I would argue there's something much bigger than our open communities going on here, and it's about the entire field of computing. This pressure is on all of us, regardless of whether we work on open source software or not.

How people use models

People using LLMs in their workflow have radically changed how programming works, even for people who claim to avoid vibe-coding. And I'm sorry to single out one poor maintainer here: it's not you, Brian, you're just one example among many. But this is typical use of those models nowadays:

Once it’s done, I’ll use /code-review and let Claude spawn sub-agents to do a full review of the new code. This usually finds some problems, even problems that the “main” Claude instance didn’t find during its validation. I usually keep running /code-review again and again after finding and fixing issues, until there aren’t any left.

Think about what that means for a minute. This is automation built to fire up dozens of agents crunching at a problem for minutes if not hours of GPU compute time, in parallel. This is essentially a couple of shelves in a datacenter rack, totally maxed out on power and cooling, abstracted behind a cute little /code-review command.

The author, here, is rightly concerned that "Anthropic could pull the rug out and require API pricing", which is perhaps a code word for "charging something closer to actual costs". Brian also pays lip service to environmental and societal costs but those are largely abstracted away, so let's keep that conversation aside here as well, as we have discussed it before anyways.

But clearly, this way of working has an (externalized) cost, to say the least.

Paying for non-free tools

For decades my work has been focused on free and open source software. I've long stopped using proprietary operating systems like Windows or Mac, and even before that switch, I was mostly using free software on those platforms, partly out of principle, but also because I was too poor. So the tools of my trade are free, and I build free tools with them.

It feels like we're going backwards: when I was in school, a millennia ago, my classmates didn't have access to a compiler and were wondering how they would scrape the money to buy a compiler like Borland's or Microsoft's. I had a compiler built into my operating system (FreeBSD at the time), so that wasn't a problem for me. For them, it was a significant expense, but at least those expenses (or more shady sourcing of programs) were a one-shot deal.

Fast forward 30 years, and software is rented: you pay monthly for Adobe's Photoshop and Microsoft's office suite just like you pay for Netflix, Disney+ or Spotify². And now you need to add dozens (if not hundreds of dollars) of monthly credits to access LLMs on top of that.

So, now we have to pay to get anything done? This is peak enshitification of our job: first they steal our work to train their models, and then they sell it back to us at a profit.

Attacking the engineers

AI is coming for our jobs, as engineers, if not everyone, according to the narrative. For a while now, our job market has deteriorated: less jobs, for less pay. Lots of skilled engineers looking for work and finding crap jobs then still looking while working.

This is not by accident.³ We engineers have a lot of power, it is not organized, but that's just a couple of unions away (easy!). Tech overlords know this, so they are attacking our profession, directly, by forcing us to train and use models that they can control.

Even in environments where programmers are not forced to use LLMs, the mere pressure of other people's LLM-generated work is huge. One can be forced to review LLM outputs, or just peer pressured you into producing more.

We're now supposed to accelerate delivery, because models can presumably do things so much better and faster. With supply chain security becoming such a large vector that we now have worms crawling around developers accounts on NPM, increasing the delivery cadence seems like a really bad idea.⁴

The LLM hype is part of the larger wave of cyberwar against workers, against water, against the Earth, against all the people. This is not a matter of individually "adapting to the reality" or personal choice, but a political, social, hard problem we need to address collectively.

I again prefer the term LLM to "AI" because models do not possess intelligence. I did use it in the title because click baiting is apparently important, but I stopped short of calling this one "Rage Against the Machines" because that would be the title of every blog post I have ever made.↩
Yes, I know that Visual Studio is kind of free now, but I wouldn't be surprised if they turn that into a rental as well, because why not.↩
Beyond sabotaging the job market, Sam Altman event wants to sell "intelligence as a utility" something that is just a really bad idea but especially shows how megalomaniac those people are.↩
This brings back memories of another era, walking us back decades in terms of computer security.↩

Thomas Lange: LLM usage in Debian

Tue, 18 Aug 2026 13:41:45 +0000

After spending many hours on reading all the proposals and discussions the best choice for me is NOTA (None of the above).

We do not need to create new rules for LLM usage, we already have our DFSG and our social contract.

Keep it simple, stupid. Avoid more rules!

Andy Simpkins: My first go at tracking down a kernel bug…

Tue, 18 Aug 2026 10:50:43 +0000

A couple of weekends back, I upgraded my home sever. It failed to restart after running apt dist-upgrade

The only update that was performed was to the kernel, it went from 6.12.88+deb13-amd64 to 6.12.100+deb13-amd64. I had previously performed an apt-get upgrade, and rebooted the machine, so I was pretty sure that this was to blame. This blog entry (is a late) attempt to document how I went about finding a fix for this issue so that next time I don’t need as much hand holding as I did this time around :-)

(1)
Having my machine not boot following an upgrade is pretty rare, but has happened before. Usually it is because I have done something wrong so as always confirming I haven’t broken something by accident is always my first step…

I plugged in a keyboard an monitor to the machine and watched it boot. Being a server this takes a long time (I guess because at this stage of system initialisation we want to test things sequentially)

Watching the system boot I see the usual BIOS/UEFI stages for this machine, followed by the grub menu and the the local screen showed:

            Loading Linux 6.12.100+deb13-amd64 ...
            Loading initial ramdisk ...

Nothing else. That was it. OK that looks like I have a broken system all right, and at very early stage of the boot process process.

(2)
Breaking into the grub menu and removing the quiet option yields a little more information (but not much):

            Loading Linux 6.12.100+deb13-amd64 …
            Loading initial ramdisk ...
            

            	EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID d
            	evice path
            		EFI stub: Measured initrd data into PCR 9

and nothing else.

(3) Initial debugging

Confirmed that I could still boot the machine with the old kernel 6.12.88+deb13-amd64 (During boot select Advanced options from the grub menu followed by the kernel image wanted)
- Yes – the system starts happily with the previous kernel
Checked that /boot had enough space
- Yes – plenty of space
Is anyone else reporting this problem?
- Nothing jumps out on Debian’s bug tracker
- Actually not mush referenced for my search “EFI stub: Measured initrd data into PCR 9 apart” other than the usual rantings to “turn off secure boot” (on this server that currently isn’t turned on – bad me)

(4) Triage

Start looking for where the fault first occurred. At this point I needed help, and given that Sledge was visiting I asked if he would sanity check what I was doing. His initial thoughts were that that /boot had run out of space, but replaying my step (3) with him acting as a ‘rubber duck’ showed that this was something other than PBKAC

Sledge had a quick look, then informed me that between kernel images 6.12.88+deb13 and 6.12.100+deb13 Debian stable has only had shipped .90 .94 .95 and .96 kernels. We could easily try them all:

wget each kernel package then install (dpkg -i) followed by an update-grub, checking that there was sufficient space on disks especially my small /boot partition)
I started with image 6.12.95+deb13 and this worked
6.12.96+deb13 yielded the same lock up on boot as 6.12.100+deb13

OK I now have the first kernel image that doesn’t boot on my system, time to raise a bug…

Up until now I have been walking to my garage where the server is located and standing in front of a rack
with a monitor and keyboard plugged into the machine. However this machine supports IPMI so I spent a little time getting that up and running so that I can continue from the relative comfort of my desk (with lights, a chair and not needing to hold the keyboard with one hand)

Great I can now grab screen shots from the confort of my desk (unfortunatly they are only screen shots not text files, but at least we can seen the early stage of boot, Post, grub menu and then initramfs before system log happens)

(5) Collating information for the initial bug report

Sledge had mentioned my problem in irc/#debain-kernal where iam_tj suggested that we try appending
‘debug earlycon=efifb’ to the kernal command line. This yielded 15 seconds worth of messages before the system locked up the last few messages being (vmlinuz-6.12.96+deb13-amd64):

[ 14.663477] RCU Tasks: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.750474] RCU Tasks Rude: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.838024] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.929752] NR_IRQS: 524544, nr_irqs: 584, preallocated irqs: 16
[ 15.016814] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 15.104011] Console: colour dummy device 80×25
[ 15.191236] printk: legacy console [tty0] enabled
[ 15.278249] printk: legacy bootconsole [efifb0] disabled

Booting the working kernel with the same kernel options yields the SAME messages with slightly differing times, but then continues to login prompt:

 [   14.697466] RCU Tasks: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
 [   14.784936] RCU Tasks Rude: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
 [   14.872067] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
 [   14.964000] NR_IRQS: 524544, nr_irqs: 584, preallocated irqs: 16
 [   15.051482] rcu: srcu_init: Setting srcu_struct sizes based on contention.
 [   15.226079] printk: legacy console [tty0] enabled
 [   15.313751] printk: legacy bootconsole [efifb0] disabled
 [   15.400831] ACPI: Core revision 20240827
 [   15.401415] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
 [   15.401464] APIC: Switch to symmetric I/O mode setup
 
... and so on

iam_tj also suggested adding keep_bootcon – with ‘debug earlycon=efifb keep_bootcon’ on vmlinuz-6.12.96+deb13-amd64:
We get a LOT further – and we see a crash / trace-back:

[ 34.285342] BUG: kernel NULL pointer dereference, address: 0000000000000000

I raised bug #1143721 and followed it up with screen captures of the boot sequence (captured from the IPMI client) and files containing the output of dmidecode, lscpu and lspci to kive the kernel team as much information as possible:

[6.12.96+deb13-amd64 debug earlycon=efifb keep_bootcon.tar.gz (application/gzip, attachment)]

[dmidecode.txt (text/plain, attachment)]

[lscpu.txt (text/plain, attachment)]

[lspci.txt (text/plain, attachment)]

(6) Tracking down the bug Git Bisect

The problem with this type of bug is that it is hardware (class) specific, whilst the kernel doesn’t boot on my system, it clearly has worked on machines used by the kernel team, the Debian test and build infrastructure, (otherwise this kernel would never have been released) and everyone else who has upgraded to the newer kernel before I did (otherwise we would be drowning in fails to boot bug reports). Carnil’s excellent response to my bug: Message #15 (and help in IRC) provided me with a detailed step by step guide in how to track down the individual git commit that fails on my system. I had already (with Sledge’s suggestion) made a clone of the stable branch, but was struggling to follow the steps in the Debian Linux Kernel Handbook to re-build a duplicate kernel because I didn’t understand how to obtain the same configuration that Debian used to build the kernel; Carnil’s email provided me the missing steps (Highlighted).

git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.12.95
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_def
test 6.12.96 to ensure this is "bad"
git checkout v6.12.96
make my_defconfig
make -j $(nproc) bindeb-pkg
… install the resulting .deb package and confirm it fails to boot and triggers the NULL pointer dereference.

Right I can now start to Bisect the problem:

git bisect start
git bisect good v6.12.95
git bisect bad v6.12.96

Rather than use the half step point’s git bisect suggested I was advised in irc to jump straight to the a given commit that from the git log was suspected as the culprit:

git checkout 977855894bca4b87afa50d21e3f3e85a5a0e901f
build and install….
fails…
git bisect bad

git checkout 977855894bca4b87afa50d21e3f3e85a5a0e901f~1 ## ~1 is the commit beforehand
build and install….
fails…
git bisect good

The entire test tree can shown with git bisect log and this was submitted as an email to the bug report, we have found our smoking gun :-)

Finally I would like to thank Carnil, Iam_tj for their time patience and fantastic support in guiding me through finding this regression. Right now kernel bugs are coming in thick and fast with a lot of AI assisted bug hunting, the increased numbers of bugs mean that the kernel team are especially busy. Hopefully our paths will cross and I’ll be able to buy you some beers (or whatever) soon. thank you. Sledge also deserves thanks for putting up with me and pointing me in the right direction (as ever). Lucky for me that he lives nearby so I can provide beers on a regular basis :-)

John Goerzen: AI in Debian: The Vote, Proposals, and Nuance

Tue, 18 Aug 2026 01:39:54 +0000

Let me start with a hypothesis:

For human developers, using coding LLMs magnifies their difference in skill levels.

I am one that rarely thinks things are always black and white. Back in March, I wrote Artifial Intelligence: Shades of Gray. Since then, I’ve had more of a chance to experiment with LLMs myself. I also happen to work for an employer that is taking a very pragmatic approach to LLMs: teams and individuals use it as they see fit, but if they are causing considerable expense, they have to justify it.

In various settings, I have seen the egregious examples of AI slop we all know about. As I wrote in March, “I have seen it both waste more time than it saves, and save a ton of time.”

I have come to see that, as a tool, it is most valuable when it is running under the supervision of an experienced engineer. It is at its worst when it has no such supervision; the “vibe coding” and other low-quality slop we see.

A coding agent is like a junior developer or research assistant. When properly supervised, they help projects move along more quickly by letting a senior developer focus on the more difficult, less mundane aspects of the project. But one couldn’t expect a junior developer to consistently deliver high-quality code and architecture on their own.

Let’s put a pin in this idea and look at the story in Debian.

LLM use in Debian

There is a vote happening in Debian around the use of LLMs. In typical Debian fashion, there are 8 options to choose from, many of them similar. Most of these proposals acknowledge there are different types of tasks done in Debian, but the proposals don’t differentiate between them well. Let me do so here. These are some of the LLM-relevant tasks people in Debian perform:

Packaging upstream software for Debian (by far the largest task)
Writing Debian-specific code (eg, apt or the Debian installer)
Maintaining Debian infrastructure (build systems, for instance)
Writing documentation and translations

I’m going to focus my remarks here on packaging upstream software for Debian, since this is by far the most time-consuming developer task project-wide.

It matters to our users that we get this right, and packaging quality is one of the things that sets Debian apart from other distros. Packaging things for Debian requires knowledge of some specific tools, such as debhelper, that aren’t widely used anywhere else. In most cases, it is fairly rote time-consuming work. In other words, by its design, it requires people with senior-level skills to do grunt work.

I can’t overstate how massive a burden this grunt work is. I maintain some packages for Go and Rust. By Debian policy, all of those packages’ dependencies must also exist as Debian packages, and be used to build against. When upstream adopts a newer version of some library, it can unleash cascading dependencies that can take hours to sort out. Worse, the Rust team and the Go team use entirely different ways of managing packages (Go uses one Git repo per package, while Rust has a monorepo with specialized scripts to import Cargo packages and generate Debian ones). On top of that, we can’t just modify things like usual; we have to use quilt. And on top of that, I’m also a backports maintainer, so all the work (and usually even more) has to be done there also.

Now let’s pull on that pin from the earlier conversation. This is exactly the kind of scenario that a well-supervised coding LLM is most effective in. I could see a seasoned developer saving hours, maybe even days, by turning over the mundane tasks of managing trees of cascading dependencies over to a coding tool — and verifying and directing the process. (Yes, I have been using em-dashes for years; LLMs have copied people like me, not the other way around! This post was not written with any AI assistance.)

Actually, this is almost a dream scenario for a coding assistant. The result is time-consuming to formulate but easy to review, which is the opposite of the way these things often go.

I can assure you with 100% certainty that humans aren’t adding a lot of value in this process. It would be wrong to believe that a human is carefully reading every line of code in dozens of updated or new library packages. The problem set is too big, the time too short, and the code too varied and complex.

Coding agents seem to be most effective when there are strong test suites that they can test changes against. Debian builds, especially of modern packages, tend to have this property. Many packages have test suites that are run during build. And, if the package builds in an isolated environment (and especially if its downstream dependencies do also), then there is a decent chance that it’s fairly correct. Maybe needing some manual tweaking here and there, but generally a successful build is a reasonable indicator.

You can argue that it would make more sense for Debian to just include dependencies in source packages, along with some version information to support security rebuilds, and I’d tend to agree with you. But we are where we are. This would be one of the more significant leaps forward in developer productivity, but it complicates things like copyright reviews.

Where are LLMs run? What is the environmental impact?

Most of the proposals seem to make the assumption that LLMs must always run in some large, hosted datacenter. As I noted in my March article, I have had credible results on even an older GPU running on solar power.

That said, it is undeniable that LLMs are fueling a datacenter boom, and this in turn is producing a significant new demand for resources. Most notably for the global scale: electricity, which is sometimes generated using carbon-emitting technologies.

Bill McKibben, who has been a leading voice in the fight against climate change since the 1980s, has made some interesting points recently: he’s noted that solar power is the fastest kind of generation we can build, and a number of large AI companies are investing heavily in solar, even to the point of fully offsetting new datacenter’s needs. On the other hand, he’s also noted that some companies are buying inefficient and dirty gas turbines. It is decidedly a mixed bag. The heavy investment in solar can have knock-on positive effects for infrastructure. Obviously, not every picture here is rosy. This analysis doesn’t touch on the real land and water use situation, either.

On the other hand, if an LLM allows me to do in an hour what I would have done in a day, that’s a day of not heating or cooling the work area — generally not sustaining a human for the purpose of writing code for Debian. HVAC energy consumption dwarfs my GPU, and I’d imagine probably also the slice of LLM energy used.

Holistically, I would have to conclude the picture is mixed. It is possible to use LLMs in a pretty green way, and also in a pretty dirty way.

Assuming Conditions Never Change

A flaw in most of these proposals is they assume that the conditions at this present moment will always hold. In fact, that the conditions at the present moment will not continue is something both AI cheerleaders and AI skeptics agree on.

For instance:

Ed Zitron has done a ton of research into the financing side of AI, and has concluded that the current model is unsustainable and headed for a significant bubble burst. I’m not positioned to personally evaluate those claims, but if that happens, what is the result? Perhaps it is a steeply increasing cost of inference for the frontier models, slower pace of training/evolution for them, etc.

In a recent episode of Oxide and Friends, Simon Willison discussed the open weight models that are now available. They have been making remarkable strides in efficiency and capabilities, to the point where $50,000 of hardware can now run high-end open weight models with capabilities that are at least in the same ballpark as the American frontier models. This puts running high-end models locally squarely within reach of universities and small- to medium-sized businesses, with power requirements that can be met with standard commercial solar and wind installations.

The lack of nuance in the more restrictive proposals is particularly concerning. Proposal A doesn’t allow “the use or assitance of… LLMs”. So it bans my solar-powered GPU. It bans using LLMs to find security issues. It bans all sorts of things that don’t seem to be ban-worthy, alongside the things that do. And it codifies it in the very hard-to-change social contract.

That proposal, and some like it, seem to imply that all LLM output is bad. I grant you that AI slop is a real and legitimate concern, and many Open Source projects have to deal with it. On the other hand, we have all seen first-hand how the security of the Linux kernel has benefited dramatically from AI analysis. It is certain that black hats are using these tools. If we refuse to use modern security tools, our security will be compromised (and what is the environmental and social impact of THAT?)

I find the statement “Generative AI is characterized by producing output of a nature that would ordinarily be produced and consumed by humans” to be particularly interesting. The same was once said of compilers.

The Real Concerns

You might think from reading this that I am some AI cheerleader. I’m not. I share the ethics of the FLOSS movement, and have for decades. I abhor the power and lack of ethics that many big names in the field are running with at the moment. I’ve had to put up Anubis on this blog, for instance.

I have personally experienced the effects of AI slop, especially at review time. This is a real problem, though I don’t think the more draconian policies are likely to help (the looser “you must disclose” stand a fighting chance, but I’m not sure they would help, either.) Done poorly, AI threatens developer burnout by overwhelming them with poor code and verbose but useless explanations. Done well, AI can help prevent developer burnout by automating tedious and low-value tasks.

Shouldn’t our goal be that humans submit work to Debian, using tools they prefer, and take responsibility for it? Does it matter if someone uses ed, vim, emacs, or vscode? If they use LSP or just run gcc manually? I’d say we benefit from the diversity. Wouldn’t we be better off to benefit from the diversity here, and judge work as we always have: on its merits, not what tools were used to create it?

Fundamentally, a GR is a long and arduous process. It’s not easy to reverse later. Amending the Social Contract is even longer and more arduous (I should know; I may have been the first one to try). The LLM landscape is fast-moving. None of us can really predict where it will be in a year. Will the current market leading companies even still exist? Will it be at all credible to refuse to use AI-assisted security tools? What is the most effective way to deal with AI slop? What level of utility will we be able to achieve with models run locally?

Some of these proposals would make sense if drafted in some way short of a GR, which would allow more maneuverability as the landscape changes.

Brief analysis of the options

Considering the proposals:

Proposal A: seeks to amend the social contract, which I am opposed to for reasons already laid out above. It names some real concerns about AI that I agree with, but implies that all LLM uses and models are guilty of the problems, which is not the case with all of the claims. It also sets us behind the curve on security and stability by forbidding the use or assistance of those tools, even if run by others. It requires us to ignore reports of actual security bugs, or correct fixes, if those reports were generated with the assistance of an LLM, which I find to be absolutely untenable.
Proposal B: This is the “AI with accountability” approach. It notes the real concerns with LLMs without painting with an overbroad brush. It strikes me as level-headed and sensible.
Proposal C: It paints with an over-broad brush and makes some non-binding requests. Then it winds up largely like proposal B, though while it is worded more strongly, has fewer binding requirements (for instance, it lacks proposal B’s prohibition on transmitting sensitive information to untrusted providers)
Proposal D: Seems broadly similar to proposal B, an “AI with accountability” approach. I’m not really clear why we need both.
Proposal E: Largely the status quo. It is like proposals B and D in that it says humans are accountable for their contributions. It encourages disclosure of LLM use, but does not mandate it. Like proposal B, it prohibits disclosing sensitive information to third-party AI services. Note that both proposals B and D have an appropriate nuance: a local model is fine, a third-party one is not.
Proposal F: This seems really similar to proposal E. I’m not sure why we have these two.
Proposal G: Disallows “the output of generative AI as direct contributions to Debian.” This is something of a weakened proposal A; it doesn’t seek to amend the social contract, nor does it ban all use; it simply bans the use as a direct contribution.
Proposal H: Ban due to climate impacts. “How is this even an argument” is disrespectful to reasoned conversation. I have already noted that LLMs can be and are used in ways that are not climate-harming. It explicitly contains no binding requirements at all, and is effectively a rant. While I agree with the sentiment that climate change is an urgent problem, and that some LLMs are exacerbating it, I disagree with that all LLM usage does so and therefore disagree with the conclusion.

In favor of nuance

I find that black-and-white thinking is almost always something to be avoided. I see it too often. I see it in politics, I see it in our software, I see it in discussions around AI. Are there deeply unethical things happening in AI? Absolutely. Are they doing some impressive things? Also yes.

We have accepted this nuance in other areas. For instance, almost all the hardware Debian runs on has closed-source hardware, and has components manufactured or assembled in countries with some of the worst human rights records on the planet. I’m not saying this is a great state of affairs. It is something we should speak up about and act upon. But the worse state of affairs would be “no Debian because the hardware is impure”.

Bits from Debian: Debian turns 33!

Sun, 16 Aug 2026 13:00:00 +0000

It has now been thirty-three years since the Debian project was announced to the world by Ian Murdock, on August 16, 1993. This anniversary is an opportunity to reaffirm the goals, characteristics, and qualities of the Debian project: it’s an association of individuals who have made common cause to create a free operating system. Our distribution is characterized by a commitment to software freedom, as enshrined in the Debian Social Contract and the Debian Free Software Guidelines. It focuses on security and stability. This stability is crucial to Debian position in the free software ecosystem.

With our users as our priority, Debian makes special efforts regarding accessibility with Debian-Accessibility and diversity with our Outreach Programs.

Debian Day is a great opportunity to get together, whether for a local meetup, or simply to grab a coffee with other members of the Debian community. Check out the Debian Day wiki to see if there is a celebration near you. And if there isn't, maybe you can organize it next year!

Today is also an opportunity for you to start or resume your contributions to Debian. For example, you can install the how-can-i-help package and see if there is a bug in any of the software that you use that you can help to fix, contribute small tips on how to install Debian on your machines to our wiki pages, or put a Debian live image in an USB memory and give it to some person near you, who still didn't discover Debian.

Thanks to everybody who has contributed to develop our beloved operating system in these 33 years, and Happy birthday Debian!

Vasudev Kamath: Releasing debvulns-exporter and debvulns CLI 0.2.2

Sun, 16 Aug 2026 11:30:00 +0000

I made another minor release with several enhancements: handling non-Debian origin vulnerabilities, improving data caching, and sharing the cache between the debvulns CLI and the exporter. Additionally, there are a few improvements on the dashboard front. Here is a breakdown of what changed.

Handling Vulnerabilities in Non-Debian Origin Packages

During the previous release, I noticed that the grafana package—which is not in Debian and was installed via an upstream repository—was reported as vulnerable with multiple issues. Looking into why this happened, I found that all the CVEs reported in the dashboard were indeed listed on security-tracker.debian.org, but without a fixed version or status description. The logic assumed no fix was available and marked the package as vulnerable on the dashboard.

How Did I Solve This?

Google maintains a distributed vulnerability database for open-source projects called osv.dev. I checked the generic vulnerability data for those CVEs on OSV (unbound to any specific distribution) and found that the issues were already fixed in the upstream version I was running. What I needed was a way to differentiate native Debian packages from non-Debian packages, which corresponds to the Origin field in APT metadata.

Pitfall

The AI-generated code initially attempted to differentiate package origin using apt_pkg.PackageRecords and its origin field. However, many native Debian packages were incorrectly flagged as non-Debian. On closer inspection, when an upgrade is available for a package, the installed version's origin field can be unset. I had to resolve this by detecting available upgrades and inspecting the candidate version's origin instead, which was implemented in this patch. This solution was proudly crafted by me ;-) (partly because I ran out of API limits and had to wait 6 hours for the next reset).

Caching OSV Data

Initially, the AI implemented the exporter to re-download the entire OSV dataset on every run, which was unnecessary. Since vulnerability data does not change rapidly once published, caching it on disk for longer than the standard 24-hour Debian/EPSS cache makes sense. OSV vulnerability data is now cached for 7 days before a refresh is triggered.

All cache expiration thresholds remain configurable via CLI flags.

Catch

One caveat with this approach: I have not yet verified whether every upstream CVE is tracked on security-tracker.debian.org. In the case of grafana, the entries existed. This feature operates on the assumption that security-tracker.debian.org indexes CVE metadata regardless of whether the package is native to Debian. I plan to re-evaluate this and add fallback handling if that assumption fails.

Unified Cache Directory for CLI and Exporter

Another issue was cache segregation: the debvulns CLI utility defaulted to /var/cache/debvulns, while the Prometheus exporter used /var/cache/debvulns-exporter. While harmless when running only one tool, installing both led to duplicated cache storage and redundant network requests. Since the core evaluation logic is identical across both tools, they now share a unified cache directory to eliminate duplicate downloads.

Dashboard Changes

During the initial dashboard rollout, my test environment (my laptop alongside Debian 11 and Debian 12 VMs) reported a high aggregated vulnerability count. It was not immediately obvious whether these were distinct vulnerabilities or the same CVEs replicated across all three machines. This mirrors common questions raised during vulnerability reviews:

How many unique vulnerabilities are present across the fleet?
Which unique packages are affected?

The dashboard has been redesigned to surface unique vulnerability counts alongside affected package lists. The updated dashboard is shown below:

What's Next?

A few planned items remain to make debvulns a comprehensive vulnerability reporting toolkit for Debian systems:

Kernel Vulnerability Handling: Currently, installing a patched kernel marks the vulnerability as resolved, even if the system has not rebooted into it. The system remains exposed while the vulnerable kernel is executing in memory. Factoring in running kernel versions is crucial.
Reboot and Service Restart Tracking: Similar to kernel upgrades requiring a reboot, userland library and binary fixes require running services to be restarted. This is typically detected via needrestart. Integrating this behavior directly into debvulns will provide complete visibility in a single dashboard metric.
Debian Packaging: Once the above features are stable, the final step is packaging debvulns for Debian so it can be installed directly from the archive.

Until then, happy hacking.

Benjamin Mako Hill: Sad Story

Sun, 16 Aug 2026 07:01:10 +0000

Not a screenshot of despair. But only because it’s not a screenshot.

Sven Hoexter: FrOSCon 2026: TLS Talk

Sat, 15 Aug 2026 18:02:03 +0000

Info: German content only, sorry.

I was pondering for the past three years if I should give some sort of TLS basics talk at FrOSCon. I finally stepped up this year and gave that talk today, with the title "TLS, mTLS, SNI, ECH, CAA, HTTPS, PKI, Zertifikate und ein bisschen PQC". I was too optimistic with my 50 slides, and had to drop the Post Quantum Cryptography part at the end. Still got positive feedback from Zugschlus and others - thanks a lot for that <3 - and was asked for the slides. It's not a piece of art, but maybe it helps to release the LibreOffice odp file as well, so others can use it as a base for other events or corp internal talks. So here is the froscon-tls-2026.pdf and froscon-tls-2026.odp, both released under the CC BY-NC license.

The video is also available at media.ccc.de if you want to watch it.

Thanks to everyone who made FrOSCon happen for the 21th time!

Russell Coker: Hacked by Chinafans

Sat, 15 Aug 2026 09:31:47 +0000

What Happened

On 2026/08/10 at 2:11 am Australian eastern standard time (2026/08/09 16:11 UTC) someone created a post titled “Hacked by Chinafans” on my documents blog [1]. The person in question created an account named “67965e42a3c3” on that site with the email address 67965e42a3c3@google.com associated with it (I tried emailing that address and it bounced).

At 04:28:41am Australian eastern standard time (18:28 UTC) I was sent an email titled “Have you been hacked” by a reader of my blogs who subscribed to the RSS feed of my documents blog (a blog that I never expected anyone to read by RSS). Along the lines of “the wisdom of crowds” should we have “the unexpected observation and problem reporting of crowds”? I appreciate the notification, I might not have noticed until the next time I watched an unusually good movie otherwise.

The account in question was apparently created on 2026-07-21 at 16:43:47 (presumably UTC) even though at the time I believe creating accounts was not permitted. As an aside the timestamp of account creation is stored in the user_registered column of the wp_users table in the database, there doesn’t appear to be a way to access this in a standard WordPress installation other than doing a SQL query.

2026-07-24 15:43:17 status triggers-pending wordpress:all 7.0+dfsg1-1
2026-07-24 15:43:19 upgrade wordpress:all 7.0+dfsg1-1 7.0.2+dfsg1-1

Above are the relevant sections of my dpkg log showing the WordPress versions in use. I was running version 7.0+dfsg1-1 at the time the account was apparently created. I am confident in the accuracy of the dpkg logs and believe that they did not compromise the OS, I am not sure whether they ran hostile SQL code to change fields in the MySQL database so had to consider the possibility that the account creation time could have been set to a deliberately misleading value. I checked backups of the MySQL database stored off-site and found that the account in question was not in the 2026-07-21 backup (which was done before 16:43) but in the 2026-07-22 backup.

The WordPress release history [2] has version 7.0.1 released on 2026-07-09 and version 7.0.2 released on 2026-07-17. So presumably the attacker diffed the code on those releases, found an exploitable bug, and used it to create an account on my blog with admin privs. Then they waited a few weeks to see if I would notice and published a blog post when I didn’t notice.

WordPress Deficiencies

WordPress doesn’t seem to store the version it’s running at the time of operations. So anyone who doesn’t have a suitable external log of versions deployed (such as the dpkg.log file for a Debian managed installation) won’t know for sure which version was running. It supports automatic updates but you can’t be sure that they happened soon after the release.
There is no log of IP addresses used for operations. There are apparently some 3rd party modules to log such things and web pages documenting how to modify the PHP to add it but nothing in the standard distribution.
Software should have a standard distribution with some support for logging of security relevant data. The typical situation is that people don’t plan for logging such things until after they have been attacked so the data should be recorded without users going out of their way to log it.
A log of security relevant data should be stored in a database table with only insert access (no update, delete, or drop).
Ideally a CMS would support different database accounts for different purposes. Someone from an internal network or VPN could talk to an instance of the web server which has a database username and password giving full access. Everyone from outside the trusted range gets an instance of the web server with database access only allowing to read the posts and appearance configuration and to enter comments. If the database didn’t allow the account used for public access to create new admin users or create posts then it would be a lot harder for attackers.
Ideally for everything that stores user account data there would be an easy way of getting a list of users in a plain text format to allow running diff. The design of WordPress has two tables, one for users and one for encoded metadata about users of which one will be the access level. The following SQL command will give a list of all users that aren’t subscribers (everyone above the minimum level of access which is typical for new users) along with their encoded password and access level. This could be used in a monitoring system to alert about new privileged users. The TABLE_PREFIX variable is for the prefix for WordPress tables, which is “wp_” by default but can be any legal value.
```
select $TABLE_PREFIXusers.user_login, $TABLE_PREFIXusers.user_pass, $TABLE_PREFIXusermeta.meta_value from  $TABLE_PREFIXusers join $TABLE_PREFIXusermeta on $TABLE_PREFIXusers.id = $TABLE_PREFIXusermeta.user_id and meta_key='$TABLE_PREFIXcapabilities' and meta_value != 'a:1:{s:10:"subscriber";b:1;}';
```

What Next?

The blog post they created had a couple of links to Telegram which could presumably be used to contact them. If anyone involved in computer security wants a copy of the original post to do so then they can contact me by any of the usual methods.

I am interested in communication with the attacker if they wish, Telegram is not a service I use but I presume that anyone capable of doing this sort of attack is also capable of finding other ways of contacting me.

I have idly considered changing to a static site generator, here is a good list of static site generators [3].

I have also idly considered other platforms for blogging such as Lemmy. I don’t know if Lemmy is better than WordPress for security and updates, but there are plenty of free instances running where it wouldn’t be an issue I have to work on.

15 Years

It’s been 15 years since my blog server was cracked by a trojaned ssh client [4]. At least this time it was only one service that was compromised.

Russell Coker: AMD Video Drivers, LLMs, and Debian Kernels

Sat, 15 Aug 2026 08:09:51 +0000

The AMD GPU Problem

For a while I’ve been having issues with AMD GPUs, video locking up periodically. I blogged about this late last year but I first had noticeable problems early last year [1]. The problems hadn’t only concerned my workstation but also my home server which is also used as a workstation. I’ve recently upgraded my machines to Debian/Testing, my home server has been generally OK but my workstation has been crashing a lot. Every second day when on kernel 7.1.6 and then when on 7.1.7 it crashed at least once a day.

The AMD GPUs I have are “[AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev e5)” in my main desktop workstation, “[AMD/ATI] Lexa [Radeon 540X/550X/630 / RX 640 / E9171 MCM] (rev c1)” in my build server, and “[AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev cf)” in my home server. They aren’t new GPUs, but also aren’t really old and they all support 4K and better resolution.

Chat GPT Was Useful

When I googled the errors I was seeing I found nothing useful. On the suggestion of a friend I tried asking ChatGPT. Generally I don’t recommend asking LLMs about such things, but it can be a last resort as long as you know what you are doing. ChatGPT asked me to run a number of commands to get information for it to make more informed decisions. I know that the output of lspci and similar commands isn’t a risk, but a novice could be tricked into running commands that expose sensitive data.

ChatGPT did give me some useful information, not a solution but an indication that the problem was due to driver bugs.

Upgrading to Experimental

Debian/Experimental is for packages that are expected to have problems and generally aren’t recommended even for the people who usually use Debian/Unstable. It’s commonly used for packages that are needed to develop other packages, EG new libraries that aren’t fully usable but which are needed to package newer versions of applications.

I upgraded my workstation to the Debian/Experimental kernel 7.2~rc7-1~exp1 after having tried every other convenient option. Generally I wouldn’t recommend that anyone run an Experimental kernel without a really good reason, but crashing more than once a day is a fairly good reason. That kernel has now given me over 4 days of uptime on a system that previously wouldn’t last a day. I installed it on my dual-socket build server that has an old AMD GPU in it for test purposes and that also hasn’t crashed since. I installed it on my ML test machine which has an Intel B580 Battlemage GPU with 16G of VRAM and was repeatedly getting a kernel panic related to the GPU a few seconds after boot and now it also works correctly.

It seems that the 7.1.x kernels have bugs in the AMD video drivers and in some part of the code that affects Intel video drivers and that the bugs in question are fixed in the tree that will become 7.2. I would not recommend anyone who has a 7.1.x kernel working fine for them try 7.2 RC kernels at this time, but anyone who has GPU related problems (particularly Intel and AMD GPUs) should definitely test it out.

I also don’t recommend upgrading any system with an AMD GPU to Debian/Testing or Debian/Unstable at this time unless you are also prepared to install an Experimental kernel if it becomes necessary.

There are a several kernel log dumps related to this after the break (which won’t be in RSS feeds). This is mainly for Google so that other people who have such issues can get more useful results out of Google searches than I got.

Future Support Options

Separate from the issue of whether commercial LLMs like ChatGPT can be useful for solving technical problems there is the issue of whether they are desirable. I think that we really don’t want people solving problems in FOSS systems with closed-source LLMs. This leads to loss of privacy, loss of the control users deserve to have over their own systems, and an implied promotion of non-fee software.

I think that the ideal would be to have a cross distribution effort to generate training data for a support LLM system which can then be further trained by each distribution for a greater emphasis on distribution specific issues.

[1] https://etbe.coker.com.au/2025/11/09/amd-video-driver-issues/

Errors on AMD GPUs

2026-08-09T23:03:06.004792+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00024802
2026-08-09T23:03:06.004792+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 42037 thread kscreenloc:cs0 pid 42044
2026-08-09T23:03:06.004793+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-09T23:03:06.004794+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F048002
2026-08-09T23:03:06.004795+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 130) at page 2048, write from 'TC0' (0x54433000) (72)
2026-08-09T23:03:06.008762+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00004802
2026-08-09T23:03:06.008768+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 42037 thread kscreenloc:cs0 pid 42044

2026-08-04T01:13:37.505839+10:00 xev kernel: ------------[ cut here ]------------ 
2026-08-04T01:13:37.505859+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] drm_WARN_ON_ONCE(cur_vblank != vblank->last) 
2026-08-04T01:13:37.505862+10:00 xev kernel: WARNING: CPU: 6 PID: 210534 at drivers/gpu/drm/drm_vblank.c:362 drm_update_vblank_count+0x2f1/0x3c0 [drm] 
2026-08-04T01:13:37.505866+10:00 xev kernel: snd_intel_dspcfg wmi_bmof rc_core snd_intel_sdw_acpi drm_ttm_helper uas realtek snd_usbmidi_lib snd_hda_codec ttm mdio_devres snd_hda_core snd_seq_midi drm_kms_helper usb_storage mc snd_hwdep libphy snd_seq_midi_event intel_uncore snd_pcm_oss i2c_algo_bit serio_raw snd_rawmidi pcspkr snd_mixer_oss i2c_i801 video snd_seq snd_pcm i2c_smbus lpc_ich snd_seq_device mei_me e1000e snd_timer mei snd tpm_infineon soundcore joydev bnx2 wmi button nfsd auth_rpcgss nfs_acl lockd grace sunrpc coretemp br_netfilter bridge stp llc sg ghash_clmulni_intel loop msr i2c_dev drm efi_pstore configfs nfnetlink ip_tables x_tables autofs4 btrfs blake2b_generic dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 md_mod ext4 crc16 mbcache jbd2 crc32c_generic virtio_blk evdev hid_generic usbhid hid sd_mod xhci_pci xhci_hcd ahci ehci_pci ehci_hcd libahci crc32c_intel libata usbcore aesni_intel nvme psmouse scsi_mod gf128mul crypto_simd nvme_core cryptd 
2026-08-04T01:13:37.505879+10:00 xev kernel: nvme_auth scsi_common usb_common efivarfs 
2026-08-04T01:13:37.505880+10:00 xev kernel: CPU: 6 UID: 1008 PID: 210534 Comm: sshd-session Tainted: G D 6.12.88+deb13-amd64 #1 Debian 6.12.88-1 
2026-08-04T01:13:37.505881+10:00 xev kernel: Tainted: [D]=DIE 
2026-08-04T01:13:37.505883+10:00 xev kernel: Hardware name: Hewlett-Packard HP Z640 Workstation/212A, BIOS M60 v02.61 03/23/2023 
2026-08-04T01:13:37.505884+10:00 xev kernel: RIP: 0010:drm_update_vblank_count+0x2f1/0x3c0 [drm] 
2026-08-04T01:13:37.505885+10:00 xev kernel: Code: 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 68 eb 2b cf 48 c7 c1 70 3e cb c0 48 89 da 48 c7 c7 f9 6f cb c0 48 89 c6 e8 af d7 a6 ce <0f> 0b e9 4b fe ff ff 48 8b 4c 24 18 e9 31 fe ff ff 31 f6 48 85 db 
2026-08-04T01:13:37.505887+10:00 xev kernel: RSP: 0000:ffffd3cc8681fca0 EFLAGS: 00010082 
2026-08-04T01:13:37.505888+10:00 xev kernel: RAX: 0000000000000000 RBX: ffff8c6b42b13710 RCX: 0000000000000027 
2026-08-04T01:13:37.505889+10:00 xev kernel: RDX: ffff8c89ef521788 RSI: 0000000000000001 RDI: ffff8c89ef521780 
2026-08-04T01:13:37.505890+10:00 xev kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffffd3cc8681fb20 
2026-08-04T01:13:37.505891+10:00 xev kernel: R10: ffff8c8a6fef3628 R11: 0000000000000003 R12: 0000000000000000 
2026-08-04T01:13:37.505892+10:00 xev kernel: R13: ffff8c6c07853828 R14: 0000000000000003 R15: 0000000000000000 
2026-08-04T01:13:37.505893+10:00 xev kernel: FS: 00007ffaf2fd5880(0000) GS:ffff8c89ef500000(0000) knlGS:0000000000000000 
2026-08-04T01:13:37.505895+10:00 xev kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
2026-08-04T01:13:37.505896+10:00 xev kernel: CR2: 00007fb1718c8000 CR3: 000000074521a004 CR4: 00000000003706f0 
2026-08-04T01:13:37.505897+10:00 xev kernel: Call Trace: 
2026-08-04T01:13:37.505898+10:00 xev kernel:  
2026-08-04T01:13:37.505899+10:00 xev kernel: drm_crtc_accurate_vblank_count+0x41/0xc0 [drm] 
2026-08-04T01:13:37.505900+10:00 xev kernel: dm_pflip_high_irq+0x155/0x330 [amdgpu] 
2026-08-04T01:13:37.505901+10:00 xev kernel: amdgpu_dm_irq_handler+0x85/0x1f0 [amdgpu] 
2026-08-04T01:13:37.505902+10:00 xev kernel: amdgpu_irq_dispatch+0xd2/0x230 [amdgpu] 
2026-08-04T01:13:37.505903+10:00 xev kernel: amdgpu_ih_process+0x84/0x100 [amdgpu] 
2026-08-04T01:13:37.505904+10:00 xev kernel: amdgpu_irq_handler+0x23/0x60 [amdgpu] 
2026-08-04T01:13:37.505905+10:00 xev kernel: __handle_irq_event_percpu+0x4a/0x190
2026-08-04T01:13:37.505907+10:00 xev kernel: handle_irq_event+0x38/0x80 
2026-08-04T01:13:37.505908+10:00 xev kernel: handle_edge_irq+0x8b/0x230 
2026-08-04T01:13:37.505909+10:00 xev kernel: __common_interrupt+0x45/0xe0 
2026-08-04T01:13:37.505910+10:00 xev kernel: common_interrupt+0x42/0xa0 
2026-08-04T01:13:37.505911+10:00 xev kernel: asm_common_interrupt+0x26/0x40 
2026-08-04T01:13:37.505912+10:00 xev kernel: RIP: 0033:0x7ffaf3c5fd7b 
2026-08-04T01:13:37.505913+10:00 xev kernel: Code: 70 c7 00 66 0f 6e f8 c1 ef 02 66 0f 70 f7 e0 83 c7 01 66 0f ef ff 66 0f fa f2 0f 1f 44 00 00 f3 0f 7e 01 66 0f 6f ce 83 c6 01 <48> 83 e9 08 f2 0f 70 c0 1b 66 0f 6f e0 66 0f 6f e8 66 41 0f f9 c0 
2026-08-04T01:13:37.505915+10:00 xev kernel: RSP: 002b:00007fff86a5e0e0 EFLAGS: 00000202 
2026-08-04T01:13:37.505916+10:00 xev kernel: RAX: 0000000000008000 RBX: 0000562614a04050 RCX: 0000562614982ed8 
2026-08-04T01:13:37.505946+10:00 xev kernel: RDX: 0000000000007fe2 RSI: 0000000000000fad RDI: 0000000000002000 
2026-08-04T01:13:37.505948+10:00 xev kernel: RBP: 0000000000000000 R08: 000056261498ac40 R09: 0000000000008000 
2026-08-04T01:13:37.505949+10:00 xev kernel: R10: 0000000000000066 R11: 0000000000007fe1 R12: 0000000000007efa
2026-08-04T01:13:37.505950+10:00 xev kernel: R13: 0000000000008000 R14: 0000000000008000 R15: 000000000000ffe0 
2026-08-04T01:13:37.505951+10:00 xev kernel:  
2026-08-04T01:13:37.505953+10:00 xev kernel: ---[ end trace 0000000000000000 ]--- 
2026-08-04T01:55:40.844110+10:00 xev kernel: pcieport 0000:00:03.3: AER: Multiple Correctable error message received from 0000:00:03.3 
2026-08-04T01:55:40.844130+10:00 xev kernel: pcieport 0000:00:03.3: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Receiver ID) 
2026-08-04T01:55:40.844132+10:00 xev kernel: pcieport 0000:00:03.3: device [8086:6f0b] error status/mask=00000040/00002000 
2026-08-04T01:55:40.844134+10:00 xev kernel: pcieport 0000:00:03.3: [ 6] BadTLP

2026-08-11T09:33:33.473855+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00024802
2026-08-11T09:33:33.473871+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:33.473871+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-11T09:33:33.473873+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F048002
2026-08-11T09:33:33.473873+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 63) at page 2048, write from 'TC0' (0x54433000) (72)
2026-08-11T09:33:33.473874+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00004802
2026-08-11T09:33:33.473874+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:33.473875+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-11T09:33:33.473876+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E048002
2026-08-11T09:33:33.473876+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 63) at page 2048, read from 'TC0' (0x54433000) (72)
2026-08-11T09:33:35.481863+10:00 xev kernel: amdgpu 0000:02:00.0: Dumping IP State
2026-08-11T09:33:35.481875+10:00 xev kernel: amdgpu 0000:02:00.0: Dumping IP State Completed
2026-08-11T09:33:35.481875+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] AMDGPU device coredump file has been created
2026-08-11T09:33:35.481876+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] Check your /sys/class/drm/card0/device/devcoredump/data
2026-08-11T09:33:35.481877+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 146 0x0110040c
2026-08-11T09:33:35.481877+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:35.481878+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000022
2026-08-11T09:33:35.481879+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E00400C
2026-08-11T09:33:35.481879+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x0c, vmid 7, pasid 63) at page 34, read from 'TC3' (0x54433300) (4)
2026-08-11T09:33:35.489845+10:00 xev kernel: amdgpu 0000:02:00.0: ring gfx timeout, signaled seq=5123619, emitted seq=5123621
2026-08-11T09:33:35.489853+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:35.489854+10:00 xev kernel: amdgpu 0000:02:00.0: GPU reset begin!. Source: 1
2026-08-11T09:33:35.493839+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] ERROR Failed to initialize parser -125!
2026-08-11T09:33:35.737848+10:00 xev kernel: amdgpu: cp is busy, skip halt cp
2026-08-11T09:33:35.897842+10:00 xev kernel: amdgpu: rlc is busy, skip halt rlc
2026-08-11T09:33:35.897852+10:00 xev kernel: amdgpu 0000:02:00.0: BACO reset
2026-08-11T09:33:36.485849+10:00 xev kernel: amdgpu 0000:02:00.0: GPU reset succeeded, trying to resume
2026-08-11T09:33:36.485859+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] PCIE GART of 256M enabled (table at 0x000000F402000000).
2026-08-11T09:33:36.485860+10:00 xev kernel: amdgpu 0000:02:00.0: VRAM is lost due to GPU reset!

Errors on Battlemage

Aug 11 17:01:47 ami kernel: ------------[ cut here ]------------
Aug 11 17:01:47 ami kernel: xe 0000:23:00.0: [drm] DMC 1 mmio[0]/0x5f074 incorrect (expected 0x96fc0, current 0x0)
Aug 11 17:01:47 ami kernel: WARNING: drivers/gpu/drm/i915/display/intel_dmc.c:696 at assert_dmc_loaded+0x275/0x430 [xe], CPU#0: kworker/0:3/215
Aug 11 17:01:47 ami kernel: Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common xe(+) skx_edac snd_h>
Aug 11 17:01:47 ami kernel:  msr i2c_dev configfs efi_pstore efivarfs autofs4 btrfs libblake2b raid6_pq xor mpt3sas raid_class scsi_transport_sas megarai>
Aug 11 17:01:47 ami kernel: CPU: 0 UID: 0 PID: 215 Comm: kworker/0:3 Not tainted 7.1.7+deb14-amd64 #1 PREEMPT(lazy)  Debian 7.1.7-1 
Aug 11 17:01:47 ami kernel: Hardware name: HP HP Z4 G4 Workstation/81C5, BIOS P61 v03.00 04/15/2026
Aug 11 17:01:47 ami kernel: Workqueue: sync_wq local_pci_probe_callback
Aug 11 17:01:47 ami kernel: RIP: 0010:assert_dmc_loaded+0x291/0x430 [xe]
Aug 11 17:01:47 ami kernel: Code: 24 10 e8 f2 e5 a3 ce 48 8d 3d bb 85 0d 00 8b 54 24 0c 45 89 e9 45 89 e0 48 89 c6 52 8b 4c 24 2c 51 8b 4c 24 30 48 8b 54>
Aug 11 17:01:47 ami kernel: RSP: 0018:ffffd27ac0b87b80 EFLAGS: 00010282
Aug 11 17:01:47 ami kernel: RAX: ffffffffc1743dfd RBX: ffff8c5b80e54000 RCX: 0000000000000001
Aug 11 17:01:47 ami kernel: RDX: ffff8c5b81df5a10 RSI: ffffffffc1743dfd RDI: ffffffffc1605860
Aug 11 17:01:47 ami kernel: RBP: ffff8c5b86955000 R08: 0000000000000000 R09: 000000000005f074
Aug 11 17:01:47 ami kernel: R10: 0000000000000000 R11: 0000000000091050 R12: 0000000000000000
Aug 11 17:01:47 ami kernel: R13: 000000000005f074 R14: 0000000000000001 R15: 0000000000000000
Aug 11 17:01:47 ami kernel: FS:  0000000000000000(0000) GS:ffff8c673e172000(0000) knlGS:0000000000000000
Aug 11 17:01:47 ami kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 11 17:01:47 ami kernel: CR2: 00007ffed1fdcd00 CR3: 0000000ae942a003 CR4: 00000000003706f0
Aug 11 17:01:47 ami kernel: Call Trace:
Aug 11 17:01:47 ami kernel:  
Aug 11 17:01:47 ami kernel:  intel_dmc_enable_pipe+0xe4/0x290 [xe]
Aug 11 17:01:47 ami kernel:  ? drm_crtc_vblank_reset+0x4d/0x120 [drm]
Aug 11 17:01:47 ami kernel:  intel_modeset_setup_hw_state+0xb50/0x1e10 [xe]
Aug 11 17:01:47 ami kernel:  ? intel_display_driver_probe_nogem+0x138/0x1a0 [xe]
Aug 11 17:01:47 ami kernel:  intel_display_driver_probe_nogem+0x138/0x1a0 [xe]
Aug 11 17:01:47 ami kernel:  xe_display_init_early+0xb2/0x140 [xe]
Aug 11 17:01:47 ami kernel:  xe_device_probe+0x3c8/0xb50 [xe]
Aug 11 17:01:47 ami kernel:  ? xe_pm_init_early+0x152/0x160 [xe]
Aug 11 17:01:47 ami kernel:  xe_pci_probe+0xc26/0x1150 [xe]
Aug 11 17:01:47 ami kernel:  local_pci_probe+0x3e/0x90
Aug 11 17:01:47 ami kernel:  local_pci_probe_callback+0x16/0x20
Aug 11 17:01:47 ami kernel:  process_one_work+0x19d/0x3a0
Aug 11 17:01:47 ami kernel:  worker_thread+0x1af/0x320
Aug 11 17:01:47 ami kernel:  ? __pfx_worker_thread+0x10/0x10
Aug 11 17:01:47 ami kernel:  kthread+0xe3/0x120
Aug 11 17:01:47 ami kernel:  ? __pfx_kthread+0x10/0x10
Aug 11 17:01:47 ami kernel:  ret_from_fork+0x2b2/0x340
Aug 11 17:01:47 ami kernel:  ? __pfx_kthread+0x10/0x10
Aug 11 17:01:47 ami kernel:  ret_from_fork_asm+0x1a/0x30
Aug 11 17:01:47 ami kernel:  
Aug 11 17:01:47 ami kernel: ---[ end trace 0000000000000000 ]---

Reproducible Builds (diffoscope): diffoscope 328 released

Fri, 14 Aug 2026 00:00:00 +0000

The diffoscope maintainers are pleased to announce the release of diffoscope version 328. This version includes the following changes:

[ Chris Lamb ]
* Don't require python3-guestfs in the autopkgtests on 32-bit architectures.
  (Closes: #1144372)

[ Jochen Sprickerhof ]
* Use the XML comparators for SVG vector image files. (Closes: #1144242)

You find out more by visiting the project homepage.

Gunnar Wolf: File recovery in process...

Thu, 13 Aug 2026 17:47:20 +0000

Ohai,

I have some pending, encrypted mails to answer. And some of my answers for the next few days (particularly to what pertains to the current in-discussion vote on LLM usage in Debian) will be unsigned, even though I’d like otherwise.

My desktop system at work is showing some data corruption, and I’m slowly backing up my data. Fortunately, it seems I haven’t lost any data, but still, given I’m letting rsync run until it starts spewing I/O errors, then power down and let the machine cool a bit, and start again… it is a potentially long process.

And yes, this makes me somewhat angry. Why angry? Because I’m working on a brand-new computer (well, have used it for slightly over six months), custom-built to specs requested by my workplace. Specs that I don’t really need, this machine is an utter luxury (i.e. an AMD Ryzen 9 9950X processor with 16 real cores / 32 threads; 128GB RAM in this day and age of RAM shortage, quite recent 32GB GPU, and lots of shiny lights seen in its huge fishbowl cabinet, liquid-based cooling…). The specs came not from me, but from people who had no idea what we would use them for. And yes, I expect the little fortune spent on this machine to be good for my use for probably a decade, as my previous computer was, but the amount paid was… exorbitant.

But still, what I learned recently is that the 4TB nVME SSD it has (a T-Force TM8FFJX34T) is… a very cheap brand, bought because it was close to half the price of other offerings similar in capacity. According to smartctl’s output, th SSD operates with a Warning Comp. Temp. Threshold: 90 Celsius and Critical Comp. Temp. Threshold: 110 Celsius, which sounds sensible, even too high for my standards (my last two laptops have been fanless… yes, an ARM system is very different from a high-end gaming machine). I’m right now typing from my laptop, which shows 78°C and 82°C for warning/critical thresholds.

And as expected, under heavy sustained reads (backing up to my NFS server), the desktop’s smartctl shows Temperature: 83 Celsius and, further down, Temperature Sensor 1: 107 Celsius and Temperature Sensor 2: 82 Celsius (don’t know which of these would make the threshold jump). The SSD has sustained Media and Data Integrity Errors: 20 and Warning Comp. Temperature Time: 21 (although Critical Comp. Temperature Time: 0). At least one of my colleagues have shrugged and installed a SATA SSD, laying the huge nVME basically to waste.

Anyway… I also learned I am not the first, but the fourth person to notice this kind of issues in this system (out of ten similar purchased systems AIUI). It is completely unacceptable, and I’ll be pushing our Institute’s authorities to demand the provider to provide either good component quality for this very expensive system that has many luxury items, or to fix the system’s build in a way the nVME does not heat as much as it currently does.

Anyway, sigh, I only wanted to say, please excuse me for not using my cryptographic keys for a couple of days 🙃

PS- I’m also currently not connected to IRC and Jabber (and some similar technologies), as my bouncer runs from my usual workstation.

Jonathan Dowland: DIY skate punch-out

Thu, 13 Aug 2026 08:28:08 +0000

Since I wrote about my fly30 ice skates, I'd continued to battle pain around the navicular bone in my feet. The action that seems to have finally fixed it was to perform a "punch out": a very localized remoulding of the area of the boot that presses against the sore area.

I basically followed the process from this helpful YouTube video.

I narrowed down the exact spot by borrowing some lipstick and transferring it from my navicular bone to the boot lining, then making that more permanent with a sharpie.

My punch was a spare part from a radiator valve which I packed with US cents (I couldn't fit any UK coins in). For the receiving-end, I tried another part from the radiator valve but I think it wasn't sufficiently larger than the punch to work well, so I swapped that out for a spoon.

take 2

I didn't have a temperature sensor I could use and I used a heat gun rather than a hairdryer, so I YOLO'd it a little. Some of the wrap on one of my boots is now distorted from where I didn't move the heat gun enough. It only took a minute or two to get the boot hot enough to be flexible. I set a 15 minute timer once the clamp was in place.

I've only skated one session since I did this but the pain seems to have gone! It's remarkably freeing to be skating without constantly trying to manage pain. Now I can focus on technique.

Steinar H. Gunderson: The PSX GPU is wild

Wed, 12 Aug 2026 15:26:00 +0000

Inspired by some recent reverse-engineering, here are some things I find wild by the original PlayStation GPU:

VRAM is a flat 1024x512 16-bit image (555 + 1 bit alpha). You want more than just a framebuffer? Figure out yourself what goes where.
Yes, that means you'll need to allocate two framebuffers and double-buffer everything yourself.
Quads are common. No “triangles only” business here.
Vertex coordinates are screen-space x/y integers. No floats or fixed-point. (I'm ignoring the GTE here, plus higher-level libraries.)
Wait, where's z? There's no z. So there's no perspective correction. (This one is pretty famous)
OK, so how do you give in subpixel coordinates? You don't. There's no AA after all.
Texture coordinates (u/v) are uint8_t. There's no texture filtering either; everything is nearest-neighbor only.
OK, so that means you can't have textures larger than 256x256 (pretty common in that era), but how do you give in the handle to the texture?
You don't, it points directly to the 1024x512 VRAM. You manage yourself what goes where, remember?
So can you an only have textures in the top-left 256x256? Hah, no, we give you a bit-packed “texture page” system that offsets all your u/v coordinates.
Most textures are paletted to save VRAM (so instead of 555+1, your pixels now mean something like “two palette indexes”). Where does the palette live?
Well, duh, that's a 256x1 (or 16x1, or whatever) area of VRAM too. The GPU does not care, you can use another texture's pixels as a palette if you feel like it.
OK, so you said there's no z, how do you do z-buffering? You have a z-buffer, right… right?
Yeah, sure, we're not cavemen. We have an “ordering table” that is your Z-buffer, drawn back-to-front. If you want 256 levels of Z, you just allocate an array of 256 linked-list pointers, and then you put your polygon into the one corresponding to the correct right Z.
But, eh, what if my polygon is not completely flat in Z-space?
Hello?
Hello…?

Reproducible Builds: Reproducible Builds summit 2026 to take place in Gothenburg

Wed, 12 Aug 2026 00:00:00 +0000

This event is happening soon — see below for registration instructions!

We are extremely pleased to announce the upcoming Reproducible Builds summit, which will take place from September 22nd—24th 2026 in the city of Gothenburg, Sweden.

This year, we are thrilled to host the tenth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Vienna (2025), Hamburg (2023—2024), Venice (2022), Marrakesh (2019), Paris (2018), Berlin (2017), Berlin (2016) and Athens (2015).

If you’re excited about joining us this year, please make sure to read the event page which has more details about the event and location. As in previous years, we will be sending invitations to all those who attended our previous summit events or expressed interest to do so. However, even if you do not receive a personal invitation, please do email the organizers and we will find a way to accommodate you.

About the event

The Reproducible Builds Summit is a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort. During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving.

Schedule

Although the exact content of the meeting will be shaped by the participants, the main goals will include:

Update & exchange about the status of reproducible builds in various projects.
Improve collaboration both between and inside projects.
Expand the scope and reach of reproducible builds to more projects.
Work together and hack on solutions.
Establish space for more strategic and long-term thinking than is possible in virtual channels.
Brainstorm designs on tools enabling users to get the most benefits from reproducible builds.
Discuss how reproducible builds will be usable and meaningful to users and developers alike.

Logs and minutes will be published after the meeting.

Location & date

Clarion Hotel Draken, Olof Palmes Plats 2, 413 30 Göteborg, Sweden. (OpenStreetMap, Google Maps)
September 22nd to September 24th 2026.

Registration instructions

Please reach out if you’d like to participate in hopefully interesting, inspiring and intense technical sessions about reproducible builds and beyond!

We look forward to what we anticipate to be yet another extraordinary event!

Colin Watson: Free software activity in July 2026

Tue, 11 Aug 2026 10:42:43 +0000

About 95% of my Debian contributions this month were sponsored by Freexian.

You can also support my work directly via Liberapay or GitHub Sponsors.

OpenSSH

Now that Ubuntu 26.04 LTS has been released, I’ve been getting back to the GSS-API key exchange package split in our OpenSSH packaging. Once I started testing my draft openssh-gssapi source package, I realized that I needed to make some changes in the main openssh source package first in order to support it. The dependency from openssh-server to openssh-client was awkward, as was the (related) fact that openssh-client contained shared documentation for other OpenSSH binary packages. After some thought, I created a new openssh-common binary package, moved shared documentation and the ssh-keygen program to that, and dropped dependencies on openssh-client which were no longer necessary (fixing #699473 and #1070098 in the process).

This caused a couple of regressions (#1141420 and #1141550) that I had to fix, and more subtly it also caused a number of autopkgtest regressions in other packages because openssh-client is no longer in base images as a result of a dependency from openssh-server. I believe I have fixes for all of these either pending review or merged (one of which I did in August rather than July):

I upgraded from 10.3p1 to 10.4p1, and in the process contributed a GSS-API option handling fix upstream.

I made openssh-ssh1’s package description more accurately describe the package, thanks to suggestions from Matthias Lang.

Installer team

With support from a Freexian customer, I reviewed, tested, edited, and merged a patch to add VLAN support. I described the details of what I did in a comment.

This has been vaguely on my to-do list since, er, about 2014, so it was very satisfying to get it sorted out.

Python packaging

New upstream versions:

cryptodatahub (fixing a build failure)
dep-logic
django-q
flufl.lock
more-itertools
multipart
pyasn1 (fixing CVE-2026-59884, CVE-2026-59885, and CVE-2026-59886)
pytest-rerunfailures
python-auditwheel
python-build
python-certifi
python-datamodel-code-generator (fixing a build failure, and an incompatibility with pydantic 2.13 that I reported upstream)
python-django-parler
python-httplib2
python-pgbouncer
python-time-machine
python-treq
python-typing-extensions
python-wheezy.template
storm
ubelt
webpy
zope.testing

Other build/test failures:

django-q: autopkgtest failure with Python 3.14 (reported upstream)
httpx: FTBFS: E assert [(‘uvicorn.ac…1.1 200 OK”’)] == [(‘httpx’, 20…1.1 200 OK”’)]
libntruprime: autopkgtest failures with Python 3.14
pygments: Handle None object before HTML escaping (fixed build failures in cmd2, gunicorn, python-inline-snapshot, and python-openapi-core)
python-authlib: some of tests/flask/test_oauth2/rfc9068/ failed
python-click: autopkgtest regression with pytest 9.1 (contributed upstream)
python-httplib2: FTBFS: ERROR tests/test_proxy.py - Failed: ‘forked’ not found in markers configuration option
python-maturin: Please upgrade goblin dependency to 0.10
python-memray: FTBFS on armhf (segfault)
python-mne: FTBFS: E pytest.PytestRemovedIn10Warning: Passing a non-Collection iterable to parametrize is deprecated (actually fixed in scikit-learn; contributed upstream)
python-softlayer: autopkgtest fails with python3-click 8.3.3 (contributed upstream)
python-urllib3: FAILED test/contrib/test_pyopenssl.py

I fixed some other bugs:

I adopted transaction for the Python team.

I attended the Python BoF at DebConf remotely, although a badly-timed fibre outage in the village I live in really didn’t help.

Code reviews

openssh: sshd-session built without crypt(), breaking UsePAM=no password auth (merged and uploaded)
openssh: Slovak debconf templates translation (merged and uploaded)
python-treq: Fails to build source after successful build (merged and uploaded)
python-better-exceptions: FTBFS: failing tests (sponsored upload for Seyed Mohamad Amin Modaresi)
yubihsm-connector: patch to make the build reproducible (merged and uploaded)

Other bits and pieces

Dan Poltawski pointed out in a Fediverse post that the project history didn’t list Sruthi as the current DPL. I fixed that, although it doesn’t look as though the fix is in the published version yet.

I upgraded yubihsm-shell to 2.8.0.

Freexian Collaborators: Debian Contributions: DebConf 26 organization, d-i VLAN support and more! (by Anupa Ann Joseph)

Tue, 11 Aug 2026 00:00:00 +0000

Debian Contributions: 2026-07

Contributing to Debian is part of Freexian’s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

DebConf 26 organization, by Lucas Kanashiro, Santiago Ruano Rincón, Stefano Rivera and Antonio Terceiro

The 27th Annual Debian Conference was held in Santa Fe, Argentina, and several Freexian fellows were quite busy by being involved in the organization team.

Santiago continued helping with duties related to the local team, e.g. preparing or proof-reading some announcements, reviewing the proposed food and the menus for the different diet required.
During the conference, Kanashiro and Santiago also carried over tasks related to the content of the conference, including updating the schedule as it became necessary during the event.
Stefano worked within the core video team, setting up equipment in talk rooms and coordinating the live video streaming. Stefano also supported the front desk and local organisers as a website developer and conference book-keeper.
Antonio kept working on website maintenance, specially in support of the content team. During DebConf he also ran a hands-on workshop to help interested contributors get started with developing the DebConf websites.

d-i VLAN support, by Colin Watson

In environments that use IEEE 802.1Q VLANs, some hosts (such as routers attached to “trunk” ports) may need to apply VLAN tags themselves rather than relying on switches to do so. There has been a long-running request to add support for these to the Debian installer with a proposed patch set put together by several people over the years, and a Freexian customer asked us to help get this over the line. Colin reviewed the latest version of the patch set, applied a number of corrections, added Netplan support, spent some time testing a variety of possible paths through the installer, and landed this. There’s also now documentation for this in the next version of the installation guide.

Miscellaneous contributions

Carles wrote documentation for installing Mailman3 and migrating from Mailman2. Added it into Mailman3 upstream documentation.
Carles, using po-debconf-manager: reviewed 2 packages, submitted 2 packages
Carles organized Catalan translation update. Created a Debian Wiki page to have an overview of the work / coordination during next months. Reviewed and submitted some pages.
Carles improved the documentation for building the debian.org Web in MR 1154 and MR 1557. Fixed debian-reference documentation. Added sections on Mutt Wiki page (handling of mailto, viewing HTML parts web browser), update and improve bash-completion Wiki page. Added a troubleshooting section in Signal Wiki.
Thorsten did another upload of hplip to fix RC bugs. He also spent some time taking care of older bugs. Most of the time such bugs had been fixed in a previous upload but haven’t been closed in the BTS. He also uploaded a new upstream version of foomatic-db. Last but not least, he gave some user support with the package epson-inkjet-printer-escpr. There seems to be a new software available for Epson printers. Unfortunately the license is not compatible with DFSG and so this software will never make it into Debian.
During DebCamp 26, the Golang team had a dedicated Sprint to transition the Golang toolchain (namely on dh-golang) to make builds aware of the module defined upstream with the aim of solving important issues. To help in these efforts, Santiago made changes in the Salsa CI pipeline and documented on how to use it to check if a package requires adjustments after the toolchain update.
Santiago continued co-mentoring Aryan Karamtoth on the Linux livepatching project, specifically providing feedback about the implementation of dlp-tools.
Stefano reviewed and merged a migration of Debian reimbursements from wkhtmltopdf to weasyprint, unblocking an upgrade to Debian trixie.
Stefano’s cPython upstream merge request adding multiarch tags to stable ABI extensions was finally merged.
Stefano iterated on his upstream cPython merge request to add CI coverage for Debian’s multi-arch expectations.
Stefano uploaded Python 3.15.0 beta 4 to Debian experimental.
Stefano uploaded Python 3.13 to trixie, fixing a regression in a previous trixie point update he made.
Helmut continued to report undeclared file conflicts.
Helmut sent patches for three cross build failures.
Helmut proposed a MR to port piuparts to pathlib.
Antonio has done quite some work on Debian CI, including rebuilding the Debian CI armhf/armel worker VMs, and releasing debci 4.2, implementing a backup scheme, and several improvements to the codebase such as improving the incus-lxc backend in preparation for switching to the upcoming switch to using it by default as announced in the latest bits from the ci.debian.net operators.
Emilio helped with transitions, particularly with Python 3.14 as default and Perl 5.42. During the Perl transition, an issue was identified with how britney schedules autopkgtests for binNMUs, and that testing was reverted for the time being.
Colin restructured openssh-* binary packages to better support the upcoming GSS-API package split. This caused several autopkgtest regressions in other packages because openssh-server no longer depends on openssh-client, all of which have fixes either pending review or merged now.
Lucas started a discussion around the creation of a Debian packaging video course for newcomers in the context of the Outreach team.
Lucas reviewed some contributions to ruby3.4 and provided feedback.
Anupa worked with Jean-Pierre Giraud on the point release announcements for Debian 13.6 and Debian 12.15.
Anupa joined Jean-Pierre Giraud to prepare the Micronews for DebConf 26 press coverage.

Bits from Debian: DebConf26 Local Team says goodbye

Mon, 10 Aug 2026 21:50:00 +0000

On Saturday 25 July 2026, the annual Debian Developers and Contributors Conference came to a close. The Debian Press team would now like to share this personal and beautiful message from the Santa Fe Local Team.

Words from DC26 Local Team

DebConf26 is over, and those of us who were part of the Local Team are trying to return to “normality”, if such a thing exists after organizing a DebConf.

This event changed our lives and would not have been possible without the help of many great people.

We would especially like to thank everyone who became part of our extended local team. Our endless thanks go to Gunnar —who also instigated this whole adventure—, Santiago, Nattie, Stefano, and Olasd. Thank you for supporting and guiding us, sharing your experience, and helping us find solutions throughout the entire process.

It was also made possible thanks to the great work, strong support and patience of international teams: Fundraising, Bursaries, Content, Video, Treasury, Visa, Website, Accommodation, Front Desk, Cheese and Wine, Publicity as well as all the other teams and individuals who contributed. We apologize if we have forgotten to mention anyone; many people helped make this event possible.

Our deepest thanks also go to everyone who joined us in working on the event, especially Fer, José, and Julián, who showed great commitment and took responsibility for several important tasks.

We would also like to extend our gratitude to FICH, the Universidad Nacional del Litoral, the institutions, organizations, sponsors, suppliers, and everyone who contributed in one way or another to welcoming the Debian community to Santa Fe.

And finally, a very special thank you to our families, to whom we dedicated little time these past few weeks, who supported us on this adventure, enduring the exhaustion, the calls and messages at all hours, and the occasional stressful situation. Always giving us that much-needed, encouraging hug with so much love.

These were very intense weeks, during which we tried to give our best so that everyone could enjoy their stay and so that the Debian community had the necessary conditions to meet, work, share knowledge, and continue creating the magic that characterizes community life and the development of Debian.

As happens at every DebConf, there were difficulties, unexpected situations, and challenges that required us to improvise, learn, and perform a few juggling acts. There were also moments that will certainly remain as memorable anecdotes: the “antisocial room”, some gas heaters worthy of a museum, and newly unlocked powers for negotiating with suppliers.

We have no evidence, but also no doubt, that for many people the Conference Dinner was one of the best moments of the event.

A few ingredients we had hoped would happen naturally were missing, such as more wine nights and at least one in-person football match.

During the two weeks of DebConf, we experienced every kind of weather and a wide range of emotions. Above all, however, we saw people enjoying themselves and building friendships, which fills us with pride.

Thank you very much to everyone who came and helped DebConf26 leave such a beautiful mark on our hearts.

We hope our paths cross again somewhere in life.

Best regards,

Leonardo, Emmanuel, Mariano, Pablo, and Martín DebConf26 Local Team

About Debian

The Debian Project was founded in 1993 by Ian Murdock to be a truly free community project. Since then the project has grown to be one of the largest and most influential Open Source projects. Thousands of volunteers from all over the world work together to create and maintain Debian software. Available in 70 languages, and supporting a huge range of computer types, Debian calls itself the universal operating system.

About DebConf

DebConf is the Debian Project's developer conference. In addition to a full schedule of technical, social and policy talks, DebConf provides an opportunity for developers, contributors and other interested people to meet in person and work together more closely. It has taken place annually since 2000 in locations as varied as Scotland, Bosnia and Herzegovina, India, Korea, France. More information about DebConf is available from https://debconf.org/.

Contact Information

For further information, please visit the DebConf26 web page at https://debconf26.debconf.org/ or send mail to press@debian.org.

Jonathan Dowland: time-delayed scifi roundup feed

Mon, 10 Aug 2026 14:44:31 +0000

I enjoy reading The Guardian's monthly round-up of new SF novels, which can be found in their Science Fiction Books section, and can also be read via feed. Since the round-up is of new books, at the time the round-up is published they're usually only available in hardback.

When it comes to choosing a book to read, these days I am tending towards paperbacks: I've largely ran out of room for hardbacks. So I decided to apply a time delay to their feed. Six months is roughly enough that a book mentioned in a round-up should be shortly available in paperback.

The first obstacle was that The Guardian only publish roughly the last six months of articles in their feed, and so the posts I want have disappeared. However, my Feed Reader (FreshRSS) had older copies stored in its database, and I am able to re-publish those using User Queries. (This also gives me an opportunity to filter out non-roundup articles from the Guardian's feed).

It's then a nice short piece of scripting (this time, using Ruby) to filter the republished feed on the publication date. To make the most recent articles appear new, I also modify the metadata for filtered entries to appear 6 months newer than they are.

#!/usr/bin/ruby
require 'rss'

# replace with the user query feed URI
uri       = 'https://www.theguardian.com/books/science-fiction/rss'
now       = Time.now
sixMonths = 6 * 30 * 24 * 60 * 60
feed      = RSS::Parser.parse(uri)

feed.items.select! do |item|
  item.date + sixMonths < now
end
feed.items.collect! do |item|
  item.date += sixMonths
  item
end

puts "Content-Type: text/xml\r\n\r"
puts feed

I stuck that up on my private web server, subscribed to it in my FreshRSS and voila, a time-delayed list of books to read, most likely available in paperback.

Uwe Kleine-König: PGP Keysigning on Linux Plumbers and OpenSource Summit Europe 2026

Mon, 10 Aug 2026 14:37:00 +0000

I'm going to this year's LPC and Open Source Summit Europe 🥳.

I will organize sessions on two days after the conference program to exchange PGP fingerprints for keysigning to improve the kernel's web-of-trust (but of course everyone is welcome).

For details see my announcement on LKML. Note the registration deadline at 2026-09-27 08:00 UTC.

Elana Hashman: Managing virtualenvs with a little bash

Sun, 09 Aug 2026 20:00:00 +0000

When you need to install something directly from PyPI, Python virtualenvs have been my go-to for over a decade.

A quick virtualenv intro

Most of my readers are probably already familiar with virtualenvs, but for completeness, I'll give you a brief introduction. A virtualenv (short for "virtual environment") is an isolated distribution of Python packages, where you can independently install packages without disturbing your system packages or other virtualenvs.

You can set one up like this, assuming you are using Python 3.3 or higher:

python3 -m venv ~/.venv/my-virtualenv

The directory specified here is just a convention. I keep all my virtualenvs in the .venv folder in my home directory, but you can pick whatever location you like.

To use the virtualenv, you must activate it:

source ~/.venv/my-virtualenv/bin/activate

This activation script is a special shell script that configures your current shell, pointing at all the right paths in order to use the virtual environment. source runs this script in your current shell session to set it up. You will notice that this adds (my-virtualenv) to the beginning of your shell prompt, reminding you that the "my-virtualenv" virtualenv is active. Now when you pip install amazing-package, the software will only be available in this virtual environment.

When you're done, you can deactivate it like so:

deactivate

Wonderful!

Managing many virtualenvs gets annoying

Over time, I end up accumulating many virtualenvs, which can become harder to manage. Maybe something like this:

$ ls ~/.venv/
my-virtualenv cool-project snakes-ahoy

I also don't want to type source ~/.venv/my-virtualenv/bin/activate every time I use the virtualenv, because it gets very repetitive—only the name of the venv is really needed.

But luckily, we can write a little bit of bash to make managing this less annoying. (Or you can use one of many Python developer tools that are designed to manage this, like pipx, but when I merely want to consume Python software, I might not have a development environment set up. So that's beyond the scope of this post!)

If you add the following shell function to your ~/.bashrc or ~/.bash_aliases file, it will nicely wrap our activation command:

setup-venv() {
        source "$HOME/.venv/$1/bin/activate"
}

Now all we need to run is

setup-venv my-virtualenv

So much quicker!

Spicing it up with tab completion

The first thing I noticed after writing this wrapper was that I started hitting tab on the virtual environment name, but... nothing happened. Wouldn't it be nice to know what virtualenvs I had available, and to not have to type out the whole long thing?

Well, we can write it ourselves 😄

If for some reason you don't already have bash completion installed, on a Debian-based system, you will need to install it with

apt install bash-completion

In order to configure our bash completion, we will create a new file, /etc/bash_completion.d/venv, with the following contents:

_list_venvs()
{
    local cur prev opts
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    opts=$(find $HOME/.venv/ -mindepth 1 -maxdepth 1 -type d -printf "%f ")

    COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
    return 0
}
complete -F _list_venvs setup-venv

This file defines another shell function order to determine how to autocomplete the options for our setup-venv function.

$opts is where we define the options for our function. We generate it with a find command—looking at the .venv folder in the current user's home directory, then only including child folders (excluding the current directory itself, .venv, in our results) by using the min/max depth and type arguments, and printing just the individual directory names, deliminated by spaces using our print formatter.

Everything else is the standard scaffolding required to use bash completions.

Once you save this file and reload your shell, you'll see that you are able to use completions as expected!

setup-venv <tab>
my-virtualenv cool-project snakes-ahoy

setup-venv s<tab>
setup-venv snakes-ahoy

Complaints, comments, questions?

Hope this was helpful! If it wasn't, that's too bad. But don't worry—you can safely ignore this post.

Reproducible Builds: Reproducible Builds in July 2026

Sun, 09 Aug 2026 19:12:10 +0000

Welcome to the July 2026 report from the Reproducible Builds project!

In our reports, we try to outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not.

If you are interested in contributing to the project, please visit the Contribute page on our website.

In this month’s report, we cover:

Tool development

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 324, 325 and 326 to Debian:

Fix tests to work with zipdetails 4.0008. (#1141359)
Bump debhelper compatibility level to 13. […]
Update copyright years. […]

In addition, Paul Spooren made changes to allow trailing garbage in Gzip files […] and Vagrant Cascadian added an external tool reference for the pedump binary to use the mono package under GNU Guix. […]

disorderfs is our FUSE-based filesystem that deliberately introduces non-determinism into system calls to reliably flush out reproducibility issues. This month, Christelle Gloor added the option to sort by ctime as returned by the lstat(2) syscall. […], which Chris Lamb uploaded whilst bumping the Standards-Version to version 4.7.4 […]. Bernhard Wiedemann also updated disorderfs to version 0.7.0 in openSUSE.

Yet again, there were a number of improvements made to our website this month as well. For example, Chris Lamb, by request of Digital Ocean, changed the target of a referral link so that they can manage incoming referrers […] and pushed a number of changes to the Tools page […].

Distribution work

In Debian this month, 32 reviews of Debian packages were added, 26 were updated and a total of 21 were removed this month, adding to our extensive knowledge about identified issues.

A number of issue types were added by Chris Lamb, including:

python_towncrier_build_date […][…]
log_files_installed_in_package […]
fontforge_varies_by_timezone […][…]

Chris also added a further note for the build_date_in_manpage_generated_by_spf13_cobra issue. […]

In addition, there is a new page showing verification rebuilds of OpenWrt APK packages and firmware images, powered by rebuilderd:

Three new scholarly papers

Yan Li, Nan Jiang, Qihang Zhou, Shaowen Xu, Yamin Xie and Xiaoqi Jia of the Chinese Academy of Sciences published a paper titled VCAligner: Aligning Source Distribution Versions with Upstream Git Commits to Secure Supply Chain:

We present VCAligner, a content-based alignment methodology that constructs inverted indexes over VCS histories to precisely map released artifacts to their originating commits, independent of fragile version tags. We evaluated VCAligner on a dataset of 2,984 verifiable PyPI packages derived from the 4,000 most-downloaded projects linked to public GitHub upstreams. Our results reveal a critical weakness in conventional tag-based heuristics: while they appear effective on 85% of the dataset, the residual 15% failure rate generates a catastrophic downstream audit workload of over 10.3 million commits. In contrast, VCAligner reduces this burden by two orders of magnitude (≈ 158×), bounding the total workload to under 65,000 commits. Furthermore, we provide the large-scale characterization of “Packaging Noise,” classifying artifact divergence into structural additions (Path Phantoms) and content mutations (Blob Phantoms), thereby isolating the distinct attack surfaces of malicious injection and code tampering.

Jens Dietrich and Spencer Sun from the Victoria University of Wellington together with Tim W. White and Behnaz Hassanshahi from Oracle Inc pre-published their paper No Snake Oil: Verifying Python Package Builds (PDF):

Python has become the default language for interacting with AI, with packages being distributed through registries like the Python Package Index (PyPI). This creates a need to analyse supply chains comprising such packages. One such analysis is to rebuild packages in order to identify compromised builds injecting malware. Independent rebuilds in hardened environments have the added advantage that they can generate and record provenance in order to increase the trustworthiness of packages. Two tools that are designed to automate such rebuilds and run them at scale are macaron and oss-rebuild. We study 12,180 popular releases from PyPI and find that the byte-for-byte equivalence rate is generally low. We analyse the reasons why they produce different wheels, and find that equivalence between the original and rebuilt wheels can often still be established, preserving most of the guarantees users expect from rebuildable releases. We present and evaluate daleq4py, a tool to establish the equivalence of Python wheels through the kernel of a normalisation function that is based on provenance-preserving datalog rules. Experimental results show that daleq4py substantially expands the set of rebuilds that can be accepted as equivalent. Although only 15.4% of macaron rebuilds and 19.1% of oss-rebuild rebuilds are byte-for-byte identical to the published PyPI wheels, daleq4py establishes wheel equivalence for 60.2% and 78.9% of source-equivalent rebuilds, respectively.

Denise Nanni, Julien Malka, Stefano Zacchiroli and Théo Zimmermann from Télécom Paris together with Gabriele D’Angelo from the University of Bologna pre-published their paper Understanding Build Reproducibility in the F-Droid Ecosystem (PDF), which was accepted at the 2026 ACM Conference on Reproducibility and Replicability:

The security of open source applications benefits considerably from the possibility of rebuilding their source and verifying the output. F-Droid, a prominent distribution for open source Android applications, systematically rebuilds them from source and tests their bitwise reproducibility at app publishing time. However, F-Droid offers no guarantee that app reproducibility will continue to hold in the future. As software ecosystems evolve, reproducibility may degrade, with potential negative consequences for software preservation and security. We present the first empirical study of build reproducibility in the F-Droid app ecosystem. Analyzing historical reproducibility logs, we find that the overall bitwise reproducibility rate has been steadily increasing over time (as new versions of apps are published). We then evaluate how reproducibility holds in time for fixed app versions, by attempting to rebuild 18 904 app versions that F-Droid had previously confirmed bitwise reproducible, published between September 2018 and February 2026, achieving an 83% rebuild success rate, and identify missing dependencies as the dominant cause of failure, accounting for 76% of non-rebuildable cases. Among successfully rebuilt apps, 94% are also bitwise reproducible-i.e., they still yield bitwise identical artifacts upon rebuild. Together, these results show that while bitwise reproducibility largely holds for apps that can be rebuilt, rebuildability itself is highly sensitive to temporal decay.

Patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:

openSUSE monthly
Arnout Engelen:
- ivy
- pekko-grpc
- sbt-ivy
- scala
Bernhard M. Wiedemann:
Chris Lamb:
- #1141505 filed against golang-github-tidwall-wal.
- #1141506 filed against lightproof.
- #1141582 filed against libslow5lib.
- #1141687 filed against siso.
- #1141841 filed against grout.
- #1142126 filed against libpsl.
- #1142492 filed against node-grunt-contrib-internal.
- #1142495 filed against fontforge.
- #1142496 filed against spopt.
- #1142887 filed against go-dlib.
- #1143147 filed against towncrier.
Jochen Sprickerhof:
- #1141412 filed against python-sphinx-chango.
- #1141553 filed against gasnet.
- #1141577 filed against yubihsm-connector.
- #1141663 filed against dh-fortran.
- #1142000 filed against watcher.
- #1142001 filed against rakudo.
- #1142128 filed against kf6-breeze-icons.
- #1142141 filed against oxygen-icons.
- #1142256 filed against gnu-apl.
- #1142513 filed against barvinok.
- #1143169 filed against ecbuild.

Misc news

On our mailing list this month, Colin Winter of Markovian Protocol wrote to our mailing list on the topic of Reproducible verification for retained logs:

Reproducible builds remove trust in the builder: anyone re-derives the same artifact from the same source, byte for byte. The same shape applies one layer over, to a retained record. Most record-keeping regimes (the EU AI Act’s Article 12 logging is the current example) require that events be recorded and logs retained, but not that a retained log be verifiable, by a party who was not present, as unaltered and existing when claimed. That leaves an integrity obligation resting on trusting the party being audited.

(Full thread)

Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

IRC: #reproducible-builds on irc.oftc.net.
Mastodon: @reproducible_builds@fosstodon.org
Mailing list: rb-general@lists.reproducible-builds.org

Thorsten Alteholz: My Debian Activities in July 2026

Fri, 07 Aug 2026 17:02:01 +0000

Debian LTS/ELTS

This was my hundred-forty-fifth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

During my allocated time I uploaded or worked on:

[DSA 6402-1] hplip security update to fix two CVEs in Trixie related to privilege escalation and/or arbitrary code execution. I sent the debdiff to the security team, which resulted in this DSA.
[#1142351] trixie-pu of libnfs has been uploaded.
[DLA 4689-1] libnfs security update to fix one CVE in Bookworm and Bullseye related to an integer overflow.
[DLA 4699-1] hplip security update to fix two CVEs in Bookworm and Bullseye related to privilege escalation and/or arbitrary code execution.
[ELA-1775-1] libnfs gimp security update to fix one CVE in Buster and Stretch related to an integer overflow.
[ELA-1784-1] hplip security update to fix two CVEs in Buster and Stretch related to privilege escalation and/or arbitrary code execution.

Unfortunately the number of assigned hours was rather low this month. So besides doing some days of FD at the end of the month, where I also had to process a new package list for ELTS, and a review of the rsync package (prepared by Sylvain), not much happened here.

Debian Printing

This month I uploaded a new upstream versions:

… hplip to unstable.
… foomatic-db to unstable.

Besides the package upload, I also took care of some older bugs of hplip.

This work is generously funded by Freexian!

Debian Lomiri

This month I continued the upload of lomiri packages with new upstream versions. Thanks to the help of my other colleagues, this project could be finished now.

This work is generously funded by Fre(i)e Software GmbH!

Debian Astro

This month I uploaded a new upstream version or a bugfix version of:

… fxload to unstable.
… indi-orion-ssg3 to unstable.
… calceph to unstable (sponsored upload).

Debian IoT

Unfortunately I had no time to work in this category this month.

Debian Mobcom

This month I uploaded a new upstream version or a bugfix version of:

… libgsm to unstable.
… libosmocore to unstable.
… libosmo-cc to unstable.

Next month I intend to upload new upstream versions of all Osmocom packages. As far as I can tell, these uploads will happen without soname changes. I like that :-).

misc

This month I uploaded a new upstream version or a bugfix version of:

… usb-modeswitch to unstable.
… ta-lib to unstable.
… lua-geoip to unstable.
… lua-systemd to unstable.
… displaylink-driver to unstable.
… nuspell to unstable.

Reproducible Builds (diffoscope): diffoscope 327 released

Fri, 07 Aug 2026 00:00:00 +0000

The diffoscope maintainers are pleased to announce the release of diffoscope version 327. This version includes the following changes:

[ Colin Watson ]
* Handle missing openssh-client binaries in autopkgtests.

You find out more by visiting the project homepage.

Bits from Debian: DebConf26 closes in Santa Fe and DebConf27 announced

Thu, 06 Aug 2026 21:50:00 +0000

On Saturday 25 July 2026, the annual Debian Developers and Contributors Conference came to a close. Over 270 attendees representing 35 countries from around the world came together for a combined 90 events (including some which took place during the DebCamp) including more than 27 Talks, 21 Short Talks, 29 Birds of a Feather sessions ("BoF" – informal meeting between developers and users), 8 workshops, and activities in support of furthering our distribution and free software, learning from our mentors and peers, building our community, and having a bit of fun.

The conference was preceded by the annual DebCamp hacking session held 13 through 19 July where Debian Developers and Contributors convened to focus on their individual Debian-related projects or work in team sprints geared toward in-person collaboration in developing Debian.

As has been the case for several years, a special effort has been made to welcome newcomers and help them become familiar with Debian and DebConf by organizing a sprint "New Contributors Onboarding" every day of Debcamp, followed more informally by mentorship during DebConf. Half a dozen new contributors joined the sessions and learned about Debian, free software, packaging and much more.

This year, a week-long DebCamp session was dedicated to auditing, patching, and modernizing the Go ecosystem in Debian and enable the transition triggered by the recent upload of dh-golang enabling GO111MODULE=on by default in Experimental.

In order to make the conference more accessible for local participants, a local language track was included in the schedule for talks in Spanish, as was done at DebConf19 in Brazil.

The actual Debian Developers Conference started on Monday 20 July 2026.

In addition to the traditional "Bits from the DPL" talk, the continuous key-signing party, lightning talks, and the announcement of next year's DebConf27, there were several update sessions shared by internal projects and teams.

Many of the hosted discussion sessions were presented by our technical core teams with the usual and useful "Meet the Technical Committee", three talks about Linux Kernel, early boot and improving Debian’s kernel and installer support for Chromebooks, and about twenty BoFs and talks about Debian packaging policy, Debian infrastructure, security and privacy.

This year, and echoing ongoing discussions within the Free Software community, Artificial Intelligence and Age Verification have been the subject of several talks. The Python, Perl, Ruby, Go, and Rust programming language teams also shared updates on their work and efforts.

More than 17 BoFs and talks about community, diversity, and local outreach highlighted the work of various teams involved in not just the technical but also the social aspect of our community

The schedule was updated each day with planned and ad hoc activities introduced by attendees over the course of the conference. Several traditional activities took place: a poetry performance, the traditional Cheese and Wine party, the Group Photos, and the Day Trip.

For those who were not able to attend, most of the talks and sessions were broadcasted live and recorded. One can find the seventy hours of recorded videos available via the conference schedule, or alternatively through this link.

Almost all of the sessions facilitated remote participation via IRC and Matrix messaging apps or online collaborative text documents which allowed remote attendees to "be in the room" and ask questions or share comments with the speaker or assembled audience. DebConf26 saw over 341 T-shirts, a day trip, and up to 130 meals planned per day.

All of these events, activities, conversations, and streams coupled with our love, interest, and participation in Debian and F/OSS certainly made this conference an overall success both here in Santa Fe, Argentina and online around the world.

The DebConf26 website will remain active for archival purposes and will continue to offer links to the presentations and videos of talks and events.

Next year, DebConf27 will be held in Asahikawa, Hokkaido, Japan, from Sunday September 5th to Saturday September 11th, 2027. As tradition follows before the next DebConf the local organizers in Japan will start the conference activities with DebCamp with a particular focus on individual and team work towards improving the distribution.

DebConf is committed to a safe and welcome environment for all participants. See the web page about the Code of Conduct on the DebConf26 website for more details on this.

Debian thanks the commitment of numerous sponsors to support DebConf26, particularly our Platinum Sponsors: Infomaniak, and Proxmox, and our Gold Sponsors : Freexian, and Viridien.

We also wish to thank our Video and Infrastructure teams, the DebConf26 and DebConf committees, our host nation of Argentina, and each and every person who helped contribute to this event and to Debian overall. Thank you all for your work in helping Debian continue to be "The Universal Operating System".

See you next year!

About Debian

About DebConf

About Infomaniak

Infomaniak is an independent, employee-owned Swiss technology company that designs, develops, and operates its own cloud infrastructure and digital services entirely in Switzerland. With over 300 employees — more than 70% engineers and developers — the company reinvests all profits into R&D. Its public cloud is built on OpenStack, with managed Kubernetes, Database as a Service, object storage, and sovereign AI services accessible via OpenAI-compatible APIs, all running on its own Swiss infrastructure. Infomaniak also develops a sovereign collaborative suite — messaging, email, storage, online office tools, videoconferencing, and a built-in AI assistant — developed in-house and as a privacy-respecting solution to proprietary platforms. Open source is central to how Infomaniak operates. Its latest data center (D4) runs on 100% renewable energy and uses no traditional cooling: all the heat generated by its servers is captured and fed into Geneva's district heating network, supplying up to 6,000 homes in winter and hot water year-round. The entire project has been documented and open-sourced at d4project.org.

About Proxmox

Proxmox develops powerful, yet easy-to-use open-source server solutions. The comprehensive open-source ecosystem is designed to manage divers IT landscapes, from single servers to large-scale distributed data centers. Our unified platform integrates server virtualization, easy backup, and rock-solid email security ensuring seamless interoperability across the entire portfolio. With the Proxmox Datacenter Manager, the ecosystem also offers a "single pane of glass" for centralized management across different locations. Since 2005, all Proxmox solutions have been built on the rock-solid Debian platform. We are proud to return to DebConf26 as a sponsor because the Debian community provides the foundation that makes our work possible. We believe in keeping IT simple, open, and under your control.

Contact Information

For further information, please visit the DebConf26 web page at https://debconf26.debconf.org/ or send mail to press@debian.org.

Russell Coker: TV Control etc

Thu, 06 Aug 2026 04:01:37 +0000

In 2008 I wrote a blog post “The Problem is Too Many Remote Controls” [1] about the issues of controlling a TV and related things. It recently got some comments on Mastodon so I think it’s time for an update.

The first issue I raised was “Now it’s not uncommon to have separate remote controls for the TV, VCR, DVD player, and the Cable TV box – a total of four remote controls” which seems to have alleviated. VCRs seem to have almost entirely gone away. The VHS Wikipedia page [2] is worth reading for everyone who hasn’t seen a VCR in operation, which I expect to be more than a few readers now and an increasing number over the next 18 years. I personally don’t have Cable TV, I own a DVD player which isn’t connected to my TV because I haven’t used it for years, I don’t own a VCR, and I don’t watch free to air TV. So I have one remote control for the TV which I use for Netflix and sometimes YouTube.

When viewing YouTube on TV there are significantly more adverts and longer adverts. I presume that is because installing an ad-blocker on my TV isn’t a viable option for me and it’s a total impossibility for most users. Generally my desktop PC is a much better platform for YouTube than my TV, it has a better quality display, is more user friendly (my previous post addressed the difficulty of getting to the data source that’s desired), and doesn’t require entering search terms via a slow on-screen keyboard. Netflix on Linux is limited to 720p at low bitrate which is obviously of low visual quality while on the TV it’s in 4K. I have Netflix so I use that only on the TV.

In my previous post I wrote a thought experiment on how to use a cheap laptop ($500 at the time – equivalent to $777 in 2025 money according to the Reserve Bank of Australia) to control a $5000 TV ($7770 in 2025 money). Now you can buy a new 65″ 4K TV for under $800 and a new laptop capable of 4K output for under $400 so the options are very different. For a $800 TV the manufacturer isn’t going to develop a remote control interface and Google (who develops the software the TVs run) won’t do it because it could reduce their advertising revenue. But a typical home user could setup a cheap laptop connected to their TV via HDMI providing a familiar and efficient user interface for themselves and visitors. For a Windows laptop 4K Netflix should work and for a Linux laptop the options of a laptop for everything apart from Netflix and the TV for Netflix are bearable, two controls are worse than one but better than the 3+ that used to be common.

In my previous post I raised the issue that “it’s often the case that you don’t want to stop watching one show while trying to find another”. This is still an unsolved problem and is not addressed in modern software. I am not aware of a Linux music player that supports such functionality and this would be much easier for a music player than for a video player where the screen would have to be shared between the interface for finding the next thing to play and the space for playing the end of the current one. Maybe I should file a bunch of wishlist bugs against music players asking for this.

I suggested that “cable modem” and “cable TV box” could be integrated into a single device. That has not happened, in fact it’s got worse. A relative who has Foxtel has a cable modem, a cable TV box, and a Wifi AP with VOIP to provide landline phone service and to make it more exciting the latter two both have bugs that require a periodic hardware reset to fix. Hopefully cable TV will go away in the next 18 years.

Regular PCs have become less noisy in recent years. I am currently using a HP Z640 to write this post and I have HP Z840 and HP Z4G4 systems behind me running as servers and the background noise is still very low. The allegedly 8K TV [3] that I have in my lounge room has cooling fans that make more noise than those three high-end HP computers combined. Using a quiet PC like one of those HP systems to drive a TV is a very viable option and I did just that for a couple of years. Kogan has currently got a selection of refurbished Lenovo ThinkStation systems on sale for under $400, they are quiet and would do well for this, it’s also nice that Kogan is selling systems with ECC RAM at home user prices.

TV does seem to be going away. YouTube and streaming services seem to get more watching time and many people don’t use TV at all.

Since my previous post the number of streaming services has increased so torrenting offers increasing benefits as no-one wants to subscribe to 6+ services. For anyone who wants to get all the content that interests them while paying the user interface situation is much worse now than it used to be in 2008.

If you use KDE on a PC then the kconnect program allows a phone to be used to remotely control some aspects of a PC and has a good interface for pause/resume of a video and seeking 10 seconds forwards/backwards. The interface for controlling volume is hard to get to and doesn’t work on my installation. If you want to use a keyboard to start something playing and then a phone for pause control then kdeconnect is a decent option. A comment on my previous post by Michael Croes raised the issue of remote control which is now a solvable problem. Justin also wrote a comment suggesting a Nokia N800 as a remote.

Jason suggested a programmable remote, which would be a good option for a power user and a viable option for someone setting things up for their grandparents. But the amount of pain is greater than I’m interested in as lounge room TV isn’t an important thing to me. It may appeal to more people than having a dedicated lounge room PC though.

Gunnar Wolf: Subscription Bombing • Email under Attack

Thu, 06 Aug 2026 00:17:35 +0000

This post is an unpublished review for Subscription Bombing • Email under Attack

One of the most important inputs one can have when designing a response strategy against a security attack is a good characterization. This article describes a relatively newly described attack mode (subscription bombing), hypothetizes on the motivations that can lie behind it, and presents some countermeasures that can be taken by different actors to reduce its impact.

At its core, suscription bombing is a classical reflection attack: it uses a third party service so that the answer to a relatively simple request is amplified and results in a distributed denial of service (DDoS) for the victim. And, as with most DDoS attacks, its effectivity lies in that there is not much a person can do against traffic coming from seemingly random different providers all around the world.

The core differentiatof for subscription bombing is that the attack’s victim is not a network port, but an individual’s e-mail address. The attacker builds a database of service providers that allow interested users to sign up for newsletter on their activities, or a mailing list, or even just to create a new account on a given Web system. This action will generate a (seemingly legitimate) confirmation mail sent to the victim. But the attacker scripts together hundreds of thousands of such request, creating a deluge of confirmation mails sent to the unsuspecting victim.

The authors explain the goals an attacker might pursue by performing this kind of attack. They suppose this can be due to harassment (a disgruntled employee being denied a salary raise, a political adversary, or even a romantic ex-partner wanting to inconvenience the victim’s use of their e-mail). More worryingly, the attack can be used as a distraction: by sending a high volume of mails in a controlled timeframe, the attacker can reduce the probability of the victim noticing a specific attack warning them of, i.e., financial fraud, unwanted purchases, or break-in attempts into their accounts. Attacks targetting mailboxes at private mail servers can also lead to overloading an account’s limit, causing it to reject mails after the attack is delivered and before the folder is cleaned. And it can also pave the way for follow-up, targetted deception attacks, where the attackers call the victim pretending to be the company’s IT department, and get them to install a remote desktop monitoring and management tool, with which they can effectively seize control of the victim’s data.

To do this, they present a study they made over 24 cases of victims, from which 47,970 total e-mails were received between October and December 2024, with individual attacks receiving between 81 and 3,387 e-mails per hour, from where they presented several descriptive analysis.

The authors explored cyber criminal’s offers on underground websites, comparing flooding services and pricing schemes.

Finally, mitigation strategies are discussed. Mitigation is quite problematic, as none of the mail servers is acting in either a hostile way or lacking permissions — they are performing just the task they should. The authors suggest four mitigation strategies for mail server operators to reduce the burden on their users, although none of them is easily automatizab (rate-limit the number of emails a given inbox can receive from previously unseen senders; educate users about this kind of attacks; group similar newsletter or account reset mails during active attacks; and automatically unsubscribe or bounce newsletter messages when a surge is detected). They also recommend newsletter providers and services accepting the unrestricted creation of user accounts to provide some hardening to increase the effort wrongdoers need to spend to abuse their services, such as requiring CAPTCHAs or requiring users to take several steps before requesting a subscription, although they recognize this adds friction to the process providers are most interested in providing; filtering and triaging known-good and known-bad domains, although this is hard to implement on a preemptive fashion, and adhering to easy unsubscription standards, such as easily identifiable headers with which mass unsubscription could be performed more easily victims, instead of hunting for the right places to click, potentially even in mails written in an unknown language.

The described problem is interesting, and properly tackling it can be a game changer for many users who will suffer this kind of abuse, and the article is easy to read and soundly supports its claims.

Iustin Pop: Yes-yes, still alive!

Wed, 05 Aug 2026 17:34:00 +0000

I am not sure what happened, but my interests have changed significantly, and… I haven’t blogged, I haven’t done any open source work, and didn’t even process any pictures for the entire year. Not because anything went bad, just… new stuff, new interests, life changes.

However, still alive, and still struggling with sports, and with sleep :)

On the positive side, on a recent mid-length flight, I thought — I haven’t done any work on Corydalis, since last year I closed quite of a few of my “must have” features, so probably, nothing else to do for now, right? I opened an editor and started thinking about ideas, and surprised! One hour later, I had written down enough ideas for a couple of months of work. So now just need to find the time… but can’t wait for the planned things!

Stay well!

Enrico Zini: Gnome refusing to suspend

Wed, 05 Aug 2026 07:57:52 +0000

I'm tired, I want to do go bed. I click "sleep" on gnome shell, nothing happens.

Swearwords.

I want to go to bed. I might have want to put my laptop in a bag and run to catch a train. I hate when this happens.

systemd-inhibit --list --mode=block doesn't help much:

$ systemd-inhibit --list --mode=block
WHO    UID  USER   PID  COMM            WHAT                                                     WHY                        MODE
enrico 1000 enrico 3042 gsd-power       handle-lid-switch                                        External monitor attached… block
enrico 1000 enrico 3037 gsd-media-keys  handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses  block
enrico 1000 enrico 2878 gnome-session-b sleep                                                    user session inhibited     block

After much googling I found out about gnome-session-inhibit:

$ gnome-session-inhibit  --list
mutter: idle-inhibit (idle)
/usr/lib/chromium/chromium: Playing audio (suspend)

Found the right tab in chromium, paused playing, sleep works again.

My sleep was a good half an hour overdue, and all I got for it was to write this blog post.

Of course Gnome could have shown me its inhibitor list instead of doing nothing, since it has that information, but it didn't.

What I really would expect is that if I intentionally click a suspend button, audio and video playing wouldn't inhibit the suspend. Maybe in a future version of Gnome?

Russell Coker: Monitors for Work

Tue, 04 Aug 2026 22:41:18 +0000

The Corporate Monitor Issue

Some time ago I worked in the IT department of a company that had a corporate standard of two 27″ FUllHD (either 1920*1080 or 1920*1200) monitors for the desktop. I was pushing to make the standard be one 32″ 4K monitor or the two cheaper monitors. They ended up making one 27″ 4K monitor an option which was still a better option for many users than two FullHD monitors due to having twice the pixels even though it had half the screen area. It was a surprise to me when hardly anyone took up that option.

One man who worked there brought a wide curved monitor from home and ran with one of the FullHD monitors on each side of that. As an employee in the IT department I had concerns about expensive personal equipment being used in the office regarding who’s going to pay the bill if it gets broken. But I was assured that it was his old monitor that he didn’t need after buying a better one for gaming at home and he wouldn’t be too upset if something happened to it.

This isn’t the only time I’ve witnessed such problems of companies paying large salaries for skilled people and providing poor equipment for them to do the work. One previous time I raised a OH&S issue because the outdated monitors were so blurry but the company determined that the monitors wouldn’t cause health problems and spending $150 per employee on better replacements was a waste of money.

Computer hardware tends to become cheaper over time and one thing that has become really cheap recently is portable monitors. Kogan has a 15.6″ FullHD monitor with USB-C and mini-HDMI inputs for $89 [1]. It wouldn’t be difficult for someone to put one of those on each side of the monitor or monitors that their employer provides and put them in a desk drawer at the end of the day to minimise risk. The same Kogan page has a 16″ monitor with 2560*1600 resolution for $189.

Company Ownership

I previously wrote about the potential benefits to companies in not owning all those keyboards, mice, and headsets when they could just give each employee the money and have them buy their own [2]. I don’t think we are at the stage where that can be applied to monitors as the cheapest price for a decent monitor is about $500 which takes it out of the disposable price range that keyboards and mice are in. Also from an IT support perspective there are real support issues with monitors and cables having compatibility issues. But paying small amounts of money to reimburse employees who buy cheap portable monitors to supplement their main monitor is a more reasonable option. For some people that will allow noteworthy improvements in work performance.

Who Will it Help?

I don’t think that adding such portable monitors will directly help the majority of workers. I think that to maximise performance and efficiency we need to chase the long tail of improvements. Big monitors, really big monitors (65″ at a larger distance), multiple monitors, standing desks, and whatever else people want.

There was some research from Microsoft some years ago (back when 27″ was a really big monitor) showing that some tasks had a 50% increase in performance with a larger monitor. Now that 27″ is about the smallest monitor size commonly available the potential for improvement is reduced. Probably most workers now already have monitors that provide the benefits to them that the “big monitors” in Microsoft research provided. But there will always be some portion of the user base who will benefit. If you can get a 50% performance boost for 1% of the users that’s really worth doing. If you can get a 0.5% benefit for 100% of the users that is also worth doing and will theoretically give equal benefits.

Costs of Employees

It is claimed that the total cost of an employee including all overheads of management and providing office facilities etc amounts to twice their base salary. If that is the case then a minimum wage employee in Australia costs $100k per year, someone at the low end of the IT pay scale costs $200k, and someone at the high end of the IT scale is around $400k. It seems clearly worthwhile to spend $1000 in hardware purchases for a $100k employee who declares that it will really help their work, anything which is noticeable to the user is going to be more than a 1% difference in performance.

For someone at the high end of the IT pay scale spending $40,000 on hardware to improve their performance could pay for itself. This is not only due to direct return on investment but because the people who do such work are often in key roles in important projects. If there’s too much work for one person on minimum wage to do then you just hire another person. You can’t hire another senior IT person and have them just do the work, it can take months to get up to speed.

But as management in corporations seems unable to recognise this cheap hardware employees can afford to buy with their own money can bridge the gap.

Job Interviews

In future when interviewing for jobs I’ll ask about the hardware that’s to be used. I won’t say “I’m not interested in this job offer because you don’t respect your employees enough to buy adequate hardware”, but I may make it a condition of working at a company that the hardware on my desk will not be obsolete.

Petter Reinholdtsen: FreeCAD MCP with llama.cpp, toy or tool?

Tue, 04 Aug 2026 09:00:00 +0000

After seeing a video a few months ago demonstrating how a proprietary CAM solution uses machine learning and large language models to automatically generate CNC instructions, and successfully testing it on a real CNC, I began wondering if the same could be achieved with free software. I still do not know the answer, but I may be getting closer to finding out. Two weeks ago, I came across the video "I Connected Claude AI to FreeCAD (And It Models Parts Like an Engineer)" by Make Form, which introduced me to the FreeCAD MCP project. Even though the video creator apparently believes it is acceptable to download and run random binaries from the Internet on a local machine (his setup uses UCX), I do not. I would probably have left the project alone entirely if I had not noticed that all of its dependencies are already available in Debian. This significantly boosted my motivation, so I set out to test it using packages built from source on Debian rather than relying on untrusted binaries.

The first hurdle was that the MCP SDK for Python was not present on my Debian Forky test machine. I initially believed it was missing from Debian altogether, but it has been available in Debian Unstable for about a month and is only absent from Forky because some automated tests fail on architectures like riscv64 and s390. Fortunately, backporting it was straightforward using `apt-get source -b python3-mcp`. The next hurdle involved an outdated version of the Validators Python library. Since I am a member of Debian's Python team, which maintains this package, updating it to a sufficient version for FreeCAD MCP was relatively easy. I could not upgrade to the latest upstream release due to a new dependency on an Ethereum-related library, so I settled on a 2024 version.

With those dependencies in place, I proceeded to create a Debian package for FreeCAD MCP. I had previously submitted a request for packaging of FreeCAD MCP to gauge interest while deciding whether to prioritize maintaining it myself. Because salsa.debian.org blocks access from Tor users like myself, I published my draft packaging scripts in a Git repository on Codeberg as the Debian FreeCAD MCP project and got it working with the FreeCAD 1.1 version in Forky. I initially struggled with the button controls for the MCP feature, which led me to submit a pull request titled "Fixed startup sync of checkable toolbar buttons" proposing a fix. Once this confusion was resolved and the MCP setup was enabled via the GUI, I was able to run FreeCAD completely headless using `xvfb-run` on a machine without an X server to generate models. I am using a private LLM service running the Debian package of llama.cpp with the Qwen 3.6 model downloaded from Hugging Face, configured with a maximum context window of 105k tokens. I also tested the Bonsai model on my test laptop; initially, its context window was too small (8k and 16k could not accommodate the FreeCAD MCP instructions), but even after increasing it to 32k, it proved useless for generating FreeCAD models so far. I've used Claw Code, Aider and Open Code with my server so far, and for this test I ended up with OpenCode because it was easy to set up to use an MCP. Because none of my LLM services are set up to be multimodal (capable of processing both text and images in this case), I configured the MCP to return only textual feedback from FreeCAD. I am unsure if this is a major limitation, though I suspect it might be.

My testing experience remains limited, with no clear successes yet. Part of the issue likely stems from my ability to provide effective instructions for modeling 3D objects (I am relatively new to FreeCAD, English is not my first language, and I lack a precise vocabulary for describing construction features to an LLM). Nevertheless, the LLM has demonstrated the capacity to create 3D models in FreeCAD. In one of my first tests, I asked it to generate a cube and then produce CAM/G-code instructions for a CNC machine. It did output G-code (which remains untested), but I was surprised to find that it bypassed FreeCAD's built-in CAM module entirely and instead generated an external Python script to produce the code. This was not quite what I intended, though my instructions were probably unclear. The Qwen model with OpenCode seems to strongly prefer programming directly; it frequently executes Python snippets inside FreeCAD to achieve its goals rather than using the standard sketch-and-extrude workflow I am accustomed to. In another test, I asked the LLM to create a parameterized pipe assembly to see which of FreeCAD's parametric tools it would choose, but found no evidence of traditional parametric features in the output. When prompted, the LLM explained that the parameters were embedded directly in the Python script used to generate the model, rather than in native FreeCAD features. With more explicit instructions, it eventually created a FreeCAD spreadsheet to manage the parameters. The resulting model looked much closer to my expectations and could have been useful with further refinement. My so far last experiment was less successful: I asked it to design a pipe clamp, but the LLM repeatedly failed to position the clamping screws in a way that would actually secure the brackets around the pipe. It is unclear whether this limitation lies with the model, my prompt, or other factors.

Based on my testing so far, I am uncertain whether FreeCAD MCP is merely a fun toy or a genuinely useful tool. I will only commit time to maintaining it in Debian if it proves to be practically valuable. I would welcome feedback from anyone who has experience with the project, preferably via the original request-for-packaging mailing list thread. Alternatively, I am available in the FreeCAD and Debian AI IRC channels for further discussion.

As usual, if you use Bitcoin and wish to support my activities, please send donations to 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Anuradha Weeraman: Plan 9 from Bell Labs, the little OS that could

Tue, 04 Aug 2026 00:00:00 +0000

Screenshot by VulcanSphere via Wikimedia Commons · MIT License

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.

References

[1] Ken Thompson Interview, March 6, 2024

[2] Yoann Padioleau — Principia Softwarica, May 9, 2026