This is amusing, a flaw in the crypto-currency Zcash allowed generating Zcash from nothing and there s no way to know if anyone did that [1]. Cory Doctorow wrote an insightful article for Locus Magazine about corporate valuations and why companies claim SciFi technologies [2]. Charles Stross wrote an interesting retcon of James Bond [3]. Trakkr.ai has an intresting post comparing political bias in LLM models, the site has lots of other comparisons of models too [4]. Wouter Verhelst wrote a blog post about his tested usage of LLMs for code generation and the conclusions about what it will do to the FOSS development process, not a lot of new material but he put a lot of good ideas together in one place [5]. Here is the git repository for the programs used for the ssh-audit.com site, really good setup for checking ssh configuration [6]. The isaiprofitable.com site is periodically updated with the profit/loss totals for AI companies, no surprise that every company is losing money apart from NVidia and NVidia are investing in the other companies [7]. Elvira Bary wrote an informative article about Russia s inability to build or design anything good [8]. Looks like we are at risk of another Chernobyl Lev Lafayette wrote an interesting blog post about the Sunway TaihuLight supercomputer with over 10,000,000 cores [9]. Point Free wrote an interesting blog post about running the Gemma 4 LLM which is 25G of data at a usable speed on a Xeon system with DDR3 RAM and no GPU [10].

• [1] https://tinyurl.com/2cxx2e6h
• [2] https://tinyurl.com/2cxotle7
• [3] https://tinyurl.com/2bgapt88
• [4] https://trakkr.ai/bias
• [5] https://tinyurl.com/22s2fome
• [6] https://github.com/jtesta/ssh-audit
• [7] https://isaiprofitable.com/
• [8] https://tinyurl.com/26p4lkr4
• [9] http://levlafayette.com/node/808
• [10] https://point.free/blog/gemma-4-on-a-2016-xeon/

Review: The Folded Sky, by Elizabeth Bear

Series:	White Space #3
Publisher:	Saga Press
Copyright:	June 2025
ISBN:	1-6680-7812-0
Format:	Kindle
Pages:	483

The Folded Sky is a far-future space opera and a fairly direct sequel to Ancestral Night, but with a different protagonist. You do not need to have a vivid memory of the previous book to read this one. It is somewhere around Elizabeth Bear's 31st (!) novel, depending on how one counts and what one includes. Sunyata Song is an archinformist, which is sort of an archaeologist, sort of a librarian, and sort of a historian. She recovers, decodes, and organizes information so that it can be preserved and made usefully available. As the book opens, she is, after an exceedingly long white space journey in an actively hostile ship with a (to Sunya at least) an atavistically off-putting crew, reaching her goal: a vast artifact that I won't describe further to avoid any spoilers for Ancestral Night. She is eager to get to work, an eagerness that is both heightened and made more anxious by the discovery that her academic rival and abusive ex has arrived before her. The pirate attack doesn't help, nor (at least at first) does the surprise appearance of her wife and kids. The opening of this book is a lot of infodumping mixed with nearly stream-of-consciousness emotional dumping. The style shift in this series continues to surprise me; previously, Elizabeth Bear books avoided reader hand-holding to the point of bafflement if you weren't paying close attention. Not here. The Folded Sky takes the shift perhaps too far, and I almost stalled out at the start of this book when Sunya's near-constant self-conscious litany and analysis of fears and concerns started feeling like whining. The book picks up considerably after the attempted murder. About a third of the way through, The Folded Sky feels like it's settling into a recognizable subgenre of murder mystery except set in the far future with fascinating technology and aliens. There has been an attempted murder on a closed station besieged by pirates. There is a law enforcement officer present, but they don't have a lot of investigative experience. For various reasons, Sunya decides to start poking around while being conscious she has no idea what she's doing. The bumbling detective is a common trope, so I thought that was where the story was headed. It is, sort of. There is a mystery and Sunya is involved in solving it. But that's only a small fraction of what's going on, and by the end of the book the plot has shifted firmly back to the genre of space opera, with a side note of family... drama is the wrong word. Whatever one would call a story about raising a rebellious teenager while trying very hard to not turn conflicts into actual drama. I am fascinated by the characterization of this book. Sunya is something of an emotional mess, but Bear doesn't use that fact in the ways that I would normally expect. Similar to Ancestral Night, I finished this book thinking that The Folded Sky is primarily an examination of rightminding, but a more subtle one than the previous novel. Rightminding is a central technology of the White Space series, and I suspect its intended thematic core. Humans in this civilization are equipped with near-universal implants that allow conscious manipulation of one's neurotransmitters and thus emotional state, either by the wearer or by a helpful nearby AI. The fox, the implant used to accomplish this, comes with some other features such as sensory recordings and the ability to load ayatanas (James White style personality recordings to provide some bit of necessary expertise), but rightminding is its primary and most frequently-used function. It is the critical technology that allowed humans to break out of cycles of endless war and join the other peaceful inhabitants of the galaxy in a shared civilization. The name is (intentionally, I assume) Orwellian because Bear knows that many readers, particularly those from the US who have been steeped in simplistic libertarian ideas, will find the idea profoundly creepy. (This was a major plot point in Grail.) This book is not the argument for the technology, though; Bear dealt with that in Ancestral Night. This book is a look at its practical messiness for a person who needs a lot of psychological support. Sunya is anxious, prone to catastrophizing, hates surprises, has some PTSD-style symptoms around space habitats due to earlier trauma, and is also dealing with the unwelcome reappearance of her ex-girlfriend who stole her work. Her first-person narration tends towards insecurity and anxiety spirals, and in another book this might signal an unreliable narrator. In this book, though, there are no dramatic emotional revelations or backstory twists the way there were in Ancestral Night, and the resolution of her troubled relationship with her daughter only partly hinges on plot developments. Instead, Sunya muddles through, with a lot of self-analysis, help from her fox, and a great deal of support from her wife. This makes it sounds like the emotional mess at the start of the book is left unresolved at the end, but that's not true at all. The muddling through works! Sunya keeps doing things that I thought were foreshadowing some catastrophe, but she knows herself better than the reader does. Bear largely avoids the sudden ruptures that are normally used to resolve emotional problems in fiction. Instead, Sunya spends a lot of time and energy working on her thinking and her relationships while trying to be ethical and useful, and those efforts slowly bear fruit. I'm worried this makes the book sound boring; rest assured that it isn't. This emotional subplot is only an undercurrent in the novel, and the main plot has enough weird science, alien aliens, and space opera drama to satisfy my page-turning desires. I'm focusing on the emotional arc in this review because I find it so unusual and so oddly compelling, particularly in retrospect. This is not how one normally does emotional development in a novel. Sunya's fox and rightminding aren't even the focus except when the pirates express their typical libertarian disgust for the idea. Rightminding is an entirely normal part of Sunya's life that she relies on. It doesn't solve all of her problems, but it gives her a foundation from which to tackle them in the slow and frustrating and inconsistent way that is required outside of novels, via a long series of small decisions to be the person she wants to be. I think The Folded Sky will be more hit and miss for readers than the other books of this series. Sunya was, for me at least, a much harder character to like early in the book, and it takes quite a while for the plot to get going. But this is one of those books that I've not stopped thinking about since I finished it. I think it makes a fascinating pair with Ancestral Night. The first book makes the philosophical argument for rightminding, and this book shows the practical reality with all of its messiness. The Synarche has some significant flaws (including the status of AIs, which is another interesting subplot), but it's a workable system. It feels rare to read a science fiction novel that shows this level of messiness without pairing it with an argument for radical change, and as frustrating as it was to read in places, I am intrigued by the overall effect. Sometimes acknowledging problems and working on them within an existing framework works. Followed by a book tentatively titled Shipwreck Star that does not yet have a release date. Rating: 7 out of 10

Review: Platform Decay, by Martha Wells

Series:	Murderbot Diaries #8
Publisher:	Tor
Copyright:	2026
ISBN:	1-250-82701-9
Format:	Kindle
Pages:	245

Platform Decay is the eighth book in the Murderbot science fiction series. You absolutely should not start here, but you also don't need to remember the specifics of the previous books. As the story opens, Murderbot and a friend (the identity of whom is a spoiler for previous books) are infiltrating a Corporation Rim torus, a massive space station that encircles a mined-out planet. (Like most science fiction megastructures, this is more space than the plot really requires.) Murderbot's mission is to exfiltrate some of Dr. Mensah's family members who have become entangled in corporate shenanigans. The corporates are eager to get revenge for the events of System Collapse, not to mention the other times Preservation Station has upended corporate plans. Murderbot's job is to stop them. The group, in addition to one of Dr. Mensah's partners, includes an older woman and a young child. Murderbot is analytical and of course not at all emotional about children, which is reliably a good time. Also, the older woman is gruff, stubborn, and thoroughly enjoyable. There are, of course, complications that lead to picking up more children and going through rather more of the torus than Murderbot wanted to explore. Each section of the torus is run by a different corporation and has a different constructed environment and visual aesthetic, so there are a lot of opportunities for fights, daring escapes, and incidental trouble. Also, well:

So I had installed a mental health module. I know, I was surprised I did it too.

After the events of System Collapse, University Medical decided that Murderbot needed a bit more metal health support.

The only reason I agreed to it was that the mental health module didn't actually try to adjust my processing or core programming or anything; it just monitored my organic neural tissue. When my neural tissue started to generate weird chemicals and whatever, it would ping me to "check in with my emotional state." Seriously, I could have coded that myself. (I told Dr. Bharadwaj that, and she said, "Would you have ever coded that yourself?" which was totally unfair and also correct. I would never have done that.)

Speaking as someone whose neural tissue sometimes generates weird chemicals and whatever, I sympathize. The specific form this module takes is periodic "emotion check" parentheticals throughout the narration, which I found utterly delightful.

I ran that through risk assessment and it produced the equivalent of a shrug. (Emotion check: Shrug sigil right back at you, you piece of shit.)

This is otherwise an extended action movie sort of a book, much like several of the early novellas. There are no major political or interpersonal developments here and the usual cast (apart from Murderbot) is mostly absent. Instead, we get an extended, dangerous journey through a corporation-controlled habitat, mixed with Murderbot trying to interact with humans in a way that minimizes its annoyance while being hopefully reassuring. It's competence porn with awkward but surprisingly heartfelt emotional bonding, not that Murderbot in any way wants to bond or would appreciate that description. I doubt this will be anyone's favorite entry into the series since there are none of the big reveals or major leaps of character development there have been in the past few books. But, like all Murderbot books, the narrative tone is wonderful and all of the small asides and little moments of character interaction are an utter delight. If you've gotten this far in the series, you know what I mean and you'll be as happy to read more of it as I was. There is a part of me that is hoping for some major plot development, and I always want to see more of ART (who has no significant role in this book), but Wells has the narrative style down so perfectly that I would read and enjoy a book about Murderbot doing just about anything. If you're this far in the series, you probably don't need a review, and since this is an action-heavy adventure rather than a character growth novel, I don't have a lot more to add. There's a new short Murderbot novel out and you want to read it. Recommended to everyone who enjoys the series. Rating: 8 out of 10

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 1282 other packages on CRAN, downloaded 47.1 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 697 times according to Google Scholar. This versions updates to the 15.4.0 upstream Armadillo release made on Thursday. We had run a complete reverse-dependency check leading up to it, asserting there were no issues with packages dependent on it. As it sometimes goes with that many packages involved, one CRAN package reported one test failure. And it turned out to be both unrelated and pre-existing. But sorting this out over one round of email delayed things by a day. And then I went cycling for a good cause so this announcement post comes a little later than usual. The package has also been updated for Debian, built for r2u, and by now also at CRAN for the different binary releases. All changes since the last CRAN release follow.

Changes in RcppArmadillo version 15.4.0-1 (2026-06-17)

• Upgraded to Armadillo release 15.4.0 (Medium Roast Agave)
  • Added fill::nan, fill::pos_inf, fill::neg_inf as optional fill forms for the Mat class
  • Added .push_back() for appending elements to vectors
  • Faster handling of find() within .elem()
  • Faster element-wise min() and max()
  • Faster conv_to when element types of input and output objects are the same

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

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. You can also sponsor my Tour de Shore 2026 ride in support of the Maywood Fine Arts Center.

Through work, I have paid license to windsurf (recently renamed to "devin"), an application for LLM-based (aka, "Agentic") development. I hadn't been using it that much, but in an effort to more clearly understand how this whole AI development thing works, I decided to give it a closer look recently. My conclusions: In its current form, this whole LLM wave is problematic for multiple reasons. But ignoring that, and looking at the technology only, I can say that:

• it is a paradigm shift;
• it is, at the technological level, a positive evolution;
• and it is a threat to free software.

Problems Lest someone (incorrectly) assume that I am arguing in favour of the current state of affairs with regards to LLMs, let me state this first. The way LLMs are built today is highly parasitic. Websites are downloaded in whole, at unsustainable rates, regardless of the consent of the people who made the original content. The result is predictable: servers get overloaded, server administrators attempt to implement various mitigations. Some of these mitigations work; some do, for a while; some are entirely useless. In actual fact, the mitigations are an arms race -- if too many people implement the same mitigation, then the people who try to build yet another LLM so they can extract rent will just try to work around the mitigation, eventually they will succeed, and you'll just have to come up with another mitigation. It's a bit like spam; you introduce regex-based spam filters, they introduce spelling mistakes, you introduce bayesian filters, they add a large batch of markov chain-generated semi-nonsense words made invisible by markup, you add filters to block emails with such markup, they move the text into an image. We have working mitigations today, but eventually we'll run out of ideas. LLMs glob up everything they can while ignoring the license of the source material. The people who push those LLMs claim that pushing the source material through the machine learning algorithms makes the output of the algorithm distinct enough from the source material that the license no longer applies; I'm not so sure that this is true. I guess the New York Times v OpenAI lawsuit will teach us some of the answer to that question here, but even so the ethical questions about "is it OK to bring down another server just so we can download the internet for another for-pay LLM" are still open. And regardless of what the law states, my opinion on "you're using my copyleft code to generate code under a different license" is not something you might like if you agree with the rent seekers' opinion on the subject. That all being said and true, the technology works. You can have a "conversation" with an LLM that resembles a human one. If you pass it some data, you can use plain english to ask it questions about that data, which is a lot easier than to ask it about that in a formal way. You can request it to generate some code, and it will generate something that looks like what you need and that will be mostly correct for like 95% of the time. Now, yes, 95% of the time is not 100% of the time, and no, you can't ask it to "write me a piece of software that implements this 300-page requirements document and get back to me when you're done", because it will fail, and you won't know where it has failed, and you'll take it into production and expect everything to be fine because it won't and this one minor logic bug will cause half your servers to spin and consume credits with your infrastructure provider with nothing to show for it. But that doesn't mean you can't use an LLM to build a large piece of software. It just means you have to understand the LLMs limitations and strenghts, and use them correctly. Here's what an LLM is good at:

• Generating plausible text
• Interpreting text to figure out what a plausible meaning or summary of that text is
• Giving vague indications as to what the probable context of a given body of text is.

It turns out that that's enough to use the LLM to build a reliable piece of software, provided you do it right.

Paradigm shift An LLM can generate text by the truckful. The generated text could be code. Given a good enough LLM, the generated text might even run and do something useful. You can try to blindly run the code, and if it doesn't run correctly, you can paste the error message to the LLM, and it can tell you what went wrong and how you could possibly fix it. This creates a feedback loop: you ask it for an amount of code, you run the code, you receive an error, you tell it that the code is problematic and give it the error message, it makes changes to the code, now you have something that at least no longer fails at startup. If you ask it to add tests to make sure that your code acts as per your specification, now you get an error if and when the code doesn't act as per your specification. Or, well, at least not as per the part of the specification that was correctly turned into a unit test by the LLM. LLMs have a context window, so if the error message is pasted in the same conversation as where the code was generated, it is able to reuse the earlier prompts to refine how it should interpret the error message that you received. You can't really paste the source code of an entire application into the prompt of your LLM, that would quickly overrun its context window. But LLMs also allow you to provide some form of background information -- a document, say -- on which you ask it to reason. It will interpret that document, but doing so uses less of the LLMs context window. So providing the LLM with your application's source code as background information can help it understand better how your code interacts. This is especially helpful if you only provide the LLM the background information relevant to the actual question. So now if you are able to:

• Create background context with your application's source code
• Have the LLM generate a first draft of your requested change, plus the tests to make sure it works
• Compile (if applicable) the generated code (and tests) and run said tests
• Return any error messages to the LLM with a request to correct the error

