An offline PKI enhances security by physically isolating the certificate
authority from network threats. A YubiKey is a low-cost solution to store a
root certificate. You also need an air-gapped environment to operate the root
CA.
Offline PKI backed up by 3 YubiKeys
This post describes an offline PKI system using the following components:
2 YubiKeys for the root CA (with a 20-year validity),
1 YubiKey for the intermediate CA (with a 5-year validity), and
It is possible to add more YubiKeys as a backup of the root CA if needed. This
is not needed for the intermediate CA as you can generate a new one if
the current one gets destroyed.
The software part
offline-pki is a small Python application to manage an offline PKI.
It relies on yubikey-manager to manage YubiKeys and cryptography for
cryptographic operations not executed on the YubiKeys. The application has some
opinionated design choices. Notably, the cryptography is hard-coded to use NIST
P-384 elliptic curve.
The first step is to reset all your YubiKeys:
$ offline-pkiyubikeyreset
This will reset the connected YubiKey. Are you sure? [y/N]: yNew PIN code:Repeat for confirmation:New PUK code:Repeat for confirmation:New management key ('.' to generate a random one):WARNING[pki-yubikey] Using random management key: e8ffdce07a4e3bd5c0d803aa3948a9c36cfb86ed5a2d5cf533e97b088ae9e629INFO[pki-yubikey] 0: Yubico YubiKey OTP+FIDO+CCID 00 00INFO[pki-yubikey] SN: 23854514INFO[yubikit.management] Device config writtenINFO[yubikit.piv] PIV application data reset performedINFO[yubikit.piv] Management key setINFO[yubikit.piv] New PUK setINFO[yubikit.piv] New PIN setINFO[pki-yubikey] YubiKey reset successful!
Then, generate the root CA and create as many copies as you want:
$ offline-pkicertificateroot--permittedexample.com
Management key for Root X:Plug YubiKey "Root X"...INFO[pki-yubikey] 0: Yubico YubiKey CCID 00 00INFO[pki-yubikey] SN: 23854514INFO[yubikit.piv] Data written to object slot 0x5fc10aINFO[yubikit.piv] Certificate written to slot 9C (SIGNATURE), compression=TrueINFO[yubikit.piv] Private key imported in slot 9C (SIGNATURE) of type ECCP384Copy root certificate to another YubiKey? [y/N]: yPlug YubiKey "Root X"...INFO[pki-yubikey] 0: Yubico YubiKey CCID 00 00INFO[pki-yubikey] SN: 23854514INFO[yubikit.piv] Data written to object slot 0x5fc10aINFO[yubikit.piv] Certificate written to slot 9C (SIGNATURE), compression=TrueINFO[yubikit.piv] Private key imported in slot 9C (SIGNATURE) of type ECCP384Copy root certificate to another YubiKey? [y/N]: n
Then, you can create an intermediate certificate with offline-pki yubikey
intermediate and use it to sign certificates by providing a CSR to offline-pki
certificate sign. Be careful and inspect the CSR before signing it, as only the
subject name can be overridden. Check the documentation for more details.
Get the available options using the --help flag.
The hardware part
To ensure the operations on the root and intermediate CAs are air-gapped,
a cost-efficient solution is to use an ARM64 single board computer. The Libre
Computer Sweet Potato SBC is a more open alternative to the well-known
Raspberry Pi.1
Libre Computer Sweet Potato SBC, powered by the AML-S905X SOC
I interact with it through an USB to TTL UART converter:
$ tio/dev/ttyUSB0
[16:40:44.546] tio v3.7[16:40:44.546] Press ctrl-t q to quit[16:40:44.555] Connected to /dev/ttyUSB0GXL:BL1:9ac50e:bb16dc;FEAT:ADFC318C:0;POC:1;RCY:0;SPI:0;0.0;CHK:0;TE: 36574BL2 Built : 15:21:18, Aug 28 2019. gxl g1bf2b53 - luan.yuan@droid15-szset vcck to 1120 mvset vddee to 1000 mvBoard ID = 4CPU clk: 1200MHz[ ]
The Nix glue
To bring everything together, I am using Nix with a Flake providing:
a package for the offline-pki application, with shell completion,
a development shell, including an editable version of the offline-pki application,
a NixOS module to setup the offline PKI, resetting the system at each boot,
a QEMU image for testing, and
an SD card image to be used on the Sweet Potato or another ARM64 SBC.
# Execute the application locally
nixrungithub:vincentbernat/offline-pki----help
# Run the application inside a QEMU VM
nixrungithub:vincentbernat/offline-pki\#qemu
# Build a SD card for the Sweet Potato or for the Raspberry Pi
nixbuild--systemaarch64-linuxgithub:vincentbernat/offline-pki\#sdcard.potato
nixbuild--systemaarch64-linuxgithub:vincentbernat/offline-pki\#sdcard.generic
# Get a development shell with the application
nixdevelopgithub:vincentbernat/offline-pki
The key for the root CA is not generated by the YubiKey. Using an
air-gapped computer is all the more important. Put it in a safe with the
YubiKeys when done!
For uninteresting reasons I need very regular 58Hz pulses coming out of an
RS-232 Tx line: the time between each pulse should be as close to 1/58s as
possible. I produce each pulse by writing an \xFF byte to the device. The
start bit is the only active-voltage bit being sent, and that produces my pulse.
I wrote this obvious C program:
#include<stdio.h>#include<stdlib.h>#include<stdbool.h>#include<sys/ioctl.h>#include<unistd.h>#include<fcntl.h>#include<termios.h>#include<stdint.h>#include<sys/time.h>staticuint64_tgettimeofday_uint64()
structtimevaltv;
gettimeofday(&tv, NULL);
return (uint64_t) tv.tv_sec * 1000000ULL + (uint64_t) tv.tv_usec;
intmain(intargc, char* argv[])
// open the serial device, and make it as raw as possibleconstchar* device = "/dev/ttyS0";
constspeed_tbaud = B9600;
intfd = open(device, O_WRONLY O_NOCTTY);
tcflush(fd, TCIOFLUSH);
structtermiosoptions = .c_iflag = IGNBRK,
.c_cflag = CS8 CREAD CLOCAL ;
cfsetspeed(&options, baud);
tcsetattr(fd, TCSANOW, &options);
constuint64_tT_us = (uint64_t)(1e6 / 58.);
constuint64_tt0 = gettimeofday_uint64();
for(inti=0; ; i++)
constuint64_tt_target = t0 + T_us*i;
constuint64_tt1 = gettimeofday_uint64();
if(t_target > t1)
usleep(t_target - t1);
write(fd, &((char) '\xff' ), 1);
return 0;
This tries to make sure that each write() call happens at 58Hz. I need these
pulses to be regular, so I need to also make sure that the time between each
userspace write() and when the edge actually hits the line is as short as
possible or, at least, stable.
Potential reasons for timing errors:
The usleep() doesn't wake up exactly when it should. This is subject to the
Linux scheduler waking up the trigger process
The write() almost certainly ends up scheduling a helper task to actually
write the \xFF to the hardware. This helper task is also subject to the
Linux scheduler waking it up.
Whatever the hardware does. RS-232 doesn't give you any guarantees about
byte-byte timings, so this could be an unfixable source of errors
The scheduler-related questions are observable without any extra hardware, so
let's do that first.
I run the ./trigger program, and look at diagnostics while that's running.
I look at some device details:
# ls -lh /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Mar 6 18:11 /dev/ttyS0
# ls -lh /sys/dev/char/4:64/
total 0
-r--r--r-- 1 root root 4.0K Mar 6 16:51 close_delay
-r--r--r-- 1 root root 4.0K Mar 6 16:51 closing_wait
-rw-r--r-- 1 root root 4.0K Mar 6 16:51 console
-r--r--r-- 1 root root 4.0K Mar 6 16:51 custom_divisor
-r--r--r-- 1 root root 4.0K Mar 6 16:51 dev
lrwxrwxrwx 1 root root 0 Mar 6 16:51 device -> ../../../0000:00:16.3:0.0
-r--r--r-- 1 root root 4.0K Mar 6 16:51 flags
-r--r--r-- 1 root root 4.0K Mar 6 16:51 iomem_base
-r--r--r-- 1 root root 4.0K Mar 6 16:51 iomem_reg_shift
-r--r--r-- 1 root root 4.0K Mar 6 16:51 io_type
-r--r--r-- 1 root root 4.0K Mar 6 16:51 irq
-r--r--r-- 1 root root 4.0K Mar 6 16:51 line
-r--r--r-- 1 root root 4.0K Mar 6 16:51 port
drwxr-xr-x 2 root root 0 Mar 6 16:51 power
-rw-r--r-- 1 root root 4.0K Mar 6 16:51 rx_trig_bytes
lrwxrwxrwx 1 root root 0 Mar 6 16:51 subsystem -> ../../../../../../../class/tty
-r--r--r-- 1 root root 4.0K Mar 6 16:51 type
-r--r--r-- 1 root root 4.0K Mar 6 16:51 uartclk
-rw-r--r-- 1 root root 4.0K Mar 6 16:51 uevent
-r--r--r-- 1 root root 4.0K Mar 6 16:51 xmit_fifo_size
Unsurprisingly, this is a part of the tty subsystem. I don't want to spend the
time to really figure out how this works, so let me look at all the tty
kernel calls and also at all the kernel tasks scheduled by the trigger
process, since I suspect that the actual hardware poke is happening in a helper
task. I see this:
Looking at the sources I see that uart_write() calls __uart_start(), which
schedules a task to call serial_port_runtime_resume() which eventually calls
serial8250_tx_chars(), which calls some low-level functions to actually send
the bits.
I look at the time between two of those calls to quantify the scheduler latency:
The offset from 58Hz of when each write() call happens. This shows effect #1
from above: how promptly the trigger process wakes up
The latency of the helper task. This shows effect #2 above.
The raw data as I tweak things lives here. Initially I see big latency spikes:
These can be fixed by adjusting the priority of the trigger task. This tells
the scheduler to wake that task up first, even if something else is currently
using the CPU. I do this:
sudo chrt -p 90 pidof trigger
And I get better-looking latencies:
During some experiments (not in this dataset) I would see high helper-task
timing instabilities as well. These could be fixed by prioritizing the helper
task. In this kernel (6.12) the helper task is called kworker/N where N is
the CPU index. I tie the trigger process to cpu 0, and priorities all the
relevant helpers:
This fixes the helper-task latency spikes.
OK, so it looks like on the software side we're good to within 0.1ms of the true
period. This is in the ballpark of the precision I need; even this might be too
high. It's possible to try to push the software to do better: one could look at
the kernel sources a bit more, to do smarter things with priorities or to try an
-rt kernel. But all this doesn't matter if the serial hardware adds
unacceptable delays. Let's look.
Let's look at it with a logic analyzer. I use a saleae logic analyzer with
sigrok. The tool spits out the samples as it gets them, and an awk script
finds the edges and reports the timings to give me a realtime plot.
On the server I was using (physical RS-232 port, ancient 3.something kernel):
OK This is very discrete for some reason, and generally worse than 0.1ms.
What about my laptop (physical RS-232 port, recent 6.12 kernel)?
Not discrete anymore, but not really any more precise. What about using a
usb-serial converter? I expect this to be worse.
Yeah, looks worse. For my purposes, an accuracy of 0.1ms is marginal, and the
hardware adds non-negligible errors. So I cut my losses, and use an external
signal generator:
Debian.Social administration, by Stefano Rivera
Over the last year, the Debian.social
services outgrew the infrastructure
that was supporting them. The matrix bridge in particular was hosted on a cloud
instance backed by a large expensive storage volume. Debian.CH rented a new
large physical server to host all these instances, earlier this year. Stefano
set up Incus on the new physical machine
and migrated all the old debian.social LXC Containers, libvirt VMs, and cloud
instances into Incus-managed LXC containers.
Stefano set up Prometheus monitoring and alerts for the new infrastructure and a
Grafana dashboard. The current stack of
debian.social services seem to comfortably fit on the new machine, with good
room to grow.
DebConf 25, by Santiago Ruano Rinc n and Stefano Rivera
DebConf 25 preparations continue. The team is currently finalizing a budget.
Stefano helped to review the current budget proposals and suggest approaches for
balancing it.
Stefano installed a Zammad instance to organize
queries from attendees, for the registration and visa teams.
Santiago continued discussions with possible caterers so we can have options for
the different diet requirements and that could fit into the DebConf budget.
Also, in collaboration with Anupa, Santiago pushed the first
draft changes
to document the venue information in the DebConf 25 website and how to get to
Brest.
Time-based test failure in requests, by Colin Watson
Colin fixed a fun bug in the Python
requests package. Santiago Vila
has been running
tests of what
happens when Debian packages are built on a system in which time has been
artificially set to somewhere around the end of the support period for the next
Debian release, in order to make it easier to do things like issuing security
updates for the lifetime of that release. In this case, the
failure indicated an expired test
certificate, and since the repository already helpfully included scripts to
regenerate those certificates, it seemed natural to try regenerating them just
before running tests. However, this
failed for more obscure reasons
and Colin spent some time investigating. This turned out to be because the test
CA was missing the CA constraint and so recent versions of OpenSSL reject it;
Colin sent a pull request to fix
this.
Priority list for outdated packages, by Santiago Ruano Rinc n
Santiago started a
discussion on
debian-devel about packages that have a history of security issues and that are
outdated regarding new upstream releases. The goal of the mentioned effort is to
have a prioritized list of packages needing some work, from a security point of
view. Moreover, the aim of publicly sharing the list of packages with the Debian
Developers community is to make it easier to look at the packages maintained by
teams, or even other maintainers where help could be welcome. Santiago is
planning to take into account the feedback provided in debian-devel and to
propose a tooling that could help to regularly bring collective awareness of
these packages.
Miscellaneous contributions
Carles worked on English to Catalan po-debconf translations: reviewed
translations, created merge requests and followed up with developers for more
than 30 packages using po-debconf-manager.
Carles helped users, fixed bugs and implemented downloading updated templates
on po-debconf-manager.
Carles packaged a new upstream version of python-pyaarlo.
Carles improved reproducibility of qnetload (now reported as reproducible) and
simplemonitor (followed up with upstream and pending update of Debian package).
Carles collaborated with debian-history package: fixed FTBFS from master
branch, enabled salsa-ci and investigated reproducibility.
Emilio improved support for automatically marking CVEs as NOT-FOR-US in the
security-tracker, closing #1073012.
Emilio updated xorg-server and xwayland in unstable, fixing the last round of
security vulnerabilities.
Helmut Grohne sent patches for 24 cross build failures.
Helmut fixed two problems in the Debian /usr-merge analysis tool. In one
instance, it would overmatch Debian bugs to issues and in another it would fail
to recognize Pre-Depends as a conflict mechanism.
Helmut attempted making rebootstrap work for gcc-15 with limited success as
very many packages FTBFS with gcc-15 due to using function declarations without
arguments.
Helmut provided a change to the security-tracker that would pre-compute
/data/json during database updates rather than on demand resulting in a
reduced response time.
Colin uploaded OpenSSH security
updates for testing/unstable,
bookworm, bullseye, buster, and stretch.
Colin fixed upstream monitoring for 26
Python packages, and upgraded 54 packages (mostly Python-related, but also
PuTTY) to new upstream versions.
Colin updated python-django in bookworm-backports to 4.2.18 (issuing
BSA-121),
and added new backports of python-django-dynamic-fixture
and python-django-pgtrigger, all of which are dependencies of
debusine.
Thorsten Alteholz finally managed to upload hplip to fix two release critical
and some normal bugs. The next step in March would be to upload the latest
version of hplip.
Faidon updated crun in unstable & trixie, resolving a long-standing request of
enabling criu support and thus enabling podman with checkpoint/restore
functionality (With gratitude to Salvatore Bonaccorso and Reinhard Tartler for
the cooperation and collaboration).
Faidon uploaded a number of packages (librdkafka, libmaxminddb,
python-maxminddb, lowdown, tox, tox-uv, pyproject-api, xiccd and gdnsd) bringing
them up to date with new upstream releases, resolving various bugs.
Lucas Kanashiro uploaded some ruby packages involved in the Rails 7 transition
with new upstream releases.
Lucas triaged a ruby3.1 bug
(#1092595)) and
prepared a fix for the next stable release update.
Lucas set up the needed wiki pages and updated the Debian Project status in
the Outreachy portal, in order to send out a call for projects and mentors for
the next round of Outreachy.
Anupa joined Santiago to prepare a list of companies to contact via LinkedIn
for DebConf 25 sponsorship.
Anupa printed Debian stickers and sponsorship brochures, flyers for DebConf
25 to be distributed at FOSS ASIA summit 2025.
Anupa participated in the Debian publicity team meeting and discussed the
upcoming events and tasks.
Rapha l packaged zim 0.76.1 and integrated an upstream patch for another
regression that he reported.
Rapha l worked with the Debian System Administrators for tracker.debian.org
to better cope with gmail s requirement for mails to be authenticated.
The other day, I noted that the emacs integration with debputy stopped working.
After debugging for a while, I realized that emacs no longer sent the didOpen
notification that is expected of it, which confused debputy. At this point, I was
already several hours into the debugging and I noted there was some discussions on
debian-devel about emacs and byte compilation not working. So I figured I would
shelve the emacs problem for now.
But I needed an LSP capable editor and with my vi skills leaving much to be desired,
I skipped out on vim-youcompleteme. Instead, I pulled out kate, which I had not
been using for years. It had LSP support, so it would fine, right?
Well, no. Turns out that debputy LSP support had some assumptions that worked for
emacs but not kate. Plus once you start down the rabbit hole, you stumble on
things you missed previously.
Getting started
First order of business was to tell kate about debputy. Conveniently, kate has
a configuration tab for adding language servers in a JSON format right next to the tab where
you can see its configuration for built-in LSP (also in JSON format9. So a quick bit of
copy-paste magic and that was done.
Yesterday, I opened an MR against upstream to have the configuration added
(https://invent.kde.org/utilities/kate/-/merge_requests/1748) and they already merged it.
Today, I then filed a wishlist against kate in Debian to have the Debian maintainers
cherry-pick it, so it works out of the box for Trixie (https://bugs.debian.org/1099876).
So far so good.
Inlay hint woes
Since July (2024), debputy has support for Inlay hints. They are basically small
bits of text that the LSP server can ask the editor to inject into the text to provide
hints to the reader.
Typically, you see them used to provide typing hints, where the editor or the underlying
LSP server has figured out the type of a variable or expression that you did not
explicitly type. Another common use case is to inject the parameter name for positional
arguments when calling a function, so the user do not have to count the position to
figure out which value is passed as which parameter.
In debputy, I have been using the Inlay hints to show inherited fields in
debian/control. As an example, if you have a definition like:
Source: foo-src
Section: devel
Priority: optional
Package: foo-bin
Architecture: any
Then foo-bin inherits the Section and Priority field since it does not supply
its own. Previously, debputy would that by injecting the fields themselves and their
value just below the Package field as if you had typed them out directly. The editor
always renders Inlay hints distinctly from regular text, so there was no risk of
confusion and it made the text look like a valid debian/control file end to end. The
result looked something like:
With the second instances of Section and Priority being rendered differently than
its surrendering (usually faded or colorlessly).
Unfortunately, kate did not like injecting Inlay hints with a newline in them,
which was needed for this trick. Reading into the LSP specs, it says nothing about
multi-line Inlay hints being a thing and I figured I would see this problem again
with other editors if I left it be.
I ended up changing the Inlay hints to be placed at the end of the Package field
and then included surrounding () for better visuals. So now, it looks like:
Unfortunately, it is no longer 1:1 with the underlying syntax which I liked about the
previous one. But it works in more editors and is still explicit. I also removed the
Inlay hint for the Homepage field. It takes too much space and I have yet to
meet someone missing it in the binary stanza.
If you have any better ideas for how to render it, feel free to reach out to me.
Spurious completion and hover
As I was debugging the Inlay hints, I wanted to do a quick restart of debputy after
each fix. Then I would trigger a small change to the document to ensure kate would
request an update from debputy to render the Inlay hints with the new code.
The full outgoing payloads are sent via the logs to the client, so it was really about
minimizing which LSP requests are sent to debputy. Notably, two cases would flood the
log:
Completion requests. These are triggered by typing anything at all and since I wanted
to a change, I could not avoid this. So here it was about making sure there would be
nothing to complete, so the result was a small as possible.
Hover doc requests. These are triggered by mouse hovering over field, so this was
mostly about ensuring my mouse movement did not linger over any field on the way
between restarting the LSP server and scrolling the log in kate.
In my infinite wisdom, I chose to make a comment line where I would do the change. I figured
it would neuter the completion requests completely and it should not matter if my cursor
landed on the comment as there would be no hover docs for comments either.
Unfortunately for me, debputy would ignore the fact that it was on a comment line.
Instead, it would find the next field after the comment line and try to complete based on
that. Normally you do not see this, because the editor correctly identifies that none of
the completion suggestions start with a \#, so they are all discarded.
But it was pretty annoying for the debugging, so now debputy has been told to explicitly
stop these requests early on comment lines.
Hover docs for packages
I added a feature in debputy where you can hover over package names in your relationship
fields (such as Depends) and debputy will render a small snippet about it based on
data from your local APT cache.
This doc is then handed to the editor and tagged as markdown provided the editor supports
markdown rendering. Both emacs and kate support markdown. However, not all
markdown renderings are equal. Notably, emacs's rendering does not reformat the text
into paragraphs. In a sense, emacs rendering works a bit like <pre>...</pre> except
it does a bit of fancy rendering inside the <pre>...</pre>.
On the other hand, kate seems to convert the markdown to HTML and then throw the result
into an HTML render engine. Here it is important to remember that not all newlines are equal
in markdown. A Foo<newline>Bar is treated as one "paragraph" (<p>...</p>) and the HTML
render happily renders this as single line Foo Bar provided there is sufficient width to
do so.
A couple of extra newlines made wonders for the kate rendering, but I have a feeling this
is not going to be the last time the hover docs will need some tweaking for prettification.
Feel free to reach out if you spot a weirdly rendered hover doc somewhere.
Making quickfixes available in kate
Quickfixes are treated as generic code actions in the LSP specs. Each code action has a "type"
(kind in the LSP lingo), which enables the editor to group the actions accordingly or
filter by certain types of code actions.
The design in the specs leads to the following flow:
The LSP server provides the editor with diagnostics (there are multiple ways to trigger
this, so we will keep this part simple).
The editor renders them to the user and the user chooses to interact with one of them.
The interaction makes the editor asks the LSP server, which code actions are available
at that location (optionally with filter to only see quickfixes).
The LSP server looks at the provided range and is expected to return the relevant
quickfixes here.
This flow is really annoying from a LSP server writer point of view. When you do the diagnostics
(in step 1), you tend to already know what the possible quickfixes would be. The LSP spec
authors realized this at some point, so there are two features the editor provides to simplify
this.
In the editor request for code actions, the editor is expected to provide the diagnostics
that they received from the server. Side note: I cannot quite tell if this is optional or
required from the spec.
The editor can provide support for remembering a data member in each diagnostic. The
server can then store arbitrary information in that member, which they will see again in
the code actions request. Again, provided that the editor supports this optional feature.
All the quickfix logic in debputy so far has hinged on both of these two features.
As life would have it, kate provides neither of them.
Which meant I had to teach debputy to keep track of its diagnostics on its own. The plus side
is that makes it easier to support "pull diagnostics" down the line, since it requires a similar
feature. Additionally, it also means that quickfixes are now available in more editors. For
consistency, debputy logic is now always used rather than relying on the editor support
when present.
The downside is that I had to spend hours coming up with and debugging a way to find the
diagnostics that overlap with the range provided by the editor. The most difficult part was keeping
the logic straight and getting the runes correct for it.
Making the quickfixes actually work
With all of that, kate would show the quickfixes for diagnostics from debputy and you could
use them too. However, they would always apply twice with suboptimal outcome as a result.
The LSP spec has multiple ways of defining what need to be changed in response to activating a
code action. In debputy, all edits are currently done via the WorkspaceEdit type. It
has two ways of defining the changes. Either via changes or documentChanges with
documentChanges being the preferred one if both parties support this.
I originally read that as I was allowed to provide both and the editor would pick the one it
preferred. However, after seeing kate blindly use both when they are present, I reviewed
the spec and it does say "The edit should either provide changes or documentChanges",
so I think that one is on me.
None of the changes in debputy currently require documentChanges, so I went with just
using changes for now despite it not being preferred. I cannot figure
out the logic of whether an editor supports documentChanges. As I read the notes for this
part of the spec, my understanding is that kate does not announce its support for
documentChanges but it clearly uses them when present. Therefore, I decided to keep it
simple for now until I have time to dig deeper.
Remaining limitations with kate
There is one remaining limitation with kate that I have not yet solved. The kate
program uses KSyntaxHighlighting for its language detection, which in turn is the
basis for which LSP server is assigned to a given document.
This engine does not seem to support as complex detection logic as I hoped from it. Concretely,
it either works on matching on an extension / a basename (same field for both cases) or
mime type. This combined with our habit in Debian to use extension less files like
debian/control vs. debian/tests/control or debian/rules or
debian/upstream/metadata makes things awkward a best.
Concretely, the syntax engine cannot tell debian/control from debian/tests/control as
they use the same basename. Fortunately, the syntax is close enough to work for both and
debputy is set to use filename based lookups, so this case works well enough.
However, for debian/rules and debian/upstream/metadata, my understanding is that if
I assign these in the syntax engine as Debian files, these rules will also trigger for any
file named foo.rules or bar.metadata. That seems a bit too broad for me, so I have
opted out of that for now. The down side is that these files will not work out of the box
with kate for now.
The current LSP configuration in kate does not recognize makefiles or YAML either. Ideally,
we would assign custom languages for the affected Debian files, so we do not steal the ID
from other language servers. Notably, kate has a built-in language server for YAML and
debputy does nothing for a generic YAML document. However, adding YAML as a supported
language for debputy would cause conflict and regressions for users that are already
happy with their generic YAML language server from kate.
So there are certainly still work to be done. If you are good with KSyntaxHighlighting
and know how to solve some of this, I hope you will help me out.
Changes unrelated to kate
While I was working on debputy, I also added some other features that I want to mention.
The debputy lint command will now show related context to diagnostic in its terminal
report when such information is available and is from the same file as the diagnostic
itself (cross file cases are rendered without related information).
The related information is typically used to highlight a source of a conflict. As an
example, if you use the same field twice in a stanza of debian/control, then
debputy will add a diagnostic to the second occurrence. The related information
for that diagnostic would provide the position of the first occurrence.
This should make it easier to find the source of the conflict in the cases where
debputy provides it. Let me know if you are missing it for certain diagnostics.
The diagnostics analysis of debian/control will now identify and flag simple
duplicated relations (complex ones like OR relations are ignored for now). Thanks
to Matthias Geiger for suggesting the feature and Otto Kek l inen for reporting
a false positive that is now fixed.
Closing
I am glad I tested with kate to weed out most of these issues in time before
the freeze. The Debian freeze will start within a week from now. Since debputy
is a part of the toolchain packages it will be frozen from there except for
important bug fixes.
This year I was at FOSDEM 2025, and it was the fifth edition in a row that I participated in person (before it was in 2019, 2020, 2023 and 2024). The event took place on February 1st and 2nd, as always at the ULB campus in Brussels.
We arrived on Friday at lunchtime and went straight to the hotel to drop off our bags. This time we stayed at Ibis in the city center, very close to the hustle and bustle. The price was good and the location was really good for us to be able to go out in the city center and come back late at night. We found a Japanese restaurant near the hotel and it was definitely worth having lunch there because of the all-you-can-eat price. After taking a nap, we went out for a walk. Since January 31st is the last day of the winter sales in the city, the streets in the city center were crowded, there were lots of people in the stores, and the prices were discounted. We concluded that if we have the opportunity to go to Brussels again at this time, it would be better wait to buy clothes for cold weather there.
Unlike in 2023 and 2024, the FOSDEM organization did not approve my request for the Translations DevRoom,so my goal was to participate in the event and collaborate at the Debian booth. And also as I always do, I volunteered to operate the broadcast camera in the main auditorium on both days, for two hours each.
The Debian booth:
Me in the auditorium helping with the broadcast:
2 weeks before the event, the organization put out a call for interested people to request a room for their community s BoF (Birds of a Feather), and I requested a room for Debian and it was approved :-)
It was great to see that people were really interested in participating at the BoF and the room was packed! As the host of the discussions, I tried to leave the space open for anyone who wanted to talk about any subject related to Debian. We started with a talk from MiniDebConf25 organizers, that will be taking place this year in France. Then other topics followed with people talking, asking and answering questions, etc. It was worth organizing this BoF. Who knows, the idea will remain in 2026.
Carlos (a.k.a Charles), Athos, Ma ra and Melissa talked at Fosdem, and Kanashiro was one for organizers of Distributions DevRoom
During the two days of the event, it didn t rain or get too cold. The days were sunny (and people celebrated the weather in Brussels). But I have to admit that it would have been nice to see snow like I did in 2019. Unlike last year, this time I felt more motivated to stay at the event the whole time.
Deixo meu agradecimento especial para o Andreas Tille, atual L der do Debian que aprovou o meu pedido de passagens para que eu pudesse participar dos FOSDEM 2025. Como sempre, essa ajuda foi essencial para viabilizar a minha viagem para Bruxelas.
I would like to give my special thanks to Andreas Tille, the current Debian Leader, who approved my request for flight tickets so that I could join FOSDEM 2025. As always, this help was essential in making my trip to Brussels possible.
And once again Jandira was with me on this adventure. On Monday we went for a walk around Brussels and we also traveled to visit Bruges again. The visit to this city is really worth it because walking through the historic streets is like going back in time. This time we even took a boat trip through the canals, which was really cool.
Meta
In case you haven't noticed, I'm trying to post and one of the things
that entails is to just dump over the fence a bunch of draft notes. In
this specific case, I had a set of rough notes about NixOS and
particularly Nix, the package manager.
In this case, you can see the very birth of an article, what it looks
like before it becomes the questionable prose it is now, by looking at
the Git history of this file, particularly its birth. I have
a couple of those left, and it would be pretty easy to publish them as
is, but I feel I'd be doing others (and myself! I write for my own
documentation too after all) a disservice by not going the extra mile
on those.
So here's the long version of my experiment with Nix.
Nix
A couple friends are real fans of Nix. Just like I work with Puppet a
lot, they deploy and maintain servers (if not fleets of servers)
with NixOS and its declarative package management system. Essentially,
they use it as a configuration management system, which is pretty
awesome.
That, however, is a bit too high of a bar for me. I rarely try new
operating systems these days: I'm a Debian developer and it takes most
of my time to keep that functional. I'm not going to go around messing
with other systems as I know that would inevitably get me dragged down
into contributing into yet another free software project. I'm mature
now and know where to draw the line. Right?
So I'm just testing Nix, the package manager, on Debian, because I
learned from my friend that nixpkgs is the largest package
repository out there, a mind-boggling 100,000 at the time of
writing (with 88% of packages up to date), compared to around
40,000 in Debian (or 72,000 if you count binary packages, with 72% up
to date). I naively thought Debian was the largest, perhaps competing
with Arch, and I was wrong: Arch is larger than Debian too.
What brought me there is I wanted to run Harper, a fast
spell-checker written in Rust. The logic behind using Nix instead of
just downloading the source and running it myself is that I delegate
the work of supply-chain integrity checking to a distributor, a bit
like you trust Debian developers like myself to package things in a
sane way. I know this widens the attack surface to a third party of
course, but the rationale is that I shift cryptographic verification
to another stack than just "TLS + GitHub" (although that is somewhat
still involved) that's linked with my current chain (Debian
packages).
I have since then stopped using Harper for various reasons and
also wrapped up my Nix experiment, but felt it worthwhile to jot down
some observations on the project.
Hot take
Overall, Nix is hard to get into, with a complicated learning curve. I
have found the documentation to be a bit confusing, since there are
many ways to do certain things. I particularly tripped on "flakes"
and, frankly, incomprehensible error reporting.
It didn't help that I tried to run nixpkgs on Debian which is
technically possible, but you can tell that I'm not supposed to be
doing this. My friend who reviewed this article expressed surprised at
how easy this was, but then he only saw the finished result, not me
tearing my hair out to make this actually work.
Nix on Debian primer
So here's how I got started. First I installed the nix binary package:
apt install nix-bin
Then I had to add myself to the right group and logout/log back in to
get the rights to deploy Nix packages:
adduser anarcat nix-users
That wasn't easy to find, but is mentioned in the README.Debian
file shipped with the Debian package.
Then, I didn't write this down, but the README.Debian file above
mentions it, so I think I added a "channel" like this:
At this point, harper was installed in a ... profile? Not sure.
I had to add ~/.nix-profile/bin (a symlink to
/nix/store/sympqw0zyybxqzz6fzhv03lyivqqrq92-harper-0.10.0/bin) to my
$PATH environment for this to actually work.
Side notes on documentation
Those last two commands (nix-channel and nix-env) were hard to
figure out, which is kind of amazing because you'd think a tutorial on
Nix would feature something like this prominently. But threedifferenttutorials failed to bring me up to that basic
setup, even the README.Debian didn't spell that out clearly.
The tutorials all show me how to develop packages for Nix, not
plainly how to install Nix software. This is presumably because "I'm
doing it wrong": you shouldn't just "install a package", you should
setup an environment declaratively and tell it what you want to do.
But here's the thing: I didn't want to "do the right thing". I just
wanted to install Harper, and documentation failed to bring me to that
basic "hello world" stage. Here's what one of the tutorials suggests
as a first step, for example:
curl -L https://nixos.org/nix/install sh
nix-shell --packages cowsay lolcat
nix-collect-garbage
... which, when you follow through, leaves you with almost precisely
nothing left installed (apart from Nix itself, setup with a nasty
"curl pipe bash". So while that works in testing Nix, you're not much
better off than when you started.
Rolling back everything
Now that I have stopped using Harper, I don't need Nix anymore, which
I'm sure my Nix friends will be sad to read about. Don't worry, I have
notes now, and can try again!
But still, I wanted to clear things out, so I did this, as root:
I think this cleared things out, but I'm not actually sure.
Side note on Nix drama
This blurb wouldn't be complete without a mention that the Nix
community has been somewhat tainted by the behavior of its founder. I
won't bother you too much with this; LWN covered it well in 2024,
and made a followup article about spinoffs and forks that's worth
reading as well.
I did want to say that everyone I have been in contact with in the Nix
community was absolutely fantastic. So I am really sad that the
behavior of a single individual can pollute a community in such a way.
As a leader, if you have all but one responsability, it's to behave
properly for people around you. It's actually really, really hard to
do that, because yes, it means you need to act differently than others
and no, you just don't get to be upset at others like you would
normally do with friends, because you're in a position of
authority.
It's a lesson I'm still learning myself, to be fair. But at least I
don't work with arms manufacturers or, if I would, I would be sure as
hell to accept the nick (or nix?) on the chin when people would get
upset, and try to make amends.
So long live the Nix people! I hope the community recovers from
that dark moment, so far it seems like it will.
And thanks for helping me test Harper!
I previously blogged about getting an 8K TV [1]. Now I m working on getting 8K video out for a computer that talks to it. I borrowed an NVidia RTX A2000 card which according to it s specs can do 8K [2] with a mini-DisplayPort to HDMI cable rated at 8K but on both Windows and Linux the two highest resolutions on offer are 3840*2160 (regular 4K) and 4096*2160 which is strange and not useful.
The various documents on the A2000 differ on whether it has DisplayPort version 1.4 or 1.4a. According to the DisplayPort Wikipedia page [3] both versions 1.4 and 1.4a have a maximum of HBR3 speed and the difference is what version of DSC (Display Stream Compression [4]) is in use. DSC apparently causes no noticeable loss of quality for movies or games but apparently can be bad for text. According to the DisplayPort Wikipedia page version 1.4 can do 8K uncompressed at 30Hz or 24Hz with high dynamic range. So this should be able to work.
My theories as to why it doesn t work are:
NVidia specs lie
My 8K cable isn t really an 8K cable
Something weird happens converting DisplayPort to HDMI
The video card can only handle refresh rates for 8K that don t match supported input for the TV
To get some more input on this issue I posted on Lemmy, here is the Lemmy post [5]. I signed up to lemmy.ml because it was the first one I found that seemed reasonable and was giving away free accounts, I haven t tried any others and can t review it but it seems to work well enough and it s free. It s described as A community of privacy and FOSS enthusiasts, run by Lemmy s developers which is positive, I recommend that everyone who s into FOSS create an account there or some other Lemmy server.
My Lemmy post was about what video cards to buy. I was looking at the Gigabyte RX 6400 Eagle 4G as a cheap card from a local store that does 8K, it also does DisplayPort 1.4 so might have the same issues, also apparently FOSS drivers don t support 8K on HDMI because the people who manage HDMI specs are jerks. It s a $200 card at MSY and a bit less on ebay so it s an amount I can afford to risk on a product that might not do what I want, but it seems to have a high probability of getting the same result. The NVidia cards have the option of proprietary drivers which allow using HDMI and there are cards with DisplayPort 1.4 (which can do 8K@30Hz) and HDMI 2.1 (which can do 8K@50Hz). So HDMI is a better option for some cards just based on card output and has the additional benefit of not needing DisplayPort to HDMI conversion.
The best option apparently is the Intel cards which do DisplayPort internally and convert to HDMI in hardware which avoids the issue of FOSS drivers for HDMI at 8K. The Intel Arc B580 has nice specs [6], HDMI 2.1a and DisplayPort 2.1 output, 12G of RAM, and being faster than the low end cards like the RX 6400. But the local computer store price is $470 and the ebay price is a bit over $400. If it turns out to not do what I need it still will be a long way from the worst way I ve wasted money on computer gear. But I m still hesitating about this.
Any suggestions?
Welcome to the second report in 2025 from the Reproducible Builds project. Our monthly reports outline what we ve been up to over the past month, and highlight items of news from elsewhere in the increasingly-important area of software supply-chain security. As usual, however, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website.
Table of contents:
Reproducible Builds at FOSDEM 2025
Similar to last year s event, there was considerable activity regarding Reproducible Builds at FOSDEM 2025, held on on 1st and 2nd February this year in Brussels, Belgium. We count at least four talks related to reproducible builds. (You can also read our news report from last year s event in which Holger Levsen presented in the main track.)
Jelle van der Waa, Holger Levsen and kpcyrd presented in the Distributions track on A Tale of several distros joining forces for a common goal. In this talk, three developers from two different Linux distributions (Arch Linux and Debian), discuss this goal which is, of course, reproducible builds. The presenters discuss both what is shared and different between the two efforts, touching on the history and future challenges alike. The slides of this talk are available to view, as is the full video (30m02s). The talk was also discussed on Hacker News.
Zbigniew J drzejewski-Szmek presented in the ever-popular Python track a on Rewriting .pyc files for fun and reproducibility, i.e. the bytecode files generated by Python in order to speed up module imports: It s been known for a while that those are not reproducible: on different architectures, the bytecode for exactly the same sources ends up slightly different. The slides of this talk are available, as is the full video (28m32s).
In the Nix and NixOS track, Julien Malka presented on the Saturday asking How reproducible is NixOS: We know that the NixOS ISO image is very close to be perfectly reproducible thanks to reproducible.nixos.org, but there doesn t exist any monitoring of Nixpkgs as a whole. In this talk I ll present the findings of a project that evaluated the reproducibility of Nixpkgs as a whole by mass rebuilding packages from revisions between 2017 and 2023 and comparing the results with the NixOS cache. Unfortunately, no video of the talk is available, but there is a blog and article on the results.
Lastly, Simon Tournier presented in the Open Research track on the confluence of GNU Guix and Software Heritage: Source Code Archiving to the Rescue of Reproducible Deployment. Simon s talk describes design and implementation we came up and reports on the archival coverage for package source code with data collected over five years. It opens to some remaining challenges toward a better open and reproducible research. The slides for the talk are available, as is the full video (23m17s).
Reproducible Builds at PyCascades 2025
Vagrant Cascadian presented at this year s PyCascades conference which was held on February 8th and 9th February in Portland, OR, USA. PyCascades is a regional instance of PyCon held in the Pacific Northwest. Vagrant s talk, entitled Re-Py-Ducible Builds caught the audience s attention with the following abstract:
Crank your Python best practices up to 11 with Reproducible Builds! This talk will explore Reproducible Builds by highlighting issues identified in Python projects, from the simple to the seemingly inscrutable. Reproducible Builds is basically the crazy idea that when you build something, and you build it again, you get the exact same thing or even more important, if someone else builds it, they get the exact same thing too.
reproduce.debian.net updates
The last few months have seen the introduction of reproduce.debian.net. Announced first at the recent Debian MiniDebConf in Toulouse, reproduce.debian.net is an instance of rebuilderd operated by the Reproducible Builds project.
Powering this work is rebuilderd, our server which monitors the official package repositories of Linux distributions and attempt to reproduce the observed results there. This month, however, Holger Levsen:
Split packages that are not specific to any architecture away from amd64.reproducible.debian.net service into a new all.reproducible.debian.net page.
Increased the number of riscv64 nodes to a total of 4, and added a new amd64 node added thanks to our (now 10-year sponsor), IONOS.
Uploaded the devscripts package, incorporating changes from Jochen Sprickerhof to the debrebuild script specifically to fix the handling the Rules-Requires-Root header in Debian source packages.
Uploaded a number of Rust dependencies of rebuilderd (rust-libbz2-rs-sys, rust-actix-web, rust-actix-server, rust-actix-http, rust-actix-server, rust-actix-http, rust-actix-web-codegen and rust-time-tz) after they were prepared by kpcyrd :
Jochen Sprickerhof also updated the sbuild package to:
Obey requests from the user/developer for a different temporary directory.
Use the root/superuser for some values of Rules-Requires-Root.
Don t pass --root-owner-group to old versions of dpkg.
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:
go (clear GOROOT for func ldShared when -trimpath is used)
Distribution work
There as been the usual work in various distributions this month, such as:
In Debian, 17 reviews of Debian packages were added, 6 were updated and 8 were removed this month adding to our knowledge about identified issues.
Fedora developers Davide Cavalca and Zbigniew J drzejewski-Szmek gave a talk on Reproducible Builds in Fedora (PDF), touching on SRPM-specific issues as well as the current status and future plans.
Thanks to an investment from the Sovereign Tech Agency, the FreeBSD project s work on unprivileged and reproducible builds continued this month. Notable fixes include:
The Yocto Project has been struggling to upgrade to the latest Go and Rust releases due to reproducibility problems in the newer versions. Hongxu Jia tracked down the issue with Go which meant that the project could upgrade from the 1.22 series to 1.24, with the fix being submitted upstream for review (see above). For Rust, however, the project was significantly behind, but has made recent progress after finally identifying the blocking reproducibility issues. At time of writing, the project is at Rust version 1.82, with patches under review for 1.83 and 1.84 and fixes being discussed with the Rust developers. The project hopes to improve the tests for reproducibility in the Rust project itself in order to try and avoid future regressions.
Yocto continues to maintain its ability to binary reproduce all of the recipes in OpenEmbedded-Core, regardless of the build host distribution or the current build path.
Finally, Douglas DeMaio published an article on the openSUSE blog on announcing that the Reproducible-openSUSE (RBOS) Project Hits [Significant] Milestone. In particular:
The Reproducible-openSUSE (RBOS) project, which is a proof-of-concept fork of openSUSE, has reached a significant milestone after demonstrating a usable Linux distribution can be built with 100% bit-identical packages.
diffoscope & strip-nondeterminismdiffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 288 and 289 to Debian:
Add asar to DIFFOSCOPE_FAIL_TESTS_ON_MISSING_TOOLS in order to address Debian bug #1095057) []
Catch a CalledProcessError when calling html2text. []
Additionally, Vagrant Cascadian updated diffoscope in GNU Guix to version 287 [][] and 288 [][] as well as submitted a patch to update to 289 []. Vagrant also fixed an issue that was breaking reprotest on Guix [][].
strip-nondeterminism is our sister tool to remove specific non-deterministic results from a completed build. This month version 1.14.1-2 was uploaded to Debian unstable by Holger Levsen.
Website updates
There were a large number of improvements made to our website this month, including:
Holger Levsen clarified the name of a link to our old Wiki pages on the History page [] and added a number of new links to the Talks & Resources page [][].
James Addison update the website s own README file to document a couple of additional dependencies [][], as well as did more work on a future Getting Started guide page [][].
Reproducibility testing framework
The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In January, a number of changes were made by Holger Levsen, including:
Fix /etc/cron.d and /etc/logrotate.d permissions for Jenkins nodes. []
Add support for riscv64 architecture nodes. [][]
Grant Jochen Sprickerhof access to the o4 node. []
Disable the janitor-setup-worker. [][]
In addition:
kpcyrd fixed the /all/api/ API endpoints on reproduce.debian.net by altering the nginx configuration. []
James Addison updated reproduce.debian.net to display the so-called bad reasons hyperlink inline [] and merged the Categorized issues links into the Reproduced builds column [].
Jochen Sprickerhof also made some reproduce.debian.net-related changes, adding support for detecting a bug in the mmdebstrap package [] as well as updating some documentation [].
Roland Clobus continued their work on reproducible live images for Debian, making changes related to new clustering of jobs in openQA. []
And finally, both Holger Levsen [][][] and Vagrant Cascadian performed significant node maintenance. [][][][][]
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:
Welcome to post 46 in the $R^4 series!
r2u, introduced less
than three years ago in post
#37, has become a runaway success. When I last tabulated downloads
in early January, we were already at 33 million downloads of binary CRAN packages across the three
Ubuntu LTS releases we support. These were exclusively for the amd64
platform of standard (Intel or AMD made) x64_64 cpus. Now we are happy
to announce that arm64 support has been added and is available!
Why arm64?
The arm64 platform is already popular on (cloud) servers and is being
pushed quite actively by the cloud vendors. AWS calls their cpu
graviton , GCS calls it axion . General servers call the cpu ampere ;
on laptop / desktops it is branded snapdragon or cortex or something
else. Apple calls their variant M1, M2, up to M4 by now (and Linux
support exists for the brave, it is less straightforward). What these
have in common is a generally more favourable power consumed to ops
provided ratio. That makes these cheaper to run or rent on cloud
providers. And in laptops they tend to last longer on a single charge
too.
Distributions such as Debian, Ubuntu, Fedora had arm64 for many
years. In fact, the CRAN
binaries of R, being made as builds at launchpad.net long provided arm64 in
Michael s repo, we now also mirror these to CRAN. Similarly, Docker has long
supported containers. And last but not least two issue tickets (#40, #55) had asked
a while back.
So Why Now?
Good question. I still do not own any hardware with it, and I have
not (yet?) bothered with the qemu-based emulation layer. The real
difference maker was the recent availability of GitHub Actions instances
of ubuntu-24.04-arm (and now apparently also for 22.04).
So I started some simple experiments which made it clear this was
viable.
What Does It Mean for a CRAN
Repo?
Great question. As is commonly known, of the (currently) 22.1k CRAN
packages, a little under 5k are compiled . Why does this matter?
Because the Linux distributions know what they are doing. The 17k (give
or take) packages that do not contain compiled code can be used as is
(!!) on another platform. Debian and Ubuntu call these builds binary:
all as they work all platforms as is . The others go by binary: any
and will work on any platform for which they have been built. So we
are looking at roughly 5k new binaries.
So How Many Are There?
As I write this in early March, roughly 4.5k of the 5k. Plus the
17.1k binary: all and we are looking at near complete coverage!
So What Is The Current State?
Pretty complete. Compare to the amd64 side of things, we do not (yet
?) have BioConductor support; this may be added. A handful of packages
do not compile because their builds seem to assume Linux so must be
amd64 and fail over cpu instructions. Similarly, a few packages want to
download binary build blobs (my own Rblpapi among them) but
none exist for arm64. Such is life. We will try to fix builds as time
permits and report build issues to the respective upstream repos. Help
in that endeavour would be most welcome.
But all the big and slow compiles one may care about (hello
duckdb, hello arrow, ) are there. Which is
pretty exciting!
How Does One Get Started?
In GitHub Actions, just pick ubuntu-24.04-arm as the
platform, and use the r-ci or r2u-setup
actiions. A first test yaml exists
worked (though this last version had the arm64 runner commented out
again). (And no, arm64 was not faster than amd64. More tests
needed.)
For simple tests, Docker. The rocker/r-ubuntu:24.04
container exists for arm64 (see here), and one
can add r2u support as is done in
this Dockerfile which is used by the builds and available as
eddelbuettel/r2u_build:noble. I will add the standard
rocker/r2u:24.04 container (or equally
rocker/r2u:noble) in a day or two, I had not realised I
wasn t making them for arm64.
One a real machine such as a cloud instance or a proper instance,
just use the standard r2u script for noble aka 24.04
available here.
The key lines are the two lines
creating the apt entry and which are now arm64-aware.
After that, apt works as usual, and of course r2u works as
usual thanks also to bspm so you can just do, say
and enjoy the binaries rolling in. So give it a whirl if you have
access to such hardware. We look forward to feedback, suggestes, feature
requests or bug reports. Let us know how it goes!
In today s digital landscape, social media is more than just a communication tool it is the primary medium for global discourse. Heads of state, corporate leaders and cultural influencers now broadcast their statements directly to the world, shaping public opinion in real time. However, the dominance of a few centralized platforms X/Twitter, Facebook and YouTube raises critical concerns about control, censorship and the monopolization of information. Those who control these networks effectively wield significant power over public discourse.
In response, a new wave of distributed social media platforms has emerged, each built on different decentralized protocols designed to provide greater autonomy, censorship resistance and user control. While Wikipedia maintains a comprehensive list of distributed social networking software and protocols, it does not cover recent blockchain-based systems, nor does it highlight which have the most potential for mainstream adoption.
This post explores the leading decentralized social media platforms and the protocols they are based on: Mastodon (ActivityPub), Bluesky (AT Protocol), Warpcast (Farcaster), Hey (Lens) and Primal (Nostr).
Comparison of architecture and mainstream adoption potential
1. Mastodon (ActivityPub)
Mastodon was created in 2016 by Eugen Rochko, a German software developer who sought to provide a decentralized and user-controlled alternative to Twitter. It was built on the ActivityPub protocol, now standardized by W3C Social Web Working Group, to allow users to join independent servers while still communicating across the broader Mastodon network.
Mastodon operates on a federated model, where multiple independently run servers communicate via ActivityPub. Each server sets its own moderation policies, leading to a decentralized but fragmented experience. The servers can alternatively be called instances, relays or nodes, depending on what vocabulary a protocol has standardized on.
Identity: User identity is tied to the instance where they registered, represented as @username@instance.tld.
Storage: Data is stored on individual instances, which federate messages to other instances based on their configurations.
Cost: Free to use, but relies on instance operators willing to run the servers.
Servers communicate across different platforms by publishing activities to their followers or forwarding activities between servers. Standard HTTPS is used between servers for communication, and the messages use JSON-LD for data representation. The WebFinger protocol is used for user discovery. There is however no neat way for home server discovery yet. This means that if you are browsing e.g. Fosstodon and want to follow a user and press Follow, a dialog will pop up asking you to enter your own home server (e.g. mastodon.social) to redirect you there for actually executing the Follow action on with your account.
Mastodon is open source under the AGPL at github.com/mastodon/mastodon. Anyone can operate their own instance. It just requires to run your own server and some skills to maintain a Ruby on Rails app with a PostgreSQL database backend, and basic understanding of the protocol to configure federation with other ActivityPub instances.
Popularity: Already established, but will it grow more?
Mastodon has seen steady growth, especially after Twitter s acquisition in 2022, with some estimates stating it peaked at 10 million users across thousands of instances. However, its fragmented user experience and the complexity of choosing instances have hindered mainstream adoption. Still, it remains the most established decentralized alternative to Twitter.
Note that Donald Trump s Truth Social is based on the Mastodon software but does not federate with the ActivityPub network.
The ActivityPub protocol is the most widely used of its kind. One of the other most popular services is the Lemmy link sharing service, similar to Reddit. The larger ecosystem of ActivityPub is called Fediverse, and estimates put the total active user count around 6 million.
2. Bluesky (AT Protocol)
Interestingly, Bluesky was conceived within Twitter in 2019 by Twitter founder Jack Dorsey. After being incubated as a Twitter-funded project, it spun off as an independent Public Benefit LLC in February 2022 and launched its public beta in February 2023.
Bluesky runs on top of the Authenticated Transfer (AT) Protocol published at https://github.com/bluesky-social/atproto. The protocol enables portable identities and data ownership, meaning users can migrate between platforms while keeping their identity and content intact. In practice, however, there is only one popular server at the moment, which is Bluesky itself.
Identity: Usernames are domain-based (e.g., @user.bsky.social).
Storage: Content is theoretically federated among various servers.
Cost: Free to use, but relies on instance operators willing to run the servers.
Popularity: Hybrid approach may have business benefits?
Bluesky reported over 3 million users by 2024, probably getting traction due to its Twitter-like interface and Jack Dorsey s involvement. Its hybrid approach decentralized identity with centralized components could make it a strong candidate for mainstream adoption, assuming it can scale effectively.
3. Warpcast (Farcaster Network)
Farcaster was launched in 2021 by Dan Romero and Varun Srinivasan, both former crypto exchange Coinbase executives, to create a decentralized but user-friendly social network. Built on the Ethereum blockchain, it could potentially offer a very attack-resistant communication medium.
However, in my own testing, Farcaster does not seem to fully leverage what Ethereum could offer. First of all, there is no diversity in programs implementing the protocol as at the moment there is only Warpcast. In Warpcast the signup requires an initial 5 USD fee that is not payable in ETH, and users need to create a new wallet address on the Ethereum layer 2 network Base instead of simply reusing their existing Ethereum wallet address or ENS name.
Despite this, I can understand why Farcaster may have decided to start out like this. Having a single client program may be the best strategy initially. One of the decentralized chat protocol Matrix founders, Matthew Hodgson, shared in his FOSDEM 2025 talk that he slightly regrets focusing too much on developing the protocol instead of making sure the app to use it is attractive to end users. So it may be sensible to ensure Warpcast gets popular first, before attempting to make the Farcaster protocol widely used.
As a protocol Farcaster s hybrid approach makes it more scalable than fully on-chain networks, giving it a higher chance of mainstream adoption if it integrates seamlessly with broader Web3 ecosystems.
Identity: ENS (Ethereum Name Service) domains are used as usernames.
Storage: Messages are stored in off-chain hubs, while identity is on-chain.
Cost: Users must pay gas fees for some operations but reading and posting messages is mostly free.
Popularity: Decentralized social media + decentralized payments a winning combo?
Ethereum founder Vitalik Buterin (warpcast.com/vbuterin) and many core developers are active on the platform. Warpcast, the main client for Farcaster, has seen increasing adoption, especially among Ethereum developers and Web3 enthusiasts. I too have an profile at warpcast.com/ottok. However, the numbers are still very low and far from reaching network effects to really take off.
Blockchain-based social media networks, particularly those built on Ethereum, are compelling because they leverage existing user wallets and persistent identities while enabling native payment functionality. When combined with decentralized content funding through micropayments, these blockchain-backed social networks could offer unique advantages that centralized platforms may find difficult to replicate, being decentralized both as a technical network and in a funding mechanism.
4. Hey.xyz (Lens Network)
The Lens Protocol was developed by decentralized finance (DeFi) team Aave and launched in May 2022 to provide a user-owned social media network. While initially built on Polygon, it has since launched its own Layer 2 network called the Lens Network in February 2024. Lens is currently the main competitor to Farcaster.
Lens stores profile ownership and references on-chain, while content is stored on IPFS/Arweave, enabling composability with DeFi and NFTs.
Identity: Profile ownership is tied to NFTs on the Polygon blockchain.
Storage: Content is on-chain and integrates with IPFS/Arweave (like NFTs).
Cost: Users must pay gas fees for some operations but reading and posting messages is mostly free.
Popularity: Probably not as social media site, but maybe as protocol?
The social media side of Lens is mainly the Hey.xyz website, which seems to have fewer users than Warpcast, and is even further away from reaching critical mass for network effects. The Lens protocol however has a lot of advanced features and it may gain adoption as the building block for many Web3 apps.
5. Primal.net (Nostr Network)
Nostr (Notes and Other Stuff Transmitted by Relays) was conceptualized in 2020 by an anonymous developer known as fiatjaf. One of the primary design tenets was to be a censorship-resistant protocol and it is popular among Bitcoin enthusiasts, with Jack Dorsey being one of the public supporters. Unlike the Farcaster and Lens protocols, Nostr is not blockchain-based but just a network of relay servers for message distribution. If does however use public key cryptography for identities, similar to how wallets work in crypto.
Popularity: If Jack Dorsey and Bitcoiners promote it enough?
Primal.net as a web app is pretty solid, but it does not stand out much. While Jack Dorsey has shown support by donating $1.5 million to the protocol development in December 2021, its success likely depends on broader adoption by the Bitcoin community.
Will any of these replace X/Twitter?
As usage patterns vary, the statistics are not fully comparable, but this overview of the situation in March 2025 gives a decent overview.
Mastodon and Bluesky have already reached millions of users, while Lens and Farcaster are growing within crypto communities. It is however clear that none of these are anywhere close to how popular X/Twitter is. In particular, Mastodon had a huge influx of users in the fall of 2022 when Twitter was acquired, but to challenge the incumbents the growth would need to significantly accelerate. We can all accelerate this development by embracing decentralized social media now alongside existing dominant platforms.
Who knows, given the right circumstances maybe X.com leadership decides to change the operating model and start federating contents to break out from a walled garden model. The likelyhood of such development would increase if decentralized networks get popular, and the encumbents feel they need to participate to not lose out.
Past and future
The idea of decentralized social media is not new. One early pioneer identi.ca launched in 2008, only two years after Twitter, using the OStatus protocol to promote decentralization. A few years later it evolved into pump.io with the ActivityPump protocol, and also forked into GNU Social that continued with OStatus. I remember when these happened, and that in 2010 also Diaspora launched with fairly large publicity. Surprisingly both of these still operate (I can still post both on identi.ca and diasp.org), but the activity fizzled out years ago. The protocol however survived partially and evolved into ActivityPub, which is now the backbone of the Fediverse.
The evolution of decentralized social media over the next decade will likely parallel developments in democracy, freedom of speech and public discourse. While the early 2010s emphasized maximum independence and freedom, the late 2010s saw growing support for content moderation to combat misinformation. The AI era introduces new challenges, potentially requiring proof-of-humanity verification for content authenticity.
Key factors that will determine success:
User experience and ease of onboarding
Network effects and critical mass of users
Integration with existing web3 infrastructure
Balance between decentralization and usability
Sustainable economic models for infrastructure
This is clearly an area of development worth monitoring closely, as the next few years may determine which protocol becomes the de facto standard for decentralized social communication.
[I d like to stop writing posts like this. I ve been trying to work out what to say now for nearly 2 months (writing the mail to -private to tell the Debian project about his death is one of the hardest things I ve had to write, and I bottled out and wrote something that was mostly just factual, because it wasn t the place), and I ve decided I just have to accept this won t be the post I want it to be, but posted is better than languishing in drafts.]
Last weekend I was in Portland, for the Celebration of Life of my friend Steve, who sadly passed away at the start of the year. It wasn t entirely unexpected, but that doesn t make it any easier.
I ve struggled to work out what to say about Steve. I ve seen many touching comments from others in Debian about their work with him, but what that s mostly brought home to me is that while I met Steve through Debian, he was first and foremost my friend rather than someone I worked with in Debian. And so everything I have to say is more about that friendship (and thus feels a bit self-centred).
My first memory of Steve is getting lost with him in Porto Alegre, Brazil, during DebConf4. We d decided to walk to a local mall to meet up with some other folk (I can t recall how they were getting there, but it wasn t walking), ended up deep in conversation (ISTR it was about shared library transititions), and then it took a bit longer than we expected. I don t know how that managed to cement a friendship (neither of us saw it as the near death experience others feared we d had), but it did.
Unlike others I never texted Steve much; we d occasionally chat on IRC, but nothing major. That didn t seem to matter when we actually saw each other in person though, we just picked up like we d seen each other the previous week. DebConf became a recurring theme of when we d see each other. Even outside DebConf we went places together. The first time I went somewhere in the US that wasn t the Bay Area, it was to Portland to see Steve. He, and his family, came to visit me in Belfast a couple of times, and I did road trip from Dublin to Cork with him. He took me to a volcano.
Steve saw injustice in the world and actually tried to do something about it. I still have a copy of the US constitution sitting on my desk that he gave me. He made me want to be a better person.
The world is a worse place without him in it, and while I am better for having known him, I am sadder for the fact he s gone.
Most of my Debian contributions this month were
sponsored by Freexian.
You can also support my work directly via
Liberapay.
OpenSSH
OpenSSH upstream released
9.9p2 with fixes for
CVE-2025-26465 and CVE-2025-26466. I got a heads-up on this in advance from
the Debian security team, and prepared updates for all of testing/unstable,
bookworm (Debian 12), bullseye (Debian 11), buster (Debian 10, LTS), and
stretch (Debian 9, ELTS). jessie (Debian 8) is also still in ELTS for a few
more months, but wasn t affected by either vulnerability.
Although I m not particularly active in the Perl team, I fixed a
libnet-ssleay-perl build failure because
it was blocking openssl from migrating to testing, which in turn was
blocking the above openssh fixes.
I also sent a minor sshd -T
fix upstream, simplified
a number of autopkgtests using the newish Restrictions:
needs-sudo facility, and prepared for
removing the obsolete slogin symlink.
PuTTY
I upgraded to the new upstream version
0.83.
GCC 15 build failures
I fixed build failures with GCC
15 in a few packages:
Python team
A lot of my Python team work is driven by its maintainer
dashboard.
Now that we ve finished the transition to Python 3.13 as the default
version, and inspired by a recent debian-devel thread started by
Santiago, I
thought it might be worth spending a bit of time on the uscan error
section. uscan is typically
scraping upstream web sites to figure out whether new versions are
available, and so it s easy for its configuration to become outdated or
broken. Most of this work is pretty boring, but it can often reveal
situations where we didn t even realize that a Debian package was out of
date. I fixed these packages:
cssutils (this in particular was very out of date due to a new and active
upstream maintainer since 2021)
In bookworm-backports, I updated python-django to 3:4.2.18-1 (issuing
BSA-121)
and added new backports of python-django-dynamic-fixture and
python-django-pgtrigger, all of which are dependencies of
debusine.
I went through all the build failures related to python-click 8.2.0 (which
was confusingly tagged but not fully released
upstream and posted an
analysis.
I fixed or helped to fix various other build/test failures:
by por Andrew Gon alves
Debian Day in Santa Maria - RS 2024 was held after a 5-year hiatus from the previous version of the event. It took
place on the morning of August 16, in the Blue Hall of the
Franciscan University (UFN) with support from the
Debian community and the Computing Practices Laboratory of UFN.
The event was attended by students from all semesters of the Computer Science,
Digital Games and Informational Systems, where we had the opportunity to talk to the participants.
Around 60 students attended a lecture introducing them to Free and Open Source
Software, Linux and were introduced to the Debian project, both about the
philosophy of the project and how it works in practice and the opportunities
that have opened up for participants by being part of Debian.
After the talk, a packaging demonstration was given by local DD Francisco
Vilmar, who demonstrated in practice how software packaging works in Debian.
I would like to thank all the people who helped us:
Debian Project
Professor Ana Paula Canal (UFN)
Professor Sylvio Andr Garcia (UFN)
Laboratory of Computing Practices
Francisco Vilmar (local DD)
And thanks to all the participants who attended this event asking intriguing
questions and taking an interest in the world of Free Software.
Photos:
by Thiago Pezzo and
Giovani Ferreira
Local celebrations of Debian 2024 Day
also happened on [Pouso Alegre, MG, Brazil] (https://www.openstreetmap.org/relation/315431). In this year we managed to organize two days of lectures!
On the 14th of August 2024, Wednesday morning, we were on the
[Federal Institute of Education, Science and Technology of the South of Minas Gerais] (https://portal.ifsuldeminas.edu.br/index.php), (IFSULDEMINAS), Pouso Alegre campus. We did an introductory presentation of the
Project Debian, operating system and community, for
the three years of the Technical Course in Informatics (professional high school). The event was closed to IFSULDEMINAS students and talked to 60 people.
On August 17th, 2024, a Saturday morning, we held the event open to the
community at the University of the Sapuca Valley (Univ s), with institutional support of the Information Systems Course. We speak about the Debian Project with Giovani Ferreira (Debian Developer); about the Debian pt_BR translation team with Thiago Pezzo; about everyday experiences using free software with Virginia
Cardoso; and on how to set up a development environment ready for production
using Debian and Docker with Marcos Ant nio dos Santos. After the lectures,
snacks, coffee and cake were served, while the participants talked, asked
questions and shared experiences.
We would like to thank all the people who have helped us:
Michelle Nery (IFSULDEMINAS) and Andr Martins (UNIV S) for the aid in the local organization - Paulo Santana (Debian Brazil) by the general organization
Virginia Cardoso, Giovani Ferreira, Marco Ant nio and Thiago Pezzo for the lectures - And a special thanks to all of you who participated in our celebratio
title: Debian Day 30 years online in Brazil
description: by Paulo Henrique de Lima Santana (phls)
published: true
date: 2025-03-01T17:39:03.284Z
tags: blog, english
editor: markdown
dateCreated: 2023-08-25T16:00:00.000Z
In 2023 the traditional Debian Day is
being celebrated in a special way, after all on August 16th Debian turned 30
years old!
To celebrate this special milestone in the Debian's life, the
Debian Brasil community organized a week with
talks online from August 14th to 18th. The event was named
Debian 30 years.
Two talks were held per night, from 7:00 pm to 10:00 pm, streamed on the
Debian Brasil channel on YouTube totaling 10 talks. The recordings are also available on the
Debian Brazil channel on Peertube.
We had the participation of 9 DDs, 1 DM, 3 contributors in 10 activities.
The live audience varied a lot, and the peak was on the preseed talk with
Eriberto Mota when we had 47 people watching.
Thank you to all participants for the contribution you made to the success of
our event.
Antonio Terceiro
Aquila Macedo
Charles Melara
Daniel Lenharo de Souza
David Polverari
Eriberto Mota
Giovani Ferreira
Jefferson Maier
Lucas Kanashiro
Paulo Henrique de Lima Santana
Sergio Durigan Junior
Thais Araujo
Thiago Andrade
Veja abaixo as fotos de cada atividade:
Nova gera o: uma entrevista com iniciantes no projeto Debian
Instala o personalizada e automatizada do Debian com preseed
Manipulando patches com git-buildpackage
debian.social: Socializando Debian do jeito Debian
Proxy reverso com WireGuard
Celebra o dos 30 anos do Debian!
Instalando o Debian em disco criptografado com LUKS
O que a equipe de localiza o j conquistou nesses 30 anos
Debian - Projeto e Comunidade!
Design Gr fico e Software livre, o que fazer e por onde come ar
Another short status update of what happened on my side last
month. One larger blocks are the Phosh 0.45 release, also reviews
took a considerable amount of time. From the fun side debugging bananui and coming up with a fix in
phoc as well as setting up a small GSM network using osmocom to test more Cell Broadcast thingies were likely the most fun parts.
phosh
I have been testing fish for a couple months now (this file started on
2025-01-03T23:52:15-0500 according to stat(1)), and those are my
notes. I suspect people will have Opinions about my comments here. Do
not comment unless you have some Constructive feedback to provide: I
don't want to know if you think I am holding it Wrong. Consider that I
might have used UNIX shells for longer that you have lived.
I'm not sure I'll keep using fish, but so far it's the first shell
that survived heavy use outside of zsh(1) (unless you count
tcsh(1), but that was in another millenia).
My normal shell is bash(1), and it's still the shell I used
everywhere else than my laptop, as I haven't switched on all the
servers I managed, although it is available since August 2022 on
torproject.org servers. I first got interested in fish because they
ported to Rust, making it one of the rare shells out there
written in a "safe" and modern programming language, released after an
impressive ~2 year of work with Fish 4.0.
Cool things
Current directory gets shortened,
~/wikis/anarc.at/software/desktop/wayland shows up as
~/w/a/s/d/wayland
Autocompletion rocks.
Default prompt rocks. Doesn't seem vulnerable to command injection
assaults, at least it doesn't trip on the git-landmine.
It even includes pipe status output, which was a huge pain to
implement in bash. Made me realized that if the last command succeeds,
we don't see other failures, which is the case of my current prompt
anyways! Signal reporting is better than my bash implementation too.
So far the only modification I have made to the prompt is to add a
printf '\a' to output a bell.
By default, fish keeps a directory history (but separate from the
pushd stack), that can be navigated with cdh, prevd, and
nextd, dirh shows the history.
Less cool
I feel there's visible latency in the prompt creation.
POSIX-style functions (foo() true ) are unsupported. Instead,
fish uses whitespace-sensitive definitions like this:
function foo
true
end
This means my (modest) collection of POSIX functions need to be ported
to fish. Workaround: simple functions can be turned into aliases,
which fish supports (but implements using functions).
EOF heredocs are considered to be "minor syntactic sugar". I find
them frigging useful.
Process substitution is split on newlines, not whitespace. you need to
pipe through string split -n " " to get the equivalent.
<(cmd) doesn't exist: they claim you can use cmd foo - as a
replacement, but that's not correct: I used <(cmd) mostly where
foo does not support - as a magic character to say 'read from
stdin'.
Documentation is... limited. It seems mostly geared the web docs
which are... okay (but I couldn't find out about
~/.config/fish/conf.d there!), but this is really inconvenient when
you're trying to browse the manual pages. For example, fish thinks
there's a fish_prompt manual page, according to its own completion
mechanism, but man(1) cannot find that manual page. I can't find the
manual for the time command (which is actually a keyword!)
Fish renders multi-line commands with newlines. So if your terminal
looks like this, say:
Note that this is an issue specific to foot(1), alacritty(1) and
gnome-terminal(1) don't suffer from that issue. I have already filed
it upstream in foot and it is apparently fixed already.
Globbing is driving me nuts. You can't pass a * to a command
unless fish agrees it's going to match something. You need to escape
it if it doesn't immediately match, and then you need the called
command to actually support globbing. 202[345] doesn't match
folders named 2023, 2024, 2025, it will send the string
202[345] to the command.
Blockers
() is like $(): it's process substitution, and not a
subshell. This is really impractical: I use ( cd foo ; do_something)
all the time to avoid losing the current directory... I guess I'm
supposed to use pushd for this, but ouch. This wouldn't be so bad if
it was just for cd though. Clean constructs like this:
... which fails and suggests using begin/end, at which point: why
not just support the curly braces?
FOO=bar is not allowed. It's actually recognized syntax, but creates
a warning. We're supposed to use set foo bar instead. This really
feels like a needless divergence from standard.
Aliases are... peculiar. Typical constructs like alias mv="\mv -i"
don't work because fish treats aliases as a function definition, and
\ is not magical there. This can be worked around by specifying the
full path to the command, with e.g. alias mv="/bin/mv -i". Another
problem is trying to override a built-in, which seems completely
impossible. In my case, I like the time(1) command the way it
is, thank you very much, and fish provides no way to bypass that
builtin. It is possible to call time(1) with command time, but
it's not possible to replace the command keyword so that means a lot
of typing.
Again: you can't use \ to bypass aliases. This is a huge annoyance
for me. I would need to learn to type command in long form, and I
use that stuff pretty regularly. I guess I could alias command to
c or something, but this is one of those huge muscle memory challenges.
alt . doesn't always work the way i expect.
A Little Vice is a stand-alone self-published
magical girl novel. It
is the author's first novel.
C is a high school student and frequent near-victim of monster attacks.
Due to the nefarious work of Avaritia Wolf and her allies, his high school
is constantly attacked by Beasts, who are magical corruptions of some
internal desire taken to absurd extremes. Standing in their way are the
Angelic Saints: magical girls who transform into Saint Castitas, Saint
Diligentia, and Saint Temperantia and fight the monsters. The monsters for
some reason seem disposed to pick C as their victim for hostage-taking,
mind control, use as a human shield, and other rather traumatic
activities. He's always rescued by the Saints before any great harm is
done, but in some ways this makes the situation worse.
It is obvious to C that the Saints are his three friends Inessa, Ida, and
Temperance, even though no one else seems able to figure this out despite
the blatant clues. Inessa has been his best friend since childhood when
she was awkward and needed his support. Now, she and his other friends
have become literal heroes, beautiful and powerful and capable, constantly
protecting the school and innocent people, and C is little more than a
helpless burden to be rescued. More than anything else, he wishes he could
be an Angelic Saint like them, but of course the whole idea is impossible.
Boys don't get to be magical girls.
(I'm using he/him pronouns for C in this review because C uses them for
himself for most of the book.)
This is a difficult book to review because it is deeply focused on
portraying a specific internal emotional battle in all of its
sometimes-ugly complexity, and to some extent it prioritizes that
portrayal over conventional story-telling. You have probably already
guessed that this is a transgender coming-out story Elkin's choice of
the magical girl genre was done with deep understanding of its role in
transgender narratives but more than that, it is a transgender
coming-out story of a very specific and closely-observed type. C knows who
he wishes he was, but he is certain that this transformation is absolutely
impossible. He is very deep in a cycle of self-loathing for wanting
something so manifestly absurd and insulting to people who have the
virtues that C does not.
A Little Vice is told in the first person from C's perspective, and
most of this book is a relentless observation of C's anxiety and shame
spiral and reflexive deflection of any possibility of a way out. This is
very well-written: Elkin knows the reader is going to disagree with C's
internalized disgust and hopelessness, knows the reader desperately wants
C to break out of that mindset, and clearly signals in a myriad of adroit
ways that Elkin is on the reader's side and does not agree with C's
analysis. C's friends are sympathetic, good-hearted people, and while
sometimes oblivious, it is obvious to the reader that they're also on the
reader's side and would help C in a heartbeat if they saw an opening. But
much of the point of the book is that it's not that easy, that breaking
out of the internal anxiety spiral is nearly impossible, and that C is
very good at rejecting help, both because he cannot imagine what form it
could take but also because he is certain that he does not deserve it.
In other words, much of the reading experience of this book involves
watching C torture and insult himself. It's all the more effective because
it isn't gratuitous. C's internal monologue sounds exactly like how an
anxiety spiral feels, complete with the sort of half-effective coping
mechanisms, deflections, and emotional suppression one develops to blunt
that type of emotional turmoil.
I normally hate this kind of book. I am a happy ending and competence porn
reader by default. The world is full of enough pain that I don't turn to
fiction to read about more pain. It says a lot about how well-constructed
this book is that I stuck with it. Elkin is going somewhere with the
story, C gets moments of joy and delight along the way to keep the reader
from bogging down completely, and the best parts of the book feel like a
prolonged musical crescendo with suspended chords. There is a
climax coming, but Elkin is going to make you wait for it for far longer
than you want to.
The main element that protects A Little Vice from being too grim is
that it is a genre novel that is very playful about both magical girls and
superhero tropes in general. I've already alluded to one of those
elements: Elkin plays with the Mask Principle (the inability of people to
see through entirely obvious secret identities) in knowing and
entertaining ways. But there are also villains, and that leads me to the
absolutely delightful Avaritia Wolf, who for me was the best character in
this book.
The Angelic Saints are not the only possible approach to magical girl
powers in this universe. There are villains who can perform a similar
transformation, except they embrace a vice rather than a virtue. Avaritia
Wolf embraces the vice of greed. They (Avaritia's pronouns change over the
course of the book) also have a secret identity, which I suspect will be
blindingly obvious to most readers but which I'll avoid mentioning since
it's still arguably a spoiler.
The primary plot arc of this book is an attempt to recruit C to the side
of the villains. The Beasts are drawn to him because he has magical
potential, and the villains are less picky about gender. This initially
involves some creepy and disturbing mind control, but it also brings C
into contact with Avaritia and Avaritia's very specific understanding of
greed. As far as Avaritia is concerned, greed means wanting whatever they
want, for whatever reason they feel like wanting it, and there is
absolutely no reason why that shouldn't include being greedy for their
friends to be happy. Or doing whatever they can to make their friends
happy, whether or not that looks like villainy.
Elkin does two things with this plot that I thought were remarkably
skillful. The first is that she directly examines and then undermines the
"easy" transgender magical girl ending. In a world of transformation
magic, someone who wants to be a girl could simply turn into a girl and
thus apparently resolve the conflict in a way that makes everyone happy. I
think there is an important place for that story (I am a vigorous defender
of escapist fantasy and happy endings), but that is not the story that
Elkin is telling. I won't go into the details of why and how the story
complicates and undermines this easy ending, but it's a lot of why this
book feels both painful and honest to a specific, and very not easy,
transgender experience, even though it takes place in an utterly
unrealistic world.
But the second, which is more happy and joyful, is that Avaritia gleefully
uses a wholehearted embrace of every implication of the vice of greed to
bulldoze the binary morality of the story and question the classification
of human emotions into virtues and vices. They are not a hero, or even all
that good; they have some serious flaws and a very anarchic attitude
towards society. But Avaritia provides the compelling, infectious thrill
of the character who looks at the social construction of morality that is
constraining the story and decides that it's all bullshit and refuses to
comply. This is almost the exact opposite of C's default emotional
position at the start of the book, and watching the two characters play
off of each other in a complex friendship is an absolute delight.
The ending of this book is complicated, messy, and incomplete. It is the
sort of ending that I think could be incredibly powerful if it hits
precisely the right chords with the reader, but if you're not that reader,
it can also be a little heartbreaking because Elkin refuses to provide an
easy resolution. The ending also drops some threads that I wish Elkin
hadn't dropped; there are some characters who I thought deserved a
resolution that they don't get. But this is one of those books where the
author knows exactly what story they're trying to tell and tells it
whether or not that fits what the reader wants. Those books are often not
easy reading, but I think there's something special about them.
This is not the novel for people who want detailed world-building that
puts a solid explanation under events. I thought Elkin did a great job
playing with the conventions of an episodic anime, including starting the
book on Episode 12 to imply C's backstory with monster attacks and hinting
at a parallel light anime story by providing TV-trailer-style plot
summaries and teasers at the start and end of each chapter. There is a
fascinating interplay between the story in which the Angelic Saints are
the protagonists, which the reader can partly extrapolate, and the novel
about C that one is actually reading. But the details of the
world-building are kept at the anime plot level: There's an arch-villain,
a World Tree, and a bit of backstory, but none of it makes that much sense
or turns into a coherent set of rules. This is a psychological novel; the
background and rules exist to support C's story.
If you do want that psychological novel... well, I'm not sure whether to
recommend this book or not. I admire the construction of this book a great
deal, but I don't think appealing to the broadest possible audience was
the goal. C's anxiety spiral is very repetitive, because anxiety spirals
are very repetitive, and you have to be willing to read for the grace
notes on the doom loop if you're going to enjoy this book. The
sentence-by-sentence writing quality is fine but nothing remarkable, and
is a bit shy of the average traditionally-published novel. The main appeal
of A Little Vice is in the deep and unflinching portrayal of a
specific emotional journey. I think this book is going to work if you're
sufficiently invested in that journey that you are willing to read the
brutal and repetitive parts. If you're not, there's a chance you will
bounce off this hard.
I was invested, and I'm glad I read this, but caveat emptor. You
may want to try a sample first.
One final note: If you're deep in the book world, you may wonder, like I
did, if the title is a reference to Hanya Yanagihara's (in)famous A
Little Life. I do not know for certain I have not read that book
because I am not interested in being emotionally brutalized but if it
is, I don't think there is much similarity. Both books are to some extent
about four friends, but I couldn't find any other obvious connections from
some Wikipedia reading, and A Little Vice, despite C's emotional
turmoil, seems to be considerably more upbeat.
Content notes: Emotionally abusive parent, some thoughts of self-harm,
mind control, body dysmorphia, and a lot (a lot) of shame and
self-loathing.
Rating: 7 out of 10
Anarcat recently wrote about Qalculate, and I think I m a convert, even though
I ve only barely scratched the surface.
The thing I almost immediately started using it for is time calculations.
When I started tracking my time, I
quickly found that Timewarrior was good at
keeping all the data I needed, but I often found myself extracting bits of
it and reprocessing it in variously clumsy ways. For example, I often don t
finish a task in one sitting; maybe I take breaks, or I switch back and
forth between a couple of different tasks. The raw output of timew
summary is a bit clumsy for this, as it shows each chunk of time spent as
a separate row:
$ timewsummary2025-02-18Debian
Wk Date Day Tags Start End Time TotalW8 2025-02-18 Tue CVE-2025-26465, Debian, 9:41:44 10:24:17 0:42:33 next, openssh Debian, FTBFS with GCC-15, 10:24:17 10:27:12 0:02:55 icoutils Debian, FTBFS with GCC-15, 11:50:05 11:57:25 0:07:20 kali Debian, Upgrade to 0.67, 11:58:21 12:12:41 0:14:20 python_holidays Debian, FTBFS with GCC-15, 12:14:15 12:33:19 0:19:04 vigor Debian, FTBFS with GCC-15, 12:39:02 12:39:38 0:00:36 python_setproctitle Debian, Upgrade to 1.3.4, 12:39:39 12:46:05 0:06:26 python_setproctitle Debian, FTBFS with GCC-15, 12:48:28 12:49:42 0:01:14 python_setproctitle Debian, Upgrade to 3.4.1, 12:52:07 13:02:27 0:10:20 1:44:48 python_charset_normalizer 1:44:48
So I wrote this Python program to help me:
#! /usr/bin/python3"""Summarize timewarrior data, grouped and sorted by time spent."""importjsonimportsubprocessfromargparseimportArgumentParser,RawDescriptionHelpFormatterfromcollectionsimportdefaultdictfromdatetimeimportdatetime,timedelta,timezonefromoperatorimportitemgetterfromrichimportbox,printfromrich.tableimportTableparser=ArgumentParser(description=__doc__,formatter_class=RawDescriptionHelpFormatter)parser.add_argument("-t","--only-total",default=False,action="store_true")parser.add_argument("range",nargs="?",default=":today",help="Time range (usually a hint, e.g. :lastweek)",)parser.add_argument("tag",nargs="*",help="Tags to filter by")args=parser.parse_args()entries:defaultdict[str,timedelta]=defaultdict(timedelta)now=datetime.now(timezone.utc)forentryinjson.loads(subprocess.run(["timew","export",args.range,*args.tag],check=True,capture_output=True,text=True,).stdout):start=datetime.fromisoformat(entry["start"])if"end"inentry:end=datetime.fromisoformat(entry["end"])else:end=nowentries[", ".join(entry["tags"])]+=end-startifnotargs.only_total:table=Table(box=box.SIMPLE,highlight=True)table.add_column("Tags")table.add_column("Time",justify="right")fortags,timeinsorted(entries.items(),key=itemgetter(1),reverse=True):table.add_row(tags,str(time))print(table)total=sum(entries.values(),start=timedelta())hours,rest=divmod(total,timedelta(hours=1))minutes,rest=divmod(rest,timedelta(minutes=1))seconds=rest.secondsprint(f"Total time: hours:02:minutes:02:seconds:02")
$ summarize-time2025-02-18Debian
Tags Time CVE-2025-26465, Debian, next, openssh 0:42:33 Debian, FTBFS with GCC-15, vigor 0:19:04 Debian, Upgrade to 0.67, python_holidays 0:14:20 Debian, Upgrade to 3.4.1, python_charset_normalizer 0:10:20 Debian, FTBFS with GCC-15, kali 0:07:20 Debian, Upgrade to 1.3.4, python_setproctitle 0:06:26 Debian, FTBFS with GCC-15, icoutils 0:02:55 Debian, FTBFS with GCC-15, python_setproctitle 0:01:50Total time: 01:44:48
Much nicer. But that only helps with some of my reporting. At the end of a
month, I have to work out how much time to bill Freexian for and fill out a
timesheet, and for various reasons those queries don t correspond to single
timew tags: they sometimes correspond to the sum of all time spent on
multiple tags, or to the time spent on one tag minus the time spent on
another tag, or similar. As a result I quite often have to do basic
arithmetic on time intervals; but that s surprisingly annoying! I didn t
previously have good tools for that, and was reduced to doing things like
str(timedelta(hours=..., minutes=..., seconds=...) + ...) in Python,
which gets old fast.
Instead:
I also often want to work out how much of my time I ve spent on Debian work
this month so far, since Freexian pays me for up to 20% of my work time on
Debian; if I m
under that then I might want to prioritize more Debian projects, and if I m
over then I should be prioritizing more Freexian projects as otherwise I m
not going to get paid for that time.
$ summarize-time-t:monthFreexian
Total time: 69:19:42$ summarize-time-t:monthDebian
Total time: 24:05:30$ qalc'24:05:30 / (24:05:30 + 69:19:42) to %'(86730 / 3600)/ ((86730 / 3600) + (249582 / 3600)) 25.78855349%
Sigh, sometimes I really don t understand time. And I don t mean, in
the physics sense.
It s just, the days have way fewer hours than 10 years ago, or there s
way more stuff to do. Probably the latter
No time for real open-source work, but I managed to do some minor
coding, released a couple of minor version (as upstream), and packaged
some refreshes in Debian. The later only because I got involved,
against better judgement, into some too heated discussions, but they
ended well, somehow. But the whole episode motivated me to actually do
some work, even if minor, than just rant on mailing lists .
My sports life is still pretty erratic, but despite some repeated
sickness (my fault, for not sleeping well enough) and tendon issues,
there are months in which I can put down 100km. And the skiing season
was really awesome.
So life goes on, but I definitely am not keeping up with entropy, even
in simple things such as my inbox. One day I ll make real blog post,
not just an update, but in the meantime, it is what it is.
And yes, running 10km while still sick just because you re bored is
not the best idea. According to a friend, of course, not to my Strava
account.
Offline PKI backed up by 3 YubiKeys
Libre Computer Sweet Potato SBC, powered by the AML-S905X SOC
This year I was at 
Welcome to post 46 in the 
In today s digital landscape, social media is more than just a communication tool it is the primary medium for global discourse. Heads of state, corporate leaders and cultural influencers now broadcast their statements directly to the world, shaping public opinion in real time. However, the dominance of a few centralized platforms X/Twitter, Facebook and YouTube raises critical concerns about control, censorship and the monopolization of information. Those who control these networks effectively wield significant power over public discourse.
In response, a new wave of distributed social media platforms has emerged, each built on different decentralized protocols designed to provide greater autonomy, censorship resistance and user control. While 
Mastodon was created in 2016 by 
Interestingly, 
[I d like to stop writing posts like this. I ve been trying to work out what to say now for nearly 2 months (writing the mail to 
Most of my Debian contributions this month were
by por Andrew Gon alves
Nova gera o: uma entrevista com iniciantes no projeto Debian
Instala o personalizada e automatizada do Debian com preseed
Manipulando patches com git-buildpackage
debian.social: Socializando Debian do jeito Debian
Proxy reverso com WireGuard
Celebra o dos 30 anos do Debian!
Instalando o Debian em disco criptografado com LUKS
O que a equipe de localiza o j conquistou nesses 30 anos
Debian - Projeto e Comunidade!
Design Gr fico e Software livre, o que fazer e por onde come ar
Another short status update of what happened on my side last
month. One larger blocks are the