August 18, 2026

John Goerzen

AI in Debian: The Vote, Proposals, and Nuance

Let me start with a hypothesis:

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

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

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

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

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

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

LLM use in Debian

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

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

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

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

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

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

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

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

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

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

Where are LLMs run? What is the environmental impact?

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

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

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

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

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

Assuming Conditions Never Change

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

For instance:

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

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

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

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

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

The Real Concerns

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

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

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

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

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

Brief analysis of the options

Considering the proposals:

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

In favor of nuance

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

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

18 August, 2026 01:39AM by John Goerzen

August 17, 2026

Ian Jackson

Debian LLM GR - Summary of the options

Debian LLM GR - Summary of the options

Introduction

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

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

A plea to the undecided voter

Suspending briefly my attempt to be neutral:

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

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

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

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

Table

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

Notes

Ordering

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

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

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

Upstream LLM code contributions

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

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

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

Ability of individual teams to set their own rules

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

I have therefore not tabulated this aspect.

Exceptions and nuances

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

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

[1] Footnote re proposal B

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

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



comment count unavailable comments

17 August, 2026 12:43PM

August 16, 2026

hackergotchi for Bits from Debian

Bits from Debian

Debian turns 33!

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

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

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

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

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

16 August, 2026 01:00PM by Debian Publicity Team

hackergotchi for Vasudev Kamath

Vasudev Kamath

Releasing debvulns-exporter and debvulns CLI 0.2.2

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

Handling Vulnerabilities in Non-Debian Origin Packages

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

How Did I Solve This?

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

Pitfall

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

Caching OSV Data

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

All cache expiration thresholds remain configurable via CLI flags.

Catch

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

Unified Cache Directory for CLI and Exporter

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

Dashboard Changes

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

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

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

What's Next?

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

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

Until then, happy hacking.

16 August, 2026 11:30AM by copyninja

hackergotchi for Benjamin Mako Hill

Benjamin Mako Hill

Sad Story

Picture of a box in a fireplace saying:

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

16 August, 2026 07:01AM by Benjamin Mako Hill

August 15, 2026

Sven Hoexter

FrOSCon 2026: TLS Talk

Info: German content only, sorry.

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

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

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

15 August, 2026 06:02PM

Russell Coker

Hacked by Chinafans

What Happened

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

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

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

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

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

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

WordPress Deficiencies

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

What Next?

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

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

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

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

15 Years

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

Related posts:

  1. blogging software Previously I asked for advice about running an Intranet blog,...
  2. WordPress and Thumbnails I have just had a lot of trouble with Thumbnails...
  3. WordPress Maintainability For a while I’ve been maintaining my own WordPress packages....

15 August, 2026 09:31AM by etbe

AMD Video Drivers, LLMs, and Debian Kernels

The AMD GPU Problem

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

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

Chat GPT Was Useful

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

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

Upgrading to Experimental

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

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

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

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

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

Future Support Options

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

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

Errors on AMD GPUs

2026-08-09T23:03:06.004792+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00024802
2026-08-09T23:03:06.004792+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 42037 thread kscreenloc:cs0 pid 42044
2026-08-09T23:03:06.004793+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-09T23:03:06.004794+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F048002
2026-08-09T23:03:06.004795+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 130) at page 2048, write from 'TC0' (0x54433000) (72)
2026-08-09T23:03:06.008762+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00004802
2026-08-09T23:03:06.008768+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 42037 thread kscreenloc:cs0 pid 42044
2026-08-04T01:13:37.505839+10:00 xev kernel: ------------[ cut here ]------------ 
2026-08-04T01:13:37.505859+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] drm_WARN_ON_ONCE(cur_vblank != vblank->last) 
2026-08-04T01:13:37.505862+10:00 xev kernel: WARNING: CPU: 6 PID: 210534 at drivers/gpu/drm/drm_vblank.c:362 drm_update_vblank_count+0x2f1/0x3c0 [drm] 
2026-08-04T01:13:37.505866+10:00 xev kernel: snd_intel_dspcfg wmi_bmof rc_core snd_intel_sdw_acpi drm_ttm_helper uas realtek snd_usbmidi_lib snd_hda_codec ttm mdio_devres snd_hda_core snd_seq_midi drm_kms_helper usb_storage mc snd_hwdep libphy snd_seq_midi_event intel_uncore snd_pcm_oss i2c_algo_bit serio_raw snd_rawmidi pcspkr snd_mixer_oss i2c_i801 video snd_seq snd_pcm i2c_smbus lpc_ich snd_seq_device mei_me e1000e snd_timer mei snd tpm_infineon soundcore joydev bnx2 wmi button nfsd auth_rpcgss nfs_acl lockd grace sunrpc coretemp br_netfilter bridge stp llc sg ghash_clmulni_intel loop msr i2c_dev drm efi_pstore configfs nfnetlink ip_tables x_tables autofs4 btrfs blake2b_generic dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 md_mod ext4 crc16 mbcache jbd2 crc32c_generic virtio_blk evdev hid_generic usbhid hid sd_mod xhci_pci xhci_hcd ahci ehci_pci ehci_hcd libahci crc32c_intel libata usbcore aesni_intel nvme psmouse scsi_mod gf128mul crypto_simd nvme_core cryptd 
2026-08-04T01:13:37.505879+10:00 xev kernel: nvme_auth scsi_common usb_common efivarfs 
2026-08-04T01:13:37.505880+10:00 xev kernel: CPU: 6 UID: 1008 PID: 210534 Comm: sshd-session Tainted: G D 6.12.88+deb13-amd64 #1 Debian 6.12.88-1 
2026-08-04T01:13:37.505881+10:00 xev kernel: Tainted: [D]=DIE 
2026-08-04T01:13:37.505883+10:00 xev kernel: Hardware name: Hewlett-Packard HP Z640 Workstation/212A, BIOS M60 v02.61 03/23/2023 
2026-08-04T01:13:37.505884+10:00 xev kernel: RIP: 0010:drm_update_vblank_count+0x2f1/0x3c0 [drm] 
2026-08-04T01:13:37.505885+10:00 xev kernel: Code: 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 68 eb 2b cf 48 c7 c1 70 3e cb c0 48 89 da 48 c7 c7 f9 6f cb c0 48 89 c6 e8 af d7 a6 ce <0f> 0b e9 4b fe ff ff 48 8b 4c 24 18 e9 31 fe ff ff 31 f6 48 85 db 
2026-08-04T01:13:37.505887+10:00 xev kernel: RSP: 0000:ffffd3cc8681fca0 EFLAGS: 00010082 
2026-08-04T01:13:37.505888+10:00 xev kernel: RAX: 0000000000000000 RBX: ffff8c6b42b13710 RCX: 0000000000000027 
2026-08-04T01:13:37.505889+10:00 xev kernel: RDX: ffff8c89ef521788 RSI: 0000000000000001 RDI: ffff8c89ef521780 
2026-08-04T01:13:37.505890+10:00 xev kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffffd3cc8681fb20 
2026-08-04T01:13:37.505891+10:00 xev kernel: R10: ffff8c8a6fef3628 R11: 0000000000000003 R12: 0000000000000000 
2026-08-04T01:13:37.505892+10:00 xev kernel: R13: ffff8c6c07853828 R14: 0000000000000003 R15: 0000000000000000 
2026-08-04T01:13:37.505893+10:00 xev kernel: FS: 00007ffaf2fd5880(0000) GS:ffff8c89ef500000(0000) knlGS:0000000000000000 
2026-08-04T01:13:37.505895+10:00 xev kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
2026-08-04T01:13:37.505896+10:00 xev kernel: CR2: 00007fb1718c8000 CR3: 000000074521a004 CR4: 00000000003706f0 
2026-08-04T01:13:37.505897+10:00 xev kernel: Call Trace: 
2026-08-04T01:13:37.505898+10:00 xev kernel:  
2026-08-04T01:13:37.505899+10:00 xev kernel: drm_crtc_accurate_vblank_count+0x41/0xc0 [drm] 
2026-08-04T01:13:37.505900+10:00 xev kernel: dm_pflip_high_irq+0x155/0x330 [amdgpu] 
2026-08-04T01:13:37.505901+10:00 xev kernel: amdgpu_dm_irq_handler+0x85/0x1f0 [amdgpu] 
2026-08-04T01:13:37.505902+10:00 xev kernel: amdgpu_irq_dispatch+0xd2/0x230 [amdgpu] 
2026-08-04T01:13:37.505903+10:00 xev kernel: amdgpu_ih_process+0x84/0x100 [amdgpu] 
2026-08-04T01:13:37.505904+10:00 xev kernel: amdgpu_irq_handler+0x23/0x60 [amdgpu] 
2026-08-04T01:13:37.505905+10:00 xev kernel: __handle_irq_event_percpu+0x4a/0x190
2026-08-04T01:13:37.505907+10:00 xev kernel: handle_irq_event+0x38/0x80 
2026-08-04T01:13:37.505908+10:00 xev kernel: handle_edge_irq+0x8b/0x230 
2026-08-04T01:13:37.505909+10:00 xev kernel: __common_interrupt+0x45/0xe0 
2026-08-04T01:13:37.505910+10:00 xev kernel: common_interrupt+0x42/0xa0 
2026-08-04T01:13:37.505911+10:00 xev kernel: asm_common_interrupt+0x26/0x40 
2026-08-04T01:13:37.505912+10:00 xev kernel: RIP: 0033:0x7ffaf3c5fd7b 
2026-08-04T01:13:37.505913+10:00 xev kernel: Code: 70 c7 00 66 0f 6e f8 c1 ef 02 66 0f 70 f7 e0 83 c7 01 66 0f ef ff 66 0f fa f2 0f 1f 44 00 00 f3 0f 7e 01 66 0f 6f ce 83 c6 01 <48> 83 e9 08 f2 0f 70 c0 1b 66 0f 6f e0 66 0f 6f e8 66 41 0f f9 c0 
2026-08-04T01:13:37.505915+10:00 xev kernel: RSP: 002b:00007fff86a5e0e0 EFLAGS: 00000202 
2026-08-04T01:13:37.505916+10:00 xev kernel: RAX: 0000000000008000 RBX: 0000562614a04050 RCX: 0000562614982ed8 
2026-08-04T01:13:37.505946+10:00 xev kernel: RDX: 0000000000007fe2 RSI: 0000000000000fad RDI: 0000000000002000 
2026-08-04T01:13:37.505948+10:00 xev kernel: RBP: 0000000000000000 R08: 000056261498ac40 R09: 0000000000008000 
2026-08-04T01:13:37.505949+10:00 xev kernel: R10: 0000000000000066 R11: 0000000000007fe1 R12: 0000000000007efa
2026-08-04T01:13:37.505950+10:00 xev kernel: R13: 0000000000008000 R14: 0000000000008000 R15: 000000000000ffe0 
2026-08-04T01:13:37.505951+10:00 xev kernel:  
2026-08-04T01:13:37.505953+10:00 xev kernel: ---[ end trace 0000000000000000 ]--- 
2026-08-04T01:55:40.844110+10:00 xev kernel: pcieport 0000:00:03.3: AER: Multiple Correctable error message received from 0000:00:03.3 
2026-08-04T01:55:40.844130+10:00 xev kernel: pcieport 0000:00:03.3: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Receiver ID) 
2026-08-04T01:55:40.844132+10:00 xev kernel: pcieport 0000:00:03.3: device [8086:6f0b] error status/mask=00000040/00002000 
2026-08-04T01:55:40.844134+10:00 xev kernel: pcieport 0000:00:03.3: [ 6] BadTLP
2026-08-11T09:33:33.473855+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00024802
2026-08-11T09:33:33.473871+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:33.473871+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-11T09:33:33.473873+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F048002
2026-08-11T09:33:33.473873+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 63) at page 2048, write from 'TC0' (0x54433000) (72)
2026-08-11T09:33:33.473874+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00004802
2026-08-11T09:33:33.473874+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:33.473875+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-11T09:33:33.473876+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E048002
2026-08-11T09:33:33.473876+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 63) at page 2048, read from 'TC0' (0x54433000) (72)
2026-08-11T09:33:35.481863+10:00 xev kernel: amdgpu 0000:02:00.0: Dumping IP State
2026-08-11T09:33:35.481875+10:00 xev kernel: amdgpu 0000:02:00.0: Dumping IP State Completed
2026-08-11T09:33:35.481875+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] AMDGPU device coredump file has been created
2026-08-11T09:33:35.481876+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] Check your /sys/class/drm/card0/device/devcoredump/data
2026-08-11T09:33:35.481877+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 146 0x0110040c
2026-08-11T09:33:35.481877+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:35.481878+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000022
2026-08-11T09:33:35.481879+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E00400C
2026-08-11T09:33:35.481879+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x0c, vmid 7, pasid 63) at page 34, read from 'TC3' (0x54433300) (4)
2026-08-11T09:33:35.489845+10:00 xev kernel: amdgpu 0000:02:00.0: ring gfx timeout, signaled seq=5123619, emitted seq=5123621
2026-08-11T09:33:35.489853+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:35.489854+10:00 xev kernel: amdgpu 0000:02:00.0: GPU reset begin!. Source: 1
2026-08-11T09:33:35.493839+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] ERROR Failed to initialize parser -125!
2026-08-11T09:33:35.737848+10:00 xev kernel: amdgpu: cp is busy, skip halt cp
2026-08-11T09:33:35.897842+10:00 xev kernel: amdgpu: rlc is busy, skip halt rlc
2026-08-11T09:33:35.897852+10:00 xev kernel: amdgpu 0000:02:00.0: BACO reset
2026-08-11T09:33:36.485849+10:00 xev kernel: amdgpu 0000:02:00.0: GPU reset succeeded, trying to resume
2026-08-11T09:33:36.485859+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] PCIE GART of 256M enabled (table at 0x000000F402000000).
2026-08-11T09:33:36.485860+10:00 xev kernel: amdgpu 0000:02:00.0: VRAM is lost due to GPU reset!

