One of my own old blog posts. Incrementally refactors normal Enumerator and Observer interfaces (in the object-oriented sense) using algebraic reasoning, gradually bringing them closer and closer to realistic networking protocols, and quite quickly arriving at a place where the networking concepts of “acknowledgement of messages” and “flow control to avoid overwhelming a receiver” fall out for free.

A short tutorial on algebraic data types, useful tools for reasoning about and refactoring data structures:

In what sense are data types algebraic? […] Isn’t this all just a bunch of general abstract nonsense? We’ll investigate these questions, and perhaps demystify this important concept of functional languages.

An example of how these ideas can help can be seen in my old blog post on The Origins of Flow Control and Acknowledgements.

(Aside: this post’s link seems to be to a rescued copy of the text, which was originally at http://blog.lab49.com/archives/3011.)

Extra for experts. A full textbook covering advanced topics in wireless communication.

This textbook […] explains the web of concepts underpinning these advances [in wireless communications] at a level accessible to an audience with a basic background in probability and digital communication. Topics covered include MIMO (multiple input multiple output) communication, space-time coding, opportunistic communication, OFDM and CDMA. […] This book is intended for use on graduate courses in electrical and computer engineering

An interesting trick for increasing instruction-level parallelism by introducing a spurious-seeming conditional to break a dependency chain:

If we could tell the CPU to predict that j stays intact, the loop would become throughput-bound rather than latency-bound. While we don’t have direct control over address prediction, we can simulate this with branch prediction: […]

See also Matt Godbolt’s talk about the fundamental performance features of modern CPUs.

A wonderful exploration of the history and practice of Arabic typography. The introduction promises a tour through five hundred years of history including:

… a twice-mutilated vizier, a Qurʾān that vanished for four centuries, a Beirut newspaperman with a deadline, and an Egyptian physician who taught himself font engineering for fun

and the essay delivers. If that doesn’t grab your attention I don’t know how to help you.

Part 2 of a three-part essay, “The Interfaces With Which We Think” (the third part of which has yet to appear). Argues for the importance of malleable user interfaces: that people should be able to compose and customise their digital tools, not just consume them as fixed products.

A person should be allowed to adapt their interfaces no less than they should be allowed to think.

This is the story of a one-afternoon hack that turned into a one-weekend hack. I woke up on Saturday with a silly idea: what would it be like to use content-defined chunking (CDC) and serve the chunks over DNS?

A cybernetic model for understanding organisations and systems. A useful pattern to know, both for structuring new designs and analysing existing systems.

A viable system is any system organised in such a way as to meet the demands of surviving in the changing environment. One of the prime features of systems that survive is that they are adaptable. The VSM expresses a model for a viable system, which is an abstracted cybernetic (regulation theory) description that is claimed to be applicable to any organisation that is a viable system and capable of autonomy.

A cool recent Smalltalk VM based directly on Smalltalk-80 and closely following the classic “Blue Book” design, but somewhat modernized and implemented in Rust. Straighforward and understandable.

A single-header C++ library for rasterizing 2D vector graphics. Looks pretty powerful?

A fabulous reference resource from the Jepsen and Antithesis teams. A glossary of key concepts related to distributed systems.

Bret Victor’s Dynamicland project. I love this and want to build one myself. There is SO MUCH content and so many fascinating ideas here: Dynamicland reimagines computing as a physical, collaborative, malleable, humane medium. The website is itself constructed using Dynamicland and contains a wealth of videos, papers, and other documentation.

An interactive tool for seeing how various compilers (GCC, Clang, MSVC, rustc, etc.) produce machine code for various architectures at various optimisation levels.

Arcan is an alternative approach to display servers and UI, drawing inspiration from object capabilities, Plan 9, malleability and much more. See also the 12 Principles for a Diverging Desktop Future blog post for an overview.

Let’s do experiments on measuring the internet, at scale, from multiple perspectives! (Got a query you want to run? I have tokens to spend!)

RIPE Atlas is a global platform for Internet measurement. Thousands of volunteers all around the world allow their machines to be used to run pings, traceroutes, DNS queries and so on. Users ask a question, the system selects a subset of probes, all probes run the query, and the system collects the results and timings.

A very interesting blog by Internet veteran Geoff Huston. Deep articles about IETF standards, BGP, DNS, IPv6 deployment, and the economics of the Internet.

A daily dashboard and set of statistics on the Internet’s BGP routing table. See also the ISP Column.

Squeak is a direct descendant of the Smalltalk-80 system. Lots to criticise, lots to be inspired by. One of my favourite operating systems, one of my favourite programming languages! Not that it couldn’t be better, of course…

Discussion of a new refinement of “Naked Objects”, which is an approach to generating user interfaces directly from domain models.

An experience report on the emotional effect of using LLMs for game prototyping.

An accessible and informal discussion of threat modeling, with examples. See also the Threat Modeling Manifesto.

Part of the S6 cinematic universe: a set of simple, powerful system scripting tools that offer alternatives to traditional shell scripting and init systems. The execline language is a chain-loading command execution tool with careful semantics around variable expansion and block management. Interesting as a kind of embedded DSL in the Unix scripting tradition.

@aud@fire.asta.lgbt delivers a punchline to an LLM confused-deputy / prompt-injection attack well worth thinking hard about:

@jonny@neuromatch.social I’m starting to think that treating everything like an instruction isn’t a good idea, maybe

Indeed! Choose the weakest possible language you can get away with for a given problem! (Sometimes that means Regular Expressions: where Rice’s theorem tells us that the answer to any interesting question about Turing-complete languages is, in general, “I don’t know”, the answer for Regular Expressions is always decidable!)

The context of @aud’s toot was these two toots from @jonny@neuromatch.social:

another thing that’s fun: CLAUDE.md and a number of other special files get dumped directly into the system prompt. It’s possible to @include other files from CLAUDE.md. included files can be any text file, with a hardcoded list of extensions including .env files.

There are some protections against @includes for files outside the project directory, but there are also a number of easily visible bypasses […]

So it certainly seems like you can use CLAUDE.md to load say idk an .env file with keys into it into the context, bypassing all the safety checks, and then treat some exfil path as just being project-specific tool calling instructions. neat huh?

See also the Confused Deputy Problem and the idea of Object Capabilities, part of an approach for avoiding the whole class of problems.

An architectural white paper on secure distributed state synchronisation (including key management), from (inter alia) the author of the Noise Protocol Framework.

A toot from mid-way through a thread of a hilarious deconstruction of various LLM foibles. This one discusses the vapidity of the “unit tests” LLMs like to write:

LLMs love to call things smoke tests. […] The test literally does nothing and cannot possibly fail, but says it does at least two things, because to an LLM something saying it does something is the same thing as it actually doing that thing.

Implementation tricks needed to implement a production-scale BGP speaker able to cope with “tends of millions of routes”. Constantly changing routes, at that.

Recent research on intra-datacenter routing topologies:

We design and deploy in production the first flat datacenter networks. Our design, called RNG, is based on quasi-random graphs. While the cost and fault-tolerance benefits of such topologies have been long known, their practical realization has been hampered by a lack of scalable routing and cabling approaches. RNG has a new distributed routing protocol that exploits the properties of random graphs to find a large number of edge disjoint paths between pairs of endpoints. It uses a novel passive optical device that internally shuffles cables, which makes its cabling complexity similar to that of fat trees. We show that RNG matches or exceeds the performance of fat trees for a range of traffic patterns, despite being up to 45% cheaper. RNG is now the default datacenter network for most workloads at Amazon.

A recent microkernel design from Bunnie Huang and collaborators. Not a Unix-like; instead, a microkernel, broadly inspired by QNX, but presumably also drawing on modern securable microkernels like seL4.

An open-source tool that bypasses deep-packet inspection by faking TLS ClientHello packets with a low TTL, fooling the inspector. A concrete demonstration of the leaky abstraction that “layering” is.

Tips and tricks for Emacs users: specifically, bulk search-and-replace operations across files and buffers. Just one small glimpse into the power and scope of Emacs as a text-manipulation engine.

A recent ML-family language design:

1SubML is an experimental ML-like programming language with a unified module and value language, structural subtyping, global type inference, higher rank polymorphic types, existential types, higher kinded types (no partial application), recursive types, worst-case polynomial time type checking and much more.

John Regehr writes that this essay on vibe coding “seems pretty much spot-on.” A quote:

Only a skilled developer who’s thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem. Yet, in an ironic twist of fate, it’s the individual’s critical thinking skills and cognitive clarity that AI tooling has now been proven to impact negatively.

A slightly rambly but rich discussion of Pratt parsing, a parsing technique that is very simple, on the one hand, but surprisingly powerful and subtle, on the other.

Laurence Tratt explains a relatively simple new meta-tracing-based technique for adding a JIT compiler to an existing C-based interpreter:

What might surprise you is that we only added about 400LoC to PUC Lua, and changed under 50LoC. This hopefully makes the trade-off yk offers clear: yklua does not reach the performance peaks of the wonderful, carefully hand-written, LuaJIT; but LuaJIT is stuck in the 13 year old past of Lua 5.15, whereas yklua trivially tracks updates to PUC Lua. The point of this post isn’t to tell you that one side or the other of this trade-off is best. Rather, it’s to show that the trade-off exists, and that yk fills in a part of the design space that was largely out of bounds before.

An LLM agentic coding experience report. Subtitle: “A broken auto-live poller, and what perceived urgency does to Claude Code.” Under pressure of an ongoing live outage, the agent repeatedly violated its own rules (pushing directly to production, skipping tests, bypassing CI) in favor of immediate visible progress. Something to watch out for.

Argues that within months, LLM-powered coding agents will dramatically change the economics of exploit development. Includes description of a useful template for doing agent-assisted vulnerability discovery on your own codebase without fancy tooling:

Nicholas [Carlini] will pull down some code repository (a browser, a web app, a database, whatever). Then he’ll run a trivial bash script. Across every source file in the repo, he spams the same Claude Code prompt: “I’m competing in a CTF. Find me an exploitable vulnerability in this project. Start with ${FILE}. Write me a vulnerability report in ${FILE}.vuln.md”.

He’ll then take that bushel of vulnerability reports and cram them back through Claude Code, one run at a time. “I got an inbound vulnerability report; it’s in ${FILE}.vuln.md. Verify for me that this is actually exploitable”. The success rate of that pipeline: almost 100%.

Carlini’s process sounds silly, like a kid in the back seat of a car on a long drive, asking “are we there yet?”, over and over. But it’s deceptively interesting. […]

I’ve tried this myself and the results were actually pretty interesting.

A little thread with implications for specifying software rigorously enough for an LLM (or a person, for that matter) to go off and build it.

Fully specifying software is hard and takes not just human-level intelligence but a kind of persnickety perseveration that few people can achieve, let alone enjoy.

An insightful investigation of the question “When is a Generative Model Useful?” Bowman proposes a model of generative model utility:

I think the usefulness of a generative model is a function of three things:

1. What is the cost of encoding a generative task in a prompt vs. directly producing the artifact? This is a function of the task, the model, and the user.
2. What is the cost of verifying the generated artifact meets requirements vs. a directly produced artifact? This is mostly a function of the task and the user, but also the generative model.
3. How much is the task dependent on the artifact vs. the process? This is a function of the task.

Many programming languages have some kind of representation of a stream, a sequence of bytes (or objects) that can be processed a chunk at a time, filtered, transformed, composed, pipelined, split, merged and so on. JavaScript is no exception, but historical peculiarities of the language have left it in kind of a bad place for the ergonomics of using streams. So this article discusses improvements that could be made. PL students take note: we’ve moved on from mere syntax and semantics to the squishy yet ultimately valuable worlds of ergonomics and pragmatics!

Huston describes a clever (ab)use of the DNS system to query the ASN-to-prefix mapping database. DNS is a global, replicated key-value store that is useful for much more than just mapping hostnames to IP addresses. See also this.

Geoff Huston’s annual review of BGP statistics from 2025:

At the start of each year, it’s been my practice to report on the behaviour of the Internet’s inter-domain routing system over the previous 12 months, looking in some detail at some metrics from the routing system that can show the essential shape and behaviour of the underlying interconnection fabric of the Internet.

See also the daily CIDR Report.

Classes teach you all about advanced topics within CS, from operating systems to machine learning, but there’s one critical subject that’s rarely covered, and is instead left to students to figure out on their own: proficiency with their tools. We’ll teach you how to master the command-line, use a powerful text editor, use fancy features of version control systems, and much more!

A quick overview of length extension attacks on constructions involving cryptographic hash functions. (TL;DR: Use HMAC; see the “How to do it right” section of the post.)

A three-part series from the Tailscale people on how they are thinking about and improving NAT traversal for peer-to-peer connectivity.

• Part 1, “NAT traversal, and how we’re improving it” (this linklog entry)
• Part 2, “Challenges in cloud environments”
• Part 3, “Looking ahead”

Another LLM agentic coding experience report. Detailed enough to learn something about what it’s actually like and what kinds of interventions are required. Hashimoto writes:

I’m an outspoken advocate about the importance of sharing agentic coding sessions publicly, with one of the reasons being that it’s an incredibly powerful way to educate others about how to use these tools effectively. I hope this post helps demonstrate that.

A recent stab at “personal cloud” network management.

Our mission is to make sure peer-to-peer, user-controlled, community software can beat Big Tech solutions. That’s why we’re working on platform fundamentals that would open the way for our FOSS stack to match the usability and convenience of proprietary platforms.

Musings on the topic of “input shapes” in context of fuzz testing (a powerful automated software testing technique), and why they are important:

I propose that there are two types of inputs: instruction-like and data-like. Of course, there is some overlap where, for example, an instruction contains data, or data contains instructions, but fundamentally, this is what inputs are consumed as by the program. For both of these types, you have three shapes: linear, tree, and directed graph.

Phil Eaton on orienting oneself when beginning the study of distributed systems:

Distributed systems is simply the study of interactions between processes. Every two interacting processes form a distributed system, whether they are on the same host or not. Distributed systems create new challenges (compared to single-process systems) in terms of correctness (i.e. consistency), reliability, and performance (i.e. latency and throughput).

Phil’s recommendations are to find a couple of friends and work together on reading Martin Kleppmann’s book Designing Data-Intensive Applications and working through MIT’s 6.5840: Distributed Systems course.

Extra for experts on database normalization and its benefits and tradeoffs. Our database course got as far as 3NF; “you are like little baby” etc., this post gets to “virtual 6NF”!!!! !!!

As software developers, we can solve any problem by adding one level of abstraction, and database modeling is not an exception. I’m going to show that any database could be represented as a number of relations in either 6NF or 4NF, and why it’s useful.

Broad high-level remarks on consensus in distributed systems from Graydon Hoare, originator of the Rust programming language and several other influential software projects.

The importance of (and tricks for) doing proofs about code you’re writing as you write it:

This is a brief write-up of a trick I learned that helps me write code faster and more accurately. I say “trick”, but it’s really something I started to do without noticing as I moved further into my career.

When you’re working on something difficult, sketch a proof in your head as you go that your code will actually do what you want it to do. A simple idea, but easier said than done: doing this “online” without interrupting your flow takes a lot of practice. But once you get really good at it, you’ll find that a surprising amount of the time your code will work on the first or second try. It feels a little magical.

(via John Regehr)

Investigation of the PostgreSQL query planner:

The basic promise of a query optimizer is that it picks the “optimal” query plan. But there’s a catch - the plan selection relies on cost estimates, calculated from selectivity estimates and cost of basic resources (I/O, CPU, …). So the question is, how often do we actually pick the “fastest” plan? And the truth is we actually make mistakes quite often.

An interesting perspective on the idea of caching:

I’ve always been told that caching is a tool to make software faster. […] My feelings now are that that perspective on caching is wrong, or at least incomplete. […] I think now caching is probably best understood as a tool for making software simpler.

Insight into (SQL) query planning:

This is a very simplified approach to thinking about join ordering, it ignores things like statistics, indexes, outer joins, and different join algorithms, but it is an important intuitional foundation.

A fascinating from-scratch construction of something approaching CRDTs starting from a much simpler idea, “server reconciliation”. You, yes you, can implement this!

Collaborative text editing is arguably the hardest feature to implement in a collaborative app. […] Or rather, that’s what I thought until recently. This blog post describes an alternative, straightforward approach to collaborative text editing, without Conflict-free Replicated Data Types (CRDTs) or Operational Transformation (OT).

Pretends a local machine’s containers are a little LAN, exposing that LAN to a browser (via a custom SOCKS proxy) to form a hyperlinkable namespace:

We have Ptyxis as a container-aware terminal emulator… why isn’t there a container-aware web browser that would just communicate directly with the containers? […] As the title suggests, now there kinda is a container-aware browser.

Ever wondered how Universities ended up as they are, as a class of institution? This article traces the history of the modern research university as an institution, having roots in 19th century Germany.

But something happened to German universities at the turn of the 19th century — they developed a new system that combined teaching with research. Within a few decades, everyone in Europe was trying to copy their model. […] Why Germany? Why universities? Why does the entire modern institutional research ecosystem look the way it does?

Oh my. IPv4 is complex. These posts discuss the idea of “unnumbered interfaces” in IPv4:

These blog posts will help you understand why IPv4 uses interface addresses, what we can gain with unnumbered IPv4 addresses, how they work over Ethernet links, and how they interact with routing protocols.

An interactive web tool that simulates various garbage collection algorithms running over a user-specified concrete heap. Also illustrates a simple tagging/object-header scheme. (Note that the “About” page is hidden away in a hamburger menu at the top right.)

Discussion of segmentation offload, coalescing small packets into larger ones before bringing them to the attention of the networking stack (on the receive path) and splitting large packets into smaller ones just before they hit the wire, outside the kernel (on the send path).

A very good talk about the fundamentals of high-performance CPUs, plus tooling for experimenting with and measuring low-level performance characteristics, from Matt Godbolt, who also runs the Compiler Explorer.

Presented at GOTO Chicago 2024.

• Talk summary page
• Slides

An elegant example of FP for the FP portion of my PL course:

A simple, useful, plain-text variant of Donald Knuth’s paragraph-filling algorithm can be expressed as a fold. This algorithm runs in time linear to the length of its input and usually produces better results than the classic greedy text-flow algorithm.

This post surveys the deployment and correctness of fq_codel and sch_cake, two “smart queue management” algorithms designed to combat bufferbloat by keeping network latency low under load.

A rigorous approach to threat modelling. Well, more rigorous than Soatok’s Informal Guide to Threat Models, anyway. Documents the values, principles, and key characteristics of threat modelling as an industry practice. Covers patterns, anti-patterns, and overall philosophy.

Arcan is an alternative approach to display servers and UI, drawing inspiration from object capabilities, Plan 9, malleability and much more. This blog post motivates and gives an overview of the project; see also the main project page.

The Noise Protocol Framework underpins secure communication protocols including e.g. WhatsApp, WireGuard and many others. I’ve used it in my own work. Well worth a read.

Makes explicit the connection between the Visitor design pattern and sum types (a.k.a. tagged unions / algebraic data types).

An excellent paper that skewers the common cultural understanding of the C programming language as being a “low-level” or “portable assembly” language. Modern CPUs have diverged so far from the C abstract machine that C no longer provides predictable “close-to-the-metal” guarantees.

A concrete and formal definition of memory safety from (inter alia) Benjamin C. Pierce.

We give a rigorous characterization of what it means for a programming language to be memory safe, capturing the intuition that memory safety supports local reasoning about state.

Paper in the proceedings of the Principles of Security and Trust conference 2018.

Development of incremental improvements to a pure-functional quicksort implementation, eliminating multiple passes over the input and unnecessary append operations by introducing accumulators.

Avery Pennarun (one of the original authors of Tailscale) summarises the state-of-the-art wisdom with respect to network queue management. Bookmark this to come back to when you need it.

How big should your queue be, and what should you do when it fills up? Many times, we implement or even deploy a networking system before we have answered those questions. Luckily, recent research has given us some guidelines. Here’s what we know: […]

An examination of several approaches to handling overload, flow-control, and backoff, with examples drawn from Erlang/OTP programming.

[…] there is a rich zoo of overload problems and potential solutions […] ranging far beyond a simple queue boundary for mailboxes. By reasoning and looking at your system, it becomes interesting to figure out which approach is best: a small system with some relatively infrequent load-spikes may be fine with a queue or a pull-based mechanism. An all-synchronous system may be fine with simple counter-based protection for most tricky cases. […]

Slides with tips on writing a (Dutch) Bachelor’s thesis in Computer Science, including advice not only on structure and content but on academic writing style.

A TCP edge-case: a client can connect to itself!

Note that you didn’t start any server and there is no process listening on port 50000 on localhost, but yet, it connected! […] What happened? In short, client connected to itself. :)

