[30.05.202610:05] andrewtridgell
I reviewed it. The rsync project has been essentially a single developer project for about 20 years now
[30.05.202610:06] andrewtridgell
Wayne did it all himself for a long time, now I'm back doing it
[30.05.202610:06] realketas
why is it one man job, it seems like too complex for that
[30.05.202610:06] realketas
i can't even imagine
[30.05.202610:06] andrewtridgell
nobody else volunteers. Its the same story with thousands of open source tools
[30.05.202610:07] realketas
it runs entire planet, just one man does it eh
[30.05.202610:07] realketas
sad too
[30.05.202610:07] andrewtridgell
the linux kernel has thousands of paid full time devs. rsync has zero.
[30.05.202610:15] andrewtridgell
the most insane part is that security releases can't be community tested. Those security releases are going to be a huge part of lots and lots of open source projects for a while to come yet, just look at the rate of CVEs over the last couple of months, its gone nuts. You can't do a beta release of a security fix as its embargoed. So for the most critical fixes you *can't* have anyone else look at it. The people reporting the flaws mostly don't have the skills as they used AI to find the bugs. So the maintainer is the sole person to review the most critical security changes, and that is how the madhouse called the internet and IT security is designed. The only defence I have is to build the most comprehensive and accurate test suite I can, so when I need to deal with yet another security report I can at least quickly identify what else the fix breaks. Luckily I can do that work (the dev of the test suite) in public.
[30.05.202610:22] andrewtridgell
bottom line isif you want to be useful then pick holes in the test suite, find things it doesn't cover, find interactions between options it doesn't pin down, report those and offer fixes for that.
Basically, it’s a solo dev being swamped by LLM security reports, and since those are embargoed only maintainers can review them… and since nobody else has volunteered, he has to do it himself.
He primarily used several AIs to rewrite the test suite from shell (slow, lacking coverage) to python (parallelised, improved coverage). He says he’s extensively reviewed everything, but I guess the suite doesn’t cover everything. And the test suite changes can be community reviewed.
The dev has been actively inviting people to join as a maintainer and poke holes in the test suite, but it seems nobody has stepped up. I can’t really blame the dev here, he just seems unable to keep up without others helping him out. He’s tried to use AIs as sensibly as he could, and I’m not entirely sure if it’s slop fixes that cause the issues (or if an “unassisted” fix would have caught it).
A very important question is being hypothesized here and I hope we all come to a conclusion sooner rather than later.
Is it better for a FOSS project to be abandoned because a single maintainer is overwhelmed? OR Should a single maintainer use LLM tools to continue a project they no longer are able to handle?
I personally see abandoned projects easier to pick up when left “as is” for someone to eventually come in. Doing massive amounts of ai code that eventually breaks the functionality (or presumably does), and then expecting people to come in to a larger shit storm seems daunting.
Fact is there’s a bunch of 50+ engineers that have been looking after these fundamental components for a long time, and people aren’t coming through to hand things off too. It won’t be long before they’ll have come to the end of their working lives and things will be abandoned.
I would prefer they walked away rather than resort to LLM agentic coding.
I don’t want to put my trans ass out there to get brigaded by assholes so open source is not my thing. Massive respect to the people who put up with fossbros.
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.
This is a duplicate thread but sure, imma just copy paste from my previous comment.
Here’s the Discord dump for those who don’t want to join (Tor not allowed, sorry I don’t have a better file host, AI brought down 0x0.st). No further commentary.
[30.05.2026 10:05] andrewtridgell I reviewed it. The rsync project has been essentially a single developer project for about 20 years now [30.05.2026 10:06] andrewtridgell Wayne did it all himself for a long time, now I'm back doing it [30.05.2026 10:06] realketas why is it one man job, it seems like too complex for that [30.05.2026 10:06] realketas i can't even imagine [30.05.2026 10:06] andrewtridgell nobody else volunteers. Its the same story with thousands of open source tools [30.05.2026 10:07] realketas it runs entire planet, just one man does it eh [30.05.2026 10:07] realketas sad too [30.05.2026 10:07] andrewtridgell the linux kernel has thousands of paid full time devs. rsync has zero. [30.05.2026 10:15] andrewtridgell the most insane part is that security releases can't be community tested. Those security releases are going to be a huge part of lots and lots of open source projects for a while to come yet, just look at the rate of CVEs over the last couple of months, its gone nuts. You can't do a beta release of a security fix as its embargoed. So for the most critical fixes you *can't* have anyone else look at it. The people reporting the flaws mostly don't have the skills as they used AI to find the bugs. So the maintainer is the sole person to review the most critical security changes, and that is how the madhouse called the internet and IT security is designed. The only defence I have is to build the most comprehensive and accurate test suite I can, so when I need to deal with yet another security report I can at least quickly identify what else the fix breaks. Luckily I can do that work (the dev of the test suite) in public. [30.05.2026 10:22] andrewtridgell bottom line is if you want to be useful then pick holes in the test suite, find things it doesn't cover, find interactions between options it doesn't pin down, report those and offer fixes for that.Basically, it’s a solo dev being swamped by LLM security reports, and since those are embargoed only maintainers can review them… and since nobody else has volunteered, he has to do it himself.
He primarily used several AIs to rewrite the test suite from shell (slow, lacking coverage) to python (parallelised, improved coverage). He says he’s extensively reviewed everything, but I guess the suite doesn’t cover everything. And the test suite changes can be community reviewed.
The dev has been actively inviting people to join as a maintainer and poke holes in the test suite, but it seems nobody has stepped up. I can’t really blame the dev here, he just seems unable to keep up without others helping him out. He’s tried to use AIs as sensibly as he could, and I’m not entirely sure if it’s slop fixes that cause the issues (or if an “unassisted” fix would have caught it).
A very important question is being hypothesized here and I hope we all come to a conclusion sooner rather than later.
Is it better for a FOSS project to be abandoned because a single maintainer is overwhelmed? OR Should a single maintainer use LLM tools to continue a project they no longer are able to handle?
I personally see abandoned projects easier to pick up when left “as is” for someone to eventually come in. Doing massive amounts of ai code that eventually breaks the functionality (or presumably does), and then expecting people to come in to a larger shit storm seems daunting.
Fact is there’s a bunch of 50+ engineers that have been looking after these fundamental components for a long time, and people aren’t coming through to hand things off too. It won’t be long before they’ll have come to the end of their working lives and things will be abandoned.
I would prefer they walked away rather than resort to LLM agentic coding.
I don’t want to put my trans ass out there to get brigaded by assholes so open source is not my thing. Massive respect to the people who put up with fossbros.
I’d have thought it would be an area where you could be viewed by the quality of what you do, and not anything else.
I might be being naive.
Yeah, sadly.
If you want to pick up this project you can take the last pre-llm version.
Or go work with the dev who is actively begging for volunteers instead of trying to make a whole new project.
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.