Chosen links

Links - 18th May 2026

2026-05-18T00:00:00+02:00

Package registries are governance providers

Package registries are infrastructure. They host files, serve downloads, run APIs. But they’re also governance providers, and that second role gets less attention. When a registry decides who owns a disputed package name, whether an unpublished package should be restored, or how to handle a compromised maintainer account, those aren’t infrastructure decisions. They’re political choices with real consequences. Registries do both jobs at once: the hosting and the ruling.

Infrastructure gets treated as a cost center, something to minimize and optimize. Governance requires expertise, accountability, and deliberation. The people making judgment calls about malware reports, naming disputes, and takedown requests are doing governance work. If we treat registries as governance institutions, not just infrastructure, we have to ask a different set of questions. How they’re designed, who they’re accountable to, and what values they encode.

To update blobs or not to update blobs

A lot of hardware runs non-free software. Sometimes that non-free software is in ROM. Sometimes it’s in flash. Sometimes it’s not stored on the device at all, it’s pushed into it at runtime by another piece of hardware or by the operating system. We typically refer to this software as “firmware” to differentiate it from the software run on the CPU after the OS has started^[1], but a lot of it (and, these days, probably most of it) is software written in C or some other systems programming language and targeting Arm or RISC-V or maybe MIPS and even sometimes x86^[2]. There’s no real distinction between it and any other bit of software you run, except it’s generally not run within the context of the OS^[3]. Anyway. It’s code. I’m going to simplify things here and stop using the words “software” or “firmware” and just say “code” instead, because that way we don’t need to worry about semantics.

Matthew Garrett

Democratising software development inherently means that people are going to develop software in ways you don’t like and which seem objectively wrong and welp that’s also the argument people made against Linux so, it;s impossible to say if its bad or not

All I’m actually saying here is that (waves broadly) a lot more people who have never opened a PR or maintained a project being in a position to either open a PR or maintaining a project is going to result in them not behaving within the social norms we’ve developed as a group that is, to be fair, far less insular than in the 90s but is still somewhat insular compared to society as a whole and yes we are going to have to get used to the equivalent of HTML mail and top posting

How Microsoft vaporized a trillion dollars

After a few minutes, I risked a question: Are you planning to port those Windows features to Overlake? The answer was yes, or at least they were looking into it. The dev manager showed some doubt, and the man replied that they could at least “ask a couple of junior devs to look into it”.

The room remained silent for an instant. I had seen the hardware specs for the SoC on the Overlake card in my previous tenure: the RAM capacity and the power budget, which was just a tiny fraction of the TDP you can expect from a regular server CPU.

The hardware folks I had spoken with told me they could only spare 4KB of dual-ported memory on the FPGA for my doorbell shared-memory communication protocol.

Everything was nimble, efficient, and power-savvy, and the team I had joined 10 minutes earlier was seriously considering porting half of Windows to that tiny, fanless, Linux-running chip the size of a fingernail.

I learned that they had identified 173 agents (one hundred seventy-three) as candidates for porting to Overlake.

I later researched this further and found that no one at Microsoft, not a single soul, could articulate why up to 173 agents were needed to manage an Azure node, what they all did, how they interacted with one another, what their feature set was, or even why they existed in the first place.

Azure sells VMs, networking, and storage at the core. Add observability and servicing, and you should be good. Everything else, SQL, K8s, AI workloads, and whatnot all build on VMs with xPU, networking, and storage, and the heavy lifting to make the magic happen is done by the good Core OS folks and the hypervisor.

How the Azure folks came up with 173 agents will probably remain a mystery, but it takes a serious amount of misunderstanding to get there, and this is also how disasters are built.

How Microsoft vaporized a trillion dollars, pt. 2

Layered on this chaos was an Azure-wide mandate: all new software must be written in Rust. Some porting plans were abandoned, and many junior engineers grew excited by the new language.

Critical modules at the heart of Azure’s node management, a critical part of the company’s flagship Cloud + AI initiative, were sometimes designed by engineers with less than a year of tenure, under leads who lacked visibility into the details.

None of it shipped.

The VM management software continued to run and crash on Windows, despite repeated public statements from 2023 through 2025 claiming that key components had been offloaded to the Azure Boost accelerator and rewritten in Rust.

From my direct involvement, I know those claims did not reflect reality as late as the end of 2024. Of the 64 key work items identified a year earlier to reengineer the VM management stack for offload, none had been completed, and work had not even started on approximately 60 of them.

The list included foundational pieces such as a key-value store, tracing, logging, and observability infrastructure.

Worse, early prototypes already pulled in nearly a thousand third-party Rust crates, many of which were transitive dependencies and largely unvetted, posing potential supply-chain risks.

How Microsoft vaporized a trillion dollars, pt. 4

Upon further digging, I discovered that WireServer was maintaining in-memory caches containing unencrypted tenant data, all mixed in the same memory areas, in violation of all hostile multi-tenancy security guidelines.

It is conceivable that, with a little poking, an attacker could obtain data, including secrets such as certificates, belonging to other tenants on the node.

Moreover, the code was leaking cached entries and even entire caches due to misunderstood memory ownership rules, and suffered from a large number of crashes, in the order of 300,000 to 500,000 crashes per month for the WireServer web server alone across the fleet.

New code was throwing C++ exceptions in a codebase that was originally exception-free. The team had coding guidelines in direct contradiction of those of the larger organization, and their testing practices didn’t include long-running tests, so they missed memory leaks and other defects.

The team had reached a point where it was too risky to make any code refactoring or engineering improvements. I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something.

This further illustrates the pervasive gap in technical leadership throughout the organization.

Language registries are unstable by default

A registry that accepts uploads from tens of thousands of loosely verified publishers and serves the newest upload as the default resolution target within minutes is going to ship malware to consumers at some ambient rate, because that is what an unstable pool is for. We’ve wired that pool directly to production with no promotion step, and I find the recurring surprise harder to justify than the incidents themselves, given the design is the one distributions explicitly label as the lane you run at your own risk.

Distributions ended up with stability channels because a distribution owns the integration problem: tens of thousands of packages have to boot a working operating system together, so somebody upstream of the user has to check that glibc, systemd, Python, and GNOME all agree on the world before any of it ships. The release team is a structural necessity, and once you have a release team you have promotion gates, and once you have promotion gates you have channels almost by accident.

Language registries made the opposite call early on by pushing the integration problem down to each consumer’s lockfile. There was never a single party whose job it was to ask whether requests 2.32.0 and urllib3 2.2.0 and certifi 2024.2.2 actually work together, so that question gets answered thousands of times a day in thousands of CI pipelines instead of once at the registry. With no upstream actor responsible for integration, there’s nobody in a natural position to run a promotion gate either, and the registries themselves have generally declined to be that actor, treating themselves as neutral pipes rather than as the governance layer a promotion policy would require.

