GrapheneOS (@GrapheneOS@grapheneos.social)
grapheneos.social
@bekkaboo@girlcock.club Linux itself is heavily using AI models. Therefore, every Linux distribution moving to recent kernel versions is heavily built on top of using AI models. Creating a Linux distribution not heavily using it would require a hard fork of the Linux kernel and many other projects. It's unclear what would be accomplished by banning AI for a tiny portion of the code while continuing to use Linux, AOSP, Chromium and hundreds of other projects heavily using it. We'd still be benefiting from it.

GrapheneOS is currently defending its use of AI coding tools on Mastodon against complaints by various accounts claiming to be users.

We do not understand where you’re coming from or why you’re so incredibly angry with us. It’s not justified and does not make sense.

  • HaraldvonBlauzahn@feddit.orgEnglish
    10·
    2 days ago

    Supposedly wonderful “human artisanal code” has plenty of fuckery.

    These are supply chain attacks and in the case of xz utils, the attacker had gone to extreme lenghts to hide the attack from a well-meaning, good-hearthed but overworked and burnt out solo maintainer.

    To compare this to bugs that people unwittingly introduce in normal human-written code is not sincere.

    • SuspiciousCarrot78@aussie.zoneEnglish
      52·
      2 days ago

      Very well. Here -

      https://www.debian.org/security/2008/dsa-1571

      https://www.finnie.org/2024/05/13/i-discovered-the-debian-openssl-bug/

      That’s the thing about “pure human slop”: it doesn’t need to be malicious to be catastrophic.

      The second link is particularly salient - kills the “supply chain attacks are special” argument because it is precisely about “unwitting bugs in normal human-written code just happen”

      • AVincentInSpace@pawb.socialEnglish
        5·
        2 days ago

        Okay, but they still happen with orders of magnitude less frequency than bugs in AI code. Consider that the time between when rsync first adopted LLM-generated code and users en masse reporting rsync internal protocol errors during a backup was on the order of months.

        • SuspiciousCarrot78@aussie.zoneEnglish
          3·
          2 days ago

          I don’t recall that one…but in fairness…AI generates a metric shit ton more code than humans. We’d have to normalize the results. Interestingly, looking it up now, someone DID normalize for that very case. Bug rate per commit for the AI-assisted versions landed within normal historical range. A pre-AI release had more regressions. The 3.4.3 regressions were primarily from the CVE security patches, not the AI work. Zero CVEs from the Claude-assisted commits.

          EDIT: Correct URL https://alexispurslane.github.io/rsync-analysis/

          • AVincentInSpace@pawb.socialEnglish
            1·
            1 hour ago

            The author of that article admits that the sample size is not large enough to draw meaningful conclusions.

            But besides that, I believe LLM code generators can be a useful tool, provided you are willing to go over their output with a fine-tooth comb and assume it is broken until you have proven otherwise, because the hallucination problem is inherent to the technology and they’re never going to completely solve it, and are willing to overlook the myriad ethical issues with all major LLMs in existence today.