Linus Torvalds' Unforgettable 'WE DO NOT BREAK USERSPACE' Rant

Level 1: Don’t Break Their Toys

Imagine you and your friends are playing with a big train set that spans the whole room. You’ve built this elaborate track over time. One day, the kid in charge of the tracks (let’s call him Linus) decides to replace a bridge piece with a different one without telling anyone. Suddenly, your friend’s train – which had always run smoothly – crashes at that new bridge. Your friend is upset, saying “My train keeps derailing here now!” Now, how do you think the track-builder should respond? Should he say, “Your train must be defective”? Of course not! The train was fine before the track was changed. The fair thing is for the track-builder to admit the mistake: the new bridge piece is wrong for this track, and it’s making the trains crash. He should fix his part – put the old bridge back – rather than telling your friend to go fix the train.

In this meme story, Linus (the track-builder in our analogy) is super angry because one of his helpers put a wrong piece into the “track” of the Linux operating system, and some “trains” (user programs like sound apps) started crashing. The helper suggested maybe the “trains” were at fault, but Linus shouted, “No way, it’s our fault – we never break the things people depend on!” It’s like he yelled, “Don’t break their toys!” because those programs are like the toys built on top of the operating system. The big lesson? If you’re responsible for the foundation (the tracks), you must not break other people’s creations (the trains running on those tracks). And if you do break something, you fix the foundation rather than blaming the toy that fell apart. The reason this is funny (in a surprised kind of way) is because of just how loudly and bluntly Linus delivered that message – picture a normally calm teacher suddenly shouting because a basic rule was broken. It’s an over-the-top reaction, but it drives the point home: keep things working for the people using them, no matter what.

Level 2: Don’t Blame the App

Let’s break down what’s happening in this meme in simpler terms. We’re looking at an email exchange from the Linux kernel mailing list, which is where Linux developers discuss changes to the core of the operating system (the kernel). Linus Torvalds – the creator and lead maintainer of Linux – is replying to another developer (a maintainer of a part of the kernel) named Mauro. The issue? Mauro submitted a patch (a code change) that caused a bug: it made some user programs start misbehaving. In particular, after Mauro’s change, audio programs like PulseAudio (which manages sound on many Linux systems) and KDE media players started to fail or loop endlessly. These programs live in user space, meaning they are ordinary applications running on top of the OS, as opposed to code running inside the kernel. Before the patch, these apps worked fine on Linux. After the patch (in the brand new Linux 3.8-rc1 test version), they broke. That’s what we call a regression – something that used to work in an older version of software stops working in the newer version.

Now, in Linux development culture, one strong rule is: if a kernel change breaks a user-space program, the kernel change is wrong. In plainer words, don’t blame the app. The app was working before; it didn’t suddenly get worse – the infrastructure (kernel) under it changed. So the responsibility is on the kernel developers to not break backward compatibility. This concept is known as maintaining backward compatibility or not breaking the ABI (Application Binary Interface). It ensures that when you update your system’s kernel, you don’t have to also update or fix all your applications – they should just keep running as before.

Mauro, the maintainer who made the patch, saw PulseAudio acting weird and initially suggested “that seems a bug at PulseAudio” – basically saying maybe the application is doing something wrong if it can’t handle the new kernel behavior. That suggestion triggered Linus’s angry response. Linus bluntly tells him to shut up and lays down the law: the kernel introduced the change, so the kernel is at fault for breaking the apps. He reminds Mauro (and everyone else reading) that “We NEVER blame the user programs” in such cases. This might sound obvious, but apparently Mauro needed the reminder, and Linus delivered it with fury.

The technical detail at the heart of this is about what kind of error code the kernel was returning to those user programs. In programming, when a function or system call fails, it often reports an error by returning a special negative code (or setting a global errno). Different codes mean different things. Two important ones here are:

• EINVAL – which stands for “Invalid argument”. This usually means “you asked for something impossible or gave a bad parameter.”
• ENOENT – which means “Error NO ENTry” or colloquially “No such file or directory”. This usually is reported when you try to open or access a file that isn’t there.