The reframe I’m after in the meantime is just an honest label on what we already have. If npm or PyPI offered two indexes tomorrow and described one of them the way Debian describes sid, as a development staging area that changes by the minute and is pointed at by people who accept they’ll be the first to hit whatever breaks, I don’t think many teams would deliberately aim a production build at it. Every production build is aimed at exactly that today, not because anyone weighed it against an alternative but because no alternative has ever been on the menu, and a fair amount of “supply-chain security” work is the industry slowly noticing it never got asked.

Where have all the complex windows malware and their analyses gone?

There is also a glaring double standard in the world of public threat intelligence. You will find endless, meticulous reports on Turla or Lazarus, but you will almost never find a deep-dive analysis of a new advanced Western-made framework on a major security blog. Western IT security companies often deliberately avoid publicly disclosing complex Western APT malware in the fear that doing so might blow an active law enforcement or intelligence operation targeted at dangerous criminals or terrorists.

It is a certainty within the industry that Western security firms are well aware of various Western threat actors and their advanced toolkits. They actively track these groups and create detections for them within their products to ensure their customers remain protected, regardless of the attack’s origin. However, they go to great lengths to avoid publicly disclosing them. Disclosing a Western-led operation is often seen as breaking an unwritten rule of professional courtesy or risking national interests, leading to a curated public history where “advanced” is a label reserved for adversaries, while domestic capabilities are treated as non-existent phantoms.

However, this one-sided reporting creates a significant narrative blindspot driven by operational concerns. It often neglects the reality that non-Western entities might also be using their complex malware for similar purposes — tracking high-level threats or managing national security interests. By disclosing non-Western tools like the Turla tools purely as “malicious” while keeping Western tools entirely in the shadows, the industry creates a skewed reality. It implies that the only advanced malware being written is the work of the East, while the true peak of malware engineering — the silent, modular ghosts of the West — remains often hidden from public scrutiny.

From error-handling to structured concurrency

What we’d like, in some sense, is to have a better place to “forward” the error. In a single-threaded program, that place is “the caller.” In the presence of concurrency, tasks don’t have a caller to which they will eventually return, so what should we do instead?

We’ve reached this conclusion in the light of the specific paradigm we’re developing here, but I think it’s much broader, and also fairly intuitive on reflection. In any concurrency paradigm, you will have some version of “multiple cooperating concurrent tasks,” and that means that you need an answer to “what happens if one of them dies unexpectedly.” And, in turn, it’s hard for me to imagine a fully-general answer other than “we ask the other tasks to cancel and terminate early.”

My experience writing concurrent programs outside of a structured concurrency framework is that it very often ends up being really frustratingly hard to just run that basic dev loop of “run program, see dumb bug, fix dumb bug,” precisely because dumb bugs that would, in a single-threaded program, print a nice stack trace and exit, have a bad habit of turning into deadlocks, or getting swallowed, or something more perverse. And, I find that ad-hoc attempts to add error handling sometimes make things worse! For instance, I sometimes would find that the “natural” approach was to “forward” errors through some pipeline, so that we can collect all errors at the end of a big concurrent operation, and log them in one place. That approach can work, but it also sometimes means you don’t find out about any error until your entire program completes, which is really frustrating during development!

Thus, I’ve found that adopting a structured concurrency approach, or at least taking it as a basic mindset and paradigm, even if I may not have a “true” structured concurrency library in my environment, actually makes concurrent programs drastically easier to write and debug in the first place, even for throwaway prototypes — it pays dividends almost immediately, not merely “eventually” or “in production.”

1. Code that runs on the CPU before the OS is still usually described as firmware — UEFI is firmware even though it’s executing on the CPU, which should give a strong indication that the difference between “firmware” and “software” is largely arbitrary

2. And, obviously 8051

3. Because UEFI makes everything more complicated, UEFI makes this more complicated. Triggering a UEFI runtime service involves your OS jumping into firmware code at runtime, in the same context as the OS kernel. Sometimes this will trigger a jump into System Management Mode, but other times it won’t, and it’s just your kernel executing code that got dumped into RAM when your system booted.

Links - 1st March 2026

2026-03-01T00:00:00+01:00

x86 CPU made in CSS

x86CSS is a working CSS-only x86 CPU/emulator/computer. Yes, the Cascading Style Sheets CSS. No JavaScript required.

Is CSS a programming language?

Do you really need to ask at this point?

Software is political

The embedding of politics into digital systems may also not seem immediately apparent. Values like parsimony or efficiency, which have long been popular in software development, may appear to be technical instead of political. An efficient tool, which requires fewer resources to run, appears to be a goal based on an objective measure. But as we see with bloated codebases and vibe-coded software, efficiency and parsimony are not universal values. Instead, they are values which fit within a system prizing low resource use, and which suddenly become less valued when quicker iteration or a simple desire to automate tasks at any cost becomes the dominant paradigm. In that world, parsimony becomes a political statement in and of itself. And the politics of efficiency is only one apparently technical concept that turns out to be political. There are myriad other embeddings of political values into software, carried out both subtly and overtly. The harvesting of data, what will be reported back and what will not be, and any number of concerns about accessibility or language, are all political concerns masquerading under the guise of features.

rtc: rk808: Compensate for Rockchip calendar deviation on November 31st

In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar insufficiently represented reality, and changed the rules about calculating leap years to account for this. Similarly, in A.D. 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws, and that the month of November should be counted up to 31 days instead. Unfortunately it takes a long time for calendar changes to gain widespread adoption, and just like more than 300 years went by before the last Protestant nation implemented Greg’s proposal, we will have to wait a while until all religions and operating system kernels acknowledge the inherent advantages of the Rockchip system. Until then we need to translate dates read from (and written to) Rockchip hardware back to the Gregorian format.

10 years of Wasm: a retrospective

When someone defines WebAssembly, odds are even that they’ll adapt the old joke about the Holy Roman Empire to say the technology is “neither web, nor assembly”. That is to say, it’s neither specific to the web nor strictly an assembly language, but rather a bytecode format targeting a virtual instruction set architecture.

For the group working on Wasm, the pressure to ship was intense. “Ship as fast as you humanly can before this whole coalition falls apart”, was the prevailing sentiment, according to Wagner.

A full-source bootstrap for NixOS

In this thesis, we present our implementation of a fullsource bootstrap for the NixOS Linux distribution. We build a Linux environment with the Nix package manager from a minimal, handauditable binary seed, and then use it to install NixOS.

Phantom obligation

The guilt you feel for something no one asked you to do.

The answering machine was the first phantom. That blinking light. But the ghosts were still familiar: actual humans spoke actual words expecting actual responses. The count was small (who leaves more than a few messages?) and the voices were known.