Errors on Battlemage

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

Related posts:

  1. AMD Video Driver Issues I have had some graphics hangs on my HP z640...
  2. Kernel issues with Debian Xen and CentOS Kernels Last time I tried using a Debian 64bit Xen kernel...
  3. PCIe Problems HP z840 Dead Slot I just had an issue with...

15 August, 2026 08:09AM by etbe

August 14, 2026

Reproducible Builds (diffoscope)

diffoscope 328 released

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

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

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

You find out more by visiting the project homepage.

14 August, 2026 12:00AM

August 13, 2026

hackergotchi for Gunnar Wolf

Gunnar Wolf

File recovery in process...

Ohai,

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

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

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

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

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

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

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

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

13 August, 2026 05:47PM

hackergotchi for Jonathan Dowland

Jonathan Dowland

DIY skate punch-out

The punch set-up
the punched boot

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

I basically followed the process from this helpful YouTube video.

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

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

take 2

take 2

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

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

13 August, 2026 08:28AM

August 12, 2026

hackergotchi for Steinar H. Gunderson

Steinar H. Gunderson

The PSX GPU is wild

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

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

12 August, 2026 03:26PM

Reproducible Builds

Reproducible Builds summit 2026 to take place in Gothenburg

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

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

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

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

About the event

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

Schedule

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

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

Logs and minutes will be published after the meeting.

Location & date

Registration instructions

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

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

12 August, 2026 12:00AM

August 11, 2026

hackergotchi for Colin Watson

Colin Watson

Free software activity in July 2026

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

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

OpenSSH

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

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

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

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

Installer team

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

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

Python packaging

New upstream versions:

Other build/test failures:

I fixed some other bugs:

I adopted transaction for the Python team.

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

Code reviews

Other bits and pieces

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

I upgraded yubihsm-shell to 2.8.0.

11 August, 2026 10:42AM by Colin Watson

hackergotchi for Freexian Collaborators

Freexian Collaborators

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

Debian Contributions: 2026-07

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

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

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

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

d-i VLAN support, by Colin Watson

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

Miscellaneous contributions

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

11 August, 2026 12:00AM by Anupa Ann Joseph

August 10, 2026

hackergotchi for Bits from Debian

Bits from Debian

DebConf26 Local Team says goodbye

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

Words from DC26 Local Team

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

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

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

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

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

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

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

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

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

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

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

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

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

We hope our paths cross again somewhere in life.

Best regards,

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

About Debian

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

About DebConf

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

Contact Information

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

10 August, 2026 09:50PM by Publicity team and DebConf26 Local Team

hackergotchi for Jonathan Dowland

Jonathan Dowland

time-delayed scifi roundup feed

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

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

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

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

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

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

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

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

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

10 August, 2026 02:44PM

Uwe Kleine-König

PGP Keysigning on Linux Plumbers and OpenSource Summit Europe 2026

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

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

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

10 August, 2026 02:37PM

August 09, 2026

Elana Hashman

Managing virtualenvs with a little bash

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

A quick virtualenv intro

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

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

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

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

To use the virtualenv, you must activate it:

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

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

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

deactivate

Wonderful!

Managing many virtualenvs gets annoying

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

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

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

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

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

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

Now all we need to run is

setup-venv my-virtualenv

So much quicker!

Spicing it up with tab completion

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

Well, we can write it ourselves 😄

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

apt install bash-completion

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

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

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

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

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

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

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

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

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

Complaints, comments, questions?

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

09 August, 2026 08:00PM by Elana Hashman

Reproducible Builds

Reproducible Builds in July 2026

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

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

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

In this month’s report, we cover:

  1. Tool development
  2. Distribution work
  3. Three new scholarly papers
  4. Patches
  5. Misc news

Tool development

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

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

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


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


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


Distribution work

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

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

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

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


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


Three new scholarly papers

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

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


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

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


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

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


Patches

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


Misc news

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

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

(Full thread)



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

09 August, 2026 07:12PM

August 07, 2026

Thorsten Alteholz

My Debian Activities in July 2026

Debian LTS/ELTS

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

During my allocated time I uploaded or worked on:

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

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

Debian Printing

This month I uploaded a new upstream versions:

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

This work is generously funded by Freexian!

Debian Lomiri

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

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

Debian Astro

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

Debian IoT

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

Debian Mobcom

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

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

misc

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

07 August, 2026 05:02PM by alteholz

Reproducible Builds (diffoscope)

diffoscope 327 released

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

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

You find out more by visiting the project homepage.

07 August, 2026 12:00AM

August 06, 2026

hackergotchi for Bits from Debian

Bits from Debian

DebConf26 closes in Santa Fe and DebConf27 announced

DebConf26 group photo - click to enlarge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

See you next year!

About Debian

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

About DebConf

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

About Infomaniak

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

About Proxmox

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

Contact Information

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

06 August, 2026 09:50PM by Debian Publicity Team and Volunteers

Russell Coker

TV Control etc

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

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

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

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

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

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

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

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

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

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

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

Related posts:

  1. Netflix and IPv6 It seems that Netflix has an ongoing issue of not...
  2. Big Smart TVs Recently a relative who owned a 50″ Plasma TV asked...
  3. The Problem is Too Many Remote Controls I am often asked for advice about purchasing TVs and...

06 August, 2026 04:01AM by etbe

hackergotchi for Gunnar Wolf

Gunnar Wolf

Subscription Bombing • Email under Attack

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

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

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

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

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

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

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

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

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

06 August, 2026 12:17AM

August 05, 2026

Iustin Pop

Yes-yes, still alive!

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

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

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

Stay well!

05 August, 2026 05:34PM

Enrico Zini

Gnome refusing to suspend

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

Swearwords.

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

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

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

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

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

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

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

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

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

05 August, 2026 07:57AM

August 04, 2026

Russell Coker

Monitors for Work

The Corporate Monitor Issue

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

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

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

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

Company Ownership

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

Who Will it Help?

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

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

Costs of Employees

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

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

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

Job Interviews

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

Related posts:

  1. Cheap Peripherals for Work A problem with a lot of the purchase of peripherals...
  2. monitors for developers Michael Davies recently blogged that all developers should have big...
  3. 4K Monitors A couple of years ago a relative who uses a...

04 August, 2026 10:41PM by etbe

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

#058: Reverse Dependencies Made Easy, Fast, Reliable

Welcome to post 58 in the R4 series.

R and the CRAN repositories maintain a very high level of what we might call “quality assurrance” by requiring that newly-added code does not break any existing dependencies. This is frequently called a “reverse-dependency check”. For any given CRAN package one can quickly determine it reverse dependencies. Calling tools::package_dependencies(pkgName, reverse=TRUE) will for a scalar or vector-valued argument return a named list with the reverse dependencies. It is then a matter of looping over this list. There are helper functions in base R as well as in contributed packages on and off CRAN. I also wrote my own with package prrd which, while possibly a wee bit specialised and under-documented has served me well to check on Rcpp and related packages which can indeed have a large number of reverse dependencies.

I recently looked into one of these contributed runner packages, and while I will refrain from naming its implementation language let me just mention that the term “cargo cult” may be a real thing here. What go me interested in this was the fact that if one has a simple-to-use runner then the fact that r2u makes it “fast, easy, reliable: pick all three” (to borrow its slogan) to deal with actual depencies if Ubuntu has indeed been selected as the host. We will maintain the position that if you can in fact integrate with the system-wide package management then any alternative per-repo package management approach not doing so will likely be dominated by an approach that does integrate with the system facilities. Which is what precisely what r2u does, and offers. And why it is used enough to by now have shipped eighty eight million binary packages. So I tested it for the reverse-dependency check task.

What I learned by looking into the (much more complicated) runner was that it at the end of the day it hands the actual task of running the reverse dependecies off to a helper function rev_check that is part of the xfun package by Yuhui. I quickly found that besides xfun we would also need its suggested dependency tinytex which in turn would error unless the tlmgr binary was present. So as the sole requirement (on an Ubuntu system with r2u) turns out to be

$ apt install r-cran-xfun r-cran-tinytex texlive-base

where we do it all in one apt call (as root in the container). (Given r2u we could also call install.packages(c("xfun","tinytext")) followed by apt install texlive-base but it is simpler for this setup step to be just one call).

With that we are basically done. I did this (twice) using a rocker/r2u container with r2u preinstalled, mounting a local work and scrap directory for the container. In it we expand the package to be tested (i.e. tar xaf pkgName_*tar.gz for a given source package pkgName from CRAN) and then just call with the package name and expanded direcrtory. I.e. I used this call to test my package AsioHeaders (which has just three reverse dependencies) to both name it and to point to the expanded source directory created for this purposed:

> system.time( res <- xfun::rev_check("AsioHeaders", src="AsioHeaders") )
## ... earlier output omitted for brevity here ...
   user  system elapsed 
 35.732   3.333 149.683 
> res
   httpgd ipaddress websocket 
        0         0         0 
>

and about a good two minutes later I would get the timing result and the summary in variable res. As I checked the current CRAN version, the check was as expected free of concerns or issues.

To support this, r2u did indeed go off and install about sixty seven binary packages (and the total includes all binary dependencies fully resolved) delivering on the ‘just works’ promise by the r2u documentation.

As another check, I did the same for RcppAnnoy which has seven reverse dependencies and needed about two hundred CRAN packages to be installed. The full test took just over four minutes with the timing function reporting some nice gains from parallelisation as total user compute time was on the order of just under eight minutes. Again, test results were clean and free of worries as expected:

> system.time( res <- xfun::rev_check("RcppAnnoy", src="RcppAnnoy") )
## ... earlier output omitted for brevity here ...
   user  system elapsed 
471.765 378.220 266.855 
> res
   bbknnR  bigANNOY  blocking     scDHA    Seurat      uwot VectrixDB 
        0         0         0         0         0         0         0 
>

Overall this was a rather useful quick excursion as it demonstrates that - existing functions can be used to orchestrate a reverse dependency check - with ‘reasonable’ dependency scale we can do this on a single machine quite easily taking advantage of parallel computing on multi-core machines - using r2u gives us fast, easy, reliable package installation making testing of packages we might not otherwise use or know a breeze - doing this in an ephemeral Docker container facilitates easy build-up of required resources and leaves no side effects behind which might affect our normal development environment

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

04 August, 2026 05:22PM

Petter Reinholdtsen

FreeCAD MCP with llama.cpp, toy or tool?

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

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

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

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

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

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

04 August, 2026 09:00AM

August 03, 2026

hackergotchi for Junichi Uekawa

Junichi Uekawa

Summer Holiday.

Summer Holiday. Busy time as a parent.

03 August, 2026 10:03PM by Junichi Uekawa

hackergotchi for Bernhard R. Link

Bernhard R. Link

I learned something new about URLs today

Today I stumbled over some behavior that I found quite surprising: 

$ ipython3 -c 'import httpx;print(httpx.URL("https://example.com/foo/bar/../../baz"))'
https://example.com/baz

Even more surprising that behavior is actually standards-compliant, even mandated by RFC 3986.

The underlying motivation is relative reverences. If some resource reachable by "https://example.com/foo/bar" references another resource relatively as "../../baz" then this is of course the intended result.

Getting from this problem to what RFC 3986 suggests might be surprising in the result, but somewhat understandable if you look at the consequences of that problem:

Giving the path components ".." (and ".") special meaning at the start of the relative reference means that if you allowed them in absolute URLs those would be impossible (or at least very convoluted) to address as relative URLs.

