I think you’ll find that even distros that are generally anti-AI and don’t allow its use in their own projects are pragmatic about not being able to influence other people’s software (for instance, Gentoo’s AI policy flat-out states that it doesn’t prohibit packaging AI-coded or AI-related software, although there’s been some discussion about marking it so that the user can make an informed decision).
The title is pure clickbait, but the article is nuanced and reasonably well written, IMO.
No one wants a freaking Ubuntu chatbot on their desktop, but code submission is an entirely different issue, and I think “the submitter is entirely responsible for their code” is a very reasonable position.
And obviously, LLM-generated code policy needs to be tuned to each project and their contributor community. As an example not cited in the article, vibe-coded PRs are an ongoing plague for llama.cpp, an LLM inference engine itself, so they blanket ban them. Ironic, and perfectly reasonable. But Linus researching that Intel bug with a little help, but using his brain for the legwork and actual submission, is also reasonable.
I think “the submitter is entirely responsible for their code” is a very reasonable position.
Especially since I just don’t see how it’s possible to fully prevent people from using AI if they want to use it. Yes a lot of code might be more obvious and could be rejected with an “absolutely no AI policy” but some people will submit perfectly good code where AI was involved in some way.
Yes, that too.
Incentivizing hiding LLM use would be a problem. Encouraging disclosure is good.
Plus if the general requirement is ‘high quality code’ then that automatically excludes the majority of LLM usage where people just vibe code it and rely heavily on the LLM to do the work. VS someone writing their own code while using an LLM to help find problems.
Well… IMO, there’s a whole spectrum between “very rare LLM brianstorming/troubleshooting” and “I don’t know how to code” vibe-coding, and Im not sure what the distribution looks like.
Personally, I get LLMs to generate boilerplate, formatting, and functions, but manually write plenty and audit/assemble all the pieces myself. But I would not call myself a vibecoder; I loathe vibe coding.
Yeah I often tell a local LLM to find problems with my code before I submit it. It’s essentially a round 0 reviewer, trained on previous (human) reviews of the same project.
The choice isn’t uncomfortable. It’s a need for a hard fork from Linus that’s always been present, and now is just more obvious because 2026 really is the year of mainstream FOSS OS use.
Ok great.
So fork it yourself.
If you can’t handle progress, then you shouldn’t force everyone else to comply.
Even Linus knows how the real world works.
I would like to see both anti-AI and “slop 'em up!” forks of Linux, mostly to see which one fails first.
My hypothesis is that the anti-AI one would fail first because the slop-em-up one would end up with bots just copying a bunch of fixes from mainline Linux.
Haiku, anyone?
Are you asking for a poem, or suggesting the BeOS based OS?
I’m suggesting the BeOS successor.
Thank you for clarifying. It needs better software, but I used Haiku as a primary OS for a month a few years back. I was able to dig out old games and play them, so no major complaints here.
