I suppose the problem is that this was evidently brought on by trying to use AI to be proactive about security risks from AI findings. So an abandoned rsync would gather cves.
That said, it looks like he has used Claude to poke at bugs no one noticed, security issue or no. Like a promise about a combination of flags having a certain effect that didn’t happen. So fine, technically you didn’t live up to your man page, but no one complained, so maybe the risk of change isn’t worth the change.
If it’s a security issue, then… ok fine, you have to give it a try, but it looks like stirring things up to try to fix years of maybe not right, which is a risky proposition.
I suppose the problem is that this was evidently brought on by trying to use AI to be proactive about security risks from AI findings. So an abandoned rsync would gather cves.
It would gather CVEs, yes, but at least the codebase would not change so fast that even the maintainer themselves can no longer keep up with understanding all the changes. I’ve looked at a few commits and there’s way too many lines of code for the maintainer to have carefully reviewed and understood them all.
But an abandoned rsync would have two great advantages:
it would give stronger support / user interest to a fork
distros would not face the decision whether or not to upgrade to a version with slop in it
If it’s a security issue, then… ok fine, you have to give it a try, but it looks like stirring things up to try to fix years of maybe not right, which is a risky proposition.
Also - if a tool finds a security risk, then I want a human maintainer to wrap their head around the attack vector to come up with the correct patch to counter the actual attack vector. Slop machines have zero understanding, so if you need to put out a house fire with people in it, a slop machine might as well drain all oxygen from the air. The fire will be gone after that. But so will the people.
…and a lot of the “security issues” being found by LLMs are not viable attack vectors. For example: in the case of rsync they just terminate a connection with no server-side effect.
Of course, there’s that as well. And self-appointed “security researchers” auto-scanning repos and creating tool-submitted issues about “vulnerabilities”, wasting dev time.
“Coding assistants” have to be considered what is the most likely intent: a large-scale attack of megacorporations on the open source community, and the gullible people who use them should be treated as agents of a hostile corporation.
Funny you use that analogy because I once worked in a factory where if a fire didn’t get you, the fire suppression system that was basically just a few tanks of CO2 would when it pushed all the breathable air away. No AI involved at all, just a bunch of people that cared more about the equipment than the people (or were willing to go to any means to keep any fires from spreading to the offices).
No point here really, other than maybe you’re overestimating people with that analogy.
Edit: also, when there’s community pressure to fork a project that already isn’t getting much help, I’d expect the ones who just want an AI to do it would be more likely to step up. Taking over a fork is more work than contributing to one someone else owns, though some might be attracted to that control (which may or may not work out for everyone else).
It’s not like bugs didn’t happen before AI, so to be so confident it’s slop that caused the issue you surely know which commit caused the issue?
I’m incredulous about the direction of AI development tools, but this whole thing is turning into attacks on the guy and acting like bugs didn’t happen before AI.
It looks like one of the issues is around openat2 which has only been around for 6 years or so. Rsync assumes that it’s available and has no fall back. I’m not sure what openat2 is or what was used before or why the change was made. I’m guessing it was an error but as ai was deemed to be involved everyone lost their shit
Enshitification is more about adding shitty anti-features than sucking at maintaining something. A codebase falling apart due to AI contributions should be called something else, like slopification. There might be an older term for codebase losing quality because of incompetent maintainers.
I see a lot of bitching in that thread but no offers to help maintain the project.
Doesn’t excuse slop in the slightest. An unmaintained or abandoned project is infinitely better than updating and corrupting the codebase with slop.
You should complain and get your money back.
I suppose the problem is that this was evidently brought on by trying to use AI to be proactive about security risks from AI findings. So an abandoned rsync would gather cves.
That said, it looks like he has used Claude to poke at bugs no one noticed, security issue or no. Like a promise about a combination of flags having a certain effect that didn’t happen. So fine, technically you didn’t live up to your man page, but no one complained, so maybe the risk of change isn’t worth the change.
If it’s a security issue, then… ok fine, you have to give it a try, but it looks like stirring things up to try to fix years of maybe not right, which is a risky proposition.
It would gather CVEs, yes, but at least the codebase would not change so fast that even the maintainer themselves can no longer keep up with understanding all the changes. I’ve looked at a few commits and there’s way too many lines of code for the maintainer to have carefully reviewed and understood them all.
But an abandoned rsync would have two great advantages:
Also - if a tool finds a security risk, then I want a human maintainer to wrap their head around the attack vector to come up with the correct patch to counter the actual attack vector. Slop machines have zero understanding, so if you need to put out a house fire with people in it, a slop machine might as well drain all oxygen from the air. The fire will be gone after that. But so will the people.
…and a lot of the “security issues” being found by LLMs are not viable attack vectors. For example: in the case of rsync they just terminate a connection with no server-side effect.
Of course, there’s that as well. And self-appointed “security researchers” auto-scanning repos and creating tool-submitted issues about “vulnerabilities”, wasting dev time.
“Coding assistants” have to be considered what is the most likely intent: a large-scale attack of megacorporations on the open source community, and the gullible people who use them should be treated as agents of a hostile corporation.
Funny you use that analogy because I once worked in a factory where if a fire didn’t get you, the fire suppression system that was basically just a few tanks of CO2 would when it pushed all the breathable air away. No AI involved at all, just a bunch of people that cared more about the equipment than the people (or were willing to go to any means to keep any fires from spreading to the offices).
No point here really, other than maybe you’re overestimating people with that analogy.
Edit: also, when there’s community pressure to fork a project that already isn’t getting much help, I’d expect the ones who just want an AI to do it would be more likely to step up. Taking over a fork is more work than contributing to one someone else owns, though some might be attracted to that control (which may or may not work out for everyone else).
Which commit was the slop that caused the issue?
It’s not like bugs didn’t happen before AI, so to be so confident it’s slop that caused the issue you surely know which commit caused the issue?
I’m incredulous about the direction of AI development tools, but this whole thing is turning into attacks on the guy and acting like bugs didn’t happen before AI.
It looks like one of the issues is around openat2 which has only been around for 6 years or so. Rsync assumes that it’s available and has no fall back. I’m not sure what openat2 is or what was used before or why the change was made. I’m guessing it was an error but as ai was deemed to be involved everyone lost their shit
Are you sure you want dumbasses like me to contribute? I thought we hated enshittification? (This goes for AI code too)
Enshitification is more about adding shitty anti-features than sucking at maintaining something. A codebase falling apart due to AI contributions should be called something else, like slopification. There might be an older term for codebase losing quality because of incompetent maintainers.