- cross-posted to:
- programming@beehaw.org
- programming@lemmy.ml
- cross-posted to:
- programming@beehaw.org
- programming@lemmy.ml
Seems like he’s been pushed into using LLMs as a way to cope with the deluge of LLM-generated security reports.
You must log in or # to comment.
Repost of my reply elsewhere:
This guy is already retired, he wants to spend his days sailing and here we are bitching about rsync not being good enough while we all use if for free
Most of us won’t be able to help code, fine.
But most of us could help with translations
Many of us could help with documentation
Some of us could contribute regularly with small financial donations
Some of us might have enough knowledge and expertise and experience to help code
Others could come up with other tasks that could be done.
The point is: rsync need more resources. Either we get him more resources or we STFU about the retired dev using AI. We can’t have it both ways.
I think it’s unreasonable to complain that the guy is not working enough for free.
I think it’s reasonable to alert people that rsync is not being properly maintained anymore and to seek alternatives.
I would prefer the maintainer to announce publicly that he can’t maintain the project anymore and is looking for help/someone to take over instead of breaking the project silently.
But where will the maintainers for these alternatives come from, when barely anybody has stepped up in the 30 years of rsync’s existence? Your comment implies that tridge didn’t call for help before, which is far from the truth.
This is thankless maintenance on critical software, not some *-arr toy project for hobbyist self-hosters.
But where will the maintainers for these alternatives come from, when barely anybody has stepped up in the 30 years of rsync’s existence?
Universal Healthcare would increase the pool of willing developers by an order of magnitude here.
No disagreement here but I’m not sure that’s on the menu right now
Either Universal Healthcare is on the menu or society falls apart, pick one.
Oh man I’m like super agreeing with you. Also I’m in a place that actually has universal healthcare, so it’s not like it’s unworkable
Universal Healthcare would increase the pool of willing developers by an order of magnitude here.
I’m not so sure. The problem is not a lack of developers. The problem is a lack of developers interested in working on rsync, or on any other specific project you can name. Most developers would rather work on their own projects.
I would also question whether or not universal healthcare (though unquestionably a good thing) would actually result in such an increase in available developers. The following study looked at the geographical distribution of OSS developers in 2021, via Github contributions, and found that the US had a similar number of OSS developers per capita compared to similar countries that do have universal healthcare (see table 2):
https://www.sciencedirect.com/science/article/pii/S0040162522000105
Github and the whole culture that it came out of it used to (it feels sooooo good to say that in the past tense) be globally hinged on Silicon Valley, why would you not expect to see a anomalously high number of US developers on it?
That’s definitely a possibility, along with the possibility that countries with worse English language skills might be underrepresented on GitHub, despite having universal healthcare. Conversely, if the US is over-represented on GitHub, then the pool of US developers who are not already active on GitHub may also be depleted compared to other countries. However, that is not something we can read out of the available evidence.
The most we can conclude is probably that the US getting universal healthcare might result in an increase in available OSS developers, depending on which assumptions turn out to be correct, but suggesting that it would lead to an order of magnitude increase is surely premature
suggesting that it would lead to an order of magnitude increase is surely premature
The US is continuing to worsen in performance on meaures of small business entrepreneurship in essentially all industries in the US, software and software adjacent industries are no different especially if you don’t get distracted by the AI bubble inflating that value of a bunch of illusions claiming to be businesses.
It is easy to see how the inability of the average person to try a new idea, or risk taking on a project that may not pay off immediately translates directly to a lack of available developers for open source software projects.
The impact of Universal Healthcare would be huge for open source development in the US, the amount of programmers that would be pushed over the line from “just making ends meet while having a work life balance” to “ok maybe I could devote some time to open source development”.
Don’t get me wrong though, I think we need to normalize straight up paying developers for Open Source Development. Just because it is open source doesn’t mean it doesn’t take labor, that is not the argument I am making.
https://github.com/rclone/rclone
https://github.com/restic/restic
https://github.com/bcpierce00/unison
The thing with old, critical software is that after some time people don’t really want to dig through decades of C code and prefer to write something new using modern tools. Those projects get plenty of support because people actually do want to work on them. If no one wants to work on rsync than what the maintainer is doing now is just prolong it’s agony a couple of years. I would say he should do the minimum work, announce end of life date and move on. People that need tools like rsync will develop something.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Here are the percent of commits from the top committer in each repository you mentioned, as well as rsync, over the last 3 months:
- rsync: 99.0%
- restic: 93.2%
- rclone: 87.5%
- union: 82.9%
- syncthing: 74.4%
As you can see, each of this projects depends heavily on a single person, though to a lesser degree than rsync. That’s just the nature of most open-source software.
Note that I excluded dependabot commits from the calculations and counted Claude commits as the lead developer for rsync
How I imagine this:
- rsync gets end of life date
- People that rely on rsync start looking for alternatives
- They try to switch and figure out what functionality is missing
- They contribute to some of the alternative to fill the gaps
For example, I’m about to setup some syncing for my homelab and I will not use rsync for that. That’s why talking about the state of rsync is important. As I said, it’s not about attacking the dev for not working hard enough. It’s about long term planning.
I remember when the maintainer for discord.py stepped down. He eventually stepped back in because no one wanted took over the project and he didn’t want to see it die. This was before the current AI era, all someone had to do was continue to develop it.
I think almost everyone will do step 2 and 3 but not step 4.
The fact that open source exist and functions so well for decades shows that people do step 4. If no one wants to step in it usually means the project is not important.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
I’m sorry to say 90% of the internet’s load bearing infrastructure is in this situation. It’s just how the story goes, everybody wants to build low-stakes toy projects, nobody wants to do high-effort low-reward infrastructure work.
“Writing something new using modern tools” is all fun and sparkles, but then you run into the same issues as rsync except without the experience. Then you get attention from attackers, you get security issues, which you have to patch with defensive code which is not appealing to read and zero fun to write. Before you know it your project is “decades of Rust/Zig/Lisp” which nobody wants to touch and you’re back at square one. All you’ve accomplished is give the attackers a few years of low hanging fruit and easy exploits.
There’s a reason why we get a million shiny toys a year but solutions like rsync stay entrenched for decades.
The trouble with some of those projects (e.g. unison and sun thing) is that they don’t solve the same problem, not really.
A rewrite with modern tooling would be better done if it was incremental.
Is that your assumption given that they’re using AI? Because it’s not at all what I have taken away from their article.
Is “not properly maintained anymore” your interpretation of them using AI? Or what do you base that on?
The whole story started because rsync stopped working for some users. That’s “not properly maintained” in my books.
I don’t know the degree to that, but bugs do happen occasionally either way as long as there are changes. In the article, they explain why the changes are necessary. Prioritizing security over no-change-stability seems reasonable and warranted.
The author said:
yes, there were regressions in some use cases of rsync in the 3.4.3 release. I quite deliberately tried to err on the side of fixing security issues for that release, and there were some valid (but unusual) use cases that got caught up in the changes.
So as I said, I don’t think it’s fair to scream at him to work harder. I do think it’s fair to worn people that rsync is having issues with stability. The author claims he knows what he’s doing and it’s all on purpose. You are free to trust him and ignore the whole affair. Other people may prefer to look for alternatives.
He’s been asking for help but nobody took him up on it.
This whole debacle is making me extremely black pilled about open software in general. Just like cheap computing has died in recent years, I suspect non corporate free software is about to meet the same end to the acclaim of people who think they’re doing a good thing for the world.
Do you mind describing what black pill means in this context? I’m familiar with the red/blue pill references, but could only find the incel context of black pill online. Is it just a “harsh truth” kinda thing?
Sorry for bringing terminally online slang to the table haha
In my head yeah it’s the pill that teaches you a bleak and depressing truth but shows you no way out of it. I may be misusing the term.
You most certainly are, use a different metaphor/descriptor.
I most certainly won’t lol
Ok then, you are labelling yourself as a pathetic loser.
Black pill ideology is most deeply rooted in misogynistic online communities heavily populated by incels, or involuntarily celibate men.
https://www.britannica.com/topic/What-does-black-pill-refer-to
Lol
This article is pretty shoddy. It acknowledges that “red/blue pill” comes from the Matrix but then acts like incels were the only ones using it and pushing its evolution as a suffix. When in reality it developed across the whole internet, not just within incel communities. Oldass encyclopedia being out of touch.
“Blackpilled” specifically basically just means pessimistic, doomer, etc. I see it used in this context on a regular basis with no association to incel, rightwing, or misogynist ideologies.
It certainly has its own unique meaning within those communities, but it’s very clear that’s not how OP was using it. To argue they were misusing the term you’d have to prove that most people here associate “x-pill” terminology with incels, rather than directly with The Matrix and/or how the terminology is commonly used on social media by regular people.
ain’t that a spicy squirrel…
He’s using it correctly
You gotta get up on ai start using it yourself, good or bad it is what it is and people will be left behind.
I think you misread my comment. I’m depressed that people are harassing open source devs, not that open source devs use LLMs.
I don’t give a shit whether a maintainer like Tridge uses AI, because i trust them to review the AI’s code like they’ve reviewed human contributions since forever.
I doubly agree to this. The moment you are deciding the license of your fucking software please think carefully. It is a public service and the dev(s) ow you nothing. Not even an apology. What you own to the devs is much greater and very high on value. They made the software that runs on your own paid electricity, that you granted to them.
Either we get him more resources or we STFU about the retired dev using AI. We can’t have it both ways.
Of course we can do both. I don’t have those resources to grant
and I get to point out that Tridge, despite his well earned reputation from the huge contribution of creating rsync and bringing it to the point where it’s effectively complete as an essential piece of internet infrastructure, was massively arrogant in abdicating his responsibility by shovelling LLM slop into that same piece of infrastructure.
In your eyes, is all AI-produced text and code slop? Or did you check on the Python tests they designed and implemented with the help of AI, and after analysis of that, you came to the conclusion that it’s slop (as in nonsensical, incoherent, faulty, or similar)?
I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:
So, look. One shot rewriting the whole test suite in another language is probably not great to do, but what happened here is so much worse than you are expecting. https://github.com/RsyncProject/rsync/pull/903/
This does not “translate tests into pytest” or a unit testing framework, it writes its own testing framework where tests are whole python scripts that redefine basic test functions in every script. Surely there would be a single way to “run rsync and get the results” - nope, well, there is, but then every test file will randomly redefine its own _run_and_capture function. So like now rsync needs a test suite for its test suite.
If instead of telling an LLM to “rewrite the tests in python” you just searched “python testing” you would find the pytest docs. And then you would find examples. And then you could write fixtures to deduplicate all the prior shell script setup and teardown stuff, and so on. But since it was just “rewrite the tests in python” its now worse than before, and the odds of the rewrite actually being a 100% faithful translation are close to 0.https://neuromatch.social/@jonny/116666900898570791
Yes right - and after reading about a dozen of the test scripts I can definitely see why using pytest would be useful here to consolidate some of the behavior that was repetitive and ad-hoc in the original testing scripts. Like the tests need to do repetitive things like set up test directories with different names and structures, run and capture results, setup and teardown a server, parameterize over a range of values. Done right, a pytest suite would have made perfect sense and improved both the existing tests by making them more systematic and uniform, but also made it easier to add new tests over time. However that is not what happened, and what did happen is much worse because it did the opposite of almost all those desirable qualities.
https://neuromatch.social/@jonny/116671260017373441
You should read the whole thread, the author goes into more detail, as to why you cannot trust the software any more after the rewrite of the unittests and why you should avoid any new release of rsync since then.
One shot rewriting the whole test suite
tridge’s blog post makes it clear that this was not “one-shotted” at all.
You should read the whole thread
I regret reading it; I’ll assume in good faith that it wasn’t LLM generated but it is ironically as confidently wrong as if it were.
It almost (and should have) lost me when it started by quote-agreeing with someone else saying “rsync was basically done until the maintainer discovered vibecoding” - no, pay attention, it was not “basically done”, there were/are a mountain of CVEs!
But then this got my interest:
This does not “translate tests into pytest” or a unit testing framework, it writes its own testing framework where tests are whole python scripts that redefine basic test functions in every script. Surely there would be a single way to “run rsync and get the results” - nope, well, there is, but then every test file will randomly redefine its own _run_and_capture function.
tridge says he has used pytest on other projects and had good reasons not to use it here; I’m inclined to believe him.
But the notion of every test defining its own way to invoke rsync sounded like a valid criticism, and an easy one to verify, so I checked: It turns out that there is in fact a common
run_rsyncfunction which is used by the majority of the tests. One test defines its own_run_and_capturefunction (which differs in that it writes the output to a file, for reasons I didn’t investigate), and it looks like a few others invoke rsync other ways, but the majority of them use the common function.So, that rambling thread’s sole concrete criticism of rsync’s new python tests turns out to be false.
I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:
They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.
The author also greatly exaggerates the amount of code duplication: They claim that “tests are whole python scripts that redefine basic test functions in every script”, but in reality it is less than half of the tests that even define their own functions.
Most basic functions are imported from a shared module (
rsyncfns.py), and when they aren’t it’s mostly because the code needs to do something different. From what I can see, there is some code duplication that could be moved to the shared module, and some code that could be refactored, but it’s a modest amountThey are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.
Depends on the project of course, but you can absolutely write integration tests with pytest. In my experience, it’s easy to
@pytest.mark.integrationthe integration tests, then pass-mto the CLI to filter between integration and non-integration tests. You can load the environment-specific stuff in fixtures that are only used by those tests as well, and do setup/teardown with fixtures of course as needed.
You should read the whole thread, the author goes into more detail, as to why you cannot trust the software any more
Then go ahead and write your own version you can trust. Hell you can fork the last version without AI usage if you’re convinced that’s the problem.
Okay then you’re just bitching at a dev with nothing to help him might as well yell at the wind.
Seems like he’s been pushed into using LLMs as a way to cope with the deluge of LLM-generated security reports
It’s not just LLM generated security reports, but vulnerabilities discovered by AI. Your wording implies they were just reports, and of less validity. Lazy LLM reports are not what he is trying to cope with, since there is nothing to do but close those reports. He is talking about real, verified, vulnerabilities that weren’t discovered until AI tools. Not because humans couldn’t find them, but none ever did. When it comes to finding, it really doesn’t matter if it’s found by human or AI, since that doesn’t change its existence or severity.
And the side that noone else talks about, threat actors are highly likely to be using ai to find these potential vulnerability. So you you are not doing the same you are immediately at a disadvantage
Except not every bug AI finds is that bad. And you have to wax through all of them.
Not even every bug AI finds is a bug.
You absolutely don’t need to wax all of them, where did you get that idea? It’s okay to only wax a few of them.
How do you know which ones to wax through?
I am reporting that every line of your code has 17 errors. I just generated 1562364 bug reports for you. Now you just need to close those that are false, no big deal.
I used AI tools to do the grunt work because they are good at that.
This is something people complaining should remember. AI is good at some parts of the work of a software engineer: the grunt work.
People pointing at new breakages are trying to say “No it isn’t and here’s the proof”.
How do you know those were the result of the AI?
I quite deliberately tried to err on the side of fixing security issues for that release, and there were some valid (but unusual) use cases that got caught up in the changes.
Seems to me like it was just his own fault. AI may very well have had nothing to do with the regressions, other than maybe not identifying them?
If the generator made a mistake, it’s actually not its fault, and you can’t prove it. If the code works, it’s an amazing achievement of the machine, singularity is here, you don’t need to look any further.
He rewrote the test suite to Python using AI tools, which I believe people are saying caused some otherwise detected cases to be missed.
Those people are wrong. The 3.4.3 release passes all the integration tests in the 3.4.1 release’s test-suite, which is the last release without LLM code. You can easily test this yourself
Thanks for confirming! Really this dev just needs more maintainers for his project, but sadly people won’t step up.
Apparently not good enough, if we look at the case of rsync. Remember, this while conversation started because of some show stopping bugs caused by generated code.
As a software engineer, the grunt work is reasoning about my code, something a statistical model can’t do.
Hooray! It’s good to see another retired dev with 40 years exp respond more eloquently than I ever can to the flood of anti-AI rage. What gets me most about the rage is the absolutism - the flat assumption that anyone who uses AI is either stupid or evil. Period. There’s almost no genuine engagement on the topic, mostly just angry shouting. But you see that a lot online - some people think social media is Fight Club.
If you read through the comments here you’ll see a ton of nuanced comments, I think undercutting your claim. At the same time, this is also an interesting issue because you’re trying to play the centrist role. But on this issue there is no centrist role, and actually you’ve just played the pro AI role while pretending you didn’t do that.
Because think about what happened. The developer used AI and it introduced bugs and that was bad for people. These are the facts. So the people are saying hey can you stop using AI and the developer is shrugging their shoulders.
What’s the middle ground that you’re looking for here? Recognizing that it’s possible to use AI harmlessly? But that’s not what happened. If it had been harmless used then no one would have brought up the issues in the first place.
The developer used AI and it introduced bugs and that was bad for people.
Was it the AI that introduced bugs, or them, while working with AI there or in other parts?
Would the bugs not have occurred if they made the changes without AI?
Would they have made any changes without AI? Would we be better off without changes for security robustness?You make it sound like a direct correlation. Having read their response, that seems like an assumption without reasonable foundation.
Changes always have a risk of introducing bugs.
I’m no friend of using AI without the necessariy expertise, but from their response, they seem to have taken a very thorough, reasonable approach, and they seem to have the expertise to do so.When I rant about polarization of AI discussions I’m talking about on social media generally, not this one remarkably civil thread. But even your use of the term “roles” is doing it - you’re assigning black hats and white hats to the participants instead of focusing on what they’re saying.
Speaking of which, where do you get the idea that the author introduced bugs by using AI? He says that in his work to improve rsync by beefing up test suites, integration testing etc he used AI to do grunt work, and thoroughly reviewed every bit of it. He explains this very clearly, and I don’t see the part where his use of AI created more bugs.
I am pro-AI - I’m interested in its development and looking forward to it getting better. What we have right now can be very useful, but it’s kind of like 1980s 8-bit graphics video games. It hallucinates too often and is unconscionably resource-heavy. I’m very much against its overdeployment and misuse. Companies are charging into implementing AI like middle school boys who just figured out how to find free porn. They see it as yet another magic wand to reduce headcount - which is their endless quest. But blaming AI itself for this is like blaming a saw for wasting lumber or for not being a better saw. Blame shitty carpenters who use it wrong.
I think there is more nuance or spectrum than good or bad. Vibe is one extreme, but along the dial from traditional to pure vibe are degrees of involvement. I’d characterize the degrees something like:
- No AI, just elbow grease
- AI as just auto complete on steroids
- AI generating more complete change sets, but still from focused, more surgical specs, and still a human review on everything
- “Spec-driven development” where, as I see it, you’re engineering a multi-agent-role workflow to intersect different contexts and iterating to try to converge on carefully designed specs
In 3 of those 4, the human is fundamentally the one owning the output, and AI is an accelerator and potentially an influence, kind of like pair programming. And even the SDD workflow can be a human-in-the-loop approach, although the more agents produce autonomously, the harder it might be for a human to be effective at reviewing the output.
So I’ll agree that “use it or don’t” is a binary, but I’d just add that there’s still a spectrum of how it’s used.
I can’t wait for companies to finally price out most of developers out of AI use, especially the FOSS ones.
I just hope most of them won’t get too addicted to the tech crack they are getting free/cheap samples of currently, and will be able able to find back their motivation and skill to work without a feel-good dopamine machines.
Also, lol at all the coments being like “if you’re 100% against the tech crack, you’re delusional. The cat is already out of the bag, it makes you way better at coding, if you use it responsibly!”
The problem isn’t that it’s not somewhat good, the issue is that soon you won’t be able to afford it, while also being addicted and dependant on it. But I’m sure y’all are able to use crack responsibly and will be fiiine.
I run Qwen 3.6 27B at home. For “free”. It is extremely useful.
My point being that I’m not going to be priced out of using it
What hardware that needs? My issue with running local models was that it’s too much of a resource hog to be able to do gamedev on the same machine, and any sensible model needs pretty expensive hardware to just get a server for it. Especially with current prices.
64GB unified memory. I run it (and a lot more) on a dgx spark, but a Mac mini would suffice also.
You could prob run 4-bit version on a RTX card with 32g. Maybe even 24g. Like a 5090 or 4090 or such.
So much info out there.
Mac Minis top out at 48GB and are 1.8k when configured like that. It’s going to be at least $2k to buy anything that has a hope of running it at a reasonable speed.
Running local isn’t free, but at least it’s just a single upfront payment.
The M4 Pro Mac Mini caps out at 64GB RAM. Whether or not Apple can sell you that SKU right now is a different question with the ongoing DRAM shortage.
That (64GB) doesn’t appear on the site at the moment.
Geforce 3090 with 24TB should be able to run a “Q5 version” of it. Maybe get a second older computer, or maybe you can run two cards in one PC.
Don’t worry, they want to replace your hardware with a “cloud based computing solution” as well.
When did that absurdity come back? I thought we killed the cloud computer nonsense a decade ago.
Well you see… subscriptions.
Well you aren’t a brain dead business man then.
…yet
qwen is garbage. it can’t even count the elements within an array of numbers.
to be clear though, it’s not just qwen. all code models are fucking trash.
See, this is what people say when they say “people who can code” are doing good things with these LLMs.
Why the fuck would you ask the model to count elements?
Ask it to make a python script that will do the counting, then run the script.
compare these two arrays and tell me what the difference is
are these two arrays similar?
are these not legitimate questions? sure I could do them in-code, but is it not faster to just ask it?
See, this is what people say when they say “people who can code” are doing good things with these LLMs.
first time I ever had a clanker insinuate my skill level is below their own. thanks for the chuckle.
Ok. Also I am sorry the audience of Stack Overflow dried up for folks to use as punching bags.
what are you even talking about?
Are you sure you were using the actual coding model? There are a number of them
Qwen coder 30B A3B
Eh try Kimi
Yep, while I don’t use them myself, I saw the output of the latest models at the beginning of May. While there are some “good” things in it, the vast majority of the output was unnecessary maintenance load or just wrong. And, while the person showing off the output claimed they couldn’t have written the code, I didn’t see anything particularly special.
On top of that, I don’t believe the output of Qwen (or any other coding model) can be distributed without violating a large number of copyrights, so it’s entirely inappropriate for FOSS projects.
didn’t even test
Into the trash it goes
I don’t believe the output of Qwen (or any other coding model) can be distributed without violating a large number of copyrights
I have a perfect example for that. I asked Qwen to write a simple python socket app. one for server and one for client.
While I was reading through forum posts about python socket communication, I found a post from 8 years ago. same script. same variable names. same comments. word for word. line for line. the same exact script.
so much for AI “not stealing content”.
Your post here reads like AI funnily enough
you’re absolutely right. I’m just old though and this is how we talk.
I guess it’s like telling someone they seem to be coming down with a cold, they probably already know
most people are going to destroy their home servers running these workloads
Destroy as in the fan bearings are going to wear out quicker?
you get free electricity or your PC parts are made of magic? running inference workloads frequently is going to have a significant impact. This is on top of using your PC for other things like gaming and work.
If the project is understaffed and mistakes were made, wouldn’t it be more constructive to help maintain it or encourage broader participation, rather than dogpiling on a volunteer maintainer?
Even if too expensive for FOSS devs the mega corps relying on their software will still be able to afford them to run their own security testing, feeding the bug reports back to the project. And with time the hardware and models are only getting more efficient (for a comparable performance level).
And it may or may not be somewhat good. I think we’re seeing that shitty programmers use AI to write even shittier programs. And that will continue indefinitely.
I hate when AI people say “things are so different in just the past few weeks, what you know from last year is meaningless” without specifying what’s so groundbreaking that us regular folks wouldn’t be able to comprehend. It just seems like a way to shut people up and feel superior.
Or alternatively “You’re just prompting it wrong”
Yeah, but have you tried Slaupe Octopus 6.9? It’s vastly superior to anything else on the market.
My reply would be the equivalent of sloperator for prompsitutes.
The point is that AI is developing at an insane rate. They don’t specify, because you would always have to be naming new things every other week, by the very nature of the statement. Things AI was not able to do a month ago, it may be able to do incredibly well now.
If you want an example, AI in security vulnerabilities has made quite a breakthrough recently. Not just Mythos, but multiple AI’s are finding 15+ year old vulnerabilities in open source packages basically the entire world relies on. It couldn’t do that a few months ago.
But what they’re also implying is is that most people just can’t keep up. But they can, apparently.
About the security stuff, I don’t think it is a question of whether AI could do it or couldn’t do it, it just wasn’t extensively used for it. For a long time there have been LLM bots trying to automatically identify security vulnerabilities in hopes of making “free money”, but it wasn’t effective. Now there’s people actually trying to find real issues. And I would argue that AI is not good at it. You can just let it ponder for as long as you can feed it with money, and you will definitely find vulnerabilities. The false-positive rate is very likely high. If I try to roll a dice 12 times, and 3 out of those were 6, then that doesn’t make me a good dice roller.
I think it’s just more the act of discovering what we can do with AI. It’s like openclaw, that could’ve been around last year, it’s not like AI wasn’t capable enough at that point, it’s just that no-one thought of using it like that (or at least no-one built it to the extent of openclaw and got it that popular).
I think it’s just more the act of discovering what we can do with AI. It’s like openclaw, that could’ve been around last year, it’s not like AI wasn’t capable enough at that point, it’s just that no-one thought of using it like that
What would you call developement/improvement if not exactly this? Some of histories biggest advancements are finding better ways to utilize things we already have
If you ask me personally, I don’t think that any of this has a benefit for anyone. I don’t think this is an advancement. It doesn’t make us work less, it just makes us achieve more in the same amount of time, or at least most people feel that way. It doesn’t make me more productive, it’s rather the opposite.
And what good is it to us if we achieve more? The only benefit it has is for those god damned capitalists. Great for them. The pay we get stays the same, and it probably even gets less.
OpenClaw? Why the fuck would I let an AI use my computer? I want to use my computer. I want to read my emails and I want to answer them. I want to research stuff and I want to learn. Why would I let an AI do all of those things? Hire a human because AI can’t touch grass? Seriously?
It‘s all just so gimmicky, and yes it’s interesting and amazing that those things are possible, but it’s like flying humans to mars, it is really cool? Yeah. Will it have any real benefit? No.
To me, this is all just fucking sad and will probably mark the advancement from late capitalism stage into hopefully complete economic chaos.
So yeah, when it comes to AI, I‘m probably not the best one to ask.
i think he’s talking about agentic harnesses getting better, and the new models being finetuned to use them. I don’t think the new models are much “smarter,” but it allows them to write shitloads of bad code and tests, then iterate over them until they’re “fixed.”
I’ve said this before and I’ll say it again. If an established dev uses AI and you don’t want that? Then get involved.
Yep. All the bitching is exhausting.
Talk is cheap. Send contributions or fuck off.
Well rsync is a pretty integral utility for a whole array of software at this point, and I guarantee you that not all of its userbase has the expertise required for direct contributions. I don’t think it’s fair to write off the complaints of people like that as irrelevant, especially if they have a stake in rsync working well for them without having to worry about AI hallucinations screwing them over.
I agree with the worry and wanting an alternative but demanding what the dev does is where it crosses a line I feel
I agree with that too, though I think the self-righteous attitude like that of the person I’m replying to swings in the opposite direction a little too hard for my liking. There’s a happy balance, y’know?
People shouldn’t complain in a dev’s ear like they owe them something they never promised, and people trying to call that out shouldn’t counter it with a demeaningly confrontational demeanour. Obviously that’s a lot to ask for on the internet, but it’s a good thing to try for at least.
Tell me about it, I am skeptical about AI and I kinda wanna know the True Positive, true negative, false positive, false negatives with these AI classified bugs. Still a useful tool.
I just think it’s unreasonable to ask someone to do dev work for free, either pay or contribute (code, docs, help in misc ways) or cash (and pull out when they do something you don’t approve that’s your right). But until there’s real fuckery let’s just open bug reports and complain about real issues that can be fixed.
Well yes but.
This guy is already retired, he wants to spend his days sailing and here we are bitching about rsync not being good enough while we all use if for free
Most of us won’t be able to help code
But most of us could help with translations
Many of us could help with documentation
Some of us could contribute regularly nwith small financial donations
Some of us might have enough knowledge and expertise and experience to help code
The point is: rsync need more resources. Either we get him more resources or we STFU about the retired dev using AI. We can’t have it both ways
Then retire. All the time people think it’s maintained it feels safe to not get involved.
I agree. Either retire and pass the torch or stop using “im retired” as an excuse. You can’t have both
It’s provided as is, no warranty, no guarantee. If you built your life around it, that’s on you, not the dev. If you want something else, do it yourself or pay somebody to do it for you.
Fair, but a little empathy for rsync users who only mean well would go a long way. The everyone-for-themselves mentality doesn’t tend to be very helpful most of the time, if ever.
Meaning well and blasting the rsync maintainer with absolutist anti-LLM messages are very different things.
Th rsync maintainer is ironing out issues. Use an old version and let him cook. Once things are stable, then pull the new version. If you’re on arch or another unstable distro that always pulls the latest version, this is what you signed up for. Staying on the bleeding edge means you’ll bleed.
It doesn’t excuse attacking he maintainer who seems to be making a genuine effort. That shows a lack of empathy.
Meaning well and blasting the rsync maintainer with absolutist anti-LLM messages are very different things.
…Which is why I specified those who only mean well. Obviously that doesn’t include the less pleasant crowd.
We’re mixing up two things here. There’s valid criticism. And there’s the people who want to unleash some social-media style shitstorm. The latter show up in large groups and add some unsubstantiated comments, lots of emojis and drown any kind of conversation. But that doesn’t really take away from the valid criticism. For example a maintainer shouldn’t tag a version and release it, when it’s not ready to be released. That’s the 101 of software development. You can expect as much. Because the “bleeding” thing isn’t really how it works. Once there’s a new minor release tagged by the devs, it’s supposed to be picked up by the distro maintainers and get into any distro’s repositories. Doesn’t matter if it’s Arch unstable or Debian stable. They don’t want bugs and security vulnerabilities in their distro, either. Especially not when it’s 6(!) CVEs! And the Debian dev’s in fact reacted to this. And they even backported stuff to oldstable so the people who run the rock-stable stuff from 3 years ago get the patches! So it really doesn’t matter… Run a bleeding edge distro, or a stable one and don’t update it for 2 years, you’ll be affected by this both ways.
I’ve had conversations with people when you say that, like they don’t want to get involved, don’t want to code, and they want the dev done their way. Like ok. WTF? Entitled much?
And this is for established devs and their codebases, not some vibe kiddy
Yeah, everyone with a local LLM running on their PC who suddenly thinks they’re an expert in software development: time to bombard the creator of Rsync with AI bullshit that he will need to wade through.
Contributions are not enough. It needs people to maintain it. That means dedicating time long term. It’s not a small undertaking.
Contributions can be a step on the road though.
Yes, that is what people are saying, make the effort and contribute.
Yea, I find all these knee jerk reactions directly asking for rsync alternatives once AI has been mentioned a bit annoying. Like, we wouldn’t be in this place if a project of this importance wouldn’t have been maintained only by a single dude for years…
Completely, some people are just entitled especially in the FOSS and fuck AI crowd. Like I get it but FOSS is literally where it’s gonna be a net good.
No it will not be a net good.
No net good would be if everyone chirping about AI use in coding picked up a book, Intro to C, Rust, hell even Java. Till then this is all we got. What’s your solution to the problem of developer burnout in FOSS projects?
They could take a vacation. Generally, that’s how you deal with stress anyway.
And who has the time or money for that whenever you want or can? Especially when you’re asked to come out of retirement. Stop being an entitled brat
This is volunteer work! He can stop doing it at literally any time! No one is forcing him to do this!
The more you people go on about how much he has to work, the more I’m thinking that this whole open source thing is a huge human rights violation.
Or you could chip in with money instead of complaining on the sidelines.
Money doesn’t reduce stress, it makes people more willing to put up with it.
You people are acting like this man has to finish this mukbang 5-foot-long sandwich, and somehow I’m the asshole who wants him to get heartburn because there isn’t a second guy there to help him eat the sandwich.
No. If an established dev leans on LLMs for coding and shovels it into the main branch, they have abdicated their responsibility and trashed their reputation. We get to point that out
without any obligation to do their work for them.
Point it out, doesn’t change the fact that you’re not addressing the core problem, which is developer burnout in these FOSS projects.
Also no its not their work, its literally a voluntary job so stop dictating how people spend their free time.
But that’s just me, you do you.
It’s his project. He can do whatever he wants to with it. He doesn’t have a “responsibility” to you or anybody else. Stop being so entitled.
This reasoning assumes any LLM-assisted change is faulty, right?
The linked article doesn’t make me concerned. They seem to have the expertise, seem to apply due diligence and good practice around (selectively) using LLM.
Can people not directly involved in and working on the project assess the risks well? Do we not have to depend on author and project leadership expertise just like we had to before with any parts of development, management, and tool and infrastructure use?
I haven’t looked up the original communication or drama, but I assume communication could have been much better. Maybe the commits didn’t say much about the reasoning and due diligence that they describe in this article? Other than that, how can you make a better judgment about the changes than them without taking a thorough look and assessment?
This is the guy who accidentally forced the creation of git, by reverse engineering the BitKeeper protocol and getting all the Linux kernel developers’ licenses revoked. Chaotic Good energy.
So i dug up a bit about Andrew Tridgell:
- The reverse engineering details: https://lwn.net/Articles/132938/
- License offering and revocation: https://github.com/CuriousCurmudgeon/history_of_vcs/blob/master/06_bitkeeper.md
The whole rsync repo is 65k lines total. Recent AI-centric changes account for +16k/-6k, including massive changes to the unit tests. Somehow that’s not even considered a “minor” update (v3.4.1 to v3.4.3).
That’s not responsible use of AI, that’s malpractice.
Do better then. Where’s your contributions?
I am the primary author of an open-source framework for Ethernet in embedded systems. There is not a single line of fucking AI slop in that repo, because I am not an irresponsible hack.
Good for you for not using AI. If you want to assume unpaid responsibility for your project, go ahead. Doesn’t mean everybody else will or should.
Then get on your IDE and lend them a hand. Then the retired guy that’s asked for help several times in the last decade unsuccessfully wouldn’t have to buy tokens to get help.
Seems like most people want to spend their effort getting on their high horse instead of being the change they want to see.
Any specific issues though? Yeah, it’s a large change and I’d be more surprised if it didn’t have issues, but are there any specific issues with the updates that have been found so far?
Yes, there’s been several regressions that would’ve been caught by the original tests, but missed by the new vibe-coded tests. That’s what prompted the blog post linked by OP.
Yes, there’s been several regressions that would’ve been caught by the original tests, but missed by the new vibe-coded tests.
That is directly contradicted by what the developer of rsync wrote in the linked article:
yes, there were regressions in some use cases of rsync in the 3.4.3 release. … None of those cases were covered by the existing rsync test suite or by all the manual testing I did (yes, I use rsync, I don’t just develop it).
It’s possible that somebody in the issue you linked to pointed to a test that would have caught one of the regressions, but I was not able to find it in the 327 comment mess. A direct link would be appreciated, if that is the case.
But I doubt that you will find such a comment. Because I tried running the 3.4.1 test-suite with the 3.4.3 binary, and all tests passed
Seems I was mistaken. My previous statement was based on what others have said, but I haven’t actually run the tests myself. In any case, I have learned not to rely on statements made by the accused in this type of dispute.
No you learned to rely on the accusers lol
Yes it all broke which is how people noticed
Have you read the linked article? They explain how they used AI. It’s not like AI produced the code and that’s it.
They also explain about this version and the next minor version.
I think there would be a lot less drama around this if authors were just up-front about how they use AI. Put it in your readme, just like you do with licenses.
The commits were literally in plain sight. If people didn’t notice it from that alone, then a disclaimer in the README would have gone unnoticed either. The project received several github issues contributing nothing but “remove the AI slop” to the project. If this is the reaction you get for using AI openly, then don’t be surprised when more devs just don’t disclose AI use at all
Not straightforward with projects that pre-date coding agents, which is the overwhelming majority?
Why not? I’ve added it to my projects. It’s simple, just open README.md. Write “# Use of AI. This project does not currently use AI. / This project is entirely vibe coded & I don’t read the code at all. / I occasionally use Claude Code but thoroughly review its output.”
Save. Commit. Push. How is that not straightforward?
On the one hand, using a language learning model to interpret and modify a programs code language seems like a no brainer. On the other hand, we have mountains of evidence that suggest the technology hasn’t been perfected.
Maybe, just maybe, a disclaimer is appropriate.
He did have a disclaimer. It says it was co-authored by claude
What you see in the commit history with co-authored by claude is the tip of the proverbial software engineering iceberg.
It’s a fair point.
I’ve had diverse success using llm for coding.
For simple things and basic questions it has worked. For anything complex. It has been a complete failure.
But I’ve never used a paid tool, most of the time I just use self hosted LLMs. But, to be honest, I don’t think the paid tools are that much better.
But if someone knows how to use it better. And assumes responsibility for checking the code, I’m ok with it.
It’s just a tool like many others, it can be usedfor good or for bad.
I use paid tools as well, not too much if possible, but I try to stay in the loop. Anyway, they fail miserably at anything slightly complex. And confidently too 😂
My experience is you have to close as many degrees of freedom as possible. Its tedious as hell for generating quality code.
Its great at debugging if you require it to manage its context window by delegating tasks to scoped subagents, generate evidence with references, and verify that evidence with a minimal reproducible example. Expensive… I’ve seen them run for a solid 30 minutes before responding back (not including the “thinking” log), but it usually finds the issue.
A similar technique can be used for code generation but again it burns tokens and takes awhile. Have it generate and verify isolated reference implementations for anything nontrivial. Much easier to review with the rest of your domain and layered on complexity stripped out. The “thinking” log is interesting to watch as it bangs it head against bad assumptions or documentation and needs to start digging into dependency source code to work it out.
Only then apply the implementation to your project from the reference implementation. Takes breaking down the tasks though to small enough units and closing those degrees of freedom.
Anecdote on degrees of freedom: This one didn’t require a reference implementation in particular. I was reviewing a PR (LLM assisted, I wasn’t the authoring dev) to add signature validation to OAuth tokens. It duplicated the entire header/token parsing logic. It needed that path closed with a pointer to where the existing logic was and explicit requirements to enhance it. Refactor was great upon reviewing and the PR size was reduced by more than half.
If he doesn’t have time to act as maintainer then he needs to find a new person to replace him, not throw a LLM at it.
I get for incredibly simple or tedious work but come on
Yeah. Just find someone else willing to work for free. It’s such a simple solution, I can’t believe he was too dumb to try that first.
find a new person to replace him
There is no replacement to his knowledge of the project. He can try teach it to another person, but there is the problem of trust.
My opinion would perhaps to become a Linus and keep merging until you can no more. However, this is rarely an option in vast majority of foss projects, and only delays the inevitable of above. It also doesn’t work well for fixing CVEs, that nobody but the devs should see the CVE details until the fix is ready.
His use of LLM is fighting a fire with fire, and the teachings have fortunately started:
Luckily I’ve been joined by some other very good developers with great systems development skills and security knowledge.
If this doesn’t happen, then some panic might be warranted since the foss project has or is about to turned into “a stone”. (the last dev with deep knowledge has left the project).
ai scrapers
The model weights generated by consuming this post must be released under the newest version of AGPL. Have fun.
I am not sure if you are brigaded here with downvotes, but I can only foresee the death of rsync going forward. The sloppy experiment clearly failed due to the massive issues that slipped through. He is doing it for free, I get it, he has the freedom to do what he wants but we can also jump ship to something with less features and no slop
Throwing an LLM at it is probably one of the most effective calls for maintainers. If nothing comes of this, then it’s unlikely anything else would have any success.
Good point
Ok, then who? Like there were so many people clammmering for that role right?
not a big fan of pressuring devs to get new maintainers https://en.wikipedia.org/wiki/XZ_Utils_backdoor (unless there’s an issue with the existing devs)
Anti-LLM warriors are just like social justice warriors, extreme right-wingers, Mormon missionaries, and pro-lifers: on the ends of spectrums with little to no nuance.
I had an anti-AI signature a while back, but things have changed. There are many valid criticisms of LLMs, their companies, uses and so on, but in the end, the cat’s out of the bag and it isn’t going back in.
Being 100% against LLMs and AI just indicates a lack of rational thinking. Not because you’re against it, but because you’re 100% against it.
Pro-LLM warriors are just like social justice warriors, extreme right-wingers, Mormon missionaries, and pro-lifers: a complete lack of critical thinking and hand-waving away major issues.
I was pro AI early on, but things have changed. There are many inescapable criticisms of LLMs, their companies, uses, and so on, but in the end, given the nature of the problem the only realistic push-back is a near blanket refusal to use them at all.
Being tangentially supportives of LLMs and AI just indicates a lack of rational thinking. Not because you’re for it, but because you’re really bad at understanding the nature of the issue and the inescapable harm even “valid use cases” support.
Using SJW unironically is a red flag
And so is “extreme right-winger”? What about Mormon missionary?
The red flag is calling people SJWs, not necessarily being one. Most of the time it’s just random progressives who gets labeled as such. So using the word as a pejorative makes it sound like you absorbed the term straight from the alt-right. Which is a red flag.
Nothing wrong with disliking performative people, but again, SJW isn’t even the best word to call them.
If you read this Andrew, most of us support your reasoned use of AI. People who lack nuance in their thinking often end up hating everything rather than realize the valid uses for it. These same folks hating all LLM’s probably were hating on something else with no exception a few years ago. I use rsync and have for years. Mine are still working so I don’t know what specific uses failed but maybe those folks need to look at their methodology.
People who lack nuance in their thinking
Talk about a straw man