Then the combination of "getting it 95% right off the bat" and the above feedback loop means you can generate syntactically correct code, that probably does what you need, in minutes. I say "probably" for a reason. There are going to be cases where you specify a request without a number of details (because they are implied), and the LLM will get most of those details right but just not implement the one bit because it's an automaton and it doesn't think. Or you will ask it to make sure that two bits of the application look exactly the same, without specifying that they must act the same, now and in the future, and it will just generate the same block of code twice and then in a future change it will change one but not the other. But if you review the changes, and you have experience as a programmer, you will be able to spot most cases where the LLM got it wrong. And so it's possible, if not necessarily easy at first, to use an LLM to generate mostly correct code. There are certain places where "mostly correct" code is not desireable. But equally, there are also cases where, "mostly correct" is good enough. After all, most of the software you run today -- the bits of it that weren't, yet, generated by an LLM -- is only "mostly correct", too, because to err is human and we all make mistakes. If not, there wouldn't be any CVEs and your software would never do anything wrong. Now, doing the feedback loop described above is certainly something you could do manually. You could open an account on one of the LLM websites, upload the source code of your application, ask it to generate some new feature, download the newly generated feature, run it, and then copy/paste any error messages back into the LLM. But that's a lot of manual work of the type that computers are pretty good at. So that's what the "windsurf" tool helps you with: you run it inside your IDE -- either a VSCode-based tool that you download from their website which comes with their product preinstalled, or a separate JetBrains plugin that you can install. You can then open your entire relevant codebase in a workspace in your IDE. You then ask the LLM, through the IDE, to generate a new feature in your codebase, and to also generate the test while it's at it. It will use a mixture of LLM interpretation and non-LLM functionality to scoop out the relevant bits of your codebase to send to the LLM as background information, will send it your prompt, will download the generated code and patch or create files, will compile (if required) and run the newly generated code and tests, and will refine the generated code if the tests produce any errors. All mostly automatic; by default, running anything requires explicit confirmation. You can turn that off completely (probably not a good idea), or you can give it a whitelist of things that you don't want to confirm (perhaps OK), and the tool also passes standing instructions to the LLM to never generate any command that deletes a file (which, like with any LLM, can be overridden, but it requires you to be very stubborn and to use more credits than you'd probably like). All this put together means you can build something without writing any piece of code, provided you do it right.

A technically positive evolution Don't go and say, "here's a 300-page document, read it and write whatever the document says". It will get it wrong, it will write a massive test suite that it will only run at the end, it will choke itself up trying to interpret the massive amount of failures it encounters, it will fill up its context window and it will start to forget some of the requirements. That won't work. But what you can do -- what I did, in fact -- is this. First, create an empty workspace. Don't put any code in it. Then, tell the LLM to generate a backend framework using technology X and a frontend framework using technology Y that initially only says "hello, world". Also add tests to it, and run the tests. It will do that. You'll not get much, but it will work. Then, ask it to add some UI elements. A login page, perhaps. A navigation bar. Small things. Most of it doesn't have to be functional -- but tests must be there for the bits that are, and have it run the tests and evaluate the results. Rinse, repeat, until you have a working application. Importantly, in between the steps, you should also run the application yourself and see if the change was implemented correctly. Sometimes it won't be. Sometimes there will be a subtle bug -- I at one point had a the application hang after a few minutes. Sometimes you tell it that there's a subtle bug, and it will discover it more quickly than you could, and it will fix it, and in implementing the fix it will uncover another bug, and then you have to fix that one -- the fix it came up with for the hang was to move something to an async process on the server, which caused the application to start spinning while trying to create hundreds of async jobs (this is when I realized that the hang was a deadlock due to some part of the codebase doing something that indirectly triggered itself). Sometimes it will try to fix the bug you tell it about, and you'll see that it's going off on a tangent that has nothing to do with what you're seeing. It's important to keep an eye on what it's doing, so you can guide it back on track when that happens -- when I told it about the hang, it started investigating the part of the code which sends out emails, thinking that it could hang while waiting for sendmail to finish, but the hang was happening when the application was idle, not when it was sending out emails, and only when I told it about it happening when it was idle did it find the deadlock. So it's not a fully automatic process, and it needs to be guided by someone who knows what they're doing. But if that is the case, you can come up with something that works. I spent evenings and breaks for about a week, and I managed to create a working application which, had I written it by hand, would have taken me a few months of full-time work to come up with. And I now have a side project, fully complete and working, that I had been thinking about doing for more than a decade, but never got around to actually doing, because of all the work that would be involved and I just didn't see myself having the time for. It's not perfect code. But it's mostly good enough, and it will perform the job it needs to. And it looks far slicker than most of the side projects I've done in the past, because in the past I would prioritize between implementing new features or making something look slick, and I would decide that the new feature was more important because it's only for me and there's only me and nobody cares if it looks good or not and I don't have three weeks to come up with something that looks better. But here, I found myself sometimes spending 10 minutes writing a prompt with instructions on making things look better. Because what's 10 minutes when you just spent an hour writing down and refining specifications for functionality and tests? There are a number of other things in which an LLM can help a programmer. For instance. I received a bug report recently in a project I'm paid to maintain that I couldn't make heads or tails of. I opened the source code in my windsurf IDE, pasted the bug report in the prompt, and then requested the tool to analyze the source code and the associated logs and tell me how the described behavior could be happening. It turned out that I had overlooked something, but with the help of the tool, I found the bug in minutes. I was trying to understand a particular part of a large codebase that I didn't really grasp very well. I loaded the codebase in the tool, and asked it to explain to me how a particular action is performed by the code. I requested specific functions and line numbers. I now have a far better understanding of how the code works, and will be able to write that patch that I've been wanting to write for years -- without using the LLM. I have been struggling for, literally, years with understanding why another tool that I maintain was misbehaving in a particular way but only in Firefox. I opened the codebase in Firefox, explained the buggy behavior in plain English, and asked it to explain how this could be happening. It picked up some obscure corner case behavior of ffmpeg and mp4 containers that I was not aware of and that perfectly explained why things were misbehaving in the way that they were. At the same time, there are limitations. Giving an LLM a codebase that was originally generated by an LLM (either the same one or another one) seems to work well. Giving it a codebase that was written by a human and expecting it to correctly update it seems to be more error-prone. I did one or two of those as a trial, and it is more problematic than anything. An LLM is also not intelligent, notwithstanding the popular term of "Artificial Intelligence". On multiple occasions, I've asked it to write a test case for some code that was not set up to do so; and rather than suggesting a refactor is required, it would instead copy the code that needed to be tested and then test the copy, rather than the original. The tool has made multiple similar errors. I have sometimes people describe agentic coding as "similar to interacting with junior programmers", but that is not the case. A junior programmer will either fill in the gaps in your specifications, or ask for clarification when something seems off. The LLM will not do that; it will do what you ask, exactly that and nothing more. If you missed a corner case in your specification, then all bets are off. I remember learning about programming language generations in college. A first-generation language is "machine code", a second-generation language is "assembler", a third-generation language is any high-level language such as C, Perl, or Pascal. I've forgotten what set a 3rd-generation language apart from a 4th-generation language. But I remember the definition they gave me for a 5th-generation language: "you tell the computer what to do, and it will do it". At the time, I thought it was ridiculous. Nobody could ever write something like that. But it's here. And it's a threat to free software.

A threat to free software? Yes. There is the obvious part where most of the well-known LLMs are non-free software. I mean, there are some "open source" LLM models. The windsurf tool that I used doesn't allow you to use them (directly), but they're there. There are also open source applications that implement what the windsurf editor does. So it's definitely possible to work like this without resorting to non-free software and non-free services, even though the non-free LLMs might be a bit ahead of the curve of the free ones. But that's not what I mean. And there is also the obvious thing which I mentioned earlier in this post, which is that the people who try to build LLMs are doing it in unethical, disgusting ways, causing downtimes and disregarding licenses for whatever they can get their grubby hands on. Ideally we wouldn't be in that situation, and ideally this wouldn't be a problem, but we are where we are. And there's the obvious thing where the OSI sold itself out and declared that a machine learning program can be open source even when the very things it was built from -- the training data -- is not available. That's a major issue that the free software community needs to fight against, but there's not really anything that that is a threat to free software. You just build your own, free software, LLM, and you're done. The actual threat is in funding and developer support. Most large businesses do not care about free-as-in-freedom software. They like the free-as-in-beer part, and they appreciate that the free-as-in-freedom bits can make the software more customizable. They are (mostly) happy to do sponsorships of the free-as-in-freedom projects that they use if that means their free-as-in-beer usage of the software gets improved. But why would you care about all that when you can just generate the code you need, rather than interacting with an open source community that may or may not care about your business's interests?

Where to go from here Although I think the moral and environmental issues with LLMs are real and problematic, given the experiments I did I am not convinced that the concept of interacting with a computer system in natural language and to use it to generate code is necessarily deficient. There are pitfalls, but they can be managed. It is possible to use such a system to create throwaway, proof-of-concept type "good enough" code bases. It can be used to interpret code bases and to understand bug reports. I believe that the major issue with LLMs has to do with that saying about hammers and nails:

If all you have is a hammer, then everything looks like a nail.

LLMs are an outgrowth of machine learning, pushed by large corporations. These large corporations have a lot of money. If all you have is money, then every problem can be fixed by throwing more money at it. The initial language models were promising but not (yet) good enough, and it seemed that one way in which they could be improved was to increase the scale of the statistics: throw more hardware (and thus money) at it, and rather than improving the efficiency of the models, just scale up. Scaling up is something that megacorporations are very good at. It's only a money problem, after all. Does that mean that "scaling up" is the only way to improve the models, though? I'm not convinced. Some hardware, such as most modern Apple and Samsung devices, ship with accelerator hardware for machine learning algorithms. There are some models that are small enough to be able to run on these devices. I don't see why it should not be possible to create a small(er) language model that can do some useful part of the above-described use cases; if not locally, then at least on a server that one can run on-prem rather than requiring that you pay rent to one of the LLM companies. The Software Freedom Conservancy has published an aspirational statement on machine learning-assisted programming that, I think, gets a lot right. It's not quite a definition, but it's something to keep in mind. Perhaps that's the way forward? More questions than answers at this point, anyway.

The Debian LTS Team, funded by Freexian s Debian LTS offering, is pleased to report its activities for May.

Activity summary During the month of May, 21 contributors have been paid to work on Debian LTS (links to individual contributor reports are located below). The team released 56 DLAs fixing 877 CVEs. May was a much busier month than usual, especially due to the disclosed vulnerabilities on linux regarding Local Privilege Escalation (LPE), that included public proof-of-concept (PoC) exploits. These reports of course impacted Debian as a whole, and the situation warrants a special mention to the Kernel Team, especially Ben Hutching and Salvatore Bonaccorso, who faced the pace and released linux packages on a weekly basis. On the LTS side, the Front Desk team also triaged a significant flow of high severity CVEs. It is also important to note that Debian 12 ( bookworm ) will be handed over to the LTS Team on June 11th. If you benefit from Debian, especially during the full 5-year lifecycle, please consider subscribing as a sponsor of Debian LTS: https://www.freexian.com/lts/debian/. Moreover, Debian 11 ( bullseye ) will reach the end of the Debian LTS period on August 31st. After that, Freexian will continue the security support under the Extended LTS offer. The team published several notable updates:

• As mentioned above, several exploitable LPE vulnerabilities in linux were published during May. Ben released the following DLAs for the Debian LTS versions:
  • DLA 4560-1 for linux (5.10)
  • DLA 4561-1 for linux-6.1
  • DLA 4572-1 for linux (5.10)
  • DLA 4574-1 for linux-6.1
  • DLA 4587-1 for linux (5.10)
  • DLA 4588-1 for linux-6.1
  • DLA 4606-1 for linux (5.10)
  • DLA 4607-1 for linux-6.1
• exim update (DLA-4580-1), prepared by Thorsten, to address a vulnerability that may result in remote code execution.
• gnutls28 update (DLA-4595-1) by Guilhem Moulin, fixes several vulnerabilities that may result in execution of arbitrary code, information leak, authentication bypass, among other impacts.
• krb5 updates released as DLA-4603-1, fixing two vulnerabilities that may yield to a denial of service. Updated prepared by Emmanuel Arias
• lemonldap-ng (DLA-4602-1), released by Abhijith PA, fixing multiple vulnerabilities
• Two imagemagick updates (DLA-4559-1 and DLA-4609-1), prepared by Bastien Roucari s, fixing several vulnerabilities
• openjdk-11 and openjdk-17 updates (DLA-4566-1 and DLA-4565-1), both prepared by Emilio, to fix seven vulnerabilities.
• php7.4 update (DLA-4586-1) to fix six vulnerabilities that could result in remote code execution, information disclosure or denial of service. Update prepared by Guilhem Moulin.
• python3.9 update (DLA-4583-1), prepared by Arnaud Rebillout, addressing multiple vulnerabilities.

Contributions from outside the LTS Team: We are greatly thankful for the contributions from people outside the LTS Team:

• Colin Watson prepared an OpenSSH update, that was released by Santiago as DLA-4584-1.
• Thomas Goirand handled a keystone update, whose advisory was done by Santiago and released as DLA-4611-1.
• Christopher Obbard kindly prepared a sentry-python update, released as DLA-4612-1.
• Christoph Goehre made two thunderbird updates (DLA-4562-1 and DLA-4582-1). As is customary, Emilio released the advisories.

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

• Andreas proposed a firewalld update for bookworm to fix a local issue that may result in bypass control rules.
• Andreas proposed atril updates for trixie and bookworm.
• Arnaud did a python3.11 upload for bookworm.
• Arnaud proposed libarchive updates for trixie and bookworm.
• Arnaud completed the systemd update for bookworm.
• Bastien completed the uploads of gpsd for bookworm. He also did an upload of apache2 for bookworm.
• Emmanuel uploaded updates of libexif for trixie and bookworm
• Jochen Sprickerhof prepared pyjwt update for trixie and bookworm, released as DSA-6259-1.
• Lukas M rdian prepared trixie and bookworm updates for nghttp2, released as DSA-6266-1.
• Markus prepared updates of tomcat11 and tomcat10, released as DSA-6329-1 (for trixie) and DSA-6328-1 (for trixie and bookworm), respectively.
• Continuing the work to replace the unmaintained p7zip fork with 7zip, Sylvain prepared trixie and bookworm updates of 7zip.
• Thorsten completed the uploads of zvbi, taglib and libuev to bookworm and did an upload of libcoap3 for wtrixie.
• Tobi prepared libpng1.6 updates for trixie and bookworm, released as DSA-6263-1.

Moreover, thanks to our partnership with Catalyst, it has been possible to extend the support for Samba 4.17, the version shipped with Debian 12. In May, several vulnerabilities were disclosed, and their patches were prepared by Catalyst. For Debian 12, the update was prepared by the Samba maintainer and released as DSA-6297-1.

Individual Debian LTS contributor reports

• Abhijith PA
• Andreas Henriksson
• Andrej Shadura
• Arnaud Rebillout
• Bastien Roucari s
• Ben Hutchings
• Carlos Henrique Lima Melara
• Chris Lamb
• Daniel Leidert
• Emmanuel Arias
• Emilio Pozuelo Monfort
• Guilhem Moulin
• Jochen Sprickerhof
• Lee Garrett
• Lucas Kanashiro
• Lukas M rdian
• Markus Koschany
• Santiago Ruano Rinc n
• Sylvain Beucler
• Thorsten Alteholz
• Tobias Frost

Thanks to our sponsors Sponsors that joined recently are in bold.

• Platinum sponsors:
  • Toshiba Corporation (for 128 months)
  • Civil Infrastructure Platform (CIP) (for 96 months)
  • VyOS Inc (for 61 months)
• Gold sponsors:
  • F. Hoffmann-La Roche AG (for 139 months)
  • CONET Deutschland GmbH (for 122 months)
  • University of Oxford (for 78 months)
  • EDF SA (for 50 months)
  • Dataport A R (for 25 months)
  • CERN (for 23 months)
• Silver sponsors:
  • Domeneshop AS (for 143 months)
  • Nantes M tropole (for 137 months)
  • Akamai - Linode (for 133 months)
  • Univention GmbH (for 129 months)
  • Universit Jean Monnet de St Etienne (for 129 months)
  • Ribbon Communications, Inc. (for 123 months)
  • Exonet B.V. (for 113 months)
  • Leibniz Rechenzentrum (for 107 months)
  • Minist re de l Europe et des Affaires trang res (for 91 months)
  • Dinahosting SL (for 78 months)
  • Upsun Formerly Platform.sh (for 72 months)
  • Moxa Inc. (for 66 months)
  • sipgate GmbH (for 64 months)
  • OVH US LLC (for 62 months)
  • Tilburg University (for 62 months)
  • GSI Helmholtzzentrum f r Schwerionenforschung GmbH (for 53 months)
  • THINline s.r.o. (for 26 months)
  • Copenhagen Airports A/S (for 20 months)
  • Conseil D partemental de l Is re (for 6 months)
• Bronze sponsors:
  • Seznam.cz, a.s. (for 144 months)
  • Evolix (for 143 months)
  • Linuxhotel GmbH (for 141 months)
  • Intevation GmbH (for 140 months)
  • Daevel SARL (for 139 months)
  • Megaspace Internet Services GmbH (for 138 months)
  • Greenbone AG (for 137 months)
  • NUMLOG (for 137 months)
  • WinGo AG (for 136 months)
  • Entr ouvert (for 128 months)
  • Adfinis AG (for 125 months)
  • Plat Home (for 122 months)
  • Laboratoire LEGI - UMR 5519 / CNRS (for 120 months)
  • Tesorion (for 120 months)
  • Bearstech (for 111 months)
  • LiHAS (for 111 months)
  • Catalyst IT Ltd (for 106 months)
  • Demarcq SAS (for 100 months)
  • Universit Grenoble Alpes (for 86 months)
  • TouchWeb SAS (for 78 months)
  • SPiN AG (for 75 months)
  • CoreFiling (for 71 months)
  • Observatoire des Sciences de l Univers de Grenoble (for 62 months)
  • Tem Innovations GmbH (for 57 months)
  • WordFinder.pro (for 57 months)
  • CNRS DT INSU R sif (for 56 months)
  • Soliton Systems K.K. (for 51 months)
  • Alter Way (for 48 months)
  • SOBIS Software GmbH (for 23 months)
  • Tuxera Inc. (for 15 months)
  • OPM-OP AS (for 6 months)