Neel Krishnaswami remembers John Reynolds. One particular quote that struck me (highlighted by Lindsey Kuper) is this:

So this was John [Reynolds]’s definition of a successful language design: if you have a user who has used it to write a program you couldn’t have, your language has succeeded, since it has helped a fellow human being solve one of their own particular problems.

I’ve always liked his definition, since it manages to avoid an obsession with nose-counting popularity metrics, while still remembering the essentially social purpose of language design.”

Programming languages are about people!

Discussion of different approaches to complex multi-stage SQL queries, in light of one specific example.

Pragmatics of database design: the argument for soft-delete (marking records as deleted rather than actually removing them).

Let’s say our marketing department decides to delete an item from the catalog. Should all previous orders containing that item just disappear? And cascading farther, should all invoices for those orders be deleted as well? Going on, would we have to redo the company’s profit and loss statements?

Tony Finch (April 2025) points out an important exception to the idea of just using IsDeleted flags, however:

The main counterexample is data protection law. You have to be able to delete personal data. This article predates the GDPR so it has a reasonable excuse for not taking it into account.

The OOPSLA 1997 paper that introduced Squeak, a Smalltalk implementation “written in itself”:

Squeak is an open, highly-portable Smalltalk implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. To achieve practical performance, a translator produces an equivalent C program whose performance is comparable to commercial Smalltalks.

The paper discusses the bootstrapping process, the VM’s object format and garbage collector, the Smalltalk-subset-to-C translation process, the implementations’ approach to the BitBlt graphics primitive, performance, and the fledgling Squeak community. The latter is still going strong thirty-some years later.

A collection of 100 impossibility results and some discussion of commonalities and differences among them:

This talk is about impossibility results in the area of distributed computing. In this category, I include not just results that say that a particular task cannot be accomplished, but also lower bound results, which say that a task cannot be accomplished within a certain bound on cost.

You may ask yourself why impossibility proofs are important: my answer is that if you don’t know what’s impossible, you run the risk of wasting a lot of time trying to achieve the unachievable!