There appears to be a few bad actors in the Lemmy community spreading ragebait for personal gain
In fact, the same mechanisms added at the beginning to catch bad human written code are the exact same that catch bad AI code
- No, the Linux kernel won't use AI to auto approve code for inclusion. And no plans to do so
- The Kernel actually has a huge number of maintainers. As part of the process, all patches are reviewed by a human who provide feedback as part of the process, and patches get bounced back and forth multiple time.
- Patches don't just magically go straight to master. The maintainers generally have their own branches where it goes to, then it goes to staging trees like Linux-Next. It goes through many eyes, and many tests by the end. The idea that AI code is overrunning the kernel is rediculous
- Maintainers also check that the code meets coding guidelines and is written properly, and solves the problem they are trying to solve. Yes, they also ensure the code isn't slop
- LLM's though might be used to identify obvious problems (bugs / coding guideline issues) with the code. These don't generate "slop" just find issues
- The only thing that matters is the human who submitted the code, as they should be checking the code submitted anyway (including LLM generated code).
Writing bad code isn't something new, and isn't unique to LLM's. Coders (and it seems some "journalists") have been writing slop since computers were invented.
The process hasn't gotten less stringent (probably even MORE stringent as there is an additional set of robotic eyes that can also check), and the same mechanisms that were put in place to catch badly written code 10 years ago, are still there now
Linus just yeeted a slop bomb before going on vacation. This is the definition of slop. LLMs have no business near the kernel code or being used at all.
https://tech.lgbt/@workingclassgames/117447428388877864
https://lwn.net/ml/all/as6vBoWQGglxXxb0@thinkstation/
https://lwn.net/ml/all/CAHk-=wiCe2H33izZHDyDHEhcFwUr9fXZk27-WZ2vn_pn5FcZTg@mail.gmail.com/
So... your evidence for slop is that he made a patch, they caught an issue in the review process, and then he had to go on vacation so he asked another maintainer to take over to get the change done correctly in the merge window?
How is that not the process working exactly as intended?
Nonono, you must understand, every patch Linus made before using AI was flawless and required no review at all.
People really be thinking every fully human-rolled PR is gonna be flawless, yet the influx of fresh CVEs is higher than it's ever been right now, because LLMs are busy poking holes in existing human code.
Exactly this.
I've been doing code review on some of our code from 10+ years ago and I'm surprised by how many major bugs I'm STILL finding (different ones between Claude and ChatGPT). And this is code that's been in prod for years, and in heavy usage.
Yeah but
humanSlop = good.
aiSlop = bad.
The funny thing is that I wrote a Websocket server library years ago, and recently (as we scaled up), there were reports of bad performance in much larger systems
AI actually basically called my code slop (and it was), and made changes that improved performance, and fixed issues with incomplete frames. The solution it came up with was far better, and far cleaner than mine. I never would have come up with it..
And, I never would have guessed that's where the performance issues were either
I feel like there are people who are willing to point the finger instantly when AI generates bad code, but, it doesn't get credit when it improves it
So you are just a terrible developer then. Not sure what you are trying to show here with your anecdote other than your inadequacies to do your job properly?
What I said doesn't indicate that at all. Not sure how many websocket servers you've written, but there is a reason that there are entire test suites to test them
Even worse, there are all kinds of combinations of half finished frames, masking, etc. The data size isn't predictable and you can also have fragmented frames too.
We also need to connect to all kinds of clients which do things slightly different
And, I had limited time to write it in as well.
If you're not getting any bugs, you're either not doing anything new, or you're designing really basic apps that offload the hard work to someone else.
Big shocker, but the performance fixing came down to bit handling of the header.. and yes, that made a huge difference overall. The code wasn't wrong...
We're working with embedded systems limited by RAM and CPU that operates on a single thread for everything, with lots of clients .We don't have the luxury of throwing in a better CPU or just pretending it's an issue. Even simply enabling logging drastically changes the CPU usage
I mean, these are your words.
A profiler ought to show you where it's spending the most time.
I did profiling. But, there were many other more likely candidates, and, its a bit of a weird edgecase in our case (since we don't control the entire environment.. It's middleware)..
I think we need a redefinition of "bug" though. If something hasn't been noticed for 10+ years, is it really a "bug"? I think the definition should depend on the probability of negative effects, not just on the possibility.
In fact, my impression is that any piece of code can be shown to have some bug, if taken from a particular angle or in particular contexts or scenarios.
(I think there are also connections with mathematical-logical foundations. For example, it is impossible to build an axiomatic system that is enough powerful and does not have undecidable propositions. Whenever you fix the axioms to fix one of the undecidable propositions, another one automatically pops up.)
Just because an issue isn't reported though, doesn't mean it hasn't been noticed by users.
We often see issues which are discussed in private forums, but were never actually reported to us (which is why we check them all)
Yes. If the intended functionality fails under conditions not often seen, it's still a bug. Bugs can be lower priority but that doesn't make them not bugs.
Your accusation is the definition of slop. Sounds convincing, asserts to have sources, turns out there's nothing of substance.
From my understanding, that was a patch series that was still under development, and NOT in the kernel. And, it was caught in Code reviews.
Code reviews are normal, and stuff like this is NORMAL, and has been well before AI. Are you seriously claiming the kernel never received buggy patch sets (in staging / non-master trees) in the past?
Also, it is interesting that the same 3 links seem to be posted everywhere blindly. Did you even read what I wrote in my post?
Do you mind explaining the technical reasons why the patch is "slop"? Or, did you just see the LLM part and think "this is gonna be great pitchfork material and I'll pretend like I actually understand whats going on"
Yeah lol also reading through the actually interaction around the patch
So one of the reasons there’s so many changes in the patch series is to account for… human bugs
Was actually going to mention that.
There are also ambiguities in specifications too.
Like one of our libraries is a websocket/http server I developed, that has been working fine for years. However recently, a system broke, and we actually discovered it's because there are even small ambiguities in http areas too that we need to accomodate, and I couldn't find anything in the specs that explicitly prevented it either.
Dependencies, dependencies everywhere! https://xkcd.com/2347/
(well, maybe not exactly right, but similar problem.)
Cool. Let us know when your fork is packaged and I'll test it out.
your ai will test it out
Nope. I assisted system test back in '04 when I was doing build/rel for Unix and ent Linux, so it's no big deal: if you have a test plan I'll run it too.