@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.
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”
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.
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.
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.
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”
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.
I froze my rsync package the day that was announced. fuck the dev :(
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/
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.