- cross-posted to:
- lobsters@lemmy.bestiver.se
- main@0xdd.org.ru
- cross-posted to:
- lobsters@lemmy.bestiver.se
- main@0xdd.org.ru
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.
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.
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.
Except not every bug AI finds is that bad. And you have to wax through all of them.
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.
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.
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.
You gotta get up on ai start using it yourself, good or bad it is what it is and people will be left behind.
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.
He’s using it correctly
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
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.
He’s been asking for help but nobody took him up on it.
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.
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.
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
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.
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.
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.
Okay then you’re just bitching at a dev with nothing to help him might as well yell at the wind.
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.
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.
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 amount
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.
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).
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?
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
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
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.
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.
Are you sure you were using the actual coding model? There are a number of them
Qwen coder 30B A3B
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.
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”.
most people are going to destroy their home servers running these workloads
Destroy as in the fan bearings are going to wear out quicker?
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.
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.
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.
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
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.
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.
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.
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.
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 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.
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
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.
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.
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?
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.
Also, nobody actually knows if human intelligence is just finer grained stochastic prediction as well.
An interesting but valid argument. It doesn’t make AI better than it is, but any human contribution and change can and often is also faulty. People have gaps of knowledge, sometimes unwarranted confidence, other times lack of care, or just miss things. It’s not like we’re comparing the perfect human vs faulty AI.
If you don’t mind the security risk then you can of course use an older release.
I haven’t read the original rage/drama but I can imagine if from other drama instances.
This post is certainly a good, founded response.
There’s some valid concerns in AI usage, but unwarranted or inappropriate harsh criticism when it’s an established trusted developer and engineer - if we assumed good practice before then we could assume continued good practice. Maybe LLM is one point of increasing skepticism, but criticism should be open, respectful, and fair.
They invested a lot of time and effort into a public good project. In that context, they deserve at least respectful and non-worst-assumptuous criticism.
People have gaps of knowledge, sometimes unwarranted confidence, other times lack of care, or just miss things. It’s not like we’re comparing the perfect human vs faulty AI.
I went through the trouble of looking at one of the problematic changes in the latest rsync release, and what happened is that it surfaced a bug introduced in 2007 which was previously silently ignored. That’s definitely a mistake any human contributor could have made.
Yeah, the current backlash over LLMs in any capacity is a meme. It has turned into tribal politics. There is no longer thought behind the criticisms.
Also, it’s not the stochastic prediction part that makes LLMs “not intelligence” to me. It’s that it’s only predicting the next token in a string of text. I don’t believe this can approach what we do. To me it could well be that some other sort of token prediction is what we do even when we introspect and think of a model of the world.
It’s that it’s only predicting the next token in a string of text.
An LLM has an internal state while predicting text. The “next token” chosen takes that state - a model of the world - into account. So a LLM is predicting the next token based on a world model and the previous text.
Saying that it is “only predicting the next token”, without more context, while technically true is very misleading.
Yeah, the current backlash over LLMs in any capacity is a meme.
No, you just don’t want to face the fact that a growing number of people are less gullible than you.
Oh come on LLM have their uses and to say it is all slop is just a tribal my team thinking. But maybe that is the best humans can achieve.
Thank you for providing a clear example of the “my side good your side bad” style of thinking that completely lacks critical thought.
Lmao bro, what do you think “stochastic prediction” means? It’s always the people who don’t even understand LLMs defending them the hardest.
They don’t know, it’s just a fancy term their local LLM spit out at them
I agree, I’ve been recommending people to try to develop some level of nuance on the topic. I understand the fear, hatred, and loathing of AI; especially the way it’s currently being implemented and used. I really do, and I share 99% of the concerns. But there is room for nuance in the understanding of how it’s being used and what it’s being used for and who is using it, and when nuance leaves the room, we’re blind. And blind hatred is never a good thing and it does not lead to good places.
The funny thing is everyone hates AI but it seems everyone is using it also. So what is the truth.
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.
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.
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.”
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.
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?
He makes some fair points. However I do think the large amount of regressions in 3.4.3 should have resulted in a new release rolling back those changes.
I still like the response of the libxml2 maintainer, where any vulnerability will be disclosed openly and fixed when it’s ready. Maybe more open source projects currently drowning in CVE should take that stance instead of their maintainers burning themselves out over it.
Also, nobody actually knows if human intelligence is just finer grained stochastic prediction as well.
I think some people are stochastic parrots and some are not. I think most of our true understanding of things comes from escaping our limitations. Why so many people want to become a stochastic parrot is beyond me though.
Now to the future, because we’re not done yet by a long shot. The security reports keep rolling in. I’m working on a bunch of CVEs right now. Luckily I’ve been joined by some other very good developers with great systems development skills and security knowledge. Some of these people came to my attention partly because of all the rage happening at the moment, so I get some rage storm clouds have silver linings. Watch out for some credits for some great new rsync developers in the next release.
The project is being taken over by vibe coders, yay.
In my perception¹, ML differs from a brain by operating on words in form of tokens, while the human brain works by associating a concrete piece of information or thing with another, with the path in between being formed at some points, but crucially, being editable more or less easily and flexibly by retraining. And that’s the points, humans learn on a fundamental level. Dropping the prod DB means that my brain will form a hard association between the action of writing ‘drop database’ and fear, which in turn triggers deeper thoughts about wth I’m doing. LLMs see “conflict at line 1, 12”, and for some reason one possible path of tokens to generate can be a drop command. And as the underlying model data does not change, they don’t learn.
On how living being’s speech centres work, idk.
¹The perception of an acidhead. So don’t trust me.
The differences between a human brain and any kind of model we can currently train are too great to be listed. They are incomparable. It turns out that no matter how many perceptrons you put together, you don’t get a brain.
Heck, we don’t even know how brains work, and you got people talking about how they’re making AI clones of themselves with LLMs lol.
Devaluing the human experience until the tech looks good
The project is being taken over by vibe coders, yay.
Evidence?
You can look at the tone of the whole post to understand where the author is mentally. You can also make an educated guess about who will want to work on a project that’s being coded with LLMs. If I’m wrong remind me and I’ll own it. But I don’t think I am.
So no evidence at all then, gotcha.
Lol, I’m not a court of law, I’m a person. I can make my own judgments based on what someone said and how they said it.
Cool story bro.
Conjecture (and largely unfounded at that) isn’t evidence. I’d bet money that you don’t even have the ability to evaluate the project to determine if it’s being vibe-coded (as it seems is the case for everyone raging about this).
Lol, I’m not a court of law, I’m a person.
Get lost with this deflection crap. You’re the one who was making a definitive statement (“The project is being taken over by vibe coders, yay.”) about a widely respected figure responsible for creating one of the most used pieces of software ever (not to mention Samba too) who IMO deserves the benefit of the doubt until proven otherwise.
I merely asked you to provide evidence to back up your statement and clearly you’re unable to do that. Don’t try to push it back onto me trying to make me seem unreasonable for asking.
I’ve seen it enough times to see a pattern. This post is riddled with tech bro language, there’s no denying it. More of it is coming with everything that entails.
Thankfully there’s still openrsync. I didn’t even realise I was already using it so I’m not invested into arguing further. To all vanilla rsync users, Godspeed.
There is a significant majority of people on Lemmy who think installing Linux made them a software engineer and think that code completion is “vibe-coding” and not a basic feature of fucking Eclipse
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.
That was a fair response. But I get the feeling that a lot of “intelligence” is given in this tool. Feels like they are seeing something that I’m not.
I didn’t get that feeling at all. They didn’t make any such claims or used such wordings which I often see elsewhere.
Well I can always point to English isn’t my native tongue, so I can always infer stuff that isn’t there :D
Still, the way it explain give the idea of something that I can’t see it. And this is what is concerning me for the last week at least.
Trust. For me that fits your description, the thing I don’t “see” but some out there do. I try to keep an open mind, but the way this stuff is being sold hard bothers me.
I think “stochastic parrot” is a terrible way to describe LLMs. (Not to mention most people don’t use the term “stochastic” a lot.)
“Slot machine autocomplete” might be a better choice.
The intended audience of “stochastic parrot” was other AI researchers who do use the term “stochastic” on a regular basis.
Fair enough
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.