So RFC 3986 describes a way to handle them everywhere: Just join the path of the base URL and the path of the relative reference and normalize the result. Or normalize the absolute on either side if only that is to be taken. This makes things very convenient: Multiple reference URLs can just be joined without special handling for relative references starting with dots, making writing applications handling them easier. Programmers don't have to care how to handle relative references and can just join everything in whatever way they want.

For maximum elegance there is still some corner case left: What happens if an absolute URL has a path starting with double-dot components? Or an relative path starting with more of them then the base URL's path has components. You just ignore them: 

$ ipython3 -c 'import httpx;print(httpx.URL("https://example.com/../../baz"))'
https://example.com/baz

With that last point every URL is valid and has well-defined meaning. Handling relative references and relative paths is very easy and convenient.

So this shows a high regard for simplicity, elegance and convenience. And a total and uncompromising disregard of security.

After all the most convenient it is for an attacker; If they are allowed to supply a path component for a request a system does in their behalf, then they can easily escape anything they were supposed to be limited to. The ignoring of dots at the start means they don't even have to know exactly how deep their request is: 

$ python3 -c 'import httpx;print(httpx.URL("https://example.com/public/api/public/resources/harmless/../../../../../../../../../internal/data"))'
https://example.com/internal/data

So even if the resource server securely handles request (unless you consider not having any way to lower your permissions for one request to a specific subset), your fully RFC conforming client library will already request the permission they should not have permission for. Even worse dots are usually not characters you can easily forbid so once slashes are to be allowed things get complicated.

There also would have been a simple, elegant and secure way: Consider every path element ".." or "." in an (absolute) URL an error. Define a reference resolution that allows the relative reference to only start with "./" or one or multiple "../" and consider every appearance of a dot or two dots as path components after than an error.

Everything joining two paths has to either use an implementation of that path joining algorithm, but only if they want to joins paths in the potentially dangerous way allowing leading "../". Otherwise they can just use the normal join and even if an attacker gets those dots that will just cause the generated URL to be rejected as invalid.

Of course using a secure implementation is now even more inconvenient thanks to RFC 3986 being around: If you have no control over the generator of relative references, it is always possible that they generate relative references with ".." components after non-dot components.

And if you check all code to properly filter out "/../", keep in mind that convienence does not stop there. After all it is not unheared of for server implementations to helpfully normalize unicode characters, too, or translate them to their nearest ASCII equivalents. Or translate percent escaped characters back before doing path splitting. Or you might think there was some unicode codepoints between those two dots, but they that those were some meaningless control characters that can be omitted. So you need some really restrictive allow lists...

03 August, 2026 07:39PM

John Goerzen

Celebrating 45 Years of Kermit with the First New C-Kermit Release in 15 Years (and working with a decades-old C codebase)

1981 was a different time for computing. It was expensive (both hardware and software), and it was far from a given that machines from one vendor would be able to talk to those from another. In fact, Columbia University had just such a problem, so in 1981, Frank da Cruz and Bill Catchings designed a serial protocol they called Kermit. Because of the many quirks of the DEC-20 and IBM mainframes, the Kermit protocol was highly adaptable from the start: able to handle systems that had trouble processing more than 96 bytes of data at once, able to transfer 8-bit files over 7-bit links, able to translate between character sets (ASCII and EBCDIC then; now also various Unicodes), and of course, handling of error-prone serial links.

Kermit spread rapidly; by 1982, Kermit had been ported to MS-DOS and Unix. Eventually, C-Kermit (an implementation of Kermit in C) became the flagship Kermit. It gained TCP support, an interactive CLI, a powerful scripting language (with features from the shell, Lisp, and expect), and optimizations for today’s high-speed links, such as jumbo packets, sliding windows, and streaming modes. Along the way, Kermit flew on the International Space Station, ran data collection from sensors during hurricanes, and many other uses including postal systems, Boeing 787 manufacturing, and more.

Today, I use it as a powerful ssh wrapper (letting me easily transfer files through multiple nested ssh, sudo, su, etc. commands), a BBS client, to exchange data with me HP 48GX calculator, and so on. It’s also used today to transmit firmware updates to embedded devices. And, of course, anyone that works with vintage systems is likely to use Kermit at some point.

It wouldn’t be until the late 1990s that the TCP/IP stack was finally adopted by most OS vendors, establishing something of a common basis for communication. Of course, we assume this today. Though transferring large files between OSs (say, Linux, Windows, MacOS, Android, iPad, etc.) is still a challenge, even though they all speak TCP/IP! I find that the easiest way to get large files from two computers is to spin up Kermit (see ckwin for a Windows fork of C-Kermit) and just set up a TCP connection over the LAN. In fact, I added a new show interfaces command in C-Kermit 11, making it easy to see your system’s local IPs.

For most of its history, Columbia’s Kermit project was self-funded. Columbia charged for commercial use, which limited its inclusion in Linux distributions. In 2011, 30 years after its founding, Columbia canceled the Kermit Project and released C-Kermit as Open Source under a BSD license. Frank da Cruz, who had still been working with the Kermit project all those years, volunteered to continue maintaining Kermit outside Columbia, and continued development with alpha and beta releases through his retirement from the project in 2025.

I dive into this C codebase

As Debian maintainer of Kermit, I noticed some areas where it wasn’t matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year.

I’ve worked with old C codebases before, such as Varnish. I’ve generally hated it. You usually find a mix of bad and terrible practices, unclear memory management, and so forth.

But I’ve been living in the C-Kermit codebase for a few months now, and I enjoy it. Yes, this thing is still designed to build on VMS, OS/2, and with compilers that haven’t heard of ANSI — and those that require modern practices. (That em-dash was mine; I knew how to use them before LLMs existed and I’m not going to stop just because LLMs have copied people like me! No AI was used for this post.)

The there is an elegance in all of that. As I worked, I fixed a bunch more potential security issues, both with memory safety and with protecting against a malicious remote in roughly the same manner that some patches to scp did a few years back. I added IPv6 support, of course conditionally compiled because some systems C-Kermit builds on have never heard of IPv6 and never will. (And, of course, with fallback algorithms at runtime for systems that have IPv6 support but not IPv6 connectivity.)

I added unit tests and Python-based end-to-end tests, running nearly 2000 test cases in total. Along the way, I found and fixed a number of bugs going back decades. I learned about FIONREAD being broken on macOS, about NetBSD’s bugs in the pty driver, and fixed bugs in the Kermit protocol implementation itself. I added compatibility tests with the gkermit and ekermit (embedded) implementations, as well as the last full release, C-Kermit 9.0.302 from 2011 (which was difficult to get compiled on a modern system).

There is an extensive changelog describing all the improvements in C-Kermit 11.

C-Kermit development had never really used a VCS at any point, though Kermit veteran Jeffrey Altman imported historical releases into a Git repo, along with some patches that hadn’t made it into a release (which I also pulled in.) There was a lot of disabled code behind COMMENT, along with commentary describing why it was no longer used. With Git, we would now generally just remove the old code and explain why in a commit message. I went through and did so with a lot of it, meaning that, at last check, C-Kermit actually has fewer lines of code now than it used to.

Towards a new release

It became apparent pretty quickly that I was making more changes than would make sense as a Debian patch series. Not only that, but they would be more widely applicable to more than just Debian and Ubuntu users. As Linux and BSD distributions were running everything from the last non-beta release (2011’s 9.0.302) to the last beta release (about 1.5 years ago), depending on their different policies about running betas, even sharing patches in a useful fashion was going to be quite difficult.

So, I spun up a project at Open Kermit to coordinate future development in the open and keep Kermit going.

With modern CI, I run that test suite on Linux (x86_64 and arm64), macOS, FreeBSD, NetBSD, and OpenBSD. It builds binary releases on all those platforms, plus a statically-linked Linux binary built with musl libc.

You can download the latest C-Kermit release, and of course contribute to C-Kermit and its website.

Dedication

Frank da Cruz was directly involved with Kermit for 44 years. I’m not aware of any other Open Source project founder being involved for so long. Richard Stallman started working on GNU Emacs in 1984, 3 years after Frank started working on Kermit, but Richard hasn’t been in that role since around 2008.

Accordingly, C-Kermit 11 bears this dedication:

I dedicate this release of C-Kermit to Frank da Cruz.

Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long.

When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so.

Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines.

As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit.

John Goerzen, July 2026

03 August, 2026 03:45PM by John Goerzen

August 02, 2026

Russ Allbery

Term::ANSIColor v6.0.0 TRIAL release

Yesterday, I uploaded Term::ANSIColor v6.0.0-TRIAL to CPAN for early testing. This release will raise the minimum required Perl version to 5.12, dropping support for Perl 5.8 and 5.10. When I did the same with podlators a couple of years ago, it upset a few people and one of them asked me to make this sort of test release in the future. Hopefully this will help.

I have not run the normal release machinery and haven't archived this release in the normal places, since I intend it to be transient. It's only on CPAN, where people can retrieve it for testing. Once v6.0.0 is released, few traces of this TRIAL release will be left. This doesn't appear to be how other people use the TRIAL mechanism, but it felt more comfortable to me. If I have to make substantial changes, I'll consider changing my approach.

I plan on turning this into the v6.0.0 release in about a month or two, hopefully with only documentation changes.

Term::ANSIColor is a "very upstream" core module with a lot of dependencies, and CPAN (unlike some of the archives that followed it, such as PyPI) doesn't support conditionally retrieving packages based on the current Perl version. This release may therefore be disruptive for people who are still trying to support Perl 5.8 and 5.10, since CPAN installation tools may attempt to install an incompatible Term::ANSIColor version. I'm sad that this will be the result, since I know some people still care about those versions.

I'm pressing forward with updating my Perl modules anyway, though. I realized that honoring other people's desire for stability to such a degree that I was unable to use Perl features added more than 15 years ago was destroying my motivation to work on these Perl modules at all. So I've decided on a very slow and gradual approach where I'm going to keep pushing the minimum supported version forward but try to give people a lot of warning.

Personally, I think it's time to let ancient versions of Perl go and follow the Lyon Amendment about supported Perl versions. When we're talking installing new modules for software released more than 15 years ago, we're talking about special limited environments and retrocomputing more than what I would consider routine software maintenance. Those tasks should expect to need different tools and a different workflow so that they can pin historical versions. Since this isn't something I'm personally interested in, my willingness to expend time and energy to assist is limited.

As you can probably tell, I still feel nervous about pressing forward in this way, but I think this is the approach that lets me continue to enjoy maintaining these Perl modules. It's been 29 years for Term::ANSIColor, but I still enjoy fixing bugs in it and putting out a new release from time to time, particularly if I can clean up the code a bit each time I touch it.

02 August, 2026 09:49PM

hackergotchi for Ben Hutchings

Ben Hutchings

FOSS activity in July 2026

02 August, 2026 05:06PM by Ben Hutchings

Russell Coker

Packet Edit Meme and Debian SE Linux

There’s yet another Linux kernel exploit based on container functions, here’s the result when run as user_t on a SE Linux system:

$ ./packet_edit_meme 
[*] target /bin/su as uid 1000; entry at file offset 0x4340; shellcode 48 bytes
unshare: Permission denied
[-] page-cache corruption failed

Here is the audit log entry for this failure:

type=AVC msg=audit(1785640621.498:1843): avc:  denied  { create } for  pid=1770 comm="packet_edit_mem" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=user_namespace permissive=0

Here’s the result of running it from the unconfined_t domain:

$ ./packet_edit_meme 
[*] target /bin/su as uid 1001; entry at file offset 0x4340; shellcode 48 bytes
[+] su entry overwritten; exec'ing su -> interactive root shell
# id
uid=0(root) gid=0(root) groups=0(root),1001(test2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
#

Daniel Baumann wrote a blog post describing how this is fixed for Debian systems without SE Linux.

Related posts:

  1. Debian SE Linux and PinTheft We have a new Linux exploit called PinTheft [1]. I...
  2. Debian SE Linux and ssh-keysign-pwn I just tested out the ssh-keysign-pwn exploit [1] on Debian...
  3. Dirty Frag on Debian and SE Linux Hot on the heels of the Copy Fail vulnerability [1]...

02 August, 2026 03:42AM by etbe

August 01, 2026

Russ Allbery

Review: How to Steal a Galaxy

Review: How to Steal a Galaxy, by Beth Revis

Series: Chaotic Orbits #2
Publisher: DAW Books
Copyright: December 2024
ISBN: 0-7564-1949-2
Format: Kindle
Pages: 143

How to Steal a Galaxy is a far-future science fiction caper short novel (maybe a novella?) and the sequel to Full Speed to a Crash Landing. You don't have to remember the details of the previous book to enjoy this one. There's an excellent inline summary at the start of this installment.

After an annoying negotiation with people who keep trying to preach at her about causes, Ada Lamarr has a new contract. She is going undercover, after a fashion, at a charity gala and auction on Rigel-Earth. While she's there, she's going to steal something. What, precisely, she keeps a mystery from both the other characters and from the reader until the end of the story.

Government agent Rian White is working security at this charity gala. Due to its link with the plot of Full Speed to a Crash Landing, he was fairly certain Ada would be there, as indeed she is. What she is planning, however, is maddeningly unclear. Also maddening is how good Ada looks in a dress.

As with the previous book, How to Steal a Galaxy is told by Ada in the first person using the same teasing tone and constant misdirection that she uses when verbally fencing with Rian and the other characters. I found this novella even more entertaining and satisfying than the previous one. The charity gala is supposedly intended to benefit the poor people of Earth, and is run with exactly the sort of condescension and disguised capitalist looting typical of such exercises in elite charity. Ada's narration is scathing in a deeply relatable way.

Also, there is a trillionaire tech-bro fake philanthropist who is smug and condescending and accustomed to getting exactly what he wants.

"I don't think anyone should have enough personal wealth to decimate a large country's income just because he's going through a midlife crisis."

Ada's interactions with Strom Fetor are an absolute delight. He is so sure of himself that he is incapable of registering her as a threat, and she effortlessly deceives him by hiding in plain sight.

"You really shouldn't be talking about this," Rian starts.

Fetor waves aside his concerns. "We're all friends here."

"Not me," I say. "I hate you. Remember?"

Fetor laughs in a tone I'm sure he thinks is charming.

Fetor's complete inability to realize that a beautiful woman might both sincerely not like him and not be flirting with him is perfect. I was cackling through half of this book.

Like any good heist story, there are twists and turns, surprises, double agents, unexpected complications, and a delightful amount of verbal fencing. I adore the narrative tone Revis uses for these stories. Ada has just the right mix of idealism, cynicism, professionalism, and irreverence to carry off the feeling that she's a step ahead of everyone else. Underneath the bones of a delightful plot is a character who cares deeply but is very aware of her limitations, and therefore has taught herself to laugh at and be ruthless with her own emotions. I am finding it an incredibly compelling type of competence porn.

I enjoyed the first book of this series, but this one was so much better. These stories are exactly the right length to keep the reader engrossed throughout and satisfied but wanting more at the end. How to Steal a Galaxy ends on a cliffhanger of sorts, to be resolved in the next and final book. I can hardly wait to start it.

Highly recommended.

Followed by Last Chance to Save the World.

Rating: 9 out of 10

01 August, 2026 04:23AM

July 31, 2026

hackergotchi for Clint Adams

Clint Adams

N.K. Jemisin is doing a worldbuilding workshop at the Bronx Library Center tomorrow afternoon

Normally, I do not read book reviews. Either I haven't read the book, in which case there's spoiler potential, or I have, in which case it's unlikely to be useful or enjoyable for me to read a thing about a thing I've already read.

But Review: Radiant Star caught my eye, and I thought, “Hmm, I've read all those books” and was curious. Of course, because I am old and senile and have no understanding of time, the “May 2026” staring at me was not able to trigger the neural synapses that would remind me that I haven't read any Ann Leckie since 2023.

However, as I read Russ's review, and began to wonder what the hell he was talking about, I was able to piece together that while I have, in fact, read 6 Ann Leckie books, none of them have been Radiant Star.

This presented an opportunity, so I resolved to add Radiant Star to my todo list. To my surprise, it was already there.

Posted on 2026-07-31
Tags:

31 July, 2026 03:32PM

Russ Allbery

Review: Painting the Blues in Gretna Green

Review: Painting the Blues in Gretna Green, by Linzi Day

Series: Midlife Recorder #2
Publisher: Linzi Day
Copyright: November 2022
ISBN: 9798360228431
Format: Kindle
Pages: 577

Painting the Blues in Gretna Green is a self-published fantasy novel and the second in the Midlife Recorder series. It picks up immediately after the end of Midlife in Gretna Green. I also read it almost immediately after, so I didn't pay attention to how good the recap of previous events was.

As before, this is urban fantasy except not urban. Day calls it paranormal women's fantasy, which I suppose is as good of a genre label as any. The other book I can think of off-hand that would go into that genre would be Nancy Springer's Larque on the Wing, although it is considerably more literary.

I suspect I'm going to read this whole series and it's going to be impossible to review these books without talking about Niki's job, so I'm not going to treat that as a spoiler. It's fairly well-advertised in the marketing for the book, so that feels justified. If you're particularly averse to any spoilers, though, you may want to stop reading here until you've gotten to the reveal in the first book.

Niki is now officially the Recorder, with the power, advice book, and sentient house to go with it. She's about to face her first test in managing interworld politics: There's something amiss in the world of the Picts. Her allies are dropping hints, there's a petition from a group on the Pict world that she can't make sense of, and although she likes the queen of the Picts, there is a great deal of tension beneath the surface that she doesn't understand. Meanwhile, after the incompetent disaster that she uncovered in the first book, Niki is determined to pick her new staff by her own criteria.

The second book leans even harder into giving Niki both a tangled mess created by previous incompetence and enough power to fix it. Watching that happen is very satisfying, particularly when it involves surprising people who are rather too used to getting their own way.

I was somewhat less convinced that Niki is getting the right training to make the decisions that she's making. Diplomacy and staff management are real skills that one needs to learn, not just wing on vibes and gut instinct. My love of competence porn occasionally wishes that Niki had a bit more structure around her competence. We do at least get a new fictional self-help book on how to rule that contributes the quotes that open each chapter. Not the ethics and management training that I would have chosen, but it's something!

In defense of Niki's technique, it becomes clear in this book that the last few recorders have been far too cautious, conservative, and content with a status quo that involved a minimum of work. One of the delights of this book is that Niki thinks power exists to be used to fix things and is determined to use it, not just sit on it. I had more suspension of disbelief issues with this book than with the first — some of the problems Niki is solving seem far too obvious to have been in stasis for this long while also having this easy of a solution, and the level of political power given to the Recorder is a bit unbelievable — but it is so satisfying to see Niki cajole and bully people into being sensible.

I have no idea if this is intentional on Day's part, but I will not be at all surprised if adult-diagnosed ADHD comes up at some point in this series. The way that Niki's focus jumps, her tendency to veer between focusing on a problem and forgetting about it, and something about the way she switches between trains of thought or misses important context because she's jumping to conclusions is making me wonder. This, to be clear, is not a complaint; I think it makes Niki more relatable and more interesting. It's a good thing that she has a sentient house to serve as her assistant. The glee with which she's delegating any task that involves keeping track of details or following up with other people feels like a bit of an indicator by itself.

I did get a bit frustrated with the plot structure of this book. Niki keeps mentioning that a critical petition submitted to her office makes no sense, but it takes half of this (rather long) book before she finally explains to anyone else, even the reader, what's deficient about it. The excuse within the book is that she's having a rather busy day, but by the third time Niki mentions and then fails to do anything about the petition, I was wishing Day would stop bringing it up until she was ready for that part of the plot.

This, as with a few issues in the previous book, feels partly like an editing problem. There is something joyful in indulgent, sprawling books, but only up to the point where they become repetitive. Painting the Blues was right at that line, and once again I wish someone had helped Day trim about fifty pages out of it.

All that said, and despite having more quibbles with this book than the previous one, this continues to be great fun. It's satisfying wish-fulfillment about fixing long-standing problems and having the power to not have to put up with abusive nonsense and ridiculous bullshit, and I am so here for that. I hope Niki realizes she's eventually going to need more refined skills than a heart-to-heart over wine, but she's learning on the job and I'm happily along for the ride. She's also capable of recognizing skill in other people, and that goes a long way.

Recommended if you liked the first one and are in the mood for another fantasy of "no, we're not going to leave it that way, we're going to fix that right now."

Followed by Ties that Bond in Gretna Green.

Rating: 7 out of 10

31 July, 2026 03:06AM

hackergotchi for Jonathan McDowell

Jonathan McDowell

My CPU died

I built my current house server back in 2019. It had an upgrade from the original Ryzen 2700 to a 5700G in late 2021, but otherwise is still running with the original setup. Back in November it developed some erratic behaviour (initially manifesting as problems with the TPM, which is ironic as I’ve spent a bunch of time at my day job trying to improve TPM reliability), culminating in unreliable reboots. I had a limited amount of ability to swap parts out, but ultimately decided it was a motherboard issue (thinking perhaps VRM problems), found a replacement locally, and everything seemed fine.

Until May.

At that point I rebooted the machine for a Debian point release, and it failed to come back. Fans would spin, but there was no sign of actual life. I ended up pressing a temporary machine into service (that could at least run the Home Assistant container, and a few other critical bits) while I tried to work out what was wrong. I’d kept the previous motherboard, and still had the Ryzen 2700, so I did a bunch of swaps (and obtained a motherboard buzzer to try and get some indication about whether there were useful beep codes being emitted), and ultimately came to the conclusion that the CPU had died.

I’m not quite clear what happened here. I played it safe and replaced the PSU at the same time, in case that was the original cause back in November and ultimately damaged the CPU, but both old + new motherboards worked just fine with the 2700.

That left a decision about what to do. This previous server was from 2013, so this machine has now lasted longer than that and I could justifiably upgrade. However when I went to look at what the equivalent modern machine would be it’s only a couple of generations later (Zen 5 vs Zen 3), and 64GB RAM alone would have set me back ~ £1k. For not a lot of gain. So I ended up buying a replacement Ryzen 5700G, hopefully allowing me to put off thinking about an upgrade until Zen 6 is out, and RAM prices are saner (though I understand that might take a couple of years).

It’s not the first time I’ve had a faulty PSU be the cause of a dead machine, but it was a pretty frustrating experience.

31 July, 2026 12:28AM

hackergotchi for Otto Kekäläinen

Otto Kekäläinen

Estonia, the country of the fit and the wit

Featured image of post Estonia, the country of the fit and the wit

While many Western democracies seem to be in a state of decay and are no longer the safe, civilized and prosperous countries they once were, there are still some European countries that are governed well. One of those that stand out is Estonia.

Estonia is probably most well known for multiple software companies that originated from there, such as Wise, Bolt, Pipedrive and Skype. The government itself is also famous for being early in issuing government IDs with an embedded smart chip for online authentication already in the 1990s. Via the national portal at eesti.ee all residents can access extensive eServices ranging from viewing their health benefits to filing taxes.

Estonia has also been running an e-Residency program since 2014, where they issue digital ID cards to foreigners, making it easy for them to remotely log into the government portals and for example, establish businesses, file annual reports and so forth. Note that the e-Residency is not a path to physical residency. Estonia does, however, have a separate Digital Nomad visa program that makes it easy for non-EU citizens to also physically establish themselves in Estonia, assuming, of course, you meet the criteria, which includes, among others, a minimum monthly income of 3960 € from outside Estonia. EU citizens naturally have free mobility inside the EU and can simply get an apartment and register as a resident in Estonia if they so choose. And there are plenty of reasons to do so.

Estonians value health, education and entrepreneurship

I moved to Estonia about one and a half years ago. In my observations Estonia strikes me as a country that values health, education (in particular programming and natural sciences) and entrepreneurship highly.

I don’t know how Estonians achieve it, but they look pretty fit and rarely obese. Estonia has rye bread and sauna in their culture just like Finland, and in addition the flat terrain and well-planned bike routes and extensive network of parks (and pull-up bars everywhere) seem to create an environment where it is easy to live in a healthier way. The consumption of processed foods and candy also seems relatively low among Estonians.

The gym chain MyFitness also seems to be present everywhere. Even the Tallinn airport has a calisthenics workout station right at the departure gates, which anyone is free to use while waiting for their flight to take off. One of the top longevity influencers in Europe, Siim Land, is Estonian.

Estonia has lots of good bike paths, parks and outdoor gyms

There is even a calisthenics station with pull-up bar and more at the departure gates at Tallinn airport

Estonians also seem to value the school system highly. The government has been actively raising teacher pay and has a stated goal of reaching 120% of the national average by 2027. The students are also expected to value the education and respect their teachers. According to the TALIS 2024 survey (OECD’s international teacher survey), Estonian teachers spend significantly more time on actual teaching and learning and waste less time on interruptions or keeping classroom order compared to the OECD average. This is among the highest rates internationally, meaning they spend relatively little time on maintaining order or dealing with disruptions. While the international education benchmark PISA scores have been dropping globally, Estonia has consistently been climbing the ranks in past decades. In the latest PISA study (from 2022), Estonia ranked number one in Europe for reading, mathematics and science. In the overall results, Estonia ranked seventh globally, only behind countries such as Japan, Korea and Singapore.

Valuing entrepreneurship is evident in how the taxation system is set up in Estonia. Famously, in Estonia, companies can defer taxes on annual earnings and reinvest all of their profit in growing the company. Taxes are due only later, when paid out from the company, for example as dividends. For individuals, receiving dividends from any Estonian or foreign company is tax-free as long as the company paying dividends already paid corporate tax on the same income.

The tax system is also very simple. For all individuals, all types of income, including salary and capital gains, are always taxed at a flat rate of 22%. This removes the incentive for anyone to try to convert income into different types, setting up holding company structures and other optimizations as there is no gain. All entrepreneurs can simply focus on growing their business and forget extra bureaucracy. There is also no marginal tax rate cliff to stop working at – everyone is encouraged to always try to produce as much value as they can. A simple tax system is also reflected in the fact that anyone can easily read all tax rules that apply to individuals in plain English on the Estonian tax authority website, and one does not need to hire any accountants simply to file taxes.

Estonia also has a very straightforward investment account system: any person can freely open a self-directed investment account at any brokerage at no extra cost and report it as such to the tax authority, and then use it to save for an apartment, retirement, or other purposes, and defer all income taxes until withdrawal. There are no caps or time limits, and all residents are encouraged to save and invest as much as they can and thus take responsibility for their own wealth accumulation.

It seems that culturally Estonians respect people who are active and progress in their careers and businesses more than in other countries. Unlike in Finland, successful people are admired and living on government welfare is not romanticized. At the same time, the government benefits are less generous so people can’t live comfortably on them and, for example, many of the asylum seekers Estonia accepted have since left on their own initiative to other European countries in search of better benefits.

Low crime, high trust

Another thing that strikes me when walking the streets of Tallinn is that there are no drug addicts, beggars, thugs or the like. The difference compared to, for example, Vancouver (where I lived previously) is stark. In public buildings, people leave their coats and bags hanging in the lobby while visiting. Private houses and apartment block yards are not fenced. In my building, I noticed people even leave their bikes unlocked in the bike shed. I have also seen the staff of a coffee stall in a shopping mall going for a break and leaving everything unattended, not worrying that anyone would take anything while the staff is away.

Nobody is stealing anything from the unattended coffee shop while staff is having a break at Ülemiste shopping mall

This is not just my personal experience. According to the Numbeo crime index, Estonia has one of the lowest crime rates in the world. Also, comparing drug and property crime stats, for example, Finland has twice as much crime per capita, and places like Vancouver in Canada almost five times more.

I don’t have any clear explanation for why crime is so much lower in Estonia, but some suggest that higher social cohesion and lower levels of welfare contribute to people standing to lose more if they behave antisocially. Compared to Finland, Estonia also more readily jails repeat offenders, and those who are put on trial will experience a swifter court process thanks to simplified legal processes and more efficient governance.

Moving to Estonia: quick checklist

Moving to Estonia is very easy for any EU citizen, in particular if your work is not location-dependent (e.g., remote work or an online business) and you are simply looking for the cleanest and safest environment to live in.

First, check into a hotel in Tallinn, check out various neighborhoods to figure out what area you like (my favorites are Kalaranna, Kalamaja, Noblessner and Volta) and start browsing available apartments in English at kv.ee. Most professionals speak fluent English, so there should not be any difficulty in reaching out to people by email or phone.

Tallinn is famous for the old town

The economic boom of recent decades created a lot of new construction, with Kalaranna being among the newest areas

The next step is to buy a local prepaid SIM card at e.g., an R-Kiosk or a convenience store as signing up for other matters later on will require an Estonian phone number. Once you have an apartment and e.g., signed a rental agreement, you can register in the population registry online.

After that, you have proof you are a local resident with an address and telephone number in Estonia. With local resident status, you can go to the police station to get a local ID card. Don’t bother scheduling an appointment, just go to the Tammesaare police station in Tallinn, take a queue number and wait. Once it is your turn, they will guide you on how to use the photo booth, fingerprint registration device, and file your application. A few days later you will receive an email confirming whether your application was accepted, and after a few more days, you will get another email notifying you that your ID card has been printed and is available for pick-up at the same location. This will also be your first practical experience of how fast and efficient the government in Estonia is.

Once you have the local ID card, you can use the smart card feature to log into all the government eServices and sort out the rest of the relocation process, such as registering tax residency and getting a family doctor.

The main eServices portal in Estonia: eesti.ee

How did Estonia evolve to be like this?

After Estonia regained its independence after the fall of the Soviet Union in 1991, the first elected government in 1992 was led by a very progressive 31-year-old Prime Minister Mart Laar, who managed to set up some very good policies and laid the foundation of a society that has evolved well in the decades since. Estonia was very lucky to have people in power in the 1990s who didn’t simply copy what other Western countries were doing, but who tried to think about things from first principles and create Estonia’s own model for efficient and fair governance. As a post-Soviet country, the population had also been vaccinated against overly socialist and unrealistic ideals, and everyone had a healthy distrust of the government’s ability to solve problems and emphasis was placed on people’s liberty to work for themselves as they best see fit. The improvement in living standards over the past 35+ years has also been witnessed by the population, and voting behavior supports keeping the country on the same trajectory.

General living standards still continue to improve as the nominal wage growth sits at around 6%, clearly above the annual inflation rate of about 3%. In 2026, the Estonian economy is expected to grow about 2.4%, which is faster than the EU average. The growth in Estonia is not the result of any accounting tricks - Estonia is part of the euro and can’t print its own currency, nor has it been funding the public sector with excessive debt. With a 24% debt-to-GDP ratio, Estonia consistently ranks as one of the most responsibly managed countries among advanced Western economies.

As wages in Estonia soon catch up with the EU average, and higher defence spending has forced the government to raise taxes in recent years, the economic growth that Estonia has enjoyed for 35+ years since it exited the Soviet Union might slow down a bit in future years. The policies that fueled this growth in living standards, however, are likely to stay.

The tiger leap

There is one specific government policy in Estonia’s history that I think should be highlighted in particular. Estonia was very progressive by announcing the Tiigrihüpe (Tiger Leap) program in 1996 with the goal of equipping all schools with computers and teaching all students the basics of programming. This surely had a large influence on why Estonia has so many successful software companies, why the government eServices are so mature that even neighboring countries like Finland are striving to copy the Estonian government’s IT architecture called X-road.

The Tiigrihüpe project was originally suggested in the mid-1990s by Toomas Hendrik Ilves, then ambassador of Estonia to the United States, Canada and Mexico, and later President of Estonia in 2006–2016. While he was a psychologist by education, he was also a self-taught amateur programmer and used his political influence to promote sensible adoption of information technology in both Estonia and the EU.

The history of Estonia has several prominent figures who were not lawyers by profession but engineers, scientists and historians who were very practical in their political decisions, which I think is now reflected in how government processes were formed.

The video below shows how the Estonian government advertises itself and what values they choose to highlight:

Should other countries adopt policies from Estonia?

Of course, not everything is perfect in Estonia either. The fertility rate of 1.16 in Estonia is very low. This trend is present globally, but in Estonia it is way below the EU average. Also, the service culture is something that needs to improve in Estonia. While services are in general fast and efficient, the attitude of people working in cafes and stores does not reflect a willingness to fill in gaps if the standard process falls short, nor are visitors actively made to feel welcome as individual humans, but are treated as mere process inputs.

However, many of the things listed earlier I think should be studied by policymakers elsewhere. Societies are complex systems and there is of course no guarantee that copying a single policy to another country with different ethnicities, history and ingrained culture would lead to the same policy outcomes. But considering that Estonia is a small country without favorable geography and no natural resources, and that it started out from a place of total chaos, low economic activity and high crime in 1992 to rise to what it is now in 2026, the success it has seen is surely largely a result of good policies, governance and culture that other countries can and should mimic.

31 July, 2026 12:00AM

July 30, 2026

hackergotchi for Clint Adams

Clint Adams

not ninpo

The UX of jj's builtin merge editor finally became too much for me. So, I looked at the list of merge tool options, saw vimdiff, and thought, “Oh, cool, I know how to use vimdiff.” So, I launched jj config edit --user, added a ui section, and set merge-editor to vimdiff. With the new config, I ran jj resolve again. It was at that point that I realized that I do not, in fact, know how to use vimdiff: I only know how to use vimdiff with two buffers. What appeared in my terminal was a 4-pane monstrosity. Why are there four panes? I'm trying to resolve conflicts between only two changes on only one file. For a moment, I nearly go down a rabbit hole, because this says that by default, vimdiff is “barely useable” [sic]. Should I be installing some addon or a Python script? Apparently there are tradeoffs. I just want to resolve these conflicts without doing line-by-line approvals for how ever many hours that would take.

Accordingly, I ran away in terror, installed meld, set merge-editor to meld, and went clicky-clicky in the GUI. I'm not happy using a GUI, but at least it didn't have a mysterious extra buffer to confuse and taunt me.

Posted on 2026-07-30
Tags:

30 July, 2026 12:12PM

Russ Allbery

Review: In the House of Aryaman, a Lonely Signal Burns

Review: In the House of Aryaman, a Lonely Signal Burns, by Elizabeth Bear

Series: Sub-Inspector Ferron Mysteries #1
Publisher: Sobbing Squonk Press
Copyright: 2012
Printing: 2018
ISBN: 0-9863735-1-6
Format: Kindle
Pages: 73

In the House of Aryaman, a Lonely Signal Burns is a science fiction police procedural set in relatively near-future India. This novella was originally published in Asimov's SF and collected in several anthologies as well as Bear's Shuggoths in Bloom collection, which I have on my shelf but have not yet read. I probably should have checked that before I got another copy. It is the first story of a series in the sense that there is an Audible-only sequel available.

Like many police procedurals, this one opens with a crime scene. Sub-Inspector Ferron and her partner are inspecting a tube of human meat in the middle of the rug of a luxurious apartment in Bengaluru. The tube is apparently the remains of one Dexter Coffin, an American with a high tech workspace who was apparently mangled beyond recognition in his locked apartment near a table set for two.

Dexter's cat is a witness. In this future world of cats enhanced with limited language skills, this would have been very useful, but the cat's memory was apparently wiped. Ferron will have to get to the bottom of the mystery some other way. Also, she apparently now has a new cat.

Meanwhile, Ferron is worrying about her partner's mental health, her partner is worrying about her use of stimulants to stay on duty for this murder investigation, and Ferron's mother is harassing her for money to pay the bills of her virtual reality addiction. Her job is a good distraction from other problems she'd rather not deal with.

I am trying to come up with something insightful to say about this story, and I'm not having much success. It's a police procedural with a bit of a science fiction twist. The characters are fine but not, at least for me, particularly engaging. There is some deft world-building, but nothing that grabbed my attention or made me desperate to read more stories in this world.

Perhaps the most interesting part of the background, and the reason why I picked up this novella, is that this is the universe that eventually becomes the setting of the White Space series. There is an early version of right-minding handled entirely through medicine without the later invention of the fox implant, and there are some signs that humanity is slowly digging itself out of the hole of climate change and antisocial behavior that it had dug. I found this mildly interesting, but it doesn't add much to the later series and is very skippable.

The source of the title is a bright light originating in the Andromeda galaxy, which is contained in Uttara Bhādrapadā in Vedic astrology. Ferron says this is under the influence of the god Aryaman. This is unrelated to the plot; it's just a background event that prompts some introspective musing from Ferron at the end of the story. It's a nice moment, but I would have been more interested in the full story of first contact between Earth and the Synarche.

This was a mildly pleasant way to spend a few hours and I'm already forgetting all of the details. It's a competent story, but not one I feel a need to recommend to others.

Followed by A Blessing of Unicorns, which appears to be an Audible audiobook exclusive.

Rating: 6 out of 10

30 July, 2026 03:25AM

Reproducible Builds (diffoscope)

diffoscope 326 released

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

[ Vagrant Cascadian ]
* Add external tool reference for "pedump" to use the "mono" package on
  GNU guix.

You find out more by visiting the project homepage.

30 July, 2026 12:00AM

July 29, 2026

hackergotchi for Joey Hess

Joey Hess

my harddrive is probably not full

I enjoyed reading this post by Marginalia "Your harddrive is probably full"

You can construct an entropic argument that there are simply more ways for a harddrive to be full than ways in which it can be empty.

Of course it made me check how full my laptop drive is, and indeed it was more than 75% full, as predicted.

But, I almost never feel that my hard drive is full. I can very easily free up almost any amount of disk space at any time, without any thought. While writing this blog post, I ran a single command and now my harddrive is 50% empty.

The other part of the equation is that a full disk isn’t a problem until it’s so full you can’t put more stuff on it, and at the point it’s so irredeemably cluttered that when you do clean it up, you only have the patience to clean up enough to bide your time, judging the fate of every file on the harddrive is simply too much work.

Why doesn't this apply to me? Because I have put in the up-front thought to organize things, so that I never have to do that anymore.

I have 3 categories of files that I can remove at any time I need more space, without any thought:

  1. Any files that are stored in git-annex. This is one of git-annex's superpowers; you can git-annex drop any file and stop it using disk space, but the file is still there (as a broken symlink) so you don't risk losing or forgetting about it.
  2. Caches.
  3. Files in ~/tmp/, which is reserved for any files I only want to have a passing acquaintance with. If I'm not comfortable with something being deleted at any time, I don't put it there.

Not only do I only have these 3 categories, these are the only 3 categories for everything except OS files and files I have decided I never want to remove (eg dotfiles and other files stored in git repos).

Computer scientists invented caches (and of course cache invalidation is no problem lol) so I only needed to learn about that one. Unix gave me /tmp/ as an example that I long ago used as the basis for the rules for my ~/tmp/. I hope that git-annex might also serve as an example that moving files between drives is not the best way to manage disk space use.

29 July, 2026 05:25PM

Russ Allbery

Review: Midlife in Gretna Green

Review: Midlife in Gretna Green, by Linzi Day

Series: Midlife Recorder #1
Publisher: Linzi Day
Copyright: July 2022
ISBN: 9798837010774
Format: Kindle
Pages: 464

Midlife in Gretna Green is a self-published fantasy novel. It's urban fantasy in the sense that it's set in our world but with magic that most people don't know about, but the primary setting is a parish in rural Scotland and therefore the genre is not urban in that sense. It was Linzi Day's published first novel.

As the story opens, Niki McKnight is a widow in Manchester, England with a job in the Register Office she likes, a boss she hates, and a Bichon Frise dog she adores. In the year since her husband Nick died, she's put her life on hold and made as few decisions as possible, despite some concerned pushing from her best friend Aysha. The death of her grandmother is not entirely unexpected, but her inheritance is about to upend her life.

Niki assumes that her grandmother has a modest cottage and a small estate, and therefore being the named heir will mostly involve cleaning up the details of a modest life. She is caught by surprise by a requirement in the will that she live in Gretna Green for a year and a day in order to inherit. Her initial reaction is to treat this as an absurd impossibility given her life and job in Manchester, but she slowly realizes something strange is going on. Her grandmother's lawyer is lying to her, he refuses to tell her the value of the estate and seems to think it's more valuable than she expected, and her grandmother's tiny cottage does not seem to be following the seasons of the rest of the world. There is something magical at work.

I will not spoil the rest of the reveal. I will say that this is a magical house book because, if you are anything like me, that is why you will want to read this series. There are not enough magical house books, and this is one of the better kind that allow the house to be a full speaking character.

Midlife in Gretna Green is an unapologetic fantasy of personal agency. Niki starts the novel with a miserable manager, a messy pile of unread mail she doesn't want to deal with, and a lot of personal emotional baggage. She gets handed a position that requires and rewards standing up for herself and being decisive. It comes with a pile of unresolved but not horribly complex problems that were waiting for someone who would listen, make sensible decisions, and treat other people with respect. Oh, and there are a few assholes in the way, but they seriously underestimate the power she has to put a stop to their bullshit.

This is the sort of book that traditional publishers tended not to buy (although Day apparently did get an offer for this one and turned it down), and I'm not sure why. Editors thought protagonists should have to work harder for their payoff? Some lingering Calvinist dourness in English language publishing mistrusted triumphant books? Obvious wish fulfillment was considered embarrassing or low-class and thus didn't warrant publication? This didn't apply to the endless bildungsromans about magically talented boys, so some level of sexism was probably in play. Maybe this is finally changing? It reminds me of the bias against romance novels and their guaranteed happily ever after, and in the case of romance there was too much money for publishers to leave it on the table.

In any case, the growth of self-publishing has created an alternative market that let these books reach an audience and I for one am here for it. A lot of wish-fulfillment books, and a lot of self-published books, are not very good, but the ones that have a spark of originality and character can be a delight worth tolerating the somewhat rocky editing and pacing problems that a full editorial staff might have cleaned up.

I loved reading books about kickass women who took no crap and fixed their lives up exactly how they wanted them to be. But how did they get to be that way? They always started out awesome in the books. Seriously, did they kick ass at sixteen? Or did their superpower kickassery not kick in until they were thirty? Forty? If so, then I was screwed. Would I need to wait till I was fifty or until a genie arrived offering wishes? I already felt as if I’d spent my whole life waiting for something wild and wonderful to happen.

Niki is a Specific Type to a somewhat hilarious degree, and I'm not sure if Day is playing into that intentionally or if she's projecting herself into the book. The amount of self-insertion is not zero: Day also lives in Gretna Green, owns a Bichon Frise, and worked as an assistant registrar and civil celebrant. Niki also drinks wine regularly, has a psychic gift, occasionally reads tarot cards, is an accommodating pushover at work who struggles to say no to her abusive boss, has impostor syndrome problems, and swears by a fictional self-help book about grief that provides the quotes at the starts of chapters. There is a cat, because of course there's a cat.

(The fictional self-help book is a spot-on parody played entirely straight in the story. I think Day is having some fun with the reader? I can't tell!)

This is what I mean by unapologetic. It's easy to read Niki as a stereotype, but she's a stereotype a lot of real people can identify with and there's something highly satisfying in watching her find her footing. I like wish fulfillment books; it's fun to see someone's wishes come true! Particularly in the year of 2026, there's something immensely satisfying in seeing an ordinary, insecure person get a massive amount of power and use it to make the world better. I don't need everything to be hard, fraught, and laden with costs in fiction, although I wouldn't want every book I read to be like this.

Also, the world building is great. It's not polished; there's a bit of a grab bag feeling to it, I'm dubious the magic system has any underlying rigorous rule set, and Niki's powers, once she has access to them, are more of a semi-sentient genie than a skill she has to learn with hard practice. But the magic is fun. The sentient house is one of the best characters, particularly after Niki realizes how underused it has been, and I am a sucker for any good sentient house book. The cat is a far more interesting character than I first thought she would be. And Niki's new magical job is more complicated and less typical than the normal Celtic-inspired fantasy that I thought it was going to be at first.

My primary warning about this book is that Niki starts out beaten down and grieving her dead husband, and it took me about five pages to decide that her dead husband was a complete piece of shit who was not worth any of the grief Niki puts into him. She also doesn't stand up for herself for the first hundred pages or so, which made me want to yell at the book a few times. Both of these problems go away farther into the book, and Niki does eventually figure out that Nick was abusive trash, but I was relieved when the "make endless excuses for worthless men" portion of the story was finally over. You have to stick with it until Niki gets brave enough to try being the protagonist; once that happens, it becomes great fun.

It is fairly obvious that Midlife in Gretna Green was self-published, and I wish it had gotten the editing that it deserved. My copy had a couple of obvious formatting errors, the plot veers about more than was strictly necessary, and I think a careful editing pass could have tightened the writing by about fifty pages or so without losing any important detail. If that sort of thing bothers you, make sure you're in self-published fiction mode before starting this one. But it also has that irrepressible, bubbling-with-ideas feeling of a book where nothing has suppressed the author's enthusiasm. It's a very grabby book; once Niki starts embracing her new life, I could barely put it down.

If you're in the mood for a good fantasy wish-fulfillment story that has no romance and a whole lot of "why are things run this way, no, we're changing that," highly recommended. I had so much fun with this book, and the series is currently making the rounds of my whole family. Don't read this when you're looking for something challenging and literary and deep; save it for when you desperately want to watch someone just fix something for once, damn it.

Followed by Painting the Blues in Gretna Green, which I have already read, breaking my usual rule of writing reviews before reading the next book in a series.

Rating: 8 out of 10

29 July, 2026 02:19AM

July 28, 2026

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

RcppDate 0.0.7: New Upstream

RcppDate ships the featureful date library written by Howard Hinnant to enable use from R packages. This header-only modern C++ library has been in pretty wide-spread use for a while now, and adds to C++11, C++14 and C++17 what is (with minor modifications) the ‘date’ library in C++20. The RcppDate package adds no extra R or C++ code and can therefore be a zero-cost dependency for any other project; yet a number of other projects decided to re-vendor it resulting in less-efficient duplication. Oh well. C’est la vie.

This release syncs with upstream release 3.0.5 made yesterday. We also made two routine updates to the continuous integration since the last release a good year ago. The Debian and r2u packages for this new release have already been uploaded too.

Changes in version 0.0.7 (2026-07-27)

  • Updated to upstream version 3.0.5

  • Regular updates to continuous integration setup

Courtesy of my CRANberries, there is also a diffstat report for the most recent release. More information is available at the repository or the package 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.

28 July, 2026 01:32PM

July 27, 2026

#057: Conditionally Quieten Compilers

Welcome to post 57 in the R4 series.

R packages with compiled codes can use the file src/Makevars to set compilation flags. We often rely on this to set libraries, include directories or compilation options. When using external libraries, be it header-only or via headers and linking, we are often experiencing ‘compilation noise’ when these libraries tickle warnings under generally-recommended flags such as -Wall -pedantic. Two packages I maintain are clearly repeat offenders here: Eigen, and BH. Both cam generate pages and pages of compiler output. This is generally not great as it may hide genuine warnings from our own code.

What makes matters worse is that some of the available and specific options for the compilers are treated by R CMD check as ‘non-portable’ leading to a nag on package checking. Examples are -Wno-parentheses, -Wno-maybe-uninitialize or -Wno-nunnull.

I have long resorted to adding these to my per-user ~/.R/Makevars. When added there, compilation is quieter, but R CMD check still nags here where the option is set but not at CRAN or r-universe. A situation that is not ideal but what somewhat ‘stable’.

More recently, I realized there was an available check we can use to conditionally add extra compilation flags but leave them off by default. That makes local development quiet allowing us to focus on the quality of our additions here without noise from third-party libraries we may use. At the same time we do not need to do anything else to let CRAN do its work.

The check we now use is whether there is a .git/ directory present. If so, we are indeed building from local sources and can add extra flags. If not, we are likely building from a tar.gz source archive—which is the case for CRAN—and hence do not set these.

An example use is this recent additional to package qlcal where this bit of R code is invoked from a minimal shell script configure and replaces the stub @XTRAFLAGS@ in src/Makevars.in (or src/Makevars.win.in)

if (dir.exists(".git")) {
    ## development from a .git directory can use these flags
    xtraflags <- "-Wno-nonnull -Wno-deprecated-declarations"
} else {
    ## else build from tarball so stick with existing flags
    xtraflags <- ""
}
win <- if (Sys.info()[["sysname"]] == "Windows") ".win" else ""
infile <- file.path("src", paste0("Makevars", win, ".in"))
outfile <- file.path("src", paste0("Makevars", win))
lines <- readLines(infile)
lines <- gsub("@XTRAFLAGS@", xtraflags, lines)
writeLines(lines, outfile)

With this change, local compilation is quiet, yet CRAN has nothing to nag about (as seen at the qlcal results page).

Similarly, one can also check from an actual configure file written in autoconf. Here is a similar example from RcppEigen (showing some relevants parts of the whole file)

# PKG_CXXFLAGS initialized earlier ...

## Check if building locally
AC_MSG_CHECKING([whether .git/ exists])
if test -d "$srcdir/.git"; then
    AC_MSG_RESULT([yes, adding extra flags])
    AC_SUBST([PKG_CXXFLAGS],["${PKG_CXXFLAGS} -Wno-ignored-attributes -Wno-maybe-uninitialized"])
else
    AC_MSG_RESULT([no, consider adding '-Wno-ignored-attributes -Wno-maybe-uninitialized' to ~/.R/Makevars])
fi

AC_SUBST([PKG_CXXFLAGS], ["${PKG_CXXFLAGS}"])
AC_CONFIG_FILES([src/Makevars])
AC_OUTPUT

Once again, with this change compilation is quiet locally, yet unaffected at CRAN. Just what we want. Give it a try in your packages.

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

27 July, 2026 10:40PM

hackergotchi for Jonathan Carter

Jonathan Carter

DebConf26 – Santa Fe, Argentina

TL;DR: What a great DebConf! I managed to recharge my Debian batteries, and my talks / BoF sessions all went fine. Already looking forward to DebConf in Japan next year!

DebCamp

The evening before DebCamp started, we had a nice bbq (we taught some locals to call it a “braai” at an organiser’s house and went for a walk around the river as the sun set. It was a very peaceful lead-in to DebCamp.

  • I set up and sent out the call for Forky desktop artwork:
  • Had many nice discussions about various Debian topics with all the Debian people around. It’s really fun being around people who are natural problem solvers who care deeply about both technical and social issues. At one point Jonas told me “Holy shit, these people are motivated!” and I appreciate that so much too!

Debian LTS wine

  • Most of my DebCamp was dedicated to preparing for my demo and main talk that followed at DebConf.
  • Sadly, we had no loopy this year, I just didn’t have the time, and the people who stepped up to help last year were either overwhelmed with other issues or couldn’t make it. I’ll try to make it happen again for next year by kicking it off long before DC27.

View of Santa Fe city from hotel

DebConf

Talk – Is it even possible to build a truly universal system installer?

In this talk I do a very quick comparison of system installers based on my experience with them. It’s hard to directly compare all of them, since there are so many, and each have their own niche that they attempt to satisfy.

I also introduce Yasi – my attempt to answer the question of whether we could build a universal installer, which can also better cover advanced installations, automated installations and niche setups.

It’s very early days for the project, and I didn’t quite feel ready to share the code with the world, but it was nice that I did a quick demo where I could install a Debian system… and the resulting system actually booted up. *phew*.

This is also going to be my main focus for the mid-term future. I aim to have all the basic partitioning options working by the time Debian 14 (Forky) is released, and by the time Debian 15 is released, I have a long list of features that I aim to have working. So, my timeline for having something that’s generally useful is around a year from now, and in around 3 years it should be a fully fledged installer that should cover a very large amount of Debian use cases and architectures.

Day Trip

For the day trip, we did a tour across Santa Fe, visited Constitución de la Nación Argentina, had lunch where we tried various dishes based on local fish from the river, and then went on a boat ride on the river.

BoF Sessions:

Funding in Free Software Projects: I initially registered this BoF because I’m increasingly concerned about how upstreams are asking for donations in their software. I increased the scope to talk about funding in free software in general. It followed Marga’s talk about funding, which focussed more about how developers are funded in general. We didn’t dive very deep into this, but we certainly need some further discussion (and action) on this within Debian.

Debian Social Team: My most important issue for this team is a carry-over from last year, I want to set up barman (packaged in Debian) for live postgres syncing for our larger databases. For the smaller DBs, doing a daily dump is quite cheap. But for Matrix, it’s very expensive in terms if i/o and CPU, so it would be ideal to do less regular complete dumps and use live replication for the first line of redundancy instead.

Images Team: I wasn’t initially planning to say much during this session, I have some ideas to reduce both size and count of images, without losing any benefits, but I don’t have any work to show for that yet. I ended up talking a lot more than I anticipated, the topics covered were quite good and representative of the current state of Debian images built. I don’t have time to create a full summary, so I suggest checking the etherpad / video recording if you’re interested.

Some more wine variety during the conference dinner

Debianites in the main hacklab

Rosario

I’m spending two days in Rosario before I head home. Exploring a bit, catching up with sleep, finishing this blog post, signing keys and exploring some ideas I made note of during DebConf.

Thank you to the DebConf26 Team!

It was a little surreal not being part of any DebConf team for the first time ever, I’ve just been too focussed on getting Yasi ready for my talk (no regrets!). I hope to be more involved again next year, in the meantime, I’m very grateful to everyone who has made this happen, you did a stellar job! I hope to see many of you again next year in Japan!

27 July, 2026 08:12PM by jonathan

Valhalla's Things

Late Victorian Vampire Shirt

Posted on July 27, 2026
Tags: madeof:atoms, craft:sewing, FreeSoftWear

A woman wearing an old-style white shirt with lots of fullness, wide and long sleeves and ruffles at the collar that spread out framing the neck, down the center front to underbust height, covering the slit and at the cuffs, reaching to mid-hand. The shirt is gathered at the waist with a belt, and worn over the bottom garment to show that it reaches to mid tight. Drama levels in the pose are pretty low.

The recurring joke is that because of some health issues, in summer I dress like a Victorian Vampire.

But how would an actual Late Victorian Vampire dress? Picture her, she would look like some kind of eccentric gentlewoman, as vampires usually do, probably with a style that is a bit conservative, rather than following the latest fashions.

Same woman, same shirt, posing as a vampire ready to attack a victim. Drama levels increasing.

Now, she wouldn’t probably wear men’s shirts. But what if she was a lesbian1 vampire? Wouldn’t she need a fancy, frilly shirt to go with her tailored cycling suit when she’s out seducing the more active ladies in the neighbourhood?

Or maybe not. It’s not making a lot of sense, is it? But I do have a lot of shirt fabric in my stash2, and I could use a few more shirts that were practical and comfortable, but also somewhat over the top.

For the practical and comfortable I went to my trusted 1880s shirt, while for the over the top part I looked at inspiration from the earlier 18th century frilly shirts, and their later imitations.

I decided to use some nice cotton batiste I had bought quite a few years ago to make one of my first historically inspired shirtwaists: I may have a tendency to buy a bit more fabric than actually needed by the pattern, but that’s what everybody does, right?

For the ruffles I decided to use a lighter weight cotton voile, also from the stash.

the top edge of a ruffle being whipstitched over some gathered fabric; the rest of the unfinished shirt is visible in the background.

At the front, I wanted the ruffle to be inserted in the yoke, but I was also whipstitching the gathers to it to make them neater, so I started bu attaching the yoke lining to the gathered front, then I whipstitched the ruffle to the front, catching each gather, and finally I whipstitched the other yoke on the ruffle and the rest of the gathered front.

The front of a shirt: the body was gathered into a yoke, but it has been unpicked and pulled out to extend a bit past the end of it, into where the collar will be sewn.

And then after sewing the collar, I realized that this way the slit would have remained open in the front (or the collar too narrow), so I had to unpick the front part of the yoke, and sew it again, this time leaving an excess of fabric as wide as half the placket width from the pattern, to be sewn directly in the collar band.

From then, things progressed smoothly, with some interruptions, until I got to the first sleeve, which I failed to insert twice, as one does.

The same shirt worn without the ruffle at the collar, with just what looks like a mandarin collar, closed with a clip with an amethyst. Drama levels have gone way down.

On the third attempt, with a different method, I succeeded, I tried the shirt on, and it already felt extra.

Close up of the collar on a table: at the center back of the shirt collar there is a buttonhole, and a double button is used to keep the detached collar in place, while at the front both the shirt collar and the detached collar have buttonholes.

But it could be even more extra. With some ruffles also at the collar.

Same close up, but now the collar has been closed with a clip-on earring with an amethyst and some small fake clear stones, and it looks as if the skirt had a ruffle collar and a jewel button (or a pin).

The shirt had been made with a simple collar band, and I could have just added the ruffle to it, but I also wanted to be able to wear it with other detachable collars, so I decided to make another collar band with ruffles, to wear on top.

And that was mostly it, except for the reinforcement patches at the side seams and cuffs: I love having them, because they make the seam end neater and stronger, but they are a bit of a hassle to make, so they got postponed a few days.

Same woman and shirt, back with the ruffled collar, in a pose like that of an artist that is fainting for futile reasons. Drama levels over the top.

But finally, the shirt was done.

And I tried it on, and it was good.

But now I really need a pair of cycling breeches, don’t I?

  1. ok, maybe straight passing bi? anyway.↩︎

  2. I have no idea how they got there.↩︎

27 July, 2026 12:00AM

July 25, 2026

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

RcppArmadillo 15.4.2-1 on CRAN: Small Upstream Fixes

armadillo image

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) 1293 other packages on CRAN, downloaded 47.8 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 710 times according to Google Scholar.

This versions updates to the 15.4.2 upstream Armadillo release made this week, as well as to included 15.4.1 version we released only to GitHub and r-universe so do not exceed the (roughly) monthly cadence. For this release, we had run the usual complete reverse-dependency check which came back spotless, and did CRAN so no email exchange needed despite nearly 1300 reverse dependencies. Automation can be helpful when used with a well-maintained software stack. The package has also already been updated for Debian, built for r2u, and will build shortly at CRAN for the different binary releases.

All changes since the last CRAN release follow.

Changes in RcppArmadillo version 15.4.2-1 (2026-07-25)

  • Upgraded to Armadillo release 15.4.2 (Medium Roast Agave)

    • Fix speed regressions in diagvec() and diagmat()

Changes in RcppArmadillo version 15.4.1-1 [github-only] (2026-07-09)

  • Upgraded to Armadillo release 15.4.1 (Medium Roast Agave)

    • Fix for rare infinite recursion bug in sparse version of diagmat()

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

25 July, 2026 08:56PM

July 24, 2026

hackergotchi for Emmanuel Kasper

Emmanuel Kasper

Opensource gaming with nouveau nvidia driver

So it will not play cyberpunk 2077, but if you prefer opensource drivers for your hardware, nouveau is certainly an option for some opensource gaming.

Using kernel 7.0 from debian backports, I could run opensource classics requiring 3D acceleration flawlessly with nouveau:

I would like to highlight here how good is LibreQuake.
It is an horror cosmic 3D shooter, using the Quake engine, but with newly made game assets under the GPL, thus creating a 100% opensource Quake-based first person shooter. Although their documentation mentions it is a work in progress, as of 2026 I find it very much of a finished product.

LibreQuake Screenshot

Dismal shores, my preferred game level.

I missed Quake in the 90s, happy to discover such a classic today.

24 July, 2026 03:31PM by Manu

July 22, 2026

hackergotchi for Freexian Collaborators

Freexian Collaborators

Monthly report about Debian Long Term Support, June 2026 (by Thorsten Alteholz)

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

Activity summary

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

The team released 48 DLAs fixing 231 CVEs.

Debian 12 (“bookworm”) has been handed over to the LTS Team on June 11th. During this handover Sylvain helped to update relevant tools and documentation. 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:

  • haveged update (DLA-4616-1), prepared by Thorsten, to address local privilege escalation.
  • tomcat9 update (DLA-4619-1), prepared by Markus, to address, among others, an authentication bypass.
  • apache2 update (DLA-4620-1), prepared by Bastien, to address a HTTP/2 bomb.
  • apache2 update (DLA-4629-1), prepared by Bastien, to address, among others, remote code execution and privilege escalation.
  • libinput update (DLA-4626-1), prepared by Santiago, to address local privilege escalation and arbitrary code execution.
  • asterisk update (DLA-4631-1), prepared by Thorsten, to address, among others, wrong processing of invalid or untrusted certificates.
  • nginx update (DLA-4634-1), prepared by Charles, to address a remote code execution and denial of service.
  • firefox-esr update (DLA-4635-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution and privilege escalation.
  • thunderbird update (DLA-4636-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution.
  • chromium update (DLA-4654-1), prepared by Emilio, to address dozens of CVEs, among other things, related to arbitrary code execution.

Contributions from outside the LTS Team:

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

  • Salvatore Bonaccorso prepared a libhttp-daemon-perl update, that was released by Santiago as DLA-4639-1.
  • Salvatore also directly uploaded libgd-perl DLA-4638-1 and libconfig-inifiles-perl DLA-4637-1.
  • Peter Palfrader prepared a tor update, that was released by Santiago as DLA-4656-1.
  • Pieter Lenaerts prepared a beets update, that was released by Emmanuel as DLA-4641-1.
  • Noah Meyerhans prepared a cloud-init update DLA-4645-1.

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

  • Besides publishing DLA-4642-1 for package u-boot Andreas also prepared an NMU for an upload to sid and prepared a stable-proposed-update (SPU) bug for trixie, which was already acknowledged by a stable release manager (SRM).
  • Andreas also prepared an upload of package atril for trixie, which was handled by the security team as DSA-6349-1.
  • Besides publishing DLA-4620-1 for package apache Bastien also prepared an upload for trixie, which was handled by the security team as DSA-6323-1.
  • Tobi uploaded package mesa to trixie and bookworm.
  • Thorsten fixed some (not security related but RC) issues in package dahdi-linux. This was in preparation to fix lots of security issues in asterisk. Unfortunately the maintainer ignored the corresponding debdiff and prefered to upload a new upstream version. Anyway, the concerns of the security team about security support of asterisk could be overcome and asterisk can migrate to tesing and again be part of a Debian release.

Individual Debian LTS contributor reports

Thanks to our sponsors

Sponsors that joined recently are in bold.

22 July, 2026 12:00AM by Thorsten Alteholz

July 21, 2026

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

qlcal 0.1.3 on CRAN: Micro Bugfix, Build Tweak

The twenty-first release of the qlcal package arrivied at CRAN just now, and has been built for r2u. It comes a week after the 0.1.2 release.

qlcal delivers the calendaring parts of QuantLib. It is provided (for the R package) as a set of included files, so the package is self-contained and does not depend on an external QuantLib library (which can be demanding to build). qlcal covers over seventy country / market calendars and can compute holiday lists, its complement (i.e. business day lists) and much more. Examples are in the README at the repository, the package page, and course at the CRAN package page.

This releases includes a one-line fix we also sent upstream as a now-merged PR: one of the calendar files added in QuantLib 1.43 also needed to include the vector header file. And every compiler appears to be lenient (QuantLib itself has fourty different continuous integration jobs, we test with all builds at r-universe) apart from the CRAN macOS x86-64 machine. Sigh. This is now fixed. We also included a neat little local trick I should blog about: if the build is detected as a non-CRAN local build (simply by checking for a .git directory) then compiler flags can be updated to quieten the build. We cannot do that in the package because we would get our fingers slapped over so-called ‘non-portable compiler flags’. Sigh again. Anyway, the trick helps.

The full details from NEWS.Rd follow.

Changes in version 0.1.3 (2026-07-21)

  • Add missing 'vector' header to new IslamicHolidays calendar file, also PRed upstream and merged there

  • In local compilation out of git repo add additional compiler flags

Courtesy of my CRANberries, there is a diffstat report for this release. See the project page and package documentation for more details, and more examples.

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.

21 July, 2026 01:18PM

hackergotchi for Vasudev Kamath

Vasudev Kamath

Releasing debvulns-exporter: Prometheus exporter for Debian System Vulnerabilities

Following up on my previous post, I am releasing debvulns-exporter, a Prometheus exporter for tracking Debian system vulnerabilities. The underlying vulnerability analysis logic remains identical to the previously released MCP server and CLI utility.

Why an Exporter?

In my engineering workflows, I frequently deal with Debian and vulnerability management. Most enterprise environments rely on commercial, paid vulnerability platforms like Tenable or Rapid7. While these platforms provide extensive feature sets, I noticed a distinct lack of open-source tools tailored for this specific pipeline. While debsecan exists, it lacks a structured, parseable format suitable for building dashboards aimed at management consumption. What started as an experimental MCP server for learning purposes evolved into a practical question: why not convert it into a Prometheus exporter? Given that Prometheus is the de facto standard metrics platform across the industry, this architecture was the logical next step.

Design and Exported Metrics

The exporter is implemented as a native Prometheus exporter utilizing the prometheus-client library. It operates using two threads: one handles fetching the vulnerability data, parsing EPSS feeds, and cross-referencing installed packages to identify local vulnerabilities; the second handles serving the metrics endpoint. The full architecture details and metrics specifications can be found in the design doc. The specification was drafted during a technical brainstorming session with Claude 4.6 Sonnet on Antigravity prior to writing the implementation.

Testing and Dashboarding

To validate the exporter, I spun up older Debian 11 and Debian 12 cloud images sourced from the Debian Cloud team. The older image was intentionally selected to guarantee a standard baseline of unpatched vulnerabilities for testing. The local evaluation topology is structured as shown below:

Rather than constructing the Grafana dashboard from scratch, I used Claude 4.6 Sonnet via Antigravity to generate the layout configuration. The generated dashboard for the local testbed functions effectively:

The complete, ready-to-import Grafana dashboard configuration is included directly in the debvulns source code.

Renaming the project

To prevent namespace conflicts and confusion with the native debsecan utility in Debian, I have unified the ecosystem under the debvulns moniker. The core CLI is named debvulns, the exporter is debvulns-exporter, and the MCP component is debvulns-mcp. The migration release has been published to PyPI, and the new consolidated repository is active at debvulns.

Conclusion

While this began as a personal utility to fill a niche tool gap, I expect it will be useful for others managing Debian infrastructure at scale. My next objective is to formalize Debian packaging for both the CLI and the exporter. The MCP component will likely remain available as an independent artifact. Until then, happy hacking.

Note: As a core design choice, `debvulns` still uses native `debsecan` as its ground-truth standard. The tool continuously cross-verifies its output against `debsecan` to ensure perfect functional parity and data consistency.

21 July, 2026 11:25AM by copyninja

July 20, 2026

hackergotchi for Jonathan Dowland

Jonathan Dowland

Interzone digital

(no, this isn't a blog post about Joy Division songs)

Last time I wrote about Interzone, I was discussing issue #294, the first published under new management in a paperback-sized format ("JB6"). The format and presentation of the magazine was fantastic: it fit in a lot of my pockets, and was packed with 15 stories as well as the regular columns, in full colour with fantastic layouts and illustrations. Sadly there was only one more physical issue before Interzone was forced to become a digital-only publication.

IZ issues 294 and 295

IZ issues 294 and 295

I don't want to dwell on the sad necessity to move to digital. Interzone continues on, celebrating the milestone issue #300 in 2024. Subscriptions are managed via Patreon. Issue #305 just came out.

Instead I wanted to write a small bit about how I engaged with the paper magazine, and the difficulties I've had trying to engage with not just Interzone but any magazine-style publication in a digital context.

With most fiction, I read linearly: start the beginning and read to the end, in order. That works well for me with e-readers. But for magazines (and most non-fiction) I don't, I jump around: usually starting with the table of contents, I might pick a short column to start, or jump into the middle of the "book reviews" section to read about a specific book. I might skip sections entirely. I find it very difficult to read like this with an e-reader. I think this is partly because I reference the depth of the paper book or magazine, its thickness, to orient myself. But it's also partly the limitations of e-ink.

My tick-list for an issue of IZ

My tick-list for an issue of IZ

For print-Interzone, I used to start by inserting a small piece of paper inside the cover (the delivery slip was ideal). On this I listed the stories within and ticked them off when I read them (sometimes I double-ticked if I really liked a story). That helped me to remember, perhaps months or years later, whether I'd read all the stories or not, and which I liked. I could do something similar on some e-readers: the Remarkable for instance. But it's far from convenient to do on most e-ink devices.

Interzone digital is available as both ePUB, the most common format for e-books, and PDF. For reading on my regular Kobo e-reader, PDFs don't work very well at all. I think this is generally true of most e-readers.

Interzone was (and is) a well-designed magazine. The value of it was not just the content of the text, but the context: how the stories were presented; the accompanying art (most often colour in recent decades), but also the typesetting. ePUB doesn't specify much of that stuff exactly: it leaves that up to the client and the client's preferences. And there's a lot of advantages to that: Prefer a different font face or size? No problem. And most importantly for accessibility: If reading in ePUB makes Interzone available to more readers then that's a great thing. But sadly a lot is lost, IMHO.

IZ #305 on iPad Mini

IZ #305 on iPad Mini

The solution I'm trying is to read the PDF version on the iPad Mini I resurrected earlier in the year. Despite being an Internet tablet, since it's not really usable for browsing the web anymore it's strangely still a distraction-free device. In fact it's pretty much single-purpose for reading Interzone and the odd other book which benefits from being read as PDF. I can appreciate the stylistic choices made in the page-setting as they were intended; I can quickly jump around the issue without waiting for an e-ink refresh; I get full colour; and whilst it would be tiring to read for a long time on the iPad screen, for the length of articles or stories in a magazine, this isn't a problem.

It's not a solution for tracking what I've read (that version of ipadOS is too old to support clumsily scrawling on PDF pages with your fingers, at least in the Books app) but it otherwise seems to work well, so I'll see how it goes.

20 July, 2026 09:26PM

Tim Retout

Renewal relationships between AWS certifications

When you pass an AWS certification exam, sometimes it can extend the life of related lesser AWS certifications. But I could not find an illustration of exactly which ones, so here’s an up-to-date diagram:

AWS Certification renewal dependencies Figure: Renewal relationships between AWS certifications.

Each arrow is a ‘renews’ relation – there’s no obligation to pass lesser exams before the harder ones, but you could also follow the arrows backwards if you want to learn easier material before sitting the more difficult exams.

I have made two important simplifications to the graph:

  1. The ‘Advanced Networking – Specialty’ certification is being retired soon, so I’ve omitted it entirely. The last date to take that exam is 25th August 2026. But Specialty certs don’t renew anything else anyway.

  2. I have left out transitive relationships in order to simplify the graph – so e.g. if you pass a ‘Solutions Architect – Professional’ exam, it also renews any Cloud Practitioner certificate you might hold, even if you do not currently hold the relevant Associate certificate.

You also have the option of sitting each exam again to renew of course, and there’s a new scheme to ‘maintain’ various certs via AWS Skill Builder which can extend them by one year rather than three.

20 July, 2026 08:52PM

hackergotchi for Bits from Debian

Bits from Debian

DebConf26 starts today in Santa Fe on Monday, July 20, 2026

DebConf26, the 27th annual Debian Developer Conference, is taking place at Santa Fe, Argentina from 20 to 25 July 2026. Debian contributors from all over the world have come together at the Facultad de Ingeniería en Ciencias Hídricas (Faculty of Engineering in Water Sciences), one of the faculties that belong to the Universidad Nacional del Litoral (National University of the Littoral), to participate and work in a conference exclusively ran by volunteers.

Today the main conference starts with around 300 expected attendants and over 80 scheduled activities, including 45-minute and 20-minute talks, Bird of a Feather ("BoF") team meetings, workshops, a job fair, as well as a variety of other events. The full schedule is updated each day, including activities planned ad-hoc by attendees over the course of the conference.

If you would like to engage remotely, you can follow the video streams available from the DebConf26 website for the events happening in the three main talk rooms: Aula Magna - FADU, Aula Magna - FBCB and Aula 0.3 - FICH accessible from the DebConf26 homepage. You can also join the conversations happening inside the talk rooms via the OFTC IRC network in the #debconf-fadu, #debconf-fbcb, and #debconf-fich3 channels. Please also join us in the #debconf channel for common discussions related to DebConf.

You can also follow the live coverage of news about DebConf26 provided by our micronews service or the @debian profile on your favorite social network.

DebConf is committed to a safe and welcoming environment for all participants. Please see our Code of Conduct page for more information on this.

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

DebConf26 sponsors logo

20 July, 2026 09:50AM by The Debian Publicity Team

July 18, 2026

DebConf26 welcomes its sponsors

Alt DebConf26 by Romina Molina

DebConf26, the 27th edition of the Debian conference is taking place at the Facultad de Ingeniería en Ciencias Hídricas of the Universidad Nacional del Litoral, in Santa Fe, Argentina. We appreciate the organizers for their hard work, and hope this event will be highly beneficial for those who attend in person as well as online.

This event would not be possible without the help from our generous sponsors. We would like to warmly welcome the sponsors of DebConf26, and introduce them to you.

We have two Platinum sponsors.

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

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

Our Gold sponsors are:

  • Freexian, Freexian specializes in Free Software with a particular focus on Debian GNU/Linux. Freexian can assist with consulting, training, technical support, packaging, or software development on projects involving use or development of Free software. All of Freexian's employees and partners are well-known contributors in the Free Software community, a choice that is integral to Freexian's business model.

  • Viridien an advanced technology, digital and Earth data company that pushes the boundaries of science for a more prosperous and sustainable future. Viridien has been using Debian-based systems to power most of its HPC infrastructure and its cloud platform since 2009 and currently employs two active Debian Project Members.

Our Silver sponsors are:

  • Arm: leading technology provider of processor IP, Arm powered solutions have been supporting innovation for more than 30 years and are deployed in over 280 billion chips to date.
  • Pexip brings the ease of commercial video platforms to secure and sovereign environments without compromising control or performance.
  • The Bern University of Applied Sciences with around 7,959 students enrolled, located in the Swiss capital.
  • Ubuntu, the Operating System delivered by Canonical.
  • OS-Sci, Open Source Science is a world-leading institution dedicated to teaching computer science through Free and Open Source Software (FOSS).
  • gcoop, a free software development company with over 19 years of market experience, organized as a worker cooperative, promoting best practices in software development.
  • Qualcomm Technologies, one of the world's leading companies in field of mobile technology, sponsors and contributes to Open Source developer communities that drive collaboration.
  • Civil Infrastructure Platform, a collaborative project hosted by the Linux Foundation, establishing an open source “base layer” of industrial grade software.
  • Siemens is a technology company focused on industry, infrastructure and transport.
  • Collabora, a global consultancy delivering Open Source software solutions to the commercial world.
  • NERDEARLA, the largest free tech event in the Spanish-speaking world.

Bronze sponsors:

And finally, our Supporter level sponsors:

A special thanks to the Facultad de Ingeniería y Ciencias Hídricas - FICH UNL, our Venue Partner!

Thanks to all our sponsors for their support! Their contributions enable a diverse global community of Debian developers and maintainers to collaborate, support one another, and share knowledge at DebConf26.

18 July, 2026 12:00PM by The Debian Publicity Team

July 17, 2026

Sergio Cipriano

Running Graphical Applications in Incus Containers

Running Graphical Applications in Incus Containers

I didn't know how easy it is to display the graphical console of a virtual machine until I tried recently.

$ sudo apt install virt-viewer
$ incus launch images:debian/trixie test --vm
$ incus console test --type=vga

That's it.

17 July, 2026 08:17PM