https://lkml.org/lkml/2026/10/13/3242This email from Linus Torvalds addresses an attempt to ban or restrict AI-assisted contributions (specifically removing "Assisted-by" documentation references). Torvalds forcefully rejects blanket restrictions on using AI tools, comparing the logic of banning AI to the absurdity of banning compilers or text editors.For traditionalists, purists, or "Luddites" within the Linux kernel community who resist the integration of AI tools, this post serves as a sharp reality check and likely impacts them in several key ways:1. Rejection of Dogmatic Tool BansLuddites often advocate for strict cultural or procedural barriers against AI, arguing that code or documentation should be strictly human-crafted from scratch. Torvalds explicitly shuts down this mindset, calling the concept of "don't use AI for X" idiotic and comparable to demanding developers write raw assembler or type commit messages without backspaces. This makes it clear that official kernel governance will not back blanket prohibitions against AI tools.2. A Shift in Burden: Focus on Competence, Not Tool RestrictionTorvalds emphasizes that the core issue isn't what tools are used, but whether the developer understands what they are doing. For those who wish to reject AI, this means they cannot rely on rules that ban the tools outright. Instead, they must focus on code quality, correctness, and review rigor. If an AI-assisted contribution is garbage, it will be rejected on its technical merits—just like poorly written human code. Conversely, if it works and is well-understood by its submitter, objecting to it solely because AI was involved will carry no weight.
>>1101068253. Cultural Marginalization of Pure ResistanceBy stating bluntly that "the people I respect and call intelligent are not the ones that shy away from using new and interesting tools," Torvalds actively pushes back against anti-technology sentiment. For traditionalists who pride themselves on old-school workflows as a badge of honor, this stings. It signals that institutional leadership views a refusal to adapt to modern tooling not as a mark of rigorous purity, but as an unproductive hang-up.SummaryUltimately, the post tells the anti-AI faction in the Linux community that they cannot legislate away new technologies through dogmatic rules. They are forced to compete in a landscape where AI use is permitted, meaning their objections must shift from policing how code is written to rigorously testing if the code actually holds up.
>>git commit mentions Cursorvs>>user "writes code themselves" but commits without Cursor.
He's fucking retarded. Also AI can poison the codebase, it's not even totally clear that you can assign a license of your own to AI-generated code yet. A court decision seems to imply otherwise, actually.Any Free or open-source project that commits AI-generated code is in for an eventual legal battle. But more importantly, this will lead to more churn and despite humans OKing the code, they won't be able to understand what's going on.Only projects like Net/OpenBSD, Haiku, and yes TempleOS will survive this AI apocalypse.
Linus hasn't been the same since his month long vacation-style treatment he was forced to take after bitching out Intel on the LKML over Spectre and Meltdown. I don't know if they replaced him or what they did. But he's been getting progressively worse since then.
>>110107079>TempleOSThis was a convincing troll post until this.
>>110107118TempleOS has no Internet, how could AI harm it? It's finished, too. Also it's blazing fucking fast.
>>110107079I wonder why FreeBSD gets left out of this when it's the one 80% of people currently running Linux could feasibly switch to. They are implicitly accept LLM commits right now but there hasn't been that many, especially compared to Linux. They are taking forever for an official yes or no, but I wonder if NetBSD's recent success and the legal ambiguity of LLM copyright especially with the recent fair use ruling will make them second guess being too permissive.
>>110107079>>110107168cuck license
