Linus Torvalds' Unforgettable 'WE DO NOT BREAK USERSPACE' Rant
Description
A screenshot of a famous plain text email from Linus Torvalds, the creator of Linux. The image has a light green-grey background with a black monospaced font. Standard email headers 'From', 'Date', and 'Subject' are visible, with the sender listed as 'Linus Torvalds'. The email's body is a long, passionately and aggressively worded message directed at another developer, Mauro. It contains several iconic, all-caps phrases, including 'SHUT THE FUCK UP!', 'WE DO NOT BREAK USERSPACE!', and a censored 'Fix your f*cking "compliance tool"'. This image immortalizes a legendary rant from the Linux Kernel Mailing List (LKML). It's a cornerstone piece of tech history that articulates a fundamental principle of Linux kernel development: kernel changes must never break existing user-space applications. Any such breakage is considered a regression and, therefore, a bug within the kernel itself. This philosophy is a key reason for Linux's long-term stability and backward compatibility, and the email is often cited as a classic example of both Linus's famously abrasive communication style and his non-negotiable technical standards
Comments
19Comment deleted
The first rule of kernel club is: You DO NOT break userspace. The second rule of kernel club is: You DO NOT break userspace. The third rule is you get this email if you forget the first two
In kernel land, backward compatibility isn’t a feature flag - it’s a blood-oath signed in ioctl and shouted in ALL CAPS
The only thing more stable than the Linux kernel ABI is Linus's commitment to reminding maintainers about it - with the same energy as a kernel panic, but directed at humans who dare suggest users should adapt to kernel changes instead of the other way around
This is the email that launched a thousand 'we do not break userspace' references - proof that even after decades of kernel development, the most important API documentation is sometimes written in all caps with creative vocabulary. It's the technical equivalent of carving 'backward compatibility' into stone tablets, except the stone is an LKML archive and the chisel is Linus's keyboard at 9:36 AM on a Sunday. The real lesson? ENOENT might mean 'Error NO ENTry,' but in kernel development, it definitely means 'Error: NO, you're ENTirely wrong about this approach.'
Returning ENOENT from an ioctl on an open file is the kernel equivalent of shipping a breaking REST change on Friday - CI goes green, userspace goes thermonuclear
First rule of kernel maintenance: never break user space. Second rule: Linus will rant anyway
Returning ENOENT from an ioctl is the syscalls equivalent of renaming a public REST field in prod - expect Linus to become your incident response playbook
sometimes I want to suck him off Comment deleted
Guy is the type to jokingly flip off a billion dollar corpo, but when he accidentally drops a pen or spills his coffee with a completely straight face and doesn't say a word, you know shit's serious Comment deleted
Linus' way to wish Mauro merry christmas. Comment deleted
https://youtube.com/watch?v=2LXZiUiQzek Comment deleted
smh at kids expecting embedded content these days. irc was better. Comment deleted
what ur fav network? theres nothing wrong with a bit of trollin x3 Comment deleted
IRC didn't even have replies or multi line messages :c Comment deleted
There’s some gut feeling when you read something in IT TG channel and text starts with caps lock on "shut the fuck up" — you know that Linus wrote it Comment deleted
So far never failed me Comment deleted
my personal favorite https://lkml.org/lkml/2013/2/21/228 Date: Thu, 21 Feb 2013 08:58:45 -0800 Subject: Re: [GIT PULL] Load keys from signed PE binaries From: Linus Torvalds <> On Thu, Feb 21, 2013 at 8:42 AM, Matthew Garrett <[email protected]> wrote: > > There's only one signing authority, and they only sign PE binaries. Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead. If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request. Why should *I* care? Why should the kernel care about some idiotic "we only sign PE binaries" stupidity? We support X.509, which is the standard for signing. Do this in user land on a trusted machine. There is zero excuse for doing it in the kernel. Linus Comment deleted
Noice Comment deleted
Should I print that in 100" and put it on a wall? Comment deleted