421–430 of 534 posts
Could be generalized to Please Do Not Vibe Fuck Up This Software. Vibe coding does make it easier to produce runable code, and vibe code isn’t a problem if properly reviewed. Seems like AI just exposed that it doesn’t happened properly.
Ah yes, we couldn't write bug-free software so now instead we take on the much harder challenge of reviewing code instead. That will surely work out.
Earlier quoted context omitted.
I think people are very justifiably angry that a very stable, well trusted tool, has started to immediately go downhill. The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding ( https://github.com/linuxmint/timeshift/issues/548 ), one of those links goes to a larger aggregate of bugs reported downs…
> The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding ( https://github.com/linuxmint/timeshift/issues/548 ) There are four actual regressions there. The commits that introduced two of them have been identified, and neither neither of those mentions Claude (or another LLM). If you look at the act…
I don’t think people really care about rsync or the nuance. They just want to make an insta-reaction, rant about AI, then move on to the next story that raises their blood pressure.
Earlier quoted context omitted.
it's dangerous to refuse to understand whats happening broadly, and what's taking place in this thread, and to signal that it's ok to keep refusing to understand it. the anger that's showing up around ai isn't a matter of the masses being misinformed, or the messaging around it, it's a matter of physics. you have this one thing that is being used as an excuse to lay people off en masse, you have tech ceos near daily…
If you think you're owed a salary to do something that a simple machine can do, I have a field for you to plow by hand.
This whole brigading is bizzarre and some people are behaving like irrational animals. I potentially understand the motivations that might bring one to want to "win" this battle but this really isn't it - it just makes you sound like a fanatic. It takes 5 minutes to search for "regression" on the issue page and go through the 17 results. There are potentially even more on the tracker used prior to github. I think thi…
I think people are very justifiably angry that a very stable, well trusted tool, has started to immediately go downhill. The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding ( https://github.com/linuxmint/timeshift/issues/548 ), one of those links goes to a larger aggregate of bugs reported downs…
Earlier quoted context omitted.
> the anger that's showing up around ai isn't a matter of the masses being misinformed Isn't it though? let me quote my other comments in this thread: > There is undoubtedly AI-written code in the Linux kernel now, but are they out there harassing those maintainers? No. rsync GitHub is easier to brigade. > They’re also all completely disingenuous (“I’ll have to stop using rsync now”) given that 99.99% of software now…
> given that 99.99% of software now includes AI-written code source?
Earlier quoted context omitted.
[flagged]
But given the actual thread, which has some "flaming" but also many dry and serious comments, and how you describe it as incredibly unhinged while speculation about someone's motivation (looking for projects that might have used AI, versus being dismayed that something that used to be stable no longer is), and how you would say none of that to any of those individuals while musing about how they are just looking for…
I mean, they are. They’re not harassing Linus or linux maintainers because that would get shut down quickly. Instead they brigade the rsync GitHub issues.
> You declare the critics as witches
Did you read a single thing I wrote?
Earlier quoted context omitted.
The source code is all right there. An actual analysis would involve a complete description of what you were doing including code they are running proving that what you were doing is reasonable and correct and expected to work. An explanation of what actually happened and ideally the exact commit where it stopped working. A users bald assertion that something is "broken" with no details should be regarded with suspic…
Why should a random user bother analyzing the code when the "developer" didn't bother doing the same before committing huge chunks of AI generated code? The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair.
This is something that you assume, not something that you have any proof of. To put it a bit more strongly, this is something that you (and hundreds of other people in that github thread) made up in your head. The maintainer is a very experienced OS developer and there's no reason to suspect they didn't review the committed code.
Bugs happen, and the mere existence of bugs is not a proof that someone is doing a poor job. Assuming those bugs even exist. I am inclined to believe they do, but the issue does a poor job of reporting them. Instead of factually reporting regressions, the "issue" is a screenshot of a viral tweet.
Your vicious reaction is not justified, and you should do better in the future.
>The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair.
It is not fair. The rsync maintainer does not owe you anything. You owe them for using their software. How much did you donate to rsync this year?
Btw, the bug itself was introduced in 30656c5e by Claude Code, and I guess.. improper human review and testing. https://github.com/RsyncProject/rsync/commit/30656c5e Someone using AI to bisect recent rsync. https://github.com/themgt/rsync-compare-link-dest-341-343-re... Someone trying to fix it with more Claude Code: https://github.com/RsyncProject/rsync/pull/930 Related ticket: https://github.com/RsyncProject/rsync/…
This wasn't "unwanted new features". Tridge was fixing a security issue, related to a bug report. I sympathise - we are all getting slammed with security issues. Fixing them isn't optional. I can't say I enjoy returning to decade old software to do it - so colour me impressed that tridge is putting in the effort.
I'm also guilty of using LLMs to help me get past this mess. I dunno what tridge is doing - but I check every line of code it spits out. Nonetheless, I have no doubt bugs slipping through is a real danger. I haven't looked at the code in a long while, I'm not as familiar with it as I once was. So a bug slipping through is not a big surprise.
Which brings us to the one odd thing about the blow up. The original complainer seems very protective of his backup system - yet tridge's commit was only 2 weeks ago. I know tridge is good - but surely you treat this as alpha software. What was he thinking? Maybe he has a bit to learn about building reliable systems himself.