A sovereign social network
powered by Bitcoin

A program compiled in 1996 just ran untouched on a kernel built this year. That's not an accident. One man has forced the kernel to keep real, documented bugs alive on purpose for over three decades just so this would keep working. No recompile, no patch, nothing bolted on top to make it work. Normally a 30-year-old binary meeting a brand new kernel means a crash or nothing at all. This one printed its output like it never left. One rule since 1991. How does a single sentence outrank three decades of hardware and software changing underneath it? The rule has a name. We do not break user space. Linus Torvalds wrote it in capitals because lowercase apparently wasn't clear enough. Here's what it actually covers. Every syscall a program can call, the text formats under proc and its sys, every ioctl a driver exposes to the outside world. That's the direct command channel between a program and a device driver. If a program observed a certain behavior yesterday, the kernel is not allowed to quietly change that behavior tomorrow. Not through an update, not through a security patch. And here's the part that surprises people. It doesn't matter if the program was using the interface wrong. If your code depended on a quirk, a race condition, even a documented bug, and a new kernel breaks it, that's a kernel regression, not your mistake, the kernel's. It even covers the boring stuff. A text file under proc that scripts have been parsing with awk since the '90s has to keep the same columns in the same order indefinitely because somewhere a monitoring script written by someone who's long since left the company is still reading it every 60 seconds without fail. A script nobody remembers writing, reading a file nobody wants to touch, and the kernel still has to honor it. Sound insane? That's the rule. So in 1991, there was no written rule. Linux was one developer and a hobby project posted on a newsgroup as just a hobby, won't be big and professional. Nobody was promising anything to anyone because there was nothing yet worth breaking. The doctrine hardened over the next decade as real companies started shipping real products on top of it. Once banks, phone carriers, and stock exchanges had production systems running on Linux, it still works on the new kernel. Stopped being a courtesy, it became the entire business model. December 20, 2012 is the incident people point to. A kernel change shipped that swapped one error code for another, deep in low-level plumbing most programs never look at, and it broke PulseAudio, the audio system millions of desktops depended on. The kernel maintainer's first instinct was to blame PulseAudio for depending on behavior it shouldn't have. Sound familiar? Linus disagreed publicly in a mail on the kernel mailing list to Mauro Carvalho Chehab on December 23rd. Reports describe the reply as blunt, even furious. The core of it, paraphrased, a kernel that breaks a working program is broken, full stop. It doesn't matter whose fault the breakage technically was. That's the line that turned a habit into a law. Therefore, from that point on, the app was wrong stopped being an acceptable excuse inside the kernel community. Here's the part almost nobody put side by side. Inside the kernel, there are two completely different worlds, and they live under opposite rules. The syscall table, the door every program on Linux walks through to read or open a socket is frozen. Those numbers on screen have meant the same thing for decades. That's the user space ABI, the fixed contract of interfaces a program can rely on, and it's sacred. But go one layer deeper into the interfaces between the kernel and its own internal drivers, and there is no such promise. None. Greg Kroah-Hartman, one of the kernel's most senior maintainers, wrote an entire document explaining why. The file is literally named stable API nonsense, and the position is simple. Internal driver interfaces change whenever the kernel needs them to, on purpose, every single release. That's why an Nvidia module built for kernel 6.8 refuses to load on 6.9, and why DKMS exists at all. A whole tool built just to recompile drivers every time the kernel underneath them moves. Enterprise Linux vendors sell entire support contracts on the difference. User space binaries from a decade ago still execute untouched, while the driver layer underneath gets rebuilt on every update. So, on Linux, user software ages better than drivers. That's backwards from almost every other system you've used. Or is it the only sane way to run a platform this old? The 1996 binary and the syscall table timeline are on Patreon. But the sacred rule has a price, and it shows up in specific documented moments. Kernel 5.3 in 2019 made getrandom stricter for security reasons. On some systems, that call blocked during early boot, waiting on entropy that hadn't accumulated yet. Machines that simply wouldn't finish starting. The fix that followed in 5.4 taught the kernel to generate its own entropy fast enough that the block resolves in about a second. It's a concession, not a reversal. The kernel still isn't allowed to leave you standing at a black screen. ext4 did something similar in 2009. Its delayed allocation feature was technically correct by the POSIX standard, and it still ate people's configuration files on power loss. Ted Ts'o and the ext4 team didn't rip the feature out. They added heuristics on top of it, tuned specifically to keep files behaving the way users already assumed they behaved. And some syscalls just never leave. oldoldname, uselib, nobody writes new code against them, and they're still in the table because something out there still might. Same story with the text formats under ./.proc. Nobody loves the exact column layout of a file like ./.proc.stat. Plenty of engineers would redesign it tomorrow if they could. Why can't they? Because the rule doesn't ask whether the format is good. It only asks whether something still parses it. Therefore, here's the cost nobody puts on the thumbnail. Every bug that became expected behavior stays forever. A decision made in 1995 is still restricting what the kernel can do in 2026 because someone, somewhere, is still depending on it. But notice where the rule stops. It only covers the kernel. Distributions rip out packages. glibc changes function signatures. Desktop environments redesign themselves into unrecognizable shapes every couple of years. None of that is protected. The rule was never a rule about Linux the platform. It's a rule about one specific, narrow promise. The kernel, and only the kernel, will not move the ground under you. So, Linux breaks things constantly, and Linux never breaks things, are both true statements. They're just describing different floors of the same building. Ask a kernel developer whether that trade is worth it, and most will say yes without hesitating. Ask them to name the specific quirk they personally wish they could delete, and you'll usually get a long pause first. Would you sign up for that trade? Personally, I would. That's the best deal in software, bugs included. So, this is why containers work at all. A Docker image built in 2015 runs on a kernel from 2026, because the syscall ABI between them never moved. Compare that to Android. It runs the Linux kernel. Same rule, same guarantee underneath. And yet, apps break constantly between Android versions. Permissions models get rewritten, background services get killed off, and developers scramble every release cycle to keep up. Same kernel underneath. Why does it feel so different? Therefore, the contradiction resolves itself once you separate the layers. The promise lives in the kernel. Everything Google built on top of that kernel, the framework, the APIs, the app model, made its own choices, and none of them signed the same contract Linus did. So, every other platform asks developers to keep up. Linux asks the kernel to instead. Not glamorous, is it? But, it's why a program older than most of its users still runs. There is one place the rule doesn't reach, hardware. This year, Linux dropped a CPU from 1989, and Linus signed off on it. That video is right here. 30 years old, still running, still obeying a rule nobody's allowed to break.