What’s interesting is that the discussion in which Torvalds decides to interject in is when Pinchart brings up the ethics of using LLMs in development as Torvalds quickly points out that the goal of the project is not to be a “social warrior” (barely indistinguishable from calling others SJWs), he even makes a reference to veganism as a metaphor.
On the other hand, legitimizing any of the several AI issues is a greet
concern for the LF members [2] that includes companies such as Google,
Meta, Microsoft and Anthropic that are collectively exposed for
trillions of dollars over the AI bubble.
It’s not that you must be “pro-AI”, but if you are not, you will be
countered or silenced in every influential technical spaces.
So neither inclusiveness or developers’ alienation are relevant ethical
issues in this list, just political tools or not.
Linus faithfully serves the interests of his employers, so no
argument, either ethical, technical or whatever, really counts
here whenever its effects could annoy them.
The LF patrons are all embroiled in the western AI bubble, so it’s difficult to ascertain whether Torvalds could ever not take a positive stance or even directly advise others to use LLMs. It’s probably not worth taking Torvalds’ “anti-ethics” arguments seriously and instead look at the bigger picture: The Linux Kernel is a titanic (pun intended) C project which hits the limits of the guarantees that the C compiler and coding guidelines can provide. Using an LLM to find memory bugs is necessary considering attackers can do the same thing (with the recent Copyfail and dirtyfrag attacking vulnerable modules). In a way, LLMs are just damage control for poor engineering decisions.
The non-LLM answer was to incorporate a stronger compiler in the form of Rust for future drivers and modules (even better would be to rewrite the kernel in Rust), which eliminates this repetitive class of memory vulnerabilities. In a more centrally planned computer science field, C would be deprecated rather than become the parasitic bedrock of everything above it.
It’d also be better if we actually had multiple kernels that were supported on the level of Torvalds’ Linux git tree rather than a monoculture where everyone is destined to hover around Torvalds’ tree because “out-of-tree” linux kernel stuff is a pain, much less a fork. Also if your foundation receives millions in grants and employment contracts from silicon valley, telling others to “make a fork” isn’t a realistic measure.
The claim that LLMs are simply damage control for poor engineering decisions is a gross misrepresentation of the reality of maintaining a codebase the size of Linux. No human can hold the full state space of the kernel in their head. Memory safety is one class of bug, but the most subtle vulnerabilities are logic bugs such as race conditions, incorrect state transitions, misuse of APIs that cross module boundaries, or behavior changes during a refactor. None of these would be caught by Rust’s borrow checker or by typical static analysis tools. These problems emerge from interactions between subsystems written by different maintainers who were solving separate problems and weren’t aware of how features might interact in negative ways.
LLMs, by contrast, can look across a far larger context and identify interactions across the entire codebase. They can trace the execution of a path through a driver, spot where a lock is held too long, or detect that a function’s contract is violated by a caller many levels deep. Humans simply cannot scale this kind of analysis to millions of lines because we can only hold so much information in our heads. Calling LLMs damage control is frankly dishonest in the extreme.
Rust is a powerful tool for eliminating issues like buffer overflows and use-after-frees in new code, but it’s by no means a silver bullet. On top of that, the Linux kernel already has millions of lines of C that will never be rewritten. A Rust rewrite of the entire kernel would be a fantastical idea, and even if that magically happened you’d still have many kinds of problems such as logic errors, algorithmic complexity attacks, or unsafe blocks needed for hardware interaction which Rust would not help you with. The reality is that LLMs help find the same memory bugs in C code today, and many of these problems would simply not be found otherwise.
The whole idea of having multiple supported kernels to break the monoculture is likewise fantastical, and ignores the sheer amount of work that goes into maintaining a project of that scale. It’s also completely orthogonal to the LLM question. If we had ten kernels then each would still be a giant codebase needing the same kind of automated analysis.
Dismissing LLMs as damage control ignores the fact that much of all engineering is damage control, and the real question is which tools give us the best return on effort. LLMs currently provide a unique ability to surface hard to see interactions that no other tool catches.
What’s interesting is that the discussion in which Torvalds decides to interject in is when Pinchart brings up the ethics of using LLMs in development as Torvalds quickly points out that the goal of the project is not to be a “social warrior” (barely indistinguishable from calling others SJWs), he even makes a reference to veganism as a metaphor.
In the end, I think Giacomo Tesio’s response is the most poignant (https://lore.kernel.org/linux-media/20260716112048.2dc10a3f@hermes.development.it/)
The LF patrons are all embroiled in the western AI bubble, so it’s difficult to ascertain whether Torvalds could ever not take a positive stance or even directly advise others to use LLMs. It’s probably not worth taking Torvalds’ “anti-ethics” arguments seriously and instead look at the bigger picture: The Linux Kernel is a titanic (pun intended) C project which hits the limits of the guarantees that the C compiler and coding guidelines can provide. Using an LLM to find memory bugs is necessary considering attackers can do the same thing (with the recent Copyfail and dirtyfrag attacking vulnerable modules). In a way, LLMs are just damage control for poor engineering decisions.
The non-LLM answer was to incorporate a stronger compiler in the form of Rust for future drivers and modules (even better would be to rewrite the kernel in Rust), which eliminates this repetitive class of memory vulnerabilities. In a more centrally planned computer science field, C would be deprecated rather than become the parasitic bedrock of everything above it.
It’d also be better if we actually had multiple kernels that were supported on the level of Torvalds’ Linux git tree rather than a monoculture where everyone is destined to hover around Torvalds’ tree because “out-of-tree” linux kernel stuff is a pain, much less a fork. Also if your foundation receives millions in grants and employment contracts from silicon valley, telling others to “make a fork” isn’t a realistic measure.
The claim that LLMs are simply damage control for poor engineering decisions is a gross misrepresentation of the reality of maintaining a codebase the size of Linux. No human can hold the full state space of the kernel in their head. Memory safety is one class of bug, but the most subtle vulnerabilities are logic bugs such as race conditions, incorrect state transitions, misuse of APIs that cross module boundaries, or behavior changes during a refactor. None of these would be caught by Rust’s borrow checker or by typical static analysis tools. These problems emerge from interactions between subsystems written by different maintainers who were solving separate problems and weren’t aware of how features might interact in negative ways.
LLMs, by contrast, can look across a far larger context and identify interactions across the entire codebase. They can trace the execution of a path through a driver, spot where a lock is held too long, or detect that a function’s contract is violated by a caller many levels deep. Humans simply cannot scale this kind of analysis to millions of lines because we can only hold so much information in our heads. Calling LLMs damage control is frankly dishonest in the extreme.
Rust is a powerful tool for eliminating issues like buffer overflows and use-after-frees in new code, but it’s by no means a silver bullet. On top of that, the Linux kernel already has millions of lines of C that will never be rewritten. A Rust rewrite of the entire kernel would be a fantastical idea, and even if that magically happened you’d still have many kinds of problems such as logic errors, algorithmic complexity attacks, or unsafe blocks needed for hardware interaction which Rust would not help you with. The reality is that LLMs help find the same memory bugs in C code today, and many of these problems would simply not be found otherwise.
The whole idea of having multiple supported kernels to break the monoculture is likewise fantastical, and ignores the sheer amount of work that goes into maintaining a project of that scale. It’s also completely orthogonal to the LLM question. If we had ten kernels then each would still be a giant codebase needing the same kind of automated analysis.
Dismissing LLMs as damage control ignores the fact that much of all engineering is damage control, and the real question is which tools give us the best return on effort. LLMs currently provide a unique ability to surface hard to see interactions that no other tool catches.