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

  1. No, the Linux kernel won’t use AI to auto approve code for inclusion. And no plans to do so
  2. 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.
  3. 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
  4. 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
  5. 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
  6. 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

  • auzy1@lemmy.worldOPEnglish
    2510·
    1 day ago

    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”

    • urushitan 漆たん@kakera.kintsugi.moeEnglish
      134·
      1 day ago

      Yeah lol also reading through the actually interaction around the patch

      > The uptodate check in filemap_read_rcu_can_copy() has to stay, though.
> The flag only says the folio was uptodate when it was marked. Some
> filesystems clear PG_uptodate on a folio that stays in the page cache,
> and that can happen after the folio got the flag.

Those filesystems are buggy.  We have assertions that the uptodate flag
is set on folios mapped into userspace, and filesystems going arund
clearing the uptodate bit will cause problems.  It's something I'm
working on removing, but since it's all connected to writeback errors,
it takes a lot of arguing with each filesystem maintainer.

      So one of the reasons there’s so many changes in the patch series is to account for… human bugs

      • auzy1@lemmy.worldOPEnglish
        74·
        1 day ago

        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.