Before Mauro’s change, the kernel’s media ioctl (a kind of function call to control devices) probably returned -EINVAL in a certain situation (perhaps when an application requested something that wasn’t available). PulseAudio was okay with that – it might handle -EINVAL by trying something else or gracefully failing. Mauro’s patch changed this to return -ENOENT instead, maybe thinking that was more correct. But it wasn’t! PulseAudio didn’t expect ENOENT from this call – after all, PulseAudio already had the device open, so “No such file or directory” didn’t make sense. Getting an ENOENT where it shouldn’t appear likely confused PulseAudio, causing it to loop or crash.

Linus points out that ENOENT was a totally wrong error to use in this context. The kernel function in question was an ioctl on an open file descriptor – by definition, the file exists if you’re calling ioctl on it. Using ENOENT there is like telling a customer “sorry, we don’t have that product” when the product is literally right in their hand. The correct thing would have been to stick with EINVAL or a more appropriate error code if needed. In fact, the patch itself seemed to realize ENOENT was problematic, because (as Linus mentions) it had code that translated ENOENT back to EINVAL in some places (ret == -ENOENT ? -EINVAL : ret). That’s just a messy, roundabout way of admitting “we shouldn’t be using ENOENT here.” No wonder Linus called the patch “incredibly broken sh*t.”

Beyond the technical goof, there’s the communication aspect. Linus’s email is extremely blunt, loaded with frustration. Phrases like “SHUT THE F*CK UP!” and “I don’t ever want to hear that kind of garbage... from a maintainer again” jump off the screen. This is pretty shocking if you’re used to polite office emails! The Linux kernel mailing list is a public forum, and Linus chose to dress down Mauro very openly. In the developer community, we often reference this style as a classic linus_rant. It’s both notorious and oddly legendary. Some find it funny or refreshing (“he said what we were all thinking!”), while others find it unprofessional. It certainly became a piece of developer humor lore because of how over-the-top the phrasing is, especially the all-caps proclamation: “WE DO NOT BREAK USERSPACE!” You can almost imagine Linus pounding his keyboard as he typed that.

For a newer developer or someone not familiar with Linux internals, here are the key takeaways:

• User space vs Kernel space: User-space programs are everyday applications (like your web browser, media player, or in this case, audio service). The kernel is the core of the OS that these programs rely on for services, via system calls and drivers.
• Backward compatibility: When the kernel (or any platform) updates, it should ideally not require changes in those user programs. They should keep working. If they don’t, that’s a problem.
• Regression: A fancy term for “it broke something that used to work.” It’s one of the worst kinds of bugs in system updates because it means the update went backwards in functionality for someone.
• Maintainers and communication: Maintainers are responsible for certain parts of the code. Here, the maintainer made a mistake and got a very harsh public scolding. The Linux kernel community has historically been very direct. This incident is an extreme example, basically a senior engineer telling a subordinate in no uncertain terms, “you messed up big time, fix it, and don’t ever make this kind of mistake again.”

People turned this email into a meme because of the mix of technical insight and dramatic flair. The line “WE DO NOT BREAK USERSPACE” is now quoted as a mantra – a reminder (sometimes used humorously) that no matter what clever idea you have in kernel development, if it risks breaking existing apps, just don’t. And even outside the kernel, it’s a relatable concept in software: don’t push an update that causes your customers’ or users’ applications to crash, and then blame them for it.

Level 3: The Wrath of Linus

What makes this meme painfully hilarious to seasoned developers is the combination of a minor-looking code change and the monumental blow-up it triggered on the kernel mailing list. You have a maintainer casually suggesting that maybe the user-space program (PulseAudio, in this case) is at fault for looping weirdly after a kernel update. That alone is enough to make any old-timer raise an eyebrow, because Rule #1 in this arena is exactly what Linus thundered: “WE DO NOT BREAK USERSPACE!”. The humor here is dark and communal – it’s the “I can’t believe he went there” moment followed by a collective nod of “but he’s not wrong.”

