Looks fine? most of the commits are tests, ci, docs and issues that could cause memory corruption / hidden bugs rather than any new feature development. Of course it's unfortunate that it caused this bug to surface and it would be curious to investigate exactly why this happened, maybe the "safe" c operations have different (unexpected) behavior instead of immediately pointing out that "ai bad". I think patching issues that could cause future CVE's is pretty important especially because rsyncing a file -> client compromise could be pretty devestating as it often runs unsandboxed.
Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers.
(edit: if someone hears "you are irresponsible if you don't let claude review your code", it would be pretty natural to let AI review your code and fix issues without knowing the full implications of it)
Yeah this is how software development works now, no matter how much anyone wants to disagree with it. The technology is here, you can't put it back in the box. If your tool has AI agents trying to find exploits 24/7, you'll need something comparable.
It is worth figuring out the new science of software engineering to get it right.
I suspect we are going to find plenty of new techniques that make this sort of development work better. After all, it took fifty years to arrive at our best known (unit test + reviewable tiny change, get an LGTM) model of software development.
no, no, no. if we all stomp our feet and kvetch really loud, a Hawaii judge will declare AI illegal and order a global moratorium. all trillion dollar companies will immediately cease all AI activities, and then UN death squads will go door-to-door confiscating assault GPUs from the chuds.
> Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers.
The main problem with using AI in open source software is that millions of people rely on your code, but you risk exposing them all to something unverified.
You also risk exposing users to any other error you make. That's called a bug.
Unless someone points to vibe coded/hallucinated code causing the breakage or provides clues that might indicate unreviewed slop code being committed and shipped, I'd hold my horses.
Well maybe we shouldn't then? Before LLMs some not just clueless but also malicious rando could've send a PR too. And the maintainers might've gotten burned out any and just said f-it and merged stuff randomly.
I don't see how AI changed the calculation here much.
No reasonable maintainer would recklessly merge something he/she hasn’t reviewed. Well, those who blindly accept whatever AI outputs… perhaps it’s time for them to find another job.
Just because one offers software for free doesn’t mean there shouldn’t be standards.
> Same issue there. A profession is an occupation that you get paid for doing.
Wrong, a profession is an occupation that requires specialized training or qualifications. This means one can have a profession and still not get paid.
> And he mainly seems to be getting abuse in return for that service.
If you want to go down that semantic route, then being an open source maintainer clearly isn't a profession, as it requires neither specialized training nor qualifications!
> If you want to go down that semantic route, then being an open source maintainer clearly isn't a profession, as it requires neither specialized training nor qualifications!
Open source software maintenance without qualifications? I hope you understand how disastrous it would be for serious software like rsync.
I should think most open source software is maintained by people without any special training or qualifications. And would you expect to obtain the services of, say, a highly qualified plumber or electrician for free?
It might be more useful if qualifications were required before people were allowed to complain about open source software on internet message boards. That’ll be the day!
If millions of people are relying on free software, that's their problem, isn't it? The maintainer has zero obligations to them, and they are not entitled to anything. If they want commercial support or SLAs, they could tender an offer, or else they can fork it and maintain it themselves. I think the maintainer here is being a silly goose but it's their right to be as silly as they want in their own repo.
Yes, you risk reputation and still need to be careful. One way to try to mitigate is to write tests. Which is what rsync project is doing, too. But there's only so much you can catch alone.
And BTW, you're not distributing to millions of people as an author of the code.
There are distributions maintainers between you and the world, which can also intervene, and are responsible for what they distribute, build testing on many configurations/architectures/versions - and can decide to revert to protect users, etc. And often do.
FOSS authors themselves can't be expected to keep around outdated systems from 5 years ago just to test build compatibility, in 8 different architectures that someone may want to build their code with.
Very few projects have as comprehensive testsuite as say sqlite. You can never cover everyting, so the beauty of FOSS is that someone will come and tell you and send you a fix for their special system, and now everything is again fine for that one special person, or distro maintainer.
Currently there are 130 Claude-coauthored commits, and the maintainer seems to not be engaging with any of the recent issues and just pushing more of the "security in depth" fixes that are breaking real features for people.
I don't think using AI as such is the core problem here. It's the type of use. Vibe coding, brain off coding and blind trust are the issue, and an issue everywhere, just enterprises were never really about quality in the first place. But eventually, they too will generate more crap than they can handle.
I mean, we have no idea how tridge is using claude. I would easily give him the benefit of the doubt that he's not vibe-coding, is involved in the change (not just turning on auto-accept), and reviews the output before committing.
But it seems like everyone's immediate hot take here and on Mastodon is to assume the worst and shit on him.
To be precise, I meant the open source as a whole, as this is what the parent poster mentioned. I don't know about Tridge, I would review the changes first to see what happened there.
For rsync in general, I would say that the important value is the trust in it not breaking my data, more so than other projects. That trust can be broken in different ways, AI or not, and the means are of a secondary concern. I hope this gets sorted out soon.
Pride in one'one's journey, the feeling of accomplishment for creating/learning/doing something, and the general art within the act...
Yes, it's ironic that the stock photo companies offer on-demand image generation when the private galleries only offer photos which required an adventure and effort.
So, has anyone actually checked if it's just an issue with 3.4.3? Going to back to 3.4.1 skips 3.4.2 which features many contributions that aren't either by Andrew or Claude.
So? May main point is: Which commits actually broke the functionality? Going from 3.4.3 to 3.4.2 to test should be easy for anyone affected and would have been more helpful than this rant.
I'm not defending bad slop commits, especially for such a long running project but the tribal Fediverse outrage whenever LLMs are involved is often just lazy and uninformed.
> NOTE: This also affects backported rsync versions when they're used on the Receiver:
> Debian: 3.4.1+ds1-5+deb13u3 / 3.2.7-1+deb12u5 / 3.2.3-4+deb11u3
> Ubuntu: 3.2.7-1ubuntu1.4
I reckon we will soon see a growing movement of maintainers forking popular open-source projects to the point before vibecoding was introduced to the development process.
I can definitely see myself supporting this. Vibecoding promotes the uncontrollable growth of features, and thus bugs, when the vast majority of software benefits from stability. It should be possible to be done with development, barring security patches and bug fixes.
Counterpoint: AI makes refactoring so much easier. Many of our monolithic code bases have gotten smaller and more organized because we were too lazy to refactor.
So they’re just kind of implying a relationship between the 2 things?
Maybe there is one, but it doesn’t support the underlying “and that must mean AI bad” hypothesis as much as the author may think.
Somebody on the Rsync team has a new tool. They may have neglected their traditional responsibilities using it, but that’s not really a fault of the tool.
I agree that it is not a fault of the tool, but of the human who must have used it improperly.
However, rsync is one of those applications where correctness has an extreme importance. If it fails completely, that is still not so bad, but any kind of subtle corruption in file data or in file metadata can be catastrophic.
I expect from an rsync developer a much higher standard for program correctness verification than for most other computer applications, so these events are very worrisome.
I do not care whether someone uses an AI tool, but I care very much about whether any written code, regardless of its author, is verified very thoroughly, or not.
Maybe he got notified from the mythos team of a bunch of vulnerabilities and then followed up using claude. Doesn't seem that unlikely.
What would you do if suddenly there were a dozen exploitable CVEs in your highly used open source project staring you down? Maybe you'd use the tool that found them to patch them as quickly as possible.
I am absolutely willing to give tridge the benefit of the doubt here, but a note on what you said: I don't think you should ever patch a CVE "as quickly as possible". You should do it slowly, be very sure of the change, and test the hell out of it. You can easily introduce a new security vulnerability by rushing something like that.
Looks like at least one of these issues was from a CVE [0], they don’t call out Mythos specifically though (“security researchers”). Many teams are sprinting on security issues atm (including mine, who put all product priorities aside two sprints ago), it must suck to be responsible for high-visibility/high-risk projects like rsync right now.
This is a problem of insufficient checking happening in-between a PR being made, and it being committed.
Imagine you have a low quality coder in your coders, they produce a lot of code, but while some of it is fine, some of it is... dubious. That is no different from an AI and the way you deal with it is the same. You check the PR before committing it.
To allow PRs from them (or anyone really) to get merged without proper checking for bugs etc is just sloppy repo management. The problem is not "AI bad, human good", it is that a human is allowing PRs through to release without properly checking them.
The difference lies in the field of civic virtue. A human programmer accepts personal responsibility for the safety of the software of which he is a member, defending it, if need be, with his life. The AI does not.
I saw an exceptionally long and thoughtful post on Mastodon from "Space Hobo" https://teh.entar.net/@spacehobo that definitely deserves reprinting here
-----
I actually worked at the same place as Andrew Tridgell, over a quarter-century ago. I got to know a few of the OzLabs folks during their immediate post-IBM years, and always had the highest respect for them in that way where you feel acute impostor syndrome when they're in the room.
Tridge almost walked backwards into implementing the Windows SMB protocol (he was just debugging some funny NetBIOS extensions IIRC). But his paper on the #rsync algorithm was groundbreaking, and actually writing the tool to implement it was brilliant. It's become one of those tools like #curl that just forms one of the major structural supports of the modern Internet. I still remember the day that the SSH transport became the default, and I remember being able to thank him in person when he came to the San Francisco office (although IIRC by that point he'd handed control of rsync over to mbp).
I remember at my next job he came to a summit of folks working on print driver/spooler software. When he pointed out that some problems were effectively a cache-consistency algorithm, we all kind of put our fingers to our temples and said "Oh wow, you're SO right!" He was always insightful and sharp, while being gentle and approachable.
I write in the past tense because I haven't crossed paths with him in two decades, and only know what I see him put out. A friend of mine in Australia noted that he hasn't posted to the Canberra LUG list since 2020, thanking someone for congratulating him on receiving the Medal of the Order of Australia. He's very much alive, but from what little I see I grow concerned for him.
In 2024 he took over maintenance of rsync once more. The 3.3.0 release was the last one from the previous maintainer, and Tridge is currently working on 3.4.x releases.
The issue tracker for rsync has recently lit up with regressions, showing features that worked reliably for almost 30 years are suddenly coming crashing down in 3.4.2 and 3.4.3. People are scrambling to find ways to pin rsync to known-good versions. The considerate, incisive mind I briefly knew is letting the stochastic parrots do his work for him, and it just seems so astonishingly unlike the person I met back in the day.
I am still willing to give him the benefit of the doubt. I hope all is well for him, but I will not cast aspersions on his goals or his abilities. No, instead I draw this conclusion:
If TRIDGE of all people can't handle #LLMs without a slopocalypse, no one can.
That means you. That means someone you admire who is intelligent and careful and considerate. Not even someone whose opinions on technology you respect a great deal.
> If TRIDGE of all people can't handle #LLMs without a slopocalypse, no one can.
> That means you. That means someone you admire who is intelligent and careful and considerate. Not even someone whose opinions on technology you respect a great deal.
I disagree. The amount of commits is not from somebody who is carefully reviewing the new code and considering the changes done. It's from somebody who thinks they are in control and think they can guardrail the AI.
I've seen this at work as well. Maybe it's a small case of the braineater that so many tech bros get when they get older. But they talk about the AI as if it were a being that can be reasoned with and not that it's just a statistical interpolator and autocompleter.
I know when I'm vibe coding. Just last week I needed 5 colors for a green to read gradient for visualisation some states. I ended up with a script that outputs arbitray color gradients in 5 different colorspaces (including a colorspace for which AFAIK there's no support in Ruby as of now) and additionally also considers different color vision deficiencies.
Is it useful? Yes. Would I run this code in production? Hell no.
This is a common fallacy: that vibecoding is not that bad if one carefully reviews the output. It's true in a vacuum, but what happens when you're late and stressed out and can't be bothered with doing a proper job.
Humans are lazy, and the mistakes of being lazy when vibe coding are orders of magnitude larger than being lazy when you have to do the damn thing yourself. In fact in the latter case, laziness is a feature.
If the AI-powered software world depends on humans not being lazy, we're all fucked.
or more generously, replace lazy with tired. even if you have all the intention of reading all the code in detail, when you are tired you are less attentive.
finally, reading code can never achieve the same detailed understanding that you would get from writing it. reading anything in general can't achieve the same understanding as writing. our brain tries to optimize. you see something familiar, you skip over it because you recognize it, and that causes you to miss subtle details.
the one thing i wonder though is, how much would it help if i use AI to generate some code but then, instead of just copying the whole thing, i type it all in by hand. does that give me enough attention to review? does that still give me any benefit of using AI with less downsides?
At what point it’s just easier to do the whole thing yourself, perhaps prompting AI to give you guidelines and which whom to discuss the design, but never using it to code?
But then again, the day one is lazy or tired, one will choose the shortcut of having the machine just write the code.
well yes, that why i concluded that at this point using AI to help me is just not worth it. i'll wait until the reliability goes up and the level of frustration goes down.
for myself i don't even want to use it to learn because i a afraid of being told things that are false or don't exist. i already had that experience, spending hours trying to figure out why my code wasn't working until i realized that the AI told me to use a property or function that didn't exist. i hate wasting time and effort like that.
“letting the stochastic parrots do his work for him” or “overwhelmed with publicly released vulnerabilities and using any tool he can find to stop the bleeding”; same same.
>I write in the past tense because I haven't crossed paths with [Andrew Tridgell] in two decades
But err, don't let that stop you, Space Hobo! I'm not sure how anyone is taking this Mastodon post seriously. The author barely knows Tridgell, but is supposedly 'concerned' because he hasn't posted to his local LUG mailing list for a few years. Isn't this the logic of the terminally online?
I notice that Space Hobo has a lot of posts warning about the dangers of AI slop. Given the rate at which they're able to produce copious quantities of their own artisanal variety, I can't imagine they have much to fear.
I'm thinking this will be a natural progression because part of the "AI slop deluge" are now real bug reports generated by these AIs. I'm glad for this noise around the regression as so many more folks are now aware of this issue.
Well, there's 1 +claude commit prior Mythos/Glasswing announcement and the rest are after the announcement. Take of it what you will.
Anyway, seems blown out of proportion. There are a few issues in the tracker, some repeated or obscure. Linux 5.10, really? You want to run frankenkernel from 5 years ago with 30 000+ patches never meant or developed against it applied on top? Good luck. Rsync is least of your worries.
Linux stable, especially these 5 year old trees are mostly a pacifier for companies that don't want to upstream and maintain their drivers and keep up with evolving internal kernel interface. It's nothing good for users, technically.
And I guess if I clone the repo and do a diff against pre-claude and claude assisted state, most of the changes will not be in the actual C code.
Looks fine? most of the commits are tests, ci, docs and issues that could cause memory corruption / hidden bugs rather than any new feature development. Of course it's unfortunate that it caused this bug to surface and it would be curious to investigate exactly why this happened, maybe the "safe" c operations have different (unexpected) behavior instead of immediately pointing out that "ai bad". I think patching issues that could cause future CVE's is pretty important especially because rsyncing a file -> client compromise could be pretty devestating as it often runs unsandboxed.
Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers. (edit: if someone hears "you are irresponsible if you don't let claude review your code", it would be pretty natural to let AI review your code and fix issues without knowing the full implications of it)
I suspect this commit: https://github.com/RsyncProject/rsync/commit/4fa7156ccdb2ad3..., appears to be changing behavior and changes like these shouldn't be in a patch version (unless it's an active security exploit).
Yeah this is how software development works now, no matter how much anyone wants to disagree with it. The technology is here, you can't put it back in the box. If your tool has AI agents trying to find exploits 24/7, you'll need something comparable.
It is worth figuring out the new science of software engineering to get it right.
I suspect we are going to find plenty of new techniques that make this sort of development work better. After all, it took fifty years to arrive at our best known (unit test + reviewable tiny change, get an LGTM) model of software development.
no, no, no. if we all stomp our feet and kvetch really loud, a Hawaii judge will declare AI illegal and order a global moratorium. all trillion dollar companies will immediately cease all AI activities, and then UN death squads will go door-to-door confiscating assault GPUs from the chuds.
Yeah but what are the downsides?
> Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers.
The main problem with using AI in open source software is that millions of people rely on your code, but you risk exposing them all to something unverified.
You also risk exposing users to any other error you make. That's called a bug.
Unless someone points to vibe coded/hallucinated code causing the breakage or provides clues that might indicate unreviewed slop code being committed and shipped, I'd hold my horses.
Well maybe we shouldn't then? Before LLMs some not just clueless but also malicious rando could've send a PR too. And the maintainers might've gotten burned out any and just said f-it and merged stuff randomly. I don't see how AI changed the calculation here much.
Before, there was a chance to spot it (and things like XZ Utils backdoor were rare), now it will be well hidden in the ocean of slop PRs.
No reasonable maintainer would recklessly merge something he/she hasn’t reviewed. Well, those who blindly accept whatever AI outputs… perhaps it’s time for them to find another job.
Just because one offers software for free doesn’t mean there shouldn’t be standards.
That's an interesting use of the word 'job'. How much is the rsync maintainer paid?
My bad, I meant profession.
Same issue there. A profession is an occupation that you get paid for doing.
AFAIK the rsync maintainer does it for free. And he mainly seems to be getting abuse in return for that service.
> Same issue there. A profession is an occupation that you get paid for doing.
Wrong, a profession is an occupation that requires specialized training or qualifications. This means one can have a profession and still not get paid.
> And he mainly seems to be getting abuse in return for that service.
What abuse you are referring to?
If you want to go down that semantic route, then being an open source maintainer clearly isn't a profession, as it requires neither specialized training nor qualifications!
In terms of abuse, I was thinking of this issue thread: https://github.com/RsyncProject/rsync/issues/929
> If you want to go down that semantic route, then being an open source maintainer clearly isn't a profession, as it requires neither specialized training nor qualifications!
Open source software maintenance without qualifications? I hope you understand how disastrous it would be for serious software like rsync.
I should think most open source software is maintained by people without any special training or qualifications. And would you expect to obtain the services of, say, a highly qualified plumber or electrician for free?
It might be more useful if qualifications were required before people were allowed to complain about open source software on internet message boards. That’ll be the day!
If millions of people are relying on free software, that's their problem, isn't it? The maintainer has zero obligations to them, and they are not entitled to anything. If they want commercial support or SLAs, they could tender an offer, or else they can fork it and maintain it themselves. I think the maintainer here is being a silly goose but it's their right to be as silly as they want in their own repo.
Yes, you risk reputation and still need to be careful. One way to try to mitigate is to write tests. Which is what rsync project is doing, too. But there's only so much you can catch alone.
And BTW, you're not distributing to millions of people as an author of the code.
There are distributions maintainers between you and the world, which can also intervene, and are responsible for what they distribute, build testing on many configurations/architectures/versions - and can decide to revert to protect users, etc. And often do.
FOSS authors themselves can't be expected to keep around outdated systems from 5 years ago just to test build compatibility, in 8 different architectures that someone may want to build their code with.
Very few projects have as comprehensive testsuite as say sqlite. You can never cover everyting, so the beauty of FOSS is that someone will come and tell you and send you a fix for their special system, and now everything is again fine for that one special person, or distro maintainer.
Currently there are 130 Claude-coauthored commits, and the maintainer seems to not be engaging with any of the recent issues and just pushing more of the "security in depth" fixes that are breaking real features for people.
Citation needed :) That's a bold claim. May be true, but it's a bold one, so something backing it up would be nice.
Could one not simply look at the github to verify it with their own eyes? One of git's defining features is every commit being accountable
Yes the person making the accusation could do that
Go look for yourself, quite a few mention CVEs.
EDIT: posted on top, see https://news.ycombinator.com/item?id=48334270
Reposting some of the (likely) bad commits with issues open against them, just to show that this isn't a one-off:
- https://github.com/RsyncProject/rsync/commit/4fa7156ccdb2ad3...: https://github.com/RsyncProject/rsync/issues/905 https://github.com/RsyncProject/rsync/issues/900
- https://github.com/RsyncProject/rsync/commit/1d5b5ab83af84db...: https://github.com/RsyncProject/rsync/issues/924
- https://github.com/RsyncProject/rsync/commit/859d44fa4f14207...: https://github.com/RsyncProject/rsync/issues/897
- https://github.com/RsyncProject/rsync/commit/30656c5e358b1c6...: https://github.com/RsyncProject/rsync/issues/896 https://github.com/RsyncProject/rsync/issues/915
- https://github.com/RsyncProject/rsync/commit/8112445318a35e4...: https://github.com/RsyncProject/rsync/issues/910 https://github.com/RsyncProject/rsync/issues/927
The first actually constructive attempt of figuring out the root cause can be found in this issue: https://github.com/RsyncProject/rsync/issues/897
Maybe time to pursue alternative implementations[1].
[1]: https://michael.stapelberg.ch/posts/2026-05-24-minimal-memor...
It's rather ironic that in profit making enterprises using AI are not only encouraged but also part of KPIs. But in open source it's scourge
Why ironic? It seems to me no different than s/AI/dark patterns/
I don't think using AI as such is the core problem here. It's the type of use. Vibe coding, brain off coding and blind trust are the issue, and an issue everywhere, just enterprises were never really about quality in the first place. But eventually, they too will generate more crap than they can handle.
I mean, we have no idea how tridge is using claude. I would easily give him the benefit of the doubt that he's not vibe-coding, is involved in the change (not just turning on auto-accept), and reviews the output before committing.
But it seems like everyone's immediate hot take here and on Mastodon is to assume the worst and shit on him.
To be precise, I meant the open source as a whole, as this is what the parent poster mentioned. I don't know about Tridge, I would review the changes first to see what happened there.
For rsync in general, I would say that the important value is the trust in it not breaking my data, more so than other projects. That trust can be broken in different ways, AI or not, and the means are of a secondary concern. I hope this gets sorted out soon.
Pride in one'one's journey, the feeling of accomplishment for creating/learning/doing something, and the general art within the act...
Yes, it's ironic that the stock photo companies offer on-demand image generation when the private galleries only offer photos which required an adventure and effort.
Well it is a scourge in both.
How is that ironic? It’s literally two sides of the same coin.
So, has anyone actually checked if it's just an issue with 3.4.3? Going to back to 3.4.1 skips 3.4.2 which features many contributions that aren't either by Andrew or Claude.
They have not
Seems like 3.4.2 was already vibe-maintained: https://github.com/RsyncProject/rsync/commits/v3.4.2
So? May main point is: Which commits actually broke the functionality? Going from 3.4.3 to 3.4.2 to test should be easy for anyone affected and would have been more helpful than this rant.
I'm not defending bad slop commits, especially for such a long running project but the tribal Fediverse outrage whenever LLMs are involved is often just lazy and uninformed.
To quote this PR: https://github.com/RsyncProject/rsync/issues/928
> NOTE: This also affects backported rsync versions when they're used on the Receiver: > Debian: 3.4.1+ds1-5+deb13u3 / 3.2.7-1+deb12u5 / 3.2.3-4+deb11u3 > Ubuntu: 3.2.7-1ubuntu1.4
Figuring out which commit broke what functionality is not something you can expect users to do.
If you're willing to build from source it's not particularly difficult with git bisect
No, but that's probably a required skill to have before you initiate claims as to what the cause of the loss of functionality was.
It's pretty shitty to accuse someone of vibe-coding without having any idea what their LLM-assisted development process is. Let's do better, please.
I reckon we will soon see a growing movement of maintainers forking popular open-source projects to the point before vibecoding was introduced to the development process.
I can definitely see myself supporting this. Vibecoding promotes the uncontrollable growth of features, and thus bugs, when the vast majority of software benefits from stability. It should be possible to be done with development, barring security patches and bug fixes.
Counterpoint: AI makes refactoring so much easier. Many of our monolithic code bases have gotten smaller and more organized because we were too lazy to refactor.
So they’re just kind of implying a relationship between the 2 things?
Maybe there is one, but it doesn’t support the underlying “and that must mean AI bad” hypothesis as much as the author may think.
Somebody on the Rsync team has a new tool. They may have neglected their traditional responsibilities using it, but that’s not really a fault of the tool.
My guess is just open source maintainers trying out new genAI tools out of curiosity. Unintentional slopification
> Maybe there is one, but it doesn’t support the underlying “and that must mean AI bad” hypothesis as much as the author may think.
It's a tweet. Do you expect thorough null-hypothesis validation from a tweet?
I agree that it is not a fault of the tool, but of the human who must have used it improperly.
However, rsync is one of those applications where correctness has an extreme importance. If it fails completely, that is still not so bad, but any kind of subtle corruption in file data or in file metadata can be catastrophic.
I expect from an rsync developer a much higher standard for program correctness verification than for most other computer applications, so these events are very worrisome.
I do not care whether someone uses an AI tool, but I care very much about whether any written code, regardless of its author, is verified very thoroughly, or not.
I see that people are recommending rclone instead
Their loss
Maybe he got notified from the mythos team of a bunch of vulnerabilities and then followed up using claude. Doesn't seem that unlikely.
What would you do if suddenly there were a dozen exploitable CVEs in your highly used open source project staring you down? Maybe you'd use the tool that found them to patch them as quickly as possible.
I am absolutely willing to give tridge the benefit of the doubt here, but a note on what you said: I don't think you should ever patch a CVE "as quickly as possible". You should do it slowly, be very sure of the change, and test the hell out of it. You can easily introduce a new security vulnerability by rushing something like that.
Good point. I just can't imagine the urgency and pressure I'd feel.
Looks like at least one of these issues was from a CVE [0], they don’t call out Mythos specifically though (“security researchers”). Many teams are sprinting on security issues atm (including mine, who put all product priorities aside two sprints ago), it must suck to be responsible for high-visibility/high-risk projects like rsync right now.
0: https://github.com/advisories/GHSA-pfv9-gp3h-73xv
I suspect that many of the new cute CLI tools that people are vibecoding will turn into malware given some time.
Seeing this happening in trusted CLI tools makes me wonder what will happen to Linux
This is a problem of insufficient checking happening in-between a PR being made, and it being committed.
Imagine you have a low quality coder in your coders, they produce a lot of code, but while some of it is fine, some of it is... dubious. That is no different from an AI and the way you deal with it is the same. You check the PR before committing it.
To allow PRs from them (or anyone really) to get merged without proper checking for bugs etc is just sloppy repo management. The problem is not "AI bad, human good", it is that a human is allowing PRs through to release without properly checking them.
The commits were all from the original inventor of rsync.
Not a low quality newbie coder.
"To allow PRs from them (or anyone really) to get merged without proper checking for bugs etc is just sloppy repo management."
I stand by my post.
Your post makes no sense unless you speak about project management in general.
The commits in question are no pull requests.
What's the difference between experience a human made bug versus an AI made bug in software?
A human preserves more context and might remember what they did and when pointing out a new bug, they often have an idea what's wrong.
A human also learns from their mistakes and grows their skillset.
I cringe any time I read loaded questions like GP's. Have they ever met a human in their life?
The difference lies in the field of civic virtue. A human programmer accepts personal responsibility for the safety of the software of which he is a member, defending it, if need be, with his life. The AI does not.
You must be trolling. Most open source software is released under MIT license which explicitly says the author isn't liable for anything.
Who cares? Is the quality good? Bug free? Readable? If so, I couldn't care less who developed the code.
I saw an exceptionally long and thoughtful post on Mastodon from "Space Hobo" https://teh.entar.net/@spacehobo that definitely deserves reprinting here
-----
I actually worked at the same place as Andrew Tridgell, over a quarter-century ago. I got to know a few of the OzLabs folks during their immediate post-IBM years, and always had the highest respect for them in that way where you feel acute impostor syndrome when they're in the room.
Tridge almost walked backwards into implementing the Windows SMB protocol (he was just debugging some funny NetBIOS extensions IIRC). But his paper on the #rsync algorithm was groundbreaking, and actually writing the tool to implement it was brilliant. It's become one of those tools like #curl that just forms one of the major structural supports of the modern Internet. I still remember the day that the SSH transport became the default, and I remember being able to thank him in person when he came to the San Francisco office (although IIRC by that point he'd handed control of rsync over to mbp).
I remember at my next job he came to a summit of folks working on print driver/spooler software. When he pointed out that some problems were effectively a cache-consistency algorithm, we all kind of put our fingers to our temples and said "Oh wow, you're SO right!" He was always insightful and sharp, while being gentle and approachable.
I write in the past tense because I haven't crossed paths with him in two decades, and only know what I see him put out. A friend of mine in Australia noted that he hasn't posted to the Canberra LUG list since 2020, thanking someone for congratulating him on receiving the Medal of the Order of Australia. He's very much alive, but from what little I see I grow concerned for him.
In 2024 he took over maintenance of rsync once more. The 3.3.0 release was the last one from the previous maintainer, and Tridge is currently working on 3.4.x releases.
Well... Tridge and #Claude, it seems: https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
The issue tracker for rsync has recently lit up with regressions, showing features that worked reliably for almost 30 years are suddenly coming crashing down in 3.4.2 and 3.4.3. People are scrambling to find ways to pin rsync to known-good versions. The considerate, incisive mind I briefly knew is letting the stochastic parrots do his work for him, and it just seems so astonishingly unlike the person I met back in the day.
I am still willing to give him the benefit of the doubt. I hope all is well for him, but I will not cast aspersions on his goals or his abilities. No, instead I draw this conclusion:
If TRIDGE of all people can't handle #LLMs without a slopocalypse, no one can.
That means you. That means someone you admire who is intelligent and careful and considerate. Not even someone whose opinions on technology you respect a great deal.
-----
> If TRIDGE of all people can't handle #LLMs without a slopocalypse, no one can.
> That means you. That means someone you admire who is intelligent and careful and considerate. Not even someone whose opinions on technology you respect a great deal.
I disagree. The amount of commits is not from somebody who is carefully reviewing the new code and considering the changes done. It's from somebody who thinks they are in control and think they can guardrail the AI.
I've seen this at work as well. Maybe it's a small case of the braineater that so many tech bros get when they get older. But they talk about the AI as if it were a being that can be reasoned with and not that it's just a statistical interpolator and autocompleter.
I know when I'm vibe coding. Just last week I needed 5 colors for a green to read gradient for visualisation some states. I ended up with a script that outputs arbitray color gradients in 5 different colorspaces (including a colorspace for which AFAIK there's no support in Ruby as of now) and additionally also considers different color vision deficiencies.
Is it useful? Yes. Would I run this code in production? Hell no.
This is a common fallacy: that vibecoding is not that bad if one carefully reviews the output. It's true in a vacuum, but what happens when you're late and stressed out and can't be bothered with doing a proper job.
Humans are lazy, and the mistakes of being lazy when vibe coding are orders of magnitude larger than being lazy when you have to do the damn thing yourself. In fact in the latter case, laziness is a feature.
If the AI-powered software world depends on humans not being lazy, we're all fucked.
or more generously, replace lazy with tired. even if you have all the intention of reading all the code in detail, when you are tired you are less attentive.
finally, reading code can never achieve the same detailed understanding that you would get from writing it. reading anything in general can't achieve the same understanding as writing. our brain tries to optimize. you see something familiar, you skip over it because you recognize it, and that causes you to miss subtle details.
the one thing i wonder though is, how much would it help if i use AI to generate some code but then, instead of just copying the whole thing, i type it all in by hand. does that give me enough attention to review? does that still give me any benefit of using AI with less downsides?
At what point it’s just easier to do the whole thing yourself, perhaps prompting AI to give you guidelines and which whom to discuss the design, but never using it to code?
But then again, the day one is lazy or tired, one will choose the shortcut of having the machine just write the code.
well yes, that why i concluded that at this point using AI to help me is just not worth it. i'll wait until the reliability goes up and the level of frustration goes down.
for myself i don't even want to use it to learn because i a afraid of being told things that are false or don't exist. i already had that experience, spending hours trying to figure out why my code wasn't working until i realized that the AI told me to use a property or function that didn't exist. i hate wasting time and effort like that.
“letting the stochastic parrots do his work for him” or “overwhelmed with publicly released vulnerabilities and using any tool he can find to stop the bleeding”; same same.
>I write in the past tense because I haven't crossed paths with [Andrew Tridgell] in two decades
But err, don't let that stop you, Space Hobo! I'm not sure how anyone is taking this Mastodon post seriously. The author barely knows Tridgell, but is supposedly 'concerned' because he hasn't posted to his local LUG mailing list for a few years. Isn't this the logic of the terminally online?
I notice that Space Hobo has a lot of posts warning about the dangers of AI slop. Given the rate at which they're able to produce copious quantities of their own artisanal variety, I can't imagine they have much to fear.
Meh, I wonder how many Claude commits iOS, MacOS, or Windows has that we just don't see?
Oh, no :-(
I was hoping that at least some solid bedrock of stadalone command-line tools would withstand the deluge of AI slop.
Will we need to start to label programs with a "written by humans" sticker? :-(
I'm thinking this will be a natural progression because part of the "AI slop deluge" are now real bug reports generated by these AIs. I'm glad for this noise around the regression as so many more folks are now aware of this issue.
Well, there's 1 +claude commit prior Mythos/Glasswing announcement and the rest are after the announcement. Take of it what you will.
Anyway, seems blown out of proportion. There are a few issues in the tracker, some repeated or obscure. Linux 5.10, really? You want to run frankenkernel from 5 years ago with 30 000+ patches never meant or developed against it applied on top? Good luck. Rsync is least of your worries.
Linux stable, especially these 5 year old trees are mostly a pacifier for companies that don't want to upstream and maintain their drivers and keep up with evolving internal kernel interface. It's nothing good for users, technically.
And I guess if I clone the repo and do a diff against pre-claude and claude assisted state, most of the changes will not be in the actual C code.
LGTM, ship it.
/s
Is there any sign of enough code review this release got?