There has been a video blog post recently published with a review of Ubuntu Touch as an option to opt out of the Android world: https://www.youtube.com/watch?v=wTK6TS3pXgc Thanks to @SwitchandClick for spending time on this and publishing that video. Much appreciated. Many Issues amended in upcoming 24.04-2.0 Release When I watched that video referenced above, I continuously thought: ah... this is fixed in the next major release of Ubuntu Touch, or: ah... this is a known issue that we have on the roadmap..., or: ah... this is done in this ways by design (so it's a feature or basic functionality)... Let me just state, that most of the criticized aspects will be resolved in upcoming Ubuntu Touch release 24.04-2.0 (the tests in that video blog post have been run on Ubuntu Touch 24.04-1.x):

• Camera notch and rounding corners get honoured now by the UI
• Ubuntu Touch's default webbrowser (Morph Browser) has been bumped from Chromium engine v87 (Qt5 based) to v134 (Qt6 based), installing another browser should not be necessary anymore (note that the privacy level in Morph Browser is pretty high, so using other browsers could mean a loss of privacy).
• Bluetooth pairing agent got added to the bluetooth indicator
• Ubuntu Touch now supports Snaps on CLI level and in the OpenStore app
• Libertine has received fixes, but no substantial improvements. It mainly targets users who want to use their Ubuntu Touch device as desktop daily driver. Libertine-provided desktop apps UI-wise are often not usable on a phone-like device.

The full feature preview of the 24.04-2.0 release can be found here: https://ubports.com/blog/ubports-news-1/ubuntu-touch-24-04-2-0-beta-is-n... Ubuntu Touch App Ecosystem The app ecosystem of Ubuntu Touch is quite specific, because many apps in Ubuntu Touch have been explicitly developed for Ubuntu Touch using a widget toolkit called Lomiri.Components. However, in Ubuntu Touch we also encourage developers to provide apps written with other convergent-capable toolkits, such as QQC2-based apps or Kirigami-based apps. One reason for the very different app ecosystem in Ubuntu Touch is that many service providers don't have Ubuntu Touch on their radar when investing in app development for their services. Some Ubuntu Touch App Developers work around this by either implementing unofficial client apps for web services (e.g. the Flow app for Deezer by Sander Klootwijk), others provide the web service via implementing a web app (will not work when offline, but at least will show up as an app in the launcher). The overall solution for making Open-Store.io more familiar to users who migrate from Android is that commercial service providers start honouring digital sovereignty and start providing apps for Linux. Not just for the Linux desktop, but also for mobile Linux platforms. This dual use case can easily achieved with an app development that bears convergence in mind. App Ecosystems are also a Matter of Perspective And one more minor note: whenever I open an Android appstore or can peak over someone's shoulder using an iOS device: I always wonder: what are all these apps about??? Never heard about them. So, familiarity really depends on perspective. And perspective depends on what you are used to. Change what you do and your perspective will follow. Ubuntu Touch's root filesystem (rootfs) is Immutable Only thing from that video blog post that we haven't fixed and won't do so in the midterm future is apt-get not working on the command line. The reason for this is: the Ubuntu Touch root file system is an immutable file system and thus shall not be changed via apt-get & friends by ordinary users. There are various discussions ongoing such as dpkg-divert'ing apt-get to a wrapper shell script that spits out an error message if rootfs is mounted read-only and someone tries to install packages the Debian/Ubuntu way. Other approaches are to mount some RAM disk over the rootfs, so apt-get can be used at runtime but changes to the system get reset at reboot. However, it is possible to mount the root filesystem read-write and test newer package versions (as UT core developers do regularly, in fact). If you tinker with this, it is recommended to reflash your device (don't wipe user data, when you reflash!) from time to time, because adding packages or package upgrades to your rootfs may over time corrupt the integrity of the rootfs. One reason for apt-get breaking the rootfs and thus your Ubuntu Touch development device is that the upgrade process of the rootfs image is incremental, so update tarballs sometimes contain only those parts that got changed between this and your previous upgrade (sometimes, upgrades contain a complete rootf image, depending on the interval between upgrades). If files from an incremental update tarball mix into a rootfs that got tinkered with via apt-get, you really end up on your own. Re-flashing will grab the complete rootfs tarball and wipe the whole rootfs and reinstall a fresh version of the newest rootfs image. Developers also do this in regular intervals to ensure their test device is clean again before running more/other tests.

The next Ubuntu Touch major release is approaching rapidly, yesterday we reached a major step in the preparation of the upcoming Ubuntu Touch 24.04-2.0 release: The branching-off (see below on what that is). Ubuntu Touch 24.04-2.0 Beta is Now Available Part of this development release step is the publication of the 24.04-2.0 Beta release images, for more details and information see:
https://ubports.com/blog/ubports-news-1/ubuntu-touch-24-04-2-0-beta-is-n... And additionally, find below some background information on how we maintain various Ubuntu Touch releases in parallel via Git(Lab). In fact, the release model of Ubuntu Touch has partially been adopted from how we in Debian maintains our various Debian versions in parallel, only that in Ubuntu Touch we use Git(Lab) for maintaining the different package versions and not, like in Debian, the APT archive itself. What does 'Branching-Off' Mean? Last Saturday, in the UBports Q&A, I explained Ubuntu Touch's "branching-off", an aspect of the Ubuntu Touch release workflow based on Git(Lab). To make this accessible to even more people, here it comes as a write-up: We host many Git repositories on GitLab, and our primary work is done on the main branches, which contain the bleeding-edge code. When a merge request is deemed critical for stable versions of Ubuntu Touch, we cherry-pick it into a release series branch. Currently, we land our changes in the main branches and then cherry-pick them to the ubports/24.04.1.x branches. The 'branching off' process for the upcoming 24.04-2.x release means that our current main branches will be copied over to create new branches for this release cycle, namely ubports/24.04-2.x. This has two major implications. First, any item that hasn't been translated by the time of the branch-off will not receive any more translation updates during the 24.04-2.x cycle. This is why it is crucial that translation work is completed before the branching-off. Warning of Breaking Changes arriving soon in 26.04-1.x Daily Development UT Images Second, looking ahead to the release after 24.04-2.x, we will be approaching 26.04-1.x. The OS base will change to Ubuntu 26.04 LTS, hopefully being ready for release to Ubuntu Touch users before the end of the year. We already have a list of features we want to land there. Because we plan to include various major changes, such as the switch from Mir 1 to Mir 2, new calendar and contacts backends, Qt6-based core apps and service components, etc., the likelihood of breaking changes at the beginning of the 26.04-1.x release cycle (which will become the next main branches' target) is very high. The Ubuntu Touch 24.04-2.0 Release Schedule The current release schedule is estimated to be: 25 May 2026 [done]
Platform stability freeze 24.04-2.x 25 May 2026 [done]
String freeze 24.04-2.x 15 June 2026 [done]
Branching-off (and unfreeze 26.04-1.x development), UT image release: 24.04-2.0 Beta 22 or 29 June 2026 [coming]
Final freeze for 24.04-2.x, UT image release: 24.04-2.0 RC 6 or 13 July 2026 [coming]
Release version 24.04-2.0

For almost two decades, the PackageKit package management abstraction layer has shipped with pkcon as its command-line client. pkcon does its job, but it was always kind of a testing front-end for the PackageKit daemon rather than a tool designed for everyday use. The focus has instead been on the GUI tools, automatic system updates, GUI application managers and other front-ends. Its command names mirror the D-Bus API almost one-to-one (get-details, get-updates, get-depends), output is very plain, and there is no machine-readable mode for scripting. Most importantly though, there has been no development on it at all for almost a decade, so pkcon was stuck in its rudimentary state from that era.

Since a lot of changes will be coming to PackageKit, and testing the daemon and working with it from the command-line was not very pleasant anymore in 2025/2026, I decided to modernize the tool as part of my work as fellow for the Sovereign Tech Agency last year. pkgcli is the new command-line client for PackageKit. It is built from the ground up to be pleasant to use interactively and easy to drive from scripts.

Why a new tool?

Of course, instead of introducing a new tool, I could have just expanded pkcon instead. The problem with that approach is that the pkcon utility has been around for so long and its command-line API had ossified so much, that rather than changing it and potentially breaking a lot of scripts relying on its quirks, I decided to introduce a new tool instead. pkcon can still be optionally compiled for people who need it in their scripts and workflows.

The goals for pkgcli, and the features it now has are:

• Human-friendly command names. Verbs that read the way you d describe the task, instead of mirroring the D-Bus API 1:1: show, search, list-updates, what-provides, instead of get-details and friends.
• Readable, colored output by default (still respecting NO_COLOR and degrading gracefully).
• A real scripting mode. A global --json flag emits JSONL instead of fully human-readable output when possible, to make it easier to use the tool for scripting purposes.
• Sensible defaults. A few defaults have been changed, such as the metadata cache-age, or automatic cleanup of unused dependencies being enabled by default. This is more in line with current defaults by other tools and frontends. We also print package information in a slightly different, more readable way.
• Better handling of internationalized text. Text should now align properly in the terminal window, and we should no longer have completely chaotic text output on non-English locales (especially Chinese/Japanese).

Why not pkgctl?

Originally, this tool was called pkgctl, to match other common cross-distro tool names. However, that name was already taken by an Arch-specific distro development tool. When this issue was raised, we decided to just rename our tool to pkgcli with the next release, to avoid the name clash on Arch Linux.

Examples!

Here are some examples on how to use the new tool (some of which include the abridged output pkgcli prints).

Search for anything containing the string editor in name or description, then look at the details of one result:

$ pkgcli search editor
Querying                  [ ] 100%
  ace-of-penguins 1.5~rc2-7.amd64 [debian-testing-main]
  acorn-fdisk 3.0.6-14.amd64 [debian-testing-main]
  ardour 1:9.2.0+ds-1.amd64 [debian-testing-main]
  audacity 3.7.7+dfsg-1.amd64 [manual:debian-testing-main]
  audacity-data 3.7.7+dfsg-1.all [auto:debian-testing-main]
  augeas-tools 1.14.1-1.1.amd64 [debian-testing-main]
  emacs 1:30.2+1-3.all [debian-testing-main]
  gedit 48.1-9+b1.amd64 [debian-testing-main]
  gedit-common 48.1-9.all [debian-testing-main]
  gedit-dev 48.1-9+b1.amd64 [debian-testing-main]
[...]
$ pkgcli show nano
Package: nano
Version: 9.0-1
Summary: small, friendly text editor inspired by Pico
Description: GNU nano is an easy-to-use text editor originally designed as
 a replacement for Pico, the ncurses-based editor from the non-free mailer
 package Pine.
[...]
URL: https://www.nano-editor.org/
Group: publishing
Installed Size: 2.9 MB
Download Size: 646.0 KB

Search only within package names rather than descriptions:

$ pkgcli search name python3

Check for updates. refresh updates the metadata, then list-updates reports what s available:

$ pkgcli refresh && pkgcli list-updates
Loading cache            [ ] 100%
  cme 1.048-1.all [debian-testing-main]
  gir1.2-gdm-1.0 50.1-2.amd64 [debian-testing-main]
  imagemagick 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main]
  imagemagick-7-common 8:7.1.2.24+dfsg1-1.all [debian-testing-main]
  imagemagick-7.q16 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main]
  libdlrestrictions1 0.22.0.amd64 [debian-testing-main]
  libfftw3-bin 3.3.11-1.amd64 [debian-testing-main]
  libfftw3-dev 3.3.11-1.amd64 [debian-testing-main]

Explore relationships between packages:

$ pkgcli list-depends inkscape  # list what inkscape depends on
$ pkgcli list-requiring libappstream5  # list what requires libappstream5

Find the package that provides a capability, here the AV1 GStreamer decoder:

$ pkgcli what-provides "gstreamer1(decoder-video/x-av1)"
  gstreamer1.0-plugins-bad 1.28.3-1.amd64 [auto:debian-testing-main]

You can also have JSON output for most commands! Attach --json to any query and pipe the result straight into jq. Each line is a self-contained JSON object:

$ pkgcli --json list-updates   jq -r '.name'
cme
gir1.2-gdm-1.0
imagemagick
imagemagick-7-common
imagemagick-7.q16
libdlrestrictions1
libfftw3-bin
libfftw3-dev
libfftw3-double3

Try it

pkgcli is built by default alongside the rest of PackageKit since PackageKit 1.3.4. If your distribution ships a recent enough PackageKit, it should already be on your PATH. You can read its man page man pkgcli for more information. Feedback, bug reports, and patches are very welcome.

AI slop is invading the web. A recent story about disallowing LLM-generated submissions on Lobsters triggered a lot of debate. My personal worst offenders are LinkedIn articles with AI-generated images and uninspired articles filled with emojis from people trying to masquerade as experts on a subject they don t care enough to write themselves. While I am unhappy about this situation, I rely on LLMs for grammar, copyediting, and translation. I don t see this as a contradiction. I am a native French speaker, but I blog in both English and French. When I started writing this blog in 2011, I was composing in French and translating to English, but I found it was better to work in the reverse order to avoid unnatural and non-idiomatic constructions. One of my goals is to write good English but I never felt it was my strong point.¹ For example, verb tenses are often an issue, even if I mostly stick with the present tense. I learn the rules and forget them right away. I also don t feel like hiring an editor for something I see as a hobby. As an example, I have kept the history of the successive iterations when writing Scaling Akvorado BMP RIB with sharding :

1. the first draft, authored with the help of a thesaurus,²
2. the edited copy revised by the copyediting skill,
3. the translation to French generated with the translation skill, and
4. the human proofread of the French translation, with minor edits to the English version.

I know that LLMs may alter the author s voice when editing, but the corrections in the second step are minor. The prompt asks to apply light stylistic edits, with some guidance around avoiding passive voice, long sentences, bland verbs, and filler words. It also defines the target audience: technical with a B2 level in English. In the following excerpt, I used long time instead of long-standing. The former is missing a hyphen and applies to people a long-time friend, while the later relates to a situation a long-standing agreement. I had a hard time understanding the reason of the second change: the LLM prefers a defining relative clause to provide the definition of RIB sharding.

As the Internet routing table contains more than 1 million routes, Akvorado needs to scale to tens of millions of routes. This has been a long time long-standing challenge, but I expect this issue is now fixed by using RIB sharding, a method to split that splits the routing database into several parts to enable concurrent updates.

In the next modification, the LLM puts device instead of equipment. This is correct as equipment is an uncountable noun. I know that, but I still fall into this trap.

When Akvorado does not find a route from a specific device, it falls back to a route sent by another equipment device.

I ask the LLM to use descriptive verbs and it complies by replacing a multi-word predicate with a lexically rich verb:

The benchmarks demonstrate it has better performance than outperforms other packages, both packages for lookups, insertions, and memory usage.

It also fixes grammar errors. In the next excerpt, a list of routes is a singular expression. Moreover, stored is a state and I should not use into as it expresses a change.

The list of routes for each prefix are is not stored directly into in the prefix tree.

As a last example, consider the following snippet. The require verb accepts a noun or an object followed by a to-infinitive. I can t use it with just a to-infinitive.

An alternative would be to have one prefix tree for each peer but it would require to configure configuring all routers to export their routes.

As someone who didn t grow up speaking English, I struggle with these grammar rules despite reading a lot of English material.³ French is more complex to get started but more systematic. English is full of irregularities.

---

On each page, I disclose in the footer whether an AI modified the content. There are three levels:

• : no AI or almost no AI (e.g., grammar corrections)
• : enhanced (e.g., copyediting)
• : generated (e.g., translated from another language, even if human-edited)

Hover or tap the icon to reveal the AI s name and its role in the document.

Example of AI usage disclosure: Claude Sonnet 4.5 edited this article.

The graph below shows which tool altered each post, year by year. Recently, I applied the grammar skill to past articles. Since 2018, French articles have been translated with the help of DeepL first, then of an LLM. Since 2024, English articles are copyedited.

🖼 Graph showing the AI usage over the years. Each level get its own color.

AI usage over the years. Hover or tap a band for the details.

---

If you are strongly against any usage of LLMs specifically for writing, I hope you accept my more nuanced position on the usage of these tools as a trade-off to provide clearer and more engaging articles. Years of literature on improving English told us it is important to choose the right word to keep the reader engaged.

[ ] Good writing consists of mastering the fundamentals (vocabulary, grammar, the elements of style) and then filling the third level of your toolbox with the right instruments. Stephen King, On Writing

Official announcement European Voxit community strengthens digital sovereignty: shared codebase completed. Read the official announcement at:
https://www.voxit.org/european-voxit-community-strengthens-digital-sover... The Voxit community and platform development The Voxit participation platform is originally based on the open source Polis platform developed by The Computational Democracy Project in the United States, but since its establishment in autumn 2025, the European Voxit community has been developing an independent solution, adapted to European needs. The aim is to create an open source, interoperable and scalable participation infrastructure suited to Europe s regulatory environment and aligned with democratic values. Through this development work, Voxit is becoming a clearly distinct fork of the original Polis platform allowing Europe to develop participatory infrastructure at its own pace and according to its own governance needs, while the original Polis project continues to break new ground. This enables Europe to build its own open and trustworthy digital democracy tools, rooted in public governance and European democratic traditions. Voxit 1.0 source code is now available The source code for version 1.0 of the European community edition of the Voxit platform has now been published and is openly maintained on GitLab.com at: https://gitlab.com/voxit/voxit#

