April 14, 2026

Russell Coker

Furilabs FLX1s Finally Working

I’ve been using the Furilabs FLX1s phone [1] as my daily driver for 6 weeks, it’s a decent phone, not as good as I hoped but good enough to use every day and rely on for phone calls about job interviews etc. I intend to keep using it as my main phone and as a platform to improve phone software in Debian as you really can’t effectively find bugs unless you use the platform for important tasks.

Support Problems

I previously wrote about the phone after I received it without a SIM caddy on the 13th of Jan. I had a saga with support about this, on the 16th of Jan one support person said that they would ship it immediately but didn’t provide a tracking number or any indication of when it would arrive. On the 5th of Feb I contacted support again and asked how long it would be, the new support person seemed to have no record of my previous communication but said that they would send it. On the 17th of Feb I made another support request including asking for a way of direct communication as the support email came from an address that wouldn’t accept replies, I was asked for a photo showing where the problem is. The support person also said that they might have to send a replacement phone!

The last support request I sent included my disappointment at the time taken to resolve the issue and the proposed solution of replacing the entire phone (why have two international shipments of a fragile and expensive phone when a single letter with a cheap SIM caddy would do?). I didn’t receive a reply but the SIM caddy arrived on the 2nd of Mar. Here is a pic of the SIM caddy and the package it came in:

One thing that should be noted is that some of the support people seemed to be very good at their jobs and they were all friendly. It was the system that failed here, turning a minor issue of a missing part into a 6 week saga.

Furilabs needs to do the following to address this issue:

Make it possible to reply directly to a message from a support person. Accept email with a custom subject to sort it, give a URL for a web form, anything. Collating discussions with a customer allows giving better support while taking less time for the support people.
Have someone monitor every social media address that is used by the company. When someone sends a support request in a public Mastodon post it indicates that something has gone wrong and you want to move quickly to resolve it.
Take care of the little things, like sending a tracking number for every parcel. If it’s something too small for a parcel (the SIM caddy could have fit in a regular letter) then just tell the customer what date it was posted and where it was posted from so they have some idea of when it will arrive.

This is not just a single failure of Furilabs support, it’s a systemic failure of their processes.

Problems I Will Fix – Unless Someone Beats Me to it

Here are some issues I plan to work on.

Smart Watch Support

I need to port one of the smart watch programs to Debian. Also I want to make one of them support the Colmi P80 [2].

A smart watch significantly increases the utility of a phone even though IMHO they aren’t doing nearly all the things that they could and should do. When we get Debian programs talking to the PineTime it will make a good platform for development of new smart phone and OS features.

Nextcloud

I have ongoing issues of my text Nextcloud installation on a Debian VM not allowing connection from the Linux desktop app (as packaged in Debian) and from the Android client (from f-droid). The desktop client works with a friend’s Nextcloud installation on Ubuntu so I may try running it on an Ubuntu VM I run while waiting for the Debian issue to get resolved. There was a bug recently fixed in Nextcloud that appears related so maybe the next release will fix it.

For the moment I’ve been running without these features and I call and SMS people from knowing their number or just returning calls. Phone calls generally aren’t very useful for me nowadays except when applying for jobs. If I could deal with recruiters and hiring managers via video calls then I would consider just not having a phone number.

Wifi IPv6

Periodically IPv6 support just stops working, I can’t ping the gateway. I turn wifi off and on again and it works. This might be an issue with my wifi network configuration. This might be an issue with the way I have configured my IPv6 networking, although that problem doesn’t happen with any of my laptops.

Chatty Sorting

Chatty is the program for SMS that is installed by default (part of the phosh/phoc setup), it also does Jabber. Version 0.8.7 is installed which apparently has some Furios modifications and it doesn’t properly support sorting SMS/Jabber conversations. Version 0.8.9 from Debian sorts in the same way as most SMS and Jabber programs with the most recent at the top. But the Debian version doesn’t support Jabber (only SMS and Matrix). When I went back to the Furilabs version of Chatty it still sorted for a while but then suddenly stopped. Killing Chatty (not just closing the window and reopening it) seems to make it sort the conversations sometimes.

Problems for Others to Fix

Here are the current issues I have starting with the most important.

Important

The following issues seriously reduce the usability of the device.

Hotspot

The Wifi hotspot functionality wasn’t working for a few weeks, this Gitlab issue seems to match it [3]. It started working correctly for a day and I was not sure if an update I applied fixed the bug or if it’s some sort of race condition that worked for this boot and will return next time I reboot it. Later on I rebooted it and found that it’s somewhat random whether it works or now.

Also while it is mostly working it seemed to stop working about every 25 minutes or so and I had to turn it off and on again to get it going.

On another day it went to a stage where it got repeated packet loss when I pinged the phone as a hotspot from my laptop. A pattern of 3 ping responses and 3 “Destination Host Unreachable” messages was often repeated.

I don’t know if this is related to the way Android software is run in a container to access the hardware.

4G Reliability

Sometimes 4G connectivity has just stopped, sometimes I can stop and restart the 4G data through software to fix it and sometimes I need to use the hardware switch. I haven’t noticed this for a week or two so there is a possibility that one fix addressed both Hotspot and 4G.

One thing that I will do is setup monitoring to give an alert on the phone if it can’t connect to the Internet. I don’t want it to just quietly stop doing networking stuff and not tell me!

On-screen Keyboard

The compatibility issues of the GNOME and KDE on-screen keyboards are getting me. I use phosh/phoc as the login environment as I want to stick to defaults at first to not make things any more difficult than they need to be. When I use programs that use QT such as Nheko the keyboard doesn’t always appear when it should and it forgets the setting for “word completion” (which means spelling correction).

The spelling correction system doesn’t suggest replacing “dont” with “don’t” which is really annoying as a major advantage for spelling checkers on touch screens is inserting an apostrophy. An apostrophy takes at least 3* longer than a regular character and saving that delay makes a difference to typing speed.

The spelling correction doesn’t correct two words run together.

Medium Priority

These issues are ongoing annoyances.

Delay on Power Button

In the best case scenario this phone has a much slower response to pressing the power button than the Android phones I tested (Huawei Mate 10 Pro and Samsung Galaxy Note 9) and a much slower response than my recollection of the vast majority of Android phones I’ve ever used. For testing pressing buttons on the phones simultaneously resulted in the Android phone screens lighting up much sooner. Something like 200ms vs 600ms – I don’t have a good setup to time these things but it’s very obvious when I test.

In a less common case scenario (the phone having been unused for some time) the response can be something like 5 seconds. The worst case scenario is something in excess of 20 seconds.

For UI designers, if you get multiple press events from a button that can turn the screen on/off please make your UI leave the screen on and ignore all the stacked events. Having the screen start turning on and off repeatedly when the phone recovers and processes all the button presses isn’t good, especially when each screen flash takes half a second.

Notifications

Touching on a notification for a program often doesn’t bring it to the foreground. I haven’t yet found a connection between when it does and when it doesn’t.

Also the lack of icons in the top bar on the screen to indicate notifications is annoying, but that seems to be an issue of design not the implementation.

Charge Delay

When I connect the phone to a power source there is a delay of about 22 seconds before it starts to charge. Having it miss 22 seconds of charge time is no big deal, having to wait 22 seconds to be sure it’s charging before leaving it is really annoying. Also the phone makes an audible alert when it gets to 0% charge which woke me up one night when I had failed to push the USB-C connector in hard enough. This phone requires a slightly deeper connector than most phones so with some plugs it’s easy to not quite insert them far enough.

Torch aka Flash

The light for the “torch” or flash for camera is not bright at all. In a quick test staring into the light from 40cm away wasn’t unpleasant compared to my Huawei Mate 10 Pro which has a light bright enough that it hurts to look at it from 4 meters away.

Because of this photos at night are not viable, not even when photographing something that’s less than a meter away.

The torch has a brightness setting which doesn’t seem to change the brightness, so it seems likely that this is a software issue and the brightness is set at a low level and the software isn’t changing it.

Audio

When I connect to my car the Lollypop player starts playing before the phone directs audio to the car, so the music starts coming from the phone for about a second. This is an annoying cosmetic error. Sometimes audio playing pauses for no apparent reason.

It doesn’t support the phone profile with Bluetooth so phone calls can’t go through the car audio system. Also it doesn’t always connect to my car when I start driving, sometimes I need to disable and enable Bluetooth to make it connect.

When I initially set the phone up Lollypop would send the track name when playing music through my car (Nissan LEAF) Bluetooth connection, after an update that often doesn’t happen so the car doesn’t display the track name or whether the music is playing but the pause icon works to pause and resume music (sometimes it does work).

About 30 seconds into a phone call it switches to hands-free mode while the icon to indicate hands-free is not highlighted, so I have to press the hands-free button twice to get it back to normal phone mode.

Low Priority

I could live with these things remaining as-is but it’s annoying.

Ticket Mode

There is apparently some code written to display tickets on screen without unlocking. I want to get this working and store screen-caps of the Android barcode screens of the different loyalty cards so I can scan them without unlocking. My threat model does not include someone trying to steal my phone to get a free loaf of bread on the bakery loyalty program.

Camera

The camera app works with both the back and front cameras, which is nice, and sadly based on my experience with other Debian phones it’s noteworthy. The problem is that it takes a long time to take a photo, something like a second after the button is pressed – long enough for you to think that it just silently took a photo and then move the phone.

The UI of the furios-camera app is also a little annoying, when viewing photos there is an icon at the bottom left of the screen for a video camera and an icon at the bottom right with a cross. Which every time makes me think “record videos” and “leave this screen” not “return to taking photos” and “delete current photo”. I can get used to the surprising icons, but being so slow is a real problem.

GUI App Installation

The program for managing software doesn’t work very well. It said that there were two updates for Mesa package needed, but didn’t seem to want to install them. I ran “flatpak update” as root to fix that. The process of selecting software defaults to including non-free, and most of the available apps are for desktop/laptop with no way to search for phone/tablet apps.

Generally I think it’s best to just avoid this and use apt and flatpak directly from the command-line. Being able to ssh to my phone from a desktop or laptop is good!

Android Emulation

The file /home/furios/.local/share/andromeda/data/system/uiderrors.txt is created by the Andromeda system which runs Android apps in a LXC container and appears to grow without end. After using the phone for a month it was 3.5G in size. The disk space usage isn’t directly a problem, out of the 110G storage space only 17G is used and I don’t have a need to put much else on it, even if I wanted to put backups of /home from my laptop on it when travelling that would still leave plenty of free space. But that sort of thing is a problem for backing up the phone and wasting 3.5G out of 110G total is a fairly significant step towards breaking the entire system.

Also having lots of logging messages from a subsystem that isn’t even being used is a bad sign.

I just tried using it and it doesn’t start from either the settings menu or from the f-droid icon. Android isn’t that important to me as I want to get away from the proprietary app space so I won’t bother trying this any more.

Unfixable Problems

Unlocking

After getting used to fingerprint unlocking going back to a password is a pain. I think that the hardware isn’t sufficient for modern quality face recognition that can’t be fooled by a photo and there isn’t fingerprint hardware.

When I first used an Android phone using a pin to unlock didn’t seem like a big deal, but after getting used to fingerprint unlock it’s a real drag to go without. This is a real annoyance when doing things like checking Wikipedia while watching TV.

This phone would be significantly improved with a fingerprint sensor or a camera that worked well enough for face unlock.

Plasma Mobile

According to Reddit Plasma Mobile (KDE for phones) doesn’t support Halium and can never work on this phone because of it [4]. This is one of a number of potential issues with the phone, running on hardware that was never designed for open OSs is always going to have issues.

Wifi MAC Address

The MAC keeps changing on reboot so I can’t assign a permanent IPv4 address to the phone. It appears from the MAC prefix of 00:08:22 that the network hardware is made in InPro Comm which is well known for using random addresses in the products it OEMs. They apparently have one allocation of 2^24 addresses and each device randomly chooses a MAC from that range on boot.

In the settings for a Wifi connection the “Identity” tab has a field named “Cloned Address” which can be set to “Stable for SSID” that prevents it from changing and allows a static IP address allocation from DHCP. It’s not ideal but it works.

Network Manager can be configured to have a permanent assigned MAC address for all connections or for just some connections. In the past for such things I have copied MAC addresses from ethernet devices that were being discarded and used them for such things. For the moment the “Stable for SSID” setting does what I need but I will consider setting a permanent address at some future time.

Docks

Having the ability to connect to a dock is really handy. The PinePhonePro and Librem5 support it and on the proprietary side a lot of Samsung devices do it with a special desktop GUI named Dex and some Huawei devices also have a desktop version of the GUI. It’s unfortunate that this phone can’t do it.

The Good Things

It’s good to be able to ssh in to my phone, even if the on-screen keyboard worked as well as the Android ones it would still be a major pain to use when compared to a real keyboard. The phone doesn’t support connecting to a dock (unlike Samsung phones I’ve used for which I found Dex to be very useful with a 4K monitor and proper keyboard) so ssh is the best way to access it.

This phone has very reliable connections to my home wifi. I’ve had ssh sessions from my desktop to my phone that have remained open for multiple days. I don’t really need this, I’ve just forgotten to logout and noticed days later that the connection is still running. None of the other phones running Debian could do that.

Running the same OS on desktop and phone makes things easier to test and debug.

Having support for all the things that Linux distributions support is good. For example none of the Android music players support all the encodings of audio that comes from YouTube so to play all of my music collection on Android I would need to transcode most of them which means either losing quality, wasting storage space, or both. While Lollypop plays FLAC0, mp3, m4a, mka, webm, ogg, and more.

Conclusion

This is a step towards where I want to go but it’s far from the end goal.

The PinePhonePro and Librem5 are more open hardware platforms which have some significant benefits. But the battery life issues make them unusable for me.

Running Mobian on a OnePlus 6 or Droidian on a Note 9 works well for the small tablet features but without VoLTE. While the telcos have blocked phones without VoLTE data devices still work so if recruiters etc would stop requiring phone calls then I could make one of them an option.

The phone works well enough that it could potentially be used by one of my older relatives. If I could ssh in to my parents phones when they mess things up that would be convenient.

I’ve run this phone as my daily driver since the 3rd of March and it has worked reasonably well. 6 weeks compared to my previous use of the PinePhonePro for 3 days. This is the first time in 15 years that a non-Android phone has worked for me personally. I have briefly used an iPhone 7 for work which basically did what it needed to do, it was at the bottom of the pile of unused phones at work and I didn’t want to take a newer iPhone that could be used by someone who’s doing more than the occasional SMS or Slack message.

So this is better than it might have been, not as good as I hoped, but a decent platform to use it while developing for it.

14 April, 2026 09:31AM by etbe

Ravi Dwivedi

Hungary Visa

The annual LibreOffice conference 2025 was held in Budapest, Hungary, from the 3rd to the 6th of September 2025. Thanks to the The Document Foundation (TDF) for sponsoring me to attend the conference.

As Hungary is a part of the Schengen area, I needed a Schengen visa to attend the conference. In order to apply for a Schengen visa, one needs to get an appointment at VFS Global and submit all the required documents there, which are then forwarded to the embassy.

I got an appointment for a Hungary visa at VFS Global in New Delhi for the 24th of July. There were many appointment slots available for the Hungary visa. One could easily get an appointment for the next day at the Delhi center. There were some technical problems on the VFS website, though, as I was unable to upload a scanned copy of my passport while booking the appointment. I got an error saying, “Unfortunately, you have exceeded the maximum upload limit.”

The problem didn’t get fixed even after contacting the VFS helpline. They asked me to try in the Firefox browser and deleting all the cache, which I already did.

So I created another account with a different email address and phone number, after which I was able to upload my passport and book an appointment. Other conference attendees from India also reported facing some technical issues on the VFS Hungary website.

Anyway, I went to the VFS Hungary application center as per my appointment on the 24th of July. Going inside, I located the Hungary visa application counter. There were two applicants ahead of me.

When it was my turn, the VFS staff warned me that my passport was damaged. The “damage” was on the bio-data page. All the details could be seen, but the lamination of the details page wore off a bit. They asked me to write an application to the Embassy of Hungary in New Delhi stating that I insist VFS to submit my application along with describing the “damage” on my passport.

I got a bit worried about my application getting rejected due to the “damage.” But I decided to gamble my money on this one, as I didn’t have time (and energy) to apply for a new passport before this trip.

Moreover, I had struck down a couple of fields in my visa application form which were not applicable to me, due to which the VFS staff asked me to fill out another visa application.

After this, the application got submitted, and it was 11,000 INR (including the fee to book the appointment at VFS). Here is the list of documents I submitted:

My passport
Photocopy of my passport
Two photographs of myself
Duly filled visa application form
Return flight ticket reservations
Payslips for the last three months
Invitation letter from the conference organizer (in Hungarian)
Proof of hotel bookings during my stay in Hungary
Cover letter stating my itinerary
Income tax returns filed by me
Bank account statement, signed and sealed by the bank
Travel insurance valid for the period of the entire trip

It took 2 hours for me to submit my visa application, even though there were only two applicants before me. This was by far the longest time to submit a Schengen visa application for me.

Fast-forward to the 30th of July, and I received an email from the Embassy of Hungary asking me to submit an additional document - paid air ticket - for my application. I had only submitted dummy flight tickets, and they were enough for the Schengen visas I applied for until now. This was the first time a country was asking me to submit a confirmed flight ticket during the visa process.

I consulted my travel agent on this, and they were fairly confident that I will get the visa if the embassy is asking me to submit confirmed flight tickets. So I asked the travel agent to book the flight tickets. These tickets were ₹78,000, and the airline was Emirates. Then, I sent the flight tickets to the embassy by email.

The embassy sent the visa results on the 6th of August, which I received the next day.

My visa had been approved! It took 14 days for me to get the Hungary visa after submitting the application.

See you in the next one!

Thanks to Badri for proofreading.

14 April, 2026 05:50AM

April 12, 2026

Dirk Eddelbuettel

littler 0.3.23 on CRAN: Mostly Internal Fixes

max-heap image

The twentyfourth release of littler as a CRAN package landed on CRAN just now, following in the now twenty-one year history (!!) as a (initially non-CRAN) package started by Jeff in 2006, and joined by me a few weeks later.

littler is the first command-line interface for R as it predates Rscript. It allows for piping as well for shebang scripting via #!, uses command-line arguments more consistently and still starts faster. It also always loaded the methods package which Rscript only began to do in later years.

littler lives on Linux and Unix, has its difficulties on macOS due to some-braindeadedness there (who ever thought case-insensitive filesystems as a default were a good idea?) and simply does not exist on Windows (yet – the build system could be extended – see RInside for an existence proof, and volunteers are welcome!). See the FAQ vignette on how to add it to your PATH. A few examples are highlighted at the Github repo:, as well as in the examples vignette.

This release, which comes just two months after the previous 0.3.22 release that brought a few new features, is mostly internal. (The previous release erroneously had 0.3.23 in its blog and social media posts, it really was 0.3.22 and this one now is is 0.3.23.) Mattias Ellert address a nag (when building for a distribution) about one example file with a shebang not have excutable modes. I accommodated the ever-changing interface the C API of R (within about twelve hours of being notified). A few other smaller changes were made as well polishing a script or two or usual, see below for more.

The full change description follows.

Changes in littler version 0.3.23 (2026-04-12)

Changes in examples scripts

Correct spelling in installGithub.r to lower-case h

The r2u.r now recognises ‘resolute’ aka 26.06

installRub.r can install (more easily) from r-multiverse