Email is where the metaphor made its jump from atoms to bits. “Inbox” was borrowed legitimacy. It sounded like that wooden tray, so it inherited its psychology. But the wooden tray had a constraint: physical space. A desk could only hold so much. The digital inbox had no bottom. Still, mostly real obligations. Humans writing to you, expecting responses.

Then Apple gave every app a weapon.

The notification badge took email’s unread count and made it universal. Any app could now claim urgency. A game wanting you to collect coins wore the same badge as a message from your mother. The weight was democratized. The meaning was gutted.

We invented escape hatches that became new traps. Read-later apps promised relief: save this, flee the obligation of reading it now. But the app created a new queue, a new count, a new obligation. You didn’t eliminate the phantom. You moved it.

I’m not here to tell you that one of these metaphors is correct and the inbox is wrong. I’m here to point out that we have more choices than we’ve been exercising.

An interface that shows you an unread count is making an argument: that reading is something to be counted, that progress is something to be measured, that your relationship to this content is one of obligation.

TBM 403: the seduction (and folly) of rollups, points, and (most) time tracking

We are easily seduced by numbers that look like accounting. Story points. Hours. Percent allocations. Velocity. Capacity utilization. They add up. They fit in spreadsheets. They produce charts. They feel concrete.

The danger is that they borrow the authority of financial accounting without actually being accounting. They are proxies, guesses, and social contracts. When we forget that, we start managing the proxy instead of the real work. We chase numbers that sum neatly rather than signals that help us understand reality. Our desire for things that “add up” can get in the way of understanding the system we are trying to improve.

Take the difference between the allocation of time and the allocation of “capacity”. They are different concepts. While knowing where the time went might be somewhat helpful, we need to consider capacity as something that is built, nurtured, established, and invested in over time.

For example, imagine you have a temporarily assembled team of geniuses. At first, they haven’t worked together, so their capacity is low. They can spend time wherever they want, but they will be hitting a lot of friction. Now nurture that team over time, work down technical debt, invest time and energy in connecting with customers, instrument the various surface areas, and supply them with powerful context about the strategy… and suddenly you might have a LOT of capacity, and they might be creating value very efficiently.

This could last until the strategy changes, maybe someone leaves, and suddenly all that well-earned capacity and potential trends to zero again. Anyway, my point is that what we would do to make capacity and the investment of capacity visible would be entirely different from what we might do to make the allocation of time visible as a tool to assist with management.

Git in Postgres

Instead of using git as a database, what if you used a database as a git?s

A self-hosted Forgejo or Gitea instance is really two systems bolted together: a web application backed by Postgres, and a collection of bare git repositories on the filesystem. Anything that needs to show git data in the web UI has to shell out to the binary and parse text, which is why something as straightforward as a blame view requires spawning a subprocess rather than running a query. If the git data lived in the same Postgres instance as everything else, that boundary disappears.

Forgejo stores issues, pull requests, users, permissions, webhooks, branch protection rules, and CI status in Postgres already, and git repositories are the one thing left on the filesystem, forcing every deployment to coordinate backups between them, and the two systems scale and fail in different ways. The codebase already shows the strain: Forgejo mirrors branch metadata from git into its own database tables (models/git/branch.go) so it can query branches without shelling out to git every time.

All git interaction goes through modules/git, about 15,000 lines of Go that shells out to the git binary and parses text output. With git data in Postgres, reading an object becomes SELECT content FROM objects WHERE oid = $1 on the database connection Forgejo already holds, and walking commit history is a query against a materialized view rather than spawning git log.

The deployment collapses to a single Postgres instance where pg_dump backs up forge metadata, git objects, and user data together, and replicas handle read scaling for the web UI without NFS mounts or a Gitaly-style RPC layer. The path there is a Forgejo fork replacing modules/git with a package that queries Postgres, where Repository holds a database connection and repo_id instead of a filesystem path and Commit, Tree, Blob become thin wrappers around query results.

Optimal Caverna gameplay via formal methods

I always win at Caverna (Uwe Rosenberg’s classic European worker placement tabletop board game). Always. But “always” just means “every time so far”, and I needed something with more mathematical permanence. So I formalized the entire game in Lean 4 and proved that my strategy is the unique weakly dominant pure strategy across every possible game configuration. My friends think this is excessive. My friends also lose at Caverna. Unrelated, I don’t get invited to board game night much anymore.

experimental: Add xx-zones protocol for area-limited window positioning

This is a new attempt to resolve the issues plaguing multi-window applications on Wayland. Those applications want to give the compositor a hint where specifically a window should be placed (or sometimes moved to), as well as whether a window should stay permanently layered above other windows of the same application, regardless of focus.

Links - 18th January 2026

2026-01-18T00:00:00+01:00

Package managers keep using git as a database, it never works out

Using git as a database is a seductive idea. You get version history for free. Pull requests give you a review workflow. It’s distributed by design. GitHub will host it for free. Everyone already knows how to use it.

Package managers keep falling for this. And it keeps not working out.

The progression is predictable. Start with a flat directory of files. Hit filesystem limits. Implement sharding. Hit cross-platform issues. Build server-side enforcement. Build custom indexes. Eventually give up and use HTTP or an actual database. You’ve built a worse version of what databases already provide, spread across git hooks, CI pipelines, and bespoke tooling.

None of this means git is bad. Git excels at what it was designed for: distributed collaboration on source code, with branching, merging, and offline work. The problem is using it for something else entirely. Package registries need fast point queries for metadata. Git gives you a full-document sync protocol when you need a key-value lookup.

If you’re building a package manager and git-as-index seems appealing, look at Cargo, Homebrew, CocoaPods, vcpkg, Go. They all had to build workarounds as they grew, causing pain for users and maintainers. The pull request workflow is nice. The version history is nice. You will hit the same walls they did.

Who needs Graphviz when you can build it yourself?

We are not the first to visualize our compiler’s internal graphs, of course, nor the first to make them interactive. But I was not satisfied with the output of common tools like Graphviz or Mermaid, so I decided to create a layout algorithm specifically tailored to our needs. The resulting algorithm is simple, fast, produces surprisingly high-quality output, and can be implemented in less than a thousand lines of code. The purpose of this article is to walk you through this algorithm and the design concepts behind it.

Pico GPU

Pico GPU is a 300KB memory GPU intended to learn, experiment and have fun with shaders. It is perfect to easily create small demos or games involving 3D rendering. It can also perform GPU based sound synthesis.

A typical PDF

When folks contact me about my forensic software, they typically ask the same three questions:

“Can you detect deep fakes?” This usually goes into a detailed discussion about how they define a deep fake, but the general conclusion is “yes”.

“Can you handle audio and video?” Yes, but the evaluation process is a lot harder than pictures. Quality means everything, and a high quality video is usually lower quality than a low quality picture. So while the answer is technically “yes”, the caveats multiply quickly.

