You aren't losing Linux
Heya!
I just read this post by Dr. Glowcat, and I have some thoughts to share.
First of all, I don't like AI. I feel like that's obvious if you take a look at my blog, but I just want to mention it here again, in case this is anyone's first time reading my stuff.
Still, I think what the Linux Kernel Team is doing here is the correct decision. Fact is, trying to ban LLM generated contributions is just completely unviable. Yes, you can catch people who suck at programming, and offload all the work to the LLM. Those people would not get their code accepted or reviewed anyways. The Linux kernel has coding standards already.
And if the AI-Generated contribution is of good enough quality to pass the scrutiny of maintainers? How exactly are you supposed to know whether or not a human wrote it? Sure, you can mandate that people disclose AI usage. But people can, yknow... Just lie about that. There'd be no way to tell, assuming they do some minor editing and generally understand the things they're submitting. (and if they didn't do either of those things, you can refer to my previous point: It'd be a low quality submission, and wouldn't pass code review)
Linus has commented about this before, it's a fools errand to try and police AI usage in large open source projects, you're not going to be able to do it.
There is zero point in talking about AI slop. That’s just plain stupid. The AI slop people aren’t going to document their patches as such. The documentation is for good actors, and pretending anything else is pointless posturing. (https://www.fosslinux.com/159063/linus-torvalds-ai-linux-kernel-debate.htm)
All of this gets especially tricky if we're talking about AI bug reports/security patches. If an LLM has found an incredibly serious security issue in your code, are you not going to accept that bug report because it's AI generated? Recently there was a magento 2 day zero security exploit where, for about a day, the only mitigation patches available were AI-assisted.
I mean, what would you rather do? Potentially compromise the private information of thousands of customers, or apply a stop-gap solution partially generated by an LLM? I know the answer here is: I'd rather there be a human-made patch instead, and like, yes, i agree, trying to understand LLM generated vulnerability disclosures is not fun...
But also, what else are you going to do? With really, really serious security issues, you're on a timer. You have to fix stuff now. Trying to recreate and fix that bug yourself is not going to be reasonable when it's already being automatically exploited in the wild, and there's a security patch that you could be using.
Anyways, the Kernel team is doing what is really the only viable option for a FOSS project of this size: they're planning to no longer spend as much time giving feedback on bad code submissions. This sucks for people trying to get into kernel programming, right? Like, it obviously does, I'm not going to pretend otherwise here.
...But what else are they supposed to do? The Linux kernel is getting absolutely flooded with slop pull requests & bug reports, and it is not always easy to distinguish bad programmers from bad LLMs. Sure, you can do it, but that takes some time. Which is the problem here, right? The problem is that we don't have enough time to review all this stuff. It's very easy for one asshole with an LLM to waste a whole lot of your time before you realize what's going on.
This was my chance to share a couple of anecdotes I had been saving for this gathering. While running on the unending treadmill that is keeping up with the linux-kernel mailing list, I had recently encountered a series of well over 100 patches, all sent within an hour from a new identity, making significant changes all over the kernel tree. When viewed that way, those patches are the obvious output of an unleashed bot and best ignored, but most maintainers only see a few of them, miss the pattern, and attempt to engage seriously with the sender. So many of those patches are applied. (https://lwn.net/SubscriberLink/1099594/be20382b54a9b4cd/)
There is an incredible flood of first-time contributors (nearly 800 in 7.3 alone) burying the community in patches. There have been plenty of cases of first-time contributors who make non-trivial changes to multiple subsystems over a short period of time. To me, it is clear that many of these submitters do not understand what they are doing, and they will not be around to fix or maintain those patches. But a lot of that code is getting into the kernel. My fear is that we are building up a collection of code that nobody understands, and that one day we will wake up and find that we have completely lost control of our kernel. (https://lwn.net/SubscriberLink/1099594/be20382b54a9b4cd/)
Airlie responded that we never really did have control over it. Torvalds said that the time has come to make it harder for new people to contribute code to the kernel. People like Kroah-Hartman have spent years trying to teach people how to contribute; it is time to stop doing that, he said. Ojeda said that there is a need to deprioritize these contributors, but that we still need to find talented people to join our community. That means finding ways to focus on the people who actually matter. For example, the people who take the time to go to conferences are much more likely to stay around. The vast majority of patches from new contributors are not worth it, but some are, and identifying them is hard. (https://lwn.net/SubscriberLink/1099594/be20382b54a9b4cd/)
And while this does suck for new contributors, it's not like this is the end of the world. It'll still be possible for new contributors to contribute to the kernel. You can learn how the subsystem you want to work on works by reading the code, and looking at newly accepted pull requests for examples of what & what not to do.
It's not like the solution they're pursuing is to just stop accepting pull requests from new contributors either. It's simply de-prioritizing singular patches fron unknown contributors. Those patches will still get reviewed, it will just take longer.
Ryabitsev said that problem is that contributing to the kernel has always been gated; it is too hard for many developers to do successfully. LLMs have made the creation of kernel patches easy. Pinchart said that a lot of LLM-using contributors just want to see their name in the changelog; they are not going to stay around, so any effort put into mentoring them is wasted. Torvalds repeated that maintainers should simply deprioritize those contributions. Hildenbrand asked how that could be done; Zijlstra suggested responding to a patch and seeing whether LLM-generated text comes back. Comments that do not evoke a clear human response can simply be ignored. Kroah-Hartman said that is the value of pointing out trivial items, like include files in the wrong order. Christian Brauner said that overly verbose changelogs are often a sign of LLM use.
And you can take issue on Linus' stance on AI, right? I don't fully agree with the guy either. But it just is true that disallowing AI generated code is just going to be nothing more than posturing at best, and at worst results in witch-hunts against people who just happen to write their code comments in ways that look similiar to how an LLM would do it. It's not a practical stance for any large FOSS project to take.
The only practical way I can think of enforcing an Anti-AI contribution policy on a scale as large as the Kernel would be using a project like vouch. And if you're concerned about a project being inaccessible for new contributors... Well, vouch just flat out guarantees that inaccessibility, by design.
Basically, what I'm saying is: This sucks. If you're a large open source project, you're currently getting fucked. But it's also pointless to pretend that the sky is falling here, and that the Linux kernel is suddenly doomed. The core project is fine. Linus has made it pretty abundantly clear in pretty much every instance he's talked about AI slop that the primary issue for him is code quality.
"LLMs can do a good job, but they are being driven by people who have no clue, and the results are ugly."
Linus isn't gonna be vibecoding the kernel or whatever, it's not going to stop accepting new contributors, and subsystem maintainers still have the final say on what actually happens with their subsystems. This isn't the kernel apocalypse. You're gonna be fine. You're not "losing linux".