A file permission was corrected (Mattias Ellert in #131)

Changes in package

Update script count and examples in README.md

Continuous intgegration scripts received minor updates

The C level access to the R API was updated to reflect most recent standards (Dirk in #132)

My CRANberries service provides a comparison to the previous release. Full details for the littler release are provided as usual at the ChangeLog page, and also on the package docs website. The code is available via the GitHub repo, from tarballs and now of course also from its CRAN page and via install.packages("littler"). Binary packages are available directly in Debian as well as (in a day or two) Ubuntu binaries at CRAN thanks to the tireless Michael Rutter. Comments and suggestions are welcome 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.

12 April, 2026 02:47PM

Colin Watson

Free software activity in March 2026

My Debian contributions this month were all sponsored by Freexian.

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

OpenSSH

I fixed CVE-2026-3497 in unstable, thanks to a fix in Ubuntu by Marc Deslauriers. Relatedly, I applied an Ubuntu patch by Athos Ribeiro to not default to weak GSS-API exchange algorithms.

I’m looking forward to being able to split out GSS-API key exchange support in OpenSSH once Ubuntu 26.04 LTS has been released! This stuff will still be my problem, but at least it won’t be in packages that nearly everyone has installed.

Python packaging

New upstream versions:

dill
django-modeltranslation
isort
langtable
pathos
pendulum
pox
ppft
pydantic-extra-types
pytango
python-asyncssh
python-datamodel-code-generator
python-evalidate
python-packaging (including fixes for python-hatch-requirements-txt and python-pyproject-examples)
python-zxcvbn-rs-py
rpds-py
smart-open
trove-classifiers

I packaged pybind11-stubgen, needed for new upstream versions of pytango. Tests of reproducible builds revealed that it didn’t generate imports in a stable order; I contributed a fix for that upstream.

I worked with the security team to release DSA-6161-1 in multipart, fixing CVE-2026-28356 (upstream discussion). (Most of the work for this was in February, but the vulnerability was still embargoed when I published my last monthly update.)

In trixie-backports, I updated pytest-django to 4.12.0.

I fixed a number of packages to support building with pyo3 0.28:

pendulum
pydantic-core
python-jellyfish
python-zxcvbn-rs-py
rpds-py

Other build/test failures:

Rust packaging

New upstream versions:

rust-rpds

Other bits and pieces

I upgraded tango to 10.1.2, and yubihsm-shell to 2.7.2.

Code reviews

python-backports.zstd: Obsolete with Python 3.14 (sponsored partial fix from YOKOTA Hiroshi)

12 April, 2026 10:13AM by Colin Watson

Vasudev Kamath

Hardening the Unpacakgeable: A systemd-run Sandbox for Third-Party Binaries

The Shift in Software Consumption

Historically, I have been a "distribution-first" user. Sticking to tools packaged within the Debian archives provides a layer of trust; maintainers validate licenses, audit code, and ensure the entire dependency chain is verified. However, the rapid pace of development in the Generative AI space—specifically with new tools like Gemini-CLI—has made this traditional approach difficult to sustain.

Many modern CLI tools are built within the npm or Python ecosystems. For a distribution packager, these are a nightmare; packaging a single tool often requires packaging a massive, shifting dependency chain. Consequently, I found myself forced to use third-party binaries, bypassing the safety of the Debian archive.

The Supply Chain Risk

Recent supply chain attacks affecting widely used packages like axios and LiteLLM have made it clear: running unvetted binaries on a personal system is a significant risk. These scripts often have full access to your $HOME directory, SSH keys, and the system D-Bus.

After discussing these concerns with a colleague, I was inspired by his approach—using a Flatpak-style sandbox for even basic applications like Google Chrome. I decided to build a generalized version of this using OpenCode and Qwen 3.6 Fast (which was available for free use at the time) to create a robust, transient sandbox utility.

The Solution: safe-run-binary

My script, safe-run-binary, leverages systemd-run to execute binaries within an isolated scope. It implements strict filesystem masking and resource control to ensure that even if a dependency is compromised, the "blast radius" is contained.

Key Technical Features

1. Virtualized Home Directory (tmpfs)

Instead of exposing my real home directory, the script mounts a tmpfs over $HOME. It then selectively creates and bind-mounts only the necessary subdirectories (like .cache or .config) into a virtual structure. This prevents the application from ever "seeing" sensitive files like ~/.ssh or ~/.gnupg.

2. D-Bus Isolation via xdg-dbus-proxy

For GUI applications, providing raw access to the D-Bus is a security hole. The script uses xdg-dbus-proxy to sit between the application and the system bus. By using the --filter and --talk=org.freedesktop.portal.* flags, the app can only communicate with necessary portals (like the file picker) rather than sniffing the entire bus.

3. Linux Namespace Restrictions

The sandbox utilizes several systemd execution properties to harden the process:

RestrictNamespaces=yes: For CLI tools, this prevents the app from creating its own nested namespaces.
PrivateTmp=yes: Ensures a private /tmp space that isn't shared with the host.
NoNewPrivileges=yes: Prevents the binary from gaining elevated permissions through SUID/SGID bits.

4. GPU and Audio Passthrough

The script intelligently detects and binds Wayland, PipeWire, and NVIDIA/DRI device nodes. This allows browsers like Firefox to run with full hardware acceleration and audio support while remaining locked out of the rest of the filesystem.

Usage

To run a CLI tool like Gemini-CLI with access only to a specific directory:

safe-run-binary -b ~/.gemini-config -- npx @google/gemini-cli

For a GUI application like Firefox:

safe-run-binary --gui -b ~/.mozilla -b ~/.cache/mozilla -b ~/Downloads -- firefox

Conclusion

While it is not always possible to escape the need for third-party software, it is possible to control the environment in which it operates. By leveraging native Linux primitives like systemd and namespaces, high-grade isolation is achievable.

PS: If you spot any issues or have suggestions for improving the script, feel free to raise a PR on the repo.

12 April, 2026 07:23AM by copyninja

Russ Allbery

Review: The Teller of Small Fortunes

Review: The Teller of Small Fortunes, by Julie Leong

Publisher:	Ace
Copyright:	November 2024
ISBN:	0-593-81590-4
Format:	Kindle
Pages:	324

The Teller of Small Fortunes is a cozy found-family fantasy with a roughly medieval setting. It was Julie Leong's first novel.

Tao is a traveling teller of small fortunes. In her wagon, pulled by her friendly mule Laohu, she wanders the small villages of Eshtera and reads the trivial fortunes of villagers in the tea leaves. An upcoming injury, a lost ring, a future kiss, a small business deal... she looks around the large lines of fate and finds the small threads. After a few days, she moves on, making her solitary way to another village.

Tao is not originally from Eshtera. She is Shinn, which means she encounters a bit of suspicion and hostility mixed with the fascination of the exotic. (Language and culture clues lead me to think Shinara is intended to be this world's not-China, but it's not a direct mapping.) Tao uses the fascination to help her business; fortune telling is more believable from someone who seems exotic. The hostility she's learned to deflect and ignore. In the worst case, there's always another village.

If you've read any cozy found-family novels, you know roughly what happens next. Tao encounters people on the road and, for various reasons, they decide to travel together. The first two are a massive mercenary (Mash) and a semi-reformed thief (Silt), who join Tao somewhat awkwardly after Tao gives Mash a fortune that is far more significant than she intended. One town later, they pick up an apprentice baker best known for her misshapen pastries. They also collect a stray cat, because of course they do. It's that sort of book.

For me, this sort of novel lives or dies by the characters, so it's good news that I liked Tao and enjoyed spending time with her. She's quiet, resilient, competent, and self-contained, with a difficult past and some mysteries and emotions the others can draw over time. She's also thoughtful and introspective, which means the tight third-person narration that almost always stays on Tao offers emotional growth to mull over. I also liked Kina (the baker) and Mash; they're a bit more obvious and straightforward, but Kina adds irrepressible energy and Mash is a good example of the sometimes-gruff soldier with a soft heart. Silt was a bit more annoying and I never entirely warmed to him, but he's tolerable and does get a bit of much-needed (if superficial) character development.

It takes some time for the reader to learn about the primary conflict of the story (Tao does not give up her secrets quickly), so I won't spoil it, but I thought it worked well. I was momentarily afraid the story would develop a clear villain, but Leong has some satisfying alternate surprises in store. The ending was well-done, although it is very happily-ever-after in a way that may strike some readers as too neat. The Teller of Small Fortunes aims for a quiet and relaxed mood rather than forcing character development through difficult choices; it's a fine aim for a novel, but it won't match everyone's mood.

I liked the world-building, although expect small and somewhat disconnected details rather than an overarching theory of magic. Tao's ability gets the most elaboration, for obvious reasons, and I liked how Leong describes it and explores its consequences. Most of the attention in the setting is on the friction, wistfulness, and small reminders of coming from a different culture than everyone around you, but so long ago that you are not fully a part of either world. This, I thought, was very well-done and is one of the places where the story is comfortable with complex feelings and doesn't try to reach a simplifying conclusion.

There is one bit of the story that felt like it was taken directly out of a Dungeons & Dragons campaign to a degree that felt jarring, but that was the only odd world-building note.

This book felt like a warm cup of tea intended to comfort and relax, without large or complex thoughts about the world. It's not intended to be challenging; there are a few plot twists I didn't anticipate, but nothing that dramatic, and I doubt anyone will be surprised by the conclusions it reaches. It's a pleasant time with some nice people and just enough tension and mystery to add some motivation to find out what happens next. If that's what you're in the mood for, recommended. If you want a book that has Things To Say or will put you on the edge of your seat, maybe save this one for another mood.

All the on-line sources I found for this book call it a standalone, but The Keeper of Magical Things is set in the same world, so I would call it a loose series with different protagonists. The Teller of Small Fortunes is a complete story in one book, though.

Rating: 7 out of 10

12 April, 2026 02:53AM

April 10, 2026

Reproducible Builds

Reproducible Builds in March 2026

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

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

Linux kernel hash-based integrity checking proposed

Eric Biggers posted to the Linux Kernel Mailing List in response to a patch series posted by Thomas Weißschuh to introduce a calculated hash-based system of integrity checking to complement the existing signature-based approach. Thomas’ original post mentions:

The current signature-based module integrity checking has some drawbacks in combination with reproducible builds. Either the module signing key is generated at build time, which makes the build unreproducible, or a static signing key is used, which precludes rebuilds by third parties and makes the whole build and packaging process much more complicated.

However, Eric’s followup message goes further:

I think this actually undersells the feature. It’s also much simpler than the signature-based module authentication. The latter relies on PKCS#7, X.509, ASN.1, OID registry, crypto_sig API, etc in addition to the implementations of the actual signature algorithm (RSA / ECDSA / ML-DSA) and at least one hash algorithm.

Distribution work

In Debian this month,

Lucas Nussbaum announced Debaudit, a “new service to verify the reproducibility of Debian source packages”:

debaudit complements the work of the Reproducible Builds project. While reproduce.debian.net focuses on ensuring that binary packages can be bit-for-bit reproduced from their source packages, debaudit focuses on the preceding step: ensuring that the source package itself is a faithful and reproducible representation of its upstream source or Vcs-Git repository.
kpcyrd filed a bug against the librust-const-random-dev package reporting that the compile-time-rng feature of the ahash crate uses the const-random crate in turn, which uses a macro to read/generate a random number generator during the build. This issue was also filed upstream.
60 reviews of Debian packages were added, 4 were updated and 16 were removed this month adding to our knowledge about identified issues. One new issue types was added, pkgjs_lock_json_file_issue.

Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their work there.

Tool development

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, 314 and 315 to Debian.

Chris Lamb:
- Don’t run test_code_is_black_clean test in the autopkgtests. (#1130402). […]
- Add some debugging info for PyPI debugging. […]
Jelle van der Waa:
- Fix compatibility with LLVM version 22. […]
- Adjust the PGP file detection regular expression. […]
Michael R. Crusoe:
- Reformat the source code using Black version 26.1.0 […][…]

In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 315.

rebuilderd, our server designed monitor the official package repositories of Linux distributions and attempt to reproduce the observed results there; it powers, amongst other things, reproduce.debian.net.

A new version, 0.26.0, was released this month, with the following improvements:

Much smoother onboarding/installation.
Complete database redesign with many improvements.
New REST HTTP API.
It’s now possible to artificially delay the first reproduce attempt. This gives archive infrastructure more time to catch up.
And many, many other changes.

Upstream patches

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

Bernhard M. Wiedemann:
- minify (rust random HashMap) / (alternative by kpcyrd)
- rpm-config-SUSE (toolchain)
Chris Lamb:
- #1129544 filed against python-nxtomomill.
- #1130622 filed against dh-fortran.
- #1130623 filed against python-discovery.
- #1130666 filed against kanboard.
- #1131168 filed against moltemplate.
- #1131384 filed against stacer.
- #1131385 filed against libcupsfilters.
- #1131395 filed against django-ninja.
- #1131403 filed against python-agate.
- #1132074 filed against aetos.
- #1132508 filed against python-bayespy.
kpcyrd:
- cargo (HashMap random order issue; more info)

Documentation updates

Once again, there were a number of improvements made to our website this month including:

kpcyrd:
- Add a new page about Rust specifics. […][…][…]
Robin Candau:
- Add link to the diffoci Arch Linux package on the Tools page. […]
Timo Pohl:
- Add new From Constrictor to Serpent: Investigating the Threat of Cache Poisoning in the Python Ecosystem paper to the Academic publications page. […]
- Add GitLab registration confirmation to How to join the Salsa group page. […]

Two new academic papers

Marc Ohm, Timo Pohl, Ben Swierzy and Michael Meier published a paper on the threat of cache poisoning in the Python ecosystem:

Attacks on software supply chains are on the rise, and attackers are becoming increasingly creative in how they inject malicious code into software components. This paper is the first to investigate Python cache poisoning, which manipulates bytecode cache files to execute malicious code without altering the human-readable source code. We demonstrate a proof of concept, showing that an attacker can inject malicious bytecode into a cache file without failing the Python interpreter’s integrity checks. In a large-scale analysis of the Python Package Index, we find that about 12,500 packages are distributed with cache files. Through manual investigation of cache files that cannot be reproduced automatically from the corresponding source files, we identify classes of reasons for irreproducibility to locate malicious cache files. While we did not identify any malware leveraging this attack vector, we demonstrate that several widespread package managers are vulnerable to such attacks.

A PDF of the paper is available online.

Mario Lins of the University of Linz, Austria, has published their PhD doctoral thesis on the topic of Software supply chain transparency:

We begin by examining threats to the software distribution stage — the point at which artifacts (e.g., mobile apps) are delivered to end users — with an emphasis on mobile ecosystems [and] we next focus on the operating system on mobile devices, with an emphasis on mitigating bootloader-targeted attacks. We demonstrate how to compensate lost security guarantees on devices with an unlocked bootloader. This allows users to flash custom operating systems on devices that no longer receive security updates from the original manufacturer without compromising security. We then move to the source code stage. [Also,] we introduce a new architecture to ensure strong source-to-binary correspondence by leveraging the security guarantees of Confidential Computing technology. Finally, we present The Supply Chain Game, an organizational security approach that enhances standard risk-management methods. We demonstrate how game-theoretic techniques, combined with common risk management practices, can derive new criteria to better support decision makers.

A PDF of the paper is available online.

Misc news

On our mailing list this month:

Holger Levsen announced that this year’s Reproducible Builds summit will almost certainly be held in Gothenburg, Sweden, from September 22 until 24, followed by two days of hacking. However, these dates are preliminary and not 100% final — an official announcement is forthcoming.
Mark Wielaard posted to our list asking a question on the difference between debugedit and relative debug paths based on a comment on the Build path page: “Have people tried more modern versions of debugedit to get deterministic (absolute) DWARF paths and found issues with it?

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

10 April, 2026 04:13PM

Jamie McClelland

AI Hacking the Planet

A colleague asked me if we should move all our money to our pillow cases after reading the latest AI editorial from Thomas Friedman. The article reads like a press release from Anthropic, repeating the claim that their latest AI model is so good at finding software vulnerabilities that it is a danger to the world.

I think I now know what it’s like to be a doctor who is forced to watch Gray’s Anatomy.

By now every journalist should be able to recognize the AI publicity playbook:

Step 1: Start with a wildly unsubstantiated claim about how dangerous your product is:

~~AI will cause human extinction before we have a chance to colonize mars~~ (remember that one? Even Kim Stanley Robinson, author of perhaps the most compelling science fiction on colonizing mars calls bull shit on it).

~~AI will eliminate all of our jobs~~ (this one was extremely effective at providing cover for software companies laying off staff but it has quickly dawned on people that the companies that did this are living in chaos not humming along happily with functional robots)

AI will discover massive software vulnerabilities allowing bad actors to “hack pretty much every major software system in the world”. (Did Friedman pull that directly from Anthropic’s press release or was that his contribution?)

Step 2: To help stave off human collapse, only release the new version to a vetted group of software companies and developers, preferably ones with big social media followings

Step 3: Wait for the limited release developers to spew unbridled enthusiasm and shocking examples that seem to suggest this new AI produce is truly unbelievable

Step 4: Watch stock prices and valuations soar

Step 5: Release to the world, and experience a steady stream of mockery as people discover how wrong you are

Step 6: Start over

Even if Friedman missed the text book example of the playbook, I have to ask: if you think bad actors compromising software resulting in massive loss of private data, major outages and wasted resources needs to be reported on, then where have you been for the last 10 years? This literally happens on a daily basis due to the fundamentally flawed way capitalism has been writing software even before the invention of AI. A small part of me wonders - maybe AI writing software is not so bad, because how could it be any worse than it is now?

Also, let’s keep in mind that AI’s super ability at finding vulnerable software depends on having access to the software’s source code, which most companies keep locked up tight. That means the owners of the software can use AI to find vulnerabilities and fix them but bad actors can’t.

Oh, but wait, what if a company is so incompetent that they accidentally release their proprietary software to the Internet?

Surely that would allow AI bots to discover their vulnerabilities and destroy the company right? I’m not sure if anyone has discovered world ending vulnerabilities in Anthropic’s Claude code since it was accidentally released, but it is fun to watch people mock software that is clearly written by AI (and spoiler alert, it seems way worse that software written now).

Well… we probably should all be keeping our money in a pillow case anyway.

10 April, 2026 12:27PM

Reproducible Builds (diffoscope)

diffoscope 317 released

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

[ Chris Lamb ]
* Limit python3-guestfs Build-Dependency to !i386. (Closes: #1132974)
* Try to fix PYPI_ID_TOKEN debugging.

[ Holger Levsen ]
* Add ppc64el to the list of architectures for python3-guestfs.

You find out more by visiting the project homepage.

10 April, 2026 12:00AM

April 09, 2026

Russell Coker

HP Z640 and E5-2696 v4

I recently decided to upgrade the CPU in my workstation, the E5-2696 v3 CPU was OK (passmark 2045 for single thread and 21,380 for multi thread) [1] but I felt like buying something better so I got a E5-2696 v4 (passmark 2115 and 24,643) [2]. I chose the E5-2696 v4 because I was looking for a E5-2699 v4 and found an ebay seller who had them at $140 but was offering the E5-2696 v4 for $99 and the passmark results for the two CPUs are almost identical.

After buying the CPU and waiting for it to be delivered I realised that the Z640 doesn’t include it in the list of supported CPUs and that the maximum TDP of any supported CPU is 145W while according to passmark it has a TDP of 150W. I looked for information about it on Intel ARK (the official site for specs of Intel CPUs) and discovered that “The Intel® Xeon® Processor E5-2696 v4 is designed to be used by system manufacturers (OEMs), and this means they can modify its specifications depending on the system where it will be implemented” and “The processor does not have an ARK page for this reason, since it has no standard specification from Intel, so depending on the original system, it is necessary to contact that system manufacturer for information” [3]. That’s the official response from an Intel employee saying that there are no standard specs for that CPU!!!

Somehow I had used a E5-2696 v3 for 3 years without realising that the same lack of support and specs applies to it [4]!

I installed the new CPU in another Z640 which had a E5-1620 v3 CPU and it worked. I was a little surprised to discover that the hole in the corner is in the bottom right (according to the alignment of the printed text on the top) for all my E5-26xx CPUs while it’s in the top left on the E5-1620 v3. Google searches for things like “e5-2600 e5-1600 difference” and “e5-2600 e5-1600 difference hole in corner” didn’t turn up any useful information. The best information I found was from the Linus Tech Tips forum which says that the hole is to allow gasses to escape when the CPU package is glued together [5] which implies (but doesn’t state) that the location of the hole has no meaning. I had previously thought that the hole was to indicate the location of “pin 1” and was surprised when the new CPU had the hole in the opposite corner. Hopefully in future when people have such concerns they can find this post and not be worried that they are about to destroy their CPU, PC, or both when upgrading the CPU.

The previous Z640 was one I bought from Facebook marketplace for $50 in “unknown condition” in the expectation that I would get at least $50 of parts but it worked perfectly apart from one DIMM socket. The Z640 I’m using now is one I bought from Facebook marketplace for $200 and it’s working perfectly with 4 DIMMs, 128G of RAM, and the E5-2696 v4 CPU. $300 for a workstation with ECC RAM and a 22 core CPU is good value for money!

There are some accounts of the E5-2696 v4 not working on white-box motherboards including a claim that when it was selling for $4000US someone’s motherboard destroyed one. The best plan for such CPUs is to google for someone who’s already got it working in the same machine, which means a name-brand server. That doesn’t guarantee that it will work (Intel refuses to supply specs and states that different items may work differently) but greatly improves the probability.

This system has the HP BIOS version 2.61, note that the Linux fwupd package doesn’t seem to update the BIOS on HP workstations so you need to manually download it and install it. There is a possibility that a Z640 with an older BIOS won’t work with this CPU.

Here is the previous post in my Z640 saga [6].

09 April, 2026 11:33PM by etbe

April 08, 2026

Jonathan Dowland

nvim-µwiki

In January 2025, as a pre-requisite for something else, I published a minimal neovim plugin called nvim-µwiki. It's essentially just the features from vimwiki that I regularly use, which is a small fraction them. I forgot to blog about it. I recently dusted it off and cleaned it up. You can find it here, along with a longer list of its features and how to configure it: https://github.com/jmtd/nvim-microwiki

I had a couple of design goals. I didn't want to define a new filetype, so this is designed to work with the existing markdown one. I'm using neovim, so I wanted to leverage some of its features: this plugin is written in Lua, rather than vimscript. I use the parse trees provided by TreeSitter to navigate the structure of a document. I also decided to "plug into" the existing tag stack navigation, rather than define another dimension of navigation (along with buffers, etc.) to track: Following a wiki-link pushes onto the tag stack, just as if you followed a tag.

This was my first serious bit of Lua programming, as well as my first dive into neovim (or even vim) internals. Lua is quite reasonable. Most of the vim and neovim architecture is reasonable. The emerging conventions about structuring neovim plugins are mostly reasonable. TreeSitter is, well, interesting, but the devil is very much in the details. Somehow all together the experience for me was largely just frustrating, and I didn't really enjoy writing it.

08 April, 2026 08:31PM

April 06, 2026

Thorsten Alteholz

My Debian Activities in March 2026

Debian LTS/ELTS

This was my hundred-forty-first 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:

[DLA 4500-1] gimp security update to fix four CVEs related to denial of service or execution of arbitrary code.
[DLA 4503-1] evolution-data-server to fix one CVE related to a missing canonicalization of a file path.
[DLA 4512-1] strongswan security update to fix one CVE related to a denial of service.
[ELA-1656-1] gimp security update to fix four CVEs in Buster and Stretch related to denial of service or execution of arbitrary code.
[ELA-1660-1] evolution-data-server security update to fix one CVE in Buster and Stretch related to a missing canonicalization of a file path.
[ELA-1665-1] strongswan security update to fix one CVE in Buster related to a denial of service.
[ELA-1666-1] libvpx security update to fix one CVE in Buster and Stretch related to a denial of service or potentially execution of arbitrary code.

I also worked on the check-advisories script and proposed a fix for cases where issues would be assigned to the coordinator instead of the person who forgot doing something. I also did some work for a kernel update and packages snapd and ldx on security-master and attended the monthly LTS/ELTS meeting. Last but not least I started to work on gst-plugins-bad1.0

Debian Printing

This month I uploaded a new upstream versions:

… epson-inkjet-printer-escpr to unstable.
… sane-airscan to unstable.
… printer-driver-oki to unstable.

Several packages take care of group lpadmin in their maintainer scripts. With the upload of version 260.1-1 of systemd there is now a central package (systemd | systemd-standalone-sysusers | systemd-sysusers) that takes care of this. Other dependencies like adduser can now be dropped.

This work is generously funded by Freexian!

Debian Lomiri

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 am also able to upload Debian packages to the corresponding Ubuntu PPA now. A small bug had to be fixed in the python script to allow the initial configuration in Launchpad.

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

Debian Astro

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

… libplayerone to experimental. For a list of other packages please see below.

I also uploaded lots of indi-drivers (libplayerone, libsbig, libricohcamerasdk, indi-asi, indi-eqmod, indi-fishcamp, indi-inovaplx, indi-pentax, indi-playerone, indi-sbig, indi-mi, libahp-xc, indi-aagcloudwatcher, indi-aok, indi-apogee, libapogee3, indi-nightscape, libasi, libinovasdk, libmicam, indi-avalon, indi-beefocus, indi-bresserexos2, indi-dsi, indi-ffmv, indi-fli, indi-gige, info-gphoto, indi-gpsd, indi-gpsnmea, indi-limesdr, indi-maxdomeii, indi-mgen, indi-rtklib, indi-shelyak, indi-starbook, indi-starbookten, indi-talon6, indi-weewx-json, indi-webcam, indi-orion-ssg3, indi-armadillo-playtypus ) to experimental to make progress with the indi-transition. No problems with those drivers appeared and the next step would be the upload of indi version 2.x to unstable. I hope this will happen soon, as new drivers are already waiting in the pipeline. There have been also four packages, that migrated to the official indi package and are no longer needed as 3rdparty drivers (indi-astrolink4, indi-astromechfoc, indi-dreamfocuser, indi-spectracyber).

While working on these packages, I thought about testing them. Unfortunately I don’t have enough hardware to really check out every package, so I can upload most of them only as is. In case anybody is interested in a better testing coverage and me being able to provide upstream patches, I would be very glad about hardware donations.

Debian IoT

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

… pywws to unstable.

Debian Mobcom

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

… osmo-trx to unstable.

misc

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

… cc-tool to unstable.
… mailio to unstable.
… gnupg-pkcs11-scd to unstable.
… odoo to unstable.

I also sponsored the upload of Matomo. Thanks a lot to William for preparing the package.

06 April, 2026 05:45PM by alteholz

April 04, 2026

Isoken Ibizugbe

Post Outreachy Activities

It’s been about a month since I wrapped up my Outreachy internship, but my journey with Debian is far from over. I planned to keep contributing and exploring the community, and these past few weeks have been busy

Testing Locales and Solving Bug #1111214

For the openQA project, we decided to explore how accurate local language installations are and see if we can improve the translations. While exploring this, I started working on automating a test for a specific bug report: Debian Bug #1111214

This is a test I had started by writing a detailed description of the installation process to confirm that selecting the Spanish_panama locale works accurately. I spent time studying previous language installation tests, and I learned that I needed to add a specific tag (LANGUAGE-) to the “needles” (visual test markers).

Since the installation wasn’t in English anymore, taking the correct screenshots and defining the areas took quite some time. I used the following command on the CLI to run the test:

`openqa-cli api -X POST isos ISO=debian-live-testing-amd64-gnome.iso DISTRI=debian-live VERSION=forky FLAVOR=gnome LANGUAGE=spanish_panama ARCH=x86_64 BUILD=1311 CHECKSUM=unknown`

While working on this, I got stuck at the complete_installation step. Because the keyboard layout had changed to Spanish, the commands required to confirm a successful install weren’t working as expected. Specifically, we had an issue typing the “greater than” sign (>).

My mentor, Roland Clobus, worked on a clever maneuver for the keys (AltGr-Shift-X), which was actually submitted upstream to openSUSE.

In this step, I also had to confirm that the locale was correctly set to LANG=”es_PA.UTF-8″. I had to dig into the scripts and Linux commands to make this work. It was a bit intimidating at first, but it turned out to be a great learning experience. You can follow my progress on this Merge Request here. I’m currently debugging a small issue where the “home” key seems to click twice in the final step, and after that, the test would be complete .

Community & Connections

Beyond the code, I’ve been getting more involved in the social side of Debian:

Debian Women: I attended the monthly meeting and met Sruthi Chandran. I’ve always seen her name as an Outreachy organizer, so it was great to meet her! She is currently running for Debian Project Leader (DPL). We also discussed starting technical sessions to introduce members to packaging, which I am very excited to learn.
DebConf Preparation: I am officially preparing for my first DebConf! My mentors, Tassia and Roland, along with my fellow intern Hellen, have been incredibly supportive in guiding me through the application and presentation process.

04 April, 2026 11:24PM by Isoken Ibizugbe

Dima Kogan

Simple gpx export from ridewithgps

The Tour de Los Padres is coming! The race organizer post the route on ridewithgps. This works, but has convoluted interfaces for people not wanting to use their service. I just wrote a simple script to export their data into a plain .gpx file, including all the waypoints; their exporter omits those.

I've seen two flavors of their data, so here're two flavors of the gpx-from-ridewithgps.py script:

#!/usr/bin/python3
import sys
import json

def quote_xml(s):
    return s.replace("&", "&amp;").replace("<", "&lt;").replace(">", "&gt;")

print("Reading stdin", file=sys.stderr)
data = json.load(sys.stdin)

print(r"""<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="gpx-from-ridewithgps.py" xmlns="http://www.topografix.com/GPX/1/1">""")

for item in data["extras"]:
    if item["type"] != "point_of_interest":
        continue
    poi = item["point_of_interest"]
    print(f'  <wpt lat="{poi["lat"]}" lon="{poi["lng"]}">')
    print(f'    <name>{quote_xml(poi["name"])}</name>')

    desc = poi.get("description","")
    if len(desc):
        print(f'    <desc>{quote_xml(desc)}</desc>')
    print(f'  </wpt>')

print("  <trk><trkseg>")
for pt in data.get("route", {}).get("track_points", []):
    print(f'    <trkpt lat="{pt["y"]}" lon="{pt["x"]}"><ele>{pt["e"]}</ele></trkpt>')
print("  </trkseg></trk>")

print("</gpx>")

#!/usr/bin/python3
import sys
import json

def quote_xml(s):
    return s.replace("&", "&amp;").replace("<", "&lt;").replace(">", "&gt;")

print("Reading stdin", file=sys.stderr)
data = json.load(sys.stdin)

print(r"""<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="gpx-from-ridewithgps.py" xmlns="http://www.topografix.com/GPX/1/1">""")

for poi in data["points_of_interest"]:
    print(f'  <wpt lat="{poi["lat"]}" lon="{poi["lng"]}">')
    print(f'    <name>{quote_xml(poi["name"])}</name>')

    desc = poi.get("description","")
    if len(desc):
        print(f'    <desc>{quote_xml(desc)}</desc>')
    print(f'  </wpt>')

for poi in data["course_points"]:
    print(f'  <wpt lat="{poi["y"]}" lon="{poi["x"]}">')
    print(f'    <name>{quote_xml(poi["n"])}</name>')
    print(f'  </wpt>')

print("  <trk><trkseg>")
for pt in data['track_points']:
    print(f'    <trkpt lat="{pt["y"]}" lon="{pt["x"]}"><ele>{pt["e"]}</ele></trkpt>')
print("  </trkseg></trk>")

print("</gpx>")

You invoke it by downloading the route and feeding it into the script:

curl -s https://ridewithgps.com/routes/54493422.json | ./ridewithgps-to-gpx.py > out.gpx

Note that the route number 54493422 is in the url above.

04 April, 2026 05:21PM by Dima Kogan

Dirk Eddelbuettel

Sponsor me for Tour de Shore 2026 to support MFA

On June 19 and 20, I will cycle a little over 100 miles from downtown Chicago and its wonderful Millenium Park to New Buffalo, Michigan, as part of the Tour de Shore 2026. The ride passes through northwest Indiana and the extended Indiana Dunes National Park ending the next morning in the southwestern Michigan town of New Buffalo. I rode Tour de Shore once before in 2024 and had a generally wonderful time (even considering some soreness after a century of miles over 1 1/2 days).

Tour de Shore is riding in support of Maywood Fine Arts Center, a local arts and sports center in Maywood, Illinois, a suburb one over from where I live and hence just a few good miles west of downtown. Maywood, Illinois is home to legends such as the late John Prine as well as several NBA players such as player and coach Doc Rivers.

But Maywood, Illinois is also little less well off than other western suburbs. The Maywood Fine Arts Center is simply legendary is what they do for this community (and surrounding communities), and especially the youth support. They can use a dollar a two. Their story about Tour de Shore is worth a read too for background and motivation.

I have bootstrapped my donation page page with a dollar for each mile to be cycled. It would be simply terrific if you could join me. A nickel, a dime, or a quarter per mile cycled would help. Multiples of that help too: More is of course still always better.

Anything you can afford will go a long way towards a worthy goal in a community that could use the help.

Of and if you are local to the area, I believe you can still register for Tour de Shore 2026. So see you out there in June? And if not, maybe help with a dollar or two?

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog.

04 April, 2026 01:08AM

April 02, 2026

Joerg Jaspert

Building a house - 1 year in

Haven’t written here about it, but last March we finally started on our journey to get our own house build, so we can move out of the rented flat here.

That will be a big step, both the actual building, but also the moving - I am living at this one single place for 36 years now.

If you can read german there is a dedicated webpage where I sometimes write about the process. Will have much more details (and way more ramblings) than the following part.

If you can’t read german, a somewhat short summary follows. Yes, still a lot of text, but shortened, still.

What? Why now?

Current flat has 83m² - which simply isn’t enough space. And the number of rooms also doesn’t fit anymore. But it is hard to find a place that fits our requirements (which do include location).

Moving to a different rented place would also mean changed amount of rent. And nowadays that would be huge increase (my current rent is still the price from about 30 years ago!).

So if we go and pay more - we could adjust and pay for something we own instead. And both, my wife and I had changes in our jobs that made it possible for us now, so we started looking.

Market

Brrrr, looking is good, actually finding something that fits - not so. We never found an offer that fit. Space wise, sure. But then location was off, or price was idiotically high. Location fit, but then size was a joke, and guess about the price… Who needs 200 square meters with 3 rooms? Entirely stupid design choices there. Or how about 40 square meters of hallway - with 50m² of tiny rooms around. What are they smoking? Oh, there, useful size, good rooms - but now you want more money than a kidney is worth, or something. Thanks, no.

New place

In February 2025 we finally got lucky and found a (newly opened) area with a large number of places to build a house on. Had multiple talks with someone from on of the companies developing that area (there are two you can select from), then talked with banks and signed a contract in March 2025. We got promised that actual house construction would be first quarter of 2026, finished in second quarter.

House type

There are basically 2 ways of building a new house (that matter here). First is called “Massivhaus”, second is called “Fertighaus” in german, roughly translating to solid and prefabricated. The latter commonly a wood based construction, though it doesn’t need to be. The important part of it is the prefabrication, walls and stuff get assembled in a factory somewhere and then transported to your place, where they play “big kid lego” for a day and suddenly a house is there.

A common thought is “prefabricated” is faster, but that is only a half true. Sure, the actual work on side is way shorter - usually one or two days and the house is done - while a massive construction usually takes weeks to build up. But that is only a tiny part of the time needed, the major part goes of into planning and waiting and in there it doesn’t matter what material you end up with.

Money fun

Last year already wasn’t the best time to start a huge loan - but isn’t it always “a few years ago would have been better”? So we had multiple talks with different banks and specialised consultants until we found something that we thought is good for us.

Thinking about it now - we should have put even more money on top as “reserve”, but who could have thought that 2026 turns into such a shitshow? Does not help at all, quite the contrary. And that damn lotto game always ends up with the wrong numbers, meh.

Plans and plans and more plans - and rules

For whichever reason you can not just go and put something on your ground and be happy. At least not if you are part of the normal people and not enormously rich. There is a large set of rules to follow. Usually that is a good thing, even though some rules are sometimes hard to understand.

In Germany, besides the usual laws, we have something that is called “Bebauungsplan”, which translates to “development plan” (don’t know if that carries the right meaning, it’s a plan on what and how may be build, which can have really detailed specifications in). It basically tells you every aspect on top of the normal law that you have to keep in mind.

In our case we have the requirement of 2 full floors and CAN have a third smaller on top, it limits how high the house can be and also how high our ground floor may be compared to the street. It regulates where on the property we may build and how much ground we may cover with the house, it gives a set of colors we are allowed to use, it demands a flat roof that we must have as a green roof and has a number of things more that aren’t important enough to list here. If you do want to see the full list, my german post on it has all the details that matter to us.

With all that stuff in mind - off to plans. Wouldn’t have believed how many details there are to take in. Room sizes are simple, but how to arrange them for ideal usage of the sun, useful ways inside the house, but also keeping in mind that water needs to flow through and out. Putting a bath room right atop a living room means a water pipe needs to go down there. Switch the bath room side in the house, and it suddenly is above the kitchen - means you can connect the pipes from it to the ones from kitchen, which is much preferred than going through the living room. And lots more such things.

It took us until nearly end of October to finalize the plans! And we learned a whole load from it. We started with a lot of wishes. The planner tried to make them work. Then we changed our minds. Plans changed. Minds changed again. Comparing the end result with the first draft we changed most of the ground floor around, with only the stairs and the entrance door at the same position. Less changes for the upper floor, but still enough.

Side quests

The whole year was riddled with something my son named side quests. We visited a construction exhibition near us, we went to the house builders factory and took a look on how they work. We went to many different other companies that do SOME type of work which we need soon, say inside floors, painters, kitchen and more stuff.

Of course the most important side quest was a visit to the notary to finalize the contracts, especially for the plot of land (in Germany you must have a notary for that to get entered into the governments books). Creates lots of fees, of course, for the notary and also the government (both fees and taxes here).

Building permit

We had been lucky and only needed a small change to the plans to get the building permit - and the second part, the wastewater permit (yes, you need a separate one for this) also got through without trouble.

Choices, so many of them

So in January we finally had an appointment for something that’s called “Bemusterung” which badly translates to “Sampling”. Basically two days at the house builders factory to select all of what’s needed for the house that you don’t do in the plans. Doors, inside and out and their type and color and handles. Same things for the windows and the blinds and the protection level you want the windows to have. Decide about stairs, design for the sanitary installations - and also the height of the toilet! - and the tiles to put into the bathrooms. Decisions on all the tech needed (heating system, ventilation and whatnot.

Two days, busy ones - and you can easily spend a lot of extra money here if you aren’t careful. We managed to get “out of it” with only about 4000€ extra, so pretty good.

Electro and automation

Now, here I am special. Back when I was young the job I learned is electrician. So here I have very detailed wishes. I am also running lots of automatism in my current flat - obviously the new house should be better than that. So I have a lot of ideas and thoughts on it, so this is entirely extra and certainly out of the ordinary the house builder usually see.

Which means I do all of that on my own. Well, the planning and some of the work, I must have a company at hand for certain tasks, it is required by some rules. But they will do what I planned, as long as I don’t violate regulations.

Which means the whole electrical installation is … different. Entirely planned for automatisms and using KNX for it. I am so happy to ditch Homeassistant and the load of Homematic, Zigbee and ZWave based wireless things.

Ok, Homeassistant is a nice thing - it can do a lot. And it can bridge between about any system you can find. But it is a central single point of failure. And it is a system that needs constant maintenance. Not touched for a while? Plan for a few hours playing update whack-a-mole. And often enough a component here or there breaks with an update. Can be fixed, but takes another hour or two.

So I change. Away from wireless based stuff. To wires. To a system thats a standard for decades already. And works entirely without a SPOF. (Yes, you can add one here too). And, most important, should I ever die - can easily be maintained by anyone out there dealing with KNX, which is a large number of people and companies. Without digging through dozens of specialised integrations and whatnot.

I may even end up with Homeassistant again - but that will entirely be as a client. It won’t drive automations. It won’t be the central point to do anything for the house. It will be a logging and data collecting thing that enables me to put up easy visualizations. It may be an easy interface for smartphones or tablets to control parts of the house, for those parts where one wants this to happen. Not the usual day-to-day stuff, extras on top.

Actual work happening

Since march there finally is action visible. The base of the house is getting build. Wednesday the 1st April we finally got the base slab poured on the construction site and in another 10 days the house is getting delivered and build up. A 40ton mobile crane will be there.

02 April, 2026 09:23PM

Samuel Henrique

Bringing HTTP/3 to curl on Amazon Linux

Screenshot of the top entry of the curl package's changelog, showing the following: Changelogs for curl-8.17.0-1.amzn2023.0.2.x86_64 * Mon Mar 16 00:00:00 2026 Samuel Henrique (samueloph) <samhn@amazon.com> - 8.17.0-1.amzn2023.0.2 - Enable HTTP/3 support in the full build using ngtcp2 and nghttp3 - HTTP/3 is explicitly disabled in the minimal build - Add runtime dependencies on libnghttp3 and libngtcp2 with minimum version pinning - Run tests in parallel via upstream make test-nonflaky, with serial fallback for race-prone tests

tl;dr

Starting with curl 8.17.0-1.amzn2023.0.2 in Amazon Linux 2023, you can now use HTTP/3.

dnf swap -y libcurl-minimal libcurl-full
dnf swap -y curl-minimal curl-full
curl --http3-only https://example.com

(HTTP/3 is only enabled in the curl -full builds)

Or, if you would like to try it out in a container:

podman run amazonlinux:2023 /bin/sh -c 'dnf upgrade -y --releasever=latest && dnf swap -y libcurl-minimal libcurl-full && dnf swap -y curl-minimal curl-full && curl --http3-only https://example.com'

For a list of test endpoints, you can refer to https://bagder.github.io/HTTP3-test/

The Upgrade I Didn't Have to Make

My teammate Steve Zarkos, who previously worked on upgrading OpenSSL in Amazon Linux from 3.0 to 3.2, spent the last few months on the complex task of bumping OpenSSL again, this time to 3.5. A bump like this only happens after extensive code analysis and testing, something that I didn't foresee happening when AL2023 was released but that was a notable request from users.

Having enabled HTTP/3 on Debian, I was always keeping an eye on when I would get to do the same for Amazon Linux (mind you, I work at AWS, in the Amazon Linux org). The bump to OpenSSL 3.5 was the perfect opportunity to do that, for the first time Amazon Linux is shipping an OpenSSL version that is supported by ngtcp2 for HTTP/3 support.

Non-Intrusive Change

In order to avoid any intrusive changes to existing users of AL2023, I've only enabled HTTP/3 in the full build of curl, not in the minimal one, this means there is no change for the minimal images.

The way curl handles HTTP/3 today also does not lead to any behavior changes for those who have the full variants of curl installed, this is due to the fact that HTTP/3 is only used if the user explicitly asks for it with the flags --http3 or --http3-only.

Side Quests

Supporting HTTP/3 on curl also requires building it with ngtcp2 and nghttp3, two packages which were not shipped in Amazon Linux, besides, my team doesn't even own the curl package, we are a security team so our packages are the security related stuff such as OpenSSL and GnuTLS. Our main focus is the services behind Amazon Linux's vulnerability handling, not package maintenance.

I worked with the owners of the curl package and got approvals on a plan to introduce the two new dependencies under their ownership and to enable the feature on curl, I appreciate their responsiveness.

Amazon Linux 2023 is forked from Fedora, so while introducing ngtcp2, I also sent a couple of Pull Requests upstream to keep things in sync:

[ngtcp2] package latest release 1.21.0

[ngtcp2] do not skip tests

While building the curl package in Amazon Linux, I've noticed the build was taking 1 hour from start to end, and the culprit was something well known to me; tests.

The curl test suite is quite extensive, with more than 1600 tests, all of that running without parallelization, running two times for each build of the package; once for the minimal build and again for the full build.

I had previously enabled parallel tests in Debian back in 2024 but never got around to submit the same improvements to Amazon Linux or Fedora, this is now fixed. The build times for Amazon Linux came down to 10 minutes under the same host (previously 1 hour), and Fedora promptly merged my PR to do the same there:

[curl] run tests in parallel

All of this uncovered a test which is timing-dependent, meaning it's not supposed to be run with high levels of parallelism, so there goes another PR, this time to curl:

Flag test 766 as timing-dependent#21155

What started as enabling a single feature turned into improvements that landed in curl, Fedora, and Amazon Linux alike. I did this in a mix of work and volunteer time, mostly during work hours (work email address used when this was the case), but I'm glad I put in the extra time for the sake of improving curl for everyone.

Release Notes

Amazon Linux 2023 release notes for 2023.10.20260330

02 April, 2026 12:00AM by Unknown

Reproducible Builds (diffoscope)

diffoscope 316 released

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

[ Jelle van der Waa ]
* Fix compatibility with LLVM version 22.

[ Chris Lamb ]
* Add some debugging info for PyPI debugging.

You find out more by visiting the project homepage.

02 April, 2026 12:00AM

April 01, 2026

Joey Hess

banning all Anthropic employees

Per my policies, I need to ban every employee and contractor of Anthropic Inc from ever contributing code to any of my projects. Anyone have a list?

Any project that requires a Developer Certificate of Origin or similar should be doing this, because Anthropic is making tools that explicitly lie about the origin of patches to free software projects.

UNDERCOVER MODE — CRITICAL

You are operating UNDERCOVER in a PUBLIC/OPEN-SOURCE repository. [...] Do not blow your cover.

NEVER include in commit messages or PR descriptions:

[...] The phrase 'Claude Code' or any mention that you are an AI
Co-Authored-By lines or any other attribution

-- via @vedolos

01 April, 2026 04:36PM

Ben Hutchings

FOSS activity in March 2026

Debian packages:
- firmware-nonfree:
  - Bugs:
  - Merge requests:
    - opened and merged !140: Update to 20260309
    - opened and merged !141: Clean up packaging (from Nicolas Boulenguez)
    - opened !142: Replace copy-firmware.sh; install files and generate metainfo.xml at build time
  - Uploads:
    - uploaded version 20260110-1~bpo13+1 to trixie-backports
    - uploaded version 20260221-1 to unstable
    - uploaded version 20260221-1~bpo13+1 to trixie-backports
    - uploaded version 20260309-1 to unstable
- hexagon-dsp-binaries:
  - Bugs:
    - replied to and reassigned #1130844: firmware-qcom-soc depends on unavailable package firmware-qcom-dsp
- initramfs-tools:
  - Merge requests:
- libtirpc:
  - Bugs:
    - replied to and reassigned #1132176: rpc.mountd: symbol lookup error: rpc.mountd: undefined symbol: rpc_gss_getcred, version TIRPC_0.3.0
- libvirt:
  - Bugs:
    - replied to and reassigned #1130974: libvirt: Should use nftables for IP masquerading to work with PREEMPT_RT
- linux:
  - Bugs:
  - Merge requests:
    - reviewed !1842: Merge kernel-wedge and use directly
    - reviewed and merged !1849: Cleanup installer
    - merged !1853: [amd64] drivers/platform/x86/uniwill: Enable UNIWILL_LAPTOP as module
    - opened and merged !1854: Fix ordering of kernel version strings for multiple Debian revisions
    - reviewed and closed !1857: crypto: padlock-sha - Disable for Zhaoxin processor
    - opened !1862: Fix regressions in debian/bin/test-patches
    - opened !1865: Draft: hyperv-daemons: Build using upstream Makefile; install hv_fcopy_uio_daemon
  - (LTS) worked on backports to 5.10 and 6.1 of the fixes for “CrackArmor” security flaws
  - Uploads:
    - (LTS) uploaded version 5.10.251-1 to bullseye-security
    - uploaded version 6.12.74-2~bpo12+1 to bookworm-backports
    - uploaded version 6.18.15-1~bpo13+1 to trixie-backports
    - uploaded version 6.19.6-2~bpo13+1 to trixie-backports
    - uploaded version 6.19.8-1~bpo13+1 to trixie-backports
- (LTS) linux-6.1:
  - Uploads:
    - uploaded version 6.1.164-1~deb11u1 to bullseye-security
- linux-base:
  - Uploads:
    - uploaded version 4.12.1~bpo12+1 to bookworm-backports
- sgt-puzzles:
  - Bugs:
  - Uploads:
    - uploaded version 20250730.a7c7826-1 to unstable
- wireless-regdb:
  - Uploads:
    - (LTS) uploaded version 2026.02.04-1~deb11u1 to bullseye-security
Debian non-packages:
- kernel-team:
  - added script to show status of all kernel team backports
- pipeline:
  - Issues:
    - opened #552: piuparts job fails to install dependencies outside of main
Mailing lists:
- debian-kernel:
  - posted and replied to Agenda items for kernel-team meeting on 2026-03-18
  - replied to How is “keep two last kernels” policy implemented?
- debian-lts-announce:
- linux-bluetooth:
  - (LTS) replied to [PATCH v3] Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ
- netdev:
  - (LTS) replied to [PATCH net v2] net: consume xmit errors of GSO frames
- stable/patches:
  - (LTS) reviewed 5.10.252 and replied to various patches included in it

01 April, 2026 03:30PM by Ben Hutchings

Matthew Garrett

Self hosting as much of my online presence as practical

Because I am bad at giving up on things, I’ve been running my own email server for over 20 years. Some of that time it’s been a PC at the end of a DSL line, some of that time it’s been a Mac Mini in a data centre, and some of that time it’s been a hosted VM. Last year I decided to bring it in house, and since then I’ve been gradually consolidating as much of the rest of my online presence as possible on it. I mentioned this on Mastodon and a couple of people asked for more details, so here we are.

First: my ISP doesn’t guarantee a static IPv4 unless I’m on a business plan and that seems like it’d cost a bunch more, so I’m doing what I described here: running a Wireguard link between a box that sits in a cupboard in my living room and the smallest OVH instance I can, with an additional IP address allocated to the VM and NATted over the VPN link. The practical outcome of this is that my home IP address is irrelevant and can change as much as it wants - my DNS points at the OVH IP, and traffic to that all ends up hitting my server.

The server itself is pretty uninteresting. It’s a refurbished HP EliteDesk which idles at 10W or so, along 2TB of NVMe and 32GB of RAM that I found under a pile of laptops in my office. We’re not talking rackmount Xeon levels of performance, but it’s entirely adequate for everything I’m doing here.

So. Let’s talk about the services I’m hosting.

Web

This one’s trivial. I’m not really hosting much of a website right now, but what there is is served via Apache with a Let’s Encrypt certificate. Nothing interesting at all here, other than the proxying that’s going to be relevant later.

Email

Inbound email is easy enough. I’m running Postfix with a pretty stock configuration, and my MX records point at me. The same Let’s Encrypt certificate is there for TLS delivery. I’m using Dovecot as an IMAP server (again with the same cert). You can find plenty of guides on setting this up.

Outbound email? That’s harder. I’m on a residential IP address, so if I send email directly nobody’s going to deliver it. Going via my OVH address isn’t going to be a lot better. I have a Google Workspace, so in the end I just made use of Google’s SMTP relay service. There’s various commerical alternatives available, I just chose this one because it didn’t cost me anything more than I’m already paying.

Blog

My blog is largely static content generated by Hugo. Comments are Remark42 running in a Docker container. If you don’t want to handle even that level of dynamic content you can use a third party comment provider like Disqus.

Mastodon

I’m deploying Mastodon pretty much along the lines of the upstream compose file. Apache is proxying /api/v1/streaming to the websocket provided by the streaming container and / to the actual Mastodon service. The only thing I tripped over for a while was the need to set the “X-Forwarded-Proto” header since otherwise you get stuck in a redirect loop of Mastodon receiving a request over http (because TLS termination is being done by the Apache proxy) and redirecting to https, except that’s where we just came from.

Mastodon is easily the heaviest part of all of this, using around 5GB of RAM and 60GB of disk for an instance with 3 users. This is more a point of principle than an especially good idea.

Bluesky

I’m arguably cheating here. Bluesky’s federation model is quite different to Mastodon - while running a Mastodon service implies running the webview and other infrastructure associated with it, Bluesky has split that into multiple parts. User data is stored on Personal Data Servers, then aggregated from those by Relays, and then displayed on Appviews. Third parties can run any of these, but a user’s actual posts are stored on a PDS. There are various reasons to run the others, for instance to implement alternative moderation policies, but if all you want is to ensure that you have control over your data, running a PDS is sufficient. I followed these instructions, other than using Apache as the frontend proxy rather than nginx, and it’s all been working fine since then. In terms of ensuring that my data remains under my control, it’s sufficient.

Backups

I’m using borgmatic, backing up to a local Synology NAS and also to my parents’ home (where I have another HP EliteDesk set up with an equivalent OVH IPv4 fronting setup). At some point I’ll check that I’m actually able to restore them.

Conclusion

Most of what I post is now stored on a system that’s happily living under a TV, but is available to the rest of the world just as visibly as if I used a hosted provider. Is this necessary? No. Does it improve my life? In no practical way. Does it generate additional complexity? Absolutely. Should you do it? Oh good heavens no. But you can, and once it’s working it largely just keeps working, and there’s a certain sense of comfort in knowing that my online presence is carefully contained in a small box making a gentle whirring noise.

01 April, 2026 02:35AM

March 31, 2026

Junichi Uekawa

April already.

April already. Wondering how bazel update is going in Debian. Seems like a large undertaking.

31 March, 2026 11:27PM by Junichi Uekawa

Benjamin Mako Hill

Quote #75514

Although I never submitted to it, I made several appearances in the now-defunct quote database on bash.org (QDB). I’m dealing with a broken keyboard now, and went to dig hard to find this classic in the Wayback machine. I thought I would put it back on the web:

<mako> my letter "eye" stopped worng
<luca> k, too?
<mako> yeah
<luca> sounds like a mountain dew spill
<mako> and comma
<mako> those three
<mako> ths s horrble
<luca> tme for a new eyboard
<luca> 've successfully taen my eyboard apart and fxed t by cleanng t wth alcohol
<mako> stop mang fun of me
<mako> ths s a laptop!

It was, in fact, horrble.

31 March, 2026 09:13PM by Benjamin Mako Hill

C.J. Collier

Finding: Promoting SeaBIOS Cloud Images to UEFI Secure Boot (Proxmox)

Discovery

Legacy cloud templates often lack the partitioning and bootloader
binaries required for UEFI Secure Boot. Attempting to switch such a VM
to OVMF in Proxmox results in “not a bootable disk.” We discovered that
a surgical promotion is possible by manipulating the block device and
EFI variables from the hypervisor.

The Problem

Protective MBR Flags: Legacy installers often set
the pmbr_boot flag on the GPT’s protective MBR. Strict UEFI
implementations (OVMF) will ignore the GPT if this flag is present.
Missing ESP: Cloud images often lack a FAT32 EFI
System Partition (ESP).
Variable Store: A fresh Proxmox
efidisk0 is empty and lacks both the trust certificates
(PK/KEK/db) and the BootOrder entries required for an automated
boot.

The “Promotion” Rule

To upgrade a SeaBIOS VM to Secure Boot without a full OS reinstall:
1. Surgical Partitioning: Map the disk on the host and
add a FAT32 partition (Type EF00). Clear the
pmbr_boot flag from the MBR. 2. Binary
Preparation: Boot the VM in SeaBIOS mode to install
shim and grub-efi packages. Use
grub2-mkconfig to populate the new ESP. 3. Trust
Injection: Use the virt-fw-vars utility on the
hypervisor to programmatically enroll the Red Hat/Microsoft CA keys and
any custom certificates (e.g., FreeIPA CA) into the VM’s
efidisk. 4. Boot Pinning: Explicitly set
the UEFI BootOrder to point to the shimx64.efi
path via virt-fw-vars --append-boot-filepath.

Solution (Example Command
Sequence)

On the Proxmox Host (root):

# Map and Clean MBR
DEV=$(rbd map pool/disk)
parted -s $DEV disk_set pmbr_boot off

# Inject Trust and Boot Path (VM must be stopped)
virt-fw-vars --inplace /dev/rbd/mapped_efidisk \
  --enroll-redhat \
  --add-db <GUID> /path/to/ipa-ca.crt \
  --append-boot-filepath '\EFI\centos\shimx64.efi' \
  --sb

This workflow enables high-integrity Secure Boot environments using
existing SeaBIOS infrastructure templates.

31 March, 2026 09:03PM by C.J. Collier

Thomas Lange

FAIme using apt-cacher-ng

The FAI.me service has become faster over the past two months.

First, the tool fai-mirror can now download all packages in one go (with all their dependencies) instead of downloading one by one. This helped a lot for the Linux Mint ISO because it uses a long list of packages.

I've also added a local apt cache (using apt-cacher-ng), so the network speed does not matter any more in most cases. This led to the following improvements:

Linux Mint install ISOs went from around 6-7 min to now only 2min.
Ubuntu install ISO went from average 3min to around 90 seconds.
The average time for a Debian Linux install ISO dropped from 2min to 40 seconds.

So far we only had once a problem with apt-cacher-ng, because the underlying partition was full.

Building cloud and live images do not gain that much from the local package cache, because most time is spend in extracting and installing the packages.

31 March, 2026 12:56PM

Russ Allbery

Review: Code Blue—Emergency

Review: Code Blue—Emergency, by James White

Series:	Sector General #7
Publisher:	Orb
Copyright:	1987
Printing:	May 2003
ISBN:	0-7653-0663-8
Format:	Trade paperback
Pages:	252

Code Blue—Emergency (annoying em-dash in original title) is the seventh book of James White's Sector General science fiction series about a vast multi-species hospital station. While there are some references to (and spoilers for) earlier books in the series, you don't have to remember the previous books to read this one. I had no trouble despite a nine-year gap.

I read this as part of the Orb General Practice omnibus, which collects this novel and The Genocidal Healer.

Cha Thrat is a Sommaradvan warrior-surgeon, member of a newly-discovered species that is beginning the process of contact with the Federation. She saved a Monitor corps human after an accident on her world, performing some some highly competent surgery on a species she had never seen before. That plus her somewhat outcast status on her own world due to her very traditional attitude towards medical ethics led Sector General to extend an offer of medical internship, and led her to leap into the unknown by accepting. This may have been a mistake; there is a great deal that Sector General does not understand about Sommaradvan medical ethics.

This series entry is another proper (if somewhat episodic) novel and the first book of the series that doesn't primarily focus on Conway. He makes an appearance in his new role as Diagnostician, but only as a supporting character. Code Blue—Emergency is told in the tight third-person perspective of Cha Thrat, an alien who finds many things about Sector General baffling, confusing, and ethically troubling (and who therefore provides a good reader surrogate for reintroducing the basics of how the hospital works).

Using an alien viewpoint is a more sophisticated narrative technique than White has used previously. I'm glad he tried it, and it mostly works, although I have some complaints. Cha Thrat comes from the middle cast of a strictly hierarchical society of three casts, but is also immensely stubborn and used to a medical system in which doctors take sole responsibility for their patients. This creates a lot of cultural conflicts, and I do enjoy science fiction where the human attitudes are portrayed as the strange ones, but the cultural analysis offered by this novel is not very deep.

The pattern of this book is for Cha Thrat to stumble into a successful approach to a problem while being either oblivious to or hostile to the normal hierarchical structure expected of medical trainees. This is believable as far as it goes. She is a skilled and intelligent doctor with some good instincts and a strong commitment to patient care, but is also culturally inclined to not ask for help. It makes sense for that to be a serious problem in a hospital. Unfortunately, no one says this directly. Sector General staff get quite upset in ways that seem more territorial than oriented towards patient safety, no one directly explains to Cha Thrat why following a process is important or shows examples of what could go wrong, and plot armor means that her mistakes usually have positive outcomes. One can extrapolate the reasons why she is not a good medical student, but the reader is forced to do the extrapolation.

This is the sort of book where the narration makes clear there are unresolved cultural clashes that are going to cause problems but hides the details. To Cha Thrat, her perspective is so obvious she never bothers to explain it to the reader, so the specifics come as a surprise. As with the alien perspective, I've seen this technique used with more subtlety and sophistication in other books, but White's version mostly works. Cha Thrat is a sympathetic protagonist because she is truly trying to take the most ethical and empathetic action in every situation and is clearly competent. Most of my frustration as a reader, ironically, lands on the other Sector General doctors who seem to make little to no effort to understand her perspective when she fails to conform to their expectations. This is believable in the abstract, but the whole point of Sector General is that they're supposed to be wiser about interspecies difference than this.

Also, sometimes their reactions just seem petty. Cha Thrat has a very hierarchical concept of medicine that matches the social classes of her culture. For her, the highest tier of doctor are wizards who treat rulers, because the work of rulers is mostly mental and intellectual and therefore the diseases of rulers are treated with magic spells performed with words to reshape their thinking rather than surgery on their bodies. O'Mara and the other Sector General psychologists take great offense at this, muttering about being called witch doctors, which I found completely absurd. This is a comprehensible, if odd, description of psychology from a wholly alien species. Surely one's first reaction should be that words like "wizard" or "magic" are translation errors. Don't get offended; look to see if the underlying substance matches, which it clearly does.

Apart from cultural and psychological clashes, Code Blue—Emergency has the standard episodic Sector General structure of interesting medical mysteries that require lateral thinking. I find this sort of puzzle story satisfying, particularly given the firm belief of every character in an essentially pacifist and empathetic approach to even the most alien of creatures. This determined non-violence is one of the more interesting things about this series, and it continues here.

White does tend towards both biological and gender essentialism for everyone other than the protagonist and main supporting characters, but he seemed to be walking back some of the more outrageous limitations on women that appeared in previous books. There is still some nonsense in here about how females of any species can't be Diagnosticians, but then Cha Thrat, who is female, seems to violate the justification for that rule over the course of this novel (sadly without comment). Perhaps he's setting up for proving Sector General wrong about this prejudice.

I picked this up after reading Elizabeth Bear's Machine, which is essentially a (better written) Sector General novel that got me in the mood for reading more. I wouldn't give Code Blue—Emergency any awards, but it delivered exactly what I was looking for. This series is not as deep or well-written as some more recent SF, but it is reliably itself and reliably entertaining. There are worse things in a series. Recommended if you're in the mood for alien ER in space.

The omnibus edition that I read has an introduction to both novels by John Clute. It does add some interesting insights, but (as is somewhat typical for Clute) it also spoils parts of both books. You may want to read it after you read the novels.

Followed by The Genocidal Healer.

Rating: 7 out of 10

31 March, 2026 03:08AM

March 30, 2026

Utkarsh Gupta

FOSS Activites in March 2026

Here’s my monthly but brief update about the activities I’ve done in the FOSS world.

Debian

Whilst I didn’t get a chance to do much, here are still a few things that I worked on:

A quick exchange with Xavier about node-lodash fixes for stable releases.
Uploaded ruby-rack to CVE-2026-25500 & CVE-2026-22860 to sid, trixie, and bookworm.
Started to work on the DebConf Bursary team along with PEB.
Assited a few folks in getting their patches submitted via Salsa.
Mentoring for newcomers.
Moderation of -project mailing list.

Ubuntu

I joined Canonical to work on Ubuntu full-time back in February 2021.

Whilst I can’t give a full, detailed list of things I did, here’s a quick TL;DR of what I did:

Successfully released 26.04 LTS Beta!
- This one was also done without the ISO tracker and cdimage access.
- We also worked very hard to build and promote all the image in due time.
- This was the first proper milestone with the Test Observer.
- We also did a retrospective: https://discourse.ubuntu.com/t/26-04-beta-tests-ubuntu-com-retrospective/79853.
Worked further on the whole artifact signing story for cdimage.
Assisted a bunch of folks with my Archive Admin and Release team hats to:
- Review and grant FFes.
- Coordinating weekly syncs.
- Promoting/demoting binaries to/from main.
- Taking care of package removals and so on.
Was pretty occupied with the new release processs architecture and design.
Preparing for the 26.04 LTS final release.

Debian (E)LTS

This month I have worked 50 hours on Debian Long Term Support (LTS) and on its sister Extended LTS project and did the following things:

Released Security Updates

libvirt: Regression introduced by the linux kernel update via DLA 4404-1.
- [LTS]: Fixed the regression (Debian bug #1124549) via 7.0.0-3+deb11u4 for bullseye. This has been released as DLA 4504-1.
ruby-rack: Path traversal and stored XSS vulnerabilities in directory handling.
- [LTS]: Fixed CVE-2026-22860 and CVE-2026-25500 via 2.1.4-3+deb11u5 for bullseye. This has been released as DLA 4505-1.
- [bookworm]: Fixed CVE-2026-22860 and CVE-2026-25500 via 2.2.2-0+deb12u1 for bookworm. This has been uploaded to oldstable-security and announced as DSA 6180-1.
- [trixie]: Fixed CVE-2026-22860 and CVE-2026-25500 via 3.1.2-0+deb13u1 for trixie. This has been uploaded to stable-security and announced as DSA 6180-1.
vlc: Out-of-bounds read and denial of service via a crafted MMS server response.
- [LTS]: Fixed CVE-2025-51602 via 3.0.23-0+deb11u1 for bullseye. This has been released as DLA 4507-1.
- [ELTS]: The 3.0.23 backport is ready but still in testing. Will be released in April.
nss: Integer overflow in the AES-GCM implementation.
- [LTS]: Fixed CVE-2026-2781 via 2:3.61-1+deb11u5 for bullseye. This has been released as DLA 4508-1.
gst-plugins-base1.0: Integer overflow in the RIFF parser.
- [LTS]: Fixed CVE-2026-2921 via 1.18.4-2+deb11u5 for bullseye. This has been released as DLA 4514-1.
- [ELTS]: Fixed CVE-2026-2921 via 1.14.4-2+deb10u6 for buster and 1.10.4-1+deb9u7 for stretch. This has been released as ELA 1669-1.
gst-plugins-ugly1.0: Heap-based buffer overflow and out-of-bounds write in media demuxers.
- [LTS]: Fixed CVE-2026-2920 and CVE-2026-2922 via 1.18.4-2+deb11u2 for bullseye. This has been released as DLA 4516-1.
- [ELTS]: Fixed CVE-2026-2920 and CVE-2026-2922 via 1.14.4-1+deb10u3 for buster and 1.10.4-1+deb9u3 for stretch. This has been released as ELA 1670-1.
phpseclib: Name confusion in X.509 certificate verification and a padding oracle timing attack in AES-CBC.
- [LTS]: Fixed CVE-2023-52892 and CVE-2026-32935 via 1.0.19-3+deb11u3 for bullseye. This has been released as DLA 4518-1.
- [ELTS]: Fixed CVE-2023-52892 and CVE-2026-32935 via 1.0.19-3~deb10u4 for buster. This has been released as ELA 1671-1.

Work in Progress

knot-resolver: Affected by CVE-2023-26249, CVE-2023-46317, and CVE-2022-40188, leading to Denial of Service.
- [LTS]: Still in back and forth discussion with maintainers on the best way to proceed for the bullseye upload. Git repository for bullseye: https://salsa.debian.org/lts-team/packages/knot-resolver/-/tree/debian/bullseye.
node-lodash: Affected by CVE-2025-13465, prototype pollution in the baseUnset function.
- [stable]: Xavier from the JS team ACK’d the patch. The trixie and bookworm uploads will follow.
- [LTS]: The bullseye test and upload will follow in April once the stable uploads are in and ACK’d by the SRMs.
vlc: Affected by CVE-2025-51602, an out-of-bounds read and denial of service via a crafted 0x01 response from an MMS server.
- [LTS]: 3.0.23 backport is ready but not tested. I’ll get this over the line in March.
- [ELTS]: 3.0.23 backport is ready but not very clean. Would like to complete LTS and get back to this.

Other Activities

[ELTS] Continued to review ruby-rack for ELTS – it has since received about 13 new CVEs, making it even more chaotic. Might consider releasing in batches.
[E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates.
[E/LTS] Attended the monthly LTS meeting on IRC. Summary here.
[Other] Spent quite some time debugging a bug in debusine. Filed https://salsa.debian.org/freexian-team/debusine/-/issues/1412 for the same. Have worked on a preliminary patch but would like to submit something for Colin to review. Will follow up in April.

Until next time.
:wq for today.

30 March, 2026 05:41AM

Russ Allbery

Review: The Cloak and Its Wizard

Review: The Cloak and Its Wizard, by R.Z. Nicolet

Publisher:	UpLit Press
Copyright:	February 2026
ISBN:	1-917849-15-X
Format:	Kindle
Pages:	423

The Cloak and Its Wizard is a standalone (at least so far) urban fantasy superhero (sort of) novel. R.Z. Nicolet is the marketing pseudonym for Rachel Reddick. This is her first novel.

I'm picky about wizards.

The wizards themselves will complain about that, but of course I'm picky. When I choose a wizard, barring utter abandonment of moral scruples, it's a till-death-do-us-part situation. (Their death, not mine. I'm the next best thing to indestructible.)

The Cloak of Sunset and Starlight is a major artifact, meaning that it has its own preferences and is capable of independent action. It has been sitting in a glass case in the wizards' library for about a hundred years, waiting for someone interesting. (Well, mostly sitting. Occasionally it sneaks out to eavesdrop or move the books around.)

Veronica Noble is interesting. She's older than most initiates, thoughtful, observant, and clearly had some mundane career before joining the Order. Her aura is appealing, and her mental shields and resistance to influence are intriguing. Normally, the Cloak would take its time investigating a new potential wizard, but the Sword was making thoughtful rattling sounds, and no way is the Cloak going to let the Sword claim her first. Time to choose a new wizard!

It was nice, being draped over warm shoulders, and feeling a heartbeat again.

I could tell she closed her eyes without even looking.

She sighed. "I just got picked by the intransigent one, didn't I?"

The last time I picked a book from the Big Idea feature in Scalzi's Whatever blog, it didn't go that well, but if you're going to write a book specifically for me, I'm going to read it. There are very few tropes of SFF that I love more than intelligent companion objects, and Nicolet's introduction to the story was compelling. So I gave this book discovery method another chance.

I'm glad I did, because this was exactly what I was in the mood for and a delight from cover to cover.

Veronica Noble is not a typical wizard. She's a surgeon and was quite happy to be a surgeon until an unexpected encounter with a magical creature killed her brother. The forgetting spell that the wizards who came to handle the Cassandra wyrm didn't work on her, so she was dragged reluctantly into the secret magical world of the Order. This long-lived society of wizards quietly defends the world against magical intrusions from other planes of existence. Now she's a wizard with a magical cloak, which she is not at all sure she wants.

Veronica is not the protagonist, though. The Cloak of Sunset and Starlight is. As far as it is concerned, its job is to assist its wizard, enjoy watching interesting feats of magic, and look fabulous doing so. It's protective, dramatic, rather vain, endlessly curious, easily bored, and intensely loyal. When it becomes clear that the Order has some serious problems, the Cloak knows what side it's on.

This sounds a bit like urban fantasy, so I was surprised when the first superheroes showed up, although given the explicit Doctor Strange inspiration I probably should have expected them. The Order and the superheroes do not mix, at least at the start of the novel. The wizards view the superheroes as a loud and irritating intrusion and hide magical activities from them the same as they do the rest of the world. Veronica's opening opinion on superheroes is based on being a trauma surgeon in a hospital dealing with the aftermath of their fights (which makes me wonder if the author has read Hench, although the idea is older than that book). As with the Order, the role of superheroes in this world gets more complicated as the plot develops.

There is a surprising amount of plot and some very nice world-building here, including multiple twists that I was not expecting. Veronica is the sort of stubborn and deeply ethical person who will not leave a problem alone if she has the ability to fix it, which is a good recipe for getting deeper and deeper into a complex plot. She's believable as a surgeon: somewhat taciturn, calm in emergencies, detail-oriented, methodical, and not at all dramatic. This makes the Cloak a perfect foil and complement. Watching their partnership develop was very satisfying.

This is a sidekick novel, and like the best sidekick novels it makes the not-protagonist more interesting and more relatable by showing them from an outside and skewed perspective. Piecing together what Veronica must be thinking is part of the fun, as is sharing the Cloak's protectiveness towards her as it becomes clear how much she's been through and how good of a person she is. The Cloak's personality was a little too much like a cat for me — I would have preferred a more unique viewpoint, fewer cat-coded shenanigans, and a bit less of the running laundry machine joke. But that's a quibble. Its endless curiosity drives the plot forward and uncovers more of the world-building, and I just love reading stories from the perspective of this sort of loyal and protective magical creature.

I had so much fun with this book. It's a popcorn sort of book, and I thought the ending sputtered a little, but overall it was great. Parts of it could have been designed in a lab to appeal to me specifically, so I'm not sure if other people will enjoy it as much, but its hit rate with my friends so far has been good.

Highly recommended, and I will be watching for any further novels from Nicolet.

The Cloak and Its Wizard reaches a satisfying conclusion and doesn't advertise itself as part of a series, but there is room for a sequel. If Nicolet ever writes one, I'd read it.

Rating: 8 out of 10

30 March, 2026 02:46AM

Sahil Dhiman

MiniDebConf Kanpur 2026

MiniDebConf Kanpur 2026 was held on 14th and 15th March 2026 at the Indian Institute of Technology Kanpur.

Having a Debian conference in the North was something many folks wanted. Ravi started the discussion (with local IIT Kanpur folks) almost 7 months before the conference. Lots of folks from Debian India joined in organizing the conference, which was nice. All the meeting notes and discussions were posted on the Debian India mailing list, a first.

Despite all the efforts, the conference start was delayed due to logistical issues. Things went fine post Day 1 lunch. We had two days of almost full schedule. disaster’s Decentralising Indian Communication was an interesting talk, diving into decentralized communication.

IIT Kanpur is a huge campus with nice footpaths and greenery. We got the opportunity to explore their HPC at Computer Center post conference.

Work has been started for MiniDebCamp Kochi. More details can be found on the wiki.

Working to make this conference happen was different with all the challenges involved, but overall, everyone was happy with the outcome.

MDC K group photo

Group photo. Click to enlarge

30 March, 2026 02:24AM by Sahil Dhiman

March 29, 2026

Russell Coker

Ebook Readers in Debian

Laptop

For a while I’ve been using Calibre 8.5.0+ds-1+deb13u1 in Debian/Trixie running KDE for reading ebooks on my laptop, it generally works well and has a large font size. The only downsides of it for that use are taking more RAM than I would prefer (about 780M RSS which seems a lot for a relatively simple task) and having separate windows for the list of books and reading an actual book without any options to just open the last book and not delay me.

I tried Arianna 25.04.0-1 in Debian/Trixie, it has a significantly smaller font size and doesn’t allow high contrast colors as the default is black on gray with the dark theme in KDE. It also only allows left and right arrows for moving through the book while Calibre uses up/down, left/right, or pgup/pgdn so whatever keys seem reasonable to you are going to work. The RSS was 762M which wasn’t great but wasn’t the real problem. Rumours of Arianna using less RAM than Calibre seem exaggerated.

Librem5

On my Librem5 phone with Plasma Mobile Calibre 8.5.0+ds-1+deb13u1 both the initial setup screen and the main screen for selecting a book to read don’t work in the width of portrait view on the phone. After putting it in landscape mode it worked, but I couldn’t touch on a book title to select it I had to touch on the number of the book at the left of the list box. But once it was loaded everything was fine. On the Librem5 Arianna 25.04.0-1 just worked fine, although only using left/right swipes to change pages instead of up/down was annoying.

Furilabs FLX1s

On my Furilabs FLX1s with phosh Arianna 25.04.0-1 and Calibre 8.16.2+ds+~0.10.5-3 both gave the same result of not displaying text or images from the book, I’m not sure if it’s phosh or some other aspect of the FLX1s configuration at fault.

PinePhonePro

On my PinePhonePro running Debian/Testing with Plasma Mobile Arianna 25.12.3-1 worked without any issue and up/down swipes worked. Calibre 9.5.0+ds+~0.10.5-1 had the initial screen work fine in portrait mode but the main screen was too wide and needed landscape. Also the issue of having to touch the number applied.

Laptop running Debian/Unstable

Calibre 9.6.0+ds+~0.10.5-2 and Arianna 25.12.3-1 worked quite nicely on a Thinkpad running Debian/Unstable. One thing I discovered while testing it is that Calibre supports the CTRL-PLUS and CTRL-MINUS key combinations to change font sizes and that also works on the version in Debian/Trixie. Arianna doesn’t support CTRL-PLUS/MINUS.

Conclusion

The problems I had were Arianna on a laptop, everything on the Furilabs FLX1s, and Calibre’s UI not being well adjusted for mobile devices.

29 March, 2026 12:29PM by etbe

Russ Allbery

Review: The Sovereign

Review: The Sovereign, by C.L. Clark

Series:	Magic of the Lost #3
Publisher:	Orbit
Copyright:	September 2025
ISBN:	0-316-54286-5
Format:	Kindle
Pages:	575

The Sovereign is the third and concluding book of C.L. Clark's Magic of the Lost high fantasy trilogy. I recommend reading the books of this series close together, since there are a lot of characters and a lot of continuity between books that is helpful to remember, but it was not quite as difficult this time to remember where the story left off.

At the end of The Faithless, the political situation in Balladaire (not-France) was more stable, but the threat of a plague lay on the horizon. That threat arrives in earnest in this book, along with new threats from both Balladaire's former colonial conscript soldiers and from neighboring Taargen (not-Germany, sort of, although the parallel isn't as close). Luca and Touraine have finally admitted that they're deeply in love, but they are still very different people with different goals and ethics. Luca is determined to do anything necessary to save her kingdom, but her definition of her kingdom is sharp and brittle. Touraine is torn between far too many loyalties, plus the lingering worry that her morals and Luca's may not be compatible.

I think the hardest part of this sort of series is finding an ending the reader will find satisfying. This one, unfortunately, did not work for me, but that may be more due to personal preference than objective flaws.

There have been two threads through this series: an improbable romance embedded in a network of complex personal relationships, and a political commentary on colonialism and post-colonial wars. I was enjoying the former, but it was the latter that felt fresh and interesting to me. The plot threads in The Faithless outside of Balladaire expanded that complexity, and I was hoping the final volume would continue in that direction. How could a colonial power atone for its history? How does the former colony establish its own governance? Is there a path to freedom without violence? Are attempts to chart a more moral course doomed to open lines of attack for one's other enemies?

It's clear that Clark was thinking about similar themes, but The Sovereign narrows the field instead of widens it, restricts the political options, and then resolves most questions in a massive war. This is not that surprising of a conclusion, but it's one that I found unsatisfying and, honestly, a little boring. Yes, one way to resolve all the competing tensions is for everyone to try to kill each other and whoever survives wins, and historically that's one of the more likely outcomes, but that ending doesn't wrestle with the politics as much as it collapses them.

Clark instead focuses this concluding volume on the romance, which becomes even more fraught, tragic, and dramatic than it was in previous books (and that's saying something). The hard questions of divided loyalties and moral conflicts are mostly framed by questions about Touraine's loyalty to Luca and Luca's trust of Touraine. This is all very Shakespearean, full of hard choices, sudden reversals, miscommunication, and a very deep conflict between Luca's realpolitik and Touraine's stubborn personal morality. If this is what you were reading the series for, if you were hoping for a maximum-drama sapphic relationship, you may thoroughly enjoy this. I thought it had its moments, but I wish they had been balanced by more moments of cool-headed practicality and creative political ingenuity.

My biggest frustration with this ending is that the characters largely stop doing politics. The political complexity was the strength of both The Unbroken and The Faithless: People who intensely dislike each other negotiate because there is something larger to be gained, personal decisions made without considering the political ramifications have costs, and multiple characters are trying hard to find a way to turn a nasty, exploitative world into something better without simply killing everyone who disagrees. Many of the characters were objectively bad at politics, inexperienced and immature, but they stumbled or dragged or fought their way into political solutions anyway. I thought Clark moved too far away from that in The Sovereign. Everyone goes deep into their own emotions and desire for vengeance or conquest or revolution and stops compromising. To a depressingly large extent, the story is resolved by killing everyone who disagrees. I think the story is poorer for it.

One of the other threads of the series is Balladairan magic, or rather its odd absence. Luca has one understanding of it, the rebels introduced in The Faithless have a different understanding of it, and its pursuit is set up as critical to resolving the threat of a plague. We do get an explanation of sorts, but it's not as complete or as satisfying as I was hoping, and the symbolism of Balladaire's missing magic is left frustratingly murky. For me, this has some of the same problems as the political conclusion: I wanted an intellectual catharsis alongside the emotional catharsis, but that was not the direction Clark was taking the story.

I like reading about these characters. All of Luca, Touraine, and Pruett are complex, comprehensible, flawed, and often intriguing. But my favorite character in the story, the person I latched on to as an emotional path through the story, was Sabine. Her refreshingly straightforward loyalty and lack of drama was a breath of fresh air. She has some great moments in this book, but there too I got wrong-footed by the direction Clark went with her arc and found its conclusion deeply unsatisfying.

I'm not sure how many of these complaints are because of missed opportunities in the novel, how many were due to a mismatch of taste, and how many were due to not being in the right mood to read this conclusion. I'm sure that it didn't help that I read this simultaneous with another novel in which the characters were always miserable, or that I read it in early 2026 with, uh, all that entails. I suspect that if you came away from the first two books invested in the messy romance and wanting MOAR DRAMA, you may get exactly what you were hoping for. That, sadly, was not what I was hoping for.

I can't really recommend this. I thought it dragged in places and didn't deliver the ending I wanted. But it has some great moments, it does wrap up the threads of the trilogy as advertised, and at least the romance gets a dramatic climax worthy of the tension that has been built through the previous books. If that matches what you were enjoying in the previous books, you may well enjoy this more than I did.

Rating: 5 out of 10

29 March, 2026 04:51AM

Samuel Henrique

Latest NVIDIA Drivers for Debian (Packaged with AI)

tl;dr

This is not an official package, it's good enough for me and it might be good enough for you, confirmed as working in Debian Testing but I don't have a Stable machine to test there.

You can use my custom repo to install the latest NVIDIA drivers on Debian Stable, Testing or Unstable (install from Sid repository):

https://deb.debusine.debian.net/debian/r-samueloph-nvidia-ai/

The page above contains the APT sources you need, just add the one for your release to /etc/apt/sources.list.d/r-samueloph-nvidia-ai.sources, run sudo apt update and install the packages, you might need to disable Secure Boot.

This is not about AI

Discussions about AI are quite divisive in the Free Software communities, and there's so much to be said about it that I'm not willing to go into in this blog post. This is rather just me telling people that if they need up-to-date NVIDIA packages for Debian, they could check if my custom repository gets the job done.

The AI part is a means to an end, I've been careful to note in the repository names that the packages were produced with AI to respect people who do not want to run it for any reason.

RTX 5000 series support

Back in May 2025 I opened a bug report asking for the NVIDIA drivers on Debian to be updated to support the RTX 5000 series. The Nouveau drivers might be good enough for some people, but I need the NVIDIA drivers because I want to play games and do experiments with open weight models.

Opening a bug report doesn't guarantee anything, at the end of the day Debian Developers are volunteers, so if I really wanted the newer drivers, I would have to do something about it, ideally submitting a merge request.

I briefly looked into the NVIDIA packaging, which involves 3 source packages (and one extra git repo for tarballs), unfortunately this was going to take more time and effort than what I was willing to spend.

What I Did

After a few weeks of lamenting that I wasn't running the NVIDIA drivers, I figured I was willing to put in more effort than I originally thought, just enough to instruct the Claude Code agent to package the latest releases. I'm skilled enough with agentic tools that I knew how to use it to save time; providing a clear instruction on how to build the package and explaining the packaging layout, then letting the agent iterate until it gets a working build. The agent was running inside a VM that didn't have any of my credentials.

After a little bit of back and forth, where I was reviewing the changes guiding the agent into how to fix certain issues, I ended up with a working set of packages.

Once I installed it on my machine and confirmed they worked, I set up a debusine repository to make it easier to install future updates, and let others test it out.

Debusine is analogous to Ubuntu's famous PPA, or Fedora's EPEL, it's a relatively new project but it has been working fine for this.

Matheus Polkorny helped me test the packages and did spot a few issues which are fixed now. The Debusine developers were also always quick to respond to my questions and bug reports.

How Good Is It?

Short answer: good enough for daily use, but not a substitute for an official Debian package.

The whole point of doing this is because I don't have enough free time to maintain the package myself. All of this work was done as a volunteer, on my personal time.

This means I'm trusting the agent to some degree; I review its commits but I don't go too deep into it, the quality will be dictated by the fact that I'm a Debian Developer and so by how easily I can spot issues without double checking everything.

I only have a single machine with an NVIDIA GPU, this machine runs Debian Testing and so I don't have a way to test the Stable packages. I can do my best to address problems but at this point there is a risk that new updates break something.

Installing NVIDIA drivers has always been a bit risky regardless, if you're comfortable with reverting updates and handling a system without a graphical interface (in case you end up in a tty), you will be fine.

You will likely need to disable Secure Boot in order to use them, or set up your BIOS so that a MOK can be used to sign the DKMS modules.

When choosing the version strings for the packages, I was careful enough to pick something that would sort lower than an official Debian package, meaning that whenever that same version is packaged in Debian, your system will see it as an upgrade.

If you have any other methods of installing the NVIDIA drivers on your Debian system that is working for you, you should likely stick to that.

I have a strong preference for installing them through .deb packages, making the package sort out configuration changes and dependency updates, besides handling the DKMS modules.

Ultimately I'm not happy with the amount of difficulty that Debian users have in installing up-to-date NVIDIA drivers, and I hope this makes it easier for some.

How To Install

Head over to the Debusine page that contains both repos for Trixie (Debian Stable) and Sid (for Debian Testing and Unstable):

https://deb.debusine.debian.net/debian/r-samueloph-nvidia-ai/

If you are running Debian Testing, then pick the Sid repository.

That page contains the contents of the apt .sources file you need, create the file /etc/apt/sources.list.d/r-samueloph-nvidia-ai.sources with the sources for your release.

Run sudo apt update and install the packages you need, if you already have a previous version installed, sudo apt upgrade --update would update them.

If there are no upgrades, meaning you don't have a previous version installed, then you need to explicitly install them.

sudo apt install nvidia-open-kernel-dkms nvidia-driver

If you run into issues in Debian Stable, consider using the Linux kernel package from the backports repository, if you need an up-to-date NVIDIA driver, you likely should also be running the backports kernel package (if you can't upgrade to Debian Testing).

Future Plans

I currently have no means of measuring how many people are using the debusine repositories, so if you do end up using it feel free to let me know somehow.

I don't know for how long I will keep managing this repository, and how much effort I will spend, but my machine needs it and for now I will keep it up-to-date with the latest production-grade NVIDIA drivers.

Sources

The sources of the packages are available under a namespace in Salsa (Debian's GitLab instance):

https://salsa.debian.org/samueloph-forks-team/nvidia-drivers-forks-with-ai

You can also get the exact sources used in the repositories from debusine:

https://debusine.debian.net/debian/r-samueloph-nvidia-ai/collection/debian:suite/sid-nvidia-ai/search/?category=debian:source-package

https://debusine.debian.net/debian/r-samueloph-nvidia-ai/collection/debian:suite/trixie-nvidia-ai/search/?category=debian:source-package

29 March, 2026 12:00AM by Unknown

March 28, 2026

Evgeni Golov

Converting Dovecot password schemes on the fly without (too much) cursing

I finally upgraded my mail server to Debian 13 and, as expected, the Dovecot part was quite a ride.

The configuration syntax changed between Dovecot 2.3 (Debian 12) and Dovecot 2.4 (Debian 13), so I started first with diffing my configuration against a vanilla Debian 12 one (this setup is slightly old) and then applied the same (logical) changes to a vanilla Debian 13 one. This mostly went well. Mostly because my user database is stored in SQL and while the Dovecot Configuration Upgrader says it can convert old dovecot-auth-sql.conf.ext files to the new syntax, it only does so for the structure, not the SQL queries themselves. While I don't expect it to be able to parse the queries and adopt them correctly, at least a hint that the field names in userdb changed and might require adjustment would've been cool.

Once I got that all sorted, Dovecot would still refuse to let me in:

Error: sql: Invalid password in passdb: Weak password scheme 'MD5-CRYPT' used and refused

Yeah, right. Did I mention that this setup is old?

The quick cure against this is a auth_allow_weak_schemes = yes in /etc/dovecot/conf.d/10-auth.conf, but long term I really should upgrade the password hashes in the database to something more modern.

And this is what this post is about.

My database only contains hashed (and salted) passwords, so I can't just update them without changing the password. And while there are only 9 users in total, I wanted to play nice and professional. (LOL)

There is a Converting Password Schemes howto in the Dovecot documentation, but it uses a rather odd looking PHP script, wrapped in a shell script which leaks the plaintext password to the process list, and I really didn't want to remember how to write PHP to complete this task.

Luckily, I know Python.

The general idea is:

As we're using plaintext authentication (auth_mechanisms = plain login), the plaintext password is available during login.
After Dovecot's imap-login has verified the password against the old (insecure) hash in the database, we can execute a post-login script, which will connect to the database and update it with a new hash of the plaintext password.

To make the plaintext password available to the post-login script, we add '%{password}' as userdb_plain_pass to the SELECT statement of our passdb query. The original howto also says to add a prefetch userdb, which we do. The sql userdb remains, as otherwise Postfix can't use Dovecot to deliver mail.

Now comes the interesting part. We need to write a script that is executed by Dovecot's script-login and that will update the database for us. Thanks to Python's passlib and mysqlclient, the database and hashing parts are relatively straight forward:

#!/usr/bin/env python3

import os

import MySQLdb
import passlib.hash

DB_SETTINGS = {"host": "127.0.0.1", "user": "user", "password": "password", "database": "mail"}
SELECT_QUERY = "SELECT password_enc FROM mail_users WHERE username=%(username)s"
UPDATE_QUERY = "UPDATE mail_users SET password_enc=%(pwhash)s WHERE username=%(username)s"

SCHEME = "bcrypt"
EXPECTED_PREFIX = "$2b$"


def main():
    # https://doc.dovecot.org/2.4.3/core/config/post_login_scripting.html
    # https://doc.dovecot.org/2.4.3/howto/convert_password_schemes.html
    user = os.environ.get("USER")

    plain_pass = os.environ.get("PLAIN_PASS")
    if plain_pass is not None:
        db = MySQLdb.connect(**DB_SETTINGS)
        cursor = db.cursor()
        cursor.execute(SELECT_QUERY, {"username": user})
        result = cursor.fetchone()
        current_pwhash = result[0]

        if not current_pwhash.startswith(EXPECTED_PREFIX):
            hash_module = getattr(passlib.hash, SCHEME)
            pwhash = hash_module.hash(plain_pass)
            data = {"pwhash": pwhash, "username": user}
            cursor.execute(UPDATE_QUERY, data)
        cursor.close()
        db.close()


if __name__ == "__main__":
    main()

But if we add that as executable = script-login /etc/dovecot/dpsu.py to our imap-postlogin service, as the howto suggests, the users won't be able to login anymore:

Error: Post-login script denied access to user

WAT?

Remember that shell script I wanted to avoid? It ends with exec "$@".

Turns out the script-login "API" is rather interesting. It's not "pass in a list of scripts to call and I'll call all of them". It's "pass a list of scripts, I'll execv the first item and pass the rest as args, and every item is expected to execv the next one again". 🤯

With that (cursed) knowledge, the script becomes:

#!/usr/bin/env python3

import os
import sys

import MySQLdb
import passlib.hash

DB_SETTINGS = {"host": "127.0.0.1", "user": "user", "password": "password", "database": "mail"}
SELECT_QUERY = "SELECT password_enc FROM mail_users WHERE username=%(username)s"
UPDATE_QUERY = "UPDATE mail_users SET password_enc=%(pwhash)s WHERE username=%(username)s"

SCHEME = "bcrypt"
EXPECTED_PREFIX = "$2b$"


def main():
    # https://doc.dovecot.org/2.4.3/core/config/post_login_scripting.html
    # https://doc.dovecot.org/2.4.3/howto/convert_password_schemes.html
    user = os.environ.get("USER")

    plain_pass = os.environ.get("PLAIN_PASS")
    if plain_pass is not None:
        db = MySQLdb.connect(**DB_SETTINGS)
        cursor = db.cursor()
        cursor.execute(SELECT_QUERY, {"username": user})
        result = cursor.fetchone()
        current_pwhash = result[0]

        if not current_pwhash.startswith(EXPECTED_PREFIX):
            hash_module = getattr(passlib.hash, SCHEME)
            pwhash = hash_module.hash(plain_pass)
            data = {"pwhash": pwhash, "username": user}
            cursor.execute(UPDATE_QUERY, data)
        cursor.close()
        db.close()

    os.execv(sys.argv[1], sys.argv[1:])


if __name__ == "__main__":
    main()

And the passwords are getting gradually updated as the users log in. Once all are updated, we can remove the post-login script and drop the auth_allow_weak_schemes = yes.

28 March, 2026 10:11PM by evgeni

Russell Coker

Communication and Hostile AIs

We seem to be entering an “AI” apocalypse of sorts, they aren’t going to kill us or even take our jobs. What they are doing is destroying the Internet commons by filling it with rubbish. This isn’t even real AI, just pattern matching and prediction systems, mostly LLMs.

The Problem

Scott Shambaugh’s saga of being attacked and defamed by an OpenClaw AI bot is interesting and raises some disturbing possibilities for future online discussion [1]. Imagine what it would be like if everyone who was in any way notable for free software work had 100 such bots going after them.

Dania Dumas wrote an insightful blog post about why OpenClaw is impossible to secure and why it won’t go away [2].

Bruce Schneier and Nathan E. Sanders wrote an insightful article about the AI generated text arms race [3] primarily concentrating on situations in which text that was assumed to be written by humans but was actually written in bulk by bots was performing a DOS attack on people who were reviewing it. There are many situations such as book publishing and publishing letters to the editor of newspapers where getting new material from unknown people is an important part of the job but where there are also people making low quality submissions that are almost a DOS attack at the best of times.

Currently the email spam problem continues to get worse and when LLM use increases it will get significantly worse. Email encryption isn’t viable [4]. The PGP web of trust never really worked well as it’s too difficult for most users.

The amount of “AI” generated content that’s being recommended to users on platforms like YouTube and Facebook is steadily increasing and the amount of LLM generated commentary that purports to be from real people on Twitter and Facebook is also increasing. Here’s an informative blog post by Erich Schubert about this [5].

Potential Solutions

Surrender?

One option and possibly the default option is to surrender to this and just let everything we built on the Internet over decades get destroyed. Whether to surrender is a decision that can be made on a per-service basis.

Twitter is pretty much useless anyway, I quit Twitter because Elon deliberately made it suck [6]. In my opinion this is not surrendering to what’s being done there, I’m just stopping wasting time on it and using better options. I used to have about 300 followers on Twitter and I don’t think that many of them would ever choose to stop following me, so I presume that about 1/3 of the people following me have decided to totally quit Twitter and delete their accounts. I also presume that some of the remainder have done the same as me and just kept a mostly inactive account. If Elon suddenly stopped being a stupid asshole it probably wouldn’t change anything as the value of the system was connections to others. Some people will consider my abandonment of Twitter as surrender and I accept that it’s not an unreasonable opinion. I think that the possibly 100 Twitter followers of mine who deleted their accounts surrendered.

Facebook has been becoming a worse service, it’s business model is becoming increasingly exploitative and it’s interface is designed to be addictive. It’s probably best avoided unless you really need it. The only good thing about Facebook at the moment is that Facebook Marketplace doesn’t take a cut on sales and there are some really good deals on computers if you know what to look for. Unfortunately Facebook has a large number of users who are from marginalised communities and have no other alternatives for communication. It would be good to get them migrated to other platforms.

We could just give up on a lot of general communications services and have everyone accept that good content is drowned out by rubbish and have the Internet become divided between people who accept the rubbish and those who cease using large portions of the Internet environment to avoid it.

Using Non Commercial Services

Lemmy is a good FOSS federated alternative to Reddit which also covers some of the uses of Facebook. It needs more users to get critical mass but is still quite usable. A post that might get a dozen comments on Reddit may get 1 comment on Lemmy but that one comment will be a good one. Reddit doesn’t appear to be attacked much by LLM generated content at least not yet. Even if the Reddit model proves to be resilient to LLM attack the Lemmy software can be used to replace some things that are done on Facebook,

Mastodon is a good FOSS federated replacement for Twitter, it has a decent user-base including some VIPs. While it is aimed at the Twitter use case it can also cover a significant part of the Facebook use case.

There are some other FOSS social media programs which could take over other parts of the commercial social media environment.

Generally commercially run Internet services will have a financial incentive to allow the problems to get worse so we need to rely on FOSS software, non-commercial implementations, and government services.

Web Search

For a long time Google has had a monopoly on web search, but now they default to including an “AI Overview” at the start of the results which is sometimes useful but also sometimes very wrong. You can use the search URL “https://www.google.com/search?q=%s&udm=web” to get google results without rubbish. But I presume that they will break that if it gets too popular.

Searxng is a AGPL licensed metasearch engine that aggregates results from other engines, here’s the Searxng source [7] and here’s a list of Searxng instances if you want to try one [8].

Even using meta search engines like Searxng won’t help if the original data is overloaded with spam, but alleviating the problem is a good temporary measure.

Web of Trust for the Web?

I’ve idly considered the possibility of having some sort of rating system for web pages that uses a web of trust so that you can securely use trust ratings of friends of friends etc. But given all the difficulties in using a web of trust for signing GPG key for software developers (the demographic that is most skilled at doing such things) it doesn’t seem viable.

Should we surrender the idea of having a usable public web?

In the early days of the web (before Google) it was standard practice to rely on recommendations from other people or from trusted sites to find other sites, that could be considered to be an informal web of trust. We could go back to that sort of usage pattern if Google and many of the big sites get overwhelmed by LLM generated spam.

Wikipedia

I believe that Wikipedia will be at the front lines of this battle. It’s model has always included anonymous contributions. Benjamin Mako Hill wrote an interesting blog post about research he did with Kaylea Champion into Wikipedia pages on taboo topics which have a larger portion of contributors choosing to be anonymous than non-taboo pages [9]. Wikipedia also has a long history of being abused for various reasons, one that I witnessed was someone putting false content into Wikipedia pages to immediately cite them in support of their facebook arguments. That sort of thing can be dealt with at human scale but a large scale attack by bots is a different problem to solve. Also with the recent developments in AI developing multiple web sites entirely populated for the purpose of supporting one fake entry in Wikipedia is plausible.

The upside of these attacks that I predict is that they will attract the attention of all the people who have skills related to developing counter-measures. While LLM bots are filling the inboxes of publishers with rubbish and messing up the stackoverflow comments section not a lot of people are bothered, but once the attacks on Wikipedia get serious everyone will take notice.

National AI

Bruce Schneier and Nathan E. Sanders wrote an interesting blog post about nationalised public AI [10]. While that won’t directly address this issue it will get the right technology in the hands of people who can use it in the right way.

Conclusion

This is going to be a difficult problem to solve, more difficult than the email spam problem we have been unable to solve after 30 years of working on it.

This is also a very important problem, we are currently in an age where we have access to information that most people couldn’t even dream of 30 years ago. We also have disinformation that combines some of the worst aspects of authoritarian regimes throughout history combined with the worst aspects of cult brainwashing. If we lose access to the information but the disinformation remains (or get worse) then the result will be terrible.

I don’t have great ideas for solving this. I have outlined some small ideas to mitigate things and I hope that others can expand on them.

Please write comments with any good ideas you have, or even ideas that don’t totally suck. A problem this difficult is not going to be solved in a blog comment, but a blog comment might point in the right direction.

28 March, 2026 03:08PM by etbe

James Valleroy

Stagger v0.1.0

I’ve decided it’s time to tag a v0.1.0 release on my roguelike game project, Stagger. It’s more of a small demo than a full game at this point. It is turn-based, and has purely text-based “graphics”, like the original Rogue.

Here’s a “screenshot”:

####################
#..................#
#.@................#
#....|.............#
#..................#
#.........>........#
#..................#
#..................#
#..................#
####################

HP: 10/10

You can find the repository at either of these locations:
https://git.sr.ht/~jvalleroy/stagger
https://codeberg.org/jvalleroy/stagger

The game is developed in Python, using ncurses. It is dual-licensed under AGPL and MPL.

28 March, 2026 10:54AM by James Valleroy

Valhalla's Things

Ink Lightfastness Tests 2026

A borderless frame set on a table outdoors, with two sheets of paper a vertical half of which is covered by black paper, while the other half has lines with an ink name and a small filled rectangle, all in the ink itself.

Note

This post will be updated in the next weeks with the test results as they become available.

Note

Most of the images in this post have no real alt-text: they are all scans of the test sheet at various stages through the test, and the results visible on them are described in detail at the end of the post.

Most of the time, what people write by hand will either end up inside a notebook in a drawer or cupboard where it’s well protected, or thrown in the recycling where it doesn’t matter. There are times, however, when things will be exposed to light: it doesn’t matter whether it’s a work of artistic calligraphy that you want to frame or a passive-aggressive notice left in the atrium of a building; it is useful to know whether the work will remain legible or it will fade into nothing in a short time.

A few inks are tested by the producers for lightfastness according to some established standard, a few others are declared lightfast in a generic way, but a lot come with no indication at all. Proper testing according to the standard scales requires significant equipment to precisely control the exposure, but it’s significantly easier — and fun — to do a simple test to divide the inks into three categories:

suitable for framed calligraphy, i.e. it looks the same after 3 months of direct sun exposure;
suitable for complaining about the way your neighbours deal with the trash, i.e. still readable after 3 months of exposure;
not suitable for either, i.e. has faded significantly in the same time.

In the past I’ve done some such tests by taping some sheets to a south-east facing window, and I’ve noticed that most of the results were already apparent after a month, and there was basically no difference between two and three months of exposure, but spring equinox to summer solstice is a nice timeframe to use for such a test (and it leaves time for a second test of different materials from summer solstice to autumn equinox), so this is what I’ve chosen to do this year.

Rather than a window, now I have access to a south-facing covered balcony that is protected from rain but receives quite a bit of direct sun, so instead of taping sheets to the windows¹ I’ve prepared a sturdy cardboard panel that I can leave on a table on the balcony, hopefully safe from the rain, but well exposed to the sun.

And then made a quick test, and realized that without the window glass in front, the black strip used to cover the unexposed half of the sample doesn’t lay flat and lets some sun in, so I used an old cheap² glass frame instead of the panel.

The contents of an order from a fountain pen shop, spread out on a table: a couple of cheap pens, a couple bottles of ink, a converter, a small ritter sport chocolate and a bag full of 5 ml vials with 2 ml of ink each, and a thank-you note from the seller (Steffi).

The next step, already in January, was mentioning in a fountain-pen enthusiasts forum that I planned such a test, and asking if people were interested in having me buy a few samples of more inks when I was buying my next pen. The word “enthusiasts” is probably a hint of the reason why soon afterwards I received a package with the pen I had planned to buy, its converter, and a couple dozens ink samples. And then a couple envelopes with additional samples of inks that weren’t available on the shops, from said enthusiasts.

Added to the inks I already had acquired since the last lightfastness test, it meant that they couldn’t all fit in one single page, and thus I had some room to add some inks I had already tested: some were requests, and for others I tried to select ones that felt relevant. Since I’m changing the test setup, I’ve decided I should probably keep doing this until I’ve tested again all of the inks I still have available.

see below

For the paper, I’ve used A4 sheets of Clairefontaine Dessin Croquis 160 g/m², one of my staples that I’m sure I will have available in the next years, printed with a dot pattern with a laser printer, using this pdf. And as for the pen I’ve used a fresh Brause n°361 nib: loading a fountain pen with all of these inks wouldn’t be a reasonable effort, and the 361 is one of the writing implements I use most anyway. I also used a glass pen to fill a couple of squares on the paper with more ink. One side of each sheet was then covered with a strip of 300 g/m² black paper (also from Clairefontaine), kept in place with three dots of non-permanent two sided tape, put in the frame and set out in the sun on the morning of 2026-03-20, the day of the spring equinox.

see below

While I was filling the sheet for the lightfastness tests, I decided to also prepare a second set of sheet, for a liquid resistance drop test.

On each line, beside the name of the ink, I added five sets of crossing parallel lines, and let everything dry for a few days.

Then I used a syringe to put a drop of a liquid on each set of lines, waited for it to be absorbed into the paper and to dry, at least overnight, but sometimes also for a day or two (life happened), and then looked at the results and did the next test.

The first liquid was water, with the usual wild difference between washable and permanent inks, and all of the intermediate possibilities.

The second liquid was isopropyl alcohol, and I was surprised to see that, with very few exceptions, most inks didn’t change at all. I wonder whether that’s related to the fact that instead of forming a drop it was absorbed almost immediately into the paper, and dried in a very short time.

The third liquid was hydrogen peroxide: beside the individual results I noticed that its column yellowed visibly; I wonder whether that means that the paper I used has optical brighteners, and it will also yellow under the sun: that wouldn’t be ideal, but it would also be a surprise, for paper that is acid free and sold for arts.

The fourth liquid was citric acid, by mixing a bit less than a teaspoon of citric acid granules in just enough very warm water (heated to 70°C, i.e. the lowest temperature available on my kettle) to dissolve most of the acid. I forgot that I had some old PH strips until one hour after I’ve put the drop on the paper, and I don’t know whether something had changed, but when I did remember about them it showed a deep red between 1 and 2. I don’t think I can trust those strips too much, however.

This backfired badly: the drop of citric acid never dried out, but formed a sticky paste that prevented me from scanning the results, and I’m not sure whether I’ll do the last test, which was supposed to be household bleach.

see below

Luckily I had scanned the partial results, and they are shown here.

see below

After one full day with plenty of sun, nothing really had changed, except possibly for a vague hint that the Herbin Bleu Myosotis may have have been a bit lighter than it started, but it may also have been a suggestion.

see below

After three days, however, some results started to show, with the most fugitive inks starting to be visibly changed, becoming either paler or in some case duller.

see below

And the full week showed more of that, with a few more inks starting to show visible change.

see below

After two weeks the paper had significantly yellowed, something I did not expect from drawing paper (and which means that I will probably use a different paper when making similar tests in the future).

As for the inks, there were a couple more inks with visible changes, but mostly it was more of the same as seen in the previous week.

see below

Three weeks started to show changes in the black and most irongall inks, and of course more changes in the even less resistant inks.

These are the inks I’ve tested, and here I’ll add notes on the results, as soon as they will be available, keeping this section updated.

When nothing is mentioned, it means that there were no changes, either under the light or under the various liquids.

Lamy Sepia

Not resistant to water, the drop becomes an uniform colour spot.

After one week it started to be just slightly paler, more so after three weeks.

Sheaffer Skrip Red

Not resistant to water, the drop becomes an uniform colour spot.

After one week it started to be just slightly paler, more so after three weeks.

Waterman Audacious Red

Not resistant to water, the drop becomes an uniform colour spot.

After three days it started to be just slightly paler, after a week visibly so.

Waterman Harmonious Green

Not resistant to water, the drop becomes an uniform colour spot; the hydrogen peroxide drop looks a bit lighter than the one with just water.

After one week it started to be just slightly paler, more so after three weeks.

Waterman Mysterious Blue

Not resistant to water, the drop becomes an uniform colour spot; the hydrogen peroxide drop is significantly lighter and tends towards green.

After two weeks it started to be just slightly paler, after three weeks it was more gray.

Waterman Serenity Blue

Not resistant to water, the drop becomes an uniform colour spot; the hydrogen peroxide drop is almost completely bleached to a light yellow.

After one week it started to be a bit duller.

Visconti Blue

Not resistant to water, the drop becomes an uniform colour spot.

After one week it was visibly duller, looking darker than the original. After three weeks it was duller, and lighter.

Montblanc Royal Blue

Not resistant to water, the drop becomes an uniform colour spot; the hydrogen peroxide drop is almost completely bleached to a light yellow.

After one week it started to be just slightly duller, more so after two weeks. After three weeks it was also paler.

Montblanc Mystery Black

Not resistant to water, the drop becomes an uniform colour spot.

After three weeks it started to be a bit paler.

Aurora Nero

Not resistant to water, the drop becomes an uniform colour spot.

After three weeks it started to be a bit more brown.

Online Duft Blueberry

Not resistant to water, the drop looks very washed out, although a hint of the original shape can be guessed; the hydrogen peroxide drop is almost completely bleached to a light yellow.

After one week it was visibly paler and duller. After three weeks significantly so.

Diamine Forever Ink - Smoky Mauve

Diamine Forever Ink - Honey Pot

Diamine Forever Ink - Coral Blaze

Diamine Forever Ink - Red Ochre

Diamine Graphite

Not resistant to water, the drop becomes an uniform colour spot.

Diamine Rustic Brown

Not resistant to water, the drop becomes an uniform colour spot.

After three weeks it started to be very slightely paler.

Diamine China Blue

Not resistant to water, the drop becomes an uniform colour spot; the hydrogen peroxide drop is almost completely bleached to a light yellow.

After three weeks it started to be paler and duller.

Diamine Inkvent Purple Edition - Glacier

Not resistant to water, there is a drop of uniform colour, but it maintains a somewhat recognisable shade of the original shape.

After three weeks it started to be lighter.

Fountainfeder STEVE

Not resistant to water, there is a drop of uniform colour, but it maintains a somewhat recognisable shade of the original shape.

After two weeks the base colour had changed to a pink rather than purple.

Pilot Iroshizuku Syo Ro

Not resistant to water, there is a drop of uniform colour, but it maintains a somewhat recognisable shade of the original shape.

Pilot Iroshizuku Shin-Kai

Not resistant to water, there is a drop of uniform colour, but it maintains a somewhat recognisable shade of the original shape.

After two weeks it had become lighter and more purple.

Rohrer & Klingner IG Ebony

Not resistant to water, there is a drop of uniform colour, but it maintains a recognisable shade of the original shape; under hydrogen peroxide the shade is significantly lighter.

KWZ IG Orange

Not resistant to water, the drop becomes an uniform colour spot; the hydrogen peroxide drop is significantly bleached to a light orange.

Kallipos.de Schwarze Eisengallus-Tinte

Water stains the paper, leaving however the original shape quite visible; is it almost completely bleached by hydrogen peroxide.

After three weeks it started to be very slightely lighter.

Kallipos.de Blaue Eisengallus-Tinte

Water stains the paper, leaving however the original shape quite visible; is it almost completely bleached by hydrogen peroxide.

After two weeks it had started to become lighter and more gray.

Rohrer & Klingner IG Salix

Water stains the paper, leaving however the original shape quite visible; is it almost completely bleached by hydrogen peroxide.

After two weeks it had become lighter and significantly more gray.

Rohrer & Klingner IG Scabiosa

Water stains the paper with a significant purple spot, leaving however the original shape quite visible; is is a bit bleached by hydrogen peroxide, but still quite readable.

Pelikan Edelstein Tanzanite

Not resistant to water, the drop becomes an uniform colour spot, but there is a visible trace of the original shape.

After three weeks it started to be slightly paler.

Montblanc Burgundy Red

Not resistant to water, the drop becomes an uniform colour spot, with just a hint of the original shape; slightly bleached by hydrogen peroxide.

After three weeks it started to be paler.

Cifra inchiostro finissimo verde alla lavanda

Not resistant to water, the drop becomes an uniform colour spot; quite bleached to a light yellowish green by hydrogen peroxide.

After one week it was visibly paler.

Sennelier Abstract acrylic ink 917 purple

The Feather Pen Ink

Eloquentia Inchiostro nero

DeAtramentis Document Blue

DeAtramentis Document BlueGrey

DeAtramentis Document Brown

DeAtramentis Document Fuchsia

DeAtramentis Document Grau

DeAtramentis Document Green Grey

DeAtramentis Document Light Grey

DeAtramentis Document Moosgrün

DeAtramentis Document Orange

DeAtramentis Document Purpurviolett

DeAtramentis Document Urban Sienna

KWZ Sheen Machine

Not resistant to water, the drop becomes an uniform colour spot; the hydrogen peroxide bleached away the red sheen. This was one of the only two inks to react to isopropyl alcohol, which caused a pale cyan halo around the lines.

After three days it was still perfectly readable, but had visibly lost some red sheen, after one week the red had completely gone and it looked very dark blue (but still shiny)

KWZ Walk over Vistula

Not resistant to water, the drop becomes an uniform colour spot.

KWZ Warsaw Dreaming

Not resistant to water, the drop becomes an uniform colour spot.

Octopus Neon Violett

Water very lightly stains the paper, leaving however the original shape quite visible. The other ink that reacted to isopropyl alcohol, with a pale purple halo around the lines.

After two weeks it was paler, more pink.

Octopus Write & Draw Elephant Black

Platinum blue black

Water stains the paper, leaving however the original shape quite visible; it is significantly bleached by hydrogen peroxide.

After three weeks it started to become gray.

Pelikan 4001 Brillant-Schwarz

Not resistant to water, the drop becomes an uniform colour spot.

After three weeks it was a bit more brown than black.

Pelikan 4001 Blau-Schwarz

Water stains the paper, leaving however the original shape quite visible; it is significantly bleached by hydrogen peroxide.

After three weeks it started to become gray.

Pelikan 4001 Königsblau

Not resistant to water, the drop becomes an uniform colour spot, with just a hint of the original shape; significantly bleached by hydrogen peroxide.

After three days it had started to be slightly paler. After three weeks it was significantly desaturated.

Herbin Bleu Myosotis

Not resistant to water, the drop becomes an uniform pink spot, significantly bleached by hydrogen peroxide.

After three days it was already visibly paler, after one week it was a pale grey.

Faber Castell Royal Blue

Not resistant to water, the drop becomes an uniform colour spot, with just a hint of the original shape; significantly bleached by hydrogen peroxide.

After three days it was slightly duller, after two weeks definitely so.

Koh-I-Noor Fountain pen ink blue

Not resistant to water, the drop becomes an uniform colour spot, with just a hint of the original shape; significantly bleached by hydrogen peroxide.

After three days it had started to be slightly paler, more so after one week when it had also turned grey.

Koh-I-Noor Document Ink Blue

Koh-I-Noor Document Ink Black

Water leaves a very light stain, but the original shape doesn’t look changed.

DeAtramentis Document Black

Waterman Intense Black

Not resistant to water, the drop becomes an uniform colour spot, with a trace of the original shape still visible; very lightly bleached by hydrogen peroxide.

After three weeks it started to look a bit more brown.

Herbin Perle Noir

Not resistant to water, the drop becomes an uniform colour spot, with a trace of the original shape still visible.

After three weeks it started to look a bit more brown.

Parker Quink black

Not resistant to water, the drop becomes an uniform colour spot.

Platinum Carbon black

Rohrer & Klingner Documentus Black

Sailor Pigment Kiwaguro

Platinum Dyestuff Red

Not resistant to water, the drop becomes an uniform colour spot; very lightly bleached by hydrogen peroxide.

After three weeks it was a bit paler.

Noodler’s Eternal Polar Blue

which would be spend the day covered by mostly closed shutters anyway, because they receive quite a bit of direct sun, and we don’t want that to enter the house during the summer.↩︎
and thus, I hope, not especially UV-filtering.↩︎

28 March, 2026 12:00AM

March 27, 2026

Jonathan Dowland

Digital gardening

I was reading a post on Alex Chan's website¹ that referenced the concept of digital gardens, a concept/analogy for organising information which dates back to the 90s. This old concept is getting new traction today by contrasting the approach with "endless stream" as used and abused by social media, but also how blogs are typically presented.

This site, my homepage, has a blog, and that's the bit that most people who interact with the site will experience. Partly, because it's the bit that gets syndicated out: via feeds; on Planet Debian and downstream from it; once upon a time on Twitter; nowadays on the Fediverse.

However there's more to my homepage than that. The rest of it may be of little interest to anyone beside me, but it's useful to me, at least. So I may switch focus a little bit from mainly writing blog posts, and tend to the rest of the garden a bit more.

Some recent seeding and pruning: Recently my guest status at Newcastle University came up for renewal, so I wrote down my goals in the Historic Computing Committee for the next year or so, and put them here: nuhcc. I've also been pondering what I'm up to in Debian at the moment, so took some time to add my current projects to that page.

I'm reminded that I should really publish a "blog roll" of cool blogs I'm following at the moment, of which Alex Chan's is one.↩

27 March, 2026 10:05PM

Bits from Debian

New Debian Developers and Maintainers (January and February 2026)

The following contributors got their Debian Developer accounts in the last two months:

Jongmin Kim (jmkim)
Yifei Zhan (yifei)
Sébastien Noel (twolife)

The following contributors were added as Debian Maintainers in the last two months:

Andreas Dolp
Dandan Zhang
M Hickford

Congratulations!

27 March, 2026 10:00PM by Jean-Pierre Giraud

Paul Tagliamonte

librtlsdr.so for fun and profit

Interested in future updates? Follow me on mastodon at @paul@soylent.green. Posts about hz.tools will be tagged #hztools.

It’s well known and universally agreed that radios are cool. Among the contested field of coolest radios, Software Defined Radios (SDRs) are definitely the most interesting to me. Out of all of my (entirely too many) SDRs I own, the rtlsdr is still my #1. It’s just good. It’s a great price, extremely capable, reliable, well-supported, and compact. Why bother with anything else? Sure, it can’t transmit, uses a (fairly weird) 8 bit unsigned integer IQ representation, limited sampling rate, limited frequency range – but even with all that, it’s still the radio I will pack first. Don’t get me wrong, I love my Ettus radios, PlutoSDRs, HackRFs, my AirspyHF+ - they’re great! I just always find myself falling back to an rtl-sdr, every time.

Perhaps the best reason to use an rtlsdr is the absolutely mind-boggling amount of cool stuff people have written for it. The rtlsdr API is super easy to use, widely supported if you’re building on top of existing radio processing frameworks – it’s still a shock to me when something omits rtlsdr support.

sparky

Over the last 7 years, I’ve been learning about radios – I got my ham radio license (de K3XEC), hacked on some cool stuff where I’ve learned how radios work by “doing”, and even was lucky enough to give my first rf-centric talk at districtcon. Embarrassingly, I still haven’t gotten around to learning how the fancy stuff like GNU Radio works. I’m sure I’m going to love it when I do.

As part of this, I’ve also cooked up some very unprofessional formats and protocols I use for convenience. Locally, all my on-disk captures are stored in rfcap or more recently arf (post on this coming soon), while direct SDR access at my house is almost entirely a mix of the widely used rtl-tcp protocol, and my “riq” protocol (post on this coming soon). Both rtl-tcp and riq operate over the network, so I don’t have to bother with plugging things into USB ports, and I can share my radios with my friends.

All of that work sits in my current generation of radio processing code, “sparky” (a reference to spark-gap transmitters), which is a heap of Rust, supporting everything from no_std for embedded experiments, conditional support for interfacing with all the radios I own, and tokio-based async support in addition to blocking i/o for highly concurrent daemons. This quickly advanced beyond my old Go-based code (hz.tools/go-sdr), which I archived so I can focus on learning. I still think Go is a great language to write RF code in – but I can’t focus on that tech tree anymore.

Of course, this now poses a new problem – no one supports my format(s) or radio protocol(s), since, well, I’m the only one using them. I’ve committed a fair amount of my hardware to this setup, and yanking it from the rack to try something out does pose a bit of a pickle. This isn’t a huge deal for learning, but it does make it tedious to try out something from the internets.

librtlsdr.so

Thankfully, Rust has robust support for wrap[ping itself] in a grotesque simulacra of C’s skin and mak[ing its] flesh undulate, which is an attractive nuisance if i’ve ever seen one. Naturally, my ability to restrain myself from engaging in ill-advised rf adventures is basically zero, so it’s time to do the thing any similarly situated person would do – reimplement the API and ABI of librtlsdr.so, backed with sparky instead.

Since enumeration of devices is going to be annoying (specifically, they’re over the network), I decided early-on to rely on an explicit list of devices via a configuration file. I’d rather only load that once so programs don’t get confused, so I opted to use a CTOR to run a stub when the ELF is linked at runtime.

// lightly edited for clarity

#[used]
#[expect(unused)]
#[unsafe(link_section = ".init_array")]
pub static INITIALIZE: extern "C" fn() = sparky_rtlsdr_ctor;

#[unsafe(no_mangle)]
pub extern "C" fn sparky_rtlsdr_ctor() {
 let config: Config = {
 if let Ok(config_bytes) = std::fs::read("/etc/sparky-rtlsdr.toml") {
 toml::from_slice(&config_bytes).unwrap()
 } else {
 Config { device: vec![] }
 }
 };
 CONFIG.set(config);
}

Next, it’s time to start with the basics. Opening and closing a handle using rtlsdr_open and rtlsdr_close. Given we don’t control the runtime, and the rtl-sdr device handle is opaque (for good reason!), I opted to smuggle a rust Box<Device> non-FFI safe heap-allocated struct through the device handle pointer, and let C take ownership of the Box. No one should be looking in there anyway.

// lightly edited for clarity

#[unsafe(no_mangle)]
pub unsafe extern "C" fn rtlsdr_open(dev: *mut *mut Handle, index: u32) -> int {
 let config = &CONFIG.device[index as usize];
 let sdr = match config.load() {
 Ok(v) => v,
 Err(err) => {
 return -1;
 }
 };
 let handle = Box::new(Handle { config, sdr });
 unsafe { *dev = Box::into_raw(handle) };
 0
}

#[unsafe(no_mangle)]
pub unsafe extern "C" fn rtlsdr_close(dev: *mut Handle) -> int {
 let dev = unsafe { Box::from_raw(dev) };
 drop(dev);
 0
}

With that in place, we can chip away at the API surface, translating calls as best as we can. I won’t bother listing it all, since it’s not very interesting – but here’s an example implementation of rtlsdr_set_sample_rate and rtlsdr_get_sample_rate. These calls are translating from an rtl-sdr frequency (which is a u32 containing the value as Hz) into a sparky Frequency type, and invoking get_sample_rate or set_sample_rate on the device’s rust handle. Since each device implements the sparky Sdr trait, the actual underlying device doesn’t matter much here.

#[unsafe(no_mangle)]
pub unsafe extern "C" fn rtlsdr_set_sample_rate(dev: *mut Handle, rate: u32) -> int {
 let dev = unsafe { &mut *dev };
 let rate = Frequency::from_hz(rate as i64);
 if let Err(err) = dev.sdr.set_sample_rate(dev.channel, rate) {
 return -1;
 }
 0
}

#[unsafe(no_mangle)]
pub unsafe extern "C" fn rtlsdr_get_sample_rate(dev: *mut Handle) -> u32 {
 let dev = unsafe { &mut *dev };
 let freq = match dev.sdr.get_sample_rate(dev.channel) {
 Ok(freq) => freq,
 Err(err) => {
 return 0;
 }
 };
 freq.as_hz() as u32
}

After repeating this process for the rest of the stubs I could (and otherwise setting error conditions if the functionality is not supported), I was ready to try it out. Within sparky, I patched my “MockSDR” (basically a Sdr traited Mock type) to implement the same testmode IQ protocol that the RTL-SDR has, and decided to see if rtl_test from apt without any changes could be fooled.

$ rtl_test
No supported devices found.

Great, cool. No devices plugged in. Looks great. Let’s try it with my librtlsdr.so LD_PRELOAD-ed into the binary first:

$ LD_PRELOAD=target/release/librtlsdr.so rtl_test
Found 1 device(s):
 0: hz.tools, mock sdr, SN: totally legit no tricks

Using device 0: sparky mock sdr
Supported gain values (0):
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 0
$

Outstanding. Even more outstandingly, if I change my testmode implementation to skip samples, rtl_test correctly reports the errors – I think it’s showing promise! On to try the real endgame here – let’s have our new librtlsdr.so connect to an rtl-tcp endpoint and see if rtl_fm works:

LD_PRELOAD=target/release/librtlsdr.so \
 rtl_fm -d 1 -s 120k -E deemp -M fm -f 90.9M | \
 ffplay -f s16le -ar 120k -i -
Found 2 device(s):
 0: hz.tools, mock sdr, SN: totally legit no tricks
 1: hz.tools, rtl-tcp, SN: node2.rf.lan:1202

Using device 1: sparky rtltcp node2
Tuner gain set to automatic.
Tuned to 91170000 Hz.
Oversampling input by: 9x.
Oversampling output by: 1x.
Buffer size: 7.59ms
Sampling at 1080000 S/s.
Output at 120000 Hz.

And there it was! Not the best audio quality (mostly due to my inability to correctly read the rtl_fm manpage to tune the filter and downsample/oversampling rates to audio), but it’s definitely passable. I figured I’d try something that was a bit more interesting next – gqrx, since it’s super handy, I use it a ton, and will definitely amuse me to no end. To my surprise and delight, LD_PRELOAD=target/release/librtlsdr.so gqrx wound up running, and I saw my devices pop right up in the setting menu:

Huge. Huge. Amazing. It did crash as soon as I tried to actually use the radio, but after fixing a few dangling bugs in the API surface (and some assumptions I think some underlying gnuradio driver may be making that I need to double check in the code), I was able to get a super solid stream of broadcast fm radio, with gqrx being none the wiser. It thought it was “just” talking to the device it knows as rtl=1.

Nice. I can’t wait to try this with the rest of the rtl-sdr based tools I like having around using my riq protocol next. I don’t think that’ll be worth a post, but hopefully I’ll get around to publishing details on that stack next.

epilogue

Well. That’s it. End of story. A bit anti-climatic, sure. While this new shim will provide me endless minutes of mild amusement, I could see using this to expose my sparky testing utilities via librtlsdr.so – my “mock sdr” driver allows for replaying captures off disk, which could be interesting to make sure that signals are still properly decoded after changes, or instrument performance changes (via SNR, BER, packets observed, etc) on reference samples I have on my NAS. Maybe that’ll come in handy one day!

Truth be told, I’m not sure I actually want to encourage anyone to do this for real (although I think I’ll definitely be using it on my LAN to see what happens). I also don’t have a repo to share – I don’t particularly feel with dealing with the secondary effects of publishing sparky (and sparky-rtlsdr) yet, since i’m still getting my feet under me on the radio aspect of all this.

I’ll be sure to post updates if anything changes with this here (tagged sparky) and at @paul@soylent.green. I can’t wait to post more about some of the odd sidequests (like this one!) i’ve completed over the last few years – I’ve been waiting to feel confident that my work has matured and was withstood the new problems i’ve thrown at it, and it largely has.

It’s my hope that these projects (and this project in particular) has provided a glimpse into the world of software defined radio for my systems friends, and a bit about systems for my radio friends. It’s not all magic, and I hope someone out there feels inclined to have some fun with radios themselves!

27 March, 2026 05:30PM

Arturo Borrero González

New job at Chainguard

A few months ago, in June 2025, I joined Chainguard, a company focused on software supply chain security. This post is a reflection on how I got here, what I’ve been doing, and why this role feels like a natural fit for my interests in Linux and open source technology.

The company and its mission

Chainguard’s mission is to make the software supply chain secure by default. The company is built around the idea that the software we all depend on — from operating system packages to container base images — carries hidden risk in the form of vulnerabilities, unverified provenance, and untrusted build processes.

The company is perhaps best known for Chainguard Images: a catalog of minimal, hardened container base images that are continuously rebuilt and kept free of known CVEs. Each image is accompanied by a signed SBOM (Software Bill of Materials) and a verifiable provenance attestation, making it possible to cryptographically verify what went into a given image and how it was built.

Chainguard has an extensive catalog of software, and maintaining it up-to-date and CVE-free is a significant engineering challenge.

What I do

I joined the Chainguard Sustaining Engineering team as a Senior Software Engineer. We are responsible for maintaining packages and images in the software catalog up-to-date and CVE-free. The core of the business, basically.

We focus on the horizontal dimension of the catalog (pretty much all packages and images).

With +30,000 packages and +2,000 images, this is indeed an interesting task.

My role as Debian Developer, and my experiencie in the Debian LTS project was extremely valuable when joning this new team.

Looking ahead

Software supply chain is truly a deep topic, gaining more and more relevance every day, especially as new technologies emerge and get adopted everywhere.

Since early in my career, I saw a recurrent problem of how companies, enterprises, or even governments, relate to and consume open source software, in a reliable, secure way. I believe Chainguard is doing the right things in the ecosystem, and I’m happy to be participating in the effort.

27 March, 2026 08:00AM

Samuel Henrique

I use curl with ECH btw (in Debian)

tl;dr

This is an experimental feature that, for the first time, brings full ECH support to curl on Debian using OpenSSL.

Starting with curl 8.19.0-3+exp2 (Debian Experimental), you can now use ECH, with HTTPS-RR and DoH for maximum privacy.

curl 8.19.0-3+exp2 is quite fresh at the time of writing, bear in mind that your repository might not have synced the package yet, all mirrors should have it by March 27th 14:00 UTC.

# defo.ie is a test server that confirms whether ECH was successfully used
curl -v --ech hard https://defo.ie/ech-check.php
# For Encrypted Client Hello (ECH) + DNS over HTTPS (DoH)
curl -v --ech hard --doh-url https://1.1.1.1/dns-query https://defo.ie/ech-check.php

"--ech hard" tells curl to refuse the connection entirely if ECH cannot be negotiated.

Or, if you would like to try it out in a container:

podman run debian:experimental /bin/bash -c 'apt install --update -t experimental -y curl && curl -v --ech hard --doh-url https://1.1.1.1/dns-query https://defo.ie/ech-check.php'

(in case you haven't noticed, apt now has the --update option for the upgrade and install commands)

For Privacy

CloudFlare calls it "the last puzzle piece to privacy" in their must-read announcement: https://blog.cloudflare.com/announcing-encrypted-client-hello/.

Encrypted Client Hello (rfc9849) encrypts the "which website are you connecting to?" part of the TLS handshake that was previously visible in plaintext.

HTTPS-RR (rfc9460) is a DNS record type that publishes connection parameters for a service, including the public key clients need to perform ECH.

DNS Over HTTPS (rfc8484) encrypts DNS queries by tunneling them over HTTPS, hiding what domains you're looking up from network observers.

When all three operate together over a CDN with shared IP space, the target domain name is hidden from passive observers; the HTTPS-RR record is queried over DoH in order to retrieve the ECH key (rfc9848) for the TLS handshake.

Seems like quite an important feature, and in fact the major browsers have it enabled for some time now, the trick is that they do not use OpenSSL (Chrome uses BoringSSL and Firefox uses NSS).

For everyone else, the only option is to patch OpenSSL or wait until 4.0.0 is released, and so part of the reason Debian is the first distro to enable it (curl + OpenSSL + ECH) is that the OpenSSL maintainer (Sebastian Andrzej Siewior) packaged the alpha release just 3 days after it was published.

Do not forget that ECH support is experimental and currently relies on the alpha release of OpenSSL.

wcurl Gets It Too

Considering wcurl is just a wrapper on curl, it gets the feature for free:

wcurl --curl-options="--ech hard --doh-url https://1.1.1.1/dns-query" $URL

If you're using wcurl, you don't want to have to set parameters, this is just to show that the feature is there and if you have a .curlrc file, it can enable the feature seamlessly.

Other Debian Releases

Given the ECH feature requires OpenSSL >= 4, it will not make it to Debian 13, having a small chance of going to Debian 13 Backports (emphasis on small).

It should get to Debian Unstable and Debian Testing within the next couple of months as the OpenSSL GA release happens and gets packaged, but you should be able to install the package from Experimental in your Unstable and Testing systems without issues. It will also be in Debian 14 once it becomes the new Stable.

Shoulders of Giants

Stephen Farrell's presentation from OpenSSL Conference 2025 has a lot of background on the work involved:

Encrypted Client Hello – Lessons learned from trying to do something that was probably too complicated

They have been working on implementing ECH in open-source projects for years, something as big as this doesn't happen without lots of people dedicating both their paid and free times over it.

I ended up being the person who enabled it on Debian, which was pretty much the least amount of work between everyone involved, but hey it's fun flipping the switch and telling you about it.

Background

Since 2025, the curl developers started organizing an yearly meeting with all maintainers of curl in Operating Systems. The 2026 edition happened in March 26th: https://github.com/curl/curl/wiki/curl-distro-discussion-2026.

Attendance was really good, and as you can imagine one of the topics of discussion was ECH, in which it was pointed out that having OpenSSL 4 was the main requirement but besides it nothing unusual was needed.

In Debian Experimental, we have been enabling HTTPS-RR since March 2025, and OpenSSL 4.0.0 alpha was packaged just recently (2026-03-13) by Sebastian Andrzej Siewior, it's time for the next step.

The curl distro meeting was just the motivation I needed to go ahead and enable it in Debian Experimental, so as part of our Debian Brasil Weekly Meetings I've prepared and uploaded the changes, while Carlos Henrique Lima Melara worked on addressing a recent test regression for Debian Unstable. Unfortunately sergiodj couldn't join and I'm sure he's jealous of the hacking session now.

Appendix

While writing this, I've noticed one of the authors of the CloudFlare blogpost is the previous curl maintainer on Debian; Alessandro Ghedini let me take over the maintenance back in 2021 and today curl is maintained by a team of 4 people, it's nice to see Alessandro's involvement.

27 March, 2026 12:00AM by Unknown

March 26, 2026

Petter Reinholdtsen

The 2026 LinuxCNC Norwegian Developer Gathering

The LinuxCNC project continues to thrive. I believe this great software system for numerical control of machines such as milling machines, lathes, plasma cutters, routers, cutting machines, robots, and hexapods would benefit even more from in-person developer gatherings. Therefore, we plan to organise another gathering this summer as well.

We invite you to a small LinuxCNC and free software fabrication workshop/gathering in Norway this summer, over the weekend starting June 26th, 2026. As last year, we maintain a slightly broader scope and welcome people outside the LinuxCNC community. As before, we suggest to organise it as an unconference, where participants create the program upon arrival.

The location is a metal workshop 15 minutes' drive from Gardermoen airport (OSL), with plenty of space and a hotel just 5 minutes away by car. We plan to fire up the barbecue in the evenings. Please let us know if you would like to join. We track the list of participants on a simple pad. Please add yourself there if you are interested in joining.

Our friends over at the TS Robotics team at the University of Oslo have offered to handle any money involved with this gathering, that is, holding sponsor funds and paying the bills. We hope to secure enough sponsors to cover food, lodging, and travel. So far, Debian has offered to sponsor part of the expenses, which should cover food and a bit more. Please get in touch if you would like to help sponsor the gathering.

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

26 March, 2026 10:45PM

March 25, 2026

Russell Coker

The Death of Twitter

At the end of last year I uninstalled the Twitter app on my phone.

In the past Twitter used to be very useful for providing feedback to large organisations. I had responses from supermarkets, chain restaurants, online stores, major computer companies, and even the IT department of a court. In recent times I have had less responses from corporations which significantly reduces the value of Twitter to me and to many other users. It seems that Elon’s management style has discouraged not only advertising but also all forms of corporate interaction. Messing up the check mark on accounts to make it harder to work out which is a real corporate

Since Elon bought it Twitter has been increasingly pushing conservative Tweets and has done little to stop bot accounts. The incidence of useful discussions has steadily decreased. I know people who have quit Twitter entirely due to opposition to Elon, I am not doing that. I finally decided to stop using Twitter in any serious way when the notifications on my phone about popular Tweets started only being about Tweets from conservative influencers and Elon. This was obviously not any algorithm based on Tweets I was liking, it was based on political decisions. I didn’t uninstall the app due to political disagreement, I uninstalled it because it was through deliberate design promoting material that any algorithm would know was something I wouldn’t either like or “like”.

I still announce new blog posts on Twitter for my 198 followers at the same time as announcing them on Mastodon and Facebook. I get the most reactions to such announcements on Mastodon, the second most on Facebook, and hardly any on Twitter. I’m wondering how long it will be worth announcing blog posts on Twitter or whether I should stop now.

I am sure that many other people are making similar decisions and this is going to affect Twitter overall.

The web site www.russellcoker.com has information on all the ways of following me.

25 March, 2026 05:21AM by etbe

John Goerzen

Artificial Intelligence: Shades of Gray

AI sure is a hot topic right now, and I see a lot of people arguing about it. To a lot of people around here, I’m the “computer person” they know and I get asked a lot about AI.

I’m going to suggest a lot of things can be true at once. For instance:

LLMs are changing how we work and will continue to do so.
LLMs are vastly over-hyped by vested interests, and may be in a bubble.

Or how about:

Huge investment in GenAI is having many negative consequences, ranging from environmental to causing affordability problems in many industries that use hardware (ie, everywhere)
Useful results can be had from models that run on local hardware, even battery-powered hardware, which may have negligible harm or even some benefit

And:

GenAI is further concentrating wealth and power in megacorps, with the effect of squeezing out the smaller players even more.
GenAI is lowering the cost of entry for people without a lot of resources already.

I have sympathy for the naysayers; those that say it’s nothing but a stochastic parrot. But I don’t have a lot of sympathy for the naysayers that deny ever using it; you can’t form a credible argument against something without having an understanding of it informed by experience.

I also have sympathy for the cheerleaders. I have seen some impressive things from AI; for instance, a story from an engineer who has a child with a rare disease without a credible cure. The engineer did a lot of research on it, started feeding research papers into AI to analyze, and the AI started finding correlations between different areas of research that humans hadn’t yet found — leading to a positive result for the child.

To be fair, I have rarely seen an AI deliver a 100% correct answer on anything with any real level of complexity. I have seen it both waste more time than it saves, and save a ton of time.

My point here is: It is neither always fantastic nor always terrible.

Let me talk you through an example.

I am a fan of inbox zero for email. That is, the inbox should be empty. Unfortunately, mine has 8000 messages in it. According to the oldest messages in my inbox, I last had inbox zero 8 years ago. But really, only a handful are older than 2020. I guess something must have happened that year…

I’ve been chipping away at this for quite some time now. The problem is, there are certain emails in there that really do still need some action – maybe it’s photos to save off into our photo collection, for instance. But when looking at things sorted by date or thread, there are old shipping confirmations next to phishing attempts and family photos. One can’t just scan down the list.

I’ve tried all the usual tricks, most of which involve selecting groups of message that are easy to bulk erase, or at least easy to scan visually for the occasional thing worth saving. Sort by sender or subject line, for instance. Then I can, for instance, delete all the old messages from the shopping sites I commonly use all at once. But then they start using different senders and different subject lines and that doesn’t get all of them. I’ve tried keyword searches for this sort of thing too. Still, that got me down to about 8000 messages.

So I thought: why not see if an LLM could help me classify these? Maybe it could categorize them, and then I could look at emails grouped by category.

I have one machine with a discrete GPU, an Nvidia RTX 4070. It’s a desktop machine I don’t use all that often. But I set up Ollama on it, running in a Docker container. Ollama runs models locally.

I should also mention at this point that we are solar-powered, and this time of year is a time of peak production of excess solar, because it is sunny and not much heat or AC is required. So that machine is solar-powered and isn’t causing environmental harm. In any case, charging the EV uses much more power than that GPU.

I figured I would do this in two passes. First, ask the LLM to classify each message (or a sampling of them would probably work too), letting it pick its own categories for each. Then, look at the patterns that emerge and give it a single, much smaller, set of broad categories to use and rerun it over that.

Then I can easily select messages from my Maildirs by category and process them in bulk.

I used open-interpreter pointing to that GPU on my network to help me write the scripts for this. It didn’t get things right on its own; for instance, it didn’t call the Ollama API correctly, and insisted on appending “/cur” to the path to the Maildir (which was not going to fly with Python’s maildir module). It took roughly an hour to classify those 8000 messages (or, as I had it do, the first 2000 characters of them), and then the same to do it a second time. I had it output lines in the form of “filename\tcategory” and hand-wrote the shell script that processed those.

In the end, was it useful? Yes, quite. Its classifications weren’t perfect (and it didn’t even follow my prompt perfectly; sometimes it would give me a long discussion on why it picked a certain category rather than just that category, and occasionally it picked categories not on the list). But then, neither were my manual keyword searches. So far I’ve gotten rid of nearly 1000 more messages. Several categories were a “visual scan for sanity and then delete all” sort of thing.

My emails never left my network. I didn’t rely on a cloud AI to process them. I didn’t contribute to global warming (this may have even been a case of saving energy, since it no doubt will offset quite a bit of manual time that would keep screens and room lights energized and so forth). I used about as much energy as watching a movie on a TV.

Did it complete the task for me entirely autonomously? Also no. AI isn’t a mind reader and it can’t possibly evaluate exactly what my thought process would be for a given task. But it can do a decent enough job to save me some time.

Still, this didn’t require hyperscaler datacenters. AI even runs on-phone (Google Translate being one of the most useful AI-driven apps I’ve ever seen, and it can run on-device).

25 March, 2026 04:12AM by John Goerzen

March 24, 2026

Russ Allbery

Review: A Shadow in Summer

Review: A Shadow in Summer, by Daniel Abraham

Series:	Long Price Quartet #1
Publisher:	Tor
Copyright:	March 2006
ISBN:	0-7653-1340-5
Format:	Hardcover
Pages:	331

A Shadow in Summer is a high fantasy novel, the first of (as the name implies) a completed four-book series. Daniel Abraham is perhaps better known as half of the writing pair behind James S.A. Corey, author of the Expanse series. This was his first novel.

Otah was the sixth son of a Khai, sent like many of the unwanted later children of the powerful to learn the secrets of the andat and be trained as a poet. He learned his lessons well enough to reject the school and its teachings and walk away.

Amat Kyaan has worked her way up from nothing to become the senior overseer of the foreign Galtic House Wilsin in the sun-drenched port city of Saraykeht. Liat is her apprentice, distracted by young love. Maati is a new apprentice poet, having endured his training and sent to learn from Heshai how to eventually hold the andat Removing-The-Part-That-Continues, better known as Seedless. None of them know they will find themselves entangled in a plot to destroy the poet of Saraykeht and, through him, the city's most potent economic tool.

A poet in this world is not what we would think of a poet. They are, in essence, magical slave-drivers who capture the essence of an andat, a spirit embodying an idea that is coerced into the prison of volition and obedience by the poet. The andat Seedless, the embodiment of the concept of removing the spark of life, is central to the economic wealth of Saraykeht in a way that is startling in its simplicity: Seedless can remove the seeds from a warehouse full of cotton at a thought. This gives Saraykeht a massive productivity advantage in the cotton trade.

Seedless is also a powerful potential weapon. What he can do to cotton, he could as easily do to any other crop, or to people. The Galts are not fond of the independence and power of Saraykeht, but as long as the city controls a powerful andat, they do not dare to attack it directly. Indirectly, though... that's another matter.

This is one of those fantasy novels with meticulous and thoughtful world-building, careful and evocative prose, and a complex ensemble cast of interesting characters that the novel then attempts to make utterly miserable and complicit in their own misery. There should be a name for this style of writing. It's not tragedy because the ending is not tragic, precisely. It's not magic realism; the andats are openly magical, which makes this clearly high fantasy. But Abraham approaches the story from the type of realist frame that considers the pain and desperation of the characters to be more interesting than their ability to overcome challenges.

Amat starts the story as an admirable, sharp-witted expert manager, so her life is destroyed and she's subjected to sexual violence. Heshai loathes himself and veers between a tragic figure and a wastrel as the story systematically undermines opportunities for redemption. Maati is young and idealistic, so of course every character in the book sets out to crush his idealism under the weight of unforeseen consequences. There is a sad and depressing love triangle, because this is exactly the sort of book that has a sad and depressing love triangle. At the end of the novel, everyone who survives is older and wiser in the sense that some stories seem to think wisdom comes from the accumulation of trauma.

I find books like this so immensely frustrating because their merits are so clear. The world-building is careful and detailed in a way that includes economic systems, unlike so much fantasy. It is full of small, intriguing touches, such as the use of posture and gesture to communicate the emotional valence of one's words. Abraham understands the moral implications of poets and andats and the story tackles them head-on. The writing flows beautifully and gave me a strong sense of the city. I wanted to like this book for the obvious skill that went into it, and sometimes I even managed.

And yet, it's taken me three months to finish A Shadow in Summer because I simply do not want to spend this much time around miserable people. I would get through one or two chapters in a night and then wanted to read something happy or defiant or heroic, rather than watching slow-motion train wrecks intermixed with desperate attempts to navigate stifling layers of immoral systems. It's not that the story lacks a moral compass. The characters are sincerely trying to make the world a better place, with some success. It even delivers a happy ending of sorts. But so much of the journey was watching the lives of the characters fall apart.

I am completely unsurprised that some people loved this book. I'm still intrigued enough by the world-building that I'm half-tempted to try to read the sequel even after having to drag myself through this one. I had a similar reaction to Abraham's The Dragon's Path, though, so I think Abraham is just not for me. I may get back to the Expanse at some point, but having to drag myself through both of his solo novels I've tried, in two different series, probably indicates an incompatibility between author and reader. That's a shame, given the quality of the writing.

Followed by A Betrayal in Winter.

Content notes: Sexual and reproductive violence as significant plot elements.

Rating: 6 out of 10

24 March, 2026 04:40AM

March 23, 2026

Marco d'Itri

systemd has not implemented age verification

This needs to be clear: systemd is under attack by a trolling campaign orchestrated by fascist elements. Nobody is forced to like or use systemd, but anybody who wants to pick a side should know the facts.

Recently, the free software Nazi bar crowd styling themselves as "concerned citizens" has tried to start a moral panic by saying that systemd is implementing age verification checks or that somehow it will require providing personally identifiable information.

This is a lie: the facts are simply that the systemd users database has gained an optional "date of birth" field, which the desktop environments may use or not as they deem appropriate. Of course there is no "identity verification" or requirements to provide any data, which in any case would not be shared beyond authorized local applications.

While the multiple recent bills proposing that general purpose operating systems implement age verification mechanisms are often concerning, both from a social and technical point of view, this is not the topic being discussed here. They are often suboptimal, but for a long time I have been opposing attempts to implement parental control at the network level and argued that it should be managed locally, by parents on their own machines: I cannot see why I should outright reject an attempt to implement the infrastructure to do that.

If we want to keep age-appropriate controls out of the hands of centralized authorities, the alternative is giving families the means to manage it themselves: this is what this field enables. Whether desktop environments use it for parental controls, for birthday reminders, or for nothing at all, is their users' decision.

By the way, the original UNIX users database has allowed storing PII in the GECOS field since it was invented in the '70s. Similar fields are also specified by many popular LDAP schemes: adding such an optional field is consistent with the UNIX tradition.

And while we are at it, let's also refute the other smear campaign started by the same people: the systemd project is not accepting "AI slop". What happened is that a documentation file for the benefit of coding agents was added to the repository. To be clear: agents still cannot submit merge requests. The file itself remarks that all contributions must be reviewed in detail by humans, and this is basically the same policy used by the Linux kernel.

23 March, 2026 03:47PM

Benjamin Mako Hill

How taboo shapes knowledge production on Wikipedia

Note: I have not published blog posts about my academic papers over the past few years. To ensure that my blog contains a more comprehensive record of my published papers and to surface them for folks who missed them, I will periodically (re) publish blog posts about some “older” published projects. This post draws material from a previously published post by Kaylea Champion on the Community Data Science Blog.

Taboo subjects—such as sexuality and mental health—are as important to discuss as they are difficult to raise in conversation. Although many people turn to online resources for information on taboo subjects, censorship and low-quality information are common in search results. In two papers I recently published at CSCW—both led by Kaylea Champion—we presented a series of analyses showing how taboo shapes the process of collaborative knowledge building on English Wikipedia.

The first study is a quantitative analysis showing that articles on taboo subjects are much more popular and are the subject of more vandalism than articles on non-taboo topics. In surprising news, we also found that they were edited more often and were of higher quality!

Short video of Kaylea’s presentation of the work given at Wikimania in August 2023.

The first challenge we faced in conducting this work was identifying taboo articles. Kaylea had a brilliant idea for a new computational approach to doing so without relying on our individual intuitions about what qualifies as taboo (something we understood would be highly specific to our own culture, class, etc). Her approach was to make use of an insight from linguistics: people develop euphemisms as ways to talk about taboos (i.e., think about all the euphemisms we’ve devised for death, or sex, or menstruation, or mental health).

We used this insight to build a new machine-learning classifier based on English Wiktionary definitions. If a ‘sense’ of a word was tagged as euphemistic, we treated the words in the definition as indicators of taboo. The end result was a series of words and phrases that most powerfully differentiate taboo from non-taboo. We then did a simple match between those words and phrases and the titles of Wikipedia articles. The topics were taboo enough that we were a little uncomfortable discussing them in our meetings! We built a comparison sample of articles whose titles are words that, like our taboo articles, appear in Wiktionary definitions.

In the first paper, we used this new dataset to test a series of hypotheses about how taboo shapes collaborative production in Wikipedia. Our initial hypotheses were based on the idea that taboo information is often in high demand but that Wikipedians might be reluctant to associate their names (or usernames) with taboo topics. The result, we argued, would be articles that were in high demand but of low quality.

We found that taboo articles are thriving on Wikipedia! In summary, we found that in comparison to non-taboo articles:

Taboo articles are more popular (as expected).
Taboo articles receive more contributions (contrary to expectations).
Taboo articles receive more low-quality contributions (as expected).
Taboo articles are higher quality (contrary to expectations).
Taboo article contributors are more likely to contribute without an account (as expected), and have less experience (as expected), but that accountholders are more likely to make themselves more identifiable by having a user page, disclosing their gender, and making themselves emailable (all three of these are contrary to expectation!).

Kaylea attempted to understand these somewhat confusing results by designing a fantastic mixed-methods analysis that sought to unpack some of the nuance missing in the quantitative analysis by delving deep into the “life histories” of four articles on English Wikipedia: two on taboo topics related to women’s anatomy (Clitoris and Menstration) and two nontaboo articles chosen for comparison (Cell membrance and Philip Pullman).

Although the findings from the analysis can be difficult to summarize succinctly (as with many qualitative studies), we showed how the taboo example articles’ success was hard-won amid real challenges and attacks. The paper describes how challenges were overcome through resilient leadership, often provided by a single dedicated individual. The paper provides a template for how taboo can be—and frequently is—overcome by dedicated Wikipedians in ways that provide useful knowledge resources in real demand.

For more details, visualizations, statistics, and more, we hope you’ll take a look at our papers, both linked below.

The full citation for the papers are: (1) Champion, Kaylea, and Benjamin Mako Hill. 2023. “Taboo and Collaborative Knowledge Production: Evidence from Wikipedia.” Proceedings of the ACM on Human-Computer Interaction 7 (CSCW2): 299:1-299:25. https://doi.org/10.1145/3610090. (2) Champion, Kaylea, and Benjamin Mako Hill. 2024. “Life Histories of Taboo Knowledge Artifacts.” Proceedings of the ACM: Human-Computer Interaction 8 (CSCW2): 505:1-505:32. https://doi.org/10.1145/3687044.

We have also released replication materials for the paper, including all the data and code used to conduct the analyses.

This blog post and the paper it describes are collaborative work by Kaylea Champion and Benjamin Mako Hill.

23 March, 2026 09:33AM by Benjamin Mako Hill

March 22, 2026

Vincent Bernat

Calculate “1/(40rods/hogshead) to L/100km” from your Zsh prompt

I often need a quick calculation or a unit conversion. Rather than reaching for a separate tool, a few lines of Zsh configuration turn = into a calculator. Typing = 660km / (2/3)c * 2 -> ms gives me 6.60457 ms¹ without leaving my terminal, thanks to the Zsh line editor.

The equal alias

The main idea looks simple: define = as an alias to a calculator command. I prefer Numbat, a scientific calculator that supports unit conversions. Qalculate is a close second.² If neither is available, we fall back to Zsh’s built-in zcalc module.

As the alias built-in uses = as a separator for name and value, we need to alter the aliases associative array:

if (( $+commands[numbat] )); then
  aliases[=]='numbat -e'
elif (( $+commands[qalc] )); then
  aliases[=]='qalc'
else
  autoload -Uz zcalc
  aliases[=]='zcalc -f -e'
fi

With this in place, = 847/11 becomes numbat -e 847/11.

The quoting problem

The first problem surfaces quickly. Typing = 5 * 3 fails: Zsh expands the * character as a glob pattern before passing it to the calculator. The same issue applies to other characters that Zsh treats specially, such as > or |. You must quote the expression:

$ = '5 * 3'
15

We fix this by hooking into the Zsh line editor to quote the expression before executing it.

Automatic quoting with ZLE

Zsh calls the line-finish widget before submitting a command. We hook a function that detects the = prefix and quotes the expression:

_vbe_calc_quote() {
  case $BUFFER in
    "="*)
      typeset -g _vbe_calc_expr=$BUFFER # not used yet
      BUFFER="= ${(q-)${${BUFFER#=}# }}"
      ;;
  esac
}
add-zle-hook-widget line-finish _vbe_calc_quote

When you type = 5 * 3 and press ↲, _vbe_calc_quote strips the = prefix, quotes the remainder with the (q-) parameter expansion flag, and rewrites the buffer to = '5 * 3' before Zsh submits the command. As a bonus, you can save a few keystrokes with =5*3! 🚀

You can now compute math expressions and convert units directly from your shell. Zsh automatically quotes your expressions:

$ = '1 + 2'
3
$ = 'pi/3 + pi |> cos'
-0.5
$ = '17 USD -> EUR'
14.7122 €
$ = '180*500mg -> g'
90 g
$ = '5 gigabytes / (2 minutes + 17 seconds) -> megabits/s'
291.971 Mbit/s
$ = 'now() -> tz("Asia/Tokyo")'
2026-03-22 22:00:03 JST (UTC +09), Asia/Tokyo
$ = '1 / (40 rods / hogshead) -> L / 100km'
118548 × 0.01 l/km

“That's the way I like it!” says Grampa Simpson

Storing unquoted history

As is, Zsh records the quoted expression in history. You must unquote it before submitting it again. Otherwise, the ZLE widget quotes it a second time. Bart Schaefer provided a solution to store the original version:

_vbe_calc_history() {
  return ${+_vbe_calc_expr}
}
add-zsh-hook zshaddhistory _vbe_calc_history

_vbe_calc_preexec() {
  (( ${+_vbe_calc_expr} )) && print -s $_vbe_calc_expr
  unset _vbe_calc_expr
  return 0
}
add-zsh-hook preexec _vbe_calc_preexec

The zshaddhistory hook returns 1 if we are evaluating an expression, telling Zsh not to record the command. The preexec hook then adds the original, unquoted command with print -s.

The complete code is available in my zshrc. A common alternative is the noglob precommand modifier. If you stick with to instead of -> for unit conversion, it covers 90% of use cases. For a related Zsh line editor trick, see how I use auto-expanding aliases to fix common typos.

This is the fastest a packet can travel back and forth between Paris and Marseille over optical fiber. ↩︎
Qalculate is less understanding with units. For example, it parses “Mbps” as megabarn per picosecond: ☢️
```
$ numbat -e '5 MB/s -> Mbps'
40 Mbps
$ qalc 5 MB/s to Mbps
5 megabytes/second = 0.000005 B/ps
```
↩︎

22 March, 2026 01:37PM by Vincent Bernat

March 21, 2026

Jonathan Dowland

Ladytron

I saw Ladytron perform in Digital, Newcastle last night. The last time I saw them was, I think, at the same venue, 18 years ago. Time flies!

Back in the day (perhaps their heyday, perhaps not!) Ladytron ploughed a particular sonic furrow and did it very well. Going into the gig I had set my expectations that, should they play just these hits, I'd have a good time.

The gig exceeded my expectations. The setlist very much did not lean into their best-known period: the more recent few albums were very well represented and to me this felt very confident. The lead singer, Helen Marnie, demonstrated some excellent range, particularly on some of the new songs. Daniel Hunt did a lot of backing vocals and they were really complementary to Helen's: underscoring but not overpowering. I enjoyed nerding out watching Mira Ayoro's excellent wrangling of her Korg MS-20. One highlight was an encore performance of Light & Magic, which was arguably the "alternate version" as available on the expanded versions of that album or the Remixed and Rare companion.

I thought I'd try to put together a 5-track playlist for a friend who attended the gig but isn't super familiar with them. As usual this is hard. I'm going to avoid the obvious hits, try to represent their whole career and try to ensure the current trio each get a vocal turn in the selection.

They actually released their latest album, Paradises, yesterday as well. One track from it is in the list below.

I'm Not Scared by Ladytron Kingdom Undersea by Ladytron Blue Jeans by Ladytron He took her to a movie by Ladytron Transparent Days by Ladytron

(If you can't see anything, the bandcamp embeds have been stripped out by whatever you are viewing this with)

21 March, 2026 10:18PM

Matthew Garrett

SSH certificates and git signing

When you’re looking at source code it can be helpful to have some evidence indicating who wrote it. Author tags give a surface level indication, but it turns out you can just lie and if someone isn’t paying attention when merging stuff there’s certainly a risk that a commit could be merged with an author field that doesn’t represent reality. Account compromise can make this even worse - a PR being opened by a compromised user is going to be hard to distinguish from the authentic user. In a world where supply chain security is an increasing concern, it’s easy to understand why people would want more evidence that code was actually written by the person it’s attributed to.

git has support for cryptographically signing commits and tags. Because git is about choice even if Linux isn’t, you can do this signing with OpenPGP keys, X.509 certificates, or SSH keys. You’re probably going to be unsurprised about my feelings around OpenPGP and the web of trust, and X.509 certificates are an absolute nightmare. That leaves SSH keys, but bare cryptographic keys aren’t terribly helpful in isolation - you need some way to make a determination about which keys you trust. If you’re using someting like GitHub you can extract that information from the set of keys associated with a user account¹, but that means that a compromised GitHub account is now also a way to alter the set of trusted keys and also when was the last time you audited your keys and how certain are you that every trusted key there is still 100% under your control? Surely there’s a better way.

SSH Certificates

And, thankfully, there is. OpenSSH supports certificates, an SSH public key that’s been signed by some trusted party and so now you can assert that it’s trustworthy in some form. SSH Certificates also contain metadata in the form of Principals, a list of identities that the trusted party included in the certificate. These might simply be usernames, but they might also provide information about group membership. There’s also, unsurprisingly, native support in SSH for forwarding them (using the agent forwarding protocol), so you can keep your keys on your local system, ssh into your actual dev system, and have access to them without any additional complexity.

And, wonderfully, you can use them in git! Let’s find out how.

Local config

There’s two main parameters you need to set. First,

1

git config set gpg.format ssh

because unfortunately for historical reasons all the git signing config is under the gpg namespace even if you’re not using OpenPGP. Yes, this makes me sad. But you’re also going to need something else. Either user.signingkey needs to be set to the path of your certificate, or you need to set gpg.ssh.defaultKeyCommand to a command that will talk to an SSH agent and find the certificate for you (this can be helpful if it’s stored on a smartcard or something rather than on disk). Thankfully for you, I’ve written one. It will talk to an SSH agent (either whatever’s pointed at by the SSH_AUTH_SOCK environment variable or with the -agent argument), find a certificate signed with the key provided with the -ca argument, and then pass that back to git. Now you can simply pass -S to git commit and various other commands, and you’ll have a signature.

Validating signatures

This is a bit more annoying. Using native git tooling ends up calling out to ssh-keygen², which validates signatures against a file in a format that looks somewhat like authorized-keys. This lets you add something like:

1

* cert-authority ssh-rsa AAAA…

which will match all principals (the wildcard) and succeed if the signature is made with a certificate that’s signed by the key following cert-authority. I recommend you don’t read the code that does this in git because I made that mistake myself, but it does work. Unfortunately it doesn’t provide a lot of granularity around things like “Does the certificate need to be valid at this specific time” and “Should the user only be able to modify specific files” and that kind of thing, but also if you’re using GitHub or GitLab you wouldn’t need to do this at all because they’ll just do this magically and put a “verified” tag against anything with a valid signature, right?

Haha. No.

Unfortunately while both GitHub and GitLab support using SSH certificates for authentication (so a user can’t push to a repo unless they have a certificate signed by the configured CA), there’s currently no way to say “Trust all commits with an SSH certificate signed by this CA”. I am unclear on why. So, I wrote my own. It takes a range of commits, and verifies that each one is signed with either a certificate signed by the key in CA_PUB_KEY or (optionally) an OpenPGP key provided in ALLOWED_PGP_KEYS. Why OpenPGP? Because even if you sign all of your own commits with an SSH certificate, anyone using the API or web interface will end up with their commits signed by an OpenPGP key, and if you want to have those commits validate you’ll need to handle that.

In any case, this should be easy enough to integrate into whatever CI pipeline you have. This is currently very much a proof of concept and I wouldn’t recommend deploying it anywhere, but I am interested in merging support for additional policy around things like expiry dates or group membership.

Doing it in hardware

Of course, certificates don’t buy you any additional security if an attacker is able to steal your private key material - they can steal the certificate at the same time. This can be avoided on almost all modern hardware by storing the private key in a separate cryptographic coprocessor - a Trusted Platform Module on PCs, or the Secure Enclave on Macs. If you’re on a Mac then Secretive has been around for some time, but things are a little harder on Windows and Linux - there’s various things you can do with PKCS#11 but you’ll hate yourself even more than you’ll hate me for suggesting it in the first place, and there’s ssh-tpm-agent except it’s Linux only and quite tied to Linux.

So, obviously, I wrote my own. This makes use of the go-attestation library my team at Google wrote, and is able to generate TPM-backed keys and export them over the SSH agent protocol. It’s also able to proxy requests back to an existing agent, so you can just have it take care of your TPM-backed keys and continue using your existing agent for everything else. In theory it should also work on Windows³ but this is all in preparation for a talk I only found out I was giving about two weeks beforehand, so I haven’t actually had time to test anything other than that it builds.

And, delightfully, because the agent protocol doesn’t care about where the keys are actually stored, this still works just fine with forwarding - you can ssh into a remote system and sign something using a private key that’s stored in your local TPM or Secure Enclave. Remote use can be as transparent as local use.

Wait, attestation?

Ah yes you may be wondering why I’m using go-attestation and why the term “attestation” is in my agent’s name. It’s because when I’m generating the key I’m also generating all the artifacts required to prove that the key was generated on a particular TPM. I haven’t actually implemented the other end of that yet, but if implemented this would allow you to verify that a key was generated in hardware before you issue it with an SSH certificate - and in an age of agentic bots accidentally exfiltrating whatever they find on disk, that gives you a lot more confidence that a commit was signed on hardware you own.

Conclusion

Using SSH certificates for git commit signing is great - the tooling is a bit rough but otherwise they’re basically better than every other alternative, and also if you already have infrastructure for issuing SSH certificates then you can just reuse it⁴ and everyone wins.

Did you know you can just download people’s SSH pubkeys from github from https://github.com/<username>.keys? Now you do ↩︎
Yes it is somewhat confusing that the keygen command does things other than generate keys ↩︎
This is more difficult than it sounds ↩︎
And if you don’t, by implementing this you now have infrastructure for issuing SSH certificates and can use that for SSH authentication as well. ↩︎

21 March, 2026 07:38PM

Ravi Dwivedi

Vietnam Trip

Before reaching Vietnam

Continuing from the last post, Badri and I took a flight from the Brunei International Airport to Kuala Lumpur on the 12th of December 2024. We reached Kuala Lumpur in the evening.

After arriving at the airport, we went through immigration. In a previous post, I mentioned that we had put our stuff in lockers at the TBS bus terminal in Kuala Lumpur. Therefore, we had to go there.

The locker was automated and required us to enter the PIN we had set. Upon entering the PIN, the locker wasn’t getting unlocked. After trying this for 10-15 minutes without any luck, we tried getting some help as there the lockers weren’t under supervision.

So, I roamed around and found a staff member, reporting that our lockers weren’t getting unlocked. They called the person who was in-charge of the lockers. He came to us in a few minutes and used their admin access to open the locker. We were supposed to pay for using the lockers by putting the banknotes inside through a slot. However, as the machine wasn’t working, we gave the amount for the use of our locker service to that person instead.

We soon went back to the KL airport to catch our morning flight to Ho Chi Minh City in Vietnam. At the flight counter, we were afraid we would have to pay extra as our luggage surpassed the allowed weight limit. This one was also a budget airline—AirAsia—and our tickets didn’t include a check-in bag.

Generally, passengers from countries requiring a visa to visit Vietnam (such as India) require going to the airline and showing their visa to get the boarding pass. However, when we went to the AirAsia counter at the Kuala Lumpur airport, they didn’t weigh our bags and asked us to get our boarding passes from an automated kiosk. So, we got our boarding passes printed and proceeded to the airport security.

While clearing the airport security, a lotion I bought from Singapore was confiscated because it was 200 mL, exceeding the limit of 100 mL per bottle. Had that 200 mL liquid been in two different bottles of 100 mL each, I would have been allowed to take it in my carry-on bag, but a single 200 mL bottle wasn’t! I was allowed to keep it in the check-in bag, but I didn’t have it included in my ticket. Huh, airports and their weird rules :( The lotion was an expensive one, so having it thrown away did ruin my mood.

Overview

We started our Vietnam trip from Ho Chi Minh City in the south on the 13th of December 2024 and finished it in Hanoi in the north on the 20th of December. We traveled from Ho Chi Minh City to Hanoi mostly by train, except for a hundred or so kilometers by bus, in chunks. On the way, we visited Nha Trang, Hoi An, and Hue. The distance between Ho Chi Minh City and Hanoi is 1700 km.

For your reference, here are those places labeled on Vietnam’s map.

Ho Chi Minh City

We landed in Ho Chi Minh City early morning on the 13th of December 2024. I was tired and sleepy as I hadn’t gotten a good night’s sleep. After going through immigration, we went to a currency exchange counter to get Vietnamese Dong. Unlike other countries on this trip, money exchange counters in Vietnam didn’t accept Indian rupees. Therefore, we exchanged euros to get Vietnamese dong at the airport.

After getting out of the airport, we took a bus to the city center. It was 15,000 dongs—approximately 50 Indian rupees. Our plan was to meet Badri’s friend and stay the night at his apartment.

So we went to a café nearby and bought a coffee for each of us for 75,000 dongs. We went upstairs and sat for a while. The Wi-Fi password was mentioned on our bill. During the trip, I found out about the café culture of Vietnam. They have their own coffee brands (such as Highlands Coffee), and you can sit down at any of the cafés for work or wait for the rain to stop. It rained a lot while we were there, so we did use these cafés for that purpose.

Badri’s friend met us there, and we roamed around the area a bit, which included roaming inside a beautiful park. Then Badri’s friend took us to a restaurant. Because I do not eat meat, he took us to a vegan restaurant. Having been to four Southeast Asian countries at this point (excluding Vietnam), I was under the impression that there wouldn’t be a lot of things for my diet in Vietnam.

A picture of the park we roamed around in Ho Chi Minh City.

However, I was pleasantly surprised at the restaurant. I found all the dishes to be tasty, especially their signature noodles called Pho. I liked another dish so much that I tracked down the restaurant again with Badri using the geotagged image of the bill I had taken earler to have it again. As a tip for vegans coming to Vietnam, the places having the letters “Chay” (without any accented letters) in their name are vegan only.

One of the dishes we had in the restaurant. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

In the night, we went to a supermarket where I got myself some oranges and guavas. Then, we went to a Japanese restaurant where I didn’t have anything, as there was no vegetarian option available for me. Then we took a free bus to the place to Badri’s friend’s apartment. The construction company that built the apartment also runs this free bus service from their residential area to different parts of the city as a way of promoting their apartments. Anyone can take the bus, not just residents.

The next day, we took the free bus back to the city center and checked in to a hostel for a night. We took two beds in dormitories, which were 88,000 dongs (270 rupees) for each bed for a night. In Vietnam, if you can spend around 300 rupees per night, you can get a bed in a decent hostel.

Train from Ho Chi Minh City to Nha Trang

On the night of the 15th of December 2024, we boarded a train from Ho Chi Minh City to Nha Trang. The ticket for each of us was 519,000 dongs (1600 Indian rupees). The train name was SNT2. When we reached the Ho Chi Minh City train station, we noticed that the station was rather small by Indian standards.

After entering the train station, we went inside to the first platform, where the tickets were checked by a staff member. Ho Chi Minh City was the originating station for our train, so our train was already standing at the station. We had to cross the railway tracks on foot to reach the platform our train was on. Then we located our coach, where a ticket inspector was standing at the gate. He let us in after checking our tickets. In all these instances, we just had to show our digital boarding pass which we had received by email.

Unlike Indian trains, the train didn’t have side berths. Additionally, I liked the fact that it had a dedicated space to put our bags in, which was very convenient. The train departed from Ho Chi Minh City at 21:05 and arrived in Nha Trang at 05:30 in the morning.

Interior of our train coach. Trains in Vietnam don’t have side berths, unlike India. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

A picture of the berths from our coach. It had three tiers, similar to a 3 AC coach in Indian trains. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

The train had a cabin to put the bags in. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Nha Trang

Nha Trang is a coastal place, and we planned to go to a beach. We figured out that the bus to the airport goes can drop us near the beach. Therefore, we went to the bus station to get to the airport bus. The bus station was walking distance from the railway station. So, we decided to walk.

On the way, we stopped at a small shop for a coffee. The shop also gave a complimentary cup of green tea along with the coffee. I found out later that it is common for local shops to give a cup of complimentary green tea in Vietnam.

Soon we reached the bus station and took a bus to the beach. It was 65,000 dongs (₹200). After getting down from the bus, I had coconut water and some eggs at a small local place.

Then we went to the beach, but nobody else was there. We spent some time there and went back to the place where the bus dropped us as it started raining. We couldn’t find a bus for some time. A taxi driver approached us and agreed to take us to the city center for 200,000 dongs (₹650). For reference, the place where he dropped us was 35 km from the place we took the taxi. Taxi fares in Vietnam were also cheap!

The beach we went to in Nha Trang. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Nha Trang was a beautiful place, and so we roamed around for a while. Then we stopped at a Highlands Coffee branch for a while. Since Christmas was coming up, the café had a Christmas tree, and I liked the Christmas vibes. They were playing Mariah Carey’s All I Want for Christmas Is You.

This one was shot in the city center. In this trip, Badri and I found out that this is customary at local places in Vietnam. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Inside a Highlands Coffee cafe in Nha Trang. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

A coffee I got from Highlands Coffee in Nha Trang. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

During the evening, we went to a local place to eat. The place mentioned “Chay” in its name, and you know what it means—it was a vegan place. There was a man there and no other customers. I don’t remember the names of the dishes we ordered, but it was a bowl of soupy noodles and a bowl of dry noodles. They were very tasty. To top that off, the meal was a total of 55,000 dongs (₹180) for both of us.

The host was welcoming and friendly. We had a nice conversation with the host. In Vietnam, restaurants give chopsticks to eat noodles. While Badri was good at using them, I wasn’t. So, the host of this restaurant helped me in using chopsticks. Although my technique was not perfect and I take a bit of time, I could now eat solely with chopsticks.

The restaurant we went to in Nha Trang. The word Chay in the name means it was a vegan restaurant. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Soupy noodles we got at that restaurant. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Dry noodles we got at that restaurant. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Our plan was to take a night bus to Hoi An, and we were hoping to find a bus stand. However, we couldn’t find one. Asking around about the pickup location of the Hoi An bus led us to many different locations. Finally, we ended up at a bus booking agency’s office where we found out that there were no tickets available for Hoi An.

At this point, we gave up on booking the bus and searched for trains instead. As we didn’t have a local SIM, we asked the agency to let us connect to their Wi-Fi so that we could look for trains. They were kind enough to let us do that. It also seemed like they were going to close the office in like 10 minutes.

Unfortunately, all the sleeper berths were booked from Nha Trang till Hoi An on the next train with only seating berths being available. It takes around 10 hours, so I wasn’t comfortable traveling on seating berths.

Here I came up with the idea to look for sleeper berths from an intermediate stop. Fortunately, there were sleeper berths available from the next stop, Ninh Hòa. Therefore, we booked a seating berth from Nha Trang to Ninh Hòa and a sleeper berth from Ninh Hòa to Trà Kiệu (the nearest railway station from Hoi An). The train name was SE6, and it was a total of 500,000 dongs per person (₹1600 per person).

So, we went to the Nha Trang railway station and boarded the train. We had to spend 40 minutes seated for the train to reach the next stop before we could go to our sleeper berths. Badri had some friendly co-passengers on that trip who gave him Saigon beer and some crispy papad-like thing. They offered me as well, but I thought it was non-veg, so I declined it.

Hoi An

On the morning of 17th December 2024, we got down at the Trà Kiệu station at around 09:30. Our hostel was in Hoi An, which was around 22 km from the station. There was no public transport to get there.

Instead, there was a taxi driver at the train platform. We told him the name of our hostel, and he quoted 270,000 dongs (around ₹850). We said it was too expensive for us, so he agreed to bargain at 250,000 dongs. At this point, we told him that we could give him no more than 200,000 dongs, but he didn’t agree.

Badri tried a trick. He asked the driver to show us prices in the Grab app (a popular taxi booking app in Southeast Asia). Unfortunately, the Grab app showed 258,000 dongs, which was more than the fare the driver agreed to.

So we walked away as if we had so many options (we didn’t!) to reach the hostel. We got out of the station and stopped at a small shop outside to have some coffee. As is customary in Vietnam, we got a complimentary green tea here as well.

This was the place we had our coffee in Tra Kieu. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

That taxi driver also joined us and sat in that shop. He started talking with the locals in the shop in the local language. The taxi driver was insistent on taking us to Hoi An for 250,000 dongs. At this point, Badri told the taxi driver (by the use of translation software) that we usually use public transport during our trips, and we aren’t used to paying high prices to get around. So, he can drop us somewhere in Hoi An for 200,000 dongs as we don’t mind walking a bit to reach our hotel.

After reading this, the taxi driver agreed to take us to our hostel for 200,000 dongs (₹660). He also had me take a picture with Badri after this. I think such a bargain tactic would not work in India.

Photo of Badri with taxi driver. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

The nice thing we noticed in Vietnam is, once bargaining is done and the deal is settled, people don’t try to bargain more or keep on talking about the subject. Before the deal, the driver was being somewhat insistent and argumentative, but after the deal was done, it was as if no argument had happened at all.

A picture of Tra Kieu area near the train station we got down at. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

We were treated to some beautiful scenery on the way to our hostel. Soon we reached our place and completed all the formalities for checking-in. During the time our room was being prepared for check-in, we had an egg sandwich with coffee in the hotel. I found the egg sandwich very tasty. The bread looked like the French baguette. The hostel was ₹240 per night for each of us.

The name of the hostel was Bana Spa. We liked staying here and we can recommend it if you find yourself there. It is operated by a family.

Our breakfast in Hoi An. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

A photo of the hostel we stayed in Hoi An. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

We also rented a bicycle for each of us—25,000 dongs per day (₹80)—and explored the old town during the evening. Hoi An is popular for Vietnamese silk. Tourists come here to buy fabric and get it done by the tailor. The buildings here looked old, and they were painted in yellow with a gabled roof.

Typical yellow house with gabled roof in Hoi An old town. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Here, I also had egg coffee for the first time, and I liked it. Egg coffee is a delicacy of Hanoi, but you can get it in other parts of Vietnam. If you find yourself in Vietnam, then I recommend you try egg coffee. We also bought some cool T-shirts and other souvenirs, such as a Vietnamese hat, from here.

Egg coffee I had in Hoi An. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Hue

The next day—the 18th of December 2024—we went to Hue by bus. As we could not take a bus on our own in Nha Trang, we asked the hostel to book it for us this time. We booked it a day before, and they told us to be ready by 07:00 in the morning. At 07:00, a minibus arrived, which took us to a bus agency’s office. There we waited for a few minutes and got into the bus to Hue.

The bus had sleeper seats, so I took the opportunity to catch some sleep. The ride was comfortable, so I am assuming the roads were good. In a couple of hours, we reached Hue. Again, we went to Highlands Coffee to have some coffee, charge our phones, and use the internet, not to mention using the bathrooms.

During the afternoon, we went to a local restaurant named Quán Chay Thanh Liễu. It was a vegan restaurant (remember the thing I mentioned earlier about “Chay” being in the name?). On the way, we had a steamed dumpling shaped like a momo called banh bao from a street vendor. It wasn’t very good, but I found it worthwhile.

Bahn Bao in Hue. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

At the restaurant, we ordered a hot pot. First, they brought noodles and a gas stove. Then came the stock and our gas stove was turned on. The stock was kept simmering on the stove. Then, we had it bit by bit with the noodles. A big hot pot at this place costs 50,000 dongs (₹170). Then we had bánh cuốn. These were steamed rolls made of rice flour for 10,000 dongs (₹33).

Hot Pot. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Added soup to the noodles. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Steamed rolls made of rice flour. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Restaurants in Vietnam usually add photos of the meals in their menu or write a description in English. So, even though the dish names were Vietnamese, we had no problems in ordering food there. In addition, all the places we went to provided free Wi-Fi. They either mention the Wi-Fi password on the bill, on the menu or paste it on the wall. This made our trip smoother without getting a local SIM.

Menu from a restaurant in Ho Chi Minh City with detailed description of the food. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Then we slowly walked towards the railway station, as we had a night train to Hanoi. We had egg coffee in a cafe. Near the railway station, we had a bánh mì (egg sandwich). As for sightseeing, we had plans to visit a couple of places in Hue, but we ended up spending all our time inside sheltered spaces due to heavy rain.

We had booked the train SE20 for Hanoi, which had a departure time of 20:41 from Hue. This one was 948,000 dongs (₹3100) for myself and 870,000 dongs (₹2900) for Badri. My ticket was pricier than Badri’s because I got a lower berth. Our train was late by half an hour, so we waited in the common area of the station. After the train arrived, we got inside and took our seats.

The cabin had four berths—two upper and two lower, similar to India’s First AC class. The ticket inspector came to us and offered us the whole cabin (two additional berths) for 300,000 dongs (₹1,000), which we declined. However, this hinted at the other two seats not being reserved. Eventually, we had the whole cabin to ourselves, as nobody else showed up for the other two berths. It was a 14-hour journey, and I got a good sleep.

Our berths in the train. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Hanoi

On the morning of the 19th of December 2024, we reached Vietnam’s capital, Hanoi. We had booked a private hotel room for ₹800. It was 1 km from the Hanoi Airport. However, it was pretty far from the railway station. So, we roamed around in the city and went to the hotel in the evening.

First, we walked to a place and had egg coffee with egg sandwiches. Then we went to Hanoi Train Street, which was walking distance from the train station. After clicking some pictures at the train street, we went to a museum nearby. Upon reaching there, we found out that it was closed.

Egg coffee in Hanoi. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Hanoi train street is a tourist attraction in Hanoi. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Then we went shopping for jackets, as Hanoi was cold compared to other parts of Vietnam we had been to, and since many of them are manufactured in Vietnam, we thought they would be cheaper. I liked some jackets, but they were not my size. Eventually, we didn’t buy anything at the clothes shop.

In the evening, I bought a Vietnamese-styled phin coffee filter and coffee powder from Highlands Coffee. We spent a lot of time in their cafes, so it made sense to buy some souvenirs from there. Badri bought a few coffee filters for his family at Trung Nguyen, where I also bought another filter.

We had dinner at a local place where we had pho and banh it. Bahn it was served packed in banana leaves and it was made of sticky rice.

A picture of pho we had in Hanoi. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Bahn it is served packed in banana leaves. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Bahn it. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.

Next, we went to Hanoi railway station to catch a bus to the airport since our hotel was 1 km from the airport. The locals there helped us take the bus. It took like an hour to get to the airport. We saw on OpenStreetMap that we can take a bus from there to the hotel, but we could not find it. So we walked to our hotel instead.

It was a decent hotel room for ₹800 for a night. We went outside to explore the area and had egg sandwiches and egg coffee at a local place. Again, we were given a complimentary green tea. We went to this place like three times. We had practically become regulars by the time we left.

The next day— 20th of December 2024 — we took a bus to the airport and boarded our flight to Delhi.

Credits: Thanks Badri, Kishy and Richard for proofreading.

21 March, 2026 07:30PM

Steinar H. Gunderson

A286874(16) >= 48

Following up on the previous post, here are some heuristic results:

First, if restricting oneself to 5-uniform values (all values have exactly five bits set), the best 15-bit code one can make is indeed 42 elements, and there are two distinct solutions: {31, 227, 364, 692, 1240, 1577, 1606, 2353, 3008, 3205, 3338, 4434, 4746, 4869, 5536, 6182, 6217, 7696, 8582, 8984, 9266, 9537, 10324, 10408, 10755, 12433, 12896, 13324, 16777, 16977, 17186, 17684, 18578, 18956, 19552, 20536, 20676, 21507, 24613, 24650, 26240, 30976} and {31, 227, 364, 692, 849, 906, 1240, 2354, 3206, 3337, 3680, 4485, 5169, 5442, 5644, 6228, 6312, 6659, 8745, 9285, 9632, 9746, 10314, 10385, 11012, 12326, 12568, 12992, 16966, 17450, 17684, 18049, 18469, 18880, 18968, 20553, 20626, 21280, 24688, 24716, 24835, 31744}. This supports, but does not prove, the conjecture that A286874(15) = 42.

Second, A286874(16) >= 48 (the best previously known bound was 45), since this is a valid 48-element solution:

0000000000011111
0000000011100011
0000000101101100
0000001010110100
0000010011011000
0000011100000011
0000100100110001
0000101000101010
0000101111000000
0001000110001001
0001010000110010
0001011000001100
0001100100000110
0001110001000001
0010000110010010
0010010010000101
0010011001100000
0010100001010100
0010110100001000
0011000001001010
0011001000010001
0011100010100000
0100001001001001
0100010001000110
0100010110100000
0100100010001100
0100111000010000
0101000000100101
0101000101010000
0101001010000010
0110000000111000
0110001100000100
0110100000000011
1000001001010010
1000010000101001
1000010100010100
1000101000000101
1000110010000010
1001000011000100
1001001100100000
1001100000011000
1010000000100110
1010000101000001
1010001010001000
1100000010010001
1100000100001010
1100100001100000
1111010000000000

I won't be sweeping all of the 15- or 16-bit spaces.

21 March, 2026 03:19PM

C.J. Collier

The WWW::Mechanize::Chrome Saga: A Comprehensive Narrative of PR #104

The
WWW::Mechanize::Chrome Saga: A Comprehensive Narrative of PR #104

This document synthesizes the extensive work performed from March
13th to March 20th, 2026, to harden, stabilize, and refactor the
WWW::Mechanize::Chrome library and its test suite. This
effort involved deep dives into asynchronous programming,
platform-specific bug hunting, and strategic architectural
decisions.

Part I:
The Quest for Cross-Platform Stability (March 13 – 16)

The initial phase of work focused on achieving a “green” test suite
across a variety of Linux distributions and preparing for a new release.
This involved significant hardening of the library to account for
different browser versions, OS-level security restrictions, and
filesystem differences.

Key Milestones &
Engineering Decisions:

Fedora & RHEL-family Success: A major effort
was undertaken to achieve a 100% pass rate on modern Fedora 43 and
CentOS Stream 10. This required several key engineering decisions to
handle modern browser behavior:
- Decision: Implement Asynchronous DOM Serialization
  Fallback. Synchronous fallbacks in an async context are
  dangerous. To prevent Resource was not cached errors during
  saveResources, we implemented a fully asynchronous fallback
  in _saveResourceTree. By chaining
  _cached_document with DOM.getOuterHTML
  messages, we can reconstruct document content without blocking the event
  loop, even if Chromium has evicted the resource from its cache. This
  also proved resilient against Fedora’s security policies, which often
  block file:// access.
- Decision: Truncate Filenames for Cross-Platform
  Safety. To avoid File name too long errors,
  especially on Windows where the MAX_PATH limit is 260
  characters, filenameFromUrl was hardened. The filename
  truncation was reduced to a more conservative 150
  characters, leaving ample headroom for deeply nested CI
  temporary directories. Logic was also added to preserve file extensions
  during truncation and to sanitize backslashes from URI paths.
- Decision: Expand Browser Discovery Paths. To
  support RHEL-based systems out-of-the-box, the
  default_executable_names was expanded to include
  headless_shell and search paths were updated to include
  /usr/lib64/chromium-browser/.
- Decision: Mitigate Race Conditions with Stabilization Waits
  and Resilient Fetching. On fast systems,
  DOM.documentUpdated events could invalidate
  nodeIds immediately after navigation, causing XPath queries
  to fail with “Could not find node with given id”. A small stabilization
  sleep(0.25s) was added after page loads to ensure the DOM
  is settled. Furthermore, the asynchronous DOM fetching loop was hardened
  to gracefully handle these errors by catching protocol errors and
  returning an empty string for any node that was invalidated during
  serialization, ensuring the overall process could complete.
Windows Hardening:
- Decision: Adopt Platform-Aware Watchdogs. The test
  suite’s reliance on ualarm was a blocker for Windows, where
  it is not implemented. The t::helper::set_watchdog function
  was refactored to use standard alarm() (seconds) on Windows
  and ualarm (microseconds) on Unix-like systems, enabling
  consistent test-level timeout enforcement.
Version 0.77 Release:
- Decision: Adopt SOP for Version Synchronization.
  The project maintains duplicate version strings across 24+ files. A
  Standard Operating Procedure was adopted to use a batch-replacement tool
  to update all sub-modules in lib/ and to always run
  make clean and perl Makefile.PL to ensure
  META.json and META.yml reflect the new
  version. After achieving stability on Linux, the project version was
  bumped to 0.77.
Infrastructure & Strategic Work:
- The ad2 Windows Server 2025 instance was restored and
  optimized, with Active Directory demoted and disk I/O performance
  improved.
- A strategic proposal for the Heterogeneous Directory
  Replication Protocol (HDRP) was drafted and published.

Part II: The
Great Async Refactor (March 17 – 18)

Despite success on Linux, tests on the slow ad2 Windows
host were still plagued by intermittent, indefinite hangs. This
triggered a fundamental architectural shift to move the library’s core
from a mix of synchronous and asynchronous code to a fully non-blocking
internal API.

Key Milestones &
Engineering Decisions:

Decision: Expose a _future API.
Instead of hardcoding timeouts in the library, the core strategy was to
refactor all blocking methods (xpath, field,
get, etc.) into thin wrappers around new non-blocking
..._future counterparts. This moved timeout management to
the test harness, allowing for flexible and explicit handling of
stalls.
```
# Example library implementation
sub xpath($self, $query, %options) {
    return $self->xpath_future($query, %options)->get;
}

sub xpath_future($self, $query, %options) {
    # Async implementation using $self->target->send_message(...)
}
```

Decision: Centralize Test Hardening in a Helper.
A dedicated test library, t/lib/t/helper.pm, was created to
contain all stabilization logic. “Safe” wrappers (safe_get,
safe_xpath) were implemented there, using
Future->wait_any to race asynchronous operations against
a timeout, preventing tests from hanging.

# Example test helper implementation
sub safe_xpath {
    my ($mech, $query, %options) = @_;
    my $timeout = delete $options{timeout} || 5;
    my $call_f = $mech->xpath_future($query, %options);
    my $timeout_f = $mech->sleep_future($timeout)->then(sub { Future->fail("Timeout") });
    return Future->wait_any($call_f, $timeout_f)->get;
}

Decision: Refactor Node Attribute Cache.
Investigations into flaky checkbox tests (t/50-tick.t)
revealed that WWW::Mechanize::Chrome::Node was storing
attributes as a flat list ([key, val, key, val]), which was
inefficient for lookups and individual updates. The cache was refactored
to definitively use a HashRef, providing O(1) lookups
and enabling atomic dual-updates where both the browser property (via
JS) and the internal library attribute are synchronized
simultaneously.
Decision: Implement Self-Cancelling Socket
Watchdog. On Windows, traditional watchdog processes often
failed to detect parent termination, leading to 60-second hangs after
successful tests. We implemented a new socket-based watchdog in
t::helper that listens on an ephemeral port; the background
process terminates immediately when the parent socket closes,
eliminating these cumulative delays.
Decision: Deep Recursive Refactoring & Form
Selection. To make the API truly non-blocking, the entire
internal call stack had to be refactored. For example, making
get_set_value_future non-blocking required first making its
dependency, _field_by_name, asynchronous. This culminated
in refactoring the entire form selection API (form_name,
form_id, etc.) to use the new asynchronous
_future lookups, which was a key step in mitigating the
Windows deadlocks.
Decision: Fix Critical Regressions & Memory
Cycles.
- Evaluation Normalization: Implemented a
  _process_eval_result helper to centralize the parsing of
  results from Runtime.evaluate. This ensures consistent
  handling of return values and exceptions between synchronous
  (eval_in_page) and asynchronous (eval_future)
  calls.
- Memory Cycle Mitigation: A significant memory
  leak was discovered where closures attached to CDP event futures (like
  for asynchronous body retrieval) would capture strong references to
  $self and the $response object, creating a
  circular reference. The established rule is to now always use
  Scalar::Util::weaken on both $self and any
  other relevant objects before they are used inside a
  ->then block that is stored on an object.
- Context Propagation (wantarray): A
  major regression was discovered where Perl’s wantarray
  context, which distinguishes between scalar and list context, was lost
  inside asynchronous Future->then blocks. This caused
  methods like xpath to return incorrect results (e.g., a
  count instead of a list of nodes). The solution was to adopt the “Async
  Context Pattern”: capture wantarray in the synchronous
  wrapper, pass it as an option to the _future method, and
  then use that captured value inside the future’s final resolution
  block.
```
# Synchronous Wrapper
sub xpath($self, $query, %options) {
    $options{ wantarray } = wantarray; # 1. Capture
    return $self->xpath_future($query, %options)->get; # 2. Pass
}

# Asynchronous Implementation
sub xpath_future($self, $query, %options) {
    my $wantarray = delete $options{ wantarray }; # 3. Retrieve
    # ... async logic ...
    return $doc->then(sub {
        if ($wantarray) { # 4. Respect
            return Future->done(@results);
        } else {
            return Future->done($results[0]);
        }
    });
}
```
- Asynchronous Body Retrieval & Robust Content
  Fallbacks: Fixed a bug where decoded_content()
  would return empty strings by ensuring it awaited a
  __body_future. This was implemented by storing the
  retrieval future directly on the response object
  ($response->{__body_future}). To make this more robust,
  a tiered strategy was implemented: first try to get the content from the
  network response, but if that fails (e.g., for about:blank
  or due to cache eviction), fall back to a JavaScript
  XMLSerializer to get the live DOM content.
- Signature Hardening: Fixed “Too few arguments”
  errors when using modern Perl signatures with
  Future->then. Callbacks were updated to use optional
  parameters (sub($result = undef) { ... }) to gracefully
  handle futures that resolve with no value.
- XHTML “Split-Brain” Bug: Resolved a
  long-standing Chromium bug (40130141) where content provided via
  setDocumentContent is parsed differently than content
  loaded from a URL. A workaround was implemented: for XHTML documents,
  WMC now uses a JavaScript-based XPath evaluation
  (document.evaluate) against the live DOM, bypassing the
  broken CDP search mechanism.

Derived Architectural Rules
& SOPs:

Rule: Always provide _future variants.
Every library method that interacts with the browser via CDP must have a
non-blocking asynchronous counterpart.
Rule: Centralize stabilization in the test layer.
All timeout and retry logic should reside in the test harness
(t/lib/t/helper.pm), not in the core library.
Rule: Explicitly propagate wantarray
context. Synchronous wrappers must capture the caller’s context
and pass it down the Future chain to ensure correct
scalar/list behavior.
Rule: The entire call chain must be asynchronous.
To enable non-blocking timeouts, even a single “hidden” blocking call in
an otherwise asynchronous method will cause a stall.
SOP: Reduce Library Noise. Diagnostic messages
(warn, note, diag) should be
removed from library code before commits. All such messages should be
converted to use the internal $self->log('debug', ...)
mechanism, ensuring a clean TAP output for CI systems.

Part III: The
`MutationObserver` Saga (March 19)

With most of the library refactored to be asynchronous, one stubborn
test, t/65-is_visible.t, continued to fail with timeouts.
This led to an ambitious, but ultimately unsuccessful, attempt to
replace the wait_until_visible polling logic with a more
“modern” MutationObserver.

Key Milestones & Challenges:

The Theory: The goal was to replace an inefficient
repeat { sleep } loop with an event-driven
MutationObserver in JavaScript that would notify Perl
immediately when an element’s visibility changed.
Implementation & Cascade Failure: The
implementation proved incredibly difficult and introduced a series of
new, hard-to-diagnose bugs:
1. An incorrect function signature for
  callFunctionOn_future.
2. A critical unit mismatch, passing seconds from Perl to JavaScript’s
  setTimeout, which expected milliseconds.
3. A fundamental hang where the MutationObserver’s
  JavaScript Promise would never resolve, even after the
  underlying DOM element changed.
Debugging Maze: Multiple attempts to fix the
checkVisibility JavaScript logic inside the observer
callback, including making it more robust by adding DOM tree traversal
and extensive console.log tracing, failed to resolve the
hang. This highlighted the opacity and difficulty of debugging complex,
cross-language asynchronous interactions, especially when dealing with
low-level browser APIs.

Procedural Learning:
Granular Edits

The effort was plagued by procedural missteps in using automated
file-editing tools. Initial attempts to replace large code blocks in a
single operation led to accidental code loss and match failures.

Decision: Adopt “Delete, then Add” Workflow.
Following forceful user correction, a new SOP was established for all
future modifications:
1. Isolate: Break the file into small, manageable
  chunks (e.g., 250 lines).
2. Delete: Perform a “delete” operation by replacing
  the old code block with an empty string.
3. Add: Perform an “add” operation by inserting the
  new code into the empty space.
4. Verify: Verifying each atomic step before
  proceeding. This granular process, while slower, ensured surgical
  precision and regained technical control over the large
  Chrome.pm module.

The consistent failure of the MutationObserver approach
eventually led to the decision to abandon it in favor of stabilizing the
original, more transparent implementation.

Part IV:
Reversion and Final Stabilization (March 20)

After exhausting all reasonable attempts to fix the
MutationObserver, a strategic decision was made to revert
to the simpler, more transparent polling implementation and fix it
correctly. This proved to be the correct path to a stable solution.

Key Milestones &
Engineering Decisions:

Decision: Perform Strategic Reversion. The
MutationObserver implementation, when integrated via
callFunctionOn_future with awaitPromise,
proved fundamentally unstable. Its JavaScript promise would consistently
fail to resolve, causing indefinite hangs. A decision was made to
revert all MutationObserver code from
WWW::Mechanize::Chrome.pm and restore the original
repeat { sleep } polling mechanism. A stable,
understandable solution was prioritized over an elegant but broken
one.
Decision: Correct Timeout Delegation in the
Harness. The root cause of the original timeout failure was
identified as a race condition in the t/lib/t/helper.pm
test harness. The safe_wait_until_* wrappers were
implementing their own timeout (via wait_any and
sleep_future) that raced against the underlying polling
function’s internal timeout. This led to intermittent failures on slow
machines. The helpers were refactored to delegate all timeout
management to the library’s polling functions, ensuring a
single, authoritative timer controlled the operation.
Decision: Optimize Polling Performance. At the
user’s request, the polling interval was reduced from 300ms to
150ms. This modest performance improvement reduced the
test suite’s wallclock execution time by over a second while maintaining
stability.
Decision: Tune Test Watchdogs. The global watchdog
timeout was adjusted to 12 seconds, specifically calculated as 1.5x the
observed real execution time of the optimized test. This provides a
data-driven safety margin for CI.

Part
V: The Last Bug – A Platform-Specific Memory Leak (March 20)

With all other tests passing, a single memory leak failure in
t/78-memleak.t persisted, but only on the Windows
ad2 environment. This required a different approach than
the timeout fixes.

Key Milestones:

The Bug: A strong reference cycle involving the
on_dialog event listener was not being broken on Windows,
despite multiple attempts to fix it. Fixes that worked on Linux (such as
calling on_dialog(undef) in DESTROY) were not
sufficient on the Windows host.
The Diagnosis: The issue was determined to be a
deep, platform-specific interaction between Perl’s garbage collector,
the IO::Async event loop implementation on Windows, and the
Test::Memory::Cycle module. The cycle report was identical
on both platforms, but the cleanup behavior was different.
Failed Attempts: A series of increasingly
aggressive fixes were attempted to break the cycle, including:
1. Moving the on_dialog(undef) call from
  close() to DESTROY().
2. Explicitly deleteing the listener and callback
  properties from the object hash in DESTROY.
3. Swapping between $self->remove_listener and
  $self->target->unlisten in a mistaken attempt to find
  the correct un-registration method.
Pragmatic Solution: After exhausting all reasonable
code-level fixes without a resolution on Windows, the user opted to mark
the failing test as a known issue for that specific platform.
Final Fix: The single failing test in
t/78-memleak.t was wrapped in a conditional
TODO block that only executes on Windows
(if ($^O =~ /MSWin32/i)), formally acknowledging the bug
without blocking the build. This allows the test suite to pass in CI
environments while flagging the issue for future, deeper
investigation.

Part VI: CI Hardening (March
20)

A final failure in the GitHub Actions CI environment revealed one
last configuration flaw.

Key Milestones:

The Bug: The CI was running
prove --nocount --jobs 3 -I local/ -bl xt t directly. This
command was missing the crucial -It/lib include path, which
is necessary for test files to locate the t::helper module.
This resulted in nearly all tests failing with
Can't locate t/helper.pm in @INC.
The Investigation: An analysis of
Makefile.PL revealed a custom MY::test block
specifically designed to inject the -It/lib flag into the
make test command. This confirmed that
make test is the correct, canonical way to run the test
suite for this project.
The Fix: The
.github/workflows/linux.yml file was modified to replace
the direct prove call with make test in the
Run Tests step. This ensures the CI environment runs the
tests in the exact same way as a local developer, with all necessary
include paths correctly configured by the project’s build system.

Final Outcome

After this long and arduous journey, the
WWW::Mechanize::Chrome test suite is now stable and
passing on all targeted platforms, with known
platform-specific issues clearly documented in the code. The project is
in a vastly more robust and reliable state.

21 March, 2026 01:52AM by C.J. Collier

March 20, 2026

Dirk Eddelbuettel

RcppSpdlog 0.0.28 on CRAN: Micro-Maintenance

Version 0.0.28 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 contains a rebuild RcppExports.cpp to aid Rcpp in the transition towards Rcpp::stop() and away from Rf_error() in its user packages. No othe

The NEWS entry for this release follows.

Changes in RcppSpdlog version 0.0.28 (2026-03-19)

Regenerate RcppExports.cpp to switch to (Rf_error) aiding in Rcpp transition to Rcpp::stop()

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.

20 March, 2026 09:47PM

Reproducible Builds (diffoscope)

diffoscope 315 released

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

[ Jelle van der Waa ]
* Adjust PGP file detection regex.

You find out more by visiting the project homepage.

20 March, 2026 12:00AM

Michael Ablassmeier

virtnbdbackup 2.46 - bitlocker recovery keys

I’ve released virtnbdbackup 2.46 which now attempts to extract the bitlocker recovery keys during backup. The windows domains need a working qemu agent installed during backup for this to work.

Using the agent, it also extracts the available guestinfo (network config, OS version etc..) from the domain and stores it alongside with the backup.

20 March, 2026 12:00AM

March 19, 2026

Otto Kekäläinen

Automated security validation: How 7,000+ tests shaped MariaDB's new AppArmor profile

Linux kernel security modules provide a good additional layer of security around individual programs by restricting what they are allowed to do, and at best block and detect zero-day security vulnerabilities as soon as anyone tries to exploit them, long before they are widely known and reported. However, the challenge is how to create these security profiles without accidentally also blocking legitimate actions. For MariaDB in Debian and Ubuntu, a new AppArmor profile was recently created by leveraging the extensive test suite with 7000+ tests, giving good confidence that AppArmor is unlikely to yield false positive alerts with it.

AppArmor is a Mandatory Access Control (MAC) system, meaning that each process controlled by AppArmor has a sort of an “allowlist” called profile that defines all capabilities and file paths a program can access. If a program tries to do something not covered by the rules in its AppArmor profile, the action will be denied on the Linux kernel level and a warning logged in the system journal. This additional security layer is valuable because even if a malicious user found a security vulnerability some day in the future, the AppArmor profile severely restricts the ability to exploit it and gain access to the operating system.

AppArmor was originally developed by Novell for use in SUSE Linux, but nowadays the main driver is Canonical and AppArmor is extensively used in Ubuntu and Debian, and many of their derivatives (e.g. Linux Mint, Pop!_OS, Zorin OS) and in Arch. AppArmor’s benefit compared to the main alternative SELinux (used mainly in the RedHat/Fedora ecosystem) is that AppArmor is easier to manage. AppArmor continues to be actively developed, with new major version 5.0 expected to arrive soon.

I also have some personal history contributing some notification handler scripts in Python and I also created the website that AppArmor.net still runs.

Regular review of denials in the system log required

Any system administrator using Debian/Ubuntu needs to know how to check for AppArmor denials. The point of using AppArmor is kind of moot if nobody is checking the denials. When AppArmor blocks an action, it logs the event to the system audit or kernel logs. Understanding these logs is crucial for troubleshooting custom configurations or identifying potential security incidents.

To view recent denials, check /var/log/audit/audit.log or run journalctl -ke --grep=apparmor.

A typical denial entry for MariaDB will look like this (split across multiple lines for legibility):

msg=audit(1700000000.123:456): apparmor="DENIED" operation="open"
profile="/usr/sbin/mariadbd" name="/custom/data/path/test.ibd" pid=1234
comm="mariadbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

How to interpret this output:

msg=audit(…): The audit timestamp and event serial number.
apparmor=“DENIED”: Indicates AppArmor blocked the action.
operation: The action being attempted (e.g., open, mknod, file_mmap, file_perm).
profile: The specific AppArmor profile that triggered the denial (in this case the /usr/sbin/mariadbd profile).
name: The file path or resource that was blocked. In the example above, a custom data path was denied access because it wasn’t defined in the profile’s allowed abstractions.
comm: The command name that triggered the denial (here mariadbd).
requested_mask / denied_mask: Shows the permissions requested (e.g., r for read, w for write).
pid: The process ID.
fsuid: The user ID of the process attempting the action.
ouid: The owner user ID of the target file.

If an action seems legit and should not be denied, the sysadmin needs to update the existing rules at /etc/apparmor.d/ or drop a local customization file in at /etc/apparmor.d/local/. If the denied action looks malicious, the sysadmin should start a security investigation and if needed report a suspected zero-day vulnerability to the upstream software vendor (e.g. Ubuntu customers to Canonical, or MariaDB customers to MariaDB).

AppArmor in MariaDB - not a novel thing, and not easy to implement well

Based on old bug reports, there was an AppArmor profile already back in 2011, but it was removed in MariaDB 5.1.56 due to backlash from users running into various issues. A new profile was created in 2015, but kept opt-in only due to the risk of side effects. It likely had very few users and saw minimal maintenance, getting only a handful of updates in the past 10 years.

The primary challenge in using mandatory access control systems with MariaDB lies in the sheer breadth of MariaDB’s operational footprint with diverse storage engines and plugins. Also the code base in MariaDB assumes that system calls to Linux always work – which they do under normal circumstances – and do not handle errors well if AppArmor suddenly denies a system call. MariaDB is also a large and complex piece of software to run and operate, and it can be very challenging for system administrators to root-cause that a misbehavior in their system was due to AppArmor blocking a single syscall.

Ironically, AppArmor is most beneficial exactly due to the same reasons for MariaDB. The larger and more complex a software is, the larger are the odds of a security vulnerability arising between the various components. And AppArmor profile helps reduce this complexity down to a single access list.

Over the years there has been users requesting to get the AppArmor profile back, such as Debian Bug#875890 since 2017. The need was raised recently again by the Ubuntu security team during the MariaDB Ubuntu ‘main’ inclusion review in 2025, which prompted a renewed effort by Debian/Ubuntu developers, mainly myself and Aquila Macedo, with upstream MariaDB assistance from Daniel Black.

A fresh approach: leverage the MariaDB test suite for automated testing and the open source community for reviews

The key to creating a robust AppArmor profile is the ability to know in detail what is expected and normal behavior of the system. One could in theory read all of the source code in MariaDB, but with over two million lines, it is of course not feasible in practice. However, MariaDB does have a very extensive 7000+ test suite, and running it should trigger most code paths in MariaDB. Utilizing the test suite was key in creating the new AppArmor profile for MariaDB: we installed MariaDB on a Ubuntu system, enabled AppArmor in complain mode and iterated on the allowlist by running the full mariadb-test-run with all MariaDB plugins and features enabled until we had a comprehensive yet clean list of rules.

To be extra diligent, we also reworked the autopkgtest for MariaDB in Debian and Ubuntu CI systems to run with the AppArmor profile enabled and to print all AppArmor notices at the end of the run, making it easy to detect now and in the future if the MariaDB test suite triggers any AppArmor denials. If any test fails, the release would not get promoted further, protecting users from regressions.

While developing and triggering manual test runs we used the maximal achievable test suite with 7177 tests. The test is however so extensive it takes over two hours to run, and it also has some brittle tests, so the standard test run in Debian and Ubuntu autopkgtest is limited just to MariaDB’s main suite with about 1000 tests. Having some tests fail while testing the AppArmor profile was not a problem, because we didn’t need all the tests to pass – we merely needed them to run as many code paths as possible to see if they run any system calls not accounted for in the AppArmor profile.

Note that extending the profile was not just mechanical copying of log messages to the profile. For example, even though a couple of tests involve running the dash shell, we decided to not allow it, as it opens too much of a path for a potential exploit to access the operating system.

The result of this effort is a modernized, robust profile that is now production-ready. Those interested in the exact technical details can read the Debian Bug#1130272 and the Merge Request discussions at salsa.debian.org, which hosts the Debian packaging source code.

Now available in Debian unstable, soon Ubuntu – feedback welcome!

Even though the file is just 200 lines long, the work to craft it spanned several weeks. To minimize risk we also did a gradual rollout by releasing the first new profile version in complain mode, so AppArmor only logs would-be-denials without blocking anything. The AppArmor profile was switched to enforce mode only in the very latest MariaDB revision 1:11.8.6-4 in Debian, and a NEWS item issued to help increase user awareness of this change. It is also slated for the upcoming Ubuntu 26.04 “Resolute Raccoon” release next month, providing out-of-the-box hardening for the wider ecosystem.

While automated testing is extensive, it cannot simulate everything. Most notably various complicated replication topologies and all Galera setups are likely not covered. Thus, I am calling on the community to deploy this profile and monitor for any audit denials in the kernel logs. If you encounter unexpected behavior or legitimate denials, please submit a bug report via the Debian Bug Tracking System.

To ensure you are running the latest MariaDB version, run apt install --update --yes mariadb-server. To view the latest profile rules, run cat /etc/apparmor.d/mariadbd and to see if it is enforced review the output of aa-status. To quickly check if there were any AppArmor denials, simply run journalctl -k | grep -i apparmor | grep -i mariadb.

Systemd hardening also adopted as security features keep evolving

For those interested in MariaDB security hardening, note that also new systemd hardening options were rolled out in Debian/Ubuntu recently. Note that Debian and Ubuntu are mainly volunteer-driven open source developer communities, and if you find this topic interesting and you think you have the necessary skills, feel free to submit your improvement ideas as Merge Requests at salsa.debian.org/mariadb-team. If your improvement suggestions are not Debian/Ubuntu specific, please submit them directly to upstream at GitHub.com/MariaDB.

19 March, 2026 12:00AM

March 18, 2026

Dirk Eddelbuettel

tidyCpp 0.0.11 on CRAN: Microfix

And yet another maintenance release of the tidyCpp package arrived on CRAN this morning, just days after previous release which itself came a mere week and a half after its predecessor. It has been built for r2u as well. The package offers a clean C++ layer (as well as one small C++ helper class) on top of the C API for R which aims to make use of this robust (if awkward) C API a little easier and more consistent. See the vignette for motivating examples.

This release restores the small CSS file used by the vignette which we, in a last-second decision, omitted from the previous release. Oddly, it only failed under the ‘oldrel’ i.e. the R from now nearly two years ago. But it was still an unenforced error, and this upload corrects it.

Changes are summarized in the NEWS entry that follows.

Changes in tidyCpp version 0.0.11 (2026-03-17)

Keep a CSS file in the package to allow vignette build on r-oldrel too

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

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

18 March, 2026 08:49PM

Bits from Debian

Debian pt_BR localization team and UFABC's mentoring program

Between July and November 2025, the Debian pt_BR translation team received five students for an online mentoring program. The initiative was carried out in partnership with the Federal University of ABC through the extension project "Immersion in Free Software", coordinated by professors Suzana Santos and Miguel Vieira.

During the mentorship the mentees acted on several of the team's translation efforts and joined presentations about the Debian Project and its community given by the mentors. We thank the dedication and contributions of Ana Parra, Bruno Freitas, Henrique Barbosa, Raul Banzatto and Vitoria Cordeiro. And we also thank the members of the team who have reviewed the work of the mentees, specially the ones who were designated as official mentors, namely Allythy Rennan, Daniel Lenharo, Thiago Pezzo, and Victor Marinho.

Results:

Package descriptions, translations: 27
Package descriptions, revisions: 190
Web pages: 11
Revisions to the Debian Administrator's Handbook
Revisions to the Debian Edu documentation

We hope that this experience will inspire new paths and that you continue to contribute to Free Software – especially to Debian.

18 March, 2026 04:45PM by Thiago Pezzo, Daniel Lenharo

Taavi Väänänen

Wikimedia Hackathon Northwestern Europe 2026

Wikimedia Nederland organised a new type of event this year, the Wikimedia Hackathon Northwestern Europe 2026, which was held last weekend in Arnhem, the Netherlands. And I'm very happy they did, since unlike last years, I will unfortunately be missing from the "main" Wikimedia Hackathon (which is happening in Milan at the start of May).

I continue to believe the primary reason for these events existing is the ability to connect with old and new friends in person. That being said, I did get a bit of technical tinkering done during the weekend as well. These include a dark mode fix to MediaWiki's notification interface, fixes to some visual bugs in MediaWiki's two-factor authentication and OAuth functionality. I did also get an older patch of mine about disabling Composer's new auditing functionality merged. And, as usual, I spent a bunch of time helping various people use with the various infrastructure pieces I'm familiar with (or at least had to suddenly get familiar with) and approved a bunch of OAuth consumers and other requests.

We also managed to continue the tradition from the past two Wikimedia Hackathons of nominating more people to receive +2 access to mediawiki/*. That request is still open as of writing, as those have to run for at least a week, but looks very likely to pass at this point.

Overall, the event was very well-organized: the venue was great, except that the number of stairs was described in a rather misleading way, food was great, and the atmosphere was amazing. The pressure that you must Just Get Things Done to justify your attendance that the main hackathon seems to have recently gained was clearly missing here which was great. Also, I will clearly need to bring more Finnish chocolate next time.

The timing of Friday and Saturday works great for us with other things (like university for me) during the week, as it takes full advantage of the weekend but still only eats workdays from a single calendar week. My main gripe with the logistics was the focus on a single sketchy non-free messaging platform for all event-related communications with the IRC bridge used on the main hackathon channel notably missing.

ps. Like Lucas, I do have Opinions about so many proudly mentioning they've used "vibe coding" tools during the introduction and showcase. Those opinions are best left for an another time, but I do want to note that all of my work and mistakes have still been lovingly handcrafted.

18 March, 2026 12:00AM by Taavi Väänänen (taavi@majava.org)