Live data from Hacker News

Please Do Not Vibe Fuck Up This Software

github.com

441–450 of 534 posts

Re: Please Do Not Vibe Fuck Up This Software

#441
post #395

Earlier quoted context omitted.

Bugs exist in human code too. The AI derangement crowd pounces on any small bug as evidence that AI is a trebuchet, and thinks that if only we didn't use AI there would never be any bugs (like five years ago when all software was perfect, was not being enshittified, and had 0 bugs).

> Bugs exist in human code too. These bugs did not exist in human code. They were introduced by AI. > thinks that if only we didn't use AI there would never be any bugs Strawman. These bugs would not exist if not introduced by AI.

The bugs were introduced because rsync had security issues(i.e. bugs) in it, presumably written into the code by humans.

It's really baffling to see so many people in this thread maintain the position that somehow software was clean and pristine until AI touched it with its evil.

Please try to at least put some sort of constructive argument forward, for example - I don't like AI because it might introduce more bugs than a careful human reviewer. Then we could discuss why a single maintainer is responsible for rsync and how they should handle the pressure of keeping it up to date - should they just stop making further changes, should they look for tools that might help them?

(By the way, if your position is that rsync was perfect before AI got its hands on it, you have a clear solution to all your problems - simply do not update to any newer versions)

Either way, move away from this absolutist nonsense that has no bearing to reality.

Re: Please Do Not Vibe Fuck Up This Software

#442

Earlier quoted context omitted.

> Rsync was complete software. It was (and is) not: rsync has over 300 open issues with bugs and feature requests.

1. Some of those recent bugs were caused by unnecessary vibe-coded changes. 2. Of course bugs should be fixed. I even say so in the comment you replied to. You are attacking a strawman. 3. People will always make feature requests. Some want rsync to be able to make a sandwich. That is not really in-scope for the project though. I think the GNU coreutils are doing this largely right. New features are almost never adde…

> Some of those recent bugs were caused by unnecessary vibe-coded changes.

If you think that fixing security issues is "unnecessary changes", maybe.

Though maybe security is not "in-scope" for you?

> That is not really in-scope for the project though.

Why do you decide what is in scope for the rsync project and what not?

Apparently the maintainer disagrees and also wants to fix existing security issues.

Re: Please Do Not Vibe Fuck Up This Software

#443

I also hate the ai slop but on the flip slide this maintainer has been asking for help for years and dosent receive much in the discord. I also want quality code but don’t jump to demonize a volunteer especially when not many have jumped in to help

Did he ask for help in churning all the code for no reason? Rsync was complete software. It does not need features, it needs stability and merely maintenance. If the author used AI for small, well-reviewed maintenance changes, that would be okay. But instead he is making large and sweeping changes that are entirely uncalled for and cause breakage. If the maintainer is overworked, that is even more reason not to do th…

If Rsync is complete software, why aren't you pinning the version and avoiding any problems with updates?

Perhaps there's people that don't consider it complete software; they can bear the burden of the new releases while you stay on the old and complete one. This has been normal software release and use practice for decades. Whole Linux distributions are built around different philosophies on software releases.

And yet you're making an argument as if this is something novel...

Re: Please Do Not Vibe Fuck Up This Software

#444
post #280

Earlier quoted context omitted.

Uhhh why? Aren’t these worthy goals? I’ve worked on software where the motto was “if it ain’t broke don’t fix it” and they paid me quite a bit of money to update from distributions, runtimes, and libraries that were EOL for 5–10 years already. I’d argue that keeping up loosely with modern practices of much easier than running outdated everything and suffer the consequences (breaches, painful updates)

What hurts the most is that most ppl disagree with me. It's like people telling you they will paint your house for free, even though the color of your house is perfectly fine, you agree to paint it in another color. Then you come home to find that they have bored a bunch of holes in the facade and tells you it's the new industry standard, when the winter comes you will have to plug these holes with special plugs, and…

> It's like people telling you they will paint your house for free, even though the color of your house is perfectly fine

You are perfectly capable of saying "No, I like the color of my house already". Just pin rsync's version. This isn't some esoteric mechanism, it's standard practice.

If you were actually willing to charitably engage, tidge was working on fixing security bugs - your house had holes in it already! Your choice was to say I'm fine with the existing holes, or yeah please try to fix them. Unfortunately while fixing them he introduced some new ones, but hey, that's the nature of software development - sometimes you introduce new bugs when fixing old ones.

Again, this isn't some esoteric happenstance. It's so banal it must happen thousands of times per day across many other maintained projects.

Re: Please Do Not Vibe Fuck Up This Software

#445

Earlier quoted context omitted.

> and grasp at every straw to combat it, which is a sane response Attacking every open source maintainer who might use AI for the sin of having used AI because one hates AI is just abusive behavior, not "sane response". What would the "sane response" be for people tired of the "AI is being forced down my throat and I need to combat it by attacking open source maintainers" side? Grasp at every straw to combat such beh…