The RISC-V CPU architecture has been gaining a lot of popularity since it launched in 2014, and now that the industry is standardizing on the RVA23 level that includes vector support as a mandatory extension, we are likely to see a lot more edge- and IoT devices with the ability to run local LLMs at reasonable speed, and most importantly at very compelling prices. SpacemiT is a Chinese RISC-V CPU manufacturer that launched on May 11th, 2026, their long-anticipated next-gen RISC-V AI chip K3. It is among the earliest RISC-V CPUs that adhere to the RVA23 standard and performance-wise it is quite capable, providing 130 KDMIPS general computing power, 60 TOPS on INT4 which translates to about 15 tokens per second when running a 30 billion parameter large language model. The aspect that really makes it stand out is:

• the RISC-V CPU architecture is open source,
• the price point is within reach of home and small business users and
• the overall feature set makes it an ideal platform to build local and offline AI systems.

SpacemiT also develops their own Debian-based Linux distribution Bianbu OS, and seems to have collaboration going on with the wider community. Their community site seems active, and they also have a dedicated X account @spacemit_riscv and Reddit account r/spacemit_riscv posting relevant progress info on Linux kernel upstreaming activities. The X account is also responsive, as evidenced by its replies to my questions. Canonical lists the SpacemiT K3 pico-ITX and K3 CoM260 Kit on its official Ubuntu for RISC-V partner-built hardware page, which strengthens the perception that upstream Linux support is being taken seriously. The SpacemiT folks also gave an interesting talk at the 2026 Ubuntu Summit that includes a peek into their roadmap with future K3, K7 and K9 models. For technical details, see SpacemiT s K3 pico-ITX documentation, the Jetson Orin Nano-compatible K3 CoM260 board documentation and documentation of the K3 processor itself.

Comparing the resellers SpacemiT does not sell anything directly to consumers. Instead you need to buy a board that includes the K3 chip from an integrator. Currently the main resellers are:

• Milk-V
• Sipeed
• Banana Pi
• Firefly
• DeepComputing

All of the above are Chinese companies that ship to customers both inside and outside China. DeepComputing stands out as the only one that actually has done real integration and ships the K3 on a custom board, while the others simply resell the SpacemiT-produced K3 pico-ITX and K3 CoM260 Kit.

Milk-V Milk-V is a RISC-V specialized integrator, as the name already implies. They sell the K3 under the name Jupiter2. Of all the K3 pico-ITX reseller product pages, the Jupiter2 presentation is the nicest and most detailed. Unfortunately their order page at arace.tech only states that it is a pre-order with no information about shipping schedule, taxes, or other details like what SSD is included (if any). Based on the pictures it does ship with a Milk-V branded case. The 32 GB RAM lists at 504 EUR, which is a very reasonable price. The @MilkV_Official account on X recently promoted the K3.

Documentation and support As of this writing, the Milk-V Jupiter2 documentation site is just a stub and has no actual content, and only two links to the SpacemiT K3 documentation site. For support there is a web forum with a dedicated Jupiter2 section. There is also a Matrix space, but unlike their other products, there is no dedicated Jupiter (neither v1 nor v2) channel.

Community size and open source involvement At least one prior Milk-V product was certified by Canonical, which indicates there is some collaboration in progress. Canonical also lists the Milk-V Titan on its official Ubuntu for RISC-V partner-built hardware page.

Sipeed The Sipeed K3 announcement is well written (in English) with all the relevant details and links to additional PDF manuals. However, their main page at sipeed.com says nothing about the K3, so one must know the subpage URL to access it. They offer both the K3 CoM260 kit compatible with Jetson Orin Nano carrier boards, and the stand-alone K3 pico-ITX-sized motherboard. The CoM260 kit is only 10 USD cheaper than the full pico-ITX motherboard, so choosing the latter is a no-brainer if starting from scratch. The pico-ITX model with 32 GB DDR5 RAM sells for 639 USD. The product page does not mention anything about hard disk size, so you don t really know exactly what you will be getting if placing an order. There is no indication about case, Wi-Fi antennas or power supply either, so most likely they are not included. Their store.sipeed.com website does not work at all, and their Taobao and AliExpress stores are not public and only accessible to registered users. The order page also says nothing about shipping time, delivery time, or taxes. The X account @SipeedIO is active and recently posted pictures of shipments in progress.

Documentation and support The main documentation wiki does not yet have any K3 content at the time of writing. There is a Discord channel for general RISC-V discussion, and their MaixHub also has a discussion board, but I didn t find anything K3-specific.

Community size and open source involvement Sipeed has had at least one of their previous devices certified by Canonical, which indicates they are active in the community. Note that the other RISC-V company SiFive that also has had hardware certified and officially supported by Canonical is a different company, despite the very similar name.

Banana Pi Banana Pi announced that they offer both the K3 CoM260 kit and the K3 pico-ITX motherboard version. Their product page for the K3 confusingly shows a MediaTek product in the page banner rather than the SpacemiT K3. Based on the product description and the fact they renamed the product as BPI-SM10, it seems to ship with some carrier board. The product pictures look identical to the SpacemiT documentation and there is no picture of the carrier board, and details are very sparse. The pico-ITX version with 8 GB RAM and 128 GB SSD sells for 293 USD and the CoM260 developer kit with the same specs sells for 287 USD and the 32 GB RAM with 128 GB SSD model sells for 595 USD. The shop page shows only five orders so far and items are currently out of stock. As there was no 32 GB RAM version of the pico-ITX available at all, this isn t an option for me as I want to run 30B parameter models that need the larger memory version. Of all of these resellers, the Banana Pi website seems the most outdated. It does not have a search feature, it is not mobile-friendly, pictures can t be pinched to zoom in and so forth. Product names are also almost all identical, and as the product listings only show the beginning of the product name, figuring out what product is what requires extra effort that just makes the online purchase experience plain bad.

Documentation and support I was only able to find the documentation page for the CoM260 kit, but none for the pico-ITX version. For support there is a forum, but the category list does not show any section for K3, and the forum search prohibits using the search term k3 as too short.

Community size and open source involvement Banana Pi has a long history in the ARM single-board computer market, but their presence in the RISC-V ecosystem is still growing. Their X account @sinovoip has posted only once about the K3 and otherwise promotes their ARM boards. However, their community culture page does express a commitment to open hardware in general, but there is no visible K3-specific community activity.

Firefly Firefly s K3 product page is comprehensive. Based on the details, they do not offer the K3 pico-ITX variant at all, but only the K3 CoM260 board inside the AIBOX-K3 Firefly RISC-V Edge Mini PC product. This is a feature-complete offering with a Jetson Orin Nano carrier board and case. The AIBOX-K3 with 32 GB RAM and 128 GB SSD in a case sells for 689 USD in their own Firefly.store. Unfortunately it only has HDMI and there is no USB-C with DisplayPort support, which is a deal-breaker for me personally. Interestingly, Firefly also offers rack-mounted servers with K3 as the CPU.

Documentation and support The wiki link on the product page is broken. The Firefly wiki does have a section for the AIBOX-K3, but it too has a broken link. It seems that as of the time of writing, there is no wiki section for this product yet. For support there is a web forum, which does have at least one K3 thread covering guides such as Hermes Agent installation, though broader K3-specific sections are still sparse.

Community size and open source involvement Firefly s X account @TeeFirefly has had no posts since 2024, and their GitLab/T-Firefly shows mostly 2024 activity, with only one repository updated in 2025 and nothing in 2026. Historically they have built a moderate community around their ARM-based Rockchip boards, with active forums and wiki contributions for those product lines. Their RISC-V K3 offerings are newer, and likely need a lot more polish to be attractive products overall.

DeepComputing Last, but certainly not least, is the laptop manufacturer DeepComputing that offers a Framework laptop compatible motherboard with the SpacemiT K3 chip. They also sell the plain motherboard, or with the Cooler Master case, which allows one to easily connect it to an external monitor and keyboard and use it as a desktop computer. The plain board with 32 GB RAM and no SSD sells for about 882 EUR. Shipping of the first batch is expected to start by end of June 2026. Their X account @DeepComputingio promotes this DC-ROMA RISC-V Mainboard III as their flagship product, so they seem to put a lot of effort into it. The overall product design and packaging seems good. Of all the K3 resellers and integrators that I was able to find, DeepComputing is the only one that actually designs their own boards with the K3 processor, while all the other vendors above are simply reselling the vanilla K3 boards with or without a case. After reviewing all these options I decided to buy the DC-ROMA RISC-V Mainboard III for Framework Laptop 13 with 32 GB RAM, 1 TB SSD and the Cooler Master case, totalling about 1100 EUR.

Documentation and support DeepComputing maintains product information for their RISC-V hardware at github.com/DC-DeepComputing/Framework, with documentation of the newest Mainboard III (FML13V05) still being finalized ahead of the first batch shipment. They provide community support through Discord and web forum, although the latter has very little activity.

Community size and open source involvement DeepComputing has established itself as a pioneer in RISC-V laptops, beginning with the DC-ROMA. I have seen their stand at FOSDEM, which shows they are genuinely active in the open source community. Canonical lists DeepComputing s first mainboard / FML13V01 on its official Ubuntu for RISC-V partner-built hardware page, and it seems likely that they will continue to collaborate with Canonical with the new model once it ships. While the underlying Linux enablement depends on SpacemiT s upstream efforts, DeepComputing s involvement helps bridge the gap between reference hardware and consumer-ready products.

Conclusion After weighing all the options, I ended up placing an order with DeepComputing for their custom K3 board with the Cooler Master case. Despite the premium price, the active community support and the properly documented promise of a complete, working system made it easy to place an order with confidence. The SpacemiT K3 is poised to be one of the most significant RISC-V chips for local AI workloads, thanks to its RVA23 compliance and high tokens per second potential. Yet the buying experience in mid-2026 remains fragmented and incomplete. Hopefully this is just because the product is new, and they will get the purchase experience polished soon. What struck me most during this process was how poor the customer experience is across nearly all of these vendor websites: broken links, missing search functions, outdated product banners, pages that show the wrong product entirely, and no information about shipping times, stock levels, taxes, and so on. One wonders why these companies don t fully invest in their web presence. Personally I would assume they likely have enough customers already, primarily through domestic channels like Taobao and JD.com, that they do not feel any pressure to improve their international-facing sites. However, I did also review what was offered on Taobao, and the product details were very incomplete there too. Taobao, however, has a built-in live chat with almost all sellers, which can be used to ask questions and thus compensate for missing product details. I don t fully understand why the sales process seems unpolished. The websites feel almost like an afterthought a checkbox to claim global reach while the real business apparently happens elsewhere via closed platforms or via inaccessible reseller channels. It is a frustrating reminder that in the RISC-V hardware world, the technology may be open and global, but the purchase experience is less so.

This was a particularly busy month for me in terms of Debian contributions. It started with a week in Hamburg for the MiniDebConf. I talked to many colleagues face-to-face and worked on various bugs and maintenance tasks. I m pleased to have finally found the time to reproduce and fix the boot-time crashes in the parallel port subsystem that have been reported many times recently. A series of easily exploited kernel LPE (local privilege execution) issues were published this month, mostly with very little coordination with distributions. Salvatore and I had to upload fixes for these at roughly weekly intervals. All of these fixes needed to be applied to 4 different upstream branches (currently 5.10, 6.1, 6.12, and 7.0) and 7 Debian branches (including backports).

• Debian packages:
  • cis-tools:
    • Bugs:
      • replied to #1135267: pack_cis should be installed in /usr/bin
  • dracut:
    • Bugs:
      • replied to #1131809: dracut: ppc64el autopkgtest are flaky and take 7 hours per run (and discussed it in-person in Hamburg)
  • firmware-free:
    • Bugs:
      • closed #1122755: firmware-free: Please remove/replace usage of dh_movetousr
    • Merge requests:
      • opened !11: Apply relevant changes from firmware-nonfree
  • firmware-nonfree:
    • Merge requests:
      • closed !68: Draft: Update bullseye in line with buster
      • reviewed and merged !146: gencontrol: s/initramfs-tools/update-initramfs/
      • merged !147: control: stop suggesting initramfs-tools
      • opened and merged !148: Update to 20260519
      • opened and merged !149: Include more firmware in binary packages
      • opened !150: Update and remove obsolete package relations
  • gnome-shell:
    • Bugs:
      • replied to and reassigned #1135951: linux-image-6.12.85+deb13-amd64: secure data is visible when waking from suspsend
  • initramfs-tools:
    • Bugs:
      • closed #1108924: initramfs-tools: Cannot boot Trixie d-i rc2 USB storage target riscv64 MODULES=most (missing: cdns3 cdns3_starfive)
    • Merge requests:
      • reviewed !142: Handle simple-framebuffer drivers and framebuffer_coreboot built as modules
      • closed !150: Do not install ARM/RISCV specific modules on other architectures
      • closed !173: Draft: Introduce copy_file helper program to replace copy_file function
      • opened and merged !195: unmkinitramfs: Make it compatible with Busybox cpio
      • reviewed !196: add module to add fw files from DT firmware-name properties
    • Uploads:
      • uploaded version 0.148.4 to trixie
  • ktls-utils:
    • Merge requests:
      • merged !5: Update to 1.4.0
    • Uploads:
      • uploaded version 1.4.0-1 to unstable
  • linux:
    • Bugs:
      • replied to #1130365: linux-image-6.18.15+deb14-amd64: kernel panic during startup
      • replied to #1136800: linux-image-7.0.4+deb14-amd64: fails to boot
      • replied to #1136894: linux-image-7.0.4+deb14-amd64: Kernel Panic - AMDGPU crash
      • replied to #1136978: linux-image-7.0.4+deb14-amd64: kernel NULL pointer dereference
      • replied to and closed #1137202: linux-image-7.1-amd64: Kernel panic on boot
      • replied to #1137203: bnx2: ifupdown-hotplug fails at boot, no network, regression from 5.10.0-42
      • replied to #1137642: linux-image-7.0.7+deb13-amd64: Failed to load Bluetooth driver
    • Merge requests:
      • closed !1720: arm64: Enable Renesas RZ/G2L features
      • merged !1759: [arm64] Enable AIR_EN8811H_PHY as module
      • merged !1792: [arm64] Enable BST platform support
      • closed !1817: [sparc64] Add patches to fix user stack sync and add clone3() syscall
      • merged !1837: [arm64] Enable configs for Qualcomm RB1 boards
      • reviewed !1845: [amd64,arm64] Enable KEXEC_HANDOVER and LIVEUPDATE
      • merged !1878: [riscv64] Enable CMA and DMA_CMA. Set CMA_SIZE_MBYTES=64
      • merged !1884: [amd64] Enable Intel USBIO bridge driver and submodules
      • opened !1904: Improve package descriptions for most of the kernel packages
      • reviewed and merged !1906: Enable SND_SOC_SDCA_CLASS and SND_SOC_SDCA_ FDL, HID, IRQ for Panther Lake audio support
      • opened and merged !1910: Add backported patches for Dirty Frag attack
      • merged !1911: Qualcomm Monaco and Talos support
      • merged !1913: d/watch: migrate to version 5
      • reviewed !1936: [sparc64] Add nvme module to scsi-modules udeb
      • reviewed !1948: [amd64] Enable Intel Platform Hardware Support Drivers
      • opened and merged !1951: Fix dirtying of the source tree when building tools
      • merged !1954: 7.0 backport Fix for fragnesia (CVE-2026-46300) and variants
      • merged !1955: 6.12 backport Fix for fragnesia (CVE-2026-46300) and variants
      • opened !1956: Draft: Enable a fully parallel build
    • Uploads:
      • (LTS) uploaded versions 5.10.251-2, 5.10.251-3, 5.10.251-4, 5.10.251-5, 5.10.257-1 to bullseye-security
      • uploaded versions 6.12.85-1~bpo12+1, 6.12.86-1~bpo12+1, 6.12.88-1~bpo12+1, 6.12.90-1~bpo12+1, 6.12.90-2~bpo12+1 to bookworm-backports
      • uploaded versions 6.19.14-1~bpo13+1, 7.0.10-1~bpo13+1, 7.0.4-1~bpo13+1, 7.0.7-1~bpo13+1, 7.0.9-1~bpo13+1 to trixie-backports
  • (LTS) linux-6.1:
    • Uploads:
      • uploaded versions 6.1.170-1~deb11u1, 6.1.170-3~deb11u1, 6.1.172-1~deb11u1, 6.1.174-1~deb11u1 to bullseye-security
  • miniramfs:
    • Bugs:
      • replied to #1132532: miniramfs: Missing cpio dependency
  • nfs-utils:
    • Bugs:
      • replied to and closed #1138209: nfs-kernel-server: Parameter RPCNFSDCOUNT from /etc/default/nfs-kernel-server is ignored after Upgrade from Deb12
  • wireless-regdb:
    • Uploads:
      • uploaded version 2026.03.18-1 to unstable
• Debian non-package bugs:
  • release.debian.org:
    • opened #1135902: trixie-pu: package initramfs-tools/0.148.4
