So I am using Debian on a System76 Arm64 (aarch64) workstation since 9 months, and I can say: everything works. It should be noted that I use very few proprietary software, so I rely mostly on Debian packages for what I am doing.
What I can say is basically all open source software which exists today, takes care to build on aarch64 or is available as a binary, either in the Debian archive, in a Flatpak or Snap, or in a Github Artefact. From 3D games, to Kubernetes tooling, practically everything open source is compiled for aarch64 Linux as well. Same thing for server software, every container image built is also proposing an aarch64 binary today.
I could also add a standard PCI Express Soundblaster sound card, and the kernel recognized it without issues.
The major downside I had was that Wayland is not working on my Nvidia GPU, whether with Nouveau or the proprietary drivers, thus I am using Gnome with X11.
Also on the proprietary side, I missed the Discourse client, but I am not using that much, and those video meetings tool which popped up in the COVID time are perfectly usable in the browser.
The situation is for me much better than in the 2000s when I used a Mac Mini (powerpc) with Debian, where the need for a Flash player at that time really limited the amount of online content I could access.
What do I get using aarch64 you ask ? The main reason for me was the curiosity to use a non x86 arch, and to have a 80 core / 128 GB RAM machine to do a Lab in a Box with OpenShift running on OpenStack, with Ceph and a bit of local LLM inference thrown in.
In the end I have enough labs at work, so that need disappeared, but I still enjoy having that amount of power in a rather quiet machine for a standard 80W consumption.
testrepository
For a long time I ve used Robert Collins testrepository (testr) to
run tests in many of the projects I work on. It s a small, focused tool
built around a simple idea: decouple the running of tests from the
recording and querying of their results.
The way it works is straightforward. A test runner emits a subunit
stream a compact binary protocol for test results and testrepository
stores those streams in a per-project .testrepository/ directory.
Once results are in the repository, you can ask questions like which
tests failed in the last run? , re-run only the failures , what are the
slowest tests? , or what changed between this run and the previous one? .
The killer feature, for me, has always been the failing-test loop. When a
big test suite breaks, you don t want to re-run the whole thing after every
fix you want to iterate on just the failures, and only re-run the full
suite once they re all green. testrepository made that workflow ergonomic
long before most language-specific test runners had anything comparable,
and many of them still don t have a good answer for it.
testrepository has served me well for over a decade, but it has been
largely unmaintained for a while, and I had some ideas of improvements that I
wanted to try out. So I wrote a Rust port, which has since grown a number of
features of its own.
Inquest
Inquest is a Rust port of testrepository that has since grown a
number of features of its own. The binary is called inq.
Goals
The goals are deliberately modest:
a single static binary, no Python runtime required
no need to write a dedicated config file for most projects
compatible enough with testrepository s workflow that I can switch projects
over without retraining my fingers
a richer on-disk format that captures more about each run (git commit,
command line, duration, exit code, concurrency)
good support for the languages I actually use day-to-day: Rust, Python,
Go, and Node.js
mostly Do What I Mean (DWIM), e.g. getting me to know as quickly
as possible what tests are failing and why, and being clever
about doing this
Inquest reads and writes subunit v2 streams, so anything that can produce
subunit (directly or via one of the many converters) can feed into it.
Quick start
Inquest can usually figure out how to run your tests on its own. In a Rust,
Python, Go or Node.js project:
$ cdmy-project
$ inq
Or if the auto-detection doesn t work, you can ask it to generate a config file and
then run the tests:
$ inqauto
$ inqrun
inq auto writes an inquest.toml describing how to invoke the test
runner; inq run runs the tests, captures the subunit stream, and stores
the results in a .inquest/ directory.
For a Rust project the generated config looks like:
$ inqstats# repository-wide statistics $ inqlast# results of the most recent run $ inqfailing# only the failing tests $ inqslowest# the slowest tests in the last run $ inqrun--failing# re-run only what failed last time
The last one is the workflow I use most often: run the full suite once, fix
the obvious failures, then iterate on inq run --failing until the list
is empty.
A few things that aren t in testrepository
Some of the features that have grown in inquest beyond the original
testrepository functionality:
Timeouts. --test-timeout, --max-duration, and
--no-output-timeout will kill a test process that is hanging or has
stopped producing output. --test-timeout auto derives a per-test
timeout from the historical duration of that test, which is handy for
catching tests that hang.
Once the test runner is killed, the test is marked as failed and the next
test is started, so a broken test doesn t hold up the whole suite.
Ordering --order can be used to run tests in a specific order, e.g.
to run the slowest tests first, to run the tests that failed most recently
first, or to run the widest variety of tests first to maximize the chance of
finding a failure early on.
Live progress. inq running tails the in-progress subunit stream
on disk and reports observed/expected test counts, percent complete,
elapsed wall-clock time, and an ETA derived from each test s historical
duration. Useful when a CI run is taking longer than you d like.
Flakiness ranking. inq flaky ranks tests by pass fail transitions
in consecutive runs in which the test was recorded, so chronically broken
tests rank low and genuinely flapping tests rank high.
Comparing runs. inq diff <A> <B> shows what changed between two
test runs newly failing, newly passing, and tests that flipped state
which makes it easy to see whether your last change actually fixed (or
broke) anything.
Bisecting git history. inq bisect <TEST> drives git bisect
to find the commit that broke a given test. It defaults the
known-good and known-bad commits from the recorded run history (the
most recent run where the test passed, and the most recent where it
failed), so in the common case there is no need to remember either
just point it at the test name and let it work.
Richer run metadata. inq info shows the git commit, command
line, duration, exit code, and concurrency for a run, with a flag for
whether the working tree was dirty when the run started. Combined with
inq diff this makes it much easier to triangulate when a regression
was introduced.
Rerun a previous run verbatim. inq rerun <ID> re-runs exactly the
tests of a previous run, in the same order, forwarding the same --
arguments that the original run used. inq rerun -1 repeats the latest.
Web based view. inq web serves a web-based view of the repository,
with a dashboard of recent runs and detailed views of individual runs and tests.
Web UI
Most of the time I drive inquest from the command line, but for browsing
historical results of a large suite spotting flapping tests, drilling
into a single test s run history, or just getting a visual sense of which
parts of the suite are hurting a web view is more pleasant. inq web
starts a local server with exactly that:
$ inqweb
The repository overview shows totals and a per-test history grid where
each cell is one run, coloured by outcome. Bands of red make it easy to
pick out tests that have been broken for a long time, and isolated red
cells in an otherwise green column point at flaky tests.
Drilling into an individual test gives you its full run history, a
duration sparkline, and per-run pass/fail status:
Migrating from testrepository
If you already have a .testrepository/ directory full of historical
runs, inq upgrade will migrate it into the new .inquest/ format,
with a progress bar for the impatient.
The legacy .testr.conf (INI) format is still understood, so existing
projects don t have to be converted to inquest.toml immediately
though the TOML format is preferred for new projects.
Trying it
The source is on GitHub at jelmer/inquest. To install from source:
$ cargoinstallinquest
In a project with a Rust, Python, Go or Node.js test suite:
Due to health reasons I did not have the energy to write individual status
updates for February & March, so I ll just combine them with the April update:
In February I cleaned out my GitHub account and moved all remaining
projects to Codeberg. I archived the
repositories on GitHub and added links to the new repositories on Codeberg.
GitHub is a platform that is more and more frustrating to use. I still have to
use it for my dayjob, though. The number of pull requests and issues that are
written either by bots or by users that use bots increased in the last two
years. Combined with that, GitHub provides a very low barrier for entitled
users who do not want to contribute to a productive environment. GitHub now
feels like the Twitter/X of git forges. Codeberg on the other hand is a
community project. I feel a lot more at home there and the platform itself
feels a lot more responsive than GitHub.
Debian Related Work
Uploaded wayback 0.3-1 to experimental
Uploaded slurp 1.6.0-1 to unstable
Uploaded first a prerelease of sway to experimental to be able to test
wlroots 0.20.0 and then uploaded rc1, rc2 and rc3 of the upcoming 1.12
release
Uploaded waybar 0.15.0-1 to unstable
Uploaded kanshi 1.9.0-1 to unstable, which was possible because the dependency libscfg finally went through NEW
Uploaded libscfg 0.2.0-1 to unstable
Uploaded swaybg 1.2.2-1 to unstable
Uploaded labwc 0.9.4-1, 0.9.5 & 0.9.6 to unstable
Fixed the packaging of vali and uploaded version 0.1.1-1 to unstable; then
added vali to the build dependencies of kanshi and reuploaded 1.9.0-2 thereof
Uploaded swaylock 1.8.5-1 to unstable
Uploaded fcft 3.3.3-1 to unstable
Uploaded foot 1.26.1-1 to unstable
Uploaded swayimg 5.0-1 and 5.1-1 to unstable
Fixed some packaging metadata in libsfdo and uploaded 0.1.4-2 to unstable
Reverted the upload of slurp from 1.6.0-1 to 1.6.0really1.5.0-1 because the
upstream release of 1.6.0 was made by mistake and yanked a week later. Maybe
I should add a cooldown period before uploading new releases ;)
Uploaded mako-notifier 1.11.0-1 to unstable
Uploaded cage 0.3.0-1 to experimental which uses wlroots 0.20.0
Uploaded xdg-desktop-portal-wlr 0.8.2-1 to unstable
Voted
DH Related Work
I took part in the DHD 2026 Conference
in Vienna, including a hands-on
workshop
of the dhinfra project.
I released 0.60.0, 0.61.0 and 0.62.0 of apis-core-rdf. We rewrote the
configuration format for the importer. We previously used TOML files, but that
does not give us inheritance. So we now use simply Python classes as
configuration format.
I implemented a new backend for our apis-bibsonomy Django package. The package
is meant to provide a datamodel for storing reference data that links to
Bibsonomy or Zotero. Given that we don t use Bibsonomy anymore we now dropped
the Bibsonomy backend but added a Zotero backend that allows to cache the
entries locally.
We are very excited to announce that Debian has been assigned seven contributors
to work under mentorship on a variety of
projects with us during the
Google Summer of Code.
Here is a list of the projects and contributors, along with details of the
tasks to be performed.
Project: Automated Debian Packaging with debianize
Contributor: Anurag Nayak
Deliverables of the project: Debianize is a tool that aims to automatically
create debian packages from scratch from upstream source trees. As for the
current version, it works for some of the packages but it is not reliable. This
project aims at making it production ready such that it can work with most of
the projects. Along with that improving its reliability, coverage, integration
with the broader ecosystem and other enhancements.
Project: Linux Livepatching
Contributor: Aryan Karamtoth
Deliverables of the project: Linux Kernel Livepatching is the process of
replacing functions in the kernel code affected by CVEs with the patch-applied
functions during system runtime. It's basically a method to apply security
kernel patches to a running system.
Project: DebNet: Visualising the Bus Factor Graph Analysis of Debian's Infrastructure
Contributor: Fabio Ruhland
Deliverables of the project: DebNet models the Debian archive as a graph to
identify critical packages maintained by too few people. Using data from the
Ultimate Debian Database (UDD), it builds a package dependency graph and a
maintainer-package graph to compute practical metrics like the Bus Factor,
Fragility Score, and Dependency Impact for every source package.
Project: Attack of the Clones: Fight Back Using Code Duplication Detection From Security Patches
Contributor: Gajendra Nath Soren
Deliverables of the project: This project aims to detect vulnerable code clones
in the Debian archive by automatically extracting signatures from security
patches. Using a two-signal approach that separates vulnerable patterns from
fix patterns, the system generates high-specificity queries to search the entire
archive via Debian CodeSearch.
Project: Debusine: debuginfod server
Contributor: Jugal59
Deliverables of the project: This project implements a debuginfod-compatible
server within Debusine to provide automated debug symbol resolution for Debian
developers.
Project: Debian-LSP: Improve File Format Support
Contributor: Lucas Ly Ba
Deliverables of the project: The Debian LSP Language Server currently provides
only basic features field completion, parse-error diagnostics, and simple
quick fixes leaving Debian maintainers without the rich IDE experience
available in other ecosystems.
Project: Debusine: live log streaming
Contributor: mo-ashraf
Deliverables of the project: Debusine currently only shows task logs after a
task has fully completed. This means developers working with long-running jobs
(such as package builds or test pipelines) have no way to monitor progress in
real time or catch failures early. This project adds live log streaming to
Debusine.
Congratulations and welcome to all the contributors!
The Google Summer of Code program is possible in Debian thanks to the efforts of
Debian Developers and Debian Contributors that dedicate part of their free time
to mentor contributors and outreach tasks.
Join us and help extend Debian! You can follow the contributors' weekly reports
on the debian-outreach mailing-list, chat with us on our
IRC channel or reach out to the individual projects' team
mailing lists.
The eight release of the binb package,
and first in two years, is now on CRAN and in r2u. binb regroups
four rather nice themes for writing LaTeX Beamer
presentations much more easily in (R)Markdown. As a teaser,
a quick demo combining all four themes is
available; documentation and examples are in the package.
This release contains regular internal updates to continuous
integration, URLs reference and switch to Authors@R. The trigger for the
release, though, was a small updated need when very recent
pandoc versions (as shipped with RStudio) are used which
require a new variable declaration in the LaTeX template files in order
to process uncaptioned tables. The summary of changes follows.
Changes in binb
version 0.0.8 (2026-05-01)
Small updates to documentation URLs and continuous
integration
The package now uses Authors@R in DESCRIPTION
Newer pandoc versions are accommodated by adding a required
counter variable in the latex template file
How to build
reverse dependencies using Salsa CI
Last week, I attended MiniDebConf Campinas, and one of my favorites
talks was "Salsa CI,
showing features that almost nobody knows" by Aquila Macedo.
One of the things I learned is that we can easily build reverse
dependencies using:
I mentor several people in Debian, and have been repeatedly asked to offer an opportunity to ask questions on a live call. I have now started a recurring video call for exactly that, which I call Mentoring Mondays, and it is open for anyone aspiring to contribute to Debian, one of the oldest and most widely used Linux distributions.
Mentoring Mondays have already been happening for the past few Mondays, and this week we had a record 20 people on the call. During the calls so far we have had a demo of updating a package for a new upstream release using gbp, and of how to create a Merge Request on Salsa for a new upstream version. There is clearly a need for this, so I am announcing this now also on my blog, just as I have publicly announced that I offer mentoring for aspiring Debian contributors.
What is Mentoring Mondays?
Mentoring Mondays is a recurring video call that lasts roughly 45 minutes with the agenda:
Weekly walk-through: demo of something in Debian packaging, explaining the what and why
Discussion on pros and cons to help participants develop their judgment
Questions & answers on Debian packaging, or open source contributing in general
This is ideal for you if you:
Have built a .deb package at least once and want to do it better
Are stuck on a specific Debian packaging bug and need guidance
Want to understand how Debian Developers actually work day-to-day
The call is mainly intended for those who want to contribute to Debian (or Debian derivatives, with Ubuntu being the most popular), but anyone can join to learn about things related to contributing to a Linux distribution. Please note that video chat uses Debian Social Jitsi. Joining the call requires authentication using a Salsa account, which anyone contributing to Debian should have anyway.
Calls are not recorded, so participants can chat freely, and are also encouraged to be on-camera for an enhanced sense of community.
Matrix channel and future meeting time announcements
Please join the Matrix channel #mentoringmondays:matrix.debian.social if you plan to attend Mentoring Mondays. All future meeting times will be announced there. It is also the channel to post questions about Debian packaging to be answered during the call.
The current meeting time is friendly to people in Europe, Asia and Australian time zones, and will repeat at the same time slot on:
May 11th, 2026 at 12:30 UTC
May 18th, 2026 at 12:30 UTC
May 25th, 2026 at 12:30 UTC
June 1st, 2026 at 12:30 UTC
June 8th, 2026 at 12:30 UTC
Starting in mid-June the meeting time will change to accommodate participation in different time zones.
Spread the word
Feel free to extend the invite to anyone you think might be interested in joining!
If you mention this on social media, please post using tag #mentoringmondays, or simply boost the existing posts on the social media of your preference: Mastodon, Lemmy, Reddit, Bluesky, LinkedIn, Farcaster, X.
Thanks
A big thanks to Jason Kregting for helping organize. I would also like to thank in advance all the Debian Developers who are able to join the call and be available to participate in discussions and help answer questions.
If I had been patient, it would have saved me time. One such instance
is following.
From my early blogs, you might know I am using mutt to do email. Just
after I get along with mutt, I started using notmuch. Because limit
search in mutt is always a pain when you have multiple folders. And
what better tool out there than notmuch-mutt to bind both these.
notmuch-mutt provide three macros by default.
One for search, one for reconstructing threads and one for
manipulating tags, which I missed.
Now my impatient part. I have already mapped f6 for my folder
movements and in my initial days of notmuch, I only use just search.
So I never cared about the f6 macro provided by notmuch-mutt. As time
goes by I got very comfortable with notmuch. I was stretching my
notmuch legs. I started to live more on notmuch search results
date:today tag:unread than more on the mutt index. To the problem,
since notmuch-mutt dump all results to a temp maildir location, can t
perform flag changes back to the original maildir which was annoying,
because we need to distinguish what mail you read and what not when
you subscribed to most of all debian mailing list.
I was under the impression that, the notmuch-mutt is not capable of
doing so and I just went like that without checking docs. I started
doing all crazy hack to sync these maildirs.
I even started reading notmuch-mutt codebase.
Later, I settled on notmuch-vim. Cause I can manipulate flags sync
back from notmuch to maildir.
And while searching for something, I accidentally revisited the the
the notmuch-mutt macro page and saw the tag manipulation. I was like
:( .
If I read about the third macro patiently when added that to config,
I could ve saved time by not doing ugly hacks around it.
I think I learned my lesson.
On the 7th of September 2025, my friend Dione and I had a day trip to Vienna the capital of Austria. We were attending a conference in Budapest, Hungary, which is 250 km from Vienna. So, it was a good opportunity to visit Vienna.
We took a morning train from Budapest to Vienna and got back to Budapest by night. However, booking these tickets turned out to be a bit complicated. There were many websites to book the train ticket Hungarian Railways, Austrian Railways, and third-party sites such as Omio. All these websites had different prices for the same ticket.
I booked the tickets from the Hungarian Railways website as it was the cheapest. The train from Budapest to Vienna was 13, operated by Eurocity. Also, I had to pay 2 for the seat reservation on top. The train from Vienna to Budapest operated by Railjet was 21, along with 2 extra for reservation again making it 23. The tickets for the two-way journey added up to 38.
The cost of these tickets varied depending on when one purchses them: the sooner you purchase, the lower the price. I bought my tickets 15 days ahead of the date of journey and paid just 38. In contrast, Dione booked just one day before her trip and paid around 100 for her tickets.
As for the seat reservation, long-distance trains in Europe usually require paying extra for the seat reservation. This ensures that you get your preferred seat, such as a window seat or an aisle seat. Nevertheless, you will get a seat on long-distance trains because they do not sell more tickets than there are seats. Therefore, you will get a seat without reservation as well. However, we reserved our seats so that we can sit together. This helped us more in the return part of the journey from Vienna to Budapest which was more crowded than the train we took from Budapest to Vienna in the morning.
On another note, reservation is mandatory on some trains in Europe, but ours wasn t one of them. In addition, people also use rail passes, so an extra charge is required on top for reserving the seats for pass holders. On the other hand, local trains do not require seat reservations in general.
Our train s scheduled departure was at 08:55 from the Budapest Kelenfold station. We reached the train station 40 minutes before the train s scheduled departure. The Kelenfold station had free Wi-Fi, which was handy because I didn t have a local SIM.
A departures board at Budapest Kelenfold station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
This is platform number 15 of Budapest Kelenfold station where we boarded our train. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Our train arrived on time. I tried to find our coach number but could not find the numbers written anywhere on the side of the coach. Luckily, we were helped by a fellow passenger who directed me to look at the doors, where the numbers were mentioned clearly!
Then we got into our compartment and took our respective seats. Our tickets were checked twice - once while the train was in Hungary and the other when in Austria. Showing the PDF of the train ticket on our mobile to the ticket inspector was good enough for the purpose. Austria and Hungary are a part of the open transit Schengen area, which means this was the extent of the border control checks we had to go through.
Interior of our Budapest to Vienna train. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
The train also had free Wi-Fi, albeit with poor connection at times. There were no eatery options inside the train.
We deboarded at the Wien Hauptbahnhof station in Vienna. The journey was 250 km and took 2.5 hours, reaching Vienna at 11:25, which was the scheduled time.
This blue colored train was the one we took for our Budapest to Vienna journey. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
An BB train standing at a platform of Vienna train station. BB is the national carrier of Austria. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Wien Hauptbahnhof train station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
At the station, we bought a 24-hour public transport pass from a ticket machine for 8. The pass includes unlimited access to all the public transport in Vienna for 24 hours. My pass was valid from the 7th of September at 11:34 to the 8th of September at 11:33. A single public transport ticket (from anywhere to anywhere) costs 2.4. A single ticket of 2.4 can be used once on any public transport in Vienna trams, metros, and buses.
Therefore, the pass is a good deal if you are going to take at least four public transport trips in a day. Unlike the public transport pass I got in Budapest, the pass in Vienna was anonymous and not tied to the rider s name.
My public transport pass in Vienna.
We wanted to visit the Sch nbrunn Palace. The palace was reachable by subway. In order to get to the subway station, we started by going outside the station. But it was not outside. So we came back inside the station building and realized that the subway was underground.
We took the subway and deboarded at the Sch nbrunn subway station the closest one to the palace. The ride was smooth; the train was pretty silent.
By the way, like Budapest, there were no AFC gates for boarding the subway in Vienna. The stations had ticket validators instead, where you are supposed to validate your tickets before getting into the subway.
Instead of AFC gates, Vienna has ticket validators as in the picture. You need to tap your ticket in the validator before boarding the subway. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
These validators are in place to ensure that you use your ticket only once. Unlike AFC gates, which are present in metros of most of the countries I have been to, the ticket validators don t act as a physical barrier to enter the boarding area.
If you board the metro without validating your ticket, you will be facing hefty fines upon getting caught. I have heard that the fine is around 100. On the other hand, if you have a public transport pass like we did, then you don t need to validate it before boarding.
In addition, there were no annoying security checks either, unlike in Indian cities. In the Delhi metro, for example, you would need to scan your bags and pass through a security check before getting to the AFC gates.
Vienna subway. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Now back to the story, after alighting at the Sch nbrunn subway station, we walked to the Sch nbrunn Palace. One can roam around outside the palace and click pictures for free. To go inside, however, requires buying tickets. The tickets for the palace can be booked in advance on the internet. We didn t take the tickets in advance, as we decided to visit the palace at the last moment.
So we went to the ticket counter and found out that we needed to wait for 1 hour 40 minutes before going inside if we took the tickets at that moment. In addition, one ticket costs 44 (around 4000 Indian rupees). Since we had to return to Budapest in the evening and only had a few hours in the city, we decided not to go inside the palace. Instead, we clicked a few pictures outside the palace.
Sch nbrunn Palace. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
The Sch nbrunn Palace is a UNESCO World Heritage Site and is a historically significant place. It servedas one of the residences of the powerful Habsburg dynasty. The palace looked so good that my friend Dione said, It seemed like the palace was built yesterday . This remark applied to other parts of Vienna we went to. For example, the subway stations also seemed like they were built yesterday.
A street near Sch nbrunn Palace. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Now, we wanted to go someplace to grab a bite. I asked my friend Urbec for suggestions on where to go. They suggested we visit the steps named Strudlhofstiege, which had the added benefit of being in a neighborhood with good bakeries and buildings.
So, we took the subway and deboarded at the Ro auer L nde station, followed by walking around a kilometer to reach the stairs.
Ro auer L nde subway station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Platform of the Ro auer L nde subway station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
The The Strudlhofstiege steps. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
On the way, we were also looking for a place to eat. Unfortunately, it was Sunday, and Vienna closes on Sunday. That means most of the shops including bakeries and caf s are closed. Only places like railway stations have shops open on Sundays.
By the way, walking around in the streets of Vienna was a treat. The streets were not crowded (as it was not exactly a touristy neighborhood) and had good pedestrian infrastructure, with clean streets and separate cycling tracks. The buildings were also beautiful.
A random street in Vienna.
Another street in Vienna.
After some walking, we found a restaurant open. I grabbed the menu to check the prices. A lady at the shop asked me what I was doing, and I told her that I was browsing the menu. She said that the menu was in German. I don t know how she knew that we didn t know German, but it seemed like a racist thing to be told.
We roamed around further and found a caf by the name of Blue Orange, where we ordered coffee and croissants. When we got our order, the waiter told us that they were having some issues, so they wouldn t charge us for the croissant if it wasn t good.
A picture of Blue Orange caf . Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
My friend and I took a bite, and both of us didn t like the croissant. After some time, the waiter came to us and asked whether the croissant was okay, to which we said no. Therefore, they didn t charge us for the croissant. This was the first time something like this happened to me. It felt like I was in a different world. I added a small tip at the end for this gesture, which I had to put in a jar at the counter.
The cappuccino I ordered was 4.50, while the espresso that Dione ordered was 3.60. The croissant would have been 3.60. I remember Paris having cheaper croissants!
Then when the waiter brought our drinks out, they automatically gave me the espresso and Dione the cappuccino. Dione found this funny because there is a stereotype in her country (Australia) that men drink strong black coffee, and women drink milky drinks like cappuccinos. She found it interesting that this stereotype seems to exist in Austrian culture too.
We hopped on a tram to reach the nearest subway station and went to the Wien Hauptbahnhof station to have something before we caught our return train to Budapest.
Trams in Vienna. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
At the station, I had Esterhazyschnitten and Punschkrapfen (thanks, Urbec, for the suggestion). The lady at the shop warned me that punschkrapfen had alcohol in it, to which I said okay.
Esterhazyschnitten was a cake made of almonds, while punschkrapfen was a jam-filled sponge cake, soaked in rum. Esterhazyschnitten was my favorite out of the two. The punschkrapfen was too sweet for my taste.
Punschkrapfen. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Esterhazyschnitten. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
While the station was well-built, there were a couple of things about the Wien Hauptbahnhof station that we didn t like. There were no seats inside the station, so we had to eat outside the building. Also, the toilets needed to be paid for. It costs 50 cents to use the toilets at this station.
The Vienna train station had departure boards all over the place. So, we went to the platform our train was to arrive on.
Departure boards in Vienna displaying information about the trains. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Platform and tracks at Wien Hauptbahnhof station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
When our train arrived, we had some difficulty locating our compartment. This train was operated by a different company (Railjet) than the one we took in the morning (Eurocity) from Budapest to Vienna, and we were able to locate the coach numbers using the digital board at the station. Each compartment had a digital board next to it on the station displaying the coach number. However, that wasn t the problem. Even after reading the coach numbers and trying to find ours, it didn t appear where we expected in the sequence.
When we were not able to find our coach for a while, we asked a ticket inspector of the train who was standing on the platform. He directed us towards the front side of the train. So we started running to the front side as we didn t know how long the train stops.
As we ran toward our coach, we found out that the engine of the back train was connected with the last compartment of the train at the front. At that point, we realized that the train was a combination of two trains. At a later station, the train on the back side parted ways and went towards Vienna Airport.
Interior of the train we took from Vienna to Budapest. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
This is the train we took for our return journey from Vienna to Budapest. It is standing on a platform in Budapest Kelenfold station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
We had a smooth journey and reached Budapest a couple of hours later.
Vienna is a beautiful city; we enjoyed being there, and we would like to visit the city again!
That s it for now. Signing off. See you in the next one!
Credits: Thanks to Dione and Badri for proofreading.
Educators throughout the world are tasked with the difficult requirement of
evaluating students works, making sure the grades meaningfully reflect the
students understanding of the subject, and that a graded assignment maps
to the relevant work invested in solving it. After the irruption of
Large-Language Models in late 2023, this task became obviously much harder:
if a widely available computer program is able to solve an assignment in a
way that resembles a human-generated response, how can educators
meaningfully grade their groups?
As it has been the case with different innovations over time (such as with
the appearance of electronic calculators or the mass availability of
digital encyclopedias), the first reactions were of prohibition and denial:
students who use the new tool in question are to be disqualified or somehow
punished. It is only some time after the innovation in question settles
that teachers find a way to properly weigh, integrate and accept its use.
The authors of this position article present several arguments as to why it
is impossible, unethical and unadvisable to use automated AI detection
systems to process student assignments. The first argument is whether it is
at all possible to reliably differentiate human-written essays from
LLM-generated artifacts. The first criticism is that AI detectors are,
themselves, LLMs trained on human-generated texts (negative) and
LLM-generated texts (positive). However, the only way to assert the
training material is not noisy is to use pre-2020 text as human-generated
but natural ways of writing are influenced by what people read, and the
authors quote studies pointing out that human language, particularly in the
scholarly fields, has incorporated terms and constructions that were used
as LLM markers. Quoting the authors, As exposure to AI-generated material
becomes increasingly widespread, it is reasonable to expect that the
linguistic patterns of human writing will shift, reflecting the influence
of AI-assisted texts encountered across education, media, and everyday
communication . Stylistic elements and other such markers are being adopted
back into regular speech at a high rate.
Then, the aspect of ethics comes into play as well. While it is expected
that teachers should demand intellectual integrity from students, and
plagiarism detectors have been widely accepted into the workflow of
academics, the accusation of presenting LLM output as own work is
necessarily an uphill battle: the accused party is tasked with providing
proof of innocence based on nebulous, probabilistic accusations. The
authors argue, once an accusation of turning in a LLM-generated text is
made on a student, the onus on proving innocence lies with the accused.
The authors review and argue against a series of techniques that have been
presented in literature to aid teachers in detecting LLM abuse, such as
linguistic markers, single or multiple AI detectors, the use of false
references, hidden adversarial prompts, arguing in all cases the techniques
fail to be trustable enough and highlighting the probability of both false
positives and negatives. They also present AI detection as a false
dichotomy: many works presented are not 100% human generated nor 100%
LLM-generated, but some pertinent LLM-generated paragraphs are presented
mixed with human-generated content, in a positive, critical AI use
( Students work is frequently created with, not by, generative AI ).
The article closes by reiterating the authors position: AI detection in
education is not merely flawed; it is conceptually unsound . they call upon
institutions to accept the use of generative LLMs cannot be solved through
surveillance and punishment , but has to be tackled by an assessment
design that recognizes AI s role in learning .
This article s position is very strong and well argued, and although it
will surely meet with ample opposition, it surely poses an important, very
current problematic. As a teacher, I found it a very enlightening read.
Yesterday, I had to add support for running KVM virtual machines inside an LXC container. More as a reminder to myself, in case I ever have to do this again, here the simple recipe:
LXC Container Config Adjustment
Enable lxc.autodev and execute hook script to be executed after initial /dev creation (updated 20260428: lxc.cgroup2.* instead of lxc.cgroup.*):
[...]
# Auto-create /dev nodes and add native KVM support to the LXC container
lxc.autodev = 1
lxc.hook.autodev = /var/lib/lxc/.hooks/lxc-hook.kvm-support
lxc.cgroup2.devices.allow = c 10:232 rwm
lxc.cgroup2.devices.allow = c 10:238 rwm
lxc.cgroup2.devices.allow = c 10:241 rwm
[...]
[added 20260408] On the internet, you can find a recipe that simply bind-mounts /dev/kvm from the host in to the LXC container. However, this fails if group ID of POSIX group kvm differs between host and container.
LXC Hook Script for KVM Support Enablement
The following script I placed at /var/lib/lxc/.hooks/lxc-hook.kvm-support (on the LXC host!):
#!/bin/sh
# set up native KVM support in LXC container
mknod -m 0660 $ LXC_ROOTFS_MOUNT /dev/kvm c 10 232
chown :kvm $ LXC_ROOTFS_MOUNT /dev/kvm
mknod -m 0660 $ LXC_ROOTFS_MOUNT /dev/vhost-net c 10 238
chown :kvm $ LXC_ROOTFS_MOUNT /dev/vhost-net
mknod -m 0660 $ LXC_ROOTFS_MOUNT /dev/vhost-vsock c 10 241
chown :kvm $ LXC_ROOTFS_MOUNT /dev/vhost-vsock
Weekly notes is a genre where people chronicle their week on their blogs. Weekly notes are like a window. I love going through these, as they re a steady stream of week on week happenings and progress in people s lives. It shows people making efforts to improve: from basic things like learning to swim or drive, to planning long-term goals such as vacations, moving house, states, or even countries. In some cases, they carry internal monologues, thoughts, and anxieties. These are like a constant nudge for me to work on myself, like them.
These are the weekly notes I read nowadays:
Most are there on Thejesh s weekly notes planet which autoupdates when new posts arrive, usually starting on Friday evenings, and by Monday, almost everyone has posted.
It reminds of a word from The Dictionary of Obscure Sorrows -
Kenaway :
the longing to see how other people live their lives when they re not in public; wishing you could tune in to the raw feed of another human existence, in all its messiness and solitude shimmying in place while brushing their teeth, squabbling over where to put the shoes, talking out their problems on solitary commutes if only to give you something to compare your own life against, and figure out whether you re bizarrely normal or normally bizarre.
What We Are Seeking is a bit hard to classify beyond science
fiction. I think I would call it anthropological science fiction, but it's
also a first contact story and a planetary colony story. It is a
standalone novel (well, so far as I know; see later in the review for
caveats). This is Cameron Reed's second novel after the excellent and
memorable cyberpunk novel The Fortunate
Fall, first published in 1996 under Reed's former name of Raphael
Carter.
John Maraintha is a doctor from the world of Essius. He took what he
thought was a temporary job on the Free Ship Edgar's Folly, where
he's endured considerable culture shock. As the novel opens, John learns
that the colonists on Scythia have requested a translator to talk to one
of the native life forms, and a doctor since they're down to only one.
John will be that doctor. The captain has decided, and by the rules of the
free ships, John does not get a choice in the matter.
The Scythian colony is about four hundred people, now located in a desert
climate since the complex native life forms destroyed their previous
settlement. The colonists are a split between Ischnurans and Zandaheans,
two other human civilizations from the scatter of colony worlds left after
Earth embraced AIs (aiyis here) and turned inward. Both of those groups
marry, something John considers a moral abomination. Neither of them seem
likely to understand Essian sexual ethics. More devastatingly, John had
intended to spend some time as a ship doctor and then return home to a new
place in Essian society. Once he lands on Scythia, the chances of that are
gone; it is highly unlikely any ship would pick him up again and take him
home.
I have been trying to find the right books to compare What We Are
Seeking with ever since I read it. The best I've come up with are Ursula
K. Le Guin (particularly The
Dispossessed), Eleanor Arnason's A Woman
of the Iron People, and Becky Chambers's To Be Taught, If Fortunate. The start of the book felt like an
intentional revisiting of an earlier era of science fiction, with somewhat
updated science and politics, but the last half of the book, where the
action picks up considerably, is a meditation on gender, social systems,
religion, and small-group politics. All of that is mixed with biological
exploration and a first-contact story with some quite-alien aliens.
This is the sort of novel where the protagonist's culture is as foreign to
the reader as any of the other cultures he counters, so the reader is
assembling several jigsaw puzzles at once. John is dropped into an
established colony with its own social norms and established hierarchies.
The one other outsider, the translator Sudharma Jain, is, as his name
implies, a Jain who keeps very strict religious observances. Half of the
colony is from something akin to a fundamentalist Christian religious sect
that practices patriarchy and strict marriage codes. The other half is
more gently sexist (but still sexist) and has its own tradition of a third
gender that becomes central to the story. John, meanwhile, is a strong
believer in the Essian approach to social organization: Any two partners
of any gender freely have sex by mutual consent and without obligation,
and family is based solely on blood relations. These beliefs do not fit
comfortably together, even when people are trying (as they mostly do) to
be welcoming.
The first half of this book is very slow. This gives all of the characters
space to breathe and become comfortable, and the characterization is
superb, but it is a book to start when you're in the mood for something
slow and observational. There is a plot that gradually becomes apparent,
or rather there are several plots that are intertwined, but tension and
urgency are mostly reserved for the second half of the book. Instead, the
book opens with a lot of close observation of alien flora and fauna and
the untangling of subtle social dynamics among the Scythians.
There is also a visitor from earth, much to the distress of the Scythians.
Earth presence means the ships will not return and the colony may be cut
off from any sort of technological resupply. Despite speaking a common
language, that visitor is as mutually alien to the other groups as they
are to the native flora. Her life is fully integrated with aiyis, giving
her essentially godlike powers and the ability to turn off inconvenient
emotions and disregard anything she doesn't want to see. What she and the
Earth aiyis are doing on the planet is one of the early mysteries.
The dialogue in this book is truly excellent. Each characters has their
own voice, there are fascinating digressions on different words that lead
to tidbits of world-building, and some of the culture-specific idioms are
delightful.
"I'm making a mess of this. None of that matters. Let me fall out the
window and come in the door again. This is how my story ought to
start:"
The challenges for the characters in this story are slow but deep ones:
belonging and self-definition, the conflict between cultural tradition and
personal circumstance, and the sacrifices required to live with small
groups in situations where civil war is viscerally attractive. It has one
of the most comprehensive and fascinating treatments of transgender issues
that I've read in science fiction. Its commentary on current politics is
subtle and estranged in the way that science fiction does best, but still
pointed and satisfying. And, well, there are passages like this that I
absolutely adore:
"I wouldn't go that far. It could be they are right, the universe we
see exists because a mind like ours created it at least, a mind
enough like ours that we can say it wants one thing and not another,
and when it acts it does so with intent. That's as good an idea as
any. But it is certainly not plausible that such a being believes that
people everywhere should marry, or that men should never visit men, or
no one should become a jess. Look at what they have created. The
universe could have been nothing at all, or one atom of hydrogen
floating in a void, or a diamond crystal infinite in all directions,
if their mind cared for simplicity or tidiness. Instead we have stars
and planets and black holes and nebulas. It could have all been cold
and dead, but there is life. They could have made one species for each
world, or just a few, which could have stayed the same forever, but
instead we have millions and millions, all of which are changing every
moment, varying among themselves and boiling off in all directions.
Such a god is like an artist who fills up a library of sketchbooks
with their drawings of strange creatures, and when every scrap of
paper in the place is used up, goes back with a different color ink
and scribbles over them again. They are obsessed with variation they
gorge themselves with it and never grow full. Do you really think a
mind like that could want us all to live in the same way?"
I had one problem with this book, though, and for me it was a big one:
There is no ending. Reed effectively builds tension, gets me caring about
all of the characters, sets up several problems, starts down a path
towards resolution, and then the book just... ends.
Long-time readers of my reviews will know that I'm a denouement fanatic. I
want the scouring of the shire, I want the chapter set in the happily ever
after, I want the catharsis of an ending. This made me so grumpy!
To be clear, this is not sequel bait (at least so far as I can tell). I
can write a philosophical defense of the ending. The types of problems and
lives that Reed set up don't have clear endings; this is, to some extent,
the point. We muddle through, and then those who come after us muddle
through some more, and the cumulative effect is called human civilization.
And there is some denouement; Reed doesn't leave the reader at a
cliffhanger or anything that egregious.
But still, I wanted the happy ending, even though that was unrealistic for
the style of story this is, because I'm a happy ending reader. This is not
an ending sort of book; it's the sort of book where I get a sinking
feeling at the 95% mark because there aren't enough pages left for the
number of remaining unresolved problems. I've gotten less annoyed in the
days since I finished the book, and I can appreciate the thematic point
made by how the book ends, but I still feel like it's worth an advance
warning if you're a reader like I am.
I would be delighted by a sequel, but it didn't feel like that was the
intent.
Apart from that, this was both excellent and rather unlike a lot of
current science fiction. I think the closest comparison I can make among
recent novels I've read is Sue Burke's Semiosis. What We Are Seeking has a similar sort of
world-building, but I liked these characters so much more. It felt like a
classic literary science fiction novel, but very much written in 2026.
Highly recommended, just beware of the lack of closure.
Content notes: Sexism, homophobia, stomach illness, and some religious
abuse.
Rating: 8 out of 10
A new maintenance release 0.4.27 of RProtoBuf
arrived on CRAN today. RProtoBuf
provides R with bindings for the
Google Protocol Buffers
( ProtoBuf ) data encoding and serialization library used and
released by Google, and deployed very widely in numerous projects as a
language and operating-system agnostic protocol. The new release is also
already as a binary via r2u.
This release adjusts to a change upstream. Luca Billi noticed that upstream
removed some fields from FieldDescriptor, filed and issue
and followed up with a spotless PR. No other changes.
The following section from the NEWS.Rd file has all details and
links.
Changes in
RProtoBuf version 0.4.27 (2026-04-26)
Adjust to FieldDescriptor API changes in ProtoBuf 3.4
(Luca Billi in #114
fixing #113)
The SpacemiT K1 is a rather
interesting RISC-V SoC, found for instance on boards like the Banana Pi
BPI-F3 board. It's one
of those platforms that looked promising on paper, but took a bit of time
before things really started to move upstream. Things have clearly accelerated
over the last few months.
Linux 7.0 brings, among other things PCIe support, making the board quite
capable as a development board. SD card,
CPU thermal sensor
and cpufreq
support are already in the pipe.
Unfortunately the situation is less advanced on the firmware side. There is
only very basic support
for the SpacemiT K1 in U-Boot for the second stage,
and initial SPL support has been
posted on the
mailing list, but has not yet been merged. In practice, this means you still
have to rely on the vendor U-Boot,
which is based on the rather old 2022.10 release.
On the other hand, OpenSBI
does have upstream support for the SpacemiT K1, however it is not compatible
with the vendor U-Boot, mostly due to device tree differences.
This can be addressed by applying a few patches to the vendor U-Boot, which I have
published in a git tree in the
k1-bl-v2.2.y-opensbi branch (technically this can also be handled on the
OpenSBI side, but I prefer using a vanilla upstream OpenSBI version). The first
two patches update the configuration to get closer to the upstream U-Boot
defaults, and to enable some configuration options for the Milk-V Jupiter board,
which stores its firmware in SPI NOR flash, instead of eMMC for the Banana Pi
BPI-F3. The following patches update the device tree by adding extra compatible
entries to several devices, as expected by the upstream kernel and OpenSBI
(thanks to Troy Mitchell for the hint about the UART change) and update the CPU
riscv,isa properties. Finally an additional patch adds the
SpacemiT P1 PMIC to the device
tree, which is required for the OpenSBI reboot patchset I recently
posted
(this is currently done only for the Banana Pi BPI-F3 and Milk-V Jupiter boards, but
extending it to other boards should be straightforward).
Building this U-Boot version is as simple as running this command in the source directory:
makek1_defconfig&&make
On a Banana Pi BPI-F3 board, the resulting U-Boot can be flashed with:
Building upstream OpenSBI is also fairly simple, and can be done by running this command in the source directory:
makePLATFORM=generic
On a Banana Pi BPI-F3 board, the resulting OpenSBI can be flashed with:
ddif=fw_dynamic.itbof=/dev/mmcblk0p2
Note that the vendor U-Boot version is patched to install OpenSBI in a separate
partition instead of embedding, as the upstream U-Boot does. While this works
well on the Banana Pi BPI-F3, the corresponding partition in the Milk-V Jupiter
SPI NOR flash is too small for the upstream OpenSBI version, and can't be
easily resized without breaking compatibility. To address this, the branch
k1-bl-v2.2.y-opensbi-embedded contains an additional patch (a bit hackish I
admit) to somehow restore the upstream approach. The build process remains
simple, first build OpenSBI with the following command:
makePLATFORM=generic
Then build U-Boot, specifying the patch to the just built OpenSBI firmware:
This combined U-Boot/OpenSBI can also be used on a Banana Pi BPI-F3, using the
same flashing procedure as above, while skipping the OpenSBI part (although
running it won't cause any issue, it will simply be unused).
All of this is admittedly a bit hackish, but enabling the use of upstream
OpenSBI is already one step forward. Hopefully, in a few months, we will be
able to rely entirely on upstream U-Boot.
The Genocidal Healer is the eighth book in James White's medical
science fiction series about the Sector General hospital. As with the rest
of the series, detailed memory of the previous books is not required and
the books could be read out of order if you didn't mind spoilers.
I read this as part of the Orb General Practice omnibus.
Surgeon-Captain Lioren is a Tarlan doctor who was in charge of the medical
response to a newly-discovered civilization. The aliens were suffering
from an apparently universal plague and an ongoing vicious war waged
entirely through hand-to-hand combat, putting them on the edge of
extinction. Lioren rushed the distribution of a possible cure against the
advice of the doctors working on developing it, with catastrophic results.
As The Genocidal Healer opens, Lioren is insisting on a
court-martial in the hope of receiving the sentence it believes it
deserves and was denied: death.
(It pronouns are the convention in the Sector General series for all alien
races and formal discussions, because even someone prone to bouts of
gender essentialism such as White understood the need for avoiding gender
assumptions in a science fiction medical context.)
Predictably, both Sector General and the Monitor Corps that technically
runs the hospital are flatly unwilling to execute Lioren. Instead, he is
assigned as a new apprentice in the psychology department under the
legendary O'Mara, where he is ordered to investigate the psychological
fitness of a senior doctor named Seldal. This leads him to talk to
Seldal's patients, which in turn leads to a challenging set of ethical
dilemmas.
The first five chapters (and more than sixty pages) are the story of
Lioren's trial and a recounting of the events on Cromsag. The series is
full of medical and cultural puzzles like this, and usually I like them,
but I thought this one was less successful. We know the vague (and
horrible) outline of the ending in advance, and the massive simplification
and artificial universality that is required to make this puzzle work is
particularly blatant. A universally infectious disease is more of a
fiction plot than a believable biological concept, and the number of
failures of communication, analysis, and misunderstanding that have to
line up to create White's predetermined outcome were a bit much for me.
Once the story gets past that and into Lioren's psychological work, the
novel improves. Lioren is guilt-ridden and irrational, but also rather
arrogant about his guilt and his concepts of professional responsibility
in a way that I think mostly worked. Most of the novel consists of Lioren
slowly discovering that people like him and enjoy talking to him, much to
his bafflement. In that, it has the gentle kindness and sense of universal
basic decency that is characteristic of this series. There are, of course,
medical puzzles to solve, although this time they are primarily
psychological in nature. Various characters from previous books make an
appearance, but White re-explains their background in sufficient detail
that you don't need to remember (or have read) those previous books.
There are a lot of similarities between this book and the previous one,
Code Blue Emergency. Both feature
nonhuman viewpoint protagonists and amusing descriptions of human facial
expressions from an alien perspective. Both feature protagonists with
overly rigid ethical structures that partly clash with the generally human
policies of Sector General. The Genocidal Healer is a bit more
subtle and nuanced, although a lot of Lioren's psychological evaluation
rests on an ethical difference that I found somewhat unbelievable. This
book, though, tackles a subject the previous book did not: religion. The
treatment isn't horrible, but I have some complaints.
My primary issue is that Lioren, who starts as an atheist, does extensive
research into religion to help a patient and then starts making statements
summarizing the religions beliefs of the majority of known species that
are just... Christianity. As someone raised Christian, I recognized it
immediately as the sort of abstracted Christianity that Christians claim
is universal while completely ignoring the opinions of the adherents of
any other religion.
Key components of this majority galactic religious pattern, according to
Lioren, include an omnipotent and omnibenevolent creator god, a religious
figure who preaches forgiveness and mercy and is persecuted, and emphasis
on redemption. This simply is not some abstract universal religion. This
is just Christianity in disguise. Even in religions that have some of
those elements in their traditions, they do not get the same emphasis and
are not handled the way that Lioren describes them. I therefore found
Lioren's extended discussions of religion rather annoying, since he kept
claiming as relatively universal principles beliefs that are not even held
by the majority of religious adherents on Earth, let alone a wildly
varying collection of alien races with entirely different biology and
societal constructions. It caused a lot of problems for my suspension of
disbelief, on top of the annoyance at this repetition of, frankly,
Christian propaganda.
Lioren goes, from that research, into theodicy (the problem of evil). The
interesting part of this is White's earnest portrayal of a doctor's
approach to societal problems: a desire to find workarounds and patches
and fixes for anything that makes people unhappy, whether medical or
social. It makes sense, given the horrible biologic hands that some of the
aliens in this series have been dealt, that they would question the idea
of a benevolent god, so this philosophical digression is justified in that
sense. But you might guess that a mid-list science fiction author is not
going to say something new about one of the oldest problems in
Christianity, and indeed he does not. Lioren arrives at the standard
handwaving about the unknowability of divine intent, which I found tedious
to read but at least not fatal to the plot.
White, thankfully, doesn't take the religious material too far. The
characters recognize how sensitive of an issue religion is in a hospital,
Lioren never adopts religion fully, and the resolution of the plot is as
much biological as philosophical. White is going somewhere with the
introduction of religion, and although some of the path there annoyed me,
I think the destination worked. White was from Northern Ireland, and
therefore well aware of the drawbacks of religion, and he abhorred
violence (hence Sector General as a setting), so the reader is in better
hands with him than with most authors who might attempt this plot.
I think I know a bit too much about religion to be the best audience for
this entry in the series, and I'm not sure the introductory five chapters
quite worked. But as with all of the other books in the series, this kept
me turning the pages and I'm glad I read it. The Genocidal Healer
probably isn't worth seeking out unless you're reading the whole series,
but if you're enjoying the rest of the series, you'll probably like this
too.
Followed by The Galactic Gourmet.
Rating: 6 out of 10
The Debian LTS Team, funded by [Freexian s Debian LTS offering]
(https://www.freexian.com/lts/debian/), is pleased to report its activities for
March.
Activity summary
During the month of March, 20 contributors have been
paid to work on Debian LTS (links to individual
contributor reports are located below).
The team released 24 DLAs fixing 250 CVEs.
We also welcomed two new members: Lukas M rdian and
Emmanuel Arias to the team, who actually started to
contribute to the LTS project several months ago.
The team continued preparing security updates in its usual rhythm. Beyond the
updates targeting Debian 11 ( bullseye ), which is the current release under LTS,
the team also proposed updates for more recent releases (Debian 12 ( bookworm )
and Debian 13 ( trixie )), including Debian unstable. We highlight several notable security updates here below.
ansible (DLA 4502-1),
prepared by Lee Garret in collaboration with Jochen, fixing a vulnerability
that allows attackers to bypass unsafe content protections
asterisk (DLA 4515-1),
prepared by Lukas M rdian, fixing four CVEs that include possible privilege
escalations.
gimp (DLA 4500-1),
prepared by Thorsten, fixing four CVEs related to denial of service or
execution of arbitrary code.
gst-plugins-base1.0 and gst-plugins-ugly1.0
(DLA-4514-1,
DLA-4516-1,
respectively), both prepared by Utkarsh, addressing vulnerabilities that may
yield to arbitrary code execution.
imagemagick, released by Bastien Roucari s
(DLA 4497-1) fixing
multiple vulnerabilities that could lead to information leaks, bypass of
security policies, denial of service or arbitrary code execution.
libpng1.6 (DLA 4521-1),
prepared by Tobias Frost, fixing an arbitrary code execution vulnerability
linux: Ben Hutchings released
DLA 4498-1
and DLA 4499-1
for linux 5.10 and linux 6.1, respectively. Those updates especially address
the CrackArmor flaw.
ruby-rack (DLA 4505-1),
prepared by Utkarsh Gupta, addressing two vulnerabilities
strongswan (DLA 4512-1),
prepared by Thorsten Alteholz, fixing a Denial of Service vulnerability
roundcube (DLA 4517-1)
prepared by Guilhem Moulin, who discovered that one of the fixes provided by upstream was incomplete.
Contributions from outside the LTS Team:
As usual, the thunderbird update, released as DLA 4511-1, was prepared by its maintainer Christoph Goehre. Thanks a lot for his continuous contributions.
The LTS Team has also contributed with updates to the latest Debian releases:
Andreas Henriksson completed the uploads of glib2.0 for both trixie and bookworm
Drilling into an individual test gives you its full run history, a
duration sparkline, and per-run pass/fail status:
We are very excited to announce that Debian has been assigned seven contributors
to work under mentorship on a variety of
The eight release of the 
This is an amazing feature. Thanks to everyone involved in making it
happen!
I mentor several people in Debian, and have been repeatedly asked to offer an opportunity to ask questions on a live call. I have now started a recurring video call for exactly that, which I call Mentoring Mondays, and it is open for anyone aspiring to contribute to Debian, one of the oldest and most widely used Linux distributions.
Mentoring Mondays have already been happening for the past few Mondays, and this week we had a record 20 people on the call. During the calls so far we have had a demo of updating a package for a new upstream release using 
A departures board at Budapest Kelenfold station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
This is platform number 15 of Budapest Kelenfold station where we boarded our train. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Interior of our Budapest to Vienna train. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
This blue colored train was the one we took for our Budapest to Vienna journey. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
An BB train standing at a platform of Vienna train station. BB is the national carrier of Austria. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Wien Hauptbahnhof train station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
My public transport pass in Vienna.
Instead of AFC gates, Vienna has ticket validators as in the picture. You need to tap your ticket in the validator before boarding the subway. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Vienna subway. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Sch nbrunn Palace. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
A street near Sch nbrunn Palace. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Ro auer L nde subway station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Platform of the Ro auer L nde subway station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
The The Strudlhofstiege steps. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
A random street in Vienna.
Another street in Vienna.
A picture of Blue Orange caf . Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Trams in Vienna. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Punschkrapfen. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Esterhazyschnitten. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Departure boards in Vienna displaying information about the trains. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Platform and tracks at Wien Hauptbahnhof station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Interior of the train we took from Vienna to Budapest. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
This is the train we took for our return journey from Vienna to Budapest. It is standing on a platform in Budapest Kelenfold station. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Yesterday, I had to add support for running KVM virtual machines inside an LXC container. More as a reminder to myself, in case I ever have to do this again, here the simple recipe:
LXC Container Config Adjustment
Enable lxc.autodev and execute hook script to be executed after initial /dev creation (updated 20260428: 
The 
The Debian LTS Team, funded by [Freexian s Debian LTS offering]
(