It looks like they’re being attacked because their mission critical software is suddenly experiencing regressions, and the evidence suggests those regressions are in part caused by AI. The regressions are the issue. If the software was working as expected, no one would be coming after them for “the sin of using AI”.

Their mission critical software has bugs in it - security issues, which the rsync maintainer is trying to fix. In his attempt, he introduced regressions*(maybe - because some of the reported regressions list exactly the security issue that is being fixed as their use case...). This happens every day to thousands and thousands of software projects. This is why we have pinned versions, release schedules, different release philosophies...none of this is new.

I don't understand what novel problem you think you've uncovered here.

Re: Please Do Not Vibe Fuck Up This Software

#446
post #429
post #124

Earlier quoted context omitted.

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.

>the "developer" didn't bother doing the same before committing huge chunks of AI generated code? 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 commit…

I'm sorry, but you're calling the kettle black here. You made up a scenario in your head in which the developer decided to save time by using AI to generate thousands of lines of code instead of writing it themselves, but then also decided to spend time carefully reviewing and understanding said code to look for issues before committing, even though it's a well known fact that properly reviewing such large amounts of code written by others can sometimes be a more daunting task than just writing it yourself.

We both know what the more likely scenario is here. We both know that AI fanatics have spent the last year bragging about how many thousands of lines of code they can pump out per hour. Do not claim otherwise, because to do so would be an insult to my intelligence. And from a quick look at the developer's Github profile, it's clear they've gone all in on the hype, as I cannot find a single significant commit made this year that is not signed by Claude. Even the most experienced developers are not immune to AI psychosis.

> You owe them for using their software. How much did you donate to rsync this year?

I don't remember reading this in the license. Could you point it out for me? I can't find any such clause.

Re: Please Do Not Vibe Fuck Up This Software

#448
post #294

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…

> 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

Hi fao, the issue you linked starts with:

> Rsync 3.4.3 and newer is AI slop, and currently has several open security vulnerabilities and other critical bugs (including some link-related ones) caused by said AI slop:

It then proceeds to link to multiple functional regressions caused by (theoretically) fixes to security vulnerabilities.

This took me about 10 mins to review. It seems that the person who created the issue did not bother to spend 10 minutes to check his own work. Is this "vibe reporting"? What should we say about the irony of employing "human slop" to trash "AI slop"?

Further ironically, the "aggregate of bugs" in void-linux included an issue that was not even about rsync. More "human slop" that you are happy with?

Re: Please Do Not Vibe Fuck Up This Software

#449
post #441
post #395

Earlier quoted context omitted.

> Bugs exist in human code too. These bugs did not exist in human code. They were introduced by AI. > thinks that if only we didn't use AI there would never be any bugs Strawman. These bugs would not exist if not introduced by AI.

The bugs were introduced because rsync had security issues(i.e. bugs) in it, presumably written into the code by humans. It's really baffling to see so many people in this thread maintain the position that somehow software was clean and pristine until AI touched it with its evil. Please try to at least put some sort of constructive argument forward, for example - I don't like AI because it might introduce more bugs t…

> It's really baffling to see so many people in this thread maintain the position that somehow software was clean and pristine until AI touched it with its evil.

Nobody maintains this position. Again, it's a strawman you made up, because it's easier to dismiss such "absolutist nonsense" than it is to just admit that these specific bugs were introduced as a direct result of careless AI usage.

If the developer is overwhelmed by the maintenance burden (they aren't, judging by how many AI commits they've been making to a large number of repositories), then that's an entirely different problem that deserves a good faith discussion, but delegating the work to AI is not the correct solution.

> By the way, if your position is that rsync was perfect before AI got its hands on it

Again, strawman, nobody said this either. In fact, quite the opposite - we want rsync to continue to be maintained by a human. If the current developer isn't interested in or capable of maintaining the project anymore, they should just say so instead of quietly letting AI take over, because then the likelihood of someone else stepping up to contribute would be much higher.

Re: Please Do Not Vibe Fuck Up This Software

#450

This anti-AI hysteria is just such a classic moral panic. It’s just 1) identify something as AI-produced 2) attack and ostracize anyone who might be involved in that production And as with all moral panics, whether (1) is factual is totally beside the point. The point is the almost sexual release you get from (2). I know in this case there is AI-produced code in rsync (as there is with most useful software by now), b…

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…

> this one thing that is being used as an excuse to lay people off en masse, you have tech ceos near daily saying they're gonna come for everyone else's job too, and you have the hyperscalers taking up every bit of oxygen in the room.

I hear these complaints multiple times per day. Not just "nearly daily". The backlash has long since drowned out the original source. The ad nauseam anguish has been steadily increasing for months.

I almost prefer to listen to asshole CEOs at this point. At least they have more to say than just repeating these same points.

Being dismissive of AI panic is healthy. What you're engaging in is not.

Post reply on HN