This picks up directly from Taipo, which I wrote in early 2024. That post ended with a promise I hadn’t kept yet: that at some point I would have to decide Taipo was good enough to go cold turkey on QWERTY, and that I was revising my 30-key two-row keyboard toward exactly that. This is what happened when I finally did it. The short version is that it worked, that the layout I use is no longer quite Taipo, and that as of today it is genuinely my daily driver.

Summary

The story is easiest to follow as a sequence of shrinking key counts: 42 keys on the board I typed on for years, 30 when I removed QWERTY as an option, 20 when I rebuilt the board around where my hands actually want to be, 16 on a layout that turned out to be a step too far, and 18 on the one I’ve settled on.

That last layout is called Dosh. It is five days old. I named it on Thursday the 3rd, drilled it across a four-day weekend, and today is the first day it feels like it has caught up with where Taipo was — not in raw speed, but in the quality that actually matters to me, which is not having to think about it.

I keep seeing arguments about AI coding assistants conducted entirely in the abstract, so here is a concrete one: a real change I made recently, start to finish, including the parts that went wrong. Everything below is a real MCUboot change; the PR numbers are live and you can check my work.

Summary

An automated review of an external contributor’s pull request flagged that the author had quietly disabled a test on one simulated device. Rather than stopping at “you disabled a test”, the model worked out why the test failed — a long-standing bug in MCUboot’s own test simulator that had been invisible for as long as it had existed, and only became observable because this PR raised a configuration limit. The fix was implemented, reviewed, pushed as PR #2808, and then empirically demonstrated to resolve the original author’s problem.

Cost: roughly 30 minutes of my attention, some of it spent doing other things while test suites ran. My honest estimate for doing this by hand is one to two days — most of it spent staring at trailer arithmetic trying to work out why an “oversized” image wasn’t oversized.

The tool was Claude Code running Opus 5.

Notes on why Andy Weir’s astrophage (from Project Hail Mary*) violates the second law of thermodynamics, prompted by watching Veritasium’s “The Most Misunderstood Concept in Physics”.*

The claim

In the book, astrophage feeds by absorbing heat directly — infrared/thermal energy from its surroundings (a star’s corona, or the dense atmosphere of Rocky’s homeworld Erid) — and stores that energy in a compact, fully recoverable form (described as mass added to held neutrinos). Critically, it does this without radiating anything back out during absorption. It behaves as a perfect heat sink: energy goes in, nothing thermal comes out, and the energy can later be released as clean, usable energy (propulsion).

An improvised weeknight mole using roasted poblanos and fresnos, with peanut butter and cocoa for depth — no tomato, no added salt.

The first mode that I implemented for my keyboard was a QWERTY mode. I needed this, because I already know how to type on QWERTY (and fairly quickly at that, over 100WPM). However, one of the goals of the more compact keyboards is to reduce the amount of reaching that is needed to access all of the keys normally.

Traditionally, this is done through multiple layers, with things like numbers and symbols mapped to these other layers. Accessing these, is then done with additional shift-type keys that access these other layers.

Update, September 2026. I did go cold turkey on QWERTY, in August 2026, and I no longer type in it at all. I also no longer type in Taipo exactly: I now use a variant of my own called Dosh, which drops the upper pinky key but keeps nineteen of Taipo’s twenty-six letters on their original chords. If you have arrived here looking for a chorded layout to actually use day to day, Dosh: Chording Down to Eighteen Keys is the current state of things. The post below still stands as written, and is the best description I have of what learning Taipo from scratch is like.

MCUboot is a bootloader for microcontrollers. It has a fairly long history and has been under development for a number of years. Over the years, it has gained some significant functionality, and is used as the bootloader for a number of projects (TF-M and Zephyr coming to mind).

MCUboot is somewhat unique as an embedded application in that it tends to be fairly isolated. There are a lot of other projects that make use of MCUboot itself, but MCUboot itself does not have a large number of dependencies. It needs the ability to run as an early application on the target, operate on the flash device, and perform some cryptographic operations. It optionally can support some types of logging to help with debugging and development.

I have been asked several times about whether the log4j vulnerability affects Zephyr. There is kind of a tendency to give a glib answer “Zephyr is an embedded RTOS, and doesn’t run Java.” Although this is true, it is important to understand that Zephyr doesn’t live alone, especially as devices become more connected, and evaluating this vulnerability should still be done.

The first place to look is indeed the source code to the Zephyr project itself. For the most part, Zephyr targets small embedded CPUs (microcontrollers) that frequently have memory sizes that are measured in tens or hundreds of kilobytes, with megabytes being available in a large system. A simple glance at the latest Apache log4j shows that the core jar file is 1.8 megabytes itself. Just the jarfile alone is larger than the memory on the targets that Zephyr supports.

My blog has been stale since 2018. There have been several reasons behind this. One is that with upgrades to Hugo, my site was no longer rendering. I have since created a new site directory, and copied the content from the old site to the new.

In addition, the Ubuntu image running the server has started to feel fragile, and I’ve been concerned about making any changes to it. I have since set this new site up using NixOS, which among other features, allows me to specify the entire configuration of the machine in a fairly simple, small file.

This is the first in what I hope to be a series of posts about the MCUboot bootloader from a security perspective. Please note that although I work in security, I am by no means a cryptographer. I appreciate any feedback on any and all flaws in my analysis.

The MCUboot project

The MCUboot Project is

…a secure bootloader for 32-bit MCUs. The goal of MCUboot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables easy software upgrade.