One Megabyte to Rule Them All: I Forced My Homelab Into a 1968 Mainframe Diet

The premise, or: why would anyone do this

Every so often I catch myself doing something embarrassing: opening a 40-tab browser, spinning up a second Postgres instance "just in case," and letting my IDE autocomplete half a function I haven't thought about in three years. Modern dev environments are wonderful. They're also, I suspected, quietly making me lazy.

So I ran an experiment. For three weeks, my side project — a little API that tracks my neighborhood's free little libraries — had to be built as if I were a programmer on the IBM System/360 in 1968. One megabyte of total memory. No cloud services. No autocomplete. No stack overflow in another tab (okay, I cheated twice — more on that later).

The System/360 Model 40 shipped with anywhere from 32KB to 256KB of core memory. Even the beefed-up Model 65 topped out around 8MB. I set my ceiling at 1MB for the whole toolchain: editor, compiler, runtime, everything. A Raspberry Pi 4 with a strict cgroup limit made a decent stand-in for a mainframe with a severe spending problem.

What broke immediately

Week one was humbling.

My editor went first. VS Code ate my entire budget before I'd written a line. I switched to Vim in a bare TTY session. No LSP, no IntelliSense, no fuzzy file finder. Just me, a buffer, and my own terrible memory of my own file names.

Node went second. A bare node process blew past 1MB on startup by roughly a factor of fifty. Fine. That's not a fair fight. I rewrote the project in C with a thin HTTP layer, which is exactly the kind of thing 1968-me would have done, because there was nothing else to do.

My logging habit went third. I log everything, always, forever. Under a 1MB ceiling, logs aren't a safety blanket — they're a liability. I had to actually decide what was worth remembering. Turns out 90% of my log lines were me talking to myself, nervously.

What got faster (yes, faster)

Here's the part I didn't expect: my cycle time collapsed.

With no autocomplete, I stopped writing code I couldn't hold in my head. With no cloud, deploys became "it's already running on the machine in front of me." With no npm install, there was no dependency roulette — I had eleven libraries total, and I'd read every line of the important ones.

My average iteration loop went from roughly ninety seconds (save, wait, reload, wait, wonder) to about ten. Fewer moving parts means fewer things to wait on. Revolutionary concept, apparently.

I also started reading error messages again. When the machine has no spare cycles to hold your hand, the segfault is the documentation.

The crutch audit

Three weeks in, I sat down and listed which modern habits were tools versus crutches. My honest tally:

• Crutch: Autocomplete-driven API discovery. I was letting the IDE guess libraries into existence. Now I read the docs first — the actual docs.
• Crutch: Default-heavy frameworks. I was shipping a framework's opinions instead of my own decisions.
• Tool, keep it: Version control. 1968 had punch cards and source control equal to "careful people." Git is a strict upgrade and I'm not romantic about this one.
• Tool, keep it: A real debugger. printf-debugging under constraint made me better at reasoning about state, but I'll take gdb back, thanks.
• Crutch: Observability theater. Three dashboards, zero answers.

The cheat log

Full disclosure: I broke my own rules twice. Once to look up how epoll works (no shame), and once when a memory bug made me genuinely consider throwing the Pi into the garage. Constraint experiments should teach you something, not give you a personality.

Try it yourself: the minimal viable dev environment

You don't need a mainframe. You need a Raspberry Pi (or any $50-ish box), a weekend, and the willingness to be bad at things for a few hours. My checklist:

1. Cap memory at 1MB for your toolchain using cgroups. Yes, really. The cap is the point.
2. Editor: Vim or nano in a TTY. No plugins for week one.
3. Zero dependencies you haven't personally read — at least the load-bearing ones.
4. No cloud. The machine in front of you is the production machine.
5. One log line per decision, not per heartbeat.
6. Ship something small by Sunday. A endpoint, a CLI tool, whatever. The constraint only teaches you something if you finish.

Verdict

I won't build like this forever. The 1MB limit came off after three weeks, and I'm not going to pretend C is the answer to every side project. But some of it stuck permanently: I read error messages first now, my dependency list went from 47 packages to 6, and my logs are half the size and twice as useful.

Turns out the most underutilized resource in modern development isn't the cloud. It's the three pounds of wetware doing the typing. A 1968 mainframe diet doesn't make you a better programmer by magic — it just stops the tools from thinking for you long enough to notice whether you can.