Long-form technical articles
Systems, security, Rust, operating system internals, AI systems. Written to be read once, carefully, by someone who will go and use it, rather than skimmed by someone who found it in a search result.
Learn
We build serious software products, and write about the systems underneath.
The internals, the tradeoffs, and the decisions behind a product and the systems it runs on, including an operating system and the tools around it. This is the writing we wish someone had left behind when we were figuring it out. No listicles, no ten tips.
Published
Everything written so far.
- Systems
Choosing an init system, and why 0dyssey runs runit
The init system is the first process on the machine and the parent of everything else. Here is the property we judged candidates on, what runit gives us, and what the choice cost.
- Published
- July 26, 2026
- Reading time
- 5 min
Read article - Systems
Package models, and the debt you defer by freezing
Judge a package manager by what happens when an install dies halfway. Judge an update model by when you pay for change. Why 0dyssey is being built on xbps and a rolling base.
- Published
- July 26, 2026
- Reading time
- 4 min
Read article - Linux
The case for tiling window management
A keyboard-driven tiler removes a decision you otherwise make hundreds of times a day. The argument, a real i3 config, and an honest account of the two days it costs you.
- Published
- July 26, 2026
- Reading time
- 5 min
Read article - Design
Designing a dark-first design system
SIGNAL, the system this site runs on: why dark is the primary act, why tokens carry roles instead of values, why pure black is a trap, and why there is exactly one accent.
- Published
- July 26, 2026
- Reading time
- 6 min
Read article - Developer tools
Building developer tools that do not punish you
Depth and legibility are separate axes. Abstraction that carries versus abstraction that traps, progressive disclosure, defaults as shipped opinions, and error messages as the most-read writing a tool produces.
- Published
- July 26, 2026
- Reading time
- 5 min
Read article - Automation
Shell scripting that scales
Strict mode line by line, quoting, arrays over eval, trap-based cleanup, and the footguns that survive set -e. The habits that keep a script honest at 3 a.m.
- Published
- July 23, 2026
- Reading time
- 5 min
Read article
01: What lives here
Three kinds of writing, one standard.
Six articles are published. The rest of this describes what the section is for, and says plainly which strands have nothing in them yet.
Build logs
Notes from building 0dyssey and the platforms, written as the work happens, including the dead ends. The dated log lives on the operating system's own page and has no entries in it yet; the two systems essays here are the closest thing published so far.
Developer education
Explainers that teach the concept rather than the API. The kind of piece that is still useful after the library it mentions has been replaced twice.
02: Why we publish
Teaching the hard thing is how trust gets earned.
People buy engineering from people who obviously understand engineering, and the fastest way to prove that is to explain something difficult clearly, in public, before anyone has asked you to.
So this is not a content calendar and it is not marketing wearing a blog's clothes. A piece gets written when the work produces something worth writing down, which means the publishing rate follows the engineering rather than the other way round.
The same rule applies to the build logs: they will describe what actually happened, including the parts that were wrong for a week. A build log that only contains good decisions is a press release.
03: Who it is for
Built for the curious.
Three readers, and the strands above are aimed at them. If none of them is you, this section is not going to be worth your time, and that is a fine answer.
Engineers levelling up
People who want to understand the layers below their abstractions. The framework is not the bottom of the stack, and everything under it is knowable by anyone willing to read it.
Linux-curious switchers
People ready to move past the surface and own their environment: choosing what runs at boot instead of inheriting it, and knowing why each piece is there.
Designers who build
Designers who want the technical fluency to ship rather than hand off. Enough of the machine to take a design the whole way to production, and to argue for it on technical ground.
04: The range
What a piece here can be.
The shapes the writing takes, from a short note to something carried across several pieces. Read it as the section's scope.
Nothing below is queued, scheduled or in production, and none of it is a commitment to a cadence. A piece appears when the work behind it produces something worth writing down.
Short notes
One problem, one fix, and the reasoning that got there. The kind of thing that would otherwise stay in a private notebook and be re-derived from scratch a year later.
Long-form internals
A single system taken to the bottom: the kernel, init, packaging, the shell, ownership and lifetimes in Rust. Written to be read once, carefully, by someone who is going to go and use it.
Logs written during the build
Notes taken while a system is being built, including the week that went the wrong way. These follow the engineering, so they start when there is a build worth logging.
Multi-part deep dives
A subject too large for one piece, carried across several: the whole of a system in order, rather than the one corner of it that makes a good standalone article. None is running yet.
Need a product built?
Describe the problem in your own terms. You will get a straight answer on what building it actually takes, and how an engagement would run.