UUIDv7 solved index locality and promptly got blamed for everything else. Brooker sorts the fair complaints from the noise and sketches what a database actually wants from its keys, with the usual distributed-systems eye for correlated behaviour across regions. Short, opinionated, and the kind of thing you end up citing in a design review.

Gelernter's Linda is the fourth concurrency model everyone forgets, sitting quietly beside shared memory, message passing and RPC. Adrian Colyer's write-up, from Peter Alvaro's desert-island list, is a good reminder that decoupling in time as well as space was a fully formed idea in the eighties. Read it and count how many modern queueing systems are reinventing it.

Every kernel hacker knows the old line: there is no such thing as a container, just namespaces and cgroups in a trench coat. This LWN piece looks at the long-running push to give the kernel a first-class notion of a container, an idea that has stalled more than once over who gets to define one. Read it for the arguments about identity and nesting rather than the patch details.

Dean and Barroso's paper is the reason everyone now says p99 in meetings, and Colyer's write-up is a tidy refresher on why. The fan-out arithmetic is the bit that still lands: one slow server in a hundred barely matters until every request touches a hundred servers. Hedged and tied requests are worth rereading next to whatever retry policy your own services have grown.

This morning brought the MirageOS unikernel paper; here is its storage sidekick. Treating application state as a Git repository, with branches, merges and history, is the sort of idea that sounds like a hack until you notice how much distributed-systems pain it absorbs. The two-way mapping to real Git repositories means your usual tools still work on the data.

A 2015 Morning Paper on the Mirage paper, back when unikernels were the next big thing and the hypervisor was cast as the only kernel you'd ever need. Adrian Colyer frames it against OSv, which makes a good compare-and-contrast of two answers to the same mismatch between general-purpose kernels and single-purpose cloud guests. Read it now knowing how the decade actually went.

The mechanism is pleasingly blunt: set no_new_privs at PID 1 and let inheritance do the rest. Notice the limits, since the flag only bites at execve(), and a task already holding privileges can still change its IDs. The interesting part is the long tail of hurdles once you ask what breaks when su-style binaries stop working.

It starts with an Andres Freund talk on async IO in Postgres 18 and one result that caught Brooker's eye: forward and reverse scans perform very differently, and readahead looks like the culprit. You know why the kernel only bets in one direction. The fun is in asking whether that bet still deserves to be the default.

Park and Ousterhout notice that most of the ordering we pay for in primary-backup replication buys nothing when operations commute. Hence 1 RTT writes until a conflict forces a sync. The write-up predicted wide adoption back in 2019, so it's fun to read now with that bet in mind.

An old friend, and worth the revisit: two LRU lists and no knobs, beating policies that were tuned with hindsight. Anyone who has argued about page replacement will enjoy how little machinery the balancing act takes, and ZFS fans will recognise the family resemblance.

The trigger is gone, the system is still on fire, and the postmortem blames the trigger anyway. Charapko returns to the pattern with the useful framing that the sustaining loop, not the initial fault, is the thing to go after. Anyone who has watched a retry storm outlive its cause will nod along.

An older paper that still earns its keep: instead of one clever lock-free structure, it looks across lists, hash tables, skip lists and trees and asks what the scalable ones share. The word to watch is portable, meaning scaling that survives a change of platform. Anyone who has watched a benchmark collapse on a new socket layout will nod along.

Neumann's VLDB 2011 paper is the one that told the Volcano iterator model to stop calling next on every tuple. Colyer's write-up is a good refresher on why pushing data through compiled pipelines suits modern CPUs, and it arrived at a moment when Spark was borrowing the idea. Old, but it aged better than most query engines.

Brooker's been dribbling this design out in blog posts for ages, so it's useful to have the query layer, transactions, replication and control plane in one document. A paper written by the people who run the thing tends to be most revealing in what it chooses to simplify. There's also an interactive transaction simulator, for those who prefer to break things by hand.

It surfaced on Lobsters this week and deserves another look. These are the people behind the write-optimised filesystem work, so it comes with real measurements, not just asymptotics. The neat trick is buffering in the interior nodes, which is why inserts stop paying the usual B-tree toll while point queries barely notice.

Adrian Colyer's astonishment is the charm here: Google didn't refactor TCP, it started a transport over from scratch. Old hands can read it as a good argument about where a network stack should live, and whether the kernel was ever the right address once you control both ends of the wire.

Formal verification usually costs more than the kernel it protects, so anything that gets push-button proofs out of a symbolic evaluator deserves a look. Worth noticing is the contrast Adrian Colyer draws with Google's ship-fast Snap work from the previous post: two ends of the same spectrum. Old post, still a good argument.

A useful corrective to the assumption that the cloud gets cheaper by itself. Core counts went up tenfold while cost efficiency merely doubled, and that gap should reshape a few back-of-envelope capacity plans. Worth reading for where the paper says the gains really went.

Everyone who has written a journalling filesystem has quietly reinvented a corner of this, usually with worse answers about partial rollbacks. Colyer's write-up from his series on techniques everyone should know is a good excuse to revisit a 1992 paper that still underlies how databases come back from a crash. Old is fine here; recovery has not gone out of fashion.