Linus Torvalds Won't Stop Fighting People In Linux

Overview

The video presents a curated set of “Linus Torvalds crash-outs” (sharp, angry replies) from Linux kernel mailing list and Git discussions, framed as lessons about kernel development practices and project culture. It emphasizes both technical substance and how tone and maintenance policy influence upstreaming.

Profanity: context vs removal (1996)

An early thread argues that profanity in code/comments is fundamentally about communication and reflects the mindset behind the code.

• Core claim: you can’t do blanket, context-free removal of profanity.
• Doing so without considering authorship/context is “worse” than leaving ugly comments.
• Targeted moderation (e.g., reconsidering specific nasty messages) could be reasonable.
• “Mindless” automated cleanup is criticized as the wrong approach.

“False positives” and checker bugs (2017)

Torvalds criticizes a patch/checker workflow where checking code produces false positives—reports that the code is wrong when it isn’t.

• Proposed fix: if the checker is broken, it should warn, not trigger severe outcomes.
• Main technical point: incorrect diagnostics prevent users from confidently enabling functionality.
• Result: hard-to-debug failures with dead systems and no useful reports.

O_DIRECT: why bypassing OS caching is fundamentally incorrect (2007)

This section explains O_DIRECT (bypassing the OS page cache). Torvalds argues that “just bypass the OS IO layers” is wrong because the OS provides:

• Resource management and prevention of conflicting allocation/deallocation
• Correctness details, including serialization of I/O
• Protection against observing “halfway state” (e.g., dirty blocks not fully written yet)
• Security and correctness guarantees

Core message: direct I/O may look like a simple/performance trick, but skipping the OS breaks invariants the OS exists to maintain.

Security stance / prioritization

A discussion criticizes security “circus” practices such as ranking vulnerabilities and scoring them.

The video conveys Torvalds’ view that:

• Security issues shouldn’t be glorified over routine reliability/correctness bugs
• “Boring” bugs matter because they are numerous
• Dramatic security fixes shouldn’t be treated as categorically more special

Upstreaming policy and expectations (2002–era)

Torvalds outlines why patches might not be merged into his tree:

• Selection depends on trust in the author (past performance) and whether the feature is interesting/well-done
• Flame wars or attempts to pressure inclusion don’t help

Governance details emphasized:

• Not merging into Linus’s tree isn’t inherently “bad”
• Other trees (e.g., stable or other organizations) may carry changes if they get used and prove value
• Whining for merges doesn’t work—people aren’t entitled to patch acceptance

Modern RISC-V merge-window complaints (6.17 / 2025)

Torvalds rejects late patches for the RISC-V merge window and criticizes:

• Adding generic header functionality outside the RISC-V scope
• “Garbage” helpers that create abstractions that are harder to read/comprehend

Technical example: hiding byte/word conversion complexity

A helper conceptually converting two 16-bit values into a 32-bit value is criticized for:

• Making byte/word order unclear
• Hiding casts and bit-shift complexity in a generic helper

Commit message links and review friction

He also disapproves useless links in commit messages, such as:

• Links that only point to information already known
• Commits pulled/unpulled due to unclear patch content and missing explanations

A recurring theme: automated “idiocy” that makes review harder (e.g., boilerplate links without added value).

D-Bus vs kernel vs performance argument (2015)

A major point: Torvalds dislikes merging kernel D-Bus (“K-D-Bus”) primarily on performance grounds.

• “We don’t merge kernel code because user space was written.”
• Kernel standards are about correctness and quality, not user-space popularity.
• If user space is slow due to bad code, that’s not automatically a justification to move it into the kernel.

Additional architectural/technical objections include:

• Signing-key related interfaces being driven by “moronic reasons”
• Pushback on kernel involvement when userland can do it on a trusted machine

Signing keys / PE binaries vs X.509 in kernel

Torvalds questions why the kernel should implement signing workflows tied specifically to PE binaries.

• Argument: the kernel should use X.509 (standard signing format)
• Other parsing/verification steps can happen in userland with a trusted signing machine
• He rejects the premise that the kernel must care about vendor-specific formats when standard mechanisms exist

Audio regression: kernel must not blame user space

A highlighted example is a kernel change breaking PulseAudio.

The maintenance rule (as framed in the subtitles):

• If a kernel change breaks user programs, it’s a kernel bug
• Kernel maintainers shouldn’t blame user space for regressions

Another technical critique:

• Returning “-ENOENT / noent” from an IOCTL is called out as incorrect usage
• IOCTLs operate on already-opened handles/files, so “no such file or directory” semantics don’t fit
• He treats the patch as poorly designed and overly wrong, not merely mildly problematic

GitHub complaints: tooling loses review context

Torvalds criticizes GitHub for:

• Losing crucial review metadata (e.g., email addresses)
• Producing inadequate/deficient PR diffs and stats
• Offering a worse PR workflow than upstream mailing list practices

He frames GitHub as acceptable for hosting, but “useless” for PR review/editing due to missing information maintainers need.

Stable patch policy and using stable as a “dump”

A late-cycle policy discussion (RC1/RC3/RC4):

• Maintainers can’t send random late fixes except stable/security/regression-type changes
• Torvalds claims stable rules are being treated as a loophole for changes that aren’t truly stable-worthy

Argument presented:

• If stable acceptance becomes easier, more changes get labeled “stable-worthy” instead of being justified properly.

Code of conduct / tone escalation (Sarah Sharp thread)

A community-management narrative describes escalation in the kernel mailing list around:

• Verbal abuse vs professionalism
• The interaction being framed as part of Linus Torvalds’ brief stepping down and the introduction of a code of conduct

Torvalds defends being blunt and argues subtlety is ineffective over email, while Sarah Sharp demands professionalism and warns against abusive behavior.

GPLv3 stance (license philosophy)

Final point: Torvalds’ opposition to GPLv3 (as described) and preference for GPLv2.

• Core argument: GPLv2’s broader acceptability helps varied developers/ideals collaborate.
• He criticizes GPLv3 as narrowing the license in ways that turn it into a tool for factional conflict instead of a widely compatible agreement.

Main speakers / sources (as indicated in the subtitles)

• Linus Torvalds (primary source)
• Keyes Cook
• Richard J. Moore
• Mauro (PulseAudio/audio regression discussion)
• Noent (mentioned in the IOCTL error-code discussion)
• Greg Kroah-Hartman (stable/pull request acceptance context)
• Constantine (automation/link-argument criticism)
• David (signing keys patch request)
• Matthew (responding about signing authority / PE binaries)
• Sarah Sharp (tone/code-of-conduct escalation thread)
• Ingo Molnar (mentioned in comparison to Torvalds’ behavior/tone)