@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.
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.
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.
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.
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/