This is a bad idea. Now we don’t know who actually wrote the code, and therefore who owns (or doesn’t own) the copyrights. This is really, exceptionally stupid.
Now we don’t know who actually wrote the code
Did you ever? Really?
On the internet nobody knows you’re a dog.
The mailing list change the article is referring to: https://lore.kernel.org/lkml/20261009083137.3-1-sashal@kernel.org/
I wonder if the original rule was too broad and it was leading to noise? I’d prefer to have attribution when code is written, but not in all cases
If someone uses an LLM to brainstorm or track down a bug, then confirms it and writes the fix by hand, adding attribution might end up being noise.
Meanwhile if someone uses the LLM to write the fix, then that should get attribution
Linus said it wasn’t working because “almost no one was using it”. Everyone was just lying because they were ashamed to admit they were using AI.
Given Torvalds’ attitude towards AI, it’s not surprising.
“They’ve gotten good enough to find bugs because LLMs, AI, are just pattern matchers and code is nothing but patterns in a specific format.”
True, but let’s not forget that
2 + 2 = 4can be achieved through a million different patterns[1], so just because AI can find a working pattern doesn’t make it goodLinus comparing AI to text editors and fucking compilers shows how high on his own farts he is. Given the same input, a compiler will always produce the same output, down to the last bit. The same cannot be said about AI - throw the same version of claude code with the same prompt on the same computer file and it will produce different results, maybe with a “similar enough” end result, but not identical.
AI is not a tool, it’s a million monkeys with keyboards that cannot be held accountable for their output.
(((((64 / 2) / 2) / 2) / 2) / 2) + (((((64 / 2) / 2) / 2) / 2) / 2)is a valid pattern for 2 + 2, for instance ↩︎
just because AI can find a working pattern doesn’t make it good
I have seen so much from AI supporters saying “it can be a good tool” to save time, but I’m not sure I’ve ever heard anyone try to make the claim that it’s a tool that leads to better code. That should be very telling.
I hate to be that guy but there are compilers with non-deterministic optimization strategies and they do tend to be the most performant. They’re just generally disallowed in major project distributions because the maintainers want the artifact to be verifiable by and end user for security reasons.
Huh, TIL. Off the rabbit hole of compiler (non)determinism I go
Being a million monkeys or not, it is a tool. The relevant definition for tool is:
something (such as an instrument or apparatus) used in performing an operation
That’s not to say it’s a good tool, or that it’s a tool being used appropriately by many people. What even is appropriate use of AI?
Accountability should be definitely be properly assigned to the user. I’ve heard of tradies blaming their tools for shitty work, but I’ve never heard of one actually holding their hammer accountable…
What even is appropriate use of AI?
Industrial scale misinformation and scamming.
Also, sometimes the responsibility falls onto the tool maker. Remember Crowdstrike? That software update that caused widespread outages in Windows computers used by many organizations, including in airports? It wasn’t any user’s fault, surprisingly it wasn’t even Microslop’s fault, it was Crowdstrike’s fault alone.
I’m not sure that’s appropriate even if it is the most common use …
I think there’s a difference between responsible and accountable. Accountable requires that you be held to account if things go pear shaped. Crowdstrike were responsible for their outage but I’m pretty sure their responsibility ended at at “here’s a new patch to fix our fuck up”. No one was charging or fining them for the outage or putting those responsible in prison. I think a toolmaker might be held accountable of their tool exploded when it wasn’t supposed to and was killing people. For example the Ford Pinto. A car is a tool for getting people from one place to another, and the toolmaker was held accountable for their shit design. If you were operating the car out of spec or driving it into walls, then you as the operator would be held responsible and most likely accountable.
That quote was someone else
“LLMs are good enough now,” said Greg Kroah-Hartman, a veteran Linux kernel maintainer, at the Linux Foundation’s Open Source Summit in South Korea in August. “They’ve gotten good enough to find bugs because LLMs, AI, are just pattern matchers and code is nothing but patterns in a specific format.”
Also to be fair, that quote is about finding bugs and the guy might not have been talking about using AI to patch them. The article makes it sound that way, but the article also seems overly confident and pro-AI about some other things too.
You can deterministically find something that is clearly defined, but bugs don’t fall into that category
I know, but even regarding bug catching, there have been a LOT of bogus bug reports “discovered by AI” that could not be replicated in any way, shape or form. Granted, I’ve seen one or two articles saying that AI helped find real software bugs, but what’s the ratio there, 1:500 for useful/useless AI bug reports?
Granted, I’ve seen one or two articles saying that AI helped find real software bugs, but what’s the ratio there, 1:500 for useful/useless AI bug reports?
It’s worth distinguishing between LLM generated bug-reports submitted by randos, and developers themselves using LLMs to look for bugs in their software.
My own experience, with my own code-bases, is that the LLM I use is extremely good at finding real flaws in my code. It’ll also nitpick a lot, but it has has become better at triaging issues than it used to be, so that kind of thing is easy to ignore.
Because of that, having an LLM take a look at my code before I push it has become another QC step, along with running tests, linters, and formatters. The end result is higher quality software
bogus bug reports “discovered by AI” that could not be replicated in any way, shape or form
And we NEED to be more serious about use of secure verifiable identities for people so we can properly filter inputs from internet contributions. Anonymous sources should be de-prioritized to just above the known consistently bad actors. That’s nothing about AI or LLMs, that’s just the world continuing to be far too trusting of basically anonymous contributions.
If you want to submit a bunch of AI slop under your secure ID, be prepared for that ID to be de-prioritized beneath anonymous contributions.
If you want submissions from your secure ID to be taken seriously, at least task your LLM with building a proof-of-concept replication of the bugs in the reports your other LLM session creates before submitting it for humans to spend their time evaluating.
We have a human test department overseas that gets a little eager to pump up their metrics once in a while, we haven’t resorted to penalizing them (yet) but when they send an “observation” with no way to reproduce it, no log files to back it up, we tend to ignore that observation until the review meeting and then in the review meeting ask “have you seen this again? do you have any way to reproduce it? do you have screen shots or log files?” and when all those things are missing, the observation is closed with a “cannot reproduce” tag, waiting for another tester to see it again and produce more evidence.
the article also seems overly confident
Anybody writing articles about AI, or evaluating articles about AI, needs to get very specific: what month are they talking about, because if your reference point for “overly confident” is based on where things were 8-12 months ago, that’s very different from where things are today, and many times experts in the field project progress to what they expect for the future - that is of course unreliable speculation, but so far most of the reasonable optimism from the last year or two for progress in LLM software authorship and maintenance proficiency has been borne out in reality. I’m not talking about the “software is solved” numbskulls, but the progress in terms of being a valuable tool set the way C compilers were valuable tools to former Assembly programmers - yeah… it’s gone there.
I also recall trying to use Borland Turbo C++ in 1991 and abandoning it because it was too buggy, wrote the project du jour in C instead, saved the C++ rewrite for 1996.
Given the same input, a compiler will always produce the same output, down to the last bit. The same cannot be said about AI
LLM’s have something like a temperature setting that is producing the intentional randomness, so that you prompting it is not going around in circles all the time. (if you are running an army of agents this is actually important for usefulness)
Anyway this is not an inherent LLM thing, it can be turned off.
Fame does something to people, either that or he’s burnt out and this is a midlife crisis. I love unix based operating systems, but sometimes I feel Linux was the wrong thing to get popular unfortunately. It abandons so much of the core philosophy.
just because AI can find a working pattern doesn’t make it good
It’s a wee bit more sophisticated than that, and will tend to find 2 + 2 even when 16/4 - 8/4 gives the same result. And if you suspect it’s settled on an over-complicated solution you can add the prompt: “Search for simpler architectures which meet all requirements with less complexity.” It won’t always find the simplest possible, but generally speaking - I find LLM agents to be a bit better than my human colleagues in terms of finding good simple solutions and also finding problems within implementations.
None of us are perfect, and LLMs are trained on our writings. LLM agents within coding frameworks have progressed easily +10 years of human experience in their perfomance levels in the last 12 months. It’s still an blueberries to tangerines comparison, a lot of what makes the LLM agents “good” is their speed and thereby ability to experiment with alternatives in a reasonable time.
I can’t see how this can go wrong.
Unpopular opinion: it shouldn’t matter when it comes to code quality.
If it’s a dev with AI and the code is good, then it should be merged.
If it’s a dev with AI and the code is bad, then the code should be rejected.
If it’s a dev without AI and the code is good, then it should be merged.
If it’s a dev without AI and the code is bad, then the code should be rejected.
So in that case AI has no effect on the outcome. The only explanation I can see for making it visible is for the sake of licensing. Which I don’t have an opinion on right now because I haven’t looked into it enough.
People using AI push a lot more code in a shorter amount of time. That deluge makes it much more likely for bad code, intentional or not, to slip by.
“Just leave it to a few trusted devs”
Some bad actors can play the long game. The XZ Utils backdoor is a very recent example of a contributor trying to abuse a backdoor he put there himself, after 2 years of posing as a helpful person.
“Let AI review it”
If humans are prone to mistakes, why would anyone leave a probabilistic program that is known to make bad decisions at random and that has, on more than one occasion, “cheated” to pass quality tests, deleted files it shouldn’t and is still suceptible to prompt attacks, review it?
I understand the sentiment of “if the AI generated code is good, allow it”, but the “productivity” gains in writing code means that, sooner or later, the person using the AI will care less and less about reading and preemptively catching possible errors because there’ll be so many alterations that he either has to spend a month reading, or just skim over and accept.
The XZ Utils backdoor is a very recent example of a contributor trying to abuse a backdoor he put there himself, after 2 years of posing as a helpful person.
A game that has been played for decades. A game that LLM review of merge requests should be making very much harder to play in the future.
Harder for the people who don’t want backdoors or critical security bugs approved, you mean
Harder for the people who want backdoors or critical security bugs approved, I’d say.
That promise of open source is getting a little boost here: many eyes on the code, insecure patterns revealed for lower effort in less time - able to be caught before wide release because the (robot) reviewers have the capacity to run the code through many more test scenarios before delivering a verdict.
Can you ensure that the llm reviewing the code will not hallucinate and, more importantly, will not fall to some prompt injection that can be within the code?
There are no guarantees in life, especially when dealing with people you’ve never met on the other side of the planet through the internet.
However, when an LLM finds a real bug or vulnerability, somewhat akin to an NP-hard problem, you can much more easily verify that the problem is real once it has been identified - you can do the verification with or without LLM assistance.
will not fall to some prompt injection that can be within the code?
that is a concern, one which has been identified and is in a state of continual improvement to make less of a concern in LLM agents / harnesses. It’s also not without human based precedent, with misleading comments and even obfuscated code structure leading humans to believe that code does something different than what it looks like to a casual or fast/shallow reader. The ability of LLM agents to more quickly run many actual tests of the code than a human tester is a huge advantage in determining what code actually does, and identifying rarely triggered pathways that may have concerning functionality.
The thing is: the review process now also has AI, and those AI assisted reviews are much more stringent than the traditional human only reviews. Neither are perfect, ideally both would give the submission all the attention it deserves - in real life that rarely happens, though at the moment the LLMs are fast and cheap enough that you really should let them review anything you are considering approving for merge - not necessarily take everything they output at face value, but I find that they find real problems that real humans often miss.
let them. Seriously, let them do it.
And when the day comes, and it will, when something is submitted and approved and breaks shit then people can turn to the devs and Linus and say “I told you so.”
my decision a few months ago to start daily driving BSD doesn’t seem to be a bad one.
FreeBSD and OpenBSD both allow AI and contain AI-generated code. NetBSD requires prior approval but doesn’t outright ban it.
OpenBSD doesn’t allow it, what are you on about?
https://lwn.net/Articles/1064541/
Thomas de Grivel made clear the chances of accepting code with such a murky copyright situation were effectively nil, and he said on March 23 that he would remove all the LLM-generated code and keep only what he wrote himself.
open-slopware calls OpenBSD having a “Permissive AI Policy” and links to this commit as evidence.
when something is submitted and approved and breaks shit
Not to defend AI, but this already happens in the kernel, often. It has been this way since long before LLMs were around.
Yeah, they literally just had an rc of 6.18 that doesn’t compile.
then people can turn to the devs and Linus and say “I told you so.”
I bet his response will be an email with a dozen variations of “fuck you for insinuating that I have any responsibility, I didn’t approve that specific commit, it’s all <approver>'s fault who is a fucking imbecile”
it’s all <approver>'s fault who is a fucking imbecile
And, as always, he’s not wrong.
Linus and say “I told you so.”
Linus fully approves this. What imagination land do you live in?
when the day comes, and it will, when something is submitted and approved and breaks shit
That day has been coming, over 300 times a year for the past 30 years. People submit things that break shit all-the-time, the system is setup to deal with it, that’s the actual genius of FOSS development procedures, they’re built to handle it.
Now, the firehose isn’t just opened, the hydrant has been knocked off entirely, and there will be some growing pains to deal with the volume, but the basic procedures are well developed and I find that applying them to LLM outputs (before passing those outputs anywhere off my own desk) goes a very long way toward refining slop into genuinely robust solutions.
Because they’re all using it.
AAAARGH!!! I JUST FINISHED HARDENING MY MAIN LINUX BOX! I LIKE BSD BUT DID I JUST PUT ALL THAT EFFORT IN FOR NOTHING‽‽‽
BSDs allow AI too
OpenBSD only has a handful of slop commits, NetBSD only had one and apparenty has since removed the code, and both MirBSD and HyperbolaBSD are firmly anti-AI (though not ready for release yet).
Besides, this new policy of not having to declare AI-generated code doesn’t apply to BSD.
3·2 days ago@heliotrope @cm0002 Securing a system is always good practice and the effort was well spent because you (ostensibly) learned something.
Unrelated question, how do I pin the version of my kernel?
Most package managers have a package hold option. (not that it wouldn’t be extremely dumb to do this on an Internet connected machine)