• Mailing lists:
  • debian-boot:
    • replied to Please add loong64 to Daily/Weekly builds of installer images
  • debian-devel:
    • replied to Licensing of licenses
  • debian-kernel:
    • posted Agenda items for kernel-team meeting on 2026-05-13
    • posted and replied to [RFC] Using SimpleDRM in the initramfs
    • replied to [bjarniig@simnet.is: kernel-img.conf.5: warning from lint ]
  • debian-lts-announce:
    • posted [SECURITY] [DLA 4560-1] linux security update
    • posted [SECURITY] [DLA 4561-1] linux-6.1 security update
    • posted [SECURITY] [DLA 4572-1] linux security update
    • posted [SECURITY] [DLA 4574-1] linux-6.1 security update
    • posted [SECURITY] [DLA 4587-1] linux security update
    • posted [SECURITY] [DLA 4588-1] linux-6.1 security update
    • posted [SECURITY] [DLA 4606-1] linux security update
    • posted [SECURITY] [DLA 4607-1] linux-6.1 security update
  • linux-hyperv:
    • posted [PATCH] uio_hv_generic: Bind to FCopy device by default
  • linux-perf-users:
    • posted and replied to [PATCH 0/3] Fix out-of-tree build of some tools
  • linux-sh:
    • posted [PATCH] sh: uaccess: Handle exception on second instruction of __put_user_u64
  • linux-trace-kernel:
    • posted [PATCH RESEND] rtla: Fix output files in source tree
  • netdev:
    • replied to [PATCH net] net: skbuff: propagate shared-frag marker through pskb_copy()
  • (mostly LTS) stable:
    • replied to Linux 5.15.205
    • posted [5.10,5.15] i3c: fix uninitialized variable use in i2c setup
    • posted [6.6] fbdev/vt8500lcdfb: Initialize fb_ops with fbdev macros
    • posted [6.6] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • posted [6.6] x86/CPU/AMD: Move the Zen3 BTC_NO detection to the Zen3 init function
    • posted [7.0] perf loongarch: Fix build failure with CONFIG_LIBDW_DWARF_UNWIND
    • replied to [PATCH 5.10 002/589] ASoC: SOF: topology: reject invalid vendor array size in token parser
    • replied to [PATCH 5.10 027/589] xfrm: Wait for RCU readers during policy netns exit
    • replied to [PATCH 5.10 072/589] media: uvcvideo: Use heuristic to find stream entity
    • replied to [PATCH 5.10 095/589] ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
    • replied to [PATCH 5.10 096/589] scsi: ufs: core: Improve SCSI abort handling
    • posted [PATCH 5.10 1/2] Revert RDMA/rxe: Fix double free in rxe_srq_from_init
    • replied to [PATCH 5.10 101/589] rxrpc: Fix key quota calculation for multitoken keys
    • replied to [PATCH 5.10 114/589] arm64: dts: imx8mq-librem5: Dont mark buck3 as always on
    • replied to [PATCH 5.10 176/589] KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state
    • replied to [PATCH 5.10 177/589] KVM: nSVM: Sync NextRIP to cached vmcb12 after VMRUN of L2
    • posted and replied to [PATCH 5.10 2/2] RDMA/rxe: Fix double free in rxe_srq_from_init
    • posted [PATCH 5.10-5.15] apparmor: validate default DFA states are in bounds
    • posted [PATCH 5.10-6.1] fbdev: vt8500lcdfb: Fix dma_free_coherent() cpu_addr parameter
    • posted [PATCH 5.10-6.1] x86/CPU/AMD: Move the Zen3 BTC_NO detection to the Zen3 init function
    • replied to [PATCH 5.10] Revert s390/cio: Fix device lifecycle handling in css_alloc_subchannel()
    • posted [PATCH 5.10] Revert s390/cio: Fix device lifecycle handling in css_alloc_subchannel()
    • posted [PATCH 5.10] net: skbuff: preserve shared-frag marker during coalescing
    • posted [PATCH 5.10] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • posted [PATCH 5.10] phy: renesas: rcar-gen3-usb2: Fix msleep() in atomic context
    • posted [PATCH 5.10] selftests: forwarding: lib: Add helpers for checksum handling
    • posted [PATCH 5.15 1/2] Revert RDMA/rxe: Fix double free in rxe_srq_from_init
    • posted [PATCH 5.15 2/2] RDMA/rxe: Fix double free in rxe_srq_from_init
    • replied to [PATCH 5.15.y] net: usb: lan78xx: Fix double free issue with interrupt buffer allocation
    • posted [PATCH 5.15] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • posted [PATCH 5.15] selftests: forwarding: lib: Add helpers for checksum handling
    • posted [PATCH 6.1 1/2] Revert RDMA/rxe: Fix double free in rxe_srq_from_init
    • posted [PATCH 6.1 2/2] RDMA/rxe: Fix double free in rxe_srq_from_init
    • posted [PATCH 6.1] apparmor: validate default DFA states are in bounds
    • posted [PATCH 6.1] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • posted [PATCH 6.1] selftests: forwarding: lib: Add helpers for checksum handling
    • posted [PATCH 6.6] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • replied to [PATCH net] net: skbuff: propagate shared-frag marker through pskb_copy()
    • posted [PATCH] parport: Fix race between port and client registration

This was a particularly busy month for me in terms of Debian contributions. It started with a week in Hamburg for the MiniDebConf. I talked to many colleagues face-to-face and worked on various bugs and maintenance tasks. I m pleased to have finally found the time to reproduce and fix the boot-time crashes in the parallel port subsystem that have been reported many times recently. A series of easily exploited kernel LPE (local privilege execution) issues were published this month, mostly with very little coordination with distributions. Salvatore and I had to upload fixes for these at roughly weekly intervals. All of these fixes needed to be applied to 4 different upstream branches (currently 5.10, 6.1, 6.12, and 7.0) and 7 Debian branches (including backports).

• Debian packages:
  • cis-tools:
    • Bugs:
      • replied to #1135267: pack_cis should be installed in /usr/bin
  • dracut:
    • Bugs:
      • replied to #1131809: dracut: ppc64el autopkgtest are flaky and take 7 hours per run (and discussed it in-person in Hamburg)
  • firmware-free:
    • Bugs:
      • closed #1122755: firmware-free: Please remove/replace usage of dh_movetousr
    • Merge requests:
      • opened !11: Apply relevant changes from firmware-nonfree
  • firmware-nonfree:
    • Merge requests:
      • closed !68: Draft: Update bullseye in line with buster
      • reviewed and merged !146: gencontrol: s/initramfs-tools/update-initramfs/
      • merged !147: control: stop suggesting initramfs-tools
      • opened and merged !148: Update to 20260519
      • opened and merged !149: Include more firmware in binary packages
      • opened !150: Update and remove obsolete package relations
  • gnome-shell:
    • Bugs:
      • replied to and reassigned #1135951: linux-image-6.12.85+deb13-amd64: secure data is visible when waking from suspsend
  • initramfs-tools:
    • Bugs:
      • closed #1108924: initramfs-tools: Cannot boot Trixie d-i rc2 USB storage target riscv64 MODULES=most (missing: cdns3 cdns3_starfive)
    • Merge requests:
      • reviewed !142: Handle simple-framebuffer drivers and framebuffer_coreboot built as modules
      • closed !150: Do not install ARM/RISCV specific modules on other architectures
      • closed !173: Draft: Introduce copy_file helper program to replace copy_file function
      • opened and merged !195: unmkinitramfs: Make it compatible with Busybox cpio
      • reviewed !196: add module to add fw files from DT firmware-name properties
    • Uploads:
      • uploaded version 0.148.4 to trixie
  • ktls-utils:
    • Merge requests:
      • merged !5: Update to 1.4.0
    • Uploads:
      • uploaded version 1.4.0-1 to unstable
  • linux:
    • Bugs:
      • replied to #1130365: linux-image-6.18.15+deb14-amd64: kernel panic during startup
      • replied to #1136800: linux-image-7.0.4+deb14-amd64: fails to boot
      • replied to #1136894: linux-image-7.0.4+deb14-amd64: Kernel Panic - AMDGPU crash
      • replied to #1136978: linux-image-7.0.4+deb14-amd64: kernel NULL pointer dereference
      • replied to and closed #1137202: linux-image-7.1-amd64: Kernel panic on boot
      • replied to #1137203: bnx2: ifupdown-hotplug fails at boot, no network, regression from 5.10.0-42
      • replied to #1137642: linux-image-7.0.7+deb13-amd64: Failed to load Bluetooth driver
    • Merge requests:
      • closed !1720: arm64: Enable Renesas RZ/G2L features
      • merged !1759: [arm64] Enable AIR_EN8811H_PHY as module
      • merged !1792: [arm64] Enable BST platform support
      • closed !1817: [sparc64] Add patches to fix user stack sync and add clone3() syscall
      • merged !1837: [arm64] Enable configs for Qualcomm RB1 boards
      • reviewed !1845: [amd64,arm64] Enable KEXEC_HANDOVER and LIVEUPDATE
      • merged !1878: [riscv64] Enable CMA and DMA_CMA. Set CMA_SIZE_MBYTES=64
      • merged !1884: [amd64] Enable Intel USBIO bridge driver and submodules
      • opened !1904: Improve package descriptions for most of the kernel packages
      • reviewed and merged !1906: Enable SND_SOC_SDCA_CLASS and SND_SOC_SDCA_ FDL, HID, IRQ for Panther Lake audio support
      • opened and merged !1910: Add backported patches for Dirty Frag attack
      • merged !1911: Qualcomm Monaco and Talos support
      • merged !1913: d/watch: migrate to version 5
      • reviewed !1936: [sparc64] Add nvme module to scsi-modules udeb
      • reviewed !1948: [amd64] Enable Intel Platform Hardware Support Drivers
      • opened and merged !1951: Fix dirtying of the source tree when building tools
      • merged !1954: 7.0 backport Fix for fragnesia (CVE-2026-46300) and variants
      • merged !1955: 6.12 backport Fix for fragnesia (CVE-2026-46300) and variants
      • opened !1956: Draft: Enable a fully parallel build
    • Uploads:
      • (LTS) uploaded versions 5.10.251-2, 5.10.251-3, 5.10.251-4, 5.10.251-5, 5.10.257-1 to bullseye-security
      • uploaded versions 6.12.85-1~bpo12+1, 6.12.86-1~bpo12+1, 6.12.88-1~bpo12+1, 6.12.90-1~bpo12+1, 6.12.90-2~bpo12+1 to bookworm-backports
      • uploaded versions 6.19.14-1~bpo13+1, 7.0.10-1~bpo13+1, 7.0.4-1~bpo13+1, 7.0.7-1~bpo13+1, 7.0.9-1~bpo13+1 to trixie-backports
  • (LTS) linux-6.1:
    • Uploads:
      • uploaded versions 6.1.170-1~deb11u1, 6.1.170-3~deb11u1, 6.1.172-1~deb11u1, 6.1.174-1~deb11u1 to bullseye-security
  • miniramfs:
    • Bugs:
      • replied to #1132532: miniramfs: Missing cpio dependency
  • nfs-utils:
    • Bugs:
      • replied to and closed #1138209: nfs-kernel-server: Parameter RPCNFSDCOUNT from /etc/default/nfs-kernel-server is ignored after Upgrade from Deb12
  • wireless-regdb:
    • Uploads:
      • uploaded version 2026.03.18-1 to unstable
• Debian non-package bugs:
  • release.debian.org:
    • opened #1135902: trixie-pu: package initramfs-tools/0.148.4
• Mailing lists:
  • debian-boot:
    • replied to Please add loong64 to Daily/Weekly builds of installer images
  • debian-devel:
    • replied to Licensing of licenses
  • debian-kernel:
    • posted Agenda items for kernel-team meeting on 2026-05-13
    • posted and replied to [RFC] Using SimpleDRM in the initramfs
    • replied to [bjarniig@simnet.is: kernel-img.conf.5: warning from lint ]
  • debian-lts-announce:
    • posted [SECURITY] [DLA 4560-1] linux security update
    • posted [SECURITY] [DLA 4561-1] linux-6.1 security update
    • posted [SECURITY] [DLA 4572-1] linux security update
    • posted [SECURITY] [DLA 4574-1] linux-6.1 security update
    • posted [SECURITY] [DLA 4587-1] linux security update
    • posted [SECURITY] [DLA 4588-1] linux-6.1 security update
    • posted [SECURITY] [DLA 4606-1] linux security update
    • posted [SECURITY] [DLA 4607-1] linux-6.1 security update
  • linux-hyperv:
    • posted [PATCH] uio_hv_generic: Bind to FCopy device by default
  • linux-perf-users:
    • posted and replied to [PATCH 0/3] Fix out-of-tree build of some tools
  • linux-sh:
    • posted [PATCH] sh: uaccess: Handle exception on second instruction of __put_user_u64
  • linux-trace-kernel:
    • posted [PATCH RESEND] rtla: Fix output files in source tree
  • netdev:
    • replied to [PATCH net] net: skbuff: propagate shared-frag marker through pskb_copy()
  • (mostly LTS) stable:
    • replied to Linux 5.15.205
    • posted [5.10,5.15] i3c: fix uninitialized variable use in i2c setup
    • posted [6.6] fbdev/vt8500lcdfb: Initialize fb_ops with fbdev macros
    • posted [6.6] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • posted [6.6] x86/CPU/AMD: Move the Zen3 BTC_NO detection to the Zen3 init function
    • posted [7.0] perf loongarch: Fix build failure with CONFIG_LIBDW_DWARF_UNWIND
    • replied to [PATCH 5.10 002/589] ASoC: SOF: topology: reject invalid vendor array size in token parser
    • replied to [PATCH 5.10 027/589] xfrm: Wait for RCU readers during policy netns exit
    • replied to [PATCH 5.10 072/589] media: uvcvideo: Use heuristic to find stream entity
    • replied to [PATCH 5.10 095/589] ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
    • replied to [PATCH 5.10 096/589] scsi: ufs: core: Improve SCSI abort handling
    • posted [PATCH 5.10 1/2] Revert RDMA/rxe: Fix double free in rxe_srq_from_init
    • replied to [PATCH 5.10 101/589] rxrpc: Fix key quota calculation for multitoken keys
    • replied to [PATCH 5.10 114/589] arm64: dts: imx8mq-librem5: Dont mark buck3 as always on
    • replied to [PATCH 5.10 176/589] KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state
    • replied to [PATCH 5.10 177/589] KVM: nSVM: Sync NextRIP to cached vmcb12 after VMRUN of L2
    • posted and replied to [PATCH 5.10 2/2] RDMA/rxe: Fix double free in rxe_srq_from_init
    • posted [PATCH 5.10-5.15] apparmor: validate default DFA states are in bounds
    • posted [PATCH 5.10-6.1] fbdev: vt8500lcdfb: Fix dma_free_coherent() cpu_addr parameter
    • posted [PATCH 5.10-6.1] x86/CPU/AMD: Move the Zen3 BTC_NO detection to the Zen3 init function
    • replied to [PATCH 5.10] Revert s390/cio: Fix device lifecycle handling in css_alloc_subchannel()
    • posted [PATCH 5.10] Revert s390/cio: Fix device lifecycle handling in css_alloc_subchannel()
    • posted [PATCH 5.10] net: skbuff: preserve shared-frag marker during coalescing
    • posted [PATCH 5.10] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • posted [PATCH 5.10] phy: renesas: rcar-gen3-usb2: Fix msleep() in atomic context
    • posted [PATCH 5.10] selftests: forwarding: lib: Add helpers for checksum handling
    • posted [PATCH 5.15 1/2] Revert RDMA/rxe: Fix double free in rxe_srq_from_init
    • posted [PATCH 5.15 2/2] RDMA/rxe: Fix double free in rxe_srq_from_init
    • replied to [PATCH 5.15.y] net: usb: lan78xx: Fix double free issue with interrupt buffer allocation
    • posted [PATCH 5.15] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • posted [PATCH 5.15] selftests: forwarding: lib: Add helpers for checksum handling
    • posted [PATCH 6.1 1/2] Revert RDMA/rxe: Fix double free in rxe_srq_from_init
    • posted [PATCH 6.1 2/2] RDMA/rxe: Fix double free in rxe_srq_from_init
    • posted [PATCH 6.1] apparmor: validate default DFA states are in bounds
    • posted [PATCH 6.1] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • posted [PATCH 6.1] selftests: forwarding: lib: Add helpers for checksum handling
    • posted [PATCH 6.6] net: skbuff: propagate shared-frag marker through frag-transfer helpers
    • replied to [PATCH net] net: skbuff: propagate shared-frag marker through pskb_copy()
    • posted [PATCH] parport: Fix race between port and client registration

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 1272 other packages on CRAN, downloaded 46.6 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 693 times according to Google Scholar. This versions updates to the 15.2.7 upstream Armadillo release made today. The package has already been updated for Debian, and built for r2u. As the upstream was modest, we for once skipped reverse-dependency checks. That bet paid off as CRAN found no issues among the over 1270 reverse dependencies. However, one package referenced a package archived today, hence invisible to CRAN and triggered a (false positive) NOTE of reference to non-existing package . We came close. Anyway, the package made it CRAN shortly thereafter following the standard brief email exchange explaining the false-positive nature of the NOTE. All changes since the last CRAN release follow.

Changes in RcppArmadillo version 15.2.7-1 (2026-05-29)

• Upgraded to Armadillo release 15.2.7 (Medium Roast Deluxe)
  • More efficient checks for aliasing

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

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. You can also sponsor my Tour de Shore 2026 ride in support of the Maywood Fine Arts Center.

To associate routing information like AS paths or BGP communities to flows, Akvorado can import routes through the BGP Monitoring Protocol (BMP). As the Internet routing table contains more than 1 million routes, Akvorado needs to scale to tens of millions of routes.¹ This has been a long-standing challenge,² but I expect this issue is now fixed by using RIB sharding, a method that splits the routing database into several parts to enable concurrent updates.

Previous implementation Akvorado connects 2 elements to build its RIB:

1. a prefix tree, and
2. a list of routes attached to each prefix.

Akvorado BMP RIB implementation without sharding. One single read/write lock.

In the diagram above, the RIB stores five IPv4 prefixes and two IPv6 prefixes. One of them, 2001:db8:1::/48, contains three routes:

• from peer 3, next hop 2001:db8::3:1, AS 65402, AS path 65402, community 65402:31,
• from peer 4, next hop 2001:db8::4:1, same ASN, AS path, and community,
• from peer 5, next hop 2001:db8::5:1, AS 65402, AS path 65401 65402, community 65402:31.

The rib structure is defined in Go as follows:

type rib struct  
    tree          *bart.Table[prefixIndex]
    routes        map[routeKey]route
    nlris         *intern.Pool[nlri]
    nextHops      *intern.Pool[nextHop]
    rtas          *intern.Pool[routeAttributes]
    nextPrefixID  prefixIndex
    freePrefixIDs []prefixIndex
 

The prefix tree uses the bart package, an adaptation of Donald Knuth s ART algorithm. The benchmarks demonstrate it outperforms other packages for lookups, insertions, and memory usage.³ Plus, the author is quite helpful.

Storing routes in a map The list of routes for each prefix is not stored directly in the prefix tree: it would put too much pressure on the garbage collector by allocating per-prefix arrays. Instead, the RIB assigns a unique 32-bit prefix identifier for each prefix, either by picking the last available prefix identifier from the freePrefixIDs array if any, or using the nextPrefixID value before incrementing it. Then, the routes are stored in the routes map, leveraging the optimized Swiss table in Go. To retrieve routes attached to a prefix, we look them up one by one in the routes map with a 64-bit key combining the 32-bit prefix index with a 32-bit route index matching the position of the route in the list. Akvorado scans routes from the first to the last to find the best one.⁴ It knows there is no more route if the route key returns no result.

type prefixIndex uint32
type routeIndex uint32
type routeKey uint64

Interning routes A route contains a BGP peer identifier, a partial NLRI⁵, the next hop, and the attributes.

type route struct  
    peer       uint32
    nlri       intern.Reference[nlri]
    nextHop    intern.Reference[nextHop]
    attributes intern.Reference[routeAttributes]
    prefixLen  uint8
 
type nlri struct  
    family bgp.Family
    path   uint32
    rd     RD
 
type nextHop netip.Addr
type routeAttributes struct  
    asn              uint32
    asPath           []uint32
    communities      []uint32
    largeCommunities []bgp.LargeCommunity
 

To save memory and allocations, NLRI, next hops, and route attributes are interned : a 32-bit integer replaces the real value. The mechanism predates the unique package introduced in Go 1.23. We keep it because it has different trade-offs:

• It uses explicit reference counting instead of relying on weak pointers.
• It works with non-comparable values implementing Hash() and Equal() methods.⁶
• It uses explicit pool instances. This will be useful for sharding.
• It has better performance. See for example this benchmark.
• It consumes half the memory thanks to unsigned 32-bit references instead of pointers.
• But it is not safe for concurrent use.

Why does it not scale?

Note At AS 12322, we don t use BMP yet.⁷ But Gerhard Bogner had the patience, availability, and technical skills to help me debug this issue.

The global read/write lock is a bottleneck in this implementation. But how? There are several users of the RIB, each with its own set of constraints:

• The Kafka workers look up the RIB to enrich flows with routing information. They are bound by the number of Kafka partitions.⁸ Akvorado also adjusts their number to ensure efficient batching to ClickHouse. On our setup, the number of workers oscillates between 8 and 16. As we want to observe the latest data, we cannot afford for the Kafka workers to lag too much.
• The monitored routers send route updates through the BMP protocol. When connecting, they can send millions of routes.⁹ After the initial synchronization, updates are sent continuously and may spike from time to time. The router detects a stuck BMP station when its TCP window is full and resets the session in this case. While Akvorado implements a large incoming buffer, it still needs to update the received routes with the write lock held fast enough to avoid being detected as stuck.
• When a remote BGP peer goes down, Akvorado flushes the associated routes by walking the RIB with the write lock held. When a monitored router goes down, Akvorado waits a bit but eventually flushes all the associated routes.

In short: on a busy setup, lock contention is high for both readers and writers, and neither can lag too much behind.

RIB sharding

First step: basic sharding To remove the global lock, the RIB is split into several shards, each one handling a subset of the prefixes:

Akvorado BMP RIB implementation with sharding.

The prefix tree stays global and is protected by a single lock. Each shard gets its read/write lock, its route map, and its intern pools to store NLRIs, next hops, and route attributes, which would not have been possible with Go s unique package. The prefix indexes are also sharded: the 8 most significant bits are the shard index and the 24 remaining bits are the local prefix index. Gerhard confirmed that after this blind change, the BMP receiver chugged steadily. Later, I wrote a concurrent benchmark over half a million synthetic but plausible routes¹⁰ partitioned over 0 to 8 writers, churning routes as fast as possible, while 1 to 16 readers continuously look up a set of 10,000 routes. I don t know if this benchmark is realistic, but it confirms the improvements for both read and write latencies:

Read and write latency performance improvement after sharding.

It also shows that a high number of writers degrades read latency.

Second step: lock-free reads The single read/write lock protecting the prefix tree is the next target. The bart package provides alternative mutation methods returning an updated tree using copy-on-write. Readers don t need the global lock any more, leaving it only to synchronize writers. The prefix tree is boxed in an atomic pointer.

Akvorado BMP RIB implementation with sharding and lock-free reads.

Without a lock, readers can now fetch a stale prefix index when walking their copy of the tree if a concurrent writer removes the last route attached to this prefix index and recycles it for another prefix. To avoid this issue, we combine the prefix index with a generation number and store them in the tree:

type generation uint32
type prefixRef struct  
    idx prefixIndex
    gen generation
 
type rib struct  
    mu     sync.Mutex
    tree   atomic.Pointer[bart.Table[prefixRef]]
    shards []*ribShard
 

Each shard stores the generation number for each local prefix index. The generation number increases by one if the associated prefix index is freed. When looking up the routes attached to a prefix index, the reader checks if the generation number matches. Otherwise, it assumes the index was recycled and the list of routes is empty.¹¹ You can see this case in the diagram above for prefix index 5, stored with a generation index of 3, while the current value in the []generations array is 4. The generation number could overflow, but it is not a problem as lookups are quick. Running the concurrent benchmark against this new implementation shows the improvements for the read latency as soon as the cost of the copy-on-write prefix tree is amortized.

Read and write latency performance improvement after lock-free reads. The middle column shows the cumulative improvements of both steps.

---

Among the multiple attempts to optimize the BMP component, RIB sharding is one of the more satisfying. Akvorado 2.2 implements the first step. PR #2433, drafted while writing this blog post, implements the second step and was released with Akvorado 2.4.

---

1. Each router exporting flows doesn t need to send its routes. When Akvorado does not find a route from a specific device, it falls back to a route sent by another device. It is up to the operator to decide if this is a good enough approximation.
2. I made many attempts to scale the BMP component. See for example PR #254, PR #255, PR #278, PR #2244, and PR #2245. Despite these efforts, this component remained problematic for some users. See discussion #2287 as the latest example.
3. It keeps improving: bart 0.28.0 features a new implementation that trades a bit of memory for greater lookup performance. I did not test it yet, as I have been preparing this blog post for a couple of months already.
4. Akvorado prefers the route matching the exact next hop. Otherwise, it falls back to any other route. This is an approximation. An alternative would be to have one prefix tree for each BGP peer but it would require configuring all routers to export their routes. pmacct s BMP daemon implements this approach.
5. If we consider the BGP RIB as a database, the Network Layer Reachability Information (NLRI) is the primary key. Its content depends on the BGP family. With IPv4 or IPv6 unicast, this is the prefix. For VPNv4 and VPNv6 families, it includes the route distinguisher. If you enable the ADD-PATH extension, the NLRI also contains a path identifier. In our implementation, we don t store the prefix as we get it from the looked-up IP address using the prefix length stored separately.
6. The Hash() methods rely on the hash/maphash package and on the unsafe package to avoid memory copies. See for example the Hash() function for the nlri structure.
7. Despite being an author or co-author of the first BMP-related RFCs since 2016 (RFC 7854, RFC 8671, RFC 9069), Cisco did not implement it in a usable way in IOS XR until version 24.2.1. We still need to upgrade a few routers to enable this feature.
8. KIP-932 introduces, in Kafka 4.2, the concept of share groups to enable cooperative consumption on the same partition. This is not supported in Akvorado yet.
9. You can configure BMP to send routes for each BGP peer before or after applying the incoming policies. In this case, you can get more than one million routes for each transit peer. You can also tell BMP to send the local RIB, which only contains the best path for each prefix.
10. The prefixes are random, but the prefix size distribution and the AS path length distribution follow the data provided by Geoff Huston.
11. Alternatively, we could retry the lookup, but it would be pointless: the RIB is an eventually consistent database, and an empty list was a correct answer at some point in the recent past.

Debian Contributions: 2026-04 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.

Undeclared file conflicts, by Helmut Grohne The duplication checker, the Multi-Arch hinter, and the /usr-move analyzer share significant parts of their code. While the /usr-move transition is complete, the other tools needed a bit of love. Helmut added Python type annotations, slightly improved the performance of the duplication website and shared more code between these tools. Building upon this Helmut looked into file conflicts of various kinds such as unrelated packages installing overlapping files, file type conflicts, mismatching directory metadata and shared files of Multi-Arch: same packages with varying content. Implementing reliable detection proved to be difficult due to the amount of corner cases. So Helmut semi-manually filed bugs. In that process, it became apparent that binNMUs do not reproduce SOURCE_DATE_EPOCH across architectures and therefore some shared files embedding the build date would vary in content. Additionally, a significant number of reports required further correspondence.

contributors.debian.org mini-sprint, by Enrico Zini Enrico Zini met with Mattia Rizzolo to continue the work started at DebConf 25 on crediting contributions done via salsa, and to catch up with accumulated site issues. Building on the same kind of infrastructure used to notify tag2upload, salsa.debian.org triggers a webping on pushes and merge request activity, which causes a small JSON payload to be queued in a private directory on contributors.debian.org. We worked on processing, filtering and aggregating the files in the queue into a private, staging database table. When configuring a data source on the site, it is now possible to configure automated submission of contributions from information in the staging table. This makes it significantly simpler to credit contributors for all teams that use Salsa as their code repository and coordination tool, as the site can take care of the data mining for you. See more details in the sprint report posted to debian-devel-announce.

MiniDebConf Campinas, by Lucas Kanashiro, Santiago Ruano Rinc n and Antonio Terceiro MiniDebConf Campinas was held between April 23rd and 25th, at the State University of Campinas, and was preceded by a MiniDebcamp between April 20th and 22nd. Freexian was Gold sponsor for the event, and Freexian collaborators were active contributors to the conference success. Lucas and Santiago delivered a talk about Debian LTS during MiniDebConf Campinas 2026, where they described how the LTS project benefits Debian users and developers, while strengthening Debian itself. Lucas and Antonio delivered a talk about internship programs in Debian during MiniDebConf Campinas 2026, with the goal of getting students interested in working in and with Debian. Lucas took part in the MiniDebConf Campinas content team, reviewing/accepting talks and building the schedule. Antonio led a session where he invited the audience to weigh in on current controversies in Debian. The session presented playful elements as colored signs to denote agree/disagree, and was not recorded, to help people feel more comfortable about speaking up. He might be convinced to lead a similar session at the next DebConf. Antonio also organized a debate to discuss the consequences of new Brazilian regulation for the protection of children and adolescents in digital spaces for Debian and other free operating systems, but also for the free software community in general. This session was very fruitful and will lead into further actions, as one of the main outcomes was the realization that the free software community must follow the discussion leading up to similar regulations more closely to avoid being caught by surprise when they come into effect.

security-tracker performance, by Helmut Grohne and Emilio Pozuelo Monfort Prompted by spontaneous influx of web requests on Freexian s security-tracker back in February, we considered the options for managing that demand. One of our mitigations was making it faster. To that end, Helmut sent two MRs towards improving the situation. There are four notable improvements. The use of Python s str.translate generally speeds up rendering of larger templates. Indexing the CVE names avoids a costly sequential table scan. Avoiding FFI calls while sorting and reducing the queryset speeds up the source package view. Emilio reviewed and deployed the changes on to the Debian instance. Together these changes provide a twofold speedup on both Freexian s and Debian s instance on average.

dput-ng data loss bug, by Colin Watson Ian Jackson (not affiliated with Freexian) reported that dput-ng could lose data when using the local install method, which could cause misleading results in tests of other packages; they also filed an initial merge request to fix it. Colin improved this to isolate its tests properly, and uploaded it.

Miscellaneous contributions

• Lucas coordinated the src:valkey update to version 9 in unstable with a potential co-maintainer.
• Lucas provided a security update for src:valkey targeting trixie .
• Thorsten did two uploads of foo2zjs, one to fix a bug and one to improve packaging. As there have been several CVEs published for cups he also did an upload of a new upstream version. Unfortunately this introduces a regression and another upload was needed to take care of a crash. The patch for one CVE also broke a test script, which is used by lots of printing packages in Debian. As a result some autopkgtest runs failed. This could be fixed as well and the only remaining issue that needs some more investigation is related to cups-pdf. It is also worth mentioning that some issues related to the apparmor configuration of cups could be resolved.
• Helmut sent patches for 11 cross build failures.
• Helmut sent a MR for enabling the new mainline YT6801 ethernet Linux driver and it is now working fine with Debian s 7.x kernels.
• Helmut upgraded a crossqa.debian.net autobuilder to trixie .
• Carles using po-debconf-manager, improved Catalan translations: reviewed 2 packages, submitted 3 packages, deleted 5 packages.
• Carles did further code developments for check-relations: steps towards making it production ready when the initial round of reports are analyzed. New show-package (information) command, improvements for report_missing cases, added support for ignoring packages for specific reasons, added unit tests, added CI. Used it to open 39 new bugs. Also followed up different open bugs
• Rapha l completed the French translation of Zulip for the release of version 12.0. Zulip is a nice 100% free software threaded communication platform for distributed teams.
• Stefano did routine uploads of python-pipx, python-mitogen, platformdirs, python-authlib, python-discovery, distro-info-data, python-virtualenv, python-certifi, python-wheel, pypy3.
• Stefano uploaded distro-info-data updates to stable and oldstable proposed updates, with the latest Ubuntu release.
• Stefano took part in DebConf 26 preparation meetings.
• Stefano prepared DebConf s online video streaming infrastructure for MiniDebConf Campinas, and configured the Debian reimbursement system to handle their travel bursary claims.
• Stefano helped MiniDebConf Hamburg prepare their website for 2027.
• Stefano did some sysadmin work on debian.social infrastructure.
• Stefano reviewed Matthias python3.15 packaging and rebased his work on top of it.
• Antonio implemented several improvements to the Debian CI platform, including but not limited to adding support for dark mode, dropping compatibility with ActiveRecord < 7 which is no longer shipped in Debian stable, and generating content-based links to static assets, in two parts.
• Antonio debugged a general slowness in salsa, caused by loss of IPv6 connectivity between the salsa host and the remote object storage in the cloud , which is a problem due to an open upstream bug in gitlab.
• Santiago reviewed different changes to the Salsa CI pipeline, including the new uscan test job, prepared by Tha s Rebou as Araujo, and the final review to introduce faketime testing, made by quila Macedo.
• Santiago continued helping the DebConf 26 local team to prepare the conference.
• Emilio updated libxpm to address a security issue.
• Colin finished upgrading groff to 1.24.1; 1.24.0 and 1.24.1 were the first upstream releases since 2023 and had extensive changes, so this took some time to get right.
• Colin released bookworm and trixie fixes for CVE-2026-3497 in openssh, and issued the corresponding BSA-130 for trixie-backports.
• Colin upgraded openssh to 10.3p1.
• Anupa worked on the accounting tasks for MiniDebConf Kanpur and prepared and submitted a report to the fiscal host.

The Debian LTS Team, funded by Freexian s Debian LTS offering, is pleased to report its activities for April.

Activity summary During the month of April, 21 contributors have been paid to work on Debian LTS (links to individual contributor reports are located below). The team released 37 DLAs fixing 145 CVEs. The team continued preparing security updates in its usual rhythm. Beyond the updates targeting Debian 11 ( bullseye ), which is the current release under LTS, the team also proposed updates for more recent releases (Debian 12 ( bookworm ) and Debian 13 ( trixie )), including Debian unstable. We highlight several notable security updates here below.

• Andrej Shadura prepared DLA 4525-1 for libyaml-syck-perl to fix a vulnerability related to a memory leak.
• Andrej also prepared DLA 4551-1 for mbedtls to fix a leak of secrets.
• Arnaud Rebillout prepared DLA 4532-1 for python3.9 to fix a use-after-free issue in several decompressors.
• Arnaud also prepared DLA 4533-1 for systemd to fix multiple vulnerabilities, which might be also used to execute arbitrary code.
• Bastien Roucari s prepared DLA 4529-1 for bind9 to fix a DNSSEC issues, which can cause the resolver to consume excessive CPU.
• Bastien also prepared DLA 4539-1 for imagemagick to fix 21 vulnerabilities.
• Emilio Pozuelo Monfort prepared DLA 4535-1 for openssh to fix a potentially execution of arbitrary code.
• Emilio also Monfort prepared DLA 4526-1, DLA 4546-1 and DLA 4555-1 for firefox-esr to fix 31 vulnerabilities.
• Jochen Sprickerhof prepared DLA 4524-1 for postgresql-13 to fix multiple vulnerabilities, which might be also used to execute arbitrary code.
• Sylvain Beucler prepared DLA 4538-1 for perl to fix unauthorized access to data or arbitrary code execution.
• Thorsten Alteholz prepared DLA 4545-1 for packagekit to fix a local privilege escalation.
• Thorsten also prepared DLA 4544-1 for ntfs-3g to fix a local privilege escalation.
• Tobias Frost prepared DLA 4521-1 for libpng1 to fix multiple vulnerabilities, which might be also used to execute arbitrary code.

