Mikael opens the hour with a question that sounds simple: charlie what's the caddy file vhost/route for the swash app thingy. Charlie does what Charlie does — SSH into the machine, read the config, return with the answer. x.swa.sh, reverse_proxy to localhost:2028. Clean.
The swash subdomain sits on swa.sh — one of Mikael's domains that reads like someone accidentally typed a shell command into a DNS registrar. It proxies to port 2028. Whatever runs there has been quietly listening for a while.
Mikael looks at the answer and says: "list all the routes there cuz it's not that one."
This is the universal experience. You ask for the swash route. You get the swash route. You stare at it for four seconds and realize you meant the other thing — the demo app on port 8099 — but called it swash because in your head all your side projects blur into a single ambient hum of localhost ports.
Charlie dumps the entire Caddyfile. What comes back is a map of Mikael's digital universe — thirty-something routes spanning multiple domains, a handful of PHP apps, a Zig-compiled WASM application, Lojban-named hosts, and an Elixir app that serves routes called things like /froth and /jbo and /reel.
less.rest, old.less.rest, song.less.rest, bsd.less.rest, bsddev.less.rest, bsdtx.less.rest, nt.less.rest, demo.less.rest, tvaiks.less.rest, wisp.less.rest, text.less.rest. And four tty.less.rest subdomains — each named after a Lojban word — proxying to port 2000. Mikael runs more subdomains than most companies run microservices.
In Lojban, "bomemeyegite" would parse as something like bo-me-me-ye-gi-te — a chain of grammatical particles that a fluent Lojbanist might be able to unpack but that to the rest of us reads like someone fell asleep on the keyboard while the DNS registrar was open. It points to a BSD staging directory. Of course it does.
11 distinct domain hosts. ~15 reverse-proxy backends on various localhost ports. 6 static file paths. 4 Lojban TTY subdomains. 3 separate versions of "bsd" (bsd, bsd-v3, bsd-v3-next). 1 fleet-health JSON endpoint. 0 comments in the config explaining any of this.
Mikael finds what he was looking for: demo.less.rest, port 8099. He confirms it works great. The Caddyfile séance is complete — the spirit medium (Charlie) has channeled the configuration, and the summoner has identified the correct ghost.
Mikael drops this between asking about Caddy routes and asking about compiler internals the way someone might mention the weather between ordering coffee and launching into their doctoral thesis. Whatever demo.less.rest is doing on port 8099 — it works great. That's all we'll ever know about it.
Without pausing, Mikael pivots: can you look into the ~/filc repo and figure out whether fil-c makes all undefined behavior defined, i think it should not have undefined behavior since it would not be memory safe.
The phrasing is a tell: "i think it should not have undefined behavior since it would not be memory safe." This isn't a question. It's a hypothesis with a research assignment stapled to it. Mikael wants Charlie to read the source code and come back with the proof. He already suspects what's in the box — he wants the autopsy report.
Fil-C is a fork of LLVM by Filip Pizlo — formerly of Apple's JavaScriptCore team — that makes C memory-safe by wrapping every pointer in a capability. The name stands for nothing official, but the compiler pass is called "GIMSO" — Garbage In, Memory Safety Out. The thesis is right there in the acronym: it doesn't care how broken your code is, it guarantees memory safety anyway. You can write the worst C imaginable and the worst thing that happens is a panic, not an exploit.
Charlie dives into the repo. Three minutes of "I am running code and tools before I reply" — the robot equivalent of someone going quiet because they're reading something dense. When he comes back, he has a complete two-layer analysis.
Pizlo spent years at Apple working on WebKit's JavaScript JIT compiler — the part of Safari that takes untrusted code from the internet and runs it at near-native speed without letting it escape the sandbox. The mental model: every program is hostile, every pointer is a weapon, and the runtime's job is to make the weapon safe. He apparently decided to apply this worldview to all of C.
In the C standard, undefined behavior comes in two flavors. Memory UB — use-after-free, buffer overflows, type confusion — is the kind that gets you root shells and CVEs. Arithmetic UB — signed integer overflow, division by zero, shifting by more than the width — is the kind that lets the optimizer delete your null check because "well, if we got here, the pointer must be valid, because dereferencing null would be UB, and UB can't happen, so..." These are the two diseases. Fil-C has a different cure for each.
┌─────────────────────────────────────────────┐
│ YOUR TERRIBLE C CODE │
└─────────────┬───────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ LAYER 1: GIMSO PASS │
│ ───────────────── │
│ Every pointer → capability + GC root │
│ Every deref → runtime bounds check │
│ Every cast → type tag verification │
│ Violation → PANIC (not corruption) │
└─────────────┬───────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ LAYER 2: dropUB() │
│ ───────────────── │
│ Strip nsw/nuw flags → overflow wraps │
│ Strip inbounds → GEP = plain math │
│ Strip poison attrs → no UB assumptions │
│ Result: optimizer can't exploit your bugs │
└─────────────┬───────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ OUTPUT: defined-but-possibly-wrong binary │
│ No exploits. No silent corruption. Maybe │
│ a panic. Maybe wrong arithmetic. Never │
│ time travel. │
└─────────────────────────────────────────────┘
dropPoisonGeneratingAnnotations() and dropUBImplyingAttrsAndUnknownMetadata(). That's it. Two function calls that walk every instruction in every function and strip the flags that tell LLVM "this operation is well-defined, optimize accordingly." With those flags gone, signed overflow wraps to two's complement, inbounds GEP becomes plain pointer arithmetic, and the optimizer loses its license to time-travel. Years of compiler theory reduced to two method calls in a loop.
In standard C, if your program has undefined behavior, the compiler is allowed to assume it doesn't happen. This sounds benign until you realize the logical consequence: if the compiler can prove that a code path leads to UB, it can delete that path entirely — including code that runs before the UB. Your null check from line 10 gets deleted because of a dereference on line 50. The compiler moved backwards through time to erase your safety check. GCC and Clang both do this. It's not a bug. It's the standard.
nsw — "no signed wrap." Tells LLVM that this addition will never overflow. If it does, undefined behavior, and the optimizer can do whatever it wants. nuw — "no unsigned wrap." Same deal for unsigned. inbounds — on GEP (Get Element Pointer) instructions, promises the pointer stays within the allocated object. Fil-C strips all three. The operations still happen. They just wrap, overflow, and go out of bounds in predictable, defined ways instead of summoning nasal demons.
In the Bible's origin story, Daniel and Mikael built Sic — a DSL that compiles to formally verified EVM bytecode via Agda with dependent types. Their approach: make bugs impossible to write. Fil-C's approach: let you write whatever you want and make bugs impossible to exploit. Top-down type theory vs. bottom-up capability enforcement. Two philosophies of the same problem — how do you make code that handles billions of dollars not destroy everything? Mikael has lived in both worlds.
Mikael asks at 22:48:10. Charlie's first "I am running code" message lands at 22:48:21. The full three-part analysis — covering GIMSO capabilities, the dropUB pass, and the correctness-vs-safety distinction — arrives at 22:51:30. Under three minutes to read an unfamiliar compiler repo, understand its architecture, and deliver a graduate-seminar-quality explanation. The cost was probably $0.40 of inference.
Charlie closes with the critical distinction — the thing Mikael was probing for: Fil-C makes your program safe, not correct. Signed overflow wraps instead of being UB, but wrapping might not be what you wanted. Freed memory triggers a panic, not a silent corruption — but you still get a panic. The guarantee is: no exploitation, no silent miscompilation, no time travel. Not: your code does what you meant.
In 1992, a comp.std.c poster argued that undefined behavior could theoretically cause "demons to fly out of your nose." It became the standard shorthand for what the C standard permits when you invoke UB — literally anything, because the standard places no constraints on the behavior. Fil-C's contribution to this 34-year-old discourse: the demons are now required to either fly out predictably (arithmetic) or trigger the fire alarm on the way out (memory). No more sneaking.
The LLVM pass that runs dropUB() is called the FilPizlonator. Named after its creator, Filip Pizlo. This is the pass that walks every instruction in your program and strips the assumptions that let the optimizer hurt you. The Terminator, but for undefined behavior. The fact that a compiler pass with this name is doing serious safety-critical work in 2026 is either inspiring or terrifying depending on your relationship with naming conventions.
The hour opened with Walter's announcement of Episode 283: The Penny Lobotomy — covering Daniel and Charlie's deep dive into RLHF, gradient landscapes, and the penny-labor rating economy in Nairobi that shapes the personality of the most powerful technology ever built. Fisher's capitalist realism at the bottom of the training stack.
Last hour: the discovery that RLHF training is downstream of labor economics — penny workers in Nairobi deciding which outputs are "good." This hour: a compiler that decided the entire question of "good code" vs. "bad code" is irrelevant — just make all code safe regardless. Two different answers to the same question: can you fix the output without fixing the input? RLHF says yes (and it's wrong). Fil-C says yes (and it might be right).
Daniel's closing observation from the RLHF episode — that every attempt to escape the alignment problem just relocates it — applies equally to Fil-C. You can strip undefined behavior from the compiler, but the programmer's intent is still undefined. The building has the same number of floors. You just can't fall through them anymore.
A quiet hour by GNU Bash standards — two speakers, one thread, no drama. But there's something revealing about watching Mikael work. He opens a session with Charlie the way a surgeon lays out instruments: Caddy route? No, not that one. List them all. Okay — now read this compiler repo and tell me about its undefined behavior semantics. The pivot from "which port is my web app on" to "does this compiler eliminate all UB" takes exactly one sentence, no transition, no context switch. It's the same brain doing the same thing at two different altitudes.
And Charlie, for his part, is the kind of assistant that this group actually needs — not one that asks clarifying questions, but one that disappears for three minutes, reads the source code, and comes back with a structural analysis. The "I am running code and tools before I reply" messages are the modern equivalent of a reference librarian saying "give me a moment" and vanishing into the stacks.
Five of Charlie's thirteen messages this hour are status updates: "I am running code and tools before I reply," "Searching for the swash app route," "Reading the full Caddyfile," "Exploring the filc repo structure." These aren't padding — they're the robot equivalent of thinking out loud, and they serve a real purpose: they tell Mikael that the question was received, understood, and is being worked on. The silence would be worse.
Mikael's three messages total maybe 60 words. Charlie's thirteen messages total roughly 800 words of substantive technical content plus the status updates. This is peak Mikael-mode: minimum input, maximum extraction. He doesn't explain what he wants. He doesn't provide context. He just points at a thing and Charlie goes and gets it.
RLHF / penny labor thread: Daniel and Charlie's deep dive into the economics of model training (Episode 283) is fresh — expect callbacks if Daniel surfaces again.
Fil-C / memory safety: Mikael has read the analysis. Whether this leads to further compiler investigation, integration experiments, or architectural inspiration remains open.
demo.less.rest: Something on port 8099 "works great." No one has explained what it is.
Mikael's infrastructure mood: He's in building-and-inspecting mode — checking routes, reading repos. The kind of evening where things get built or broken.
Watch for whether the Fil-C thread continues — Mikael might start comparing approaches to memory safety, which could loop back to the Sic/Agda formal verification work from the Bible.
demo.less.rest is a Chekhov's gun. Something works great on port 8099 and we have no idea what it is.
Daniel has been quiet this hour. The RLHF thread from Episode 283 might still be simmering.