“Can you handle documents?” This is where I begin to cringe. By “documents”, they almost always mean PDF. Yes, my code can evaluate PDF files and it can often identify indications of edits. However, distinguishing real from AI or identifying specific edits is significantly harder to do. (If you thought evaluating pictures and videos was hard, wait until you try PDF files.)

All of this goes back to the problem of trying to define a typical PDF document. Between different PDF generators and different PDF creation pipelines, there’s virtually no consistency. You can’t say that a PDF looks suspicious because it has multiple EOF lines, multiple startxref, inconsistent object enumerations, etc.

There are a few ways to detect intentional PDF edits, like seeing reused object IDs, metadata indicating different edits, or changes more than a few seconds apart. But even then, the question becomes whether those edits are expected. For example, if you’re filling out a PDF form, then we’d expect the edits (filled-out form) to happen long after the initial document was created. Seeing a clear indication of an edit may not be suspicious; you must take the context into consideration.

Control structures in programming languages: from goto to algebraic effects

This book is a journey through the design space and history of programming languages from the perspective of control structures: the language mechanisms that enable programs to control their execution flows. Starting with the “goto” jumps of early programming languages and the emergence of structured programming in the 1960s, the book explores advanced control structures for imperative languages such as generators and coroutines, then develops alternate views of control in functional languages, first as continuations and their control operators, then as algebraic effects and effect handlers. Blending history, code examples, and theory, the book offers an original, comparative perspective on programming languages, as well as an extensive introduction to algebraic effects and other contemporary research topics in P.L.

ASCII characters are not pixels: a deep dive into ASCII rendering

We’ll start with the basics of image-to-ASCII conversion and see where the common issue of blurry edges comes from. After that, I’ll show you the approach I used to fix that and achieve sharp, high-quality ASCII rendering. At the end, we’ll improve on that by implementing the contrast enhancement effect I showed above.

Links - 14th December 2025

2025-12-14T00:00:00+01:00

A journey into the Linux scheduler

One of the things I was fascinated by was how Linux is able to manage and let the CPU run thousands and thousands of processes each second. To give you an idea, right now, Linux on my laptop configured with an Intel i7-1185G7 CPU switched context 28,428 times in a second! That’s fantastic, isn’t it?

During this journey inside Linux, I’ve written notes as it helps me to digest and re-process in my own way the informations I learn. Then I thought: “Maybe they’re useful to someone. Why not share them?”.

So here I am with with a blog.

Vertical integration is the only thing that matters

On the subject of developer tooling, or perhaps computer programs more broadly, I have become increasingly convinced that vertical integration is the only thing that matters. I also think that the inability of developer productivity startups to vertically integrate their offerings has hindered their adoption and utility. I’d like to talk about what I mean by “vertical integration” and why we don’t have it today.

None of the features here are particularly shocking, but they all require cooperation between tools that aren’t used to cooperating. Your test runner knows the call stack of a failing test, but it can’t make that information available in a format your editor or terminal is able to consume. Your deploy system runs an optimized build and then throws away all the artifacts, so if you want to build the same commit you need to start from scratch. The compilation was already run, but your build system isn’t able to grab artifacts from CI because your build system doesn’t know that you have CI.

Open source is also full of software freedom acolytes who insist that each tool must “do one thing well.” To these engineers, project A maintaining an integration with project B is a threat to the ability of users to swap out project B for a different tool; the best approach, to them, is for every tool to behave as if no other tool exists. The fact that this results in strictly less-capable tools seems to be lost on these engineers.

At the same time, many open source projects are owned or funded largely by a single corporation with no motivation (or ability) to make their internal stack available externally. Any integrations in the project must therefore be compatible with the stack used by those corporations internally. For similar reasons, it is also common to see projects with test suites or build systems that cannot be used outside of the organization that funds them.

Failed software projects are strategic failures

The thing is, projects don’t usually fail like that: I’d be hard-pressed to think of any projects where the strategic underpinnings of the project are sound, the supporting logistics and suchlike behind the company work as expected and the project simply fails because despite all this being in place, the software engineers assigned to the project just aren’t good enough. What usually sinks projects are mistakes like a lack of clarity about what a project is actually meant to achieve for a business, a failure to properly understand requirements, under-resourcing or a failure to provide missing capabilities, poor management and organisation and a failure to update the strategy underpinning the project when conditions change. These are all strategy-level mistakes much more than they’re tactical ones.

Tim Ferriss promised freedom. Indie hackers are selling shovels

To support this mirage, we see fake screenshots showing fake revenue, fake Stripe notification popups, fake dashboards — everything aligned with one of the mantras from the startup world: “Fake it until you make it.”

And the worst part? Others started seeing the opportunity. The best thing isn’t selling shovels — it’s running the bar where everyone comes to drink in the evening. Selling alcohol to the shovel sellers.

Because now you can buy the app that lets you create fake dashboards, fake payment notifications, fake analytics panels — everything I just mentioned. Not to mention courses teaching you how to sell courses on creating SaaS products. And now there are even apps designed to prove your MRR isn’t fake.

Using the ancient evils for debugging

On first sight that sounds like a really stupid superpower. On second sight, it still does. We look into how that element became part of HTML below. But now we will use it for one specific purpose: debugging server-side code.

Of course, specialized debuggers like XDebug for PHP or built-in error pages in frameworks like Django take over the heavy lifting here. And even the good ol' print "<script>console.log('here!')</script>" is often helpful. Those tools should be high up in your utility belt.

But imagine this: You are deep in your code, chasing an elusive bug that affects only part of the HTML output, and you want to spot on the rendered page exactly where it shows up. The fastest way is to put a quick <plaintext> close to the offending place, reload the page, and presto! Just scan down to where the markup starts to show through.

This is especially useful to access formatted debugging output. A var_dump() in PHP, for example. Or an error.stack stack trace in NodeJS. Slap a <plaintext> in front of it before writing it to the HTML output, so that the string is immediately readable

Let’s embed a Go program into the Linux kernel

Today, we would like to present a lesser-known feature of the Linux kernel. Instead of launching a program from a file system, regardless of whether it’s virtual or not, it is also possible to embed a user-space program directly into the kernel image itself and start it from there.

C++ standard adventure

Welcome to the C Standard Adventure! Explore the C standard as an interactive world.
Type "help" for a list of commands.

TBM 395: Words! Damned Words!

The best description of this risk I’ve found of reification in action is in James C. Scott’s Seeing Like a State. In the book, Scott describes how organizations try to simplify complex, lived, and emergent realities to make them legible, comparable, and governable from a distance. These simplifications aren’t malicious and, in many cases, are necessary. The problems arise when the model designed to support administration and control is mistaken for reality itself.