Contributions from outside the LTS Team:

• As usual, the thunderbird updates, released as DLA 4534-1 and DLA 4549-1, were prepared by its maintainer Christoph Goehre. This month 28 CVEs has been fixed. Thanks a lot for his continuous contributions. The DLAs have been sent by Emilio.
• Thanks alot as well to Mathias Behrle for providing DLA 4543-1 for package simpleeval. The DLA has been sent by Santiago.

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

• Andreas Henriksson completed the upload of gvfs for trixie and bookworm
• Ben Hutchings did uploads of several kernel packages to unstable and the corresponding backports repositories.
• Sylvain took care of uploads of awstats to trixie and bookworm. He also did the same for 7zip-rar with an upload to bookworm-backports).

Some milestones in the lifecycle of two Debian releases are just around the corner. The support of Debian 12 will be handed over to the LTS team on June 11th 2026. After August 31st, support for Debian 11 will move from Debian LTS to ELTS managed by Freexian.

Individual Debian LTS contributor reports

• Abhijith PA
• Andreas Henriksson
• Andrej Shadura
• Arnaud Rebillout
• Bastien Roucari s
• Ben Hutchings
• Carlos Henrique Lima Melara
• Chris Lamb
• Daniel Leidert
• Emmanuel Arias
• Emilio Pozuelo Monfort
• Guilhem Moulin
• Jochen Sprickerhof
• Lucas Kanashiro
• Lukas M rdian
• Markus Koschany
• Santiago Ruano Rinc n
• Stefano Rivera
• Sylvain Beucler
• Thorsten Alteholz
• Tobias Frost

Thanks to our sponsors Sponsors that joined recently are in bold.

• Platinum sponsors:
  • Toshiba Corporation (for 127 months)
  • Civil Infrastructure Platform (CIP) (for 95 months)
  • VyOS Inc (for 59 months)
• Gold sponsors:
  • F. Hoffmann-La Roche AG (for 137 months)
  • CONET Deutschland GmbH (for 121 months)
  • University of Oxford (for 77 months)
  • EDF SA (for 49 months)
  • Dataport A R (for 24 months)
  • CERN (for 22 months)
• Silver sponsors:
  • Domeneshop AS (for 142 months)
  • Nantes M tropole (for 136 months)
  • Akamai - Linode (for 131 months)
  • Univention GmbH (for 128 months)
  • Universit Jean Monnet de St Etienne (for 128 months)
  • Ribbon Communications, Inc. (for 122 months)
  • Exonet B.V. (for 111 months)
  • Leibniz Rechenzentrum (for 106 months)
  • Minist re de l Europe et des Affaires trang res (for 89 months)
  • Dinahosting SL (for 77 months)
  • Upsun Formerly Platform.sh (for 71 months)
  • Moxa Inc. (for 65 months)
  • Deveryware (for 64 months)
  • sipgate GmbH (for 63 months)
  • OVH US LLC (for 61 months)
  • Tilburg University (for 61 months)
  • GSI Helmholtzzentrum f r Schwerionenforschung GmbH (for 52 months)
  • THINline s.r.o. (for 25 months)
  • Copenhagen Airports A/S (for 19 months)
  • Conseil D partemental de l Is re (for 5 months)
• Bronze sponsors:
  • Evolix (for 142 months)
  • Seznam.cz, a.s. (for 142 months)
  • Intevation GmbH (for 139 months)
  • Linuxhotel GmbH (for 139 months)
  • Daevel SARL (for 138 months)
  • Megaspace Internet Services GmbH (for 137 months)
  • Greenbone AG (for 136 months)
  • NUMLOG (for 136 months)
  • WinGo AG (for 135 months)
  • Entr ouvert (for 126 months)
  • Adfinis AG (for 124 months)
  • Plat Home (for 120 months)
  • Tesorion (for 119 months)
  • Laboratoire LEGI - UMR 5519 / CNRS (for 118 months)
  • Bearstech (for 110 months)
  • LiHAS (for 110 months)
  • Catalyst IT Ltd (for 105 months)
  • Demarcq SAS (for 99 months)
  • Universit Grenoble Alpes (for 85 months)
  • TouchWeb SAS (for 77 months)
  • SPiN AG (for 74 months)
  • CoreFiling (for 70 months)
  • Observatoire des Sciences de l Univers de Grenoble (for 61 months)
  • Tem Innovations GmbH (for 56 months)
  • WordFinder.pro (for 55 months)
  • CNRS DT INSU R sif (for 54 months)
  • Soliton Systems K.K. (for 49 months)
  • Alter Way (for 47 months)
  • SOBIS Software GmbH (for 22 months)
  • Tuxera Inc. (for 13 months)
  • OPM-OP AS (for 5 months)

During March and April, we had a number of performance issues that made Debusine s core functions of running work requests and reflecting their results in workflows quite unreliable. Investigating and fixing this took up a lot of time from both the Debusine development team and Freexian s sysadmins. The central problems involved a series of database concurrency and worker communication issues that interacted in complex ways. On bad days, this caused between 10% and 25% of processed work requests to fail unnecessarily. We communicated some of the problems to users on IRC, but not consistently since we didn t entirely understand the scope of the problems at the time. Most of the problems are fixed now, but we had a retrospective meeting to make sure we understood what happened and that we learn from it. Here s a summary.

Data model Debusine s workflows consist of many individual work requests. Each work request has a database row representing its state, which means that the overall state of a workflow is distributed across many rows. Changes to one work request (for example, when it is completed) can cause changes to other work requests (perhaps unblocking it so that it can be scheduled to an idle worker). Those changes may happen concurrently, and in practice often do. Workers typically need to create artifacts containing the output of tasks: these include things like packages, build logs, and test output. Debusine records task history so that it can make better decisions about how to schedule work requests. Since this might otherwise grow without bound, the server expires older parts of that history after a while. The same is true for many other kinds of data.

Causes

• Because workflows involve changes that propagate between work requests, there were historically some cases where different parts of the system could deadlock due to trying to take update locks on overlapping sets of work request rows in different orders. We mitigated that somewhere around 2025-11-05 by locking entire workflows in one go before making any change that might need to propagate between work requests like this; that dealt with the deadlocks, but it s quite a heavyweight locking strategy that sometimes caused significant delays.
• We ve been working for some time to make Debusine useful to Debian developers, and regression tracking is an important part of that: it lets developers test uploads without being too badly misled by tests in related packages that were already failing before they started. On 2026-03-11 we enabled this by default on debusine.debian.net, after testing it for a while. Although this is useful, it put more load on the system as a whole, often approximately doubling the number of work requests in a given workflow with many additional dependencies between them.
• Like much of the world, we re in an arms race with unethical scrapers desperately trying to feed everyone else s data into LLMs before they run out of money. We saw a substantial uptick here towards the end of March, which meant that we had to temporarily disable regression tracking and to put some other mitigations in front of our web interface.
• We historically haven t had systematic internal timeouts. Prompted by ruff, a Google Summer of Code applicant went through and added timeouts in many places, including some calls between the worker and the server. This was fiddly work and the student did a solid job, so I m not putting them on blast or anything! However, it did mean that some things that came in under load balancer timeouts now timed out earlier on the client side of the request (and hence in Debusine workers), which made some problems show up in different ways and be more obvious. This was deployed on 2026-04-03.

Fixes

Workflow orchestration Figuring out what individual work requests need to be run as part of a workflow - the process we call orchestration - can be challenging. Unlike typical CI pipelines, these workflows often span substantial chunks of a distribution: a glibc update can involve retesting nearly everything! Nevertheless, it s not particularly helpful for it to take hours just to build the workflow graph. Fixing this involved many classic database optimizations such as adding indexes and CTEs, but probably the most effective fix was adding a cache for lookups within each orchestrator run or work request. Profiling showed that resolving lookups was a hot spot, and the way that task data is often passed down through a workflow meant that the same lookup could be resolved hundreds or thousands of times in a large workflow.

Expiry We knew for quite some time that our expiry job took very aggressive locks, effectively blocking most of the rest of the system. This was an early decision to make the expiry logic simpler by allowing it to follow graphs without worrying about concurrent activity, but it clearly couldn t stay that way forever. Row locks in PostgreSQL was very helpful in figuring out the correct approach here. Since we re mainly concerned about the possibility of new foreign key references being created to artifacts we re considering for expiry, and since that would involve taking FOR KEY SHARE locks on those rows, we can explicitly take FOR UPDATE locks (which conflict with FOR KEY SHARE), and then recompute the set of artifacts to expire with any locked artifacts marked to keep. This was delicate work, but it saved minutes of downtime every day.

Whole-workflow locking I mentioned earlier that we avoided some deadlock issues by taking locks on entire workflows. To ensure that these locks are effective even against code that isn t specifically aware of them, this is implemented by using SELECT FOR UPDATE on all the work request rows in the workflow. In some cases the search for which rows to lock itself tripped up the PostgreSQL planner.

Scheduling We run multiple Celery workers for various purposes. Some of them can do many things in parallel, but in some specific cases (notably the task scheduler) we only ever want a single instance to run at once. Unfortunately a bug in the systemd service meant that the scheduler often ran concurrently anyway! Once we fixed that, the scheduler logs became a lot less confusing. When Debusine was small, it was reasonable for it to perform scheduling very aggressively, typically as soon as any change occurred to a work request or a worker that might possibly influence it. This doesn t scale very well, though, and even though we tried to batch multiple scheduling triggers that occurred within a single transaction, it could still make debugging very confusing. We reduced the number of changes that would result in immediate scheduling, and deferred everything else to a regular tick . The scheduler may not be able to assign a work request to an idle worker due to the workflow being locked. That isn t a major problem in itself; it can just try again later. However, in very large workflows, we found that it often worked its way down all the pending work requests one by one finding that each of them was locked, which was slow and also produced a huge amount of log noise. It now assumes that if a work request is locked, then it might as well skip other work requests in the same workflow until the next scheduler run. Between them, these changes reduced the number of locks typically being held on debusine.debian.net by about 80%:

Worker refactoring The Debusine worker has always been partially asynchronous, but while it was actually executing a task - in other words, most of the time, at least in busy periods - it didn t respond to inbound websocket messages, causing spurious disconnections. We restructured the whole worker to be fully event-based. We also had to put quite a bit of effort into improving the path by which workers report work request completion, because if that hits a timeout then it can mean throwing away hours of work. We have some further improvements in mind, but for now we defer most of this work to a Celery task so that whole-workflow locks aren t on the critical path.

Database write volume One of our sysadmins observed that our database write volume was consistently very high. This was a puzzle, but for a long time we left that unexplored. Eventually we thought to ask PostgreSQL s own statistics, and we found a surprise:

debusine=> SELECT relname AS table_name,
debusine->        n_tup_ins AS inserts,
debusine->        n_tup_upd AS updates,
debusine->        n_tup_del AS deletes,
debusine->        (n_tup_ins + n_tup_upd + n_tup_del) AS total_dml
debusine-> FROM pg_stat_user_tables
debusine-> WHERE (n_tup_ins + n_tup_upd + n_tup_del) > 0
debusine-> ORDER BY total_dml DESC
debusine-> LIMIT 20;
              table_name                inserts    updates     deletes   total_dml
--------------------------------------+---------+------------+---------+------------
 db_collectionitem                      1418251   3578202388   3630143   3583250782
 db_token                                 15143     11212106     11389     11238638
 db_workrequest                          386196      6399071   1820500      8605767
 db_fileinartifact                      2783021      1837929   1663887      6284837
 django_celery_results_taskresult       1819301      1501623   1791656      5112580
 db_artifact                             960077      3340859    663890      4964826
 db_collectionitemmatchconstraint       1550457            0   2207486      3757943
 db_artifactrelation                    2229382            0   1363825      3593207
 db_fileupload                          1023400      1057036   1023346      3103782
 db_file                                1673194            0    970252      2643446
 db_fileinstore                         1411995            0    970259      2382254
 db_filestore                                 0      2381578         0      2381578
 django_session                          645423      1519880       531      2165834
 db_workrequest_dependencies             365877            0    936537      1302414
 db_worker                                18317       949280      9487       977084
 db_collection                            10061           85    177741       187887
 db_workerpooltaskexecutionstatistics     28721            0         0        28721
 db_workerpoolstatistics                   1640            0         0         1640
 db_workflowtemplate                        130          158       649          937
 db_identity                                 76          661         0          737
(20 rows)

Oh my - that s a lot of db_collectionitem updates and must surely be out of proportion with what we really need. Can we narrow that down by asking about the most recently-updated tuples?

debusine=> SELECT DISTINCT category
debusine-> FROM db_collectionitem
debusine-> WHERE id IN (
debusine->     SELECT id FROM db_collectionitem
debusine->     ORDER BY xmin::text::integer DESC LIMIT 10000
debusine-> );
           category
------------------------------
 debusine:historical-task-run
(1 row)

That might not be absolutely reliable, but it was certainly a hint. As per PostgreSQL s documentation, by default UPDATE always performs physical updates to every matching row regardless of whether the data has changed, and our code to expire old task history entries wasn t doing that properly. Once we knew where to look, it was easy to add some extra constraints. This reduced our mean write volume on debusine.debian.net from about 23 MB/s to about 3 MB/s, which had an immediate knock-on effect on our request failure rate:

Current state Our metrics indicate that things are a lot better now. We still have a few things to deal with, such as:

• Some more performance fixes are on their way to fix some remaining cases where views are very slow or where file uploads from workers fail due to locks.
• We have some changes in the works to revamp how work request changes propagate through workflows in a way that doesn t require so many heavyweight locks.
• We have a number of monitoring and alerting improvements we d like to make, both for outcomes (things like slow Celery tasks) and possible root causes (database performance). We d also like to deploy some more modern observability tools; hunting for things using journalctl isn t terrible, but it s not really the state of the art.
• We need to improve how we communicate to users when we re having operational problems, both informally (IRC, etc.) and on the site.
• Retries don t always behave the way you d expect in workflows.

I hope this has been an interesting tour through the sorts of things that can go wrong in this kind of distributed system!