Imagine being Mauro, the maintainer. You submit a patch (commit f0ed2ce840b3) to the media subsystem of the Linux kernel. Perhaps some automated compliance tool or personal preference made you think returning -ENOENT (No such file or directory) from that ioctl was a neat idea – maybe you thought, “Hey, the driver didn’t find something, so ENOENT makes sense.” Then bug reports start trickling in: users on the bleeding-edge v3.8-rc1 kernel find that their audio is broken and KDE media apps are crashing. PulseAudio, which used to work flawlessly, is now “entering some weird loop.” Mauro’s first reaction (in the email thread) is essentially: “If PulseAudio can’t handle the new return value, isn’t that PulseAudio’s bug?” Seasoned engineers reading this can practically hear the record scratch. That question is the match that lights the fuse.

Linus Torvalds responds with a public maintainer reprimand so blistering that it became meme history. He doesn’t just disagree; he goes full “Shut up, Mauro” mode with an F-bomb for good measure: “Mauro, SHUT THE F**K UP!”. This is the communication breakdown moment where formal politeness exits and raw frustration takes the stage. For those of us who’ve been around open-source communities (and maybe have PTSD from communication on tough projects), the message is shockingly candid but also cathartic. Linus is voicing what every serious engineer knows: if your kernel patch broke user programs, the bug is in the kernel. Period. It’s like watching the CEO of a company tear into a manager for blaming customers who complained – brutal, but you understand why.

The senior perspective sees the layers of irony: Linux, an open-source project famous for its technical excellence, has also long been famous for a stark, no-nonsense communication style on its mailing lists. This email is practically exhibit A of that blunt culture. There’s a twisted humor in how unfiltered it is. Linus doesn’t sugarcoat it: the patch is “total and utter CRAP,” the idea of using ENOENT in that context is “insane,” and the maintainer’s attempt to make excuses by blaming an external program is “just shameful.” It’s harsh enough to make an HR department faint, but in the context of the Linux Kernel Mailing List (LKML), many veterans smirk and think, “Yup, that’s classic Linus.” In fact, Linus_rant is practically a genre of email that older Linux devs are morbidly amused by, as long as they’re not the ones in the hot seat.

We also recognize the shared pain that underlies this anger. Breaking user-space isn’t just a theoretical no-no; it causes real-world chaos. Think of all the bugs in software you’ve chased that turned out to be due to an OS upgrade or a mismatched library version. Now scale that up: a kernel regression that crashes sound systems on Linux desktops worldwide. That’s a nightmare scenario for a maintainer – and exactly what Linus wants to avoid at all costs. The mantra “we_do_not_break_userspace” exists because people have been burned before. It’s a lesson written in blood (or at least in thousands of angry bug reports).

From a Systems Engineering perspective, the email is a senior engineer (Linus) reasserting a best practice with the subtlety of a sledgehammer. And let’s be honest, there’s a bit of schadenfreude in seeing someone else get schooled so hard. Developers with a long memory might recall other famous Torvalds tirades and even chuckle at phrases like “fix your f*cking compliance tool” – it’s ruthless, but it’s also Linus implying “your static analysis or whatever told you to do this is garbage – use your brain and kernel common-sense.” The subtext is that being a kernel maintainer isn’t just about writing code; it’s about judgment and understanding the ethos of the project. When Mauro didn’t instinctively prioritize user-space stability, he got a very public wake-up call.

The whole situation also highlights an organizational dynamic unique to open source: no matter your title (even a respected maintainer), if you mess up something fundamental, you can be called out in front of all your peers. It’s both terrifying and effective. After this incident, you can bet every kernel dev was double-checking their patches for any whiff of a userspace_regression. No one wants to be the next person in a screenshot where Linus is yelling at them in all caps. The community found humor in the intensity of it all – how often do you see “I don’t ever want to hear that kind of obvious garbage from a maintainer again” in an email? It’s over-the-top, yet it underscores a truth: in LowLevelProgramming of the kernel variety, messing up the contract with user programs is the ultimate facepalm, and you will hear about it.