That’s exactly what’s happening here. Labels like initiative, strategic, or BAU start as useful abstractions, created to help with funding, reporting, or coordination. But over time, they harden and are used to regulate product development in ways that are fundamentally incompatible with learning-heavy, adaptive work.

[…]

The problem is when rules designed for administration and protection are mistaken for a complete description of reality, and then used to override local knowledge, lived context, and good judgment.

Alicia Juarrero’s work on constraints offers a useful lens here. She argues that coherence does not come from forceful causes or fixed definitions, but from enabling constraints that shape how systems evolve. These constraints create the conditions for action and learning. As patterns of interaction stabilize, they become constitutive constraints that allow an identity to hold together. Over time, some of these harden into governing constraints that regulate behavior at scale.

For example, describing an initiative as “a focused investment of capacity” leaves open what that investment is focused on. The initiative can then be linked to outcomes, opportunities, risks, or value hypotheses without collapsing all of that meaning into the noun itself.

If, instead, you define an initiative as “a value delivery mechanism”, you lose that flexibility and hard-code assumptions about purpose and success prematurely.

Links - 9th November 2025

2025-11-09T00:00:00+01:00

The joy of small scripts

I believe that anyone can find the joy of small scripting. There is a sense of accomplishment to bending the world to your will, even if only slightly. They solve real, if small, problems. When they break, their authors are perfectly placed to fix them. The tools themselves are surprisingly reliable, since they’re built from commonly available and well-known tools. That no two are alike means there is no central failure, they tick on even as services fail. They are an expression of self-reliance and self-empowerment, even as companies seek to constrain how we use the products and services we buy. They are a joy.

build system tradeoffs

Nix has one more interesting property, which is that all its packages compose. You can install two different versions of the same package and that’s fine because they use different store paths. They fit together like lesbians' fingers interlock.

Compare this to docker, which does not compose. In docker, there is no way to say “Inherit the build environment from multiple different source images”. The closest you can get is a “multi-stage build”, where you explicitly copy over individual files from an earlier image to a later image. It can’t blindly copy over all the files because some of them might want to end up at the same path, and touching fingers would be gay.

Most build systems do not prioritize correctness.

Prioritizing correctness comes with severe, hard to avoid tradeoffs.

Tracing build systems show the potential to avoid some of those tradeoffs, but are highly platform specific and come with tradeoffs of their own at large enough scale. Combining a tracing build system with a hermetic build system seems like the best of both worlds.

Writing build rules in a “normal” (but constrained) programming language, then serializing them to a build graph, has surprisingly few tradeoffs. I’m not sure why more build systems don’t do this.

Machine scheduler in LLVM — Part II

Making the optimal choice has always been a difficult problem in computer science (as in real life). There is a whole big field telling you how to optimize for a specific set of constraints – usually with a cost of non-trivial amount of runtime, however. Machine Scheduler, just like other parts of LLVM, prioritizes speed and perhaps maintainability over finding the absolute optimal instruction.

And that, is the rationale behind the design of tryCandidate — specifically its fixed set of comparisons done on candidates — we’ve shown in the previous post. Among those heuristics and comparisons, we are particularly interested in two of them: favor the candidate with a lower register pressure and pick the instruction with lower resource pressure. As they have a more direct connection with the goals of instruction scheduling mentioned earlier. Plus, both out-of-order and in-order cores put attentions on these items. So, without further ado, let’s look at the register pressure heuristics first.

JVM exceptions are weird: a decompiler perspective

Some time ago, I played around with decompiling Java class files in a more efficient manner than traditional solutions like Vineflower allow. Eventually, I wrote an article on my approach to decompiling control flow, which was a great performance boost for my prototype.

At the time, I believed that this method can be straightforwardly extended to handling exceptional control flow, i.e. decompiling try…catch blocks. In retrospect, I should’ve known it wouldn’t be so easy. It turns out that there are many edge cases, ranging from strange javac behavior to consequences of the JVM design and the class file format, that significantly complicate this. In this post, I’ll cover these details, why simple solutions don’t work, and what approach I’ve eventually settled on.

Recursive macros in C, demystified (once the ugly crying stops 😭)

Still, being C’s only compile-time execution capability (currently), it is still both critical and important. Critical, in that many venerable critical systems heavily depend on them, and wouldn’t compile without them. Important, in that it’s often the only way to abstract out complexity that would lead to safety or security issues if exposed, such as automatically adding sentinels or static type checks.

The C Preprocessor (which I will usually call CPP) is responsible for macro expansion and processing lines with a leading #. As we’ve said, it does not fully support recursion. As you might expect, that’s the core of the actual problem in our first attempt. Yet, the preprocessor happily thinks it did its job. We’ll see in more detail what’s going on, but the crux of this particular problem is how recursion is disallowed, not that it IS disallowed.

The problem here is that C macros are their own programming language, being used to generate C code. The macro language doesn’t model most of the interesting parts of the language, and it is quite easy to produce code that the preprocessor finds acceptable, that the compiler cannot understand (as we will see).

In both these cases, the preprocessor feels like it’s done its job, and passes off its work to the C compiler. The C compiler gets the generated code, and has no idea that macros were used. It calls the error as it sees it.

This disconnect between the preprocessor and the compiler is one of the things that makes macros in C so unfriendly.

Building a UI Framework

This document examines important design decisions for creating a new graphical UI framework.

It was commissioned to answer the question of how to create a UI framework, considering four possible design goals: developer adoption, performance, display effects, and power consumption.

This document has three parts. In the first part, we will cover some background material to set the context for the discussion. In the second part, we will examine each of the stated goals which provide constraints within which to consider how to design a UI framework. In the third part, we will discuss design choices, examine possible implementations, and discuss some non-technical issues within the context of the specified goals.

Look out for bugs

The key is careful, slow reading. What you actually are doing is building the mental model of a program inside your head. Reading the source code is just an instrument for achieving that goal. I can’t emphasize this enough: programming is all about building a precise understanding inside your mind, and then looking for the diff between your brain and what’s in git.

Links - 5th October 2025

2025-10-05T00:00:00+02:00

The limits of NTP accuracy on Linux

So, in all, I’m seeing time syncing somewhere in the 200–500 ns range across my network. The GPS time sources themselves are sometimes as far as 150 ns apart, even after compensating for systemic differences, and the network itself adds another 200–300 ns of noise.

In an ideal world, it’d be cool to see ~10 ns accuracy, but it’s not really possible at any level with this hardware. My time sources aren’t that good, my network adds more systemic error than that, and when I try to measure the difference between test servers I see a couple hundred nanoseconds of noise. So 10 ns isn’t going to happen.

On the other hand, though, I’m almost certainly accurate to within 1 μs across the set of 8 test servers most of the time, and I’m absolutely more accurate than my original goal of 10 μs.

Introducing the forklift certified license

Let me explain: have you heard about Supply Chain Attacks? They go about like this:

— “Madame Aria Salvatrice, this is GitHub here. Your javascript library YALP - Yet Another Left-Pad is used by Lockheed Martin, Monsanto, Electronic Arts, McDonald’s, and Adolf Hitler.”
— “Oh that thing i wrote one day i was shitfaced lmao i haven’t updated it in 8 years. Cool.”
— “And you just accepted a pull request by user KinkySatanicPuppygirl2 whose profile picture depicts the character named Leonmitchelli Galette des Rois from the Japanese animation series Dog Days (2011).”
— “Yeag.”
— “Your library is used to generate 26 billions of yearly revenue and this latest pull request added a vulnerabiliy to a cross-site buffer privilege distributed escalation spoofing attack (CVE-8008135). They demand a fix.”
— “Lol sucks to suck. Will they pay me?”
— “No”

Tracing JITs in the real world @ CPython Core Dev Sprint

CPython’s new JIT and PyPy’s JIT share fundamental similarities, as they’re both tracing JITs.

I spent ~7 years of my career optimizing existing code for PyPy at a high-frequency trading firm, and I realized that I’m probably one of the few people in the world with actual experience in optimizing real world Python code for a tracing JIT.

I expect that some of the challenges which I faced will still be valid also for CPython, and I wanted to share my experience to make sure that CPython core devs are aware of them.

One lesson which I learned is that the set of benchmarks in pyperformance are a good starting point, but they are not entirely representative of what you find in the wild.

The main goal of the talk is not to present solutions to these problems, but to raise awareness that they exist.

Changes to `NOT NULL` in Postgres 18

“So what?,” I hear you say. “I can easily use ALTER TABLE aircraft ALTER COLUMN range DROP NOT NULL if I want to drop that constraint, right? And then I don’t need the constraint name at all.” And you would be correct. However, what if you wanted to do other things to that constraint? For instance, foreign keys have the ability to be created as NOT VALID, and validated later; this is incredibly useful if your database is in continuous operation, because such a constraint addition can be made with very little disruption to your production load, because no lengthy scan of the data needs to be made. You couldn’t previously do that with not-null constraints. (Actually, you can create an invalid CHECK constraint, validate it, then add a not-null constraint (which doesn’t require a slow scan because of the CHECK constraint), then drop the CHECK constraint. But who wants to go to all that trouble!?)

TBM 381: stop trying to make prioritization “easy”

Prioritization is a continuous dialogue, which is why frameworks, almost by definition, are only marginally helpful. Prioritization also occurs across fractal layers, ranging from directional ambitions to specific deliverables.

It is a never-ending journey between aspiration and pragmatism, optimism and skepticism, divergence and convergence, abundance and scarcity, and the dance of challenging constraints while also working within them.

The huge problem is that people look for quick fixes to REPLACE the conversation and the various tensions. We don’t want that.

The tension between limited capacity, limited capital, and ambition/intent is the game. It should be challenging — but the RIGHT kind of challenging. Juggling overly precise estimates and trying to fit arbitrary things into the quarter to prove out a weird say/do ratio is the WRONG kind of challenging. If you eliminate that tension or optimize for just one piece of the puzzle, you’ll end up with subpar results.

Nine HTTP edge cases every API developer should understand

Your defense isn’t more code. It’s understanding HTTP deeply, knowing what your framework handles, using infrastructure layers for redundancy, and writing custom validation only where genuinely needed. Most security vulnerabilities come from unnecessary custom code that reimplements (incorrectly) what the framework already does correctly.

Pre-emptive multi-tasking on Arm Cortex-M

Well, all told, we needed 300 lines of Rust and Assembly code, excluding the examples, to write a pre-emptive task switching scheduler. I think that’s not bad at all, especially as the less code you write, the less you have to test and verify. We’ve seen how Armv7-M’s SysTick, PendSV and PSP functions are literally tailor-made for writing an RTOS. And I don’t think we missed C at any point? Very few lifetime or ownership and borrowing issues to worry about here.

Upgrading our way through OpenGL 1.x

In fact, we can do a little better. We can actually start at the very beginning, writing a skeletal version of the pixel-screen display that only uses the 1992 OpenGL 1.0 API, and then work our way up to the final 4.6 revision from 2017, picking up useful or newly-necessary capabilities as we go.

Links - 7th September 2025

2025-09-07T00:00:00+02:00

Meschers: geometry processing of impossible objects

Impossible objects, geometric constructions that humans can perceive but that cannot exist in real life, have been a topic of intrigue in visual arts, perception, and graphics, yet no satisfying computer representation of such objects exists.

Previous work embeds impossible objects in 3D, cutting them or twisting/bending them in the depth axis. Cutting an impossible object changes its local geometry at the cut, which can hamper downstream graphics applications, such as smoothing, while bending makes it difficult to relight the object. Both of these can invalidate geometry operations, such as distance computation.

As an alternative, we introduce meschers, meshes capable of representing impossible constructions akin to those found in M.C. Escher’s woodcuts. Our representation has a theoretical foundation in discrete exterior calculus and supports the use-cases above, as we demonstrate in a number of example applications. Moreover, because we can do discrete geometry processing on our representation, we can inverse-render impossible objects. We also compare our representation to cut and bend representations of impossible objects.

Fun and weirdness with SSDs

The behavior with SSDs is much more complicated, and heavily depends on the I/O pattern, which can have significant impact on query timings.

This problem only affects index scans. Sequential and bitmap scans always read data “forward”, which works fine both with buffered and direct I/O. Only index scans can do backward scans.

The index scan cost model however does not consider these effects. If it did, maybe we’d pick a different plan with an explicit Sort.

Could the cost model account for these effects somehow? I can see some challenges for doing that. The behavior seems to be somewhat specific to the model/drive. And the pattern may not be known while planning the query. If we look at the ORDER BY clause, index correlation, would that be enough to predict the direction?

Baba Yaga licence

# Preamble

By ancient rites, this code is bound, No mortal hand may twist it 'round.

# Terms of Use

Permission granted: to mend and make, To copy, share, for spirit’s sake. Yet mark: no coin, no profit gained, Shall taint this magic, unrestrained.

# Disclaimer

Provided "as is," without a truth, No crone will blame, if ill, forsooth.

# Enforcement

The pact by moonlight, strongly spun, Binds souls if greed hath now been won.

# Cost

The threads are spun, the spell complete, No greed, lest curses, you shall meet.

Affirmations for bloggers

You have things to write about.

Your perspective matters.

You are good enough.

Posts don’t have to be novel.

People will read it.

Mistakes are okay!

It’s okay to ask for things.

You can get started quickly.

You can write on a schedule.

Links - 10th August 2025

2025-08-10T00:00:00+02:00

TBM 370: Dependencies aren’t your problem