Discussion of AI systems seems to be dominated by fears of uncommon and unlikely threats. I think that we should be focusing more on real issues with LLMs and with society in general and put the most effort towards the biggest problems. It s Not AI True Artificial Intelligence [1] (IE a computer that has the mental capacity of a household pet) is something that I think can be developed, but it hasn t been developed and we don t have good plans for developing it. We seem to be a lot further away from achieving that goal than we were from landing on the moon in 1962 when JFK gave his historic speech. What we have is a variety of pattern recognition systems that can predict what fits into a pattern. The most well known type of Machine Learning (ML) is the Large Language Model (LLM) which means ChatGPT and similar systems which predict which text would be likely to come next and can make an essay from it. They can give interesting and useful output, but there is no thought behind it, it s just a better form of Eliza (the famous program from 1964 that simulates conversation by pattern matching) [2]. By analysing billions of documents, storing the data in a condensed mathematical way, and then using computation to extract from that record LLMs can produce output that is unfortunately considered by some people to be good enough to include in legal documents submitted to courts, university assignments, and many other documents. But they do so without even having the thinking ability of a mouse. To call current systems AIs without any significant qualifiers when criticising them is to concede the debate about the worth of such things. If we develop AIs that can actually think we will have to deal with the issues in the SciFi horror short story Lena by qntm [3]. The Bad Arguments Here is a list of some of the most unreasonable arguments I ve seen against AI which distract attention from real problems both related to AI and other problems in society. Suicide and Homicide Wikipedia has a page listing Deaths Linked to Chatbots [4] which right now has 16 entries from 2023 to Feb 2026. They are all tragedies and as a society we should try to prevent such things. But what I would like to see from the media is some analysis of overall trends, yes it gets people s attention when someone dies in an unusual way but we need to have attention paid to the more numerous deaths which are preventable. It has become a standard practice to give information on Lifeline in media referencing suicide, it would be good if they also developed a practice of mentioning the relative incidence of a problem when publishing an article about it. One of the many factors that cause more suicides than chatbots is school, Scientific American has an informative article from 2022 about the correlation between child suicide and school [5]. It is based on US statistics and shows that the lowest suicide rate is in July (a no-school month in the US) which has a rate of 2.3 per 100,000 person years. So if kids had a quality of life equivalent to July all year around then there would be 2.3 suicides per 100,000 kids every year while if they had a quality of life equivalent to a Monday in January or November it would be 3.9 suicides per 100,000 kids every year. The article states Any time I present these data to teachers, parents, principals or school administrators, they are shocked. This should be common knowledge. It is common knowledge to anyone who takes any notice of what happens in schools, but paying attention to serious problems is unpleasant, it s more fun to pretend that school is good for everyone. No parent wants to think that they sent their child to a place that was horrible, no teacher wants to think that they are part of a system that harms kids. The US CDC has an informative article about youth suicide [6] which documents it as the 3rd largest cause of death in the 14-18 age range fro 2021. This article was published in 2024 and based on statistics from 2023 and earlier. It notes significant differences in suicides, attempts, and persistent feelings of sadness or hopelessness which had girls at more than twice the rate of boys and LGBQ+ kids at more than twice the rate of heterosexual students. It seems obvious that misogyny and homophobia is correlated with suicide and that s something that could and should be addressed in schools. My state has a Safer Schools program [7] to try and alleviate the problems related to homophobia, but I expect that things are getting worse in the US in that regard. 39.7% of kids in US high schools had persistent feelings of sadness or hopelessness before LLMs became popular, school could and should be a happy time for the vast majority of kids but instead almost half of the kids don t enjoy it and a majority of girls and LGBQ+ kids don t. Having no mention of trans kids is a significant omission from that article, based on everything I ve heard from trans people I expect that their statistics would be even worse. One could argue that the small number of deaths inspired by use or misuse of LLMs is an indication of a larger number of people suffering in ways that don t result in death and don t get noticed. But I don t think that can compare to the fact that the majority of girls and LGBQ+ kids have persistent feelings of sadness or hopelessness in the current school system. Regarding homicide, the Australian Institute of Criminology has an article showing that in the 2003-2004 time period 49% of women who were killed were listed as a domestic argument [8], that s something that could and should be addressed. That article claimed 308 homicide victims in that time period which is larger than the world-wide death toll from LLMs but also less than 1/3 the death toll from car accidents in Australia. Australia has less than 0.4% of the world population, a fairly low homicide rate, and a number of homicides that vastly outnumbers all world homicides related to LLMs. I think it s great to address any cause of suicide or homicide, but devoting government resources and legislation towards very uncommon causes instead of things that happen every day is not a good strategy. It would be fine to address all factors leading to suicide, but problems with the school system have been a major factor for decades with little effort applied to fix it. Fraud and Other Crime There is evidence of criminals using LLMs to help prepare for crimes, the ability to generate large amounts of text quickly can be used for fraud and extortion. This is going to be a serious problem and we need structural changes to society to deal with it. There is an ongoing issue of scammers convincing older people that their child or other young relative is in trouble and a large amount of cash is required to address it. This sort of scam as well as the more well known Nigerian scams will probably become more common as the cost of running them decreases. This may be more of a problem for people in developing countries as currently a common scam business model is to have people in regions where wages are low (such as Pakistan for one who I spoke to) scamming people in relatively wealthy countries like Australia so an attack with a low probability of success is financially viable. Cheaper attacks will make less affluent victims financially viable to the scammers. While writing this post I received a financial scam phone call trying to get me to invest in SpaceX that was run by an AI chat system, I expect to receive more of them and this is something that needs to be dealt with via both technical measures and legislation. Do we have to accept less freedom and less anonymity in finances as a cost of reducing financial crime? Greater restrictions on the use of cash would make some crimes more difficult or less profitable for criminals. As a society I think we need to have a discussion about a balance between financial freedom and freedom from criminal exploitation, failing to have such a discussion is likely to lead to policies which don t work well. Also one thing that ML systems are good at is recognising patterns in data. Banks could scan all their transactions and look for patterns that correlate with fraud. They currently do this badly and do things like locking credit cards when someone goes to another country and spends money. They could do a better job of that and involve the police in cases of obvious fraud even when the customer doesn t realise that they are a victim. This isn t a reason to criticise AIs , it s a reason to plan defensive technology that matches the capabilities of attackers. As an aside I used to work for a company that was developing AI software to scan bank phone calls and allow banks to recognise employees who acted illegally. Unfortunately the Royal Commission into banking misconduct [9] didn t impose any penalties that gave the banks a financial reason to avoid criminal activity. Unemployment and Inequality There are many claims about AI systems making large numbers of jobs obsolete, some of them are outlandish such as the claims that all white-collar jobs will be obsolete in the near future. There are some reasonable claims like the ability to replace some mundane jobs. Replacing jobs that suck with computers, robots, and other machinery is a good thing! Very few people wish that they were working on a farm without a tractor. In 1900 it s estimated that between 60% and 70% of the world labour force worked in agriculture and 40% of the US labour force did so. Now it s something like 27% globally and between 1% and 3% in developed countries. Automated factories are also a good thing, it s best to avoid boring and dangerous work. The most plausible claims about job replacement from AI is jobs that involve analysing and summarising documents. One example that comes to mind is the worst kind of journalism where press releases from companies are massaged into the format of a feature article. I don t think anyone wants that sort of job and doing it with AI hopefully means no human has to sign their name to it. For work like programming few people will be directly replaced by AI but if people can do their work more efficiently while using it then less people are required. I don t think that any programmer likes the part of their job where they have to skim read long documents looking for a clue about how to solve a problem with a library or protocol. A LLM processing the document and finding the potentially useful things will take away the drudgery from the work and allow greater productivity. The trend in replacing people has been making people work longer. If you force all employees to work 60 hour weeks then that can theoretically allow hiring fewer people than having 40 hour weeks. For some work that applies but for skilled work it mostly doesn t as productivity and work quality on average drops when people work more than 40 hours in a week. Another trend for exploiting people is having a low minimum wage and making accommodation expensive so that many people need to work two jobs. What we need is legislation to restore the situation in the 70s where a single full time job was sufficient to provide for a family. The low minimum wage and high expenses for many things is a problem that s been slowly developing over the course of decades while being mostly ignored by journalists. If they could concentrate on the real issues that are hurting workers today they could incite political action to fix these problems. Academic Cheating There is no shortage of ways of cheating in school and university. There are people who are paid to write essays, mobile phones are used for cheating in exams, etc. Getting an AI to write essays makes it easier to cheat for the essay writing part but does so with lower quality and in a less stealthy way. What s the worst case scenario? That we have to change to oral exams for all university subjects? In the US the average annual price for tuition at a university is apparently $25,000, if each student had individually supervised assessment for their exams at a cost of $100 per hour it would make the degree cost 4% more. The cost of university in the US is unreasonably high and that s a problem that needs to be fixed, but a hypothetical case of increasing the price by 4% isn t going to be a major part of it. Weak Arguments Against AI Computer Security Attacks There have been many claims made that AI will break the security of all systems and cause the type of disruption that was previously predicted for year 2000. Bruce Schneier has written a good analysis of the issues including how AI can be used by both attackers and defenders [10], he doesn t have a strong conclusion on whether the net result will be good or bad but his article does make it clear that the result is not going to be a total disaster. While I was working on this post I read another post by Bruce Schneier that was significantly more negative about this issue [11]. While I still don t think this will destroy civilisation I found his other post convincing enough to move computer security from the bad argument section to the weak argument section. Spidering the Web to Death There are issues of bots from AI companies doing a bad job of trying to download all the Internet s content and using a lot of resources. When it was just the major search engines and the Wayback Machine doing it the load was small due to having a small number of organisations that were very good at the way they did it having evolved practices over many years. Now we have a lot of idiots doing it badly and repeatedly hitting generated content. This is really annoying but is something that we can deal with. Currently my blog and many other sites are hosted on a Hetzner server with a E3-1271 v3 CPU with 32G of RAM and there are occasions where more than half the CPU power is being used to service web requests from such systems. Even on the server bidding (renting servers previously used by other customers) Hetzner isn t offering systems so slow nowadays, the slowest they offer is about 20% faster than that. This is something that can be dealt with by spending a little more on hosting until the companies doing that go bankrupt. I m sure this is a serious problem for some people, but for most people it s not a big deal. Also hostile traffic on the Internet is something we have all had to deal with as a part of life since the mid to late 90s. RAM Prices The unreasonably high prices for RAM are annoying and hurt the development of useful computer projects. Big companies can afford it, even with current high prices and large quantities of RAM used for some servers it s still not significant. But it is a major issue for hobbyists and small projects. Things like setting up a dozen test VMs for FOSS development are now too expensive for many people who develop software in their spare time. But this is a temporary thing, if AI companies were to keep buying RAM at high rates for a few years companies would just manufacture more of it to meet demand. In some situations capitalism can work. Environmental Damage There are many people claiming that power used by data centers for AI will lead to environmental damage, using power and water when there isn t enough. The trend of computer hardware is to get smaller and faster. It hasn t been going as fast as it used to in many areas but it hasn t stopped either and it s an exponential trend. There has been an increase in data centers (DCs) for AI use as the use has been increasing faster than the hardware gets smaller. Eventually they will stop increasing faster than advances in hardware and software can match and the size of DCs will decrease. As the production of renewable energy is increases the environmental cost of energy hungry industries decreases. In a few years this won t be an issue anyone is bothered about. False Claims About Danger as PR Jamie McClelland makes an interesting claim that the AI companies are pushing dangers of AI as a method of PR [12]. That seems plausible and combined with the tendency of many journalists to just massage press releases from companies into articles could be the reason for a lot of the bad arguments against AI. Good Arguments Against AI Spam Everywhere I ve previously written about Communication and Hostile AIs [13]. I think that filling all communication channels with rubbish is a denial of service attack against society. In the past communication took some effort, even the simplest email that was directly targeted at the recipient took some human effort and that reduced it s frequency. I get a lot of spam saying something like I see your web site doesn t rank in the top for Google searches while my web site in fact rates well and the actor named Russell Coker is ranking below me, so I know that such spam hasn t had the minimum of human involvement. Now a spammer who wanted to do a better job could get an LLM written spam for every target so the message was specifically aimed at them and would take much longer to be recognised by a human as spam and would also avoid most anti-spam software. Searching for businesses used to be easy, the phone book had listings for them and there was a real cost to being in the book as well as humans actively trying to stop fraud. Creating fake web sites to get business isn t too difficult but it s also not trivial at the moment and such fake sites won t look complete. Now with LLMs it s possible to create hundreds of sites that have content and look reasonable without human involvement. Instead of the small number of suicides and homicides inspired by AI chat systems we should probably be concerned about people who need psychological or medical advice being misled by bogus web sites created as part of fraud campaigns. Imagine people searching for mental health assistance finding web sites run by cults who oppose psychology as a profession. Imagine people searching for basic medical advice such as how to cook a healthy meal getting sucked in to web sites that start sane and then lead people to Ivermectin as a universal medicine. LLMs have the potential to take spam from quick and simple attacks to large scale targeted fraud aimed at people and organisations that don t have the resources to defend against it. There have been many reports of CEO impersonation fraud against major corporations aiming to steal hundreds of thousands of dollars and fraud against individuals who are persuaded to get amounts like $50,000 to help a relative who is allegedly in a difficult situation. But if every corner store experienced the same type of attack that CEOs experience and if every child had someone trying to steal the pocket money in the same way that relatively wealthy people are being targeted now it would really change things. David Brin wrote an insightful and informative blog post about this focusing on how AI generated content is being allowed to destroy YouTube [14]. Deep Fakes There is some overlap between filling all communications channels with rubbish (fake news etc) and deep fake. Making a fake photo of a politician or celebrity to lobby for legislative changes is a real issue but it s not what most people think of when the term deep fake is used. Using photo and video faking targeting non-consenting people is a serious issue. It s not just fake porn (which is a major issue and will cause some suicides) as there are many other possibilities. Fake videos showing behaviour that justifies sacking people from their jobs is going to become an issue, for people in public facing positions even proof that the videos are fake won t necessarily help them. Will we find ourselves in a situation where every politician gets deep-fake porn made of them and the only people who run for public office are ones who are cool with that? Will positions of leadership in the technology industry be restricted to people who aren t bothered by having the most depraved fake porn made of them? The Justice System We have seen a lot of evidence of law enforcement and the court system based on bias leading to bad results. The Innocence Project attempts to correct that and it s web site documents some of the things that have gone wrong [15]. Using AI systems to do some of the work of law enforcement by training computers on the flawed results of current systems can entrench bias and also make it harder to spot. When determining whether someone should be considered a suspect or whether a prisoner should be eligible for parole the number of factors that a human can use is limited. But a computer can take many more factors into account so the issues of whether inappropriate factors are being used can be masked. Computers are also unable to explain decisions that they made and are also able to come up with better fake reasons. In the past there have been racist policies in the US about banks not lending to people living in suburbs where most houses were owned by non-white people, these policies were documented and the documents have become part of the historical record showing racist policies. If a LLM decides not to lend money to people based on mathematical correlations it determined based on historical banking practices it could assign negative weights to factors such as non-English names and implement the racism in a large array of numbers with no proof. The current cases of lawyers getting LLM systems to do some of their work and having their incompetence revealed when the computer generated work is shown to be ridiculously bad are amusing. But that is not the real problem. The real problems will start when the computers in police cars start flagging every car owned by a non-write person as having a probable cause for a drug stop. Technically Not Financial Fraud The majority of the ecosystem around AI is a financial scam [16]. There are companies and individuals doing good things with machine learning some of which is based on hardware and software developed as part of this ecosystem. But the majority of it has no plausible path to profits and a the future of it inevitably ends with some bankruptcies. There are circular flows of money that have the major cloud providers and NVidia looped in, when the values of these companies correct it will become apparent that they have all burned a lot of money keeping this running and all the senior people have got a share of it (the entire purpose of stock options is to allow senior people to suck money out of the company). Then every cloud provider will increase costs while under chapter 11 and all the companies that depend on them will pay whatever it takes. That includes all major companies and most governments. Unlike the dot-com boom and crash and the housing crash the coming financial crash will impact every company that we deal with and most governments. So the people in first-world countries will effectively be taxed to pay for this scam while the executives go party in Monaco. This may seem like an extreme claim but it all happened before with the dot com crash and the housing market crash. The CEO class has an ongoing practice of doing things that aren t crimes because they lobby (bribe) politicians to make them legal. So the current stock market shenanigans around AI don t seem to involve things that governments consider to be crimes. But any normal person might be surprised to learn that such things are legal and most people would vote for such things to be crimes if they had the opportunity. A global financial crisis is the least of the problems that seem likely to afflict society from AI systems. But it will be more immediately obvious when it happens which could be this year! Propaganda Creating art requires skills that the type of people who want to create propaganda tend to lack. AI technologies allow creating art that is based on mathematical models of actual art to the requirements of the person running the program. I have seen the term AI Fascism used to describe the use of AI to help authoritarian governments. I am dubious about whether it deserves that term and while every article I ve read about the topic has had some good points I thought that they were all weak points. But there are lots of ways that governments can abuse their populations without going full fascist. In the last century there were lots of truly terrible governments that didn t even make the top 10 of fascism. AI Sycophants Bruce Schneier wrote an informative blog post about AI Chatbots and Trust which focused on sycophantic chatbots [17]. We have seen a lot of evidence of terrible behaviour and stupid decisions from rich people due to having no negative consequences for bad choices. The vast majority of the history of kings concerns bad decisions made by such people. A future where middle class and poor people can make the same bad decisions as rich people wouldn t be good. Good Things About ML Machine Learning (abbreviated as ML) can do useful things. It s not just Large Language Models (LLMs) such as ChatGPT etc. There are also ML systems that can analyse images and other data sets. I have found ChatGPT to be very useful for making suggestions for improving blog posts. I don t get it to write anything just ask for suggestions. It has pointed out things that I missed such as when I didn t include the price when reviewing a car because the car in question was much more expensive than I will ever pay, the price wasn t relevant to me but would be to some readers. It has also made useful suggestions about structure of blog posts, repeating points, and having a good conclusion. It has some downsides which include trying to erase my voice from my writing, suggesting that the rhetorical question does email suck? is unprofessional. I have worked for a company that used ML systems to analyse driver performance and alert people if a driver is falling asleep, using a phone, or otherwise seems unable to drive safely. Their business model involved a human reviewing the images from the drivers the computer flagged and then determining who is actually doing the wrong thing. This seems a good use of the technology. I have also worked for a company that used ML systems to analyse the performance of bank employees and detect potentially fraudulent behaviour. Preventing crime seems to be clearly a good thing and in this case the manager of the employee in question would review the evidence to make sure that they weren t being falsely accused. Conclusion I don t think that the problems with managing the changes that so called AI is introducing are particularly new. An example of how society handles change that s worth considering is car safety. The seat belt first became mandatory for aeroplanes in some jurisdictions in 1928. The Model T Ford is widely regarded as the first vehicle to start a mass market for cars and it was released in 1925. So if society acted in a reasonable way then for the majority of mass market cars seat belts would have been a standard feature. However seat belts were first made compulsory in 1970 in Victoria Australia and there are still people who think that they are safer without seat belts! The delay in adoption of car seat belts is only one example of needless deaths caused by not taking reasonable measures for car safety but it s one that s easy to demonstrate and measure. The difference between past problems like car safety and the current problems of AI is that the AI problems will be more pervasive. Most of my history as a car driver and car passenger was in cars that are much less safe than cars made in the last 10 years. But partly through luck I ve never been in a serious crash so being in cars that wouldn t have given me a low probability of surviving a freeway speed crash didn t affect me. There is no possibility that through any combination of luck and skill someone could avoid the downsides of AI . If nothing else the results of elections will be affected and no-one can avoid that. As a society we really need to address the real issues related to AI which in some cases requires legislation.

• [1] https://en.wikipedia.org/wiki/Artificial_intelligence
• [2] https://en.wikipedia.org/wiki/ELIZA
• [3] https://qntm.org/mmacevedo
• [4] https://en.wikipedia.org/wiki/Deaths_linked_to_chatbots
• [5] https://tinyurl.com/262hrtke
• [6] https://www.cdc.gov/mmwr/volumes/73/su/su7304a9.htm
• [7] https://www.vic.gov.au/safe-schools
• [8] https://www.aic.gov.au/sites/default/files/2020-05/cfi110.pdf
• [9] https://tinyurl.com/2cbhq737
• [10] https://tinyurl.com/254wy3br
• [11] https://tinyurl.com/2cnx7t48
• [12] https://tinyurl.com/27wgwqu4
• [13] https://tinyurl.com/2354dewc
• [14] https://tinyurl.com/28vhagfz
• [15] https://innocenceproject.org/
• [16] https://fromtheprism.com/anthropic-30-billion
• [17] https://tinyurl.com/2cc6tyov