In summary, this meme is the perfect storm of DeveloperHumor and real kernel policy. We have a legendary figure (Torvalds) delivering a scathing tech sermon about an error code mix-up. It’s funny because it’s true: even something as small as an errno can unleash the wrath of Linus if it threatens the stability of the Linux ecosystem. Seasoned devs find themselves nodding and laughing at the absurdity and the righteousness of it. “Never break user space” isn’t just a guideline – it’s practically Linus’s Ten Commandments, carved in stone (or in this case, etched in an email with plenty of expletives for emphasis).

Level 4: The Kernel Prime Directive

In the world of Linux Kernel Development, there's an unwritten law as inviolable as gravity: never break user-space. This is the kernel’s prime directive – a fundamental ABI stability contract. The kernel’s Application Binary Interface (ABI) is like a sacred promise to all programs running in user space (any normal application outside the kernel). Once the kernel exposes a behavior or an interface, that behavior becomes a permanent part of the contract with user programs. Changing it might seem trivial in code, but it’s akin to altering the laws of physics for applications that rely on it.

At a deep technical level, this stability means if a system call or an ioctl (I/O control operation on a device) used to return a certain result, it must continue to do so for the same inputs, forever. Even something as small as switching an error code from -EINVAL to -ENOENT violates that contract. Why? Because user-space programs (like audio daemons or media players) have been built around the original behavior. They might check for specific error codes or assume certain outcomes. EINVAL (Invalid argument) and ENOENT (No such file or directory) are not interchangeable – each has a distinct meaning defined by POSIX standards and decades of OS tradition. An application like PulseAudio might handle -EINVAL gracefully (perhaps by trying a different fallback or skipping an unsupported operation). But if it suddenly gets -ENOENT – an error code that should never come from an already-open device – the program could misinterpret the situation or enter an unexpected path. This discrepancy can send well-behaved software into a tailspin, through no fault of its own.

Maintaining backward compatibility in low-level programming (especially in an operating system kernel) is brutally hard, but absolutely essential. The kernel is the foundation for all user applications; if that foundation shifts unpredictably, everything built on top can crack. Kernel developers treat userspace regressions as priority-one bugs: if any previously working user program regresses (breaks) due to a kernel change, that change is considered wrong. It’s a point of pride (and discipline) that you can take a binary from, say, 2005 and run it on a modern Linux kernel – it should behave the same as it did originally. This long-term stability is one reason Linux (and other mature OSes) have earned developers’ trust: you upgrade your system and your tools and apps keep on running.

The technical nuance here goes beyond just etiquette – it’s about architectural integrity. The system call interface is basically a contract between kernel and user programs. In legal terms, the kernel must honor its side of the contract unconditionally. Changing an error code is like sneaking in a new clause without telling the other party. And the kernel community’s verdict on that is clear: not allowed. In kernel design, an abrupt change can have ripple effects reminiscent of a butterfly effect – one wrong error code in some media subsystem ioctl and suddenly audio servers and media players across different Linux distributions crash or hang.

This is why Linus’s fury in the email is actually rooted in deep technical wisdom. He’s not just being dramatic; he’s enforcing a core OS principle. The maintainer in question (Mauro) had, perhaps with good intentions, introduced a change (commit f0ed2ce840b3) that violated the “userspace must not be broken” covenant. Not only that, the patch’s use of ENOENT was conceptually wrong for an ioctl – a misuse of the errno that defied the conventions every systems programmer lives by. Linus’s explosive response – profanity and all – underscores to every other kernel developer watching: this rule will be defended ferociously. It’s a bit like a cryptographic hash of the Linux philosophy: a small change in input (one bad patch) produced an avalanche of output (Linus’s rant), reinforcing that the cost of breaking user-space is not negotiable.