"This is Garbage": Linus Torvalds, a Meta Engineer, and the Brutal Reality of Linux Kernel Development

Linus Torvalds, the creator and benevolent dictator for life of the Linux kernel, is as famous for his technical genius as he is for his brutally honest, and often scathing, feedback. His legendary tirades on the Linux Kernel Mailing List (LKML) are a spectacle of unfiltered criticism, aimed at protecting the quality of one of the most important software projects on the planet.

Recently, a senior software engineer felt the full force of Torvalds”s wrath after submitting code that was deemed unacceptable. The incident provides a fascinating, raw look into the high-stakes world of kernel development.

The Code, The Conflict, and The “Garbage”

The engineer in question was Palmer Dabbelt, an experienced developer with a resume that includes Google and, currently, Meta. Dabbelt submitted a series of patches for the RISC-V architecture, intended for the upcoming kernel version 6.17.

The submission, however, was not only late but, in Linus”s view, of exceptionally poor quality. Torvalds”s rejection was swift, public, and merciless. In a now-famous email, he wrote:

“Nope. This is garbage and it”s way too late. I asked for pull requests to be early because I am traveling, and if you cannot follow that rule, at least provide good pull requests.

This adds a bunch of non-RISC-V-specific garbage to the generic header files.

And by ”garbage”, I really mean it. This is something nobody should ever send to me, least of all at the end of a merge window.

This thing actively makes the world a worse place to live in.”

The critique was not just about a few lines of bad code. Torvalds was furious that the changes were not specific to RISC-V but were being added to generic kernel headers, potentially affecting countless other architectures and creating a maintenance nightmare. It violated a core principle of kernel development: changes should be clean, self-contained, and respectful of the shared codebase.

To his credit, Palmer Dabbelt responded with a straightforward apology, acknowledging his mistakes:

“Ok, sorry. I”ve been falling behind lately and this sort of just piled up because I grabbed a bunch of backlogged stuff, but that just resulted in me making mistakes. So I”ll stop falling behind, and hopefully that helps with the quality issues.”

This isn”t an isolated event. Torvalds has a long history of harsh interventions. In a past incident, he publicly chastised developers arguing over the inclusion of Rust in the kernel, which led Hector Martin, leader of the Asahi Linux project, to step away from kernel development.

While the abrasive style is controversial, it serves a purpose. It”s a high-impact, if brutal, quality control mechanism. But to understand why it happens, you have to understand the unique way the Linux kernel is built.

The Cathedral and the Bazaar: How the Linux Kernel Gets Made

This explosive exchange might seem chaotic, but it”s a symptom of a highly structured, albeit intense, development process that has been refined over three decades. It’s a system built on a strict hierarchy of trust.

1. The Pyramid of Trust

At the top sits Linus Torvalds. He is the final arbiter. Nothing gets into the official kernel without his approval.

Below him are the subsystem maintainers. These are trusted, expert developers responsible for specific parts of the kernel—like networking, filesystems, or, in this case, the RISC-V architecture. Palmer Dabbelt is one such maintainer.

Below them are tens of thousands of developers from around the world who write and submit patches.

2. The Release Cycle: A Two-Act Play

The kernel development process revolves around a predictable cycle, typically lasting 9-10 weeks.

• Act I: The Merge Window (The Frenzy) For two weeks immediately following a new kernel release, the “merge window” opens. This is the only time new features are accepted. Subsystem maintainers, who have been collecting and testing patches from other developers, send “pull requests” to Linus. This isn”t a GitHub pull request; it”s an email asking Linus to pull the curated code from their public git repository. Linus personally reviews these requests, often rejecting, questioning, or, as we saw, lambasting them if they don”t meet his standards.

• Act II: The Stabilization Phase (The Calm-Down) After the two-week merge window closes, the first release candidate (-rc1) is tagged. No new features are allowed from this point on. The next 7-8 weeks are dedicated exclusively to fixing bugs and stabilizing the code introduced during the merge window. A new release candidate (-rc2, -rc3, etc.) is typically issued every week. When Linus feels the kernel is stable enough, the final version is released, and the cycle begins anew.

Dabbelt”s submission was a cardinal sin in this process: it was a feature-level change submitted after the merge window had closed, a time reserved for bug fixes.

3. The Public Square: The LKML

All of this communication happens in the open on the Linux Kernel Mailing List (LKML). It’s a massive, high-volume forum where patches are submitted, debated, and reviewed in plain text for the world to see. This radical transparency ensures that everyone is accountable for their work, but it also means that when conflicts arise, they are spectacularly public.

Linus”s role is not just to write code, but to be the ultimate guardian of the kernel”s quality. His harshness, while jarring, is a direct reflection of the immense responsibility he carries. The Linux kernel runs our world—from Android phones and cloud servers to cars and stock exchanges. In this context, there is simply no room for “garbage.”