| ▲ | Development statistics for the 7.2 kernel(lwn.net) |
| 115 points by farlight 5 hours ago | 68 comments |
| |
|
| ▲ | ogoffart 4 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | majormajor 42 minutes ago | parent | next [-] | | >I think user just use their agents to code, and agents don't report bugs, they just work it around somehow. Claude comes up with some truly delicious insane workarounds these days. Like launching something in a subprocess and capturing stdout/stderr and doing string parsing on info logs because of a desire for some hook not exposed by API (or at least that it didn't find on its quick scan). There's probably no such thing as semver reliability for dependencies anymore in stuff that agents glue together, since they will poke at ANY sort of way of getting additional insight or control if they want it. | |
| ▲ | timhh 4 hours ago | parent | prev | next [-] | | > > 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 3 hours ago | parent [-] | | 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 an hour ago | parent [-] | | I usually report the bug and leave a link to it in a comment beside the work-around code. |
|
| |
| ▲ | veqq an hour ago | parent | prev | next [-] | | > 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 4 hours ago | parent | prev [-] | | 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 3 hours ago | parent [-] | | 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 4 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent [-] | | > pushes back on much of this He's "pushing back on this" because he's being obsoleted in real time. | | |
| ▲ | MarceColl 3 hours ago | parent [-] | | Oh, you dont have to worry. You'll be obsoleted waaay before him. | | |
| ▲ | rfgplk 2 hours ago | parent [-] | | Not quite. My C++ Linux rewrite is already production ready, meaning in theory I no longer need to rely on the Linux kernel devs. This will, in a matter of months I presume, become the norm. | | |
|
|
|
|
| ▲ | 05kqhg 5 hours ago | parent | prev | next [-] |
| 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- 4 hours ago | parent [-] | | 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." | | |
|
|
| ▲ | jayd16 4 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent | prev | next [-] |
| Just how massive can the machine-generated amdgpu header files get, it may be time to set some limits. |
|
| ▲ | dash2 3 hours ago | parent | prev | next [-] |
| 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? |
|
| ▲ | tosti 3 hours ago | parent | prev | next [-] |
| 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 |
|
| ▲ | cwillu 4 hours ago | parent | prev | next [-] |
| Please don't editorialize titles. (Edit: title has been fixed) |
| |
| ▲ | dang 4 hours ago | parent [-] | | 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 4 hours ago | parent [-] | | I got shadow banned. How do I delete my account? | | |
| ▲ | dang 3 hours ago | parent | next [-] | | You haven't been banned, but quite a few of your comments have been breaking the site guidelines, and so correctly flagged. | |
| ▲ | steelframe 3 hours ago | parent | prev | next [-] | | Bummer that you got shadow banned. | |
| ▲ | tomwojcik 3 hours ago | parent | prev [-] | | I see your comment. |
|
|
|
|
| ▲ | Matl 5 hours ago | parent | prev | next [-] |
| 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 3 hours ago | parent | next [-] | | 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 | parent | prev [-] | | greatly exaggerated as indicated by linus' own feelings https://lore.kernel.org/lkml/CAHk-=whTs09_ozN+e09GU68N1wPP56... | | |
| ▲ | rvz 4 hours ago | parent | next [-] | | 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. [0] https://lkml.iu.edu/2610.1/13146.html [1] https://lkml.iu.edu/2610.1/13573.html | | |
| ▲ | ceejayoz 3 hours ago | parent | next [-] | | Is your belief that Linus never had a bug caught in code review prior to Claude? | |
| ▲ | biorach 2 hours ago | parent | prev [-] | | The data race is exactly the kind of subtle bug that even very experienced programmers would make in this circumstance. The patches that Linus posted are relatively small and self contained and from reading the thread it seems came from a series of in depth conversations with Claude and were carefully reviewed by Linus. So what we're seeing here is a tricky concurrency bug that even an expert would make. You can't use it as an example of slop |
| |
| ▲ | senderista 4 hours ago | parent | prev [-] | | Linus's claim that use of LLM tools is uncorrelated with understanding or competence is ludicrous. | | |
| ▲ | munchbunny 4 hours ago | parent | next [-] | | What he actually said was: > The kind of expectations I have is that people do their best and I expect people to understand what they are doing. > But that understanding has very little to do with what tools they use. > And quite honestly, in my experience, the people I respect and call intelligent are not the ones that shy away from using new and interesting tools. He’s saying that understanding or competence are more about the person than their AI use. I think that’s a reasonable argument, even though I disagree on the basis that it’s at least a little correlated in the shortcuts in understanding the many devs I’ve seen (not all, but a nontrivial amount) seem to be taking. | | |
| ▲ | senderista 4 hours ago | parent [-] | | To be clear: I believe that it's entirely possible to use LLMs to amplify understanding and competence, but that in practice LLM usage is anticorrelated with understanding and competence. This is about empirical reality, not logical entailment. |
| |
| ▲ | vlovich123 4 hours ago | parent | prev | next [-] | | As an example, I’m in the process of putting up a patch series to optimize some specific filesystem operations. The amount of boilerplate that has to know to get done is completely unapproachable to an outsider both from the amount of time needed to learn that boilerplate and form it in such a way that maintainers will be happy. Even though I know exactly how the code is working, it bridges that understanding gap but I don’t see how it correlates with incompetence. I may be an outlier but I suspect there’s a huge amount of people who are extremely capable and competent and it’s just that the Linux kernel has so many processes that it’s difficult to onboard into the community without LLM assistance. | | |
| ▲ | MobiusHorizons 4 hours ago | parent [-] | | The Linux kernel project is not hurting for contributors nor was it prior to LLMs. The processes you describe as roadblocks don’t seem to have been preventing the Linux kernel from getting code contributions. Maybe they don’t need or want more easy onboarding or broader audience? |
| |
| ▲ | cwillu 4 hours ago | parent | prev | next [-] | | Presumably the person who's full-time job is staying on top of proposed changes to the linux source tree knows something about this; what are your credentials on the topic? | |
| ▲ | rfgplk 3 hours ago | parent | prev | next [-] | | Linus himself is actually comically incompetent. He only became famous after the Linux kernel took off... decades ago? Since Git, he has made ZERO code contributions whatsoever (not even to the Linux kernel). He doesn't even review code and has his team of capos do it for him. All in all he's no different than the CEO of some tech company, his thoughts on LLMs are no longer relevant (for more lack of credibility, see his stance on Rust, C++, Go) | | |
| ▲ | nullpoint420 2 hours ago | parent [-] | | Why does he need to write code to be "competent." He's a structural and architectural genius. Projects like the Linux kernel do not pop up out of thin air. They need a leader. |
| |
| ▲ | mathisfun123 4 hours ago | parent | prev [-] | | how do you feel about his analogy > Here's a new rule just for you: don't use compilers for any of your
kernel submissions. > Because if you can't show that you really understand what the machine
is actually doing by writing your code in assembler, then I don't want
to see your code contribution. You clearly aren't competent if you
can't write it that way. | | |
| ▲ | Matl 4 hours ago | parent [-] | | I feel like you can't compare deterministic tools to non-deterministic ones so not a great analogy. |
|
|
|
|
|
| ▲ | pelagicAustral 5 hours ago | parent | prev | next [-] |
| 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 4 hours ago | parent | next [-] | | > 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 4 hours ago | parent | next [-] | | 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 2 hours ago | parent | next [-] | | You can usually be pragmatic but entirely emotional about something specific. Famously, Linus is both pragmatic AND emotional about being pragmatic. | | | |
| ▲ | bitwize 4 hours ago | parent | prev [-] | | The pragmatic ones are excited about where things are going. The ones complaining about "slop" are the ones going on vibes now. | | |
| ▲ | kstrauser 3 hours ago | parent [-] | | I’m strongly with you on that. Current models aren’t perfect, but neither am I. In a lot of my daily use, they’re as good as or better than I am at certain tasks. I hear people around me talking about a bad experience they had with ChatGPT last summer as though it proves all AI coding is “slop”. Honestly, it makes me sad for them. There are reasons to dislike AI, but so many detractors skip right past those to anecdata that just aren’t relevant anymore, if they ever were. |
|
| |
| ▲ | mycall 4 hours ago | parent | prev | next [-] | | 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 3 hours ago | parent | prev | next [-] | | As someone who hates c++ so much, he is surprisingly nice to llm. | | |
| ▲ | dist-epoch 3 hours ago | parent [-] | | LLMs write C for the kernel. He would hate them too if they only outputed C++. |
| |
| ▲ | bigstrat2003 3 hours ago | parent | prev | next [-] | | That's exactly why one would expect him to not embrace it. LLM usage is anti-correlated with either of those things. | | |
| ▲ | nomel 2 hours ago | parent [-] | | Or, he has a full understanding that, like everything single thing he's ever been involved with in his career, it's a new tech under development and will, as every measure up to now has demonstrated, improve over time. And, as all tech that has ever existed since the beginning of man starts, has somewhat initially limited, but still very practical and real, use in its current state. Again, he's pragmatic, and has seen countless types and iterations of tech come into existence. The people expecting perfection from the start have no actual experience with the creative process, engineering or design, and and only want progress to stop (because there is, literally, without exception ever existing, no alternative to iteration). |
| |
| ▲ | teekert 4 hours ago | parent | prev [-] | | 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 | parent | prev | next [-] | | 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 3 hours ago | parent | prev [-] | | 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 | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | lousken 4 hours ago | parent | prev [-] |
| 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 4 hours ago | parent [-] | | You can literally do that now. Exactly as you wrote it... | | |
| ▲ | lousken 3 hours ago | parent [-] | | Not good enough, I am testing if some agent is checking hackernews and will fix it for me |
|
|