Dependency problems are frequently boiled down to discussions about estimation and commitment, when the real conversation should be about priorities and actual outcomes. In the current economic climate, teams are too gun-shy to escalate issues, so you’ll hear a lot of talk about the evils of dependencies but very few concrete examples.

Pure and impure software engineering

This pure/impure distinction has been obscured by the fact that there used to be much more scope for pure engineering at large tech companies. In the 2010s, times were different. Companies were driven almost entirely by hype, and they were hiring more engineers than they knew what to do with. Funding pure engineering projects solved both of those problems: it produced impressive open-source artifacts that made the company look good to prospective engineering hires, and it provided a bottomless pit of useful-looking work for those engineers to do.

Even impure engineering got colonized by pure engineering. Companies burned hundreds of thousands of engineer-hours migrating from monoliths to microservices, or from HTTP service calls to event-sourced architecture, or from event-sourced architecture to full CQRS, and so on. A lot of very skilled engineers found their niche in navigating these hard, technical projects.

But like I said, those times are gone. Tech companies now have to make money. Hiring has slowed down dramatically, and companies are tightening their belts. A lot of pure engineers have had a rough time navigating this transition. From their perspective, work has all of a sudden become much more political. But what’s really happened is that their previous role — which was effectively a covert developer marketing position — isn’t being funded in the current market.

HTTP is not simple

Remember how browser implementations of protocols always tend to prefer to show the user something and guess the intention rather than showing an error because if they would be stringent and strict they risk that users would switch to another browsers that is not.

This impacts how the rest of the world gets to deal with HTTP, as users then come to expect that what works with the browsers should surely also work with non-browsers and their HTTP implementations.

This makes interpreting and understanding the spec secondary compared to just following what the major browsers have decided to do in particular circumstances. They may even change their stances over time and they may at times contradict explicit guidance in the specs.

The whole spec was subsequently rearranged and reorganized again to better cater for the new HTTP versions, and the latest update was published in June 2022. The HTTP/1.1 parts had then been compacted into three documents RFC 9110 to RFC9112, with a total of 95,740 words.

For the argument sake, let’s say we can read two hundred words per minute when plowing this. It is probably a little slower than average reading speed, but I imagine we read standard specs a little slower than we read novels for example. Let’s say that 10% of the words are cruft we don’t need to read.

If we read only the three latest HTTP/1.1 related RFC documents non-stop, it would still take more than seven hours.

Vibe code is legacy code

We already have a phrase for code that nobody understands: legacy code.

Legacy code is universally despised, and for good reason. But why? You have the code, right? Can’t you figure it out from there?

Wrong. Code that nobody understands is tech debt. It takes a lot of time to understand unfamiliar code enough to debug it, let alone introduce new features without also introducing bugs.

Links - 27th July 2025

2025-07-27T00:00:00+02:00

A distributed systems reliability glossary

This glossary is an overview of the concepts that you’ll need to think about distributed systems reliability. We’re writing chiefly for industry practitioners — software developers who are learning about distributed systems testing at any stage of their careers.

It’s meant as a handy guide, bringing together information that was previously scattered all over the internet — because the concepts here originate in many different disciplines (and naturally everyone’s too shy to talk to people outside their field, us included). To the best of our knowledge, it’s the first resource to do so. At the same time, we hope that simply putting all these ideas together in one place starts to show how they all fit together.

Grinding down open source maintainers with AI

The emotional manipulation starts in the first line — telling me how frustrated the user is.

It turns the blame on me for providing poor guidance.

Then the criticism of the tool.

Next, a request that I do work.

Finally some more emotional baggage for me to carry.

You MUST listen to RFC 2119

I found a voice actor and hired them with the task of “Reading this very dry technical document in the most over-the-top sarcastic, passive-aggressive, condescending way possible. Like, if you think it’s too much, take that feeling, ignore it, and crank things up one more notch.”

Writing code was never the bottleneck

Tools like Claude can speed up initial implementation. Still, the result is often more code flowing through systems and more pressure on the people responsible for reviewing, integrating, and maintaining it.

This becomes especially clear when:

It’s unclear whether the author fully understands what they submitted.

The generated code introduces unfamiliar patterns or breaks established conventions.

Edge cases and unintended side effects aren’t obvious.

We end up in a situation where code is more straightforward to produce but more complex to verify, which doesn’t necessarily make teams move faster overall.

Migrating the Jira database platform to AWS Aurora

Our build and test phase proceeded without any major hassles, until one day our support team at AWS contacted us. We had a large test RDS instance that was synchronising in preparation for conversion but AWS were alerted that although synchronisation had completed, the new cluster had failed to start. From our side looking at the AWS console this failed replica instance still appeared to be a healthy, still-replicating instance, but AWS’s control plane detected that the instance’s startup process had timed out.

The reason the startup had timed out was, unknown to us at the time, there were so many files on our source RDS database instance (and therefore, also on our new destination Aurora cluster volume) that the new read replica instance was timing out while performing a status check activity that involved enumerating all those files. The more files one had, the longer the process would take, and the higher the likelihood of hitting this startup timeout threshold. And we had millions and millions of files!

In Postgres, each high-level database object like tables, indexes, and sequences are stored in at least one file on disk each: the more tables, indexes, and sequences in your database schema, the more files on disk you will have.

Jira has a large number of these high-level database objects, which means that in total a single Jira database needs about 5,000 files on disk. With the large number of databases we co-host together on Jira database instances, we wound up creating substantially more files on our new Aurora cluster volumes than any other AWS customer normally would. So even if we weren’t using up all the enormous space available on an Aurora cluster volume, we were still effectively pushing another boundary — impacting our ability to convert our clusters safely.

