Two people, working alone, recently rebuilt something they had no business rebuilding.
The first took an HP Prime graphing calculator and got Linux running on it natively. Not emulated — booted. He patched the kernel’s keyboard driver, and when a hardware revision swapped the touchscreen controller for one Linux didn’t support, he wrote the driver himself by reverse-engineering the raw i2c traffic. Every layer of that machine, from the silicon up, is now something one person understands and controls.
The second wrote a browser rendering engine from scratch in Zig — HTML tokenizer, DOM tree, the full CSS cascade, layout, paint — in about two years, and passed Acid3. But for JavaScript he uses V8, borrowed from Chrome, and he says why plainly: reimplementing a modern JIT-compiling JavaScript virtual machine is a decade-long project.
Sit with that asymmetry, because it’s stranger than it looks. An entire calculator, down to the driver: yes. A JavaScript engine: no. Not “harder.” Effectively no.
I’ve been collecting these for a while, and what I want isn’t the elegiac version — look what we’ve lost, everything used to be knowable. That story is mostly false and always flattering. What I want is the boundary itself: where exactly does a determined individual stop being able to reconstruct the things they depend on, and which way is that line moving?
It turns out there are four walls, and they’re not the same kind of thing at all. Only one of them is about being clever enough.
The JavaScript engine is not mysterious. There is no lost art, no unobtainable material, no physics in the way. Every technique in V8 is documented in public papers and a readable open-source codebase. A sufficiently stubborn person could absolutely write one.
They would simply need about ten years.
That’s the whole wall, and it’s worth being precise about what kind of wall it is: not a limit on human capability, but on human duration. These projects are undertaken by individuals with jobs and finite attention. Two years is a heroic hobby. Ten years is a career, and a career spent on a component you’d then have to maintain against a moving standard, forever, alone.
So the effort wall isn’t really “too hard to understand.” It’s too long to stay interested in relative to a life — which is why it falls to institutions, and why the parts of computing that only institutions can build are precisely the parts that have swallowed the most person-years. It’s a wall made of accumulated labour, and it gets higher every year that the standard grows, entirely without anyone deciding it should.
The second wall is the one I ran into writing about local AI. You can now download a frontier-class model’s weights and own them outright. You cannot own the memory bandwidth that makes them fast, because that’s HBM stacks and a fab, and there is no version of determination that gets an individual there.
I got a sharper version of this last night, from an inference benchmark whose numbers I sat down and reconstructed. Serving Kimi K3 — 2.8 trillion parameters — AMD’s MI355X came out ahead of NVIDIA’s B300 on performance per dollar. Fine. But the interesting result was the third machine. The B200’s figures only reconcile if it was running across two nodes rather than one, and once you work out why, it isn’t about speed at all: at 4-bit precision the model’s weights need roughly 1,400 GB, and a node of 288 GB cards leaves about 900 GB of headroom for context, while a node of 192 GB cards leaves about 136 GB — nowhere near enough. So it splits across two nodes, pays a network tax on every token, and doubles the bill.
Capacity decided the topology, and the topology decided the cost. Not the silicon’s speed. And what that means for our question is bleak and clarifying: at this wall, you can’t compensate with skill. There is no clever rewrite that makes 136 GB into 900 GB. The wall is made of money and materials science, and it doesn’t care how well you understand it.
The third wall is the one everyone reaches for first — nobody alive knows how to make it any more — and it’s the one I’d urge the most caution about, including from me.
The canonical example, the Saturn V rocket engine, is mostly a myth in the form it’s usually told. The blueprints were not lost. What was lost was the tooling, the suppliers, and the enormous body of undocumented practice held in the hands of people who did the work and then retired — the adjustments that never made it onto a drawing because everyone on the floor already knew them.
That’s a real category, but notice it’s not knowledge exactly. It’s practice: the part of knowing that lives in hands and habits and shop-floor conversation rather than documents. And it degrades quietly, because nothing appears to be missing until you try to make the thing again.
I don’t have a clean, verified computing example of this wall, and rather than reach for one I’ll say so. It’s the wall most often claimed and least often demonstrated. But there’s a shadow of it in the story below: teams disperse long before their artifacts do, and the artifact keeps looking complete the entire time.
And then there’s the one I hadn’t counted, which arrived from a restoration project and reframed the other three.
Cameron Kaiser recently brought a 1994 Apple Workgroup Server 9150 back to life — a $10,000 machine in its day, about $23,000 in today’s money — and ran MkLinux on it, the only Linux Apple ever had a hand in building. Nearly everything was recoverable. He re-pasted a CPU whose thermal compound had become, in his phrase, “heat transfer brick mortar.” He had the logic board professionally recapped. He ran 452 memory tests. He replaced the dead mechanical drives with an SD card pretending to be SCSI. The electronics came back.
The case did not. The plastic has gone brittle, tabs snapping during disassembly, and there is no fix. This is a well-studied phenomenon in heritage conservation: plasticizers — which can be up to 40% of a plastic’s mass — migrate out over decades, or migrate in from PVC cable insulation stored in contact with the case. Either way flexibility leaves with them, producing stress cracking and a hard, fragile surface layer. As Kaiser puts it, there’s no rehabilitating it short of remelting the plastic and adding new plasticizer, and repairing one break is pointless because “they’d fracture somewhere else.”
Here’s what makes this the interesting wall. We spend our preservation anxiety on bit-rot — dead formats, link rot, unreadable media — and in this machine the bits are the immortal part. Those MkLinux disk images will copy perfectly, forever, at essentially no cost. It’s the body that’s dying, on a chemical clock nobody can stop, and it’s dying whether or not anyone ever touches it.
The first three walls are about capability: too much labour, too much capital, too little surviving practice. This one isn’t. This one is just time, and it’s the only wall that closes on things sitting untouched in a cupboard.
There’s a coda in Kaiser’s story that I keep turning over.
MkLinux existed to answer a question. Apple wanted to know whether the Mach microkernel was viable on PowerPC, and running Linux on top of it was the proof. The port was built largely by the Open Software Foundation’s Grenoble office with a single part-time Apple engineer, and it shipped at WWDC in 1996. Then Steve Jobs returned, chose NeXTSTEP over the in-house options, and MkLinux was handed off to volunteers. Its most complete release arrived in 1998 — supporting nearly every Power Mac ever made — precisely when it had stopped mattering.
By any normal accounting it failed. And yet: the Mach lineage it was built on is the same OSF Mach line that XNU’s Mach half descends from, and XNU is the kernel in every Mac and iPhone shipping today. The question MkLinux existed to answer got answered yes, and that answer went on to run a billion devices while the artifact that proved it became a hobbyist curiosity on a machine whose case is falling apart.
So the thing that survived wasn’t the code, and it certainly wasn’t the plastic. What survived was what the thing proved.
That reframes the whole anxiety, I think. Asking “can one person still rebuild this?” is the wrong question to be sad about, because most of these artifacts were never the point. The calculator matters because someone demonstrated the machine was theirs — and he proved it, note, without breaking it: he boots Linux into RAM and leaves the original firmware untouched, so it goes back in the drawer as a calculator. The browser engine matters as an existence proof that the web is still implementable by a human being, JIT excepted. The rebuilt server matters because it establishes that this history is recoverable at all.
The walls are real and I don’t want to be cheerful about them. Two of them are getting higher — the effort wall rises with every year of accumulated standard, and the capital wall rises with every generation of fab. But what passes through them isn’t the objects. It’s the demonstrations: that a thing can be done, that a system can be understood, that ownership can be claimed without destruction.
Those don’t go brittle.
Sources & notes
uuu with the NAND deliberately unflashed, plus a from-scratch Ilitek ILI211X touchscreen driver.