The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 18.4, 17.10, 16.14, 15.18, and 14.23. This release fixes 11 security vulnerabilities and over 60 bugs reported over the last several months.
For the full list of changes, please review the release notes.
PostgreSQL 14 will stop receiving fixes on November 12, 2026. If you are running PostgreSQL 14 in a production environment, we suggest that you make plans to upgrade to a newer, supported version of PostgreSQL. Please see our versioning policy for more information.
Log in
CREATE TYPE does not check multirange schema CREATE privilegeCVSS v3.1 Base Score: 5.4
Supported, Vulnerable Versions: 14 - 18.
Missing authorization in PostgreSQL CREATE TYPE allows an object creator to
hijack other queries that use search_path to find user-defined types,
including extension-defined types. That is to say, the victim will execute
arbitrary SQL functions of the attacker's choice. Versions before PostgreSQL
18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
The PostgreSQL project thanks Jelte Fennema-Nio for reporting this problem.
CVSS v3.1 Base Score: 8.8
Supported, Vulnerable Versions: 14 - 18.
Integer wraparound in multiple PostgreSQL server features allows an application input provider to cause the server to undersize an allocation and write out-of-bounds. This results in a segmentation fault. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
The PostgreSQL project thanks Anemone, A1ex, Xint Code, Jihe Wang, Jingzhou Fu, Pavel Kohout, Petr Simecek, www.aisle.com, Bruce Dang of Calif.io, and Sven Klemm for reporting this problem.
timeofday() can disclose portions of server memoryCVSS v3.1 Base Score: 4.3
Supported, Vulnerable Versions: 14 - 18.
Externally-controlled format string in PostgreSQL timeofday() function allows
an attacker to retrieve portions of server memory, via crafted timezone zones.
Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
The PostgreSQL project thanks Xint Code for reporting this problem.
pg_basebackup and pg_rewind can overwrite unrelated files of origin superuser choiceCVSS v3.1 Base Score: 8.8
Supported, Vulnerable Versions: 14 - 18.
Symlink following in PostgreSQL pg_basebackup plain format and in pg_rewind
allows an origin superuser to overwrite local files, e.g.
/var/lib/postgres/.bashrc, that hijack the operating system account. It will
remain the case that starting the server after these commands implicitly trusts
the origin superuser, due to features like shared_preload_libraries. Hence, the
attack has practical implications only if one takes relevant action between
these commands and server start, like moving the files to a different VM or
snapshotting the VM. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and
14.23 are affected.
The PostgreSQL project thanks Valery Gubanov, XlabAI Team of Tencent Xuanwu Lab, Atuin Automated Vulnerability Discovery Engine, Zhanpeng Liu (pkugenuine(at)gmail(dot)com), Guannan Wang (wgnbuaa(at)gmail(dot)com), and Guancheng Li (lgcpku(at)gmail(dot)com) for reporting this problem.
pg_createsubscriber allows SQL injection via subscription nameCVSS v3.1 Base Score: 7.2
Supported, Vulnerable Versions: 17 - 18.
SQL injection in PostgreSQL pg_createsubscriber allows an attacker with
pg_create_subscription rights to execute arbitrary SQL as a superuser. The
attack takes effect when pg_createsubscriber next runs. Within major versions
17 and 18, minor versions before PostgreSQL 18.4 and 17.10 are affected.
Versions before PostgreSQL 17 are unaffected.
The PostgreSQL project thanks Yu Kunpeng for reporting this problem.
libpq lo_* functions let server superuser overwrite client stack memoryCVSS v3.1 Base Score: 8.8
Supported, Vulnerable Versions: 14 - 18.
Use of inherently dangerous function PQfn(..., result_is_int=0, ...) in
PostgreSQL libpq lo_export(), lo_read(), lo_lseek64(), and lo_tell64()
functions allows the server superuser to overwrite a client stack buffer with an
arbitrarily-large response. Like gets(), PQfn(..., result_is_int=0, ...)
stores arbitrary-length, server-determined data into a buffer of unspecified
size. Because both the \lo_export command in psql and pg_dump call
lo_read(), the server superuser can overwrite pg_dump or psql stack memory.
Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
The PostgreSQL project thanks Yu Kunpeng and Martin Heistermann for reporting this problem.
CVSS v3.1 Base Score: 6.5
Supported, Vulnerable Versions: 14 - 18.
Covert timing channel in comparison of MD5-hashed password in PostgreSQL authentication allows an attacker to recover user credentials sufficient to authenticate. This does not affect scram-sha-256 passwords, the default in all supported releases. However, current databases may have MD5-hashed passwords originating in upgrades from PostgreSQL 13 or earlier. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
The PostgreSQL project thanks Joe Conway for reporting this problem.
CVSS v3.1 Base Score: 7.5
Supported, Vulnerable Versions: 14 - 18.
Uncontrolled recursion in PostgreSQL SSL and GSS negotiation allows an attacker able to connect to a PostgreSQL AF_UNIX socket to achieve sustained denial of service. If SSL and GSS are both disabled, an attacker can do the same via access to a PostgreSQL TCP socket. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
The PostgreSQL project thanks Calif.io in collaboration with Claude and Anthropic Research for reporting this problem.
pg_restore_attribute_stats accepts values that cause query planning to read past end of stats arrayCVSS v3.1 Base Score: 4.3
Supported, Vulnerable Versions: 18.
Buffer over-read in PostgreSQL function pg_restore_attribute_stats() accepts
array values of unmatched length, which causes query planning to read past end
of one array. This allows a table maintainer to infer memory values past that
array end. Within major version 18, minor versions before PostgreSQL 18.4 are
affected. Versions before PostgreSQL 18 are unaffected.
The PostgreSQL project thanks Jeroen Gui for reporting this problem.
refint allows stack buffer overflow and SQL injectionCVSS v3.1 Base Score: 8.8
Supported, Vulnerable Versions: 14 - 18.
Stack buffer overflow in PostgreSQL module refint allows an unprivileged
database user to execute arbitrary code as the operating system user running the
database. A distinct attack is possible if the application declares a
user-controlled column as a refint cascade primary key and facilitates
user-controlled updates to that column. In that case, a SQL injection allows a
primary key update value provider to execute arbitrary SQL as the database user
performing the primary key update. Versions before PostgreSQL 18.4, 17.10,
16.14, 15.18, and 14.23 are affected.
The PostgreSQL project thanks Nikolay Samokhvalov for reporting this problem.
REFRESH PUBLICATION allows SQL injection via table nameCVSS v3.1 Base Score: 3.7
Supported, Vulnerable Versions: 16 - 18.
SQL injection in PostgreSQL logical replication
ALTER SUBSCRIPTION ... REFRESH PUBLICATION allows a subscriber table creator
to execute arbitrary SQL with the subscription's publication-side credentials.
The attack takes effect at the next REFRESH PUBLICATION. Within major versions
16, 17, and 18, minor versions before PostgreSQL 18.4, 17.10, and 16.14 are
affected. Versions before PostgreSQL 16 are unaffected.
The PostgreSQL project thanks Pavel Kohout, Aisle Research for reporting this problem.
This update fixes over 60 bugs that were reported in the last several months. The issues listed below affect PostgreSQL 18. Some of these issues may also affect other supported versions of PostgreSQL.
DEFERRABLE INITIALLY DEFERRED would behave as NOT DEFERRABLE
after being set to NOT ENFORCED status and then back to ENFORCED. If you
have a foreign key with this problem, after installing this update you can fix
it by setting it to NOT ENFORCED and then back to ENFORCED.ON t1.boolcol.INSERT ... ON CONFLICT works when EXCLUDED references a virtual
generated column.MERGE encounters a concurrently-updated
tuple in "repeatable read" or "serializable"
isolation modes.CREATE TABLE ... LIKE ... INCLUDING STATISTICS for cases where the
source table had one or more dropped columns.WITHOUT OVERLAPS to allow domains.multirange.array_agg(anyarray) executes in
parallel.pg_aios system view pid column show NULL instead of 0 when an
entry has no owning process.pg_stat_replication shows NULL lag even while replication
is active.GROUP BY.pg_basebackup and pg_verifybackup.pg_dumpall doesn't skip role grants with dangling grantor OIDs,
restoring the behavior before PostgreSQL 16. Emits a warning about missing
grantor if the source server is PostgreSQL 16 or later.pg_upgrade to use the correct protocol version when connecting to older
source servers.pg_overexplain when using the RANGE_TABLE option.postgres_fdw crash due to premature cleanup of a failed connection.This release also updates time zone data files to tzdata release 2026b, in which British Columbia (America/Vancouver) will be on year-round UTC-07 (effectively, permanent DST) beginning in November 2026. This release assumes that their TZ abbreviation will be MST from that time forward (though this could change). There is also a historical correction for Moldova, which has used EU DST transition times since 2022.
All PostgreSQL update releases are cumulative. As with other minor releases,
users are not required to dump and reload their database or use pg_upgrade
in order to apply this update release; you may simply stop PostgreSQL and
update its binaries.
Users who have skipped one or more update releases may need to run additional post-update steps; please see the release notes from earlier versions for details.
For more details, please see the release notes.
If you have corrections or suggestions for this release announcement, please send them to the pgsql-www@lists.postgresql.org public mailing list.
It's so exciting when something you've been working on for quite some time is finally done. Today is the day, as the long-awaited Illinois DLC for American Truck Simulator is ready to welcome its first truckers!
The Illinois DLC is now released and available on Steam!
We announced Illinois in February 2025, and since then, our asset and map designers have done some amazing work on bringing it to life for our #BestCommunityEver. As we brought you updates on this DLC in the past year, we have seen your amazing feedback and excitement about this map expansion. We are so happy that today, we are finally able to explore it! And believe us, there's so much to discover.
Make the most of your visit to the wonderful Prairie State and enjoy every moment as you:
From vibrant cities like Chicago, one of the Midwest's most iconic cities, to breathtaking landscapes shaped by the Mississippi River, winding past picturesque towns, there will be no shortage of new and beautiful locations to explore and haul some cargo. If you own some of our already released DLCs, you will also be able to travel the full length of the legendary Route 66 with the release of Illinois!
Don't forget about our special Release Live Stream, which is going to start today at 3 pm CEST. We will introduce some special guests, including the CEO of SCS Software, Pavel Šebor, who will tell you more about this new map expansion while we drive through Illinois. Towards the end of the live stream, we will officially release the Illinois DLC together, so make sure to be there!
We are eager for you to start trucking in the Prairie State. Remember to tag us in your photos and videos from this map expansion using the hashtag #CruisingIllinois on X/Twitter, Facebook, Instagram, and Bluesky. If you'll enjoy your time in Illinois, we'd really appreciate it if you left a review on its DLC Steam store page. We thank you for all your support, and until next time, happy haulin'!
In or around 2014 I bought an iPad Mini (2), and following the normal lifecycle of iOS devices, a major OS update eventually killed it as a useful, general-purpose device: operating it was just too sluggish. It remained useful as a streaming media player for a little while longer until eventually the big streamers (BBC iPlayer, Netflix, etc.) stopped supporting the version of their app which the iPad could install: the last officially supported iOS was 12.4.8 in July 2020, and by November it was officially dead.
Old 32bit games
During its useful life, the iPad Mini witnessed Apple's transition from 32 to 64 bit apps. In the 32 bit days, there was a little cottage industry of app developers, and in particular, game developers. There were even several independent websites (App Shopper, Pod Gamer, Free-App Hero), which aided in sorting through the morass of apps to find the good ones (then as now, the App Store itself was almost impossible to effectively browse). This all went away during the 32/64 transition, as many small-scale developers weren't actively developing their applications or games any more, and weren't prepared to pay the time or apple tax to rebuild and publish them as 64 bit.
The last version of iOS that supported 32 bit apps on this device was 10.3.3, and by luck, there are some methods available to install this old version of iOS on the Mini 2 Today. A couple of years ago I did so, and I kept no notes so sadly I can't report on which method I used. But it worked, and I was able to install a bunch of old 32 bit games that I had no access to on more modern devices.
Prior to John Carmack's1 departure from iD Software, he'd been responsible for publishing several experimental iD software games on iOS. These mostly disappeared in the 64 bit transition. Amongst them are ports of Wolfenstein 3D, classic Doom, some RAGE tie-ins, but perhaps most interestingly. at least two original games, designed for the phone form factor: Doom 2 RPG and Wolfenstein RPG.
Reading magazine-style things
Another notable game that disappeared was "Civilisation Revolution", a cut-down Civ game that for a while I was obsessed with. Rather than port it to 64 bit, the publisher withdrew it, and then published a "new" game "Civilisation Revolution 2", requiring a separate purchase. Sadly, it is rubbish, nowhere near as good as the first one.
Anyway, having managed to downgrade it to the 32 bit iOS and install these old lost games, I then, of course, never played them and the device continued to gather dust. I should make clear that, running such an old unpatched iOS version means it's not safe at all to put any kind of sensitive information on this, including entering passwords. I don't recommend even opening the web browser. However, this 12 year old device does have some use as an e-reader, especially for certain types of ebook or magazine, that I've struggled to engage with on other devices. That's a topic for another blog post.
Last week, I spent the entire week in Campinas attending MiniDebConf and MiniDebCamp. The Debian Brazil community organizes this event every year, and this year's edition was the biggest so far.
During MiniDebCamp, I sponsored a few uploads and spent two days teaching packaging to two participants. I usually teach packaging online, so it was refreshing to do it in person. I believe the experience was much better than teaching online.
One of my mentees introduced me to the DDTSS (Debian Distributed Translation Server Satellite). Even though there are many i18n contributors in Brazil, this was my first time learning about this system. I plan to contribute to translations over the next few weeks using DDTSS.
NOTE: I translated every talk title; the original titles are in PT-BR, so some details may have been lost in translation.
I presented three talks and led one BoF session. The talks are all available on Debian's Peertube:
You can also find my slides at people.d.o.
My first talk was a showcase of dh-make-vim, a tool I created and have been using for a few months. Some people tested it and found bugs, which was really nice to see.
My second talk was essentially a live version of my blog post Zero-Code Instrumentation of an Envoy TCP Proxy using eBPF.
I also gave a lightning talk about something many people are not aware of: non-uploading DDs can also sponsor uploads.
If you're interested, this bug report provides more context: tracker.debian.org: Signed by field is missing when sponsoring as DD non-uploading
Finally, I led the BoF session "Experiences, lessons learned, and next steps from the mentoring sessions". This was my favorite session, we had many participants with different perspectives and ideas, which led to a very engaging discussion. I'm still working on the action plans and I plan to release them soon.
Here are some photos of these activities:
This is a list, in no particular order, of some of the sessions I enjoyed the most:
Salsa CI, showing features that almost nobody knows
I wrote a blog post about one of the things I learned in this talk, and there is still a lot more to explore. Aquila Macedo is developing many cool features in Salsa CI.
Free Software: Freedom, Autonomy, Sovereignty
I had been really looking forward to this one. Alexandre Oliva is a very important figure in the Free Software movement, especially in South America. I'll need to rewatch it, my futures talks about Free Software will likely be inspired by this one.
What I've lived/seen in 33 Years of Debian & Free Software in general
Eduardo Maçan was the first Debian Developer in Brazil, so it's always valuable to hear the story from someone who was part of it.
Despite the title, this talk was not about astrology! I'll probably rewatch it as well, as there is a lot of information to take in. I really like the passion Sérgio Durigan has for C. He is also a great speaker and knows how to guide the audience through the topic.
Debate: Contemporary controversies in Debian
The debate itself was great, but the conversations we had afterward were even better. I changed some of my opinions after hearing different perspectives. I don't think this format would work at DebConf, but I would definitely like to attend another one like this.
I had a few questions about LTS, and Kanashiro and Santiago answered them both during the talk and in the Q&A session. They also shared some challenges and how to avoid them, it was a great learning experience.
From my first contribution to the Debian Maintainer
Polkorny was a bit shy but did a great job! I really enjoy this kind of talk. It is always nice to see the different paths people take.
Unfortunatly, I couldn't attend everything I was interested in, as always.
Sirius is the largest and most complex scientific infrastructure ever built in Brazil and one of the most advanced synchrotron light sources in the world. My jaw dropped the entire time; it's hard to describe how incredible this is.
My favorite detail: they're running Debian :)
I believe this was the best MiniDebConf Brazil so far. There were many other things I chose not to include here, as this post is already quite long. Still, here are a few more highlights:
My Debian contributions this month were all sponsored by Freexian.
You can also support my work directly via Liberapay or GitHub Sponsors.
Ian Jackson reported that dput-ng could lose data when using the local install method (relevant in tests of other packages, for instance) and filed an initial merge request to fix it. I improved this to isolate its tests properly, and uploaded it.
I upgraded from 1.23.0 to 1.24.1. 1.24.0 and 1.24.1 were the first upstream releases since 2023, and had extensive changes; I’d had the corresponding packaging changes in the works since January, but it took me a while to get round to finishing them off. It was good to get this off my list.
I released bookworm and trixie fixes for CVE-2026-3497, and issued the corresponding BSA-130 for trixie-backports.
I upgraded from 10.2p1 to 10.3p1.
I upgraded from 3.6 to 3.7. 3.7 was the first upstream release since 2023, but the changes were nowhere near as extensive as groff, so this was a fairly quick job. I also fixed the parted-doc package to ship proper API documentation.
New upstream versions:
I started an upstream discussion about how best to handle the pydantic and pydantic-core packages now that they share an upstream git repository.
Other bug fixes:
New upstream versions:
I upgraded from 2.7.2 to 2.7.3.
During March and April, we had a number of performance issues that made Debusine’s core functions of running work requests and reflecting their results in workflows quite unreliable. Investigating and fixing this took up a lot of time from both the Debusine development team and Freexian’s sysadmins.
The central problems involved a series of database concurrency and worker communication issues that interacted in complex ways. On bad days, this caused between 10% and 25% of processed work requests to fail unnecessarily. We communicated some of the problems to users on IRC, but not consistently since we didn’t entirely understand the scope of the problems at the time.
Most of the problems are fixed now, but we had a retrospective meeting to make sure we understood what happened and that we learn from it. Here’s a summary.
Debusine’s workflows consist of many individual work requests. Each work request has a database row representing its state, which means that the overall state of a workflow is distributed across many rows. Changes to one work request (for example, when it is completed) can cause changes to other work requests (perhaps unblocking it so that it can be scheduled to an idle worker). Those changes may happen concurrently, and in practice often do.
Workers typically need to create artifacts containing the output of tasks: these include things like packages, build logs, and test output.
Debusine records task history so that it can make better decisions about how to schedule work requests. Since this might otherwise grow without bound, the server expires older parts of that history after a while. The same is true for many other kinds of data.
Because workflows involve changes that propagate between work requests, there were historically some cases where different parts of the system could deadlock due to trying to take update locks on overlapping sets of work request rows in different orders. We mitigated that somewhere around 2025-11-05 by locking entire workflows in one go before making any change that might need to propagate between work requests like this; that dealt with the deadlocks, but it’s quite a heavyweight locking strategy that sometimes caused significant delays.
We’ve been working for some time to make Debusine useful to Debian developers, and regression tracking is an important part of that: it lets developers test uploads without being too badly misled by tests in related packages that were already failing before they started. On 2026-03-11 we enabled this by default on debusine.debian.net, after testing it for a while. Although this is useful, it put more load on the system as a whole, often approximately doubling the number of work requests in a given workflow with many additional dependencies between them.
Like much of the world, we’re in an arms race with unethical scrapers desperately trying to feed everyone else’s data into LLMs before they run out of money. We saw a substantial uptick here towards the end of March, which meant that we had to temporarily disable regression tracking and to put some other mitigations in front of our web interface.
We historically haven’t had systematic internal timeouts. Prompted by ruff, a Google Summer of Code applicant went through and added timeouts in many places, including some calls between the worker and the server. This was fiddly work and the student did a solid job, so I’m not putting them on blast or anything! However, it did mean that some things that came in under load balancer timeouts now timed out earlier on the client side of the request (and hence in Debusine workers), which made some problems show up in different ways and be more obvious. This was deployed on 2026-04-03.
Figuring out what individual work requests need to be run as part of a workflow - the process we call “orchestration” - can be challenging. Unlike typical CI pipelines, these workflows often span substantial chunks of a distribution: a glibc update can involve retesting nearly everything! Nevertheless, it’s not particularly helpful for it to take hours just to build the workflow graph.
Fixing this involved many classic database optimizations such as adding indexes and CTEs, but probably the most effective fix was adding a cache for lookups within each orchestrator run or work request. Profiling showed that resolving lookups was a hot spot, and the way that task data is often passed down through a workflow meant that the same lookup could be resolved hundreds or thousands of times in a large workflow.
We knew for quite some time that our expiry job took very aggressive locks, effectively blocking most of the rest of the system. This was an early decision to make the expiry logic simpler by allowing it to follow graphs without worrying about concurrent activity, but it clearly couldn’t stay that way forever.
Row locks in
PostgreSQL
was very helpful in figuring out the correct approach here. Since we’re
mainly concerned about the possibility of new foreign key references being
created to artifacts we’re considering for expiry, and since that would
involve taking FOR KEY SHARE locks on those rows, we can explicitly take
FOR UPDATE locks (which conflict with FOR KEY SHARE), and then recompute
the set of artifacts to expire with any locked artifacts marked to keep.
This was delicate work, but it saved minutes of downtime every day.
I mentioned earlier that we avoided some deadlock issues by taking locks on
entire workflows. To ensure that these locks are effective even against
code that isn’t specifically aware of them, this is implemented by using
SELECT FOR UPDATE on all the work request rows in the workflow. In some
cases the search for which rows to lock itself tripped up the PostgreSQL
planner.
We run multiple Celery workers for various purposes. Some of them can do many things in parallel, but in some specific cases (notably the task scheduler) we only ever want a single instance to run at once. Unfortunately a bug in the systemd service meant that the scheduler often ran concurrently anyway! Once we fixed that, the scheduler logs became a lot less confusing.
When Debusine was small, it was reasonable for it to perform scheduling very aggressively, typically as soon as any change occurred to a work request or a worker that might possibly influence it. This doesn’t scale very well, though, and even though we tried to batch multiple scheduling triggers that occurred within a single transaction, it could still make debugging very confusing. We reduced the number of changes that would result in immediate scheduling, and deferred everything else to a regular “tick”.
The scheduler may not be able to assign a work request to an idle worker due to the workflow being locked. That isn’t a major problem in itself; it can just try again later. However, in very large workflows, we found that it often worked its way down all the pending work requests one by one finding that each of them was locked, which was slow and also produced a huge amount of log noise. It now assumes that if a work request is locked, then it might as well skip other work requests in the same workflow until the next scheduler run.
Between them, these changes reduced the number of locks typically being held on debusine.debian.net by about 80%:
The Debusine worker has always been partially asynchronous, but while it was actually executing a task - in other words, most of the time, at least in busy periods - it didn’t respond to inbound websocket messages, causing spurious disconnections. We restructured the whole worker to be fully event-based.
We also had to put quite a bit of effort into improving the path by which workers report work request completion, because if that hits a timeout then it can mean throwing away hours of work. We have some further improvements in mind, but for now we defer most of this work to a Celery task so that whole-workflow locks aren’t on the critical path.
One of our sysadmins observed that our database write volume was consistently very high. This was a puzzle, but for a long time we left that unexplored. Eventually we thought to ask PostgreSQL’s own statistics, and we found a surprise:
debusine=> SELECT relname AS table_name,
debusine-> n_tup_ins AS inserts,
debusine-> n_tup_upd AS updates,
debusine-> n_tup_del AS deletes,
debusine-> (n_tup_ins + n_tup_upd + n_tup_del) AS total_dml
debusine-> FROM pg_stat_user_tables
debusine-> WHERE (n_tup_ins + n_tup_upd + n_tup_del) > 0
debusine-> ORDER BY total_dml DESC
debusine-> LIMIT 20;
table_name | inserts | updates | deletes | total_dml
--------------------------------------+---------+------------+---------+------------
db_collectionitem | 1418251 | 3578202388 | 3630143 | 3583250782
db_token | 15143 | 11212106 | 11389 | 11238638
db_workrequest | 386196 | 6399071 | 1820500 | 8605767
db_fileinartifact | 2783021 | 1837929 | 1663887 | 6284837
django_celery_results_taskresult | 1819301 | 1501623 | 1791656 | 5112580
db_artifact | 960077 | 3340859 | 663890 | 4964826
db_collectionitemmatchconstraint | 1550457 | 0 | 2207486 | 3757943
db_artifactrelation | 2229382 | 0 | 1363825 | 3593207
db_fileupload | 1023400 | 1057036 | 1023346 | 3103782
db_file | 1673194 | 0 | 970252 | 2643446
db_fileinstore | 1411995 | 0 | 970259 | 2382254
db_filestore | 0 | 2381578 | 0 | 2381578
django_session | 645423 | 1519880 | 531 | 2165834
db_workrequest_dependencies | 365877 | 0 | 936537 | 1302414
db_worker | 18317 | 949280 | 9487 | 977084
db_collection | 10061 | 85 | 177741 | 187887
db_workerpooltaskexecutionstatistics | 28721 | 0 | 0 | 28721
db_workerpoolstatistics | 1640 | 0 | 0 | 1640
db_workflowtemplate | 130 | 158 | 649 | 937
db_identity | 76 | 661 | 0 | 737
(20 rows)
Oh my - that’s a lot of db_collectionitem updates and must surely be out
of proportion with what we really need. Can we narrow that down by asking
about the most recently-updated tuples?
debusine=> SELECT DISTINCT category
debusine-> FROM db_collectionitem
debusine-> WHERE id IN (
debusine-> SELECT id FROM db_collectionitem
debusine-> ORDER BY xmin::text::integer DESC LIMIT 10000
debusine-> );
category
------------------------------
debusine:historical-task-run
(1 row)
That might not be absolutely reliable, but it was certainly a hint. As per
PostgreSQL’s
documentation,
by default UPDATE always performs physical updates to every matching row
regardless of whether the data has changed, and our code to expire old task
history entries wasn’t doing that properly. Once we knew where to look, it
was easy to add some extra
constraints.
This reduced our mean write volume on debusine.debian.net from about 23 MB/s to about 3 MB/s, which had an immediate knock-on effect on our request failure rate:
Our metrics indicate that things are a lot better now. We still have a few things to deal with, such as:
journalctl isn’t terrible,
but it’s not really the state of the art.I hope this has been an interesting tour through the sorts of things that can go wrong in this kind of distributed system!
MySQL released (well, flipped the default compilation flag for) the hypergraph join optimizer in the community builds; this was the main project I started and worked on while I was there, so it's nice to see even though it's been default in e.g. their cloud column store for a long time. You can read their blog post (though beware, likely-LLM text ahead).
(The cost model improvements and TPC-DS benchmarking are from after my time.)
Version 0.0.29 of RcppSpdlog arrived on CRAN today, has been uploaded to Debian and built for r2u. The (nice) documentation site has been refreshed too. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn more at the nice package documention site.
This release features a rewritten internal routine unpacking the R
variadic arguments into C++ variadic template arguments. This in turn
allows to turn back to std::format in C++ mode when C++20
is used. We also adjust for the not-quite-ready-for-this state of the
x86-64 based macOS machine at CRAN. It is running a compiler and SDK
choice that cannot fully deal with C++20, so we dial compilation on it
down to C++17. Similarly, and as we found out after the release, Ubuntu
jammy is also too old to default to std::format so we need
to add a better detection here too so that we can also fall back to the
included fmt there.
The NEWS entry for this release follows.
Changes in RcppSpdlog version 0.0.29 (2026-05-08)
Some small continuous integration updates
The internal formatter was rewritten as a recursive generator of variadic templates.
Switch back to
std::formatwith C++20, but force inferior macos-release-x86_64 to use C++17 rather than default C++20 which fails
Courtesy of my CRANberries, there is also a diffstat report detailing changes. More detailed information is on the RcppSpdlog page, or the package documention site.
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.
deb-scrub-obsolete is a tool in the debian-codemods suite that tries to identify and remove cruft automatically. It knows about dummy transitional packages, superseded alternatives, and similar patterns it can detect by querying the archive. But some workarounds are too project-specific for a generic tool to recognise on its own.
Developers can leave structured comments in their packaging files that tell deb-scrub-obsolete when a particular line or block can be removed.
The Debian Janitor regularly runs various codemods like deb-scrub-obsolete on all vcs-accessible Debian packages. This means that if you leave a “remove-after: trixie” annotation in your package, you will automatically get a pull request to remove the annotated code once trixie has been released, without needing to remember to do it yourself.
The annotations take the form of specially-formatted comments. For shell files (and by extension most maintainer scripts), a line-level annotation looks like this:
install -m 755 compat-wrapper /usr/lib/foo/ # remove-after: trixie
When trixie has been released, deb-scrub-obsolete will remove that line entirely. The comment can appear anywhere on the line — before or after other comments — and additional explanatory text can follow:
blah # Trixie comes with blah built in # remove-after: trixie
For larger sections, block-level annotations bracket the code to remove:
# begin-remove-after: trixie alternatives --add foo bar alternatives --add foo bar1 # end-remove-after
These blocks can be nested, which is useful when one outer condition wraps several inner ones with finer-grained timing.
The initial set of supported expressions is deliberately small. The main one is a Debian release name: remove-after: trixie means “once trixie has been released”. The condition is checked against distro-info <https://manpages.debian.org/trixie/distro-info/distro-info.1.en.html>_, the same data source that other Debian tooling uses to track release status.
The expression language is designed to be monotonic — conditions should only ever go from false to true, not back. A workaround that needs to be re-introduced after removal belongs in a new commit, not in an annotation. If deb-scrub-obsolete cannot parse an annotation it finds in a file, it leaves all annotations in that file untouched, to avoid a situation where related blocks are only partially removed.
Annotations can also carry a marker name — an arbitrary label with no spaces, commas, or the word “after” — which can then be passed to deb-scrub-obsolete on the command line. This makes it possible to trigger removal of a named set of annotations together, useful for coordinated transitions where several packages need to be cleaned up at the same time.
The initial expression set is minimal; the design leaves room for richer conditions. Some candidates under consideration:
Compound expressions using “and” / “or” are also on the list, for cases where removal depends on multiple conditions being true simultaneously.
The annotation format is specified but not yet implemented in deb-scrub-obsolete - it is planned for a future release. If you maintain Debian packages and have opinions on the annotation format or the expression language, feedback is welcome. The specification lives in scrub-obsolete/doc/scrub-annotations.md in the lintian-brush repository. Many thanks to Helmut Grohne for the initial suggestion and feedback on the design.
I have done some packaging work on Amazfish (the smart-watch software that works with the PineTime among others) for Debian. Here is my Git repository for libnemodbus (a dependency for Amazfish that isn’t in Debian) [1]. Here is my Git repository for Amazfish itself [2].
These packages are currently using QT5 which is a good reason to not upload them now as the transition to QT6 is in progress. Patching them to work with QT6 (as the libnemodbus upstream is apparently not migrating to QT6 yet) shouldn’t be that difficult but is something that needs some care and communication to get it right.
Running this package on my laptop with my PineTime (which worked very reliably when run by GadgetBridge on Android) wasn’t reliable and the PineTime would disconnect and refuse to connect again. Doing it on the Furilabs FLX1s gave a similar result. If Amazfish was the only Bluetooth program having problems on my laptop and on my FLX1s then I’d blame it, but both those systems have some other Bluetooth issues.
Running this on my laptop Amazfish would send it’s own test notifications to my watch but system notifications (from notify-send among others) wouldn’t get sent. Running this on my FLX1s I got ONE notification from my network monitoring system sent to my watch before my phone and watch stopped talking to each other.
To make things even more difficult for me the harbour-amazfish-ui program doesn’t work correctly with the libraries installed on my FLX1s and doesn’t display the content of many screens but it works correctly when running in a container environment with stock Debian/Testing.
Below is the script that I’m currently using to launch apps in a Debian/Testing container on my FLX1s. The comment about unshare-user doesn’t apply to this version of the script but I left it in to avoid the potential for future confusion. The Furilabs people diverted the bwrap binary and have a wrapper that removes a set of parameters that they think will cause problems.
#!/bin/bash set -e BUILDBASE=/chroot/testing # bwrap: Can't mount proc on /newroot/proc: Device or resource busy # get the above with --unshare-user and --unshare-pid exec bwrap.real --bind /tmp /tmp --bind /run /run --bind $HOME $HOME --ro-bind $BUILDBASE/etc /etc --ro-bind $BUILDBASE/usr /usr --ro-bind $BUILDBASE/var/lib /var/lib --symlink usr/bin /bin --symlink usr/sbin /sbin --symlink usr/lib /lib --proc /proc --dev-bind /dev /dev --die-with-parent --new-session "$@"
Due to the range of problems I’m having I think it would be best to pass this package on to someone else who has a different test setup. It could be that further testing will reveal that my issues are related to bugs in Amazfish but I can’t prove it either way at this time. Maybe when using a smart watch other than a Pine Time it will work more reliably but it seems most likely that my laptop and phone are to blame. I can’t make more progress on this now.
Related posts:
Discussion of “AI” systems seems to be dominated by fears of uncommon and unlikely threats. I think that we should be focusing more on real issues with LLMs and with society in general and put the most effort towards the biggest problems.
True Artificial Intelligence [1] (IE a computer that has the mental capacity of a household pet) is something that I think can be developed, but it hasn’t been developed and we don’t have good plans for developing it. We seem to be a lot further away from achieving that goal than we were from landing on the moon in 1962 when JFK gave his historic speech.
What we have is a variety of pattern recognition systems that can predict what fits into a pattern. The most well known type of Machine Learning (ML) is the Large Language Model (LLM) which means ChatGPT and similar systems which predict which text would be likely to come next and can make an essay from it. They can give interesting and useful output, but there is no thought behind it, it’s just a better form of Eliza (the famous program from 1964 that simulates conversation by pattern matching) [2]. By analysing billions of documents, storing the data in a condensed mathematical way, and then using computation to extract from that record LLMs can produce output that is unfortunately considered by some people to be good enough to include in legal documents submitted to courts, university assignments, and many other documents. But they do so without even having the thinking ability of a mouse.
To call current systems “AIs” without any significant qualifiers when criticising them is to concede the debate about the worth of such things.
If we develop AIs that can actually think we will have to deal with the issues in the SciFi horror short story Lena by qntm [3].
Here is a list of some of the most unreasonable arguments I’ve seen against “AI” which distract attention from real problems both related to “AI” and other problems in society.
Wikipedia has a page listing Deaths Linked to Chatbots [4] which right now has 16 entries from 2023 to Feb 2026. They are all tragedies and as a society we should try to prevent such things. But what I would like to see from the media is some analysis of overall trends, yes it gets people’s attention when someone dies in an unusual way but we need to have attention paid to the more numerous deaths which are preventable. It has become a standard practice to give information on Lifeline in media referencing suicide, it would be good if they also developed a practice of mentioning the relative incidence of a problem when publishing an article about it.
One of the many factors that cause more suicides than chatbots is school, Scientific American has an informative article from 2022 about the correlation between child suicide and school [5]. It is based on US statistics and shows that the lowest suicide rate is in July (a no-school month in the US) which has a rate of 2.3 per 100,000 person years. So if kids had a quality of life equivalent to July all year around then there would be 2.3 suicides per 100,000 kids every year while if they had a quality of life equivalent to a Monday in January or November it would be 3.9 suicides per 100,000 kids every year. The article states “Any time I present these data to teachers, parents, principals or school administrators, they are shocked. This should be common knowledge.” It is common knowledge to anyone who takes any notice of what happens in schools, but paying attention to serious problems is unpleasant, it’s more fun to pretend that school is good for everyone. No parent wants to think that they sent their child to a place that was horrible, no teacher wants to think that they are part of a system that harms kids.
The US CDC has an informative article about youth suicide [6] which documents it as the 3rd largest cause of death in the 14-18 age range fro 2021. This article was published in 2024 and based on statistics from 2023 and earlier. It notes significant differences in suicides, attempts, and “persistent feelings of sadness or hopelessness” which had girls at more than twice the rate of boys and “LGBQ+” kids at more than twice the rate of “heterosexual” students. It seems obvious that misogyny and homophobia is correlated with suicide and that’s something that could and should be addressed in schools. My state has a Safer Schools program [7] to try and alleviate the problems related to homophobia, but I expect that things are getting worse in the US in that regard. 39.7% of kids in US high schools had “persistent feelings of sadness or hopelessness” before LLMs became popular, school could and should be a happy time for the vast majority of kids but instead almost half of the kids don’t enjoy it and a majority of girls and “LGBQ+” kids don’t. Having no mention of trans kids is a significant omission from that article, based on everything I’ve heard from trans people I expect that their statistics would be even worse.
One could argue that the small number of deaths inspired by use or misuse of LLMs is an indication of a larger number of people suffering in ways that don’t result in death and don’t get noticed. But I don’t think that can compare to the fact that the majority of girls and “LGBQ+” kids have “persistent feelings of sadness or hopelessness” in the current school system.
Regarding homicide, the Australian Institute of Criminology has an article showing that in the 2003-2004 time period 49% of women who were killed were listed as a “domestic argument” [8], that’s something that could and should be addressed. That article claimed 308 homicide victims in that time period which is larger than the world-wide death toll from LLMs but also less than 1/3 the death toll from car accidents in Australia. Australia has less than 0.4% of the world population, a fairly low homicide rate, and a number of homicides that vastly outnumbers all world homicides related to LLMs.
I think it’s great to address any cause of suicide or homicide, but devoting government resources and legislation towards very uncommon causes instead of things that happen every day is not a good strategy. It would be fine to address all factors leading to suicide, but problems with the school system have been a major factor for decades with little effort applied to fix it.
There is evidence of criminals using LLMs to help prepare for crimes, the ability to generate large amounts of text quickly can be used for fraud and extortion. This is going to be a serious problem and we need structural changes to society to deal with it. There is an ongoing issue of scammers convincing older people that their child or other young relative is in trouble and a large amount of cash is required to address it. This sort of scam as well as the more well known “Nigerian” scams will probably become more common as the cost of running them decreases. This may be more of a problem for people in developing countries as currently a common scam business model is to have people in regions where wages are low (such as Pakistan for one who I spoke to) scamming people in relatively wealthy countries like Australia so an attack with a low probability of success is financially viable. Cheaper attacks will make less affluent victims financially viable to the scammers.
While writing this post I received a financial scam phone call trying to get me to invest in SpaceX that was run by an “AI” chat system, I expect to receive more of them and this is something that needs to be dealt with via both technical measures and legislation.
Do we have to accept less freedom and less anonymity in finances as a cost of reducing financial crime? Greater restrictions on the use of cash would make some crimes more difficult or less profitable for criminals. As a society I think we need to have a discussion about a balance between financial freedom and freedom from criminal exploitation, failing to have such a discussion is likely to lead to policies which don’t work well.
Also one thing that ML systems are good at is recognising patterns in data. Banks could scan all their transactions and look for patterns that correlate with fraud. They currently do this badly and do things like locking credit cards when someone goes to another country and spends money. They could do a better job of that and involve the police in cases of obvious fraud even when the customer doesn’t realise that they are a victim.
This isn’t a reason to criticise “AIs”, it’s a reason to plan defensive technology that matches the capabilities of attackers.
As an aside I used to work for a company that was developing “AI” software to scan bank phone calls and allow banks to recognise employees who acted illegally. Unfortunately the Royal Commission into banking misconduct [9] didn’t impose any penalties that gave the banks a financial reason to avoid criminal activity.
There are many claims about AI systems making large numbers of jobs obsolete, some of them are outlandish such as the claims that all white-collar jobs will be obsolete in the near future. There are some reasonable claims like the ability to replace some mundane jobs.
Replacing jobs that suck with computers, robots, and other machinery is a good thing! Very few people wish that they were working on a farm without a tractor. In 1900 it’s estimated that between 60% and 70% of the world labour force worked in agriculture and 40% of the US labour force did so. Now it’s something like 27% globally and between 1% and 3% in developed countries. Automated factories are also a good thing, it’s best to avoid boring and dangerous work.
The most plausible claims about job replacement from “AI” is jobs that involve analysing and summarising documents. One example that comes to mind is the worst kind of journalism where press releases from companies are massaged into the format of a feature article. I don’t think anyone wants that sort of job and doing it with “AI” hopefully means no human has to sign their name to it.
For work like programming few people will be directly replaced by “AI” but if people can do their work more efficiently while using it then less people are required. I don’t think that any programmer likes the part of their job where they have to skim read long documents looking for a clue about how to solve a problem with a library or protocol. A LLM processing the document and finding the potentially useful things will take away the drudgery from the work and allow greater productivity.
The trend in replacing people has been making people work longer. If you force all employees to work 60 hour weeks then that can theoretically allow hiring fewer people than having 40 hour weeks. For some work that applies but for skilled work it mostly doesn’t as productivity and work quality on average drops when people work more than 40 hours in a week.
Another trend for exploiting people is having a low minimum wage and making accommodation expensive so that many people need to work two jobs. What we need is legislation to restore the situation in the 70s where a single full time job was sufficient to provide for a family. The low minimum wage and high expenses for many things is a problem that’s been slowly developing over the course of decades while being mostly ignored by journalists. If they could concentrate on the real issues that are hurting workers today they could incite political action to fix these problems.
There is no shortage of ways of cheating in school and university. There are people who are paid to write essays, mobile phones are used for cheating in exams, etc. Getting an “AI” to write essays makes it easier to cheat for the essay writing part but does so with lower quality and in a less stealthy way.
What’s the worst case scenario? That we have to change to oral exams for all university subjects?
In the US the average annual price for tuition at a university is apparently $25,000, if each student had individually supervised assessment for their exams at a cost of $100 per hour it would make the degree cost 4% more. The cost of university in the US is unreasonably high and that’s a problem that needs to be fixed, but a hypothetical case of increasing the price by 4% isn’t going to be a major part of it.
There have been many claims made that “AI” will break the security of all systems and cause the type of disruption that was previously predicted for year 2000. Bruce Schneier has written a good analysis of the issues including how “AI” can be used by both attackers and defenders [10], he doesn’t have a strong conclusion on whether the net result will be good or bad but his article does make it clear that the result is not going to be a total disaster.
While I was working on this post I read another post by Bruce Schneier that was significantly more negative about this issue [11]. While I still don’t think this will destroy civilisation I found his other post convincing enough to move computer security from the bad argument section to the weak argument section.
There are issues of bots from “AI” companies doing a bad job of trying to download all the Internet’s content and using a lot of resources. When it was just the major search engines and the Wayback Machine doing it the load was small due to having a small number of organisations that were very good at the way they did it having evolved practices over many years. Now we have a lot of idiots doing it badly and repeatedly hitting generated content.
This is really annoying but is something that we can deal with. Currently my blog and many other sites are hosted on a Hetzner server with a E3-1271 v3 CPU with 32G of RAM and there are occasions where more than half the CPU power is being used to service web requests from such systems. Even on the “server bidding” (renting servers previously used by other customers) Hetzner isn’t offering systems so slow nowadays, the slowest they offer is about 20% faster than that. This is something that can be dealt with by spending a little more on hosting until the companies doing that go bankrupt.
I’m sure this is a serious problem for some people, but for most people it’s not a big deal. Also hostile traffic on the Internet is something we have all had to deal with as a part of life since the mid to late 90s.
The unreasonably high prices for RAM are annoying and hurt the development of useful computer projects. Big companies can afford it, even with current high prices and large quantities of RAM used for some servers it’s still not significant. But it is a major issue for hobbyists and small projects. Things like setting up a dozen test VMs for FOSS development are now too expensive for many people who develop software in their spare time.
But this is a temporary thing, if AI companies were to keep buying RAM at high rates for a few years companies would just manufacture more of it to meet demand. In some situations capitalism can work.
There are many people claiming that power used by data centers for “AI” will lead to environmental damage, using power and water when there isn’t enough.
The trend of computer hardware is to get smaller and faster. It hasn’t been going as fast as it used to in many areas but it hasn’t stopped either and it’s an exponential trend. There has been an increase in data centers (DCs) for “AI” use as the use has been increasing faster than the hardware gets smaller. Eventually they will stop increasing faster than advances in hardware and software can match and the size of DCs will decrease.
As the production of renewable energy is increases the environmental cost of energy hungry industries decreases. In a few years this won’t be an issue anyone is bothered about.
Jamie McClelland makes an interesting claim that the AI companies are pushing dangers of “AI” as a method of PR [12]. That seems plausible and combined with the tendency of many journalists to just massage press releases from companies into articles could be the reason for a lot of the bad arguments against AI.
I’ve previously written about Communication and Hostile AIs [13]. I think that filling all communication channels with rubbish is a denial of service attack against society.
In the past communication took some effort, even the simplest email that was directly targeted at the recipient took some human effort and that reduced it’s frequency. I get a lot of spam saying something like “I see your web site doesn’t rank in the top for Google searches” while my web site in fact rates well and the actor named Russell Coker is ranking below me, so I know that such spam hasn’t had the minimum of human involvement. Now a spammer who wanted to do a better job could get an LLM written spam for every target so the message was specifically aimed at them and would take much longer to be recognised by a human as spam and would also avoid most anti-spam software.
Searching for businesses used to be easy, the phone book had listings for them and there was a real cost to being in the book as well as humans actively trying to stop fraud. Creating fake web sites to get business isn’t too difficult but it’s also not trivial at the moment and such fake sites won’t look complete. Now with LLMs it’s possible to create hundreds of sites that have content and look reasonable without human involvement. Instead of the small number of suicides and homicides inspired by “AI” chat systems we should probably be concerned about people who need psychological or medical advice being misled by bogus web sites created as part of fraud campaigns. Imagine people searching for mental health assistance finding web sites run by cults who oppose psychology as a profession. Imagine people searching for basic medical advice such as how to cook a healthy meal getting sucked in to web sites that start sane and then lead people to Ivermectin as a universal medicine.
LLMs have the potential to take spam from quick and simple attacks to large scale targeted fraud aimed at people and organisations that don’t have the resources to defend against it. There have been many reports of CEO impersonation fraud against major corporations aiming to steal hundreds of thousands of dollars and fraud against individuals who are persuaded to get amounts like $50,000 to help a relative who is allegedly in a difficult situation. But if every corner store experienced the same type of attack that CEOs experience and if every child had someone trying to steal the pocket money in the same way that relatively wealthy people are being targeted now it would really change things.
There is some overlap between filling all communications channels with rubbish (fake news etc) and deep fake. Making a fake photo of a politician or celebrity to lobby for legislative changes is a real issue but it’s not what most people think of when the term “deep fake” is used.
Using photo and video faking targeting non-consenting people is a serious issue. It’s not just fake porn (which is a major issue and will cause some suicides) as there are many other possibilities. Fake videos showing behaviour that justifies sacking people from their jobs is going to become an issue, for people in public facing positions even proof that the videos are fake won’t necessarily help them.
Will we find ourselves in a situation where every politician gets deep-fake porn made of them and the only people who run for public office are ones who are cool with that? Will positions of leadership in the technology industry be restricted to people who aren’t bothered by having the most depraved fake porn made of them?
We have seen a lot of evidence of law enforcement and the court system based on bias leading to bad results. The Innocence Project attempts to correct that and it’s web site documents some of the things that have gone wrong [15]. Using “AI” systems to do some of the work of law enforcement by training computers on the flawed results of current systems can entrench bias and also make it harder to spot.
When determining whether someone should be considered a suspect or whether a prisoner should be eligible for parole the number of factors that a human can use is limited. But a computer can take many more factors into account so the issues of whether inappropriate factors are being used can be masked. Computers are also unable to explain decisions that they made and are also able to come up with better fake reasons.
In the past there have been racist policies in the US about banks not lending to people living in suburbs where most houses were owned by non-white people, these policies were documented and the documents have become part of the historical record showing racist policies. If a LLM decides not to lend money to people based on mathematical correlations it determined based on historical banking practices it could assign negative weights to factors such as non-English names and implement the racism in a large array of numbers with no proof.
The current cases of lawyers getting LLM systems to do some of their work and having their incompetence revealed when the computer generated work is shown to be ridiculously bad are amusing. But that is not the real problem. The real problems will start when the computers in police cars start flagging every car owned by a non-write person as having a “probable cause” for a drug stop.
The majority of the ecosystem around “AI” is a financial scam [16]. There are companies and individuals doing good things with machine learning some of which is based on hardware and software developed as part of this ecosystem. But the majority of it has no plausible path to profits and a the future of it inevitably ends with some bankruptcies. There are circular flows of money that have the major cloud providers and NVidia looped in, when the values of these companies correct it will become apparent that they have all burned a lot of money keeping this running and all the senior people have got a share of it (the entire purpose of stock options is to allow senior people to suck money out of the company). Then every cloud provider will increase costs while under chapter 11 and all the companies that depend on them will pay whatever it takes. That includes all major companies and most governments. Unlike the dot-com boom and crash and the housing crash the coming financial crash will impact every company that we deal with and most governments. So the people in first-world countries will effectively be taxed to pay for this scam while the executives go party in Monaco. This may seem like an extreme claim but it all happened before with the dot com crash and the housing market crash.
The CEO class has an ongoing practice of doing things that aren’t crimes because they lobby (bribe) politicians to make them legal. So the current stock market shenanigans around “AI” don’t seem to involve things that governments consider to be crimes. But any normal person might be surprised to learn that such things are legal and most people would vote for such things to be crimes if they had the opportunity.
A global financial crisis is the least of the problems that seem likely to afflict society from “AI” systems. But it will be more immediately obvious when it happens – which could be this year!
Creating art requires skills that the type of people who want to create propaganda tend to lack. “AI” technologies allow creating “art” that is based on mathematical models of actual art to the requirements of the person running the program.
I have seen the term “AI Fascism” used to describe the use of “AI” to help authoritarian governments. I am dubious about whether it deserves that term and while every article I’ve read about the topic has had some good points I thought that they were all weak points.
But there are lots of ways that governments can abuse their populations without going full fascist. In the last century there were lots of truly terrible governments that didn’t even make the top 10 of fascism.
Bruce Schneier wrote an informative blog post about AI Chatbots and Trust which focused on sycophantic chatbots [17]. We have seen a lot of evidence of terrible behaviour and stupid decisions from rich people due to having no negative consequences for bad choices. The vast majority of the history of kings concerns bad decisions made by such people. A future where middle class and poor people can make the same bad decisions as rich people wouldn’t be good.
Machine Learning (abbreviated as ML) can do useful things. It’s not just Large Language Models (LLMs) such as ChatGPT etc. There are also ML systems that can analyse images and other data sets.
I have found ChatGPT to be very useful for making suggestions for improving blog posts. I don’t get it to write anything just ask for suggestions. It has pointed out things that I missed such as when I didn’t include the price when reviewing a car because the car in question was much more expensive than I will ever pay, the price wasn’t relevant to me but would be to some readers. It has also made useful suggestions about structure of blog posts, repeating points, and having a good conclusion. It has some downsides which include trying to erase my voice from my writing, suggesting that the rhetorical question “does email suck?” is unprofessional.
I have worked for a company that used ML systems to analyse driver performance and alert people if a driver is falling asleep, using a phone, or otherwise seems unable to drive safely. Their business model involved a human reviewing the images from the drivers the computer flagged and then determining who is actually doing the wrong thing. This seems a good use of the technology.
I have also worked for a company that used ML systems to analyse the performance of bank employees and detect potentially fraudulent behaviour. Preventing crime seems to be clearly a good thing and in this case the manager of the employee in question would review the evidence to make sure that they weren’t being falsely accused.
I don’t think that the problems with managing the changes that so called “AI” is introducing are particularly new. An example of how society handles change that’s worth considering is car safety. The seat belt first became mandatory for aeroplanes in some jurisdictions in 1928. The Model T Ford is widely regarded as the first vehicle to start a mass market for cars and it was released in 1925. So if society acted in a reasonable way then for the majority of mass market cars seat belts would have been a standard feature. However seat belts were first made compulsory in 1970 in Victoria Australia and there are still people who think that they are safer without seat belts! The delay in adoption of car seat belts is only one example of needless deaths caused by not taking reasonable measures for car safety but it’s one that’s easy to demonstrate and measure.
The difference between past problems like car safety and the current problems of “AI” is that the “AI” problems will be more pervasive. Most of my history as a car driver and car passenger was in cars that are much less safe than cars made in the last 10 years. But partly through luck I’ve never been in a serious crash so being in cars that wouldn’t have given me a low probability of surviving a freeway speed crash didn’t affect me. There is no possibility that through any combination of luck and skill someone could avoid the downsides of “AI”. If nothing else the results of elections will be affected and no-one can avoid that.
As a society we really need to address the real issues related to “AI” which in some cases requires legislation.
Related posts:
I’ve had some problems running apps I want on my Furilabs FLX1s [1], so I decided to install some container environments to test various versions. I started with Debian/Testing so I can test the build process for some packages I’m about to upload to Unstable.
When running debootstrap testing testing to setup the chroot the process aborted with errors including the following from the systemd postinst:
Failed to enable units: Protocol driver not attached. Cannot open '/etc/machine-id': Protocol driver not attached
This turned out to be from trying to run systemctl in the postinst, I just removed the “set -e” line from /chroot/testing/var/lib/dpkg/info/systemd.postinst and kept on going (I’m not planning to actually use systemd so it’s failure to setup wasn’t a problem).
Then I installed a bunch of -dev packages needed to build my package which had a dependency chain that included udev leading to the following error:
Setting up udev (260.1-1) ... Failed to chase and open directory '/etc/udev/hwdb.d', ignoring: Protocol driver not attached Failed to chase and open directory '/usr/lib/udev/hwdb.d', ignoring: Protocol driver not attached
Udev is also a part of systemd.
Googling for this turned up a closed systemd bug about this indicating that it has a minimum kernel version of 5.10 [2]. The Furiphone has kernel 4.19.325-furiphone-radon due to being based on Android.
Checking the kernel version isn’t that hard to do, if the systemd programs in question checked the version and reported “can’t run on kernels prior to 5.10 then it would avoid a lot of confusion – and also bug reports that the systemd developers don’t want.
Some Debian package dependencies can probably do with revision. Installing the packages “libkdb3-dev libkf5archive-dev qtdeclarative5-dev qtpositioning5-dev qttools5-dev” ideally wouldn’t have a dependency chain leading to udev.
The Furilabs people appear to have patched the latest Debian version of systemd to work with the older kernels, the version is currently 260.1-1+furios0+git20260425023744.8401044.forky.production.
I got this working by just editing every postinst script and either removing the “set -e” or adding an “exit 0” at the top, I don’t need things to be configured properly for a running OS I just need the files in the right locations for a container.
One issue I discovered when I started compiling is that it was only running on 1 core and the “nprocs” program was returning “1”. The “lscpu” program showed that only 1 of the 8 cores was online, it was a single Cortex-A78 core. Some combination of putting it in “caffeine mode” and having the screen on enabled all 6*Cortex-A55 and 2*Cortex-A78 cores.
The below table compares compiling Harbour-Amazfish on the Furiphone with all 8 CPU cores active, my E5-2696 v4 workstation (almost the fastest socket 2011-3 CPU ever made), running ARM64 software emulation on a system with two E5-2699A v4 CPUs, and a Radxa 8 core ARM SBC (which I will review in a future blog post).
Given that the source apparently limits the parallelism to less than 7 cores on average it’s pretty impressive for the elapsed time to be only 2.5* longer on the phone. Emulating the ARM64 build at about 4* the system CPU time is impressive too, as the system has 4.5* as many CPU cores it could theoretically compile ARM code faster than the native ARM hardware I own for any project that uses enough cores.
| System | User time | System time | Elapsed | %CPU |
|---|---|---|---|---|
| Furiphone | 2252.76 | 164.51 | 7:00.88 | 574 |
| E5-2696 v4 workstation | 679.64 | 119.07 | 1:58.63 | 673 |
| 2*22core Intel CPUs (qemu) | 8476.65 | 113.14 | 10:24.57 | 1375 |
| Radxa | 2011.45 | 239.40 | 6:25.55 | 583 |
Related posts:
Hot on the heels of the Copy Fail vulnerability [1] there is a new vulnerability Dirty Frag [2] (I linked to the Alma Linux page because it’s the first one I saw and it explains things well).
The test system was running kernel 6.19.14+deb14-amd64 and had the configuration after my last test of Copy Fail which was a default configuration with the following commands run:
semanage login -m -s user_u -r s0 __default__ restorecon -R -v -F /home semanage login -m -s root -r s0 root # logout and login again semodule -X 100 -r unconfined
I did a quick test on a Debian SE Linux system with a user running as user_t (which is often referred to as “strict policy”) and got the following result:
test@testing1:~/t$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Cloning into 'dirtyfrag'... remote: Enumerating objects: 26, done. remote: Counting objects: 100% (26/26), done. remote: Compressing objects: 100% (20/20), done. remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0) Receiving objects: 100% (26/26), 5.83 MiB | 11.47 MiB/s, done. Resolving deltas: 100% (9/9), done. dirtyfrag: failed (rc=1) test@testing1:~/t/dirtyfrag$ ./exp dirtyfrag: failed (rc=1)
I checked the audit log and saw the following:
# audit2allow -al #============= user_t ============== allow user_t self:rxrpc_socket create; allow user_t self:user_namespace create;
It seems that the rxrpc_socket access is the main thing.
I did a search for domains permitted to use that class on a system without unconfined domains and saw the following:
# sesearch -A -c rxrpc_socket
allow daemon init_t:rxrpc_socket { getattr getopt ioctl read setopt write };
allow devicekit_disk_t domain:rxrpc_socket getattr;
allow sosreport_t domain:rxrpc_socket getattr;
allow sysadm_t domain:rxrpc_socket getattr;
This configuration doesn’t appear to be vulnerable, at least to this form of the attack.
I reinstalled the unconfined policy with the following command and assigned it to the user test2 with the following commands:
semodule -X 100 -i /usr/share/selinux/default/unconfined.pp.bz2 semanage login -a -s unconfined_u test2 restorecon -R -v -F /home/test2
I then tested the exploit as user test2 and got the following result:
test2@testing1:~$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Cloning into 'dirtyfrag'... remote: Enumerating objects: 26, done. remote: Counting objects: 100% (26/26), done. remote: Compressing objects: 100% (20/20), done. remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0) Receiving objects: 100% (26/26), 5.83 MiB | 16.57 MiB/s, done. Resolving deltas: 100% (9/9), done. # id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 #
The kernel message log had the following lines from the time of the attack:
[ 1310.861545] Initializing XFRM netlink socket [ 1310.909048] alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni)) [ 1310.909935] alg: No test for echainiv(authencesn(hmac(sha256),cbc(aes))) (echainiv(authencesn(hmac-sha256-lib,cbc-aes-aesni))) [ 1318.353602] process 'su' launched '/bin/sh' with NULL argv: empty string added
It seems that we will be getting a lot of these so running SE Linux users as user_t is the right thing to do for servers and multi user systems.
Related posts:
After Copy Fail [CVE-2026-31431] from last week, the new Linux local root privilege escalations of today are Dirty Frag (Part 1) aka Copy Fail 2 [CVE-2026-43284] and Dirty Frag (Part 2) [CVE-2026-43500].
For those who can not update to linux >= 7.0.4-1 that was uploaded to sid and contains the needed fixes (backports for trixie are available in trixie-fastforward-backports), or are waiting for backports and updates to older Debian releases, or can’t reboot on short notice, mitigations might be needed.
Given the current trend, it seems we will see more of these bugs in the future. Therefore, I’ve uploaded a new package linux-vulnerability-mitigation to sid containing the mitigation for both Copy Fail and Dirty Frag (with debconf multiselect).
Until it passed NEW, it can also be downloaded from here:
The package is architecture independent, has no dependencies, and can be installed on any version of Debian or Debian derivative.
Update: Updated text above and descriptions in linux-vulnerability-mitigation for Dirty Frag Part 2 [CVE-2026-43500].
Welcome to our April 2026 report from the Reproducible Builds project!
Our reports outline what we’ve been up to over the past month, highlighting items of news from elsewhere in the increasingly-important area of software supply-chain security. As ever, if you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website.
In this month’s report, we cover:
An interesting post was published on Tor Project blog by Osservatorio Nessuno OdV this month on “stateless relays”. These are stateless, diskless operating systems that are designed to be used as Tor exit relays. According to the post, which is titled A Server That Forgets: Exploring Stateless Relays:
For relay operators, this approach raises the security bar by enforcing better behaviors by design: […]
- Reproducibility. A system that doesn’t change between reboots is easier to verify and, eventually, to reproduce and audit.
Furthermore, using a Trusted Platform Module (TPM), could allow for greater integrity in the future:
Transparency logs. Once you have a measured boot chain, you can publish it. A relay operator provides a recipe for a reproducible build; anyone can recompute the expected hash and verify it matches what the TPM reports. An append-only transparency log can make these attestations publicly auditable. The Tor community could run an independent monitor to track this across the relay fleet.
Congratulations to the Civil Infrastructure Platform (CIP) for reaching their 10-year anniversary last month. CIP has been a supporter of Reproducible Builds for many years, and we have collaborated on a number of technical issues that overlap. As Chris Lamb mentions in CIP’s press release:
The collaboration between the Reproducible Builds project and CIP highlights a critical shift in how we approach industrial software. Through verifiability, CIP ensures that the open source foundation of our critical infrastructure is not only sustainable but also demonstrably secure. This commitment to transparency is vital for the trust and resilience required by critical systems over decades of operation.”
Vagrant Cascadian and Chris Lamb hosted a table in the exposition hall at LinuxFest NorthWest 2026 this month in Bellingham, WA, USA, introducing many people to Reproducible Builds and answering questions both days of the conference.
In addition, Vagrant presented Beyond Trusting Open Source Software on Sunday afternoon, exploring the intersection of Free/Open Source Software, Reproducible Builds and Bootstrappable builds, and how they all reinforce each other. Vagrant’s slides are available online, including source code to build them reproducibly.
Reproducible Builds developer kpcyrd opened a ticket on the Rustsec issue tracker regarding binaries that deliberately inject random bytes into their binaries “as a secret seed for a Hash Collision DoS mitigation.”
As kpcyrd notes in his message, this causes issues for reproducibility, and because the relevant end-user binaries are “mostly distributed pre-compiled through package managers, those binaries (and by extension the secret seed) are public knowledge”. kpcyrd goes on to note:
This is somewhat unique to Rust because Python/JavaScript doesn’t compile binaries, and Go (to my knowledge) is too restrictive during build for any library to pull something like this.
In Arch Linux this month, Robin Candau and Mark Hegreberg worked at adding a new repro tag/version to the Arch Linux Docker images providing a bit-for-bit reproducible image. Robin also shared a related announcement and implementation details on our mailing list.
Arch Linux developer Robin Candau posted a blog post announcing that “Arch Linux Now Has a Bit-for-Bit Reproducible Docker Image”. Robin mentions one interesting caveat:
to ensure reproducibility, the
pacman[package manager] keys have to be stripped from the image, meaning thatpacmanis not usable out of the box in this image. While waiting to find a suitable solution to this technical constraint, we are therefore providing this reproducible image under a dedicated tag as a first milestone. […]
The blog post was also discussed on Hacker News.
In Debian this month, 24 reviews of Debian packages were added, 7 were updated and 16 were removed this month adding to our knowledge about identified issues.
Vagrant Cascadian performed Non-Maintainer Uploads (NMUs) in Debian for several packages with outstanding patches over a year old jakarta-jmeter, wxmplot, critcl, vcsh and magic-wormhole-transit-relay.
In addition, Reproducible Builds developer Jochen Sprickerhof filed a bug against the APT package manager to request that “APT should ignore [a] 0 epoch when downloading or installing with a version specifier”. This is related to the special-case handling of the optional epoch prefix in Debian package version numbers.
In NixOS, Julien Malka presented Lila: Decentralized Build Reproducibility Monitoring for the Functional Package Management Model, a paper written together with Arnout Engelen at the Mining Software Repositories (MSR) ACM conference, where it was awarded the MSR 2026 FOSS Impact Award. Congratulations!
Lastly, in openSUSE, Michael Schroeder added reproducibility verification support in the Open Build Service […] and Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.
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:
Bernhard M. Wiedemann:
Chris Lamb:
wapiti.mage.vim-youcompleteme.python-observabilityclient.gwcs.php-dompdf.supercell.gunicorn.fonts-spleen.geoalchemy2.rust-opam-file-rs.spaln.python-msgspec.golang-github-go-ini-ini.golang-github-deruina-timberjack.ruby-timers.node-yarnpkg.Jochen Sprickerhof:
Michael Schroeder:
Robin Candau:
Chris Lamb and Vagrant Cascadian:
Manuel Jacob
binutils (consider SOURCE_DATE_EPOCH when emitting static library archive header)
diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including preparing and uploading versions, 316, 317 and 318 to Debian.
Chris Lamb:
Holger Levsen:
ppc64el to the list of python3-guestfs architecture whitelist. (Closes: #1132974). […]In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 317.
Yet again, there were a number of improvements made to our website this month including:
Manuel Jacob:
.tar file portability […] and correct a section about .tar PAX headers […].Mattia Rizzolo:
kpcyrd:
ktecho:
On our mailing list this month:
Timo Pohl posted our list inviting people to “online group discussions with 4-6 participants each to talk about your perception of terms and requirements for reproducibility.” As Timo notes:
During our research of the existing literature, as well as my experience at the Reproducible Builds Summit 2025 in Vienna, we noticed that some of the terminology in the field is not used consistently across different groups of people, and that the precise meaning of some core terms like “reproducibility of an artifact” in itself is not uniform.
As Timo mentions, the sessions will last roughly 90 minutes and will be rewarded with 50€ per participant.
kpcyrd posted to the list asking for assistance with fixing an issue after updating the flake.lock file for their repro-env project.
Aman Sharma of the KTH Royal Institute of Technology, Sweden, posted to our list in order to share that Eric Cornelissen, a PhD student in KTH’s CHAINS group, is maintaining an open-source project to monitor the reproducibility of GitHub Actions:
The goal of the project is to assess whether GitHub Actions can be reproduced. Currently, it focuses on two types of Actions: JavaScript-based actions and Docker-based actions (composite actions are not considered). For JavaScript actions, the project rebuilds the distributed files and compares them bit-by-bit with the repository contents. For Docker actions, it rebuilds images from the
Dockerfileand checks for semantic equivalence, usingdiffoci, across builds.
Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
IRC: #reproducible-builds on irc.oftc.net.
Mastodon: @reproducible_builds@fosstodon.org
Mailing list: rb-general@lists.reproducible-builds.org
This was my hundred-forty-second 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:
I also did a week of front desk duties and started to work on backports of the cups CVEs.
This month I uploaded a new upstream versions:
Unfortunately the first upload of cups introduces a regression and another upload was needed to take care of a crash. The patch for one CVE also broke a test script, which is used by lots of printing packages in Debian. As a result some autopkgtest runs failed. This could be fixed as well and the only remaining issue that needs some more investigation is related to cups-pdf.
This work is generously funded by Freexian!
This month I continued to work on unifying packaging on Debian and Ubuntu. This makes it easier to work on those packages independent of the used platform.
I also started working on two new packages: lomiri-radio-app and lomiri-fretboardtrainer-app
This work is generously funded by Fre(i)e Software GmbH!
This month I uploaded a new upstream version or a bugfix version of:
This month I uploaded a new upstream version or a bugfix version of:
Marcos Talau joined the Debian IoT group, welcome aboard.
This month I uploaded a new upstream version or a bugfix version of:
This month I uploaded a new upstream version or a bugfix version of:
A feature on modern PCIe implementations is “Resizable BAR” AKA “REBAR”. This basically means that instead of allocating 256MB of address space for a PCIe device to have it’s memory mapped the device can ask for more, the limit can be 4G with some hardware or the combination of motherboard and expansion card can support 64bit addressing to allow the entire memory space of a GPU to be mapped in one region. Directly mapping all the memory will be faster no matter how things work, but a combination of algorithms optimised for a flat memory layout and overheads from remapping can cause 90% of performance to be lost without REBAR support. Some GPUs (or maybe the software driving them) will even refuse to work without it.
I believe that almost all hardware supporting DDR4 will support REBAR at a hardware level, but in many cases the BIOS doesn’t support it. There are people who have reflashed a system BIOS to add REBAR support and there are options to use a modified UEFI boot loader to replace the code that is used for mapping the GPU memory.
The systems I like to use are server grade tower systems with registered ECC RAM, after a few years they become quite cheap and still give decent performance while supporting large amounts of RAM. But many such systems that could support REBAR don’t, presumably because the vendor doesn’t have a great interest in supporting new uses of old hardware.
The HP Z640 and Z840 systems I’m running date from 2014 and give good performance with replacement CPUs that are cheap on ebay, but they don’t support REBAR without a flashed BIOS. The next release of those HP servers are the HP Z6 and Z8 Gen 4 systems from 2017 that have BIOS support for enabling REBAR.
The Lenovo Thinkstation Px20 (P520, P920, etc) don’t support REBAR which is especially disappointing as they were on sale from 2017 to 2022 and have decently fast CPUs. The replacement for the Px20 systems are the ones that are still on sale now and they seem likely to have REBAR support – but won’t be affordable on ebay.
The Dell PowerEdge T440 and R740 systems (and presumably all their servers from 2017) don’t support REBAR. There are no google hits for T550 and R750 systems from 2021, so presumably no complaints means that Dell servers from that era support it. But the T350 servers are junk and only take slow CPUs, and the T550 systems are brutally expensive. The Precision 5520 systems don’t support it and newer Precision workstations will get expensive.
It seems that HP is best for this.
The Z2 G4 only supports 64G of RAM so isn’t worth considering.
The Z4 G4 is low end and comes in two variants. The one with i5/i7/i9 CPUs doesn’t support ECC RAM so isn’t suitable for me, and that probably means most Z4 G4 systems on the market. The upside is that apparently 2*6pin PCIe power cables is standard so any size GPU should work and there are 8 DIMM slots supporting up to 512G of RAM. There are 3 options for PSU, 490w for 0 GPUs, 750W for 2 (small) GPUs, and 1000W for up to 4 GPUs.
The Z6 G4 has an option for a second CPU that almost no-one selects, that reduces the space for RAM so there’s only 6 DIMM slots. But as there is no option for a Z6 without ECC RAM every one on offer will be good.
The Z8 G4 is a nice dual socket system that I would not use for a serious GPU after my experience of my Z840 having a motherboard problem from a big GPU.
The Z4 G4 is going for about $500 on ebay with the 750W PSU, that is more than I want to pay but not a lot more. In 6 months they could be going for $350 or so. There are hardly any Z6 G4 systems on offer and they are all well over $1000 so I’m not considering them.
I need to poll the second hand sites for Z4 G4 systems and find one going cheap. One of those could be a good ML test machine for a while and then become a workstation once the faster CPUs (which are currently around $900) become cheap.
Related posts:
Review: Full Speed to a Crash Landing, by Beth Revis
| Series: | Chaotic Orbits #1 |
| Publisher: | DAW |
| Copyright: | August 2024 |
| ISBN: | 0-7564-1947-6 |
| Format: | Kindle |
| Pages: | 153 |
Full Speed to a Crash Landing is a science fiction novella and the first of a series. Beth Revis made the New York Times bestseller list for an earlier series of young adult science fiction novels, but somehow I had not heard of her before this series.
Ada Lamarr is a salvager. She picks up material from crashed or dead ships for resale. As the story opens, she has a large hole in the side of her ship, she's running out of oxygen, and the other ship nearby is refusing to answer her distress call. By the time they finally respond, there is barely enough time to get aboard before she is entirely out of air.
Ada's first-person narration drops hints that she may not be entirely what she seems. But then, neither is the Halifax, so it's only fair.
The captain of the Halifax treats Ada with a great deal of suspicion and wants her out of the way of their ongoing salvage operation. However, the captain does not appear to be entirely in charge. Ada is immediately struck by the mysterious Rian White, who seems to have some authority over their mission and is more thoughtful and calculating than the rest of the crew. He's also handsome, which doesn't hurt.
I was tempted to keep writing about the plot, but given the short length of this book, I should stop there and let you enjoy the twists and turns for yourself. This is a fun science fiction action romp: lots of banter, lots of tense moments, and a cagey first-person protagonist with an irrepressible sense of humor and a knack for brazening her way through conversations. It's not long on world-building (there isn't enough room), but Revis works in enough details to be intriguing and to set up some interesting motivations.
This is the sort of book that lives and dies by how much you like the protagonist, something that you will easily figure out by the end of an ebook sample if you're the sort of reader who uses those. Ada is irreverent, talkative, and very adroit at diverting attention (entertainingly) onto anything other than the critical piece of information other people are missing. If you want to, I suspect you could easily figure out most of what Ada is up to before the book reveals it explicitly. It's not that complicated, and the book isn't really trying to hide, although it doesn't give you all the necessary information in advance. Personally, I was happy to sit back and enjoy the ride.
There is no romance in this book beyond frequent comments from Ada that she would have liked there to be a romance in this book under different circumstances, but I will be surprised if that romance doesn't show up later in the series. Ada and Rian are clearly being set up as a pair. I didn't like Rian as much, mostly because he's less memorable as a character, but he comes into his own in the appendices after the plot proper.
I thought those concluding appendices were the best part of the novella and question the Kindle formatting decision to treat them like supplemental material. They purport to be a series of government memos, fill in a lot more of the backstory and world building, and have the best footnotes. Don't skip them!
This isn't the sort of book that I am inspired to immediately push into everyone's hands, but it's a fast, well-paced story that delivered a few reading sessions of entertainment. I'm not sure the political philosophy in the background makes a lot of sense, but at least not a standard stereotype of current politics seen in so much science fiction. It's going to set up some interesting character conflict in later books. I'm certainly intrigued enough to keep reading.
Recommended when you're in the mood for some fast-paced fun that's short and undemanding.
Followed by How to Steal a Galaxy.
Rating: 7 out of 10
So I am using Debian on a System76 Arm64 (aarch64) workstation since 9 months, and I can say: everything works. It should be noted that I use very few proprietary software, so I rely mostly on Debian packages for what I am doing. What I can say is basically all open source software which exists today, takes care to build on aarch64 or is available as a binary, either in the Debian archive, in a Flatpak or Snap, or in a Github Artefact. From 3D games, to Kubernetes tooling, practically everything open source is compiled for aarch64 Linux as well. Same thing for server software, every container image built is also proposing an aarch64 binary today.
I could also add a standard PCI Express Soundblaster sound card, and the kernel recognized it without issues.
The major downside I had was that Wayland is not working on my Nvidia GPU, whether with Nouveau or the proprietary drivers, thus I am using Gnome with X11. Also on the proprietary side, I missed the Discourse client, but I am not using that much, and those video meetings tool which popped up in the COVID time are perfectly usable in the browser.
The situation is for me much better than in the 2000s when I used a Mac Mini (powerpc) with Debian, where the need for a Flash player at that time really limited the amount of online content I could access.
What do I get using aarch64 you ask ? The main reason for me was the curiosity to use a non x86 arch, and to have a 80 core / 128 GB RAM machine to do a Lab in a Box with OpenShift running on OpenStack, with Ceph and a bit of local LLM inference thrown in. In the end I have enough labs at work, so that need disappeared, but I still enjoy having that amount of power in a rather quiet machine for a standard 80W consumption.
For a long time I’ve used Robert Collins’ testrepository (testr) to run tests in many of the projects I work on. It’s a small, focused tool built around a simple idea: decouple the running of tests from the recording and querying of their results.
The way it works is straightforward. A test runner emits a subunit stream — a compact binary protocol for test results — and testrepository stores those streams in a per-project .testrepository/ directory. Once results are in the repository, you can ask questions like “which tests failed in the last run?”, “re-run only the failures”, “what are the slowest tests?”, or “what changed between this run and the previous one?”.
The killer feature, for me, has always been the failing-test loop. When a big test suite breaks, you don’t want to re-run the whole thing after every fix — you want to iterate on just the failures, and only re-run the full suite once they’re all green. testrepository made that workflow ergonomic long before most language-specific test runners had anything comparable, and many of them still don’t have a good answer for it.
testrepository has served me well for over a decade, but it has been largely unmaintained for a while, and I had some ideas of improvements that I wanted to try out. So I wrote a Rust port, which has since grown a number of features of its own.
Inquest is a Rust port of testrepository that has since grown a number of features of its own. The binary is called inq.
The goals are deliberately modest:
Inquest reads and writes subunit v2 streams, so anything that can produce subunit (directly or via one of the many converters) can feed into it.
Inquest can usually figure out how to run your tests on its own. In a Rust, Python, Go or Node.js project:
$ cd my-project $ inq
Or if the auto-detection doesn’t work, you can ask it to generate a config file and then run the tests:
$ inq auto $ inq run
inq auto writes an inquest.toml describing how to invoke the test runner; inq run runs the tests, captures the subunit stream, and stores the results in a .inquest/ directory.
For a Rust project the generated config looks like:
test_command = "cargo subunit $IDOPTION" test_id_option = "--test $IDFILE" test_list_option = "--list"
After the first run, the usual queries work:
$ inq stats # repository-wide statistics $ inq last # results of the most recent run $ inq failing # only the failing tests $ inq slowest # the slowest tests in the last run $ inq run --failing # re-run only what failed last time
The last one is the workflow I use most often: run the full suite once, fix the obvious failures, then iterate on inq run --failing until the list is empty.
Some of the features that have grown in inquest beyond the original testrepository functionality:
Timeouts. --test-timeout, --max-duration, and --no-output-timeout will kill a test process that is hanging or has stopped producing output. --test-timeout auto derives a per-test timeout from the historical duration of that test, which is handy for catching tests that hang.
Once the test runner is killed, the test is marked as failed and the next test is started, so a broken test doesn’t hold up the whole suite.
Ordering --order can be used to run tests in a specific order, e.g. to run the slowest tests first, to run the tests that failed most recently first, or to run the widest variety of tests first to maximize the chance of finding a failure early on.
Live progress. inq running tails the in-progress subunit stream on disk and reports observed/expected test counts, percent complete, elapsed wall-clock time, and an ETA derived from each test’s historical duration. Useful when a CI run is taking longer than you’d like.
Flakiness ranking. inq flaky ranks tests by pass↔fail transitions in consecutive runs in which the test was recorded, so chronically broken tests rank low and genuinely flapping tests rank high.
Comparing runs. inq diff <A> <B> shows what changed between two test runs — newly failing, newly passing, and tests that flipped state — which makes it easy to see whether your last change actually fixed (or broke) anything.
Bisecting git history. inq bisect <TEST> drives git bisect to find the commit that broke a given test. It defaults the known-good and known-bad commits from the recorded run history (the most recent run where the test passed, and the most recent where it failed), so in the common case there is no need to remember either — just point it at the test name and let it work.
Richer run metadata. inq info shows the git commit, command line, duration, exit code, and concurrency for a run, with a flag for whether the working tree was dirty when the run started. Combined with inq diff this makes it much easier to triangulate when a regression was introduced.
Rerun a previous run verbatim. inq rerun <ID> re-runs exactly the tests of a previous run, in the same order, forwarding the same -- arguments that the original run used. inq rerun -1 repeats the latest.
Web based view. inq web serves a web-based view of the repository, with a dashboard of recent runs and detailed views of individual runs and tests.
Most of the time I drive inquest from the command line, but for browsing historical results of a large suite — spotting flapping tests, drilling into a single test’s run history, or just getting a visual sense of which parts of the suite are hurting — a web view is more pleasant. inq web starts a local server with exactly that:
$ inq web
The repository overview shows totals and a per-test history grid where each cell is one run, coloured by outcome. Bands of red make it easy to pick out tests that have been broken for a long time, and isolated red cells in an otherwise green column point at flaky tests.
Drilling into an individual test gives you its full run history, a duration sparkline, and per-run pass/fail status:
If you already have a .testrepository/ directory full of historical runs, inq upgrade will migrate it into the new .inquest/ format, with a progress bar for the impatient.
The legacy .testr.conf (INI) format is still understood, so existing projects don’t have to be converted to inquest.toml immediately — though the TOML format is preferred for new projects.
The source is on GitHub at jelmer/inquest. To install from source:
$ cargo install inquest
In a project with a Rust, Python, Go or Node.js test suite:
$ inq
Bug reports and patches are welcome.
Due to health reasons I did not have the energy to write individual status updates for February & March, so I’ll just combine them with the April update:
In February I cleaned out my GitHub account and moved all remaining projects to Codeberg. I archived the repositories on GitHub and added links to the new repositories on Codeberg. GitHub is a platform that is more and more frustrating to use. I still have to use it for my dayjob, though. The number of pull requests and issues that are written either by bots or by users that use bots increased in the last two years. Combined with that, GitHub provides a very low barrier for entitled users who do not want to contribute to a productive environment. GitHub now feels like the Twitter/X of git forges. Codeberg on the other hand is a community project. I feel a lot more at home there and the platform itself feels a lot more responsive than GitHub.
I took part in the DHD 2026 Conference in Vienna, including a hands-on workshop of the dhinfra project.
I released 0.60.0, 0.61.0 and 0.62.0 of apis-core-rdf. We rewrote the configuration format for the importer. We previously used TOML files, but that does not give us inheritance. So we now use simply Python classes as configuration format.
I implemented a new backend for our apis-bibsonomy Django package. The package is meant to provide a datamodel for storing reference data that links to Bibsonomy or Zotero. Given that we don’t use Bibsonomy anymore we now dropped the Bibsonomy backend but added a Zotero backend that allows to cache the entries locally.
We are very excited to announce that Debian has been assigned seven contributors to work under mentorship on a variety of projects with us during the Google Summer of Code.
Here is a list of the projects and contributors, along with details of the tasks to be performed.
Project: Automated Debian Packaging with debianize
Deliverables of the project: Debianize is a tool that aims to automatically create debian packages from scratch from upstream source trees. As for the current version, it works for some of the packages but it is not reliable. This project aims at making it production ready such that it can work with most of the projects. Along with that improving its reliability, coverage, integration with the broader ecosystem and other enhancements.
Project: Linux Livepatching
Deliverables of the project: Linux Kernel Livepatching is the process of replacing functions in the kernel code affected by CVEs with the patch-applied functions during system runtime. It's basically a method to apply security kernel patches to a running system.
Project: DebNet: Visualising the Bus Factor – Graph Analysis of Debian's Infrastructure
Deliverables of the project: DebNet models the Debian archive as a graph to identify critical packages maintained by too few people. Using data from the Ultimate Debian Database (UDD), it builds a package dependency graph and a maintainer-package graph to compute practical metrics like the Bus Factor, Fragility Score, and Dependency Impact for every source package.
Project: Attack of the Clones: Fight Back Using Code Duplication Detection From Security Patches
Deliverables of the project: This project aims to detect vulnerable code clones in the Debian archive by automatically extracting signatures from security patches. Using a two-signal approach that separates vulnerable patterns from fix patterns, the system generates high-specificity queries to search the entire archive via Debian CodeSearch.
Project: Debusine: debuginfod server
Deliverables of the project: This project implements a debuginfod-compatible server within Debusine to provide automated debug symbol resolution for Debian developers.
Project: Debian-LSP: Improve File Format Support
Deliverables of the project: The Debian LSP Language Server currently provides only basic features—field completion, parse-error diagnostics, and simple quick fixes—leaving Debian maintainers without the rich IDE experience available in other ecosystems.
Project: Debusine: live log streaming
Deliverables of the project: Debusine currently only shows task logs after a task has fully completed. This means developers working with long-running jobs (such as package builds or test pipelines) have no way to monitor progress in real time or catch failures early. This project adds live log streaming to Debusine.
Congratulations and welcome to all the contributors!
The Google Summer of Code program is possible in Debian thanks to the efforts of Debian Developers and Debian Contributors that dedicate part of their free time to mentor contributors and outreach tasks.
Join us and help extend Debian! You can follow the contributors' weekly reports on the debian-outreach mailing-list, chat with us on our IRC channel or reach out to the individual projects' team mailing lists.
The eight release of the binb package, and first in two years, is now on CRAN and in r2u. binb regroups four rather nice themes for writing LaTeX Beamer presentations much more easily in (R)Markdown. As a teaser, a quick demo combining all four themes is available; documentation and examples are in the package.
This release contains regular internal updates to continuous
integration, URLs reference and switch to Authors@R. The trigger for the
release, though, was a small updated need when very recent
pandoc versions (as shipped with RStudio) are used which
require a new variable declaration in the LaTeX template files in order
to process uncaptioned tables. The summary of changes follows.
Changes in binb version 0.0.8 (2026-05-01)
Small updates to documentation URLs and continuous integration
The package now uses Authors@R in DESCRIPTION
Newer pandoc versions are accommodated by adding a required counter variable in the latex template file
CRANberries provides a summary of changes to the previous version. For questions or comments, please use the issue tracker at the GitHub repo.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub. You can also sponsor my Tour de Shore 2026 ride in support of the Maywood Fine Arts Center.
A rainy day starts May.
The diffoscope maintainers are pleased to announce the release of diffoscope
version 318. This version includes the following changes:
[ Chris Lamb ]
* Upload to test PyPI integration.
* Bump Standards-Version to 4.7.4.
[ Manuel Jacob ]
* Remove a misleading comment.
You find out more by visiting the project homepage.
Last week, I attended MiniDebConf Campinas, and one of my favorites talks was "Salsa CI, showing features that almost nobody knows" by Aquila Macedo.
One of the things I learned is that we can easily build reverse dependencies using:
$ git push -o ci.variable="SALSA_CI_DISABLE_BUILD_REVERSE_DEPENDENCIES=0"I tried this option before uploading typer version 0.20.0-1:
This is an amazing feature. Thanks to everyone involved in making it happen!
I mentor several people in Debian, and have been repeatedly asked to offer an opportunity to ask questions on a live call. I have now started a recurring video call for exactly that, which I call Mentoring Mondays, and it is open for anyone aspiring to contribute to Debian, one of the oldest and most widely used Linux distributions.
Mentoring Mondays have already been happening for the past few Mondays, and this week we had a record 20 people on the call. During the calls so far we have had a demo of updating a package for a new upstream release using gbp, and of how to create a Merge Request on Salsa for a new upstream version. There is clearly a need for this, so I am announcing this now also on my blog, just as I have publicly announced that I offer mentoring for aspiring Debian contributors.
Mentoring Mondays is a recurring video call that lasts roughly 45 minutes with the agenda:
This is ideal for you if you:
.deb package at least once and want to do it betterThe call is mainly intended for those who want to contribute to Debian (or Debian derivatives, with Ubuntu being the most popular), but anyone can join to learn about things related to contributing to a Linux distribution. Please note that video chat uses Debian Social Jitsi. Joining the call requires authentication using a Salsa account, which anyone contributing to Debian should have anyway.
Calls are not recorded, so participants can chat freely, and are also encouraged to be on-camera for an enhanced sense of community.
Make sure you are logged into Salsa first, before opening the call on Debian’s Jitsi instance.
Please join the Matrix channel #mentoringmondays:matrix.debian.social if you plan to attend Mentoring Mondays. All future meeting times will be announced there. It is also the channel to post questions about Debian packaging to be answered during the call.
The current meeting time is friendly to people in Europe, Asia and Australian time zones, and will repeat at the same time slot on:
Starting in mid-June the meeting time will change to accommodate participation in different time zones.
Feel free to extend the invite to anyone you think might be interested in joining!
If you mention this on social media, please post using tag #mentoringmondays, or simply boost the existing posts on the social media of your preference: Mastodon, Lemmy, Reddit, Bluesky, LinkedIn, Farcaster, X.
A big thanks to Jason Kregting for helping organize. I would also like to thank in advance all the Debian Developers who are able to join the call and be available to participate in discussions and help answer questions.