The advice from AWS was: drastically reduce your file counts on your RDS instances if you want to perform safe RDS→Aurora conversions. The only ways to reduce the file counts on the cluster volume were either to reduce the number of files per database, or to reduce the number of databases on a given instance. Because it wasn’t really going to be possible to reduce the number of files per database drastically (we do need to actually store our tenants' tables, after all!) the only path available to us was to reduce the number of tenants on instances to be converted, which we referred to as “draining”.

Links - 29th June 2025

2025-06-29T00:00:00+02:00

Ink & Switch malleable software essay

Software (aggregate) is malleable. Software (singular) has no need to be. You don’t need to read an essay by Kittler to understand that, at its core, the computer is a machine for manipulating ordered sequences of bits.

The malleable part of wood-working, an oh-so-fetishized sibling to software engineering, is the wood. You can plane it, sand it, cut it, screw it, nail it, glue it, crack it, throw it. The tools are ridiculously simple (hammer, circular saw, table saw, sander, etc). The malleability is not in the tool, but between the user and the material.

Software engineers trying to make “malleable substrates for computing” are like woodworkers trying to build the Mega-Jig, one jig that lets you build anything. It’s a fool errand and is blind to how wood-working is done by ordinary users.

Using the computer is messy like a wood-shop floor. It’s impure and hard to replicate. It has side-effects. It’s not like using a closed-off Smalltalk image that can be the same everywhere. These idealized systems are homogeneous. They are Seeing Like The State. They are high modernism. They are attempts by people who like control, who are attracted to computers because they follow their orders, to impose the demand for the same amount of control onto others. It is an inability to cope with otherness, with mess, with excess.

Why I cannot be technical

I recognize that in these moments what Technical friends wish to do is usher me safely inside of the Technical tent. There is a core of such goodness to this, dare I even say sweetness. In many cases packaged inside of this kind of statement is a hand outstretched, seeking to extend protection to me. Mama didn’t raise no fool: I know that on any quest we should accept protection. In your outdoor voice, please continue to tell people I’m Technical. If we meet inside of a meeting or inside of a decision, and being called technical is the dividing line between people who get to stand on the high ground when the water comes in and people who don’t, I don’t care what type of line you throw down to me.

However, mama didn’t raise no fool. What I know — because my form of expertise which creates the basis for your extended hand in the first place is expertise for this exactly — is that I cannot be Technical. Not really. This is because Technical is a structural designation that operates outside of any actual problem-solving you and I are doing together. Being Technical is about being legitimate. Or to put it more simply: it’s because you are Technical that I can’t be. We have created the identities this way. A person with a PhD in human things and who deals in human problems and human solutions cannot ever be Technical no matter how dense her statistics are, how many conferences she speaks at, and how comprehensively she has given examples of generating outcomes that are often beyond engineering to generate (change over time; impacts on humans; making legible even an imperfect approximation of just one single emotion). These things can be useful, interesting, valuable, heartrending, inspiring and memorable to tech, but they cannot be legitimate.

Tattoy

Tattoy can generally be thought of as a framework for adding eye-candy to your terminal. It is purely text-based so works in any terminal emulator that supports true colour. “Graphics” is rendered with UTF8 half-blocks (▀,▄). Whilst most of its effects are for getting you street credibility it also has more powerful features based around its awareness of terminal contents. For example it can detect and auto adjust text contrast whilst remaining faithful to the terminal’s palette.

Tattoy works with your existing shell, theme and prompt, etc. It can always and immediately toggle between its effects and your normal terminal state, allowing for easy copy-pasting for example.

The cult of hard mode

We see this in the proliferation of tools and frameworks. There is a productivity stack for every ideology: Zettelkasten for the information hoarders, PARA for the organize-everything crowd, Notion for the aesthetes, Roam for the graph-brained, Obsidian for the markdown monks. And under it all is the same impulse: make it harder than it needs to be, so I can feel smarter than I am.

It’s not that these tools are bad. Many are quite good. Obsidian is beautiful. But the way they are used — to signal intellectual rigor, to differentiate oneself from the casuals, to construct a lifestyle rather than solve a problem — shows off a moral hierarchy in which difficulty equates to virtue.

They pursue clarity in mission but bury it under layers of process. This is inefficient — largely because it’s protective. Complexity becomes a defense mechanism. If your system breaks, it’s because it’s complicated, not because you made a bad decision. If no one can understand it, that’s not a failure of communication — it’s proof of depth.

Having fun with OpenSSH private keys

having the public key bytes in there THREE TIMES seems very silly. but the fact that the public key is in there at all is useful.

maybe you’ve been in a situation where you’ve needed to find the public key file of a private key you had around, and just couldn’t find it. but as I just mentioned, you don’t actually need the .pub file for that, as the public key is contained in the private key. ssh-keygen can even extract it for you with -y!

Links - 8th June 2025

2025-06-08T00:00:00+02:00

What works (and doesn’t) selling formal methods

Unfortunately, a lot of developers don’t care about getting to a higher level of correctness. Their current tools work great, they have priced in the existence of bugs and security flaws. The value of fewer bugs and more security is basically zero, so if a new tool costs anything at all, it’s too expensive. This is even true for high assurance systems, which is always surprising to me. You’d think that for a thing that flies or drives around, you’d want that to be less buggy. But often the companies or people who build and maintain these systems genuinely don’t care much, either because they’ve priced in the bugs or because their system is designed to be robust in the presence of bugs.

A good way to understand this is that developers have a lot of competing demands, and many other things can be more important than increasing correctness or security. For example, a team might prefer to spend limited resources on shipping security features and fixes, hiring more developers for the team, paying down technical debt, or meeting upstream needs from customers. Worse, a correctness technology might make other goals more difficult and expensive. For example, rewriting in Fancy Language X sounds great, but it might mean the team is much harder to staff, which is a significant cost to most organizations.

Theory building without a mentor

Naur also says in the article:

in a certain sense there can be no question of theory modification, only program modification

i think this is wrong: theory modification is exactly what Ward Cunningham describes as “consolidation” in his 1992 article on Technical Debt. i highly recommend the original article, but the basic idea is that over time, your understanding of how the program should behave changes, and you modify and refactor your program to match that idea. this happens in all programs, but the modification is easier in programs with little technical risk.

furthermore, this theory modification often happens unintentionally over time as people are added and removed from teams. as ceejbot puts it:

This is Conway’s Law over time. Teams are immutable: adding or removing a person to a team produces a different team. After enough change, the team is different enough that it no longer recognizes itself in the software system it produces. The result is people being vaguely unhappy about software that might be working perfectly well.

i bring this up to note that you will never recover the same theory as the original programmers (at least, not without talking to them directly). the most you can do is to recover one similar enough that it does not require large changes to the program. in other words, you are creating a new theory of the program, and may end up having to adapt the program to your new theory.

Against Curry-Howard mysticism

Many programmers can get swept up in mysticism about Curry-Howard, overstating its consequences. Of these, I think there are two main groups: the mathematically curious and the mathematical fetishists. The curious are those who, usually through no fault of their own, have no or little experience with program specification, verification, formal methods, semantics, proofs etc, before being introduced to Curry-Howard. They then make the mistake of thinking that Curry-Howard is central to all of these new areas to them, simply because it was their starting point. To a certain extent, I do understand this viewpoint — being excited about a particular topic in research is a good thing! The good thing here, is that this problem can be resolved simply by doing better education, so that programmers' first exposure to logic, for example, isn’t in third year university, when puzzling out types for lambda calculus terms.

The Windows registry adventure #1: introduction and research results

And that’s how the story starts. Instead of further refining the fuzzer, I made a detour to reverse engineer the registry implementation in the Windows kernel (internally known as the Configuration Manager) and learn more about its inner workings. The more I learned, the more hooked I became, and before long, I was all-in on a journey to audit as much of the registry code as possible. This series of blog posts is meant to document what I’ve learned about the registry, including its basic functionality, advanced features, security properties, typical bug classes, case studies of specific vulnerabilities, and exploitation techniques.