(This is an updated version of an older post - the introduction remains the same, the technical details are different)
Linux draws a distinction between code running in kernel (kernel space) and applications running in userland (user space). This is enforced at the hardware level - in x86-speak1, kernel space code runs in ring 0 and user space code runs in ring 32. If you re running in ring 3 and you attempt to touch memory that s only accessible in ring 0, the hardware will raise a fault. No matter how privileged your ring 3 code, you don t get to touch ring 0.
Kind of. In theory. Traditionally this wasn t well enforced. At the most basic level, since root can load kernel modules, you could just build a kernel module that performed any kernel modifications you wanted and then have root load it. Technically user space code wasn t modifying kernel space code, but the difference was pretty semantic rather than useful. But it got worse - root could also map memory ranges belonging to PCI devices3, and if the device could perform DMA you could just ask the device to overwrite bits of the kernel4. Or root could modify special CPU registers ( Model Specific Registers , or MSRs) that alter CPU behaviour via the /dev/msr interface, and compromise the kernel boundary that way.
It turns out that there were a number of ways root was effectively equivalent to ring 0, and the boundary was more about reliability (ie, a process running as root that ends up misbehaving should still only be able to crash itself rather than taking down the kernel with it) than security. After all, if you were root you could just replace the on-disk kernel with a backdoored one and reboot. Going deeper, you could replace the bootloader with one that automatically injected backdoors into a legitimate kernel image. We didn t have any way to prevent this sort of thing, so attempting to harden the root/kernel boundary wasn t especially interesting.
In 2012 Microsoft started requiring vendors ship systems with UEFI Secure Boot, a firmware feature that allowed5 systems to refuse to boot anything without an appropriate signature. This not only enabled the creation of a system that drew a strong boundary between root and kernel, it arguably required one - what s the point of restricting what the firmware will stick in ring 0 if root can just throw more code in there afterwards? What ended up as the Lockdown Linux Security Module provides the tooling for this, blocking userspace interfaces that can be used to modify the kernel and enforcing that any modules have a trusted signature.
But that comes at something of a cost. Most of the features that Lockdown blocks are fairly niche, so the direct impact of having it enabled is small. Except that it also blocks hibernation6, and it turns out some people were using that. The obvious question is what does hibernation have to do with keeping root out of kernel space , and the answer is a little convoluted and is tied into how Linux implements hibernation. Basically, Linux saves system state into the swap partition and modifies the header to indicate that there s a hibernation image there instead of swap. On the next boot, the kernel sees the header indicating that it s a hibernation image, copies the contents of the swap partition back into RAM, and then jumps back into the old kernel code. What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot. The kernel would happily resume into the attacker s image, giving the attacker control over what gets copied back into kernel space.
This is annoying, because normally when we think about attacks on swap we mitigate it by requiring an encrypted swap partition. But in this case, our attacker is root, and so already has access to the plaintext version of the swap partition. Disk encryption doesn t save us here. We need some way to verify that the hibernation image was written out by the kernel, not by root. And thankfully we have some tools for that.
Trusted Platform Modules (TPMs) are cryptographic coprocessors7 capable of doing things like generating encryption keys and then encrypting things with them. You can ask a TPM to encrypt something with a key that s tied to that specific TPM - the OS has no access to the decryption key, and nor does any other TPM. So we can have the kernel generate an encryption key, encrypt part of the hibernation image with it, and then have the TPM encrypt it. We store the encrypted copy of the key in the hibernation image as well. On resume, the kernel reads the encrypted copy of the key, passes it to the TPM, gets the decrypted copy back and is able to verify the hibernation image.
That s great! Except root can do exactly the same thing. This tells us the hibernation image was generated on this machine, but doesn t tell us that it was done by the kernel. We need some way to be able to differentiate between keys that were generated in kernel and ones that were generated in userland. TPMs have the concept of localities (effectively privilege levels) that would be perfect for this. Userland is only able to access locality 0, so the kernel could simply use locality 1 to encrypt the key. Unfortunately, localities are typically only available on systems that implement a Dynamic Root of Trust Measurement like Intel s TXT, and most consumer systems have no support for this. So, we need another approach.
TPMs have a set of Platform Configuration Registers (PCRs), intended for keeping a record of system state. The OS isn t able to modify the PCRs directly. Instead, the OS provides a cryptographic hash of some material to the TPM. The TPM takes the existing PCR value, appends the new hash to that, and then stores the hash of the combination in the PCR - a process called extension . This means that the new value of the TPM depends not only on the value of the new data, it depends on the previous value of the PCR - and, in turn, that previous value depended on its previous value, and so on. The only way to get to a specific PCR value is to either (a) break the hash algorithm, or (b) perform exactly the same sequence of writes. On system reset the PCRs go back to a known value, and the entire process starts again.
Some PCRs are different. PCR 23, for example, can be reset back to its original value without resetting the system. We can make use of that. The first thing we need to do is to prevent userland from being able to reset or extend PCR 23 itself. All TPM accesses go through the kernel, so this is a simple matter of parsing the write before it s sent to the TPM and returning an error if it s a sensitive command that would touch PCR 23. We now know that any change in PCR 23 s state will be restricted to the kernel.
When we encrypt material with the TPM, we can ask it to record the PCR state. This is given back to us as metadata accompanying the encrypted secret. Along with the metadata is an additional signature created by the TPM, which can be used to prove that the metadata is both legitimate and associated with this specific encrypted data. In our case, that means we know what the value of PCR 23 was when we encrypted the key. That means that if we simply extend PCR 23 with a known value in-kernel before encrypting our key, we can look at the value of PCR 23 in the metadata. If it matches, the key was encrypted by the kernel - userland can create its own key, but it has no way to extend PCR 23 to the appropriate value first. We now know that the key was generated by the kernel.
Unfortunately it turns out that some people actually make use of PCR 23, and
restricting it to the kernel makes them sad. There are other resettable PCRs, but only in non-0 localities, so (a) we can t reset them on most systems and (b) we ll just find someone who uses them anyway and run into the same problem. We need a different approach.
Thankfully TPMs have a small chunk of non-volatile RAM that can be used for storing things, and by storing I mean they can be used in a range of different ways. One of these is effectively as additional PCRs. These values can be configured such that they work the same way as PCRs, with the only way to modify them being to append a new hash to their existing value and update the new value to the hash of that merged value. We can allocate one of these for in-kernel use and reject any access from userspace, and also there are officially allocated ranges (so people shouldn t be using random values) and the namespace is large enough anyway that w eshouldn t collide with anyone, so we can carve one of those out and use it for this purpose.
Unfortunately, though, these NV indexes aren t included in the creation data we get when we create a key, so we need another approach. TPMs have the concept of sessions, a series of commands executed in sequence. A flag allows these sessions to be audited , with the TPM keeping a running track of the hash of the commands executed and the results returned. At the end of the session you can ask for a signed copy of this hash, and if you ve kept a log of all the commands then you can verify that they match that signed hash and know that this log represents a real communication with the TPM. If we read the NV index and generate the key inside the same session, we can verify that the key we re looking at was created while the NV index had a specific value, and if only the kernel can set that value then we know that the key was generated by the kernel.
Or, well, can we? Only new kernels would impose the restriction on modifying that NV index. An attacker could boot an old kernel, generate a key there in userland, sign a hibernation image with it, and then reboot into a new kernel. The new kernel would see a valid signature with a valid NV index associated with it and have no way to know it was generated from userland rather than the kernel. We need to be able to tell the difference between kernels that implement this feature and ones that don t, and we need to do that without being able to go back in time to change old kernel behaviour. We can extend a PCR to indicate we implement the new functionality, but so can an attacker running an old kernel.
The normal approach to determining whether an event occurred in a specific phase of the boot process is to cap the PCRs - extend them with a known value that indicates a transition between stages of the boot process. Any events that occur before the cap event must have occurred in the previous stage of boot, and since the final PCR value depends on the order of measurements and not just the contents of those measurements, if a PCR is capped before userland runs, userland can t fake the same PCR value afterwards. If Linux capped the PCRs before userland started running, we d be able to place a measurement there before the cap occurred and then prove that that extension occurred before userland had the opportunity to interfere. We could simply place a statement that the kernel supported the NV index restrictions there, and we d be fine.
Unfortunately Linux doesn t currently do this, and adding support for doing so doesn t fix the problem - if an attacker boots a kernel that doesn t cap a PCR, they can just cap it themselves from userland. So, we re faced with the same problem: booting an older kernel allows the system to be placed in an identical state to the current kernel, and a fake hibernation image can be written out. Solving this requires a PCR that was being modified after kernel code was running, but before userland was started, even with existing kernels.
Thankfully, there is one! PCR 5 is defined as containing measurements related to boot management configuration and data. One of the measurements it contains is the result of the UEFI ExitBootServices() call. ExitBootServices() is called at the transition from the UEFI boot environment to the running OS, and the kernel contains code that executes before it. So, if we measure an assertion regarding whether or not we support restricted access to NV indexes into PCR 5 before we call ExitBootServices(), this will prevent userspace from spoofing us (because userspace will only be able to extend PCR 5 after the firmware extended PCR 5 in response to ExitBootServices() being called). Obviously this depends on the firmware actually performing the PCR 5 extension when ExitBootServices() is called, but if firmware s out of spec then I don t think there s any real expectation of it being secure enough for any of this to buy you anything anyway.
That s what this patchset does. Review feedback so far seems positive, although James Bottomley suggested a design improvement. My approach of using an NV index as a PCR and generating a signing key made sense as a consequence of my original approach involving PCR 23, which had been to use the key creation data and not use audit sessions at all. But the goal isn t to use a key - it s to prove that hibernation occurred in-kernel, and while signing is one way of doing that, there are others. His suggestion is to simply record the hash of the hibernation image into the NV index and then read that back as part of the audit session. On resume we verify the audit session log is legitimate, read the hibernation image, and compare the hash of the hibernation image against the hash in the log. If it matches, and if the PCR 5 value matches, we know the audit session happened in kernel and that the hibernation image hasn t been modified.
It still seems like we re missing something, though. If we re not storing a key anywhere, how do we verify the audit session? To explain this we re going to need to go into some details about how TPM keys work in the first place. TPMs can produce a special kind of key called an Attestation Key, or AK. Attestation keys are used to sign attestation statements from the TPM, such as PCR quotes or audit logs. We need a separate key type for this in order to prove that the signature was generated as part of an attestation - normal TPM signing keys are fundamentally designed to sign arbitrary material, and so can be used by userland to sign something that looks identical to an attestation record. By being able to distinguish the types of key the TPM uses, we can prove that a signature was generated using an AK, and so know that it s a real TPM attestation (because nothing other than the TPM can sign stuff with an AK).
But even beyond this distinction, TPMs have different key types. Ordinary keys are generated using an RNG and will be unique. Primary keys are generated using a seed that is used as an input into a key derivation function. For a given TPM, using the same seed to generate the same type of primary key will always generate the same primary key8. We can have the kernel deterministically generate an AK during suspend in order to sign the audit log, and then generate the same key again on resume to validate it. This means we don t need any other form of trusted storage for the AK - the TPM already provides that functionality.
This is all rather complicated but I ve been thinking about this for some time now and I haven t come up with a cleaner solution. The only real open issue is the degree to which machines actually perform the PCR 5 extension. If it turns out there s a bunch that don t we ll need to come up with some alternative approach to identifying whether the kernel supports this functionality, but the design is such that that should be invisible to userspace so adding alternatives later shouldn t be an issue. Filtering accesses to the NV index is also not super clean, and depends on there not being alternative mechanisms to get at the TPM by sending raw commands. Again, this is intended to be opaque to userland and can be improved if we come up with something better later on (such as a secure way to pass a secret to the kernel on boot that can be used as an auth value for acess to the NV index).
Anyway. Time to go and fix the next thing.
Other architectures use different terminology here, such as supervisor and user mode, but it s broadly equivalent
In theory rings 1 and 2 would allow you to run drivers with privileges somewhere between full kernel access and userland applications, but in reality we just don t talk about them in polite company
This is how graphics worked in Linux before kernel modesetting turned up. XFree86 would just map your GPU s registers into userland and poke them directly. This was not a huge win for stability
IOMMUs can help you here, by restricting the memory PCI devices can DMA to or from. The kernel then gets to allocate ranges for device buffers and configure the IOMMU such that the device can t DMA to anything else. Except that region of memory may still contain sensitive material such as function pointers, and attacks like this can still cause you problems as a result.
This describes why I m using allowed rather than required here
Saving the system state to disk and powering down the platform entirely - significantly slower than suspending the system while keeping state in RAM, but also resilient against the system losing power.
With some handwaving around coprocessor . TPMs can t be part of the OS or the system firmware, but they don t technically need to be an independent component. Intel have a TPM implementation that runs on the Management Engine, a separate processor built into the motherboard chipset. AMD have one that runs on the Platform Security Processor, a small ARM core built into their CPU. Various ARM implementations run a TPM in Trustzone, a special CPU mode that (in theory) is able to access resources that are entirely blocked off from anything running in the OS, kernel or otherwise.
Unless the TPM is cleared, in which case it ll generate a new internal seed and now the keys will be different to before the clear
A week ago, release
0.0.5 of the RcppFastAD package
went to CRAN, and we
noted that it provided a stop-gap measure against a gnarly segfault
with g++-16 under heavier optimization / inlining. We are
happy to now announce that a new and fixed version 0.0.6 of RcppFastAD is now
on CRAN, and has been built for
r2u as well as at r-universe.
RcppFastAD
wraps the FastAD
header-only C++ library by James which provides a C++
implementation of both forward and reverse mode of automatic
differentiation. It offers an easy-to-use header library that is both
lightweight and performant. With a little of bit of Rcpp glue, it is also easy to use from R
in simple C++ applications.
This release takes advantage of some large-language model inference
access I now get via Debian. The Deepseek v4 flash-0731 model, driven in
a container via the pi.dev harness, took just about no time finding a
small workaround for the issue described
last week where we could see segfaults under heavier optimization
and inlining. The fix was to prohibit inlining the local
bind() reimplementation. We have also sent this upstream as
a patch. It is nice to have an option of querying something a little
more powerful than the local models I experimented with before. We
suppress more compiler warnings in local builds via another option, and
did some standard maintenance.
The NEWS file for this release follows.
Changes in version 0.0.6
(2026-10-01)
The expression-template view rebinding is protected against
g++ -O3 (which led to wrong Eigen::Map
dimensions, an Eigen::Map resize assertion, and a
segfault.
The bind() helpers are marked non-inline and are
also protected from operating on a nullptr.
Both items co-written with DeepSeek V4 Flash, and have been sent
upstream in a PR.
Suppress another compiler warning when local build
detected.
A new release 0.0.5 of the RcppFastAD package
is now on CRAN, has been built
for r2u, and updated
at r-universe.
This comes (to the day) two years after the preceding 0.0.4 release.
RcppFastAD
wraps the FastAD
header-only C++ library by James which provides a C++
implementation of both forward and reverse mode of automatic
differentiation. It offers an easy-to-use header library that is both
lightweight and performant. With a little of bit of Rcpp glue, it is also easy to use from R
in simple C++ applications. This release updates the continuous
integration setup as one does, adds a local configuration helper to
quieten compilation (described also in this
blog post). It also adds a defensive setting for g++:
Under recent g++ versions and optimisation at least the -O3
level, segfaults are seen as something is not quite right with
(temporary) views of Eigen objects in code generated by this versions.
Others are fine, as is clang++. We have not gotten to the
bottom of it, but setting -g0 seems to ensure that builds
generally work.
The NEWS file for this release follows.
Changes in version 0.0.5
(2026-09-24)
Several routine updates to continuous integration have been
made
Local builds (where a .git/ directory is seen) now
append silencing compiler option that CRAN would object to
Given recent issues with g++ under optimization,
debugging is turned off by default.
Welcome to the August 2026 report from the Reproducible Builds project!
In our reports, we try to outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not.
In this month s report, we cover:
New updated SBOM specification from CISA.gov
CISA, the Cybersecurity and Infrastructure Security Agency of the U.S. government published some the joint guidance entitled Minimum Elements for a Software Bill of Materials (SBOM), which updates and supersedes the baseline 2021 version covered in previous editions of these reports.
Whilst the PDF is worth skimming, the interesting changes include that the specification now mandates standard cryptographic hashes: unlike earlier standards that allowed hash omission or manifest-only parsing, hashes must be computed from the output. This is is important for reproducible builds, as it ensures the recording of the metadata required to demonstrate the shipped software matches the build output precisely where applicable. In addition, where the top-level only dependency limitation that was present in the 2021 version has been removed in favour of complete coverage with no minimum depth. That is, SBOMs are expected to reflect all linked libraries, vendored dependencies and other build-time inclusions.
The basic idea behind bootstrappable builds is to create a system that can be built without relying on pre-built artifacts. Can we go from zero to the modern day without having to just assume the existence of these already-built-for-us artifacts? The classic recipe for yogurt requires some yogurt to start the process, which is like how we normally build a C compiler today we start with an existing C compiler binary. You might think about making sourdough bread with your grandmother s starter brought over from the old country; we re basically making C compilers with Dennis Ritchie s starter carried over from Bell Labs .
The reason I like the idea of making reproducible builds work is that I think it can be done in such a way as to not require any work on the part of the producer of a distribution (which is a technical term for sdists or wheels, i.e., the people who upload stuff to PyPI), and thus make reproducible builds very low-friction for people to opt into supporting. []
Brett goes on to outline What s missing from the specs and how reproducibility might be visible on PyPI to consumers:
Assuming all of this comes to pass and we record the where the source code is that went into a distribution and the software used to make the distribution, how do we make it useful to people? Does every person who cares about having a secure supply chain have to rebuild everything they use themselves? Is there some way for even people who don t care about this stuff to benefit? []
Distribution work
In Debian this month, 23 reviews of Debian packages were added, 28 were updated and 27 were removed this month adding to our knowledge about identified issues. A number of issue types have been updated as well, such as the addition of a new toolchain issue related to python-traitlets [], and the note for an existing issue related to texi2html was updated as well [].
Lastly, Bernhard M. Wiedemann posted another openSUSEmonthly update for their reproducibility work there.
Unreproducible builds under EROFS filesystem fixed
Martin Pitt reported on Fosstodon that they had identified an issue where the mkfs ( make filesystem ) command for the EROFS (Enhanced Read-Only File System) subsystem of the Linux kernel did not have sorted extended file attributes, leading to reproducible builds.
Thankfully, Martin also reported that they had fixed this in a commit to the kernel which order[s] each inode s xattrs by name so that images stay reproducible . []
Tool and documentation development
diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including preparing and uploading versions 327, 328 and 329 to Debian. In particular, he ensured that diffoscope did not require python3-guestfs in the autopkgtests on 32-bit architectures in order to fix Debian bug (#1144372) []. Colin Watson made an additional change, handling a potentially missing openssh-client package when running the autopkgtests [], and Jochen Sprickerhof made a similar change to cope with missing cpio and qemu-img functionality [] whilst also updating the XML comparator to be considered when comparing SVG images [].
Yet again, there were a number of improvements made to our website this month as well. For example:
Chris Lamb added draft for a Gothenburg summit-related news article. [][]
Lastly, a large number of commits were pushed comprising an interview with Reproducible Builds developer Jochen Sprickerhof to be published within the next week. [][][][][][][]
Six new scholarly papers
Jens Dietrich, Spencer Sun, Tim W. White and Behnaz Hassanshahi (the result of a collaboration between Victoria University of Wellington and Oracle Australia published a paper this month entitled No Snake Oil: Verifying Python Package Builds. Drawing on the metaphor of snake oil , that is, a fake or ineffective medicine or solution sold with exaggerated claims of curing or fixing everything, the authors write that
Two tools that are designed to automate [PyPI] rebuilds and run them at scale are macaron and oss-rebuild. We study 12,180 popular releases from PyPI and find that the byte-for-byte equivalence rate is generally low. We analyse the reasons why they produce different wheels, and find that equivalence between the original and rebuilt wheels can often still be established, preserving most of the guarantees users expect from rebuildable releases. We present and evaluate daleq4py, a tool to establish the equivalence of Python wheels through the kernel of a normalisation function that is based on provenance-preserving datalog rules. Experimental results show that daleq4py substantially expands the set of rebuilds that can be accepted as equivalent.
pose a persistent threat to opensource software. Known attempts to inject such backdoors into widely used projects through malicious commits, tampered release packages, or compromised third-party dependencies, were stopped only by luck and manual review. Existing Continuous Integration (CI) pipelines cannot detect these attacks, and downstream binary analysis tools require substantial manual effort. In this work, we present Lily, an automated approach that strengthens open-source development and release processes against backdoor injection. Lily integrates a backdoor detection mechanism into (1) CI pipelines to block malicious commits, and (2) release vetting workflows to prevent tampered releases or compromised dependencies from entering large ecosystems, such as Linux distributions.
The full PDF can be read online.
Ranindya Paramitha and Laurie Williams of North Carolina State University along with Christian K stner of Carnegie Mellon University published a paper this month with the title of The Software Supply Chain as a Market for Lemons: A Multivocal Review of Trust Signal Collapse. (A lemon in American English, is a vehicle that turns out to have several manufacturing defects .) Their abstract is as follows:
Practitioners evaluating open-source dependencies rely on cheap trust signals, e.g., stars, download counts, and contributor activity, as substitutes for direct code inspection, assuming those signals reflect genuine trustworthiness. Prior work has documented individual signal gaming, but the landscape of collapses across all dependency-adoption signals, as well as the ecosystem s response, remains unexplored. The goal of this study is to aid software practitioners in understanding the reliability of dependency adoption trust signals, such as download counts and contributor activity, by conducting a multivocal review of 252 Google Search sources and 870 Reddit threads.
Worryingly, after their review, the authors conclude that cheap trust signals collapse under three simultaneous forces: adversarial manipulation, gaming techniques indistinguishable from legitimate behavior, and non-adversarial AI-driven inflation.
The full PDF of the paper is available online.
Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli and Th o Zimmermann published a paper this month on Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation:
Ken Thompson s trusting-trust attack, in which a compromised compiler backdoors the programs it builds and reproduces the backdoor in subsequent rebuilds of itself, is widely regarded as a threat specific to compilers. We show that it is not. We construct a complete trusting-trust attack around GNU strip, an ordinary build utility that neither inspects nor generates source code, using only manipulations of finished ELF files.
Scarily, in the authors example, a single tampered strip in the binary seed implants a payload that propagates from one generation of strip to the next and survives into the final standard environment after the seed leaves the dependency closure [ ] without failures and backdoors .
A full PDF of the paper is available for download online.
Mehdi Keshanimm, Amirhossein Rahmati, Mohammad Hossein Aref and Abbas Heydarnoori published a paper that is currently under review at Emperical Software Engineering titled AROMA+: A Study of Factors Affecting Reproducible Builds in the Maven Ecosystem. (Maven is a/the build automation tool used for Java projects.) In their paper, the authors note that
[ ] reusing external software in a project presents a security risk when the source of the component is unknown or the consistency of a component cannot be verified. The SolarWinds attack serves as a popular example in which the injection of malicious code into a library affected thousands of customers and caused a loss of billions of dollars. [ ] Our research aims to support [reproducibility] efforts in the Maven ecosystem through automation. We investigate the feasibility of automatically finding the source code of a library from its Maven release and recovering information about the original release environment. Our tool, AROMA+, can obtain this critical information from the artifact and the source repository through several heuristics and we use the results for reproduction attempts of packages on Maven Central.
[A]rtifact verification requires more than deterministic builds: a verifier must also recover the source state, build environment, dependencies, and build instructions that produced the artifact. Decentralized-build ecosystems make this difficult because artifacts are produced through heterogeneous tools, maintainer-controlled workflows, and fragmented metadata. As a result, it remains unclear how often artifacts in these ecosystems can be independently verified. This paper studies artifact verifiability across four popular decentralized-build package ecosystems. We define an independent verifier model that relies only on registry-derivable metadata and an artifact comparison model with tiered equivalence levels. We implement these models in an Artifact Verification Pipeline and use it to measure artifact verifiability across the target ecosystems.
The authors conclude that beyond build determinism, verifiability is limited by missing source and build metadata, implicit release transformations, and unconventional build practices .
A PDF of their paper can be reviewed online.
Patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where applicable or possible. This month, we wrote a large number of such patches, including:
I have just tried CoMaps, a free mapping program released under the Apache license [1]. I have tried it on Android on a Pixel 6a but it also runs on Linux so I ll try it on a PinePhone or similar at some convenient time. On Android it is in the F-Droid repository among others and for Linux there s a Flatpak package.
The data it uses is from Open Street Map project [2] which has extensive and accurate coverage of every place I ve looked at (Australia and a few other first-world countries). The first thing it does after being installed is start downloading the world data set from Open Street Map and prompt to download the data for the detected region (Melbourne in my case).
The UI is decent and allows most of the features that I am used to using in Google Maps. The quality of directions seems good, I ve only tested it with one journey so far which was a 50 minute drive across the city and it gave a set of directions that Google Maps often gives.
It gives spoken directions which is an important feature but sometimes the way the directions are presented is confusing. When turning off a freeway it didn t give a spoken direction to do that, it gave a direction to turn right which was AFTER leaving the freeway, fortunately the map was clearly displayed.
In terms of use practices of this program the main difference I recommend is checking which off ramp to use from a freeway before entering the freeway. With Google Maps you can rely on it giving clear directions in that case.
I recommend this program without reservation. It can do everything that Google Maps does apart from detecting traffic jams because there s no way of detecting traffic without spying on users. It is designed to preserve user privacy and works well in that regard.
After ranting and railing about LLMs or "AI" as the optimists (or
accelerationists?) call it, I figured it might be important to
be a little more honest about my use of LLMs and how I think about it
more practically in the world.
The Debian vote context
This is not a coming out. I am not using LLMs on a daily basis, and
this blog is, again, written out of my cold dead hands in a dying
world, with over-engineered hardware and (to a certain extent, hi
Emacs!) software, powered by 100% green energy built on stolen land.
There is a vote going on in Debian. If you're unfamiliar with it,
you can catch up at LWN. So far I've essentially said "LLM is
bad" which is not a very balanced or useful opinion. Obviously, people
are using LLMs, sometimes unknowing or unwillingly, and we need to
take that into account. Furthermore, there has been many different
blog posts on Debian planet about this. Some that I found
balanced, good summaries, even if I didn't fully agreewith
them, at least some did the basic civil service of being
short. But others were just not only Wrong but also so long
that I couldn't finish that I just had to write something.1
This is not an explanation of the ballots, nor how I will vote. This
vote is Debian's failure of framing that debate in a reasonable way:
we have 8 options on the ballot with many duplicates. We have failed
to do the hard work of summarizing and aggregating options into a
meaningful set. I doubt the final vote will represent a readable
position we can rally around.
I have not read the twomonths of debates on the topic
either. Normally, before voting, I take a cursory look at the debate
to see points of view I might have missed. But in this case, it will
just make me sad, add noise, and I'm already pretty sure on where I
stand on this.
So let me describe how I use LLMs and how I think they fit in our
work, as computer engineers and hobbyists.
My LLM use
Debian Packaging
An astute reader has pointed out that I maintain a package in
Debian made to use Anthropic. It's actually multiple packages:
As I previously explained in response, I am not entirely
comfortable with this work: it's a compromise. In fact, I first
uploaded llm to the contrib section of Debian, where we keep
software that depends on other non-free software, but I was told that,
since yt-dlp was in main, llm belonged there as well.
So I moved it to main, alongside similarly controversial tools
like llama.cpp or the python-openai library.
OpenAI and Anthropic usage
An important part of my work is technology watch. I keep tabs on
thousands of (new and old) software projects, follow news, and
generally try to keep my skills up to date. It's a pretty impossible
race, especially as I grow older, but I still think I'm doing the
right choices in my job.
Testing large language models is part of that work. At first, I was
using ChatGPT's web interface, but it was annoying to copy-paste
things into a browser, so I looked for different interfaces.
For a while I tried gptel, a "simple, extensible LLM client for
Emacs" but I found it kind of terrifying. Giving a LLM control over an
Emacs buffer seems like a security nightmare, so I stopped doing
that.
So I use the llm command-line tool to talk to Anthropic's API. I
started that in the summer of 2025, when I bought 20$USD of API
credits. Before that, I paid for a ChatGPT subscription and then
OpenAI credits, which expired and sent me over to Anthropic, which
seemed then to have better ethics.
As it turns out, Anthropic is also happy to work for the US military
(which is a big red line for me). Anthropic also won't let you talk
about the genocide in Gaza, it is destroying physical books,
and is blackmailing us to use their product for security
coverage.
Needless to say, Anthropic and "Claude" are not my friends, but they
seem like the lesser evil in current "frontier models". So I have
renewed, a couple of weeks ago, another 20$USD of API credits with
Anthropic.
Actual prompts and responses
So what does 20$ give you at Anthropic anyways? What am I using LLMs
for and how?
The neat thing with llm is that everything is logged in a sqlite
database, so there are some answers that are easy to get:
> llm logs status
Logging is ON for all prompts
Found log database at /home/anarcat/.config/io.datasette.llm/logs.db
Number of threads logged: 7
Number of turns logged: 12
Number of legacy conversations: 543
Number of legacy responses: 970
Database file size: 9.61MB
That is 10MB of logs, with about a thousand prompts.
My logs go back to 2024-03-07, a little over two years ago, and
include a mix of Anthropic and OpenAI responses. I used it more in
2024 than 2025, and if the trend continues, I will have used it less
in 2026 again:
It looks like about 10 prompts per month right now, down from a peak
of about 60 per month in 2024. It's pretty difficult to analyze those
actual logs to get more patterns and I won't run the prompts through a
model again to process them.
How I'm using models now
At first, I was using it partly for benchmarking model's capabilities,
like Simon Willison does with his pelicans, clearly not trusting
its output. But I was impressed by the capacities of the Claude Opus
4.5 model when it wrote this script in January. Impressed, but
also scared: it's the first time I felt I could delegate the entirety
of my programming to a model. Just run the code, if it works, it
works, right?
So what do I use it now? As an example, here are the 10 last prompts
in my history:
there is now Claude 5, and a fable model, maybe you know about it?
impress me
not impressive, i already know all of this
chat
in postfix, i have a 300k mailing that happens regularly here. normally, it delivers within about...
is there a way i could have drained the maildrop queue faster without removing the milter?
the problem was that rspamd was timing out on the FUZZY_CALLBACK check. how do i disable that?
how do i disable all spam checks? i just want rspamd to add dkim signatures
how do the default_destination_concurrency_limit and initial_destination_concurrency settings int...
mic check
The first one was me trying to confirm which model I am using, which
is not always obvious when going through the whole llm stack I've
been using. The following two are an attempt at seeing what the model
is capable of and I was "not impressed", to which Claude answered that
I have a "high bar", which, fair enough.
The chat is me failing to use a command line, which shows that
perhaps I need to readjust that "high bar", again.
The next five are a rather embarrassing debacle in a large Postfix
mailing that went sideways, and where I couldn't find an actual
Postfix expert of my level to help. The fabled Claude Fable 5 answered
rather correctly, but dangerously, that I could empty the queue by
disabling the non_smtpd_milters. What Fable (and myself) did not
realize is that the milter was also adding DKIM signatures, so while the
mailing was expedited, it was done without those precious signatures,
which got us promptly blocked at Gmail. We have recovered since, and,
thanks to the model and reading the Postfix manual for the
hundredth time, that pickup(8) is single-threaded and that we
needed to review the architecture of that mailing (and our spam
filters) a bit. Many tickets ensued.
The last one is a test I did to make sure my last uploads of
llm-anthropic and its dependency worked correctly.
Note that the above excludes 5 questions I asked Anthropic while
writing this article, where I asked for synonyms and "what nanometer
scale are arduino processors built from? how is an arduino CPU
printed?", a question which Wikipedia furiously evades providing a
good answer.
Those prompts are pretty typical of my LLM use: I'm testing the models
to see if they work at all, but also, out of desperation, I fire off a
prompt after I fire off questions to colleagues or search engines (in
that order). It's often weird edge cases like the Prometheus query
language, Python's matplotlib, LaTeX, Elisp, optimizations, and so on.
I use models for translation a lot. Being fully bilingual, it is
common for me to think of a word in French or English and fail to find
exactly the right word for that in the other language. Models help
with that, and are also useful to find synonyms. Those are low-token
uses that seem pretty innocuous to me, but I realize the irony of this
after writing about the tower of
Babel.
What I am not using models for
I am not using models to write prose.
I am not using models to read prose. If it's generated with LLMs, I
stop reading.
I am not using models to write code, with the exception of that single
Python script above.
I am generally not using models to review code, with exceptions. If
I get stuck on a hard problem, I might feed a piece of code to the
model. I repeatedly fed asncounter into Claude to try to fix a
performance regression I had introduced. It found micro-optimizations
that taught me a thing or two about Python's internal implementations,
but overall, it was mostly a waste of time. This was in June 2025, so
perhaps now models would fare better. I have not tried again.
I am not using LLMs to do Debian packaging. When I can, I manually
review the diffs of packages I upload into Debian, still, by hand.
I do this for the reasons outlined in The Four Horsemen of the LLM
Apocalypse, because I refuse to be
complicit in the:
aggressive and illegal scraping of the servers I steward
world-wide computer hardware shortage (making it, by the way,
nearly impossible to run presumably clean local models) and the
attack on our job conditions (also discussed in
The people vs the AI overlords)
death of copyright and free software
complication and enshifitication of everything, and the
destruction of our communities
the imperialist Nerd Reich that wants to take over the world
Like I reluctantly use Intel computers, I do fire off a prompt. But
I still hold on to the dream that we can build communities of
practice that hold human knowledge collectively and not offload
that as a utility to some megalomaniac billionaire.
Their LLM use I am forced into
So that's me. Clearly, I'm going against the grain here. Everywhere I
look, I see LLM-generated code and projects. Slop and botnets have
flooded the web.
I use Wadamesh, clearly vibe-coded, because it's the best
graphical interface for MeshCore that runs on portable devices. I wish
it was made by a human, in a community I could participate in, but it
isn't, and I don't.
I package the above llm toolset, which is more and more
vibe-coded, but I still review the diffs. And I have to say: I
trust Simon here. The code is verbose as hell, feels overengineered,
and llm feels slow, but it generally works, and Simon is still at
the gate.
The Anthropic SDK is another thing entirely. The 0.91.0 to 0.120
upload, for example, was nuts:
I explicitly did not review that entire diff. It feels like there's a
lot of garbage there to just have a shim between a proprietary API and
Python. But this is the hand I've been dealt.
Larger projects LLM use
LLMs are being used in the Linux kernel, Firefox, rsync, Rust, and
other places. I don't feel good about this, particularly in Rust, but
they at least made a decent policy. I am glad GCC made a policy
against LLM contributions and I support the human Emacs
project.
We need to have a set of foundational tools that are "clean" in the
sense that they are built upon a community of people that understand
how they are built.
Maybe that's naive or even impossible. The Linux kernel and GCC, in
particular, are massive projects that have long grown past the scale
of a single person's understanding. But the theory was that a
community of humans can understand collectively.
Now we seem to be throwing up our hands and giving up on
that community. That LLMs will just fix the problem, whatever it
is. But we're all just one rug pull away from being completely
incapable of managing those projects. The argument there is that we'll
just switch to local models, but no one is actually doing that.
All I see is people use local models as a corner case
(for privacy) or as in theory, but in reality, everyone uses the
centralized frontier models right now. We just can't fallback.
We're in the same situation we were, a decade or two ago, when
Microsoft decided it would kill free office alternatives by making
Office free for non-profits. It worked: thousands, if not millions of
schools, community groups and individuals stopped looking for
alternatives (including free software but also "piracy") for Office
and embraced what seemed like a generous offer.
Now Microsoft pulled the plug and Over 170,000 Nonprofits Lost All
Their Data.
I'm afraid the rug pull on LLMs will be much worse: never mind that
Linus won't be able to use his tireless helper to fix obscure kernel
bugs; we're looking at a collapse of the economy so large that we are
already talking about bailing out the companies responsible.
In a sense, the most striking thing about the Debian vote is it has
actually no option to completely refuse upstream LLM contributions. It
seems the community has taken it for granted that it's now impossible
to build Debian entirely without LLMs. We lost the battle even without
a fight, it seems.
A plea for small
If it has really become impossible for us to manage the complexity we
have built, maybe it's time to stop and think about what we're doing
in the first place. We're struggling to even bootstrap our
current toolchain!
This is one of the things I like the most about working on the mesh:
it's low tech, small Arduino devices that is built with decades-old
semiconductor processes that is understandable by human
beings.
Maybe the answer lies more in single-purpose devices like those
communicators and simpler multi-purpose computers than what we have
now, which is what the permacomputing movement is about.
Small is beautiful, let's scale it down.
and yes, I'm sorry this has gotten this long, I hope you will
forgive those 3000 words.
I haven't made a new book haul post in I don't know how long, so a lot of
books have piled up and many have already been reviewed. Here's the
overdue catch-up in case anyone is curious what books I am finding
interesting before the reviews get posted.
Ilona Andrews Magic Bites (sff)
Elizabeth Bear In the House of Aryaman, a Lonely Signal Burns
(sff)
Oliver Burkeman Four Thousand Weeks (non-fiction)
Miles Cameron Whalesong (sff)
Lee Child Killing Floor (thriller)
august clarke The Felicity Complex (sff)
Alison Cochrun Here We Go Again (romance)
Dan Davies The Unaccountability Machine (non-fiction)
Linzi Day Midlife in Gretna Green (sff)
Linzi Day Painting the Blues in Gretna Green (sff)
Linzi Day Ties that Bond in Gretna Green (sff)
Linzi Day Spilling the Tea in Gretna Green (sff)
Michelle Diener Dark Ambitions (sff)
Michelle Diener Dark Class (sff)
Michelle Diener Collision Course (sff)
Michelle Diener Crash Course (sff)
Henry Farrell Underground Empire (non-fiction)
Kathleen A. Flynn The Jane Austen Project (sff)
Victoria Goddard The Hands of the Emperor (sff)
James Herriot All Creatures Great and Small (mainstream)
James Herriot All Things Bright and Beautiful (mainstream)
James Herriot All Things Wise and Wonderful (mainstream)
James Herriot The Lord God Made Them All (mainstream)
James Herriot Every Living Thing (mainstream)
Lauren Hough Monster of a Land (non-fiction collection)
Bethany Jacobs This Brutal Moon (sff)
Guy Gavriel Kay Written on the Dark (sff)
Mary Robinette Kowal The Martian Contingency (sff)
Ann Leckie Radiant Star (sff)
C.B. Lee Coffeeshop in an Alternate Universe (sff)
Fonda Lee The Last Contract of Isako (sff)
Julie Leong The Teller of Small Fortunes (sff)
Julie Leong The Keeper of Magical Things (sff)
R.Z. Nicolet The Cloak and Its Wizard (sff)
Claire North Slow Gods (sff)
Rebecca Ore Writing's Writing (non-fiction collection)
Suzanne Palmer Ode to the Half-Broken (sff)
Gareth L. Powell Fleet of Knives (sff)
Cameron Reed What We Are Seeking (sff)
Beth Revis Full Speed to a Crash landing (sff)
Beth Revis How to Steal a Galaxy (sff)
Beth Revis Last Chance to Save the World (sff)
Natalie Zina Walschots Villain (sff)
Jo Walton Everybody's Perfect (sff)
Martha Wells Platform Decay (sff)
James White The Galactic Gourmet (sff)
James White Final Diagnosis (sff)
The James Herriot books were ones my parents were getting rid of. I have
them marked as mainstream fiction as a short-hand since "fictionalized
autobiography" seemed like too much of a mouthful.
What Happened
On 2026/08/10 at 2:11 am Australian eastern standard time (2026/08/09 16:11 UTC) someone created a post titled Hacked by Chinafans on my documents blog [1]. The person in question created an account named 67965e42a3c3 on that site with the email address 67965e42a3c3@google.com associated with it (I tried emailing that address and it bounced).
At 04:28:41am Australian eastern standard time (18:28 UTC) I was sent an email titled Have you been hacked by a reader of my blogs who subscribed to the RSS feed of my documents blog (a blog that I never expected anyone to read by RSS). Along the lines of the wisdom of crowds should we have the unexpected observation and problem reporting of crowds ? I appreciate the notification, I might not have noticed until the next time I watched an unusually good movie otherwise.
The account in question was apparently created on 2026-07-21 at 16:43:47 (presumably UTC) even though at the time I believe creating accounts was not permitted. As an aside the timestamp of account creation is stored in the user_registered column of the wp_users table in the database, there doesn t appear to be a way to access this in a standard WordPress installation other than doing a SQL query.
Above are the relevant sections of my dpkg log showing the WordPress versions in use. I was running version 7.0+dfsg1-1 at the time the account was apparently created. I am confident in the accuracy of the dpkg logs and believe that they did not compromise the OS, I am not sure whether they ran hostile SQL code to change fields in the MySQL database so had to consider the possibility that the account creation time could have been set to a deliberately misleading value. I checked backups of the MySQL database stored off-site and found that the account in question was not in the 2026-07-21 backup (which was done before 16:43) but in the 2026-07-22 backup.
The WordPress release history [2] has version 7.0.1 released on 2026-07-09 and version 7.0.2 released on 2026-07-17. So presumably the attacker diffed the code on those releases, found an exploitable bug, and used it to create an account on my blog with admin privs. Then they waited a few weeks to see if I would notice and published a blog post when I didn t notice.
WordPress Deficiencies
WordPress doesn t seem to store the version it s running at the time of operations. So anyone who doesn t have a suitable external log of versions deployed (such as the dpkg.log file for a Debian managed installation) won t know for sure which version was running. It supports automatic updates but you can t be sure that they happened soon after the release.
There is no log of IP addresses used for operations. There are apparently some 3rd party modules to log such things and web pages documenting how to modify the PHP to add it but nothing in the standard distribution.
Software should have a standard distribution with some support for logging of security relevant data. The typical situation is that people don t plan for logging such things until after they have been attacked so the data should be recorded without users going out of their way to log it.
A log of security relevant data should be stored in a database table with only insert access (no update, delete, or drop).
Ideally a CMS would support different database accounts for different purposes. Someone from an internal network or VPN could talk to an instance of the web server which has a database username and password giving full access. Everyone from outside the trusted range gets an instance of the web server with database access only allowing to read the posts and appearance configuration and to enter comments. If the database didn t allow the account used for public access to create new admin users or create posts then it would be a lot harder for attackers.
Ideally for everything that stores user account data there would be an easy way of getting a list of users in a plain text format to allow running diff. The design of WordPress has two tables, one for users and one for encoded metadata about users of which one will be the access level. The following SQL command will give a list of all users that aren t subscribers (everyone above the minimum level of access which is typical for new users) along with their encoded password and access level. This could be used in a monitoring system to alert about new privileged users. The TABLE_PREFIX variable is for the prefix for WordPress tables, which is wp_ by default but can be any legal value.
select $TABLE_PREFIXusers.user_login, $TABLE_PREFIXusers.user_pass, $TABLE_PREFIXusermeta.meta_value from $TABLE_PREFIXusers join $TABLE_PREFIXusermeta on $TABLE_PREFIXusers.id = $TABLE_PREFIXusermeta.user_id and meta_key='$TABLE_PREFIXcapabilities' and meta_value != 'a:1: s:10:"subscriber";b:1; ';
What Next?
The blog post they created had a couple of links to Telegram which could presumably be used to contact them. If anyone involved in computer security wants a copy of the original post to do so then they can contact me by any of the usual methods.
I am interested in communication with the attacker if they wish, Telegram is not a service I use but I presume that anyone capable of doing this sort of attack is also capable of finding other ways of contacting me.
I have idly considered changing to a static site generator, here is a good list of static site generators [3].
I have also idly considered other platforms for blogging such as Lemmy. I don t know if Lemmy is better than WordPress for security and updates, but there are plenty of free instances running where it wouldn t be an issue I have to work on.
15 Years
It s been 15 years since my blog server was cracked by a trojaned ssh client [4]. At least this time it was only one service that was compromised.
At May First, we recently received (all within a
single week) three different complaints about domain names that previously
worked fine suddenly not resolving to our servers.
While that isn t terribly uncommon, we discovered that in each case, the domain
name s authoritative name servers were pointing to our mail servers
(a.mx.mayfirst.org, b.mx.mayfirst.org and c.mx.mayfirst.org) instead of
our name servers (a.ns.mayfirst.org, b.ns.mayfirst.org and
c.ns.mayfirst.org). The weird part: this mistaken configuration was happening
at the registrar level, protected by each member s own credentials that we
don t have access to.
Each affected member fixed their records to resolve the problem but also made
very clear that they had not logged into their registrar in years, sugggesting
that the DNS authoritative records in their registrar accounts spontaneously
changed on their own. The first time was weird, the second time could possibly
be a coincidence? But by the third time this happened, we started to panic.
How could registrar records spontaneously change? All three domain names were
registered with different companies - so it couldn t be a single registrar
problem? Are we going to get a flood of these complaints? What is going on!?!?
We did an inventory to see if this was happening with other domain names in use
by our membership and that s when we discovered just how hard it is for our
mostly non-technical users to set a domain s authoritative name servers. The
error rate was less than 1% but still that was a lot of domain names with
typos:
raise your fist in the air with a.ns.mayfist.org!
or just plain give up and hit the floor with a.ns.matfirst.org
Or more commonly people added our name servers, but also left the default
name servers in place.
Also, one person added as their authoritative name servers:
a.ns.mayfirst.org, b.ns.mayfirst.org, c.ns.mayfirst.org,
a.mx.mayfirst.org, b.mx.mayfirst.org, c.mx.mayfirst.org, and even
a.webproxy.mayfirst.org - in other words, all the domain names we tell you
do to anything with.
And lastly, I did find two more domains just pointing to
a.mx.mayfirst.org, b.mx.mayfirst.org and c.mx.mayfirst.org.
That s when it occurred to me: for years we have maintained an offsite server
that provides bothc.ns.mayfirst.org and c.mx.mayfirst.org. It hangs out
in case something terrible happens to our main colo. The week before we started
receiving these complaints, I separated these services, moving
c.mx.mayfirst.org to a dedicated MX server. As a result, these two domain
names stopped pointing to the same IP address. And that s when the complaints
started rolling in. In other words: the affected members set the incorrect name
servers years ago, but because just one of the name servers resolved to an IP
that happened to provide the correct authoritative lookup services, it went
undeteced all this time.
So mystery solved. Nobody s authoritative registrar records suddenly
changed. They were mis-configured for years but thanks to the amazing
resilience of the DNS system, nobody noticed because just one working DNS
server is all you need.
The Folded Sky is a far-future space opera and a fairly direct
sequel to Ancestral Night, but with a
different protagonist. You do not need to have a vivid memory of the
previous book to read this one. It is somewhere around Elizabeth Bear's
31st (!) novel, depending on how one counts and what one includes.
Sunyata Song is an archinformist, which is sort of an archaeologist, sort
of a librarian, and sort of a historian. She recovers, decodes, and
organizes information so that it can be preserved and made usefully
available. As the book opens, she is, after an exceedingly long white
space journey in an actively hostile ship with a (to Sunya at least) an
atavistically off-putting crew, reaching her goal: a vast artifact that I
won't describe further to avoid any spoilers for Ancestral Night.
She is eager to get to work, an eagerness that is both heightened and made
more anxious by the discovery that her academic rival and abusive ex has
arrived before her. The pirate attack doesn't help, nor (at least at
first) does the surprise appearance of her wife and kids.
The opening of this book is a lot of infodumping mixed with nearly
stream-of-consciousness emotional dumping. The style shift in this series
continues to surprise me; previously, Elizabeth Bear books avoided reader
hand-holding to the point of bafflement if you weren't paying close
attention. Not here. The Folded Sky takes the shift perhaps too
far, and I almost stalled out at the start of this book when Sunya's
near-constant self-conscious litany and analysis of fears and concerns
started feeling like whining.
The book picks up considerably after the attempted murder.
About a third of the way through, The Folded Sky feels like it's
settling into a recognizable subgenre of murder mystery except set in the
far future with fascinating technology and aliens. There has been an
attempted murder on a closed station besieged by pirates. There is a law
enforcement officer present, but they don't have a lot of investigative
experience. For various reasons, Sunya decides to start poking around
while being conscious she has no idea what she's doing. The bumbling
detective is a common trope, so I thought that was where the story was
headed.
It is, sort of. There is a mystery and Sunya is involved in solving it.
But that's only a small fraction of what's going on, and by the end of the
book the plot has shifted firmly back to the genre of space opera, with a
side note of family... drama is the wrong word. Whatever one would call a
story about raising a rebellious teenager while trying very hard to not
turn conflicts into actual drama.
I am fascinated by the characterization of this book. Sunya is something
of an emotional mess, but Bear doesn't use that fact in the ways that I
would normally expect. Similar to Ancestral Night, I finished this
book thinking that The Folded Sky is primarily an examination of
rightminding, but a more subtle one than the previous novel.
Rightminding is a central technology of the White Space series, and I
suspect its intended thematic core. Humans in this civilization are
equipped with near-universal implants that allow conscious manipulation of
one's neurotransmitters and thus emotional state, either by the wearer or
by a helpful nearby AI. The fox, the implant used to accomplish this,
comes with some other features such as sensory recordings and the ability
to load ayatanas (James White style
personality recordings to provide some bit of necessary expertise), but
rightminding is its primary and most frequently-used function. It is the
critical technology that allowed humans to break out of cycles of endless
war and join the other peaceful inhabitants of the galaxy in a shared
civilization.
The name is (intentionally, I assume) Orwellian because Bear knows that
many readers, particularly those from the US who have been steeped in
simplistic libertarian ideas, will find the idea profoundly creepy. (This
was a major plot point in Grail.) This
book is not the argument for the technology, though; Bear dealt with that
in Ancestral Night. This book is a look at its practical messiness
for a person who needs a lot of psychological support.
Sunya is anxious, prone to catastrophizing, hates surprises, has some
PTSD-style symptoms around space habitats due to earlier trauma, and is
also dealing with the unwelcome reappearance of her ex-girlfriend who
stole her work. Her first-person narration tends towards insecurity and
anxiety spirals, and in another book this might signal an unreliable
narrator. In this book, though, there are no dramatic emotional
revelations or backstory twists the way there were in Ancestral
Night, and the resolution of her troubled relationship with her daughter
only partly hinges on plot developments. Instead, Sunya muddles through,
with a lot of self-analysis, help from her fox, and a great deal of
support from her wife.
This makes it sounds like the emotional mess at the start of the book is
left unresolved at the end, but that's not true at all. The muddling
through works! Sunya keeps doing things that I thought were foreshadowing
some catastrophe, but she knows herself better than the reader does. Bear
largely avoids the sudden ruptures that are normally used to resolve
emotional problems in fiction. Instead, Sunya spends a lot of time and
energy working on her thinking and her relationships while trying to be
ethical and useful, and those efforts slowly bear fruit.
I'm worried this makes the book sound boring; rest assured that it isn't.
This emotional subplot is only an undercurrent in the novel, and the main
plot has enough weird science, alien aliens, and space opera drama to
satisfy my page-turning desires.
I'm focusing on the emotional arc in this review because I find it so
unusual and so oddly compelling, particularly in retrospect. This is not
how one normally does emotional development in a novel. Sunya's fox and
rightminding aren't even the focus except when the pirates express their
typical libertarian disgust for the idea. Rightminding is an entirely
normal part of Sunya's life that she relies on. It doesn't solve all of
her problems, but it gives her a foundation from which to tackle them in
the slow and frustrating and inconsistent way that is required outside of
novels, via a long series of small decisions to be the person she wants to
be.
I think The Folded Sky will be more hit and miss for readers than the
other books of this series. Sunya was, for me at least, a much harder
character to like early in the book, and it takes quite a while for the
plot to get going. But this is one of those books that I've not stopped
thinking about since I finished it. I think it makes a fascinating pair
with Ancestral Night. The first book makes the philosophical
argument for rightminding, and this book shows the practical reality with
all of its messiness. The Synarche has some significant flaws (including
the status of AIs, which is another interesting subplot), but it's a
workable system.
It feels rare to read a science fiction novel that shows this level of
messiness without pairing it with an argument for radical change, and as
frustrating as it was to read in places, I am intrigued by the overall
effect. Sometimes acknowledging problems and working on them within an
existing framework works.
Followed by a book tentatively titled Shipwreck Star that does not
yet have a release date.
Rating: 7 out of 10
Hello and welcome to my May 2026 free software activities report.
A lot's been going on in my life offline so I took a bit of a hiatus
from doing these reports, but I've had a fairly productive month of
May so I thought it'd be nice to do another one for this month.
ffs-0.2.2: I finally polished and published my ffs package for
GNU Emacs on GNU ELPA. Many thanks to Protesilaos for rounds of
code review and feedback for improving and polishing the package
in preparation for submission to GNU ELPA.
bug#81101: Trying to visit https://www.emacswiki.org in EWW
I noticed it fails with a Somebody wants you to give them money
error due to the anti-bot challenge being served with a HTTP 402
(Payment Required) response. So I landed a patch 12eec781ed6 to
no longer do that. Thanks to Emacs comaintainer Sean Whitton
for reviewing and approving my proposed patch.
bug#81107: I noticed that in EWW, unlike <input type="submit">
HTML buttons, <button> elements were not tab-stoppable, leading
to poorer usability and accessibility. So I landed a patch
ec3d662de0b to fix that. Thanks to Emacs comaintainer Eli
Zaretskii for reviewing, providing feedback, and accepting my
proposed change.
Emacs Chat with Sacha Chua: I joined Sacha for a new episode of
her Emacs Chat podcast, where we talked about Emacs and life.
I gave a quick tour of my Emacs configuration, discussing at
length my configurations for EXWM (Emacs X Window Manager) among
other topics like Emacs's facility for visually indicating buffer
boundaries in the fringe by setting indicate-buffer-boundaries
and my convenience configuration macros.
maintainers@: I started the next long-overdue round of emails to GNU
package maintainers to confirm the contact information we have on
file for them and get a brief status update about their packages.
Emails are sent in small batches to keep the workload of handling
the responses manageable for assistant GNUisances.
GNU Spotlight: I prepared and sent the May GNU Spotlight to the FSF
campaigns team for publication on the FSF's community blog and the
monthly Free Software Supporter newsletter.
Debian
I've begun the work toward updating the Jami package in Debian
unstable again, which means I need to package new releases of its
direct and indirect dependencies. For OpenDHT, I need to update
RESTinio, and to do that I first need to package expected-lite and
sobjectizer for Debian:
#1120837: ITP: expected-lite expected objects for C++11 and later
#1137609: ITP: sobjectizer C++ implementation of Actor,
Publish-Subscribe, and CSP models
I've been working on packaging both and hope to have them uploaded to
the archive in the next days and weeks.
That's it for this month's report.
Take care, and so long for now.
Being persistent, sticking to a plan and showing up to work every day is generally valued highly across all cultures as virtuous behavior. It is obvious that anything of value and worth achieving is also not easy, but requires significant and recurring effort. Learning a new language, winning a sports competition or building a successful business are all typical scenarios where grit plays a central role above everything else. However, sometimes the virtue of tenacity can result in just a waste of energy.
The question is then: how does one recognize that true progress is being blocked by stubbornness and a pivot would be the correct decision, as opposed to being close to breakthrough where doing more of the same would actually be the right choice?
What is persistence actually?
To think clearly about this topic, one must first grasp the concept of grit and what it looks like in practice. Research by psychologist Angela Duckworth on grit shows that sustained effort in the face of setbacks separates high achievers from those who quit too soon. Entrepreneurs who iterated through dozens of failed prototypes or writers who revised manuscripts for years understand this truth. Persistence builds resilience, deep expertise, and the kind of compounding results that shortcuts cannot deliver. It also protects against the distraction of shiny new ideas that pull focus from what actually works.
Persistence is about:
Believing in an outcome and working towards it despite people around you not sharing the belief, and despite your own work and experiments not being successful.
Continuing to hold the belief and sticking to the decision despite other ideas, solutions and competing alternatives surfacing.
The more time passes, the firmer the conviction becomes. Time, money, and emotional energy invested in a failing direction create psychological pressure to continue (sunk-cost fallacy).
Simply following through on a plan or upholding a contract is not true persistence. Grit is a personal trait one can cultivate to actually become more energized to do something precisely because it turns out to be harder than expected.
Pivoting: a calculated choice
The opposite of being persistent is giving up. Pivoting is not about giving up, but about redirecting the energy and momentum towards a new goal. Pivoting requires coming to the realization that you were wrong, and going through the painful process of discovering a new truth.
Ideas tend to be abundant, and doing something new isn t hard as such. The hard part is to abandon a previously held belief and adopt a new one with equal conviction. To have that conviction you need to have data and metrics. This is also the key to how to decide between persisting vs pivoting at any moment in time.
Key metrics of success
Any decision is only as good as the information available at the time it was made. To be set up for success one needs to start by deciding on what the actual goal is, what one values and how progress is measured.
Key metrics are usually easiest to discover by working backwards from the goal. If you want to build an electric car, you might decide that the goal is to have a car that costs 30,000 euros and can drive 300 km on one charge. From that goal you can break down what the cost structure should be, what volume of production is needed to break even, what raw materials are needed and what the battery chemistry needs to achieve to meet the goal. That can further be broken down into a rate of progress. Suppose the plan requires battery energy density to reach 150 Wh/kg to be viable. If the state of the art starts at 100 Wh/kg and funding lasts a maximum of five years, the team needs at least an 8% improvement every year (1.08^5 100 Wh/kg 150 Wh/kg). This can then be used as a guideline. Sometimes progress is not steady, but happens in jumps. Even in those cases there should be a trajectory to benchmark the jumps against.
In an online business, the key metric could, for example, be one of these:
7- or 30-day retention rate: Do new users who try the service actually like it?
Weekly or monthly active users: Is usage trending up?
Feature adoption rate: In an existing service, how many users are using the new feature?
Product-Market Fit Score (from Sean Ellis test): Percentage of users who say they would be very disappointed if the product disappeared. Above 40% is a strong early indicator. A number below that (after multiple iterations) is a good data point to pivot.
Revenue run rate or burn rate: The most generic metric everything eventually boils down to. Healthy markets reward good products.
Weekly metrics are better than monthly, as they make the feedback loop faster and allow you to get validation quickly and do minor course corrections along the way. A complete pivot should, however, be based on long-term data, driven by the key metric and supported by additional data points.
Metrics are also needed because they can t be bribed or convinced to be anything other than what they are. Listening to other people is good, but just relying on the opinion of others is extremely dangerous because people are biased either for you or against you depending on whether they see you as a trusted leader or an outcast.
Key metrics are of course domain-specific and everyone needs to come up with their own. However, you must have some key metric. You can t have the excuse that what you are doing can t be measured. If you are part of a larger organization and you need to advocate for a difficult decision for example, to kill your darlings when facing a pivot you need to have the metrics to back up your views, and those metrics need to have been established way before as something the organization values, and not cherry-picked just for this one decision.
It does not matter if you are on a personal improvement journey, running a political campaign, inventing a new product, or growing a business you need to have some metric you can check at any given time to see if things are improving fast enough to predict success. Metrics can and should also be used in daily work to validate that you are on the correct path, and to optimize execution.
Famous examples of persistence and pivoting that led to breakthroughs
In all of the cases below it is of course in hindsight easy to say they made the right decision. However, take a minute to try to imagine yourself in their shoes at the time of the decision. What metrics might they have had available to support their decision? What would you have wanted to measure or find out if you were in the same situation?
Frustrated that his vacuum lost suction, James Dyson spent five years and built thousands of failed prototypes in a backyard shed. He remortgaged his home, lived on savings, and faced rejection from every major manufacturer who wanted to protect their bag-replacement business. The 5,127th prototype based on an idea from a sawmill with a cyclone finally worked. Launched in 1993, the Dyson DC01 became Britain s best-selling vacuum within two years.
As a single mother on welfare in the mid-1990s, J.K. Rowling finished her manuscript for Harry Potter and the Philosopher s Stone while battling depression and poverty. She hand-typed copies and mailed them to publishers. Twelve rejected it outright, with comments like children s books about magic don t sell. She nearly quit multiple times but kept revising and submitting. Bloomsbury finally accepted it after the CEO s eight-year-old daughter read the first chapter and demanded the rest. The series has since sold hundreds of millions of copies worldwide.
Founded in 1997 as a mail-order DVD rental service, Netflix added unlimited subscriptions in 1999 to compete with Blockbuster. By 2007, broadband growth and declining DVD sales signaled a shift. CEO Reed Hastings pivoted aggressively toward streaming, investing in bandwidth deals and original content while de-emphasizing physical media. The move faced skepticism, but eventually changed the whole culture of how entertainment is consumed.
YouTube launched in 2005 as a video-dating site. Founders offered money to women who uploaded dating videos, but almost no one did. Meanwhile, users uploaded random clips. The team recognized the mismatch and pivoted within months to a general-purpose video-sharing platform with easy uploading. Google bought it just 18 months later.
Instagram began in 2010 as Burbn, a location-based check-in app that let users post plans, earn points, and share photos. Co-founders Kevin Systrom and Mike Krieger quickly noticed users ignored most features and mainly used it for photo-sharing. They made the tough call: scrap everything else. Within weeks, they rebuilt the app around clean, simple photography with filters. The pivot launched as Instagram in October 2010. It gained 1 million users in two months and was acquired by Facebook just 18 months later.
Insanity or conviction?
English has several proverbs that warn against excessive persistence, such as banging your head against the wall . Insanity is commonly defined as Doing the same thing over and over again and expecting different results.
In Finland, the national identity is practically built on the concept of sisu . It means much more than just grit . The word is derived from the word for inside or guts and represents an unexplained, almost superhuman force that makes one stoically take action despite seemingly impossible odds and somehow succeed anyway. It became a defining national mythos during the Winter War (1939 1940), where a force 10 times larger than the Finnish army tried to invade the country but was stopped and Finland just barely managed to keep its independence. The word sisu transitioned from a character trait to a pillar of national survival.
I think Finns survived because the more you believe in persistence, the more likely you are to persist. I view persistence as a religion that requires faith, while pivoting is a science where you derive the truth from the numbers.
When in doubt, I would always choose persistence over pivoting. Perhaps it is because of my genetic tendency towards having sisu , but I would also rather keep on going a bit more and try one more time before giving up and pivoting in order to get more data, so that when I pivot, I know it is absolutely the right thing to do at that point.
Depending on the situation, the costs of postponing the pivot vary. Of course, if the main metric is the burn rate and a company is running out of money, a pivot must be done early enough that the remaining runway is enough to execute the pivot, and then some more.
In some situations a business idea might simply be ahead of its time. If that is the conviction and the key metrics support it, the best way to navigate the situation is to cut down on costs and wait for competitors to appear, help build general awareness, and then ramp up again to ride the wave. Remember that success does not come from grit alone there is always an element of timing and luck as well. But if you are not persistent and stop showing up every day, you won t be able to seize the opportunities if and when they arise.
Failure is the likely outcome you have to avoid it at any cost
One must also realize that most attempts end in failure. Failure is the baseline, and success is the exception. To reach a breakthrough, one must be stubbornly persistent. In particular, if you are a leader, you need to be so high in conviction that it almost becomes an aura that radiates to those around you.
Postponing the decision to pivot allows you to get a bit more data for the decision, so that once you pivot, you have full belief in the new direction. Once you pivot, there is no looking back, otherwise you will undermine morale and most certainly fail with the new thing as people will execute it with hesitation.
Failure is statistically always the more likely outcome. Most things end in failure and we never hear about them. If someone on your team does not believe in what you are doing, it is very easy for them to prove that something is a failure by spreading negativity, putting in less effort (perhaps unconsciously due to lack of conviction) and thus actually contributing to a self-fulfilling failure.
In most areas of life, ideas are cheap and the only thing that matters is execution. To be good at executing, you need to be good at making decisions. When drafting plans it is good to have alternatives and a lot of consideration. However, when execution starts, there is no room for doubt, otherwise the chances of success decrease.
Therefore, the best way of balancing persistence vs pivoting is to
plan well ahead,
establish the key metrics,
have thresholds established for what would trigger a pivot, and
do everything you can to move the metrics in the direction you want them to go.
Finally, if you decide to pivot, you must do so only with very high conviction, as you can t undo a pivot, and you should not be doing multiple pivots in a row either. If you are fully convinced yourself about the pivot, you will also be able to convince others about it, and carry the momentum.
Version 0.0.29 of RcppSpdlog arrived
on CRAN today, has been
uploaded to Debian and built for r2u. The (nice) documentation site
has been refreshed too. RcppSpdlog
bundles spdlog, a
wonderful header-only C++ logging library with all the bells and
whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn
more at the nice package
documention site.
This release features a rewritten internal routine unpacking the R
variadic arguments into C++ variadic template arguments. This in turn
allows to turn back to std::format in C++ mode when C++20
is used. We also adjust for the not-quite-ready-for-this state of the
x86-64 based macOS machine at CRAN. It is running a compiler and SDK
choice that cannot fully deal with C++20, so we dial compilation on it
down to C++17. Similarly, and as we found out after the release, Ubuntu
jammy is also too old to default to std::format so we need
to add a better detection here too so that we can also fall back to the
included fmt there.
The NEWS entry for this release follows.
Changes in
RcppSpdlog version 0.0.29 (2026-05-08)
Some small continuous integration updates
The internal formatter was rewritten as a recursive generator of
variadic templates.
Switch back to std::format with C++20, but force
inferior macos-release-x86_64 to use C++17 rather than default C++20
which fails
Discussion of AI systems seems to be dominated by fears of uncommon and unlikely threats. I think that we should be focusing more on real issues with LLMs and with society in general and put the most effort towards the biggest problems.
It s Not AI
True Artificial Intelligence [1] (IE a computer that has the mental capacity of a household pet) is something that I think can be developed, but it hasn t been developed and we don t have good plans for developing it. We seem to be a lot further away from achieving that goal than we were from landing on the moon in 1962 when JFK gave his historic speech.
What we have is a variety of pattern recognition systems that can predict what fits into a pattern. The most well known type of Machine Learning (ML) is the Large Language Model (LLM) which means ChatGPT and similar systems which predict which text would be likely to come next and can make an essay from it. They can give interesting and useful output, but there is no thought behind it, it s just a better form of Eliza (the famous program from 1964 that simulates conversation by pattern matching) [2]. By analysing billions of documents, storing the data in a condensed mathematical way, and then using computation to extract from that record LLMs can produce output that is unfortunately considered by some people to be good enough to include in legal documents submitted to courts, university assignments, and many other documents. But they do so without even having the thinking ability of a mouse.
To call current systems AIs without any significant qualifiers when criticising them is to concede the debate about the worth of such things.
If we develop AIs that can actually think we will have to deal with the issues in the SciFi horror short story Lena by qntm [3].
The Bad Arguments
Here is a list of some of the most unreasonable arguments I ve seen against AI which distract attention from real problems both related to AI and other problems in society.
Suicide and Homicide
Wikipedia has a page listing Deaths Linked to Chatbots [4] which right now has 16 entries from 2023 to Feb 2026. They are all tragedies and as a society we should try to prevent such things. But what I would like to see from the media is some analysis of overall trends, yes it gets people s attention when someone dies in an unusual way but we need to have attention paid to the more numerous deaths which are preventable. It has become a standard practice to give information on Lifeline in media referencing suicide, it would be good if they also developed a practice of mentioning the relative incidence of a problem when publishing an article about it.
One of the many factors that cause more suicides than chatbots is school, Scientific American has an informative article from 2022 about the correlation between child suicide and school [5]. It is based on US statistics and shows that the lowest suicide rate is in July (a no-school month in the US) which has a rate of 2.3 per 100,000 person years. So if kids had a quality of life equivalent to July all year around then there would be 2.3 suicides per 100,000 kids every year while if they had a quality of life equivalent to a Monday in January or November it would be 3.9 suicides per 100,000 kids every year. The article states Any time I present these data to teachers, parents, principals or school administrators, they are shocked. This should be common knowledge. It is common knowledge to anyone who takes any notice of what happens in schools, but paying attention to serious problems is unpleasant, it s more fun to pretend that school is good for everyone. No parent wants to think that they sent their child to a place that was horrible, no teacher wants to think that they are part of a system that harms kids.
The US CDC has an informative article about youth suicide [6] which documents it as the 3rd largest cause of death in the 14-18 age range fro 2021. This article was published in 2024 and based on statistics from 2023 and earlier. It notes significant differences in suicides, attempts, and persistent feelings of sadness or hopelessness which had girls at more than twice the rate of boys and LGBQ+ kids at more than twice the rate of heterosexual students. It seems obvious that misogyny and homophobia is correlated with suicide and that s something that could and should be addressed in schools. My state has a Safer Schools program [7] to try and alleviate the problems related to homophobia, but I expect that things are getting worse in the US in that regard. 39.7% of kids in US high schools had persistent feelings of sadness or hopelessness before LLMs became popular, school could and should be a happy time for the vast majority of kids but instead almost half of the kids don t enjoy it and a majority of girls and LGBQ+ kids don t. Having no mention of trans kids is a significant omission from that article, based on everything I ve heard from trans people I expect that their statistics would be even worse.
One could argue that the small number of deaths inspired by use or misuse of LLMs is an indication of a larger number of people suffering in ways that don t result in death and don t get noticed. But I don t think that can compare to the fact that the majority of girls and LGBQ+ kids have persistent feelings of sadness or hopelessness in the current school system.
Regarding homicide, the Australian Institute of Criminology has an article showing that in the 2003-2004 time period 49% of women who were killed were listed as a domestic argument [8], that s something that could and should be addressed. That article claimed 308 homicide victims in that time period which is larger than the world-wide death toll from LLMs but also less than 1/3 the death toll from car accidents in Australia. Australia has less than 0.4% of the world population, a fairly low homicide rate, and a number of homicides that vastly outnumbers all world homicides related to LLMs.
I think it s great to address any cause of suicide or homicide, but devoting government resources and legislation towards very uncommon causes instead of things that happen every day is not a good strategy. It would be fine to address all factors leading to suicide, but problems with the school system have been a major factor for decades with little effort applied to fix it.
Fraud and Other Crime
There is evidence of criminals using LLMs to help prepare for crimes, the ability to generate large amounts of text quickly can be used for fraud and extortion. This is going to be a serious problem and we need structural changes to society to deal with it. There is an ongoing issue of scammers convincing older people that their child or other young relative is in trouble and a large amount of cash is required to address it. This sort of scam as well as the more well known Nigerian scams will probably become more common as the cost of running them decreases. This may be more of a problem for people in developing countries as currently a common scam business model is to have people in regions where wages are low (such as Pakistan for one who I spoke to) scamming people in relatively wealthy countries like Australia so an attack with a low probability of success is financially viable. Cheaper attacks will make less affluent victims financially viable to the scammers.
While writing this post I received a financial scam phone call trying to get me to invest in SpaceX that was run by an AI chat system, I expect to receive more of them and this is something that needs to be dealt with via both technical measures and legislation.
Do we have to accept less freedom and less anonymity in finances as a cost of reducing financial crime? Greater restrictions on the use of cash would make some crimes more difficult or less profitable for criminals. As a society I think we need to have a discussion about a balance between financial freedom and freedom from criminal exploitation, failing to have such a discussion is likely to lead to policies which don t work well.
Also one thing that ML systems are good at is recognising patterns in data. Banks could scan all their transactions and look for patterns that correlate with fraud. They currently do this badly and do things like locking credit cards when someone goes to another country and spends money. They could do a better job of that and involve the police in cases of obvious fraud even when the customer doesn t realise that they are a victim.
This isn t a reason to criticise AIs , it s a reason to plan defensive technology that matches the capabilities of attackers.
As an aside I used to work for a company that was developing AI software to scan bank phone calls and allow banks to recognise employees who acted illegally. Unfortunately the Royal Commission into banking misconduct [9] didn t impose any penalties that gave the banks a financial reason to avoid criminal activity.
Unemployment and Inequality
There are many claims about AI systems making large numbers of jobs obsolete, some of them are outlandish such as the claims that all white-collar jobs will be obsolete in the near future. There are some reasonable claims like the ability to replace some mundane jobs.
Replacing jobs that suck with computers, robots, and other machinery is a good thing! Very few people wish that they were working on a farm without a tractor. In 1900 it s estimated that between 60% and 70% of the world labour force worked in agriculture and 40% of the US labour force did so. Now it s something like 27% globally and between 1% and 3% in developed countries. Automated factories are also a good thing, it s best to avoid boring and dangerous work.
The most plausible claims about job replacement from AI is jobs that involve analysing and summarising documents. One example that comes to mind is the worst kind of journalism where press releases from companies are massaged into the format of a feature article. I don t think anyone wants that sort of job and doing it with AI hopefully means no human has to sign their name to it.
For work like programming few people will be directly replaced by AI but if people can do their work more efficiently while using it then less people are required. I don t think that any programmer likes the part of their job where they have to skim read long documents looking for a clue about how to solve a problem with a library or protocol. A LLM processing the document and finding the potentially useful things will take away the drudgery from the work and allow greater productivity.
The trend in replacing people has been making people work longer. If you force all employees to work 60 hour weeks then that can theoretically allow hiring fewer people than having 40 hour weeks. For some work that applies but for skilled work it mostly doesn t as productivity and work quality on average drops when people work more than 40 hours in a week.
Another trend for exploiting people is having a low minimum wage and making accommodation expensive so that many people need to work two jobs. What we need is legislation to restore the situation in the 70s where a single full time job was sufficient to provide for a family. The low minimum wage and high expenses for many things is a problem that s been slowly developing over the course of decades while being mostly ignored by journalists. If they could concentrate on the real issues that are hurting workers today they could incite political action to fix these problems.
Academic Cheating
There is no shortage of ways of cheating in school and university. There are people who are paid to write essays, mobile phones are used for cheating in exams, etc. Getting an AI to write essays makes it easier to cheat for the essay writing part but does so with lower quality and in a less stealthy way.
What s the worst case scenario? That we have to change to oral exams for all university subjects?
In the US the average annual price for tuition at a university is apparently $25,000, if each student had individually supervised assessment for their exams at a cost of $100 per hour it would make the degree cost 4% more. The cost of university in the US is unreasonably high and that s a problem that needs to be fixed, but a hypothetical case of increasing the price by 4% isn t going to be a major part of it.
Weak Arguments Against AI
Computer Security Attacks
There have been many claims made that AI will break the security of all systems and cause the type of disruption that was previously predicted for year 2000. Bruce Schneier has written a good analysis of the issues including how AI can be used by both attackers and defenders [10], he doesn t have a strong conclusion on whether the net result will be good or bad but his article does make it clear that the result is not going to be a total disaster.
While I was working on this post I read another post by Bruce Schneier that was significantly more negative about this issue [11]. While I still don t think this will destroy civilisation I found his other post convincing enough to move computer security from the bad argument section to the weak argument section.
Spidering the Web to Death
There are issues of bots from AI companies doing a bad job of trying to download all the Internet s content and using a lot of resources. When it was just the major search engines and the Wayback Machine doing it the load was small due to having a small number of organisations that were very good at the way they did it having evolved practices over many years. Now we have a lot of idiots doing it badly and repeatedly hitting generated content.
This is really annoying but is something that we can deal with. Currently my blog and many other sites are hosted on a Hetzner server with a E3-1271 v3 CPU with 32G of RAM and there are occasions where more than half the CPU power is being used to service web requests from such systems. Even on the server bidding (renting servers previously used by other customers) Hetzner isn t offering systems so slow nowadays, the slowest they offer is about 20% faster than that. This is something that can be dealt with by spending a little more on hosting until the companies doing that go bankrupt.
I m sure this is a serious problem for some people, but for most people it s not a big deal. Also hostile traffic on the Internet is something we have all had to deal with as a part of life since the mid to late 90s.
RAM Prices
The unreasonably high prices for RAM are annoying and hurt the development of useful computer projects. Big companies can afford it, even with current high prices and large quantities of RAM used for some servers it s still not significant. But it is a major issue for hobbyists and small projects. Things like setting up a dozen test VMs for FOSS development are now too expensive for many people who develop software in their spare time.
But this is a temporary thing, if AI companies were to keep buying RAM at high rates for a few years companies would just manufacture more of it to meet demand. In some situations capitalism can work.
Environmental Damage
There are many people claiming that power used by data centers for AI will lead to environmental damage, using power and water when there isn t enough.
The trend of computer hardware is to get smaller and faster. It hasn t been going as fast as it used to in many areas but it hasn t stopped either and it s an exponential trend. There has been an increase in data centers (DCs) for AI use as the use has been increasing faster than the hardware gets smaller. Eventually they will stop increasing faster than advances in hardware and software can match and the size of DCs will decrease.
As the production of renewable energy is increases the environmental cost of energy hungry industries decreases. In a few years this won t be an issue anyone is bothered about.
False Claims About Danger as PR
Jamie McClelland makes an interesting claim that the AI companies are pushing dangers of AI as a method of PR [12]. That seems plausible and combined with the tendency of many journalists to just massage press releases from companies into articles could be the reason for a lot of the bad arguments against AI.
Good Arguments Against AI
Spam Everywhere
I ve previously written about Communication and Hostile AIs [13]. I think that filling all communication channels with rubbish is a denial of service attack against society.
In the past communication took some effort, even the simplest email that was directly targeted at the recipient took some human effort and that reduced it s frequency. I get a lot of spam saying something like I see your web site doesn t rank in the top for Google searches while my web site in fact rates well and the actor named Russell Coker is ranking below me, so I know that such spam hasn t had the minimum of human involvement. Now a spammer who wanted to do a better job could get an LLM written spam for every target so the message was specifically aimed at them and would take much longer to be recognised by a human as spam and would also avoid most anti-spam software.
Searching for businesses used to be easy, the phone book had listings for them and there was a real cost to being in the book as well as humans actively trying to stop fraud. Creating fake web sites to get business isn t too difficult but it s also not trivial at the moment and such fake sites won t look complete. Now with LLMs it s possible to create hundreds of sites that have content and look reasonable without human involvement. Instead of the small number of suicides and homicides inspired by AI chat systems we should probably be concerned about people who need psychological or medical advice being misled by bogus web sites created as part of fraud campaigns. Imagine people searching for mental health assistance finding web sites run by cults who oppose psychology as a profession. Imagine people searching for basic medical advice such as how to cook a healthy meal getting sucked in to web sites that start sane and then lead people to Ivermectin as a universal medicine.
LLMs have the potential to take spam from quick and simple attacks to large scale targeted fraud aimed at people and organisations that don t have the resources to defend against it. There have been many reports of CEO impersonation fraud against major corporations aiming to steal hundreds of thousands of dollars and fraud against individuals who are persuaded to get amounts like $50,000 to help a relative who is allegedly in a difficult situation. But if every corner store experienced the same type of attack that CEOs experience and if every child had someone trying to steal the pocket money in the same way that relatively wealthy people are being targeted now it would really change things.
David Brin wrote an insightful and informative blog post about this focusing on how AI generated content is being allowed to destroy YouTube [14].
Deep Fakes
There is some overlap between filling all communications channels with rubbish (fake news etc) and deep fake. Making a fake photo of a politician or celebrity to lobby for legislative changes is a real issue but it s not what most people think of when the term deep fake is used.
Using photo and video faking targeting non-consenting people is a serious issue. It s not just fake porn (which is a major issue and will cause some suicides) as there are many other possibilities. Fake videos showing behaviour that justifies sacking people from their jobs is going to become an issue, for people in public facing positions even proof that the videos are fake won t necessarily help them.
Will we find ourselves in a situation where every politician gets deep-fake porn made of them and the only people who run for public office are ones who are cool with that? Will positions of leadership in the technology industry be restricted to people who aren t bothered by having the most depraved fake porn made of them?
The Justice System
We have seen a lot of evidence of law enforcement and the court system based on bias leading to bad results. The Innocence Project attempts to correct that and it s web site documents some of the things that have gone wrong [15]. Using AI systems to do some of the work of law enforcement by training computers on the flawed results of current systems can entrench bias and also make it harder to spot.
When determining whether someone should be considered a suspect or whether a prisoner should be eligible for parole the number of factors that a human can use is limited. But a computer can take many more factors into account so the issues of whether inappropriate factors are being used can be masked. Computers are also unable to explain decisions that they made and are also able to come up with better fake reasons.
In the past there have been racist policies in the US about banks not lending to people living in suburbs where most houses were owned by non-white people, these policies were documented and the documents have become part of the historical record showing racist policies. If a LLM decides not to lend money to people based on mathematical correlations it determined based on historical banking practices it could assign negative weights to factors such as non-English names and implement the racism in a large array of numbers with no proof.
The current cases of lawyers getting LLM systems to do some of their work and having their incompetence revealed when the computer generated work is shown to be ridiculously bad are amusing. But that is not the real problem. The real problems will start when the computers in police cars start flagging every car owned by a non-write person as having a probable cause for a drug stop.
Technically Not Financial Fraud
The majority of the ecosystem around AI is a financial scam [16]. There are companies and individuals doing good things with machine learning some of which is based on hardware and software developed as part of this ecosystem. But the majority of it has no plausible path to profits and a the future of it inevitably ends with some bankruptcies. There are circular flows of money that have the major cloud providers and NVidia looped in, when the values of these companies correct it will become apparent that they have all burned a lot of money keeping this running and all the senior people have got a share of it (the entire purpose of stock options is to allow senior people to suck money out of the company). Then every cloud provider will increase costs while under chapter 11 and all the companies that depend on them will pay whatever it takes. That includes all major companies and most governments. Unlike the dot-com boom and crash and the housing crash the coming financial crash will impact every company that we deal with and most governments. So the people in first-world countries will effectively be taxed to pay for this scam while the executives go party in Monaco. This may seem like an extreme claim but it all happened before with the dot com crash and the housing market crash.
The CEO class has an ongoing practice of doing things that aren t crimes because they lobby (bribe) politicians to make them legal. So the current stock market shenanigans around AI don t seem to involve things that governments consider to be crimes. But any normal person might be surprised to learn that such things are legal and most people would vote for such things to be crimes if they had the opportunity.
A global financial crisis is the least of the problems that seem likely to afflict society from AI systems. But it will be more immediately obvious when it happens which could be this year!
Propaganda
Creating art requires skills that the type of people who want to create propaganda tend to lack. AI technologies allow creating art that is based on mathematical models of actual art to the requirements of the person running the program.
I have seen the term AI Fascism used to describe the use of AI to help authoritarian governments. I am dubious about whether it deserves that term and while every article I ve read about the topic has had some good points I thought that they were all weak points.
But there are lots of ways that governments can abuse their populations without going full fascist. In the last century there were lots of truly terrible governments that didn t even make the top 10 of fascism.
AI Sycophants
Bruce Schneier wrote an informative blog post about AI Chatbots and Trust which focused on sycophantic chatbots [17]. We have seen a lot of evidence of terrible behaviour and stupid decisions from rich people due to having no negative consequences for bad choices. The vast majority of the history of kings concerns bad decisions made by such people. A future where middle class and poor people can make the same bad decisions as rich people wouldn t be good.
Good Things About ML
Machine Learning (abbreviated as ML) can do useful things. It s not just Large Language Models (LLMs) such as ChatGPT etc. There are also ML systems that can analyse images and other data sets.
I have found ChatGPT to be very useful for making suggestions for improving blog posts. I don t get it to write anything just ask for suggestions. It has pointed out things that I missed such as when I didn t include the price when reviewing a car because the car in question was much more expensive than I will ever pay, the price wasn t relevant to me but would be to some readers. It has also made useful suggestions about structure of blog posts, repeating points, and having a good conclusion. It has some downsides which include trying to erase my voice from my writing, suggesting that the rhetorical question does email suck? is unprofessional.
I have worked for a company that used ML systems to analyse driver performance and alert people if a driver is falling asleep, using a phone, or otherwise seems unable to drive safely. Their business model involved a human reviewing the images from the drivers the computer flagged and then determining who is actually doing the wrong thing. This seems a good use of the technology.
I have also worked for a company that used ML systems to analyse the performance of bank employees and detect potentially fraudulent behaviour. Preventing crime seems to be clearly a good thing and in this case the manager of the employee in question would review the evidence to make sure that they weren t being falsely accused.
Conclusion
I don t think that the problems with managing the changes that so called AI is introducing are particularly new. An example of how society handles change that s worth considering is car safety. The seat belt first became mandatory for aeroplanes in some jurisdictions in 1928. The Model T Ford is widely regarded as the first vehicle to start a mass market for cars and it was released in 1925. So if society acted in a reasonable way then for the majority of mass market cars seat belts would have been a standard feature. However seat belts were first made compulsory in 1970 in Victoria Australia and there are still people who think that they are safer without seat belts! The delay in adoption of car seat belts is only one example of needless deaths caused by not taking reasonable measures for car safety but it s one that s easy to demonstrate and measure.
The difference between past problems like car safety and the current problems of AI is that the AI problems will be more pervasive. Most of my history as a car driver and car passenger was in cars that are much less safe than cars made in the last 10 years. But partly through luck I ve never been in a serious crash so being in cars that wouldn t have given me a low probability of surviving a freeway speed crash didn t affect me. There is no possibility that through any combination of luck and skill someone could avoid the downsides of AI . If nothing else the results of elections will be affected and no-one can avoid that.
As a society we really need to address the real issues related to AI which in some cases requires legislation.
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.
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
A colleague asked me if we should move all our money to our pillow cases after
reading the latest AI editorial from Thomas
Friedman.
The article reads like a press release from Anthropic, repeating the claim that
their latest AI model is so good at finding software vulnerabilities that it is
a danger to the world.
I think I now know what it s like to be a doctor who is forced to watch Gray s
Anatomy.
By now every journalist should be able to recognize the AI publicity playbook:
Step 1: Start with a wildly unsubstantiated claim about how dangerous your
product is:
AI will cause human extinction before we have a chance to colonize mars
(remember that one? Even Kim Stanley Robinson, author of perhaps the most
compelling science fiction on colonizing mars calls bull
shit
on it).
AI will eliminate all of our jobs (this one was extremely effective at
providing cover for software companies laying off staff but it has quickly
dawned on people that the companies that did this are living in chaos not
humming along happily with functional robots)
AI will discover massive software vulnerabilities allowing bad actors to hack
pretty much every major software system in the world . (Did Friedman pull that
directly from Anthropic s press release or was that his contribution?)
Step 2: To help stave off human collapse, only release the new version to a
vetted group of software companies and developers, preferably ones with big
social media followings
Step 3: Wait for the limited release developers to spew unbridled
enthusiasm and shocking examples that seem to suggest this new AI produce is
truly unbelievable
Step 4: Watch stock prices and valuations soar
Step 5: Release to the world, and experience a steady stream of mockery as
people discover how wrong you are
Step 6: Start over
Even if Friedman missed the text book example of the playbook, I have to ask:
if you think bad actors compromising software resulting in massive loss of
private data, major outages and wasted resources needs to be reported on, then
where have you been for the last 10 years? This literally happens on a daily
basis due to the
fundamentally flawed way capitalism has been writing software even before the
invention of AI. A small part of me wonders - maybe AI writing software is not
so bad, because how could it be any worse than it is now?
Also, let s keep in mind that AI s super ability at finding vulnerable software
depends on having access to the software s source code, which most companies
keep locked up tight. That means the owners of the software can use AI to find
vulnerabilities and fix them but bad actors can t.
Oh, but wait, what if a company is so incompetent that they accidentally
release their proprietary software to the
Internet?
Surely that would allow AI bots to discover their vulnerabilities and destroy
the company right? I m not sure if anyone has discovered world ending
vulnerabilities in Anthropic s Claude code since it was accidentally released,
but it is fun to watch people mock
software that is clearly
written by AI (and spoiler alert, it seems way worse that software written
now).
Well we probably should all be keeping our money in a pillow case anyway.
(This is an updated version of an older post - the introduction remains the same, the technical details are different)
Linux draws a distinction between code running in kernel (kernel space) and applications running in userland (user space). This is enforced at the hardware level - in x86-speak1, kernel space code runs in ring 0 and user space code runs in ring 32. If you re running in ring 3 and you attempt to touch memory that s only accessible in ring 0, the hardware will raise a fault. No matter how privileged your ring 3 code, you don t get to touch ring 0.
Kind of. In theory. Traditionally this wasn t well enforced. At the most basic level, since root can load kernel modules, you could just build a kernel module that performed any kernel modifications you wanted and then have root load it. Technically user space code wasn t modifying kernel space code, but the difference was pretty semantic rather than useful. But it got worse - root could also map memory ranges belonging to PCI devices3, and if the device could perform DMA you could just ask the device to overwrite bits of the kernel4. Or root could modify special CPU registers ( Model Specific Registers , or MSRs) that alter CPU behaviour via the /dev/msr interface, and compromise the kernel boundary that way.
It turns out that there were a number of ways root was effectively equivalent to ring 0, and the boundary was more about reliability (ie, a process running as root that ends up misbehaving should still only be able to crash itself rather than taking down the kernel with it) than security. After all, if you were root you could just replace the on-disk kernel with a backdoored one and reboot. Going deeper, you could replace the bootloader with one that automatically injected backdoors into a legitimate kernel image. We didn t have any way to prevent this sort of thing, so attempting to harden the root/kernel boundary wasn t especially interesting.
In 2012 Microsoft started requiring vendors ship systems with UEFI Secure Boot, a firmware feature that allowed5 systems to refuse to boot anything without an appropriate signature. This not only enabled the creation of a system that drew a strong boundary between root and kernel, it arguably required one - what s the point of restricting what the firmware will stick in ring 0 if root can just throw more code in there afterwards? What ended up as the Lockdown Linux Security Module provides the tooling for this, blocking userspace interfaces that can be used to modify the kernel and enforcing that any modules have a trusted signature.
But that comes at something of a cost. Most of the features that Lockdown blocks are fairly niche, so the direct impact of having it enabled is small. Except that it also blocks hibernation6, and it turns out some people were using that. The obvious question is what does hibernation have to do with keeping root out of kernel space , and the answer is a little convoluted and is tied into how Linux implements hibernation. Basically, Linux saves system state into the swap partition and modifies the header to indicate that there s a hibernation image there instead of swap. On the next boot, the kernel sees the header indicating that it s a hibernation image, copies the contents of the swap partition back into RAM, and then jumps back into the old kernel code. What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot. The kernel would happily resume into the attacker s image, giving the attacker control over what gets copied back into kernel space.
This is annoying, because normally when we think about attacks on swap we mitigate it by requiring an encrypted swap partition. But in this case, our attacker is root, and so already has access to the plaintext version of the swap partition. Disk encryption doesn t save us here. We need some way to verify that the hibernation image was written out by the kernel, not by root. And thankfully we have some tools for that.
Trusted Platform Modules (TPMs) are cryptographic coprocessors7 capable of doing things like generating encryption keys and then encrypting things with them. You can ask a TPM to encrypt something with a key that s tied to that specific TPM - the OS has no access to the decryption key, and nor does any other TPM. So we can have the kernel generate an encryption key, encrypt part of the hibernation image with it, and then have the TPM encrypt it. We store the encrypted copy of the key in the hibernation image as well. On resume, the kernel reads the encrypted copy of the key, passes it to the TPM, gets the decrypted copy back and is able to verify the hibernation image.
That s great! Except root can do exactly the same thing. This tells us the hibernation image was generated on this machine, but doesn t tell us that it was done by the kernel. We need some way to be able to differentiate between keys that were generated in kernel and ones that were generated in userland. TPMs have the concept of localities (effectively privilege levels) that would be perfect for this. Userland is only able to access locality 0, so the kernel could simply use locality 1 to encrypt the key. Unfortunately, localities are typically only available on systems that implement a Dynamic Root of Trust Measurement like Intel s TXT, and most consumer systems have no support for this. So, we need another approach.
TPMs have a set of Platform Configuration Registers (PCRs), intended for keeping a record of system state. The OS isn t able to modify the PCRs directly. Instead, the OS provides a cryptographic hash of some material to the TPM. The TPM takes the existing PCR value, appends the new hash to that, and then stores the hash of the combination in the PCR - a process called extension . This means that the new value of the TPM depends not only on the value of the new data, it depends on the previous value of the PCR - and, in turn, that previous value depended on its previous value, and so on. The only way to get to a specific PCR value is to either (a) break the hash algorithm, or (b) perform exactly the same sequence of writes. On system reset the PCRs go back to a known value, and the entire process starts again.
Some PCRs are different. PCR 23, for example, can be reset back to its original value without resetting the system. We can make use of that. The first thing we need to do is to prevent userland from being able to reset or extend PCR 23 itself. All TPM accesses go through the kernel, so this is a simple matter of parsing the write before it s sent to the TPM and returning an error if it s a sensitive command that would touch PCR 23. We now know that any change in PCR 23 s state will be restricted to the kernel.
When we encrypt material with the TPM, we can ask it to record the PCR state. This is given back to us as metadata accompanying the encrypted secret. Along with the metadata is an additional signature created by the TPM, which can be used to prove that the metadata is both legitimate and associated with this specific encrypted data. In our case, that means we know what the value of PCR 23 was when we encrypted the key. That means that if we simply extend PCR 23 with a known value in-kernel before encrypting our key, we can look at the value of PCR 23 in the metadata. If it matches, the key was encrypted by the kernel - userland can create its own key, but it has no way to extend PCR 23 to the appropriate value first. We now know that the key was generated by the kernel.
Unfortunately it turns out that some people actually make use of PCR 23, and
restricting it to the kernel makes them sad. There are other resettable PCRs, but only in non-0 localities, so (a) we can t reset them on most systems and (b) we ll just find someone who uses them anyway and run into the same problem. We need a different approach.
Thankfully TPMs have a small chunk of non-volatile RAM that can be used for storing things, and by storing I mean they can be used in a range of different ways. One of these is effectively as additional PCRs. These values can be configured such that they work the same way as PCRs, with the only way to modify them being to append a new hash to their existing value and update the new value to the hash of that merged value. We can allocate one of these for in-kernel use and reject any access from userspace, and also there are officially allocated ranges (so people shouldn t be using random values) and the namespace is large enough anyway that w eshouldn t collide with anyone, so we can carve one of those out and use it for this purpose.
Unfortunately, though, these NV indexes aren t included in the creation data we get when we create a key, so we need another approach. TPMs have the concept of sessions, a series of commands executed in sequence. A flag allows these sessions to be audited , with the TPM keeping a running track of the hash of the commands executed and the results returned. At the end of the session you can ask for a signed copy of this hash, and if you ve kept a log of all the commands then you can verify that they match that signed hash and know that this log represents a real communication with the TPM. If we read the NV index and generate the key inside the same session, we can verify that the key we re looking at was created while the NV index had a specific value, and if only the kernel can set that value then we know that the key was generated by the kernel.
Or, well, can we? Only new kernels would impose the restriction on modifying that NV index. An attacker could boot an old kernel, generate a key there in userland, sign a hibernation image with it, and then reboot into a new kernel. The new kernel would see a valid signature with a valid NV index associated with it and have no way to know it was generated from userland rather than the kernel. We need to be able to tell the difference between kernels that implement this feature and ones that don t, and we need to do that without being able to go back in time to change old kernel behaviour. We can extend a PCR to indicate we implement the new functionality, but so can an attacker running an old kernel.
The normal approach to determining whether an event occurred in a specific phase of the boot process is to cap the PCRs - extend them with a known value that indicates a transition between stages of the boot process. Any events that occur before the cap event must have occurred in the previous stage of boot, and since the final PCR value depends on the order of measurements and not just the contents of those measurements, if a PCR is capped before userland runs, userland can t fake the same PCR value afterwards. If Linux capped the PCRs before userland started running, we d be able to place a measurement there before the cap occurred and then prove that that extension occurred before userland had the opportunity to interfere. We could simply place a statement that the kernel supported the NV index restrictions there, and we d be fine.
Unfortunately Linux doesn t currently do this, and adding support for doing so doesn t fix the problem - if an attacker boots a kernel that doesn t cap a PCR, they can just cap it themselves from userland. So, we re faced with the same problem: booting an older kernel allows the system to be placed in an identical state to the current kernel, and a fake hibernation image can be written out. Solving this requires a PCR that was being modified after kernel code was running, but before userland was started, even with existing kernels.
Thankfully, there is one! PCR 5 is defined as containing measurements related to boot management configuration and data. One of the measurements it contains is the result of the UEFI ExitBootServices() call. ExitBootServices() is called at the transition from the UEFI boot environment to the running OS, and the kernel contains code that executes before it. So, if we measure an assertion regarding whether or not we support restricted access to NV indexes into PCR 5 before we call ExitBootServices(), this will prevent userspace from spoofing us (because userspace will only be able to extend PCR 5 after the firmware extended PCR 5 in response to ExitBootServices() being called). Obviously this depends on the firmware actually performing the PCR 5 extension when ExitBootServices() is called, but if firmware s out of spec then I don t think there s any real expectation of it being secure enough for any of this to buy you anything anyway.
That s what this patchset does. Review feedback so far seems positive, although James Bottomley suggested a design improvement. My approach of using an NV index as a PCR and generating a signing key made sense as a consequence of my original approach involving PCR 23, which had been to use the key creation data and not use audit sessions at all. But the goal isn t to use a key - it s to prove that hibernation occurred in-kernel, and while signing is one way of doing that, there are others. His suggestion is to simply record the hash of the hibernation image into the NV index and then read that back as part of the audit session. On resume we verify the audit session log is legitimate, read the hibernation image, and compare the hash of the hibernation image against the hash in the log. If it matches, and if the PCR 5 value matches, we know the audit session happened in kernel and that the hibernation image hasn t been modified.
It still seems like we re missing something, though. If we re not storing a key anywhere, how do we verify the audit session? To explain this we re going to need to go into some details about how TPM keys work in the first place. TPMs can produce a special kind of key called an Attestation Key, or AK. Attestation keys are used to sign attestation statements from the TPM, such as PCR quotes or audit logs. We need a separate key type for this in order to prove that the signature was generated as part of an attestation - normal TPM signing keys are fundamentally designed to sign arbitrary material, and so can be used by userland to sign something that looks identical to an attestation record. By being able to distinguish the types of key the TPM uses, we can prove that a signature was generated using an AK, and so know that it s a real TPM attestation (because nothing other than the TPM can sign stuff with an AK).
But even beyond this distinction, TPMs have different key types. Ordinary keys are generated using an RNG and will be unique. Primary keys are generated using a seed that is used as an input into a key derivation function. For a given TPM, using the same seed to generate the same type of primary key will always generate the same primary key8. We can have the kernel deterministically generate an AK during suspend in order to sign the audit log, and then generate the same key again on resume to validate it. This means we don t need any other form of trusted storage for the AK - the TPM already provides that functionality.
This is all rather complicated but I ve been thinking about this for some time now and I haven t come up with a cleaner solution. The only real open issue is the degree to which machines actually perform the PCR 5 extension. If it turns out there s a bunch that don t we ll need to come up with some alternative approach to identifying whether the kernel supports this functionality, but the design is such that that should be invisible to userspace so adding alternatives later shouldn t be an issue. Filtering accesses to the NV index is also not super clean, and depends on there not being alternative mechanisms to get at the TPM by sending raw commands. Again, this is intended to be opaque to userland and can be improved if we come up with something better later on (such as a secure way to pass a secret to the kernel on boot that can be used as an auth value for acess to the NV index).
Anyway. Time to go and fix the next thing.
A week ago, 
The following contributors got their Debian Developer accounts in the last two
months:
Being persistent, sticking to a plan and showing up to work every day is generally valued highly across all cultures as virtuous behavior. It is obvious that anything of value and worth achieving is also not easy, but requires significant and recurring effort. Learning a new language, winning a sports competition or building a successful business are all typical scenarios where grit plays a central role above everything else. However, sometimes the virtue of tenacity can result in just a waste of energy.
The question is then: how does one recognize that true progress is being blocked by stubbornness and a pivot would be the correct decision, as opposed to being close to breakthrough where doing more of the same would actually be the right choice?
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.