• MonkderVierte@lemmy.zip
    link
    fedilink
    arrow-up
    15
    ·
    13 hours ago

    The bug reports may not be arriving yet. They will. And when they do, you will face the same calculation the kernel maintainers faced: maintain dead code to satisfy automated reporters, or cut it.

    This could actually be a good thing for software quality.

    • Alex@lemmy.ml
      link
      fedilink
      arrow-up
      25
      arrow-down
      3
      ·
      17 hours ago

      That’s not kernel policy but LF guidance. From the kernel’s point of view patches still have a high bar to pass to get merged and I don’t think we have enough data yet to see if LLM based submissions to the kernel have a higher or lower error rate than humans.

      I certainly feel the uptick in LLM reports though - one of the projects I’m working on is seeing a deluge of them at the moment.

      • ell1e@leminal.space
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        2
        ·
        edit-2
        12 hours ago

        The kernel policy seems to be what I think it is, since LLM slop patches have been merged.

        I find it slightly contradictory to delete code due to hidden bugs on the one end, then insert LLM code at the other rather than hand-craft the code to avoid hidden bugs better.

        • Alex@lemmy.ml
          link
          fedilink
          arrow-up
          5
          arrow-down
          1
          ·
          5 hours ago

          How is that patch sloppy?

          I feel the term slop is being overused to cover anything an LLM has touched. If I ask an agent to re-read a mail thread for me and apply the changes to my tree to review is that slop? Would you feel better about it if I copy and paste from email to code in my editor?

          I’ve just been doing a bunch of bug triage which was mostly driven by the agent although I checked the issues where it had commented. Was that slop? Ironically a lot of the issues where AI generated although for the most part more complete than a lot of the purely human submissions we get. Are those bug reports slop? What about the poorly drafted human ones?

          • ell1e@leminal.space
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            2 hours ago

            The studies about hidden errors don’t really care about how “slop” the code looks, as far as I understand them. That’s why LLM code is kind of dangerous.

        • ISO@lemmy.zip
          link
          fedilink
          arrow-up
          2
          arrow-down
          2
          ·
          5 hours ago

          You should look up the genetic fallacy. And using phrases like “hand-craft code” make you look stupid.

          • ell1e@leminal.space
            link
            fedilink
            English
            arrow-up
            6
            arrow-down
            1
            ·
            11 hours ago

            I’m saying if their policy is to accept AI code, which the link seems to demonstrate that it is, the rate of future hidden errors in the kernel code is likely going to go up. This is what all the studies are saying, including those involving competent coders.

            • Alex@lemmy.ml
              link
              fedilink
              arrow-up
              2
              arrow-down
              2
              ·
              edit-2
              4 hours ago

              Your making a big assumption extrapolating from one particular study involving Java code and a static analyser.

              • ell1e@leminal.space
                link
                fedilink
                English
                arrow-up
                4
                ·
                edit-2
                10 hours ago

                I heard it’s alright for games and many apparently work. Sadly, FreeBSD simply doesn’t seem to have drivers for a lot of hardware that I’m using. And as far as I know, they don’t have an LLM policy yet (so they could still come out in favor of it).

                • FuckBigTech347@lemmygrad.ml
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  3 hours ago

                  I’m on a machine w/ FreeBSD 15.0-RELEASE right now and my AMD GPUs mostly work (minus some features like manual fan control or overclocking, also certain shaders may make the driver crash). They pull in the amdgpu driver code from Linux so you get the same experience for the most part. Bluetooth is very hit or miss in terms of drivers. (Also I find OSS to be better than any audio “solution” on Linux.)

                  I haven’t been able to get Steam to work reliably. It starts up fine the first time after a fresh install. But on any subsequent startup it just hangs indefinitely. I also haven’t messed with WINE since I don’t really have the need, but FOSS games/ports generally just work (OpenRCT2, OpenMW, Quake, Doom, 0ad, SuperTux, Wesnoth, Xonotic, etc.).

                  As with Linux distros, I just recommend installing it on a spare machine or drive to see if it works for you. Definitely consult the FreeBSD handbook for guidance though.