Development statistics for the 7.2 kernel (lwn.net)
110 points by farlight 4 hours ago
ogoffart 3 hours ago
I have noticed the same on my project.
The agent helps a lot to fix bugs. Just point the agents at the bug reports. They do the reproduction, debugging and fixes. We "just" have to review. (Sometimes ask more details and tell we'd prefer another approach.) This makes bug fixing much faster and automated.
And at the same time, it seems we get less bug reports to our library. I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.
So overall, the open bug count is decreasing. Which somehow feels good.
On the other hand, we get a lot of PR made by other's people agents, which can be a bit overwhelming when it's just a huge code drop. We can't easily review that.
timhh 3 hours ago
> > and agents don't report bugs, they just work it around somehow.
Yeah I've definitely noticed this. On a project I'm working on Opus 5.5 found a bug in Smithay and another in Winit. It did tell me about them but its preferred solution was just to work around them locally. To be fair we don't really want agents going off and reporting bugs automatically...
I don't run any big open source projects but I think my preferred solution to AI PRs would be to get my AI to implement the same thing, and give then afterwards tell it to look at the PR for anything it missed. Then I at least know that I'm using a competent model and it reduces the danger of just blindly accepting someone else's code. (And obviously review the code if you have time and care, but that isn't always the case.)
cocoto 2 hours ago
Yes the default behavior of working around the bug is good, that’s what everyone was doing anyway pre-LLMs. The good practice is to report the bug. Simply add instructions to your agents to report you the bugs it found in the summary, so you can check the bug and report it correctly upstream.
0x696C6961 13 minutes ago
veqq 23 minutes ago
> I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.
It's quite a pity, preventing us from improving our model of the domain, from Naurian theory building and presenting a perfected API etc.
fock 3 hours ago
also the agent might introduce bugs, just like a human (see rsync which now has very busy development). Likely we (and the LLM) just won't notice them as easily. Fun times I guess.
throw73847939 2 hours ago
And? People also introduce bugs. If you are too lazy to setup verification harness, you will be even more lazy to do all testing manually.
Rsync is hopelessly underfunded under staffed. Current developer was forced to takeover, because everyone quit!
zdw 3 hours ago
Greg KH did a video on the flood of LLM created stuff: https://www.youtube.com/watch?v=NnV_cWeoo5Q , HN thread: https://news.ycombinator.com/item?id=49929391
Which covers how he responds and pushes back on much of this, as well as asking for a patch (not just bug reports)
rfgplk 2 hours ago
> pushes back on much of this
He's "pushing back on this" because he's being obsoleted in real time.
MarceColl 2 hours ago
Oh, you dont have to worry. You'll be obsoleted waaay before him.
rfgplk 2 hours ago
05kqhg 4 hours ago
The headline is "Development statistics for the 7.2 kernel", and the last paragraph is highly LLM critical in contrast with the editorialized headline "Linux bugs fixed per release over time: >2× rise since 2026-04", which seems to imply some sort of Mythos bug finding.
From the last paragraph:
"The Linux kernel is aimed at production use, not research or experimentation. But there is currently a massive experiment being run on the kernel's development processes and community."
mh- 3 hours ago
The following sentence:
"This community has absorbed new processes and tools many times over its 35-year history, and will almost certainly find a way to do that this time as well. But that absorption has not always been without turbulence along the way."
seb1204 19 minutes ago
Elaborated in here https://news.ycombinator.com/item?id=50133642
jayd16 3 hours ago
The major issue with these kinds of blurbs is that there's no control.
Historical numbers are not valid because incentivizes of a well funded entity have changed. It would require an equally well funded push to up the patch numbers without LLMs to really measure the impact in a quantifiable way.
AmazingEveryDay 2 hours ago
Just how massive can the machine-generated amdgpu header files get, it may be time to set some limits.
tosti 2 hours ago
Heads up for those upgrading to 7.3, I just downgraded my slackware box from 7.3-rc7 to 7.2.10 because /dev/input/events was missing. Keyboard and mouse only worked in the console as a result.
YMMV
dash2 2 hours ago
So it seems worth vibecoding a survival analysis for bugs introduced. But not quite a survival analysis because we don't even know the bugs exist until the event of their discovery.... Is there a publicly available dataset for this, with a URL?
cwillu 3 hours ago
Please don't editorialize titles.
(Edit: title has been fixed)
dang 3 hours ago
Submitted title was "Linux bugs fixed per release over time: >2× rise since 2026-04". We've reverted it now.
Submitters: If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
lurk2 3 hours ago
I got shadow banned. How do I delete my account?
dang 2 hours ago
steelframe 2 hours ago
tomwojcik 2 hours ago
Matl 4 hours ago
While great in theory, the flip side is all the slop patches and PRs that both the kernel and open source in general now has to deal with, often with only agents as responders.
It honestly doesn't want to make me open anything for outside contributions anymore.
dist-epoch 2 hours ago
do you want the bugs in your project fixed, no matter the source, or do you want only humans to contribute.
Linus wants the bugs fixed.
mathisfun123 4 hours ago
greatly exaggerated as indicated by linus' own feelings
https://lore.kernel.org/lkml/CAHk-=whTs09_ozN+e09GU68N1wPP56...
rvz 3 hours ago
Clearly, Linus is all over the place here.
He used Claude Code to write one of his patches in [0] and introduced a data race bug in the kernel unbeknownst to himself but this bug was caught by other reviewer [1] before it made it into a new kernel release.
So I'm afraid Linus himself did not understand the changes Claude made to the code he submitted in the mailing list, despite his "principles" in telling others previously that AI was creating slop patches and then now shouting at others who were concerned about using LLMs on code where they do not understand the generated code themselves when it all applied to....himself.
ceejayoz 2 hours ago
biorach an hour ago
senderista 3 hours ago
Linus's claim that use of LLM tools is uncorrelated with understanding or competence is ludicrous.
munchbunny 3 hours ago
vlovich123 3 hours ago
cwillu 3 hours ago
rfgplk 2 hours ago
mathisfun123 3 hours ago
pelagicAustral 4 hours ago
To the surprise of no one. Although, I must recognise that I did not envision a future where Linus embraced AI as frictionless has its been, then again after the inclusion of Rust in the kernel, I probably would've risked some money on it.
nomel 3 hours ago
> where Linus embraced AI as frictionless has its been
Why? He seems very pragmatic. I fully expected him to embrace it, with the only concern being correctness and quality.
pelagicAustral 3 hours ago
True, but I think there are quite a few very pragmatic people in here, and yet you see the they don't exactly go around singing praises.
nomel an hour ago
bitwize 3 hours ago
mycall 3 hours ago
Also, it took a long time for rust to mature to be considered for linux kernel development. AI is faster but easier to integrate.
mrheosuper 2 hours ago
As someone who hates c++ so much, he is surprisingly nice to llm.
dist-epoch 2 hours ago
bigstrat2003 2 hours ago
That's exactly why one would expect him to not embrace it. LLM usage is anti-correlated with either of those things.
nomel an hour ago
teekert 3 hours ago
100%. Too many people equate LLM assisted programming with vibe coding some slop. Which is just a weird thing to do at this point.
nvme0n1p1 4 hours ago
Yes, Linus is quite forward thinking, and we can credit that with why Linux has stayed relevant for so many decades. Not many software projects manage to pull that off.
dist-epoch 2 hours ago
Linus has always been pragmatic as opposed to dogmatic.
20 years ago he was fine using BitKeeper, proprietary software, for kernel source control, because it was better than Subversion and CVS. He only created git when BitKeeper introduced some road blocks.
VCFundedGenYer 3 hours ago
They are also now vibe coding the kernel which is a major issue. Race conditions were already found in one of the slop suggestions. Linus is apparently fine with this degradation in quality.
New leadership is needed over there.
seb1204 8 minutes ago
kstrauser 2 hours ago
Who’s vibecoding the kernel? I’ve heard stories of devs using AI to help write code, but don’t recall a single story of an experienced kernel dev vibecoding anything.
ttul 2 hours ago
I suppose, feel free to fork the kernel and take the lead?
AspireOne 2 hours ago
Come on.
lousken 3 hours ago
atlantic 0000:0f:00.0: PM: dpm_run_callback(): pci_pm_resume.llvm.11545057702175119861 returns -12
atlantic 0000:0f:00.0: PM: failed to resume async: error -12
AI fix this, thanks
viraptor 3 hours ago
You can literally do that now. Exactly as you wrote it...
lousken 2 hours ago
Not good enough, I am testing if some agent is checking hackernews and will fix it for me