14 ms·

Please Do Not Vibe Fuck Up This Software

553 points by justdotJS 4mo ago

nickdothutton 4mo ago
Torture testing required before acceptance of vibed/AI submissions?
freakynit 4mo ago
[flagged]
- akerl_ 4mo ago
  Are they? I've read them and they mostly just made me feel like shit. The amount of drive-by hate being thrown at project maintainers of an open source project is depressing.
  - asp_hornet 4mo ago
    I guess both things can be true. Make you feel horrible and the reality of open source sometimes.
- drdrey 4mo ago
  Counterpoint: don't read the comments
- cpard 4mo ago
  The comments are definitely not worth reading. It’s a very sad thread, you literally had to go through all of them to find one that wasn’t about hate and stating some facts about the issues of the code.
  - wjnc 4mo ago
    I found them worth reading for the following set of thoughts came up: - programmers had problems with delivering quality long before LLM’s - very much research and tools went into that, bringing us {Git, libraries, VSCode, reviews, …,} but the human factor stayed the same (and more pronounced imho than in other fields of engineering) - LLMs democratized programming, enhancing a few, dropping the bottom to no skill programming - the tools and practices created for the quality problems from the past turn out to be wholly incapable of maintaining quality in the present The main problem behind this is that those delivering the QA tools of the past are central in the AI race. Old school engineering would separate these concerns.
- butterlesstoast 4mo ago
  The bread shop analogy made my year
- themafia 4mo ago
  People are saying they detect a lot of "hate" in these comments which I don't see or agree with at all. People clearly have negative opinions about this and they're expressing them rather openly but to confuse this with actual "personal hate" seems like an equally overcharged response. When you do anything publicly, even something that's considered a 'public good' like contributing to open source, you are opening yourself to the full tide of humanity for better or for worse. The overwhelming majority of the time it's for the better, occasionally, and in response to unpopular decisions, it's for worse. What you shouldn't do is take any of this personally. It's open source. You have permission to take a break, you have permission to directly ignore issues and users, you have permission to do whatever makes _you_ happy. If your goal is to receive unremitting love and adoration from a crowd of strangers then you're going to be bitterly disappointed... no matter how you occupy yourself.
magarnicle 4mo ago
Aww, but I have such big plans for it!
rsyring 4mo ago
> 26k code changes in 2 months..... rsync was 67k LOC as of 236417c (latest not obviously vibecoded commit it seems?).[1] Wow. 1: https://github.com/RsyncProject/rsync/issues/929#issuecomment-4585065320 https://github.com/RsyncProject/rsync/issues/929#issuecommen...
- scared_together 4mo ago
  When I look at the commits themselves, most of the ones generated by Claude are testsuite changes, or at least labelled as such. https://github.com/RsyncProject/rsync/commits/master/ https://github.com/RsyncProject/rsync/commits/master/
  - shimman 4mo ago
    Is that suppose to make this better? IME the most valuable tests are those that test specific regressions. It's the scaffolding we build for ourselves to enable feature development. Remove that scaffolding and you get accidents. Pray to your god of choice these accidents don't cause harm or loss of life. It should really be considered negligence at this point. Some of this software is extremely valuable, it's how we flourish as humans. Purposely fucking with that should bear some real world consequence. We do the same in every other industry, software is just as important too.
    - abuob 4mo ago
      In my perspective, "Analyze code, come up with edge cases and gaps and create unit tests for them" is one of the use-cases where AI was starting to get really good at, so I can see why someone would want to extend their test-suite dramatically using it. But yes, using AI to then generate code that still causes regressions doesn't quite square with that. Given the huge amount of test-changes I'd still assume good faith by the maintainer; possibly just a bit of overexcitement paired with a dash of too much confidence into the new tools that is now hitting reality.
    - ornornor 4mo ago
      I hear you, OTOH if this software was so valuable how come we aren’t funding it? A lot of the world runs on OSS with a coupe overwhelmed maintainers who get treated as if they owed everybody working software yet can’t make a living off it.
dnnddidiej 4mo ago
[flagged]
- bfkwlfkjf 4mo ago
  If I were a user, knowing that the maintainers just let Claude lose on rsync would be bad for my stress levels. In any case, I hate rsync owing to how easy it is to accidentally deleting everything. From my pov I don't care if it disappears.
  - bathtub365 4mo ago
    Then I have bad news for you about a large chunk of both open and closed source development today. We also don’t know if it was “unleashed”. Claude will add a co-author line to your commit even if you just ask it to author or touch up your commit message or clean up your branch’s commit history or any of a number of things that result in the creation of a commit, even if it touched none of the code. This functionality actually saves me a ton of time and results in higher quality commit structure and messages. Has this specific issue actually been tied to misuse of Claude?
  - egeozcan 4mo ago
    > If I were a user, knowing that the maintainers just let Claude lose on rsync would be bad for my stress levels. I think you are being too entitled.
krackers 4mo ago
Hm good timing with https://news.ycombinator.com/item?id=48334854 https://news.ycombinator.com/item?id=48334854 (OpenRsync)
- em-bee 4mo ago
  i suspect that post was made in reaction to the first AI/rsync post: https://news.ycombinator.com/item?id=48334021 https://news.ycombinator.com/item?id=48334021 , as i believe was this post too.
- exe34 4mo ago
  is this considered safe? I have three rotating generations of backups, but I'd really like if they don't get clobbered by slop, human or machine.
theonemind 4mo ago
I find the way that issue was opened incredible obnoxious, but it is baffling that the maintainers seem to have let AI loose on rsync. Like, why? Why try comparatively experimental crap when your fortune and reputation is made and you're the leader of a niche and immune to market pressure and the people love the thing and it does exactly what it's supposed to and works well? It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling. And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.
- roenxi 4mo ago
  Are you basing this opinion on the issue or actual evidence? Because this github link, although interesting, is almost completely context free on what the drama is beyond "Claude". The rsync maintainers could be anywhere on the spectrum from the perfect and responsible maintainer to incompetent children and we couldn't really tell.
  - xiphias2 4mo ago
    The problem is the we couldn’t really tell part. Changes made to mature finished projects should be minimal and readable and understandable by humans. Also rsync is handling copying binary data, it’s a project that’s super sensitive to hardware faults for example, which means it’s not just enough for the tests to pass.
    - throwaway7356 4mo ago
      > finished projects rsync is not a finished project: it has hundreds of open issues (bugs, feature requests, ...). "Finished projects" are a mythical thing that rarely exists in reality and even less in actually used software like rsync or the Linux kernel.
  - bulbar 4mo ago
    To me it seems people had actual problems with newer versions. Additionally, a significant portion of the code changed within a very short time frame. Doesn't matter if they did it by hand or with AI.
impure 4mo ago
Oh no, not Rsync. I guess that's one good thing about MacOS shipping with an ancient version of rsync. Oh, wait, they ship openrsync now, but the command is still called rsync.
jochem9 4mo ago
This is the third HN post I read on this topic. Everytime the same tweet (or whatever it's called for mastodon/bluesky/etc). Did anyone actually debug the issue? Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?
- cwillu 4mo ago
  https://github.com/RsyncProject/rsync/issues/929#issuecomment-4585695638 https://github.com/RsyncProject/rsync/issues/929#issuecommen... has a partial list
  - Lerc 4mo ago
    That is a list of problems, not causes, which is what was being asked for. It's possible it's some LLM randomness that caused bugs. That would suggest that some AI hygiene is in order. If it is because of behaviour changes necessary to fix security issues, then the regressions might be from things that relied on unsafe features. Do we know of actual specific causes yet?
    - adrian17 4mo ago
      Yesterday's comment listed suspected commits alongside the issues: https://news.ycombinator.com/item?id=48334270 https://news.ycombinator.com/item?id=48334270
- JdeBP 4mo ago
  It's called a post, the same as you used for Hacker News. And yes, I debugged one of the issues. I made the second comment in one of them. Markus Mayer did some debugging, too. Then I had to deal with something completely unrelated to computers for the rest of that day and several days thereafter, and came back to this. The problem with compiling code that used new kernel features was a bit poorly done. Anyone with any experience knows that a simple #if defined(__linux__) , which is a platform test, does not cut it for feature testing. M. Mayer went with an autotools test, which is what I'd have done too. The problem with the on-the-wire protocol is a tricky one, and caused by suddenly being conservative in what rsync accepts apparently without much testing of what out-of-range stuff in-the-wild rsync sends.
z3t4 4mo ago
Few things can trigger me more then finding a bug/regression and when tracking it down the commit reads like "modernizing the code", replacing all var with let, etc.
- ornornor 4mo ago
  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)
  - z3t4 4mo ago
    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 you wake up next morning and it's -10 C outside. Your house is now pink, you are cold, and nothing has improved. Next week another team comes by and offers to repaint your house for free... They say orange is the new pink.
    - Sacho 4mo ago
      > 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.
vsgherzi 4mo ago
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
- Hendrikto 4mo ago
  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 this.
  - brabel 4mo ago
    What the hell why are you thinking you decide anything?? The man has his project and can do whatever he wants with it. Read the license.
    - bakugo 4mo ago
      Yes, he is free to do whatever he wants with it. And others are also free to say that what he's doing is bad and is causing them problems when trying to use this well established software that is known for being stable and reliable.
    - baobabKoodaa 4mo ago
      Freedom of speech goes both ways, not just the way you like.
  - throwaway7356 4mo ago
    > Rsync was complete software. It was (and is) not: rsync has over 300 open issues with bugs and feature requests.
    - 4mo ago
sixhobbits 4mo ago
[dead]
himata4113 4mo ago
previous convo: https://news.ycombinator.com/item?id=48334021 https://news.ycombinator.com/item?id=48334021, has my comment so won't repeat myself.
koehler 4mo ago
I truly don't get it You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes. Why do we need AI here? And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched. What I have to do now, keep a fork of my entire system's toolkit?
- nottorp 4mo ago
  > Why is there a need of AI in here? For the same reason as some people would rewrite it in Rust.
  - mike_hock 4mo ago
    No, that's usually to decrease the number of bugs and vulnerabilities.
    - lelanthran 4mo ago
      That's not why people rewrite in Rust. Rewrites brings new bugs regardless of the language.
      - Matl 4mo ago
        You're conflating why people want to rewrite it in Rust vs what is the likely end result i.e. I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs especially because there's been almost no meaningful improvement in this space for a long time. But of course in the short term it will mean regressions compared to the established C written version. That is different from AI where the calculus seems to be that if AI isn't involved, it aien't relevant.
        lelanthran 4mo ago
        > I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs I don't believe that anymore - if that were true, the large portion of code now being rewritten in Rust wouldn't be vibe-coded slop. I'd be more willing to believe that "quality" was the reason if those doing the rewrite weren't fucking vibing everything!
m1keil 4mo ago
[flagged]
- egeozcan 4mo ago
  Comments in Github were usually horrible, but the AI stuff brought extra divisiveness. yt-dlp stops supporting bun because they call the rust rewrite a risk -> hate comments. rsync fixes security issues and gets some help from AI -> someone finds a bug and... hate comments. Poor maintainers. Crazy.
- deleted 4mo ago
  [deleted]
- throwaway2027 4mo ago
  "Cheap clients pay the least and complain the most."
relistan 4mo ago
Hacker News: “It’s unfair the burden put on maintainers of the core pillars of open source software. Show some respect for the maintainers, and do your best to contribute.” … little changes … Also Hacker News: “I have the right to tell you how to manage the project that you created and have maintained for 30+ years, because I feel very self-righteous about AI and code quality!”
- marginalia_nu 4mo ago
  As HN consists of more than two people, it is home to multiple contradictory opinions. Furthermore, both points may be valid. As a user you might want working software, and as an open source maintainer, you aren't beholden to what the users want.
  - relistan 4mo ago
    Sure, but you cannot deny the hypocritical swarm behavior, which is the point.
    - marginalia_nu 4mo ago
      The "swarm behavior" is mostly an illusion created by your mind. HN is just a bunch of people and bots.
      - relistan 4mo ago
        Yep a bunch of people who often exhibit swarm behavior.
        cyclopeanutopia 4mo ago
        By this logic, will you just start calling yourself "hypocritical Karl", as you clearly belong here? ;)
        relistan 4mo ago
GalaxyNova 4mo ago
What's next? Vibe coded coreutils?
- akoboldfrying 4mo ago
  Funny you should say that. The latest Ubuntu reimplemented coreutils in Rust, introducing a bunch of TOCTOU bugs. TTBOMK the reimplementation was done by humans, but the overall principle still applies I think.
  - ornornor 4mo ago
    I think TTBOMK = to the best of my knowledge, for TOUWANFIA (those of us who are not fluent in acronyms)
    - r_lee 4mo ago
      IGIN! (I get it now)
kjellsbells 4mo ago
I sure would hate to be a human developer named Claude right now. You wouldnt get credit for anything and every problem would be laid at your feet.
- deleted 4mo ago
  [deleted]
- GCUMstlyHarmls 4mo ago
  On the plus side, the CTO, CEO and CFO all know you by name now.
simianwords 4mo ago
I get the feeling that the GitHub issue space is used to wage some ideological warfare. It’s interesting to see how all this is panning and out how it would look like in the future. This tech is going absolutely nowhere.
akoboldfrying 4mo ago
Nobody whose software you use for free owes you anything. It is so important not to lose sight of this. If you feel like they do owe you something, that's only because years of habit -- years of using other people's software for free, and having the good fortune of finding it generally to improve in quality over time -- has caused your baseline to drift from the true state of affairs, which is that nobody whose software you use for free owes you anything.
- ianbutler 4mo ago
  People here hate hearing this. You're entirely correct though.
- tardedmeme 4mo ago
  Indeed you can step down, but as one of the comments says: > Just because you're giving free soup to the homeless doesn't mean you can piss in it
  - deleted 4mo ago
    [deleted]
  - DonsDiscountGas 4mo ago
    Okay but if shipping software that has a bug counts as pissing in soup then a lot of people have been doing this for a long time.
    - saghm 4mo ago
      Honestly if this is the metric, I'm not sure anyone has ever made piss-free soup
      - jason_oster 4mo ago
        You best start believing in piss-soup stories. You're in one!
    - bigstrat2003 4mo ago
christkv 4mo ago
Can GitHub add a tag to repositories that says "probably vibe coded" or "ai code detected"
- 0123456789ABCDE 4mo ago
  would you argue for an 'unsafe code' tag too, if it's attached to repos with C/C++?
  - cyclopeanutopia 4mo ago
    So all the other languages are safe now?
    - 0123456789ABCDE 4mo ago
      is that what i wrote?
      - LtWorf 4mo ago
        Then not why tag all of them?
  - christkv 4mo ago
    Would have to be on all repositories I think.
    - 0123456789ABCDE 4mo ago
      you're not required to include code in your repos, some are just a collection of markdown files. those could be considered unsafe, but they're not code. but i think you meant: tag all code repos as unsafe, because you assume all code is unsafe, and 1. i don't fully agree with that, and 2. that's half of my argument. 1. historically most languages bootstrapped their compilers with one of those, some eventually reaching the selfhosted milestone (ex: https://go.dev/doc/go1.5#implementation https://go.dev/doc/go1.5#implementation). 2. tagging repos with `unsafe code`, or if you prefer to stay with original `maybe vibes` tag, implies you have some level of confidence in the tag you are applying, and that you also can back that tag with some common understanding of its meaning. i do not think we have established what `vibed` or `ai coded` actually means. some know what their personal definition is, but it is not a shared understanding of the definition. as matter of non-exhaustive sampling we currently have vibe coded and ai code, ai co-authored and ai completions/suggestions, and ai aided. which one should be picked? nevermind the term ai is fuzzy, but how do you even begin the process of classification? a process that by it self, is likely to use more of the dreaded ai technology. where would github draw the line for this tag, such that it avoids backlash from users? pick your broad strokes: llm generated with no human revision; llm generated with human revision; llm wrote large parts of the change set, but a human made adjustments; lm generated small snippets — implying the contributor accepted the suggestions, llm aided with codebase understanding (RAG); lm picked symbol completion and types; ml model used for refactoring suggestions. for github the question† is: what is important for a user that sees this tag? what does the user care for? how does that affect their decision process when considering using, or participating in a project. there are much more interesting questions, than wether a repo accepts vibe coded contributions, still not easily answered. show me: total lines of code, or a ranking per language (only a percentage is currently displayed), code complexity stats, code churn, merged pull-requests vs total pull-requests, avg reviewers per pull-request, merge pull-request non-members vs members, mtt member reply on issues, mtt member reply/action on pull-requests, or split that between merged and non-merged pull-requests † also github has been absorbed into a large proponent of ai, microsoft
hugodan 4mo ago
Just use openrsync instead. And OpenBSD for that matter. There goes the bazar…
- kdjkskdndn 4mo ago
  Dude ssshhhhhhhhhhhh next thing systemd will come for openbsd...
contingencies 4mo ago
[flagged]
sciolist 4mo ago
When commenting, please assume good faith (in other commenters and maintainers). This is the third thread I've read on HN about the subject and I've sadly seen a lot of closeminded or shallow comments on each thread. Adding the above reminder, as I hope HN can engage in more thoughtful discussion.
- DonsDiscountGas 4mo ago
  One should assume good faith at first, or when in doubt, but after a certain point it's just denial.
21asdffdsa12 4mo ago
[flagged]
- foldr 4mo ago
  On the contrary: it's the people posting unhinged comments on an issue tracker that will be rushing to delete them in the years to come.
michaelmrose 4mo ago
This entire post doesn't belong here other than as a cautionary tale. Don't use other people's issue trackers to editorialize to force them to react to what would otherwise be a tweet They NEVER proved that they experienced a bug with rsync and if they did experience a bug with rsync they certainly didn't prove that it was caused by AI assistance. This useful research would have required real work. Their language and methodology of communication is abominable. Lest we forget the "crime" of the developer is providing for free something so useful that it became integral the the users workflow for years then potentially shipping a buggy version. People who labor for free for us deserve our thanks not our contempt.
throwaway2027 4mo ago
AI for me but not for thee.
croes 4mo ago
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.
- LtWorf 4mo ago
  > vibe code isn’t a problem if properly reviewed 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.
llbbdd 4mo ago
Crazy to watch the death of open source happen in real time like this. Why would anyone share any code to open themselves up for all of these wannabe main characters to pile on them? Given the choice I'd rather have a bunch of slop coded PR contributions to wade through than whatever this entitled nightmare raider thread is.
m132 4mo ago
Wow. Rsync has to be one of the worst spaghetti projects I've worked with. It's an incredibly decent tool built around a well-though out algorithm, but its code is an exact opposite of what you'd expect. And it's written in C. I'm not surprised letting Claude loose on it for roughly 2 months already caused visible breakage. The question is, with it being very obviously a bad idea, can the maintainer still be trusted if he let something like this happen?
eloisant 4mo ago
Is there any evidence this was broken by AI? I feel like these day any time users find an issue in software they blame it on "vibe coding". But software had bugs before AI.
- reliablereason 4mo ago
  The issue is apparently this commit (someone did a git bisect): https://github.com/RsyncProject/rsync/commit/859d44fa4f1420775e4ba050337ef32092f2894c https://github.com/RsyncProject/rsync/commit/859d44fa4f14207... Which is a fix to the security issue CVE-2026-29518: https://nvd.nist.gov/vuln/detail/CVE-2026-29518 https://nvd.nist.gov/vuln/detail/CVE-2026-29518 A CVE reported by VulnCheck which is a company that uses AI to find software vulnerabilitys. I would honestly blame this on bad test coverage. If you look at most of the commits where Claude is "co-author" you see that 80% of are just adding new tests. Which is exactly what would be needed if low test coverage was the issue. I have done the exact same thing long before AI was a thing. You are rushed to "FIX" some security issue that someone reported. It is a scenario where you are working in code that you did not write or you wrote it so long ago that you cant remember. You try your best to just fix the security issue but you perturb something else while doing it.
  - nbaugh1 4mo ago
    This doesn’t even 100% mean that the code was generated using Claude, only really means the commit message was. Write some code and then ask Claude to diff your changes and write a commit message. Now the internet hates you
  - deleted 4mo ago
    [deleted]
alkonaut 4mo ago
Would be interesting to know what exactly went wrong. How obvious was the mistake? How necessary was the change? What is wrong with the test suite that didn’t capture it?
- vinyl7 4mo ago
  What went wrong is using LLM generated code
SideburnsOfDoom 4mo ago
It seems that the person who opened this issue has a real and relevant point. But neither the original post nor the majority of the responses are productive, mostly due to the acrimonious language used.
rawoke083600 4mo ago
Been thinking of this mental model held by some "oh ai coding is always bad etc etc" (fair we all allowed opinions). But why are we okey with colleagues making from time to time terrible blunders (hey we all human ). But when ai makes mistakes its a sweeping judgment of "oh ai coding is terrible". We seen to not include all the amazing code they do right and security bugs they do find.. I feel if it was a human or colleague we be more fair with its failure and balance about his/her achievements also. Just a thought.ymmv
- consp 4mo ago
  When LLMs make mistakes, it is still the human making the mistake of trusting the LLM. And more often than not "AI" is hailed as costing no effort and being perfect in every way (yes exaggerated), which you can attack when it obviously is going to fail at some point.
- sureglymop 4mo ago
  Because AI can't take responsibility. Humans can. A human can not only learn from their mistakes and blunders but also, until very recently, the social pressure and fear of judgement would push (some) humans to try their best. Now however, it is less socially acceptable to judge a human for mistakes made with AI coding because we are in a time of experimentation. So the blame has to go towards AI coding. Of course, coding with AI can be acceptable, if the human using the AI is rational and responsible. But I think the bigger implicit point is actually that perhaps experimentation shouldn't be done on real projects and products as nonchalantly.
- matt3210 4mo ago
  AI mistakes are due to pure laziness and incompetence that appears well done. There’s a big difference between that and a genuine mistake from a knowledgeable person.
  - rawoke083600 4mo ago
    Lol what ??
Ozzie-D 4mo ago
[flagged]
matt3210 4mo ago
When people realize the AI doesn’t work in the long run we can have a mass revert party
afshinmeh 4mo ago
Genuinely wondering though: is the problem that the patch was vibe coded, or is that no one reviewed the changes?
- bakugo 4mo ago
  "Vibe coding" implies the changes weren't reviewed. That's the most common definition of the term. Even if the developer himself didn't say that, though, it's safe to assume no AI generated commit beyond a very small size is ever properly reviewed (in the sense that the entire code is actually understood) because doing so would take longer than actually writing the code by hand like a caveman.
- deleted 4mo ago
  [deleted]
thevinter 4mo ago
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 this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing, seemingly forgetting that before AI people did mistakes as well. If you have proof that AI involvement in rsync has lead to a significant increase in open issues please show it to me - I'll be happy to change my mind.
- consp 4mo ago
  > I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing It's not silly to have issues with something. People act on their issues. Possibly not the issue underlying the commit at hand here but something else, and act on it which makes it something to consider. My guess is people are tired of the "AI is the greatest thing since [cultural reference]" being forced down their throat and grasp at every straw to combat it, which is a sane response in my opinion and should be taken into account.
  - thevinter 4mo ago
    > It's not silly to have issues with something. I absolutely understand and agree. As I said, I understand the underlying reason. The silly part is the brigading - issues should be adressed on their own merits. The specific GH issue, and some of the comments therein, make the whole crowd they're affiliated with look bad. (imho)
    - consp 4mo ago
      I'd argue there would be two lanes as well: one where the issues are addressed in code, the other being the discussion of why people think this is a bad idea and speak so openly about it. This topic is the second I guess. Looking at the flow there is quite a bit of flamebait by the LLM and non-LLM camps which only muddies the water and doesn't resolve anything. The better discussion (imo) would be to decide if the vide coded fixes are worth it and if not, fork the project somewhere and let the distro's chip in to maintain that.
antirez 4mo ago
A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.
- cafebabbe 4mo ago
  Love that your comment is ambiguous enough to apply to both sides here :)
  - antirez 4mo ago
    Nope my comment is against the folks that are criticizing rsync author. Editing the comment to make it more clear, thanks.
- weiliddat 4mo ago
  Maybe I'm getting too skeptical. I have a feeling increasingly many of the comments on HN and the GitHub issue are just bots ragebaiting other people (incl. the maintainer)...
  - rf15 4mo ago
    [flagged]
    - weiliddat 4mo ago
      I'm not sure how to interpret your comment. It could be - a response to my comment saying that I am "illiterate" and cannot differentiate LLM output vs actual human comments (in that case I'm not sure what you're adding to the discussion here beyond a personal attack) - a general comment saying it's getting harder for people in a position similar to us (i.e. tech / tech-adjacent who interact a lot with others who write with LLM assistance or via LLMs) to differentiate human/AI output. I'll assume good faith and you mean the second. In that case maybe you can explain the "fundamental problem" you're referring to?
RustyRussell 4mo ago
I'm shocked that people are jumping on one of the most productive and powerful OSS maintainers in existence. The actual Claude "churn" is mainly test suite enhancement.
- deleted 4mo ago
  [deleted]
- nuclearpidgeon 4mo ago
  One of the most reliable OSS sync/backup tools on the planet for 2+ decades broke under people's daily backup use of it because of a large pile of LLM-driven changes basically out of nowhere from the project maintainer in a minor point release. I think they're right to be annoyed and to complain about it. Whilst a lot of the Claude changes are test related, there were still other changes that obviously broke things for people - and who's to say that some of the testing changes may not have thinned out the testing too given one commit "rewrote all shell tests in python" with over 4000 lines added and removed at once. And even after all that Claude churn on the testing, these breaking changes obviously weren't caught by tests, so it's not exactly an "enhancement" from the end user perspective.
  - ilikehurdles 4mo ago
    It has broken many times before. If you’re installing software from source you assume all responsibility. Go use Debian if you don’t want to deal with breakage.
    - izacus 4mo ago
      Just because you got shat on the head once it doesn't mean it's fine to be shat on the head every day now.
      - deleted 4mo ago
        [deleted]
      - newtonsmethod 4mo ago
KolmogorovComp 4mo ago
Seem to me some people have forgotten about FOSS projects > 15. Disclaimer of Warranty. > THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
- latexr 4mo ago
  “No warranty” isn’t the same as “no complaints”. Otherwise there wouldn’t be an issue tracker and a discussions section. The issue in question has already gone to crap and your point has been made there as well. It could definitely have been handled better, by all parties involved, but blindly quoting legalese isn’t going to resolve anything or make it better.
  - KolmogorovComp 4mo ago
    An Issue tracker is to track issues regarding the behaviour of the program, not the behaviour of the maintainer.
    - layer8 4mo ago
      If issues with the program are caused by behavior of the maintainer, it doesn’t seem inappropriate.
    - latexr 4mo ago
      And focusing on that after the fact does nothing to resolve the situation or advance the discussion, which should be the goal now. During an emergency situation where an issue is running out of control, the priority is to evaluate and contain the problem then address it, it is not the time to assign blame and quote regulations which weren’t followed. That’s for later, when everything is stable, together with understanding why the rules weren’t followed and if you can improve that process for the future.
irusensei 4mo ago
As much as I would love to see Anthropic going down in flames I think that developer doesn’t deserve to be targeted by such a low effort social media farming post. I am nothing but grateful for Samba and Rsync.
redsocksfan45 4mo ago
[dead]
abc123abc123 4mo ago
Jesus Christ... this anti-AI thing is getting ridiculous. If the code is good, bug free, and easily understood, who the f*ck cares? If a maintainer just accepts any code, without review or control, humans, just as well as "AI:s" can submit crappy code. I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.
- Symbiote 4mo ago
  The code obviously isn't bug-free as several issues were identified. It's also not easily understood, as there are multi-thousand-line AI-generated commits.
- latexr 4mo ago
  > If the code is good, bug free, and easily understood The whole point here is that it wasn’t. That’s the whole reason the submission exists, that allegedly bugs were introduced where it was previously working. > I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious. Be careful with assumptions. You are basically expressing that the people you disagree with have petty negative reasons to think how they do. That’s not empathetic and it’s colossally misinformed. I recommend you attempt a good faith search of the myriad reasons people may be against LLMs. Here’s a good faith question on HN to start: https://news.ycombinator.com/item?id=48172574 https://news.ycombinator.com/item?id=48172574
  - newtonsmethod 4mo ago
    Can you tell me any of the bugs? All claims I have seen so far of people being affected by bugs seem deeply implausible. The current ones I see are: * Can't build on Linux < 5.6. But people aren't complaining strongly about this, since it requires a build from source / isn't a result of an update from a distribution (and people can wait for updates / implement them themselves). * An issue hit with chroot false + daemon. People running this in an automated manner (as some claims suggest) are already using it in a way fairly likely to be insecure, chroot false is strongly discouraged here, and the whole point of these commits was that they fixed CVEs impacting precisely these people.
veyh 4mo ago
This could be an opportunity for another xz-utils incident.
comrade1234 4mo ago
I'm pretty dependent on rsync across all of my ubuntu servers. I just checked and most of my servers are on openrsync but one, built most recently, is on classic rsync. Not sure why the old servers are openrsync and the new one on classic rsync - I would expect the opposite. Anyway, on that one server: sudo apt-mark hold rsync
- pacifika 4mo ago
  You rather open the server up to security issues than have software where the developer has been assisted by ai which you feel decreases the quality of the code or is it for moral reasons? Rsync is not being vibe coded, and it’s not become slop so would love to understand the position.
  - LtWorf 4mo ago
    The integrity of the backups seems uncertain at this point. A backup tool that doesn't do backups properly is less useful than one with a CVE that might be exploited if the stars align.
vova_hn2 4mo ago
Since when github issues became a place to post a screenshot of a post from some other platform? I've seen this behavior before only in places where people post memes and other entertainment content. No actionable bug report/feature request. No text version. Not even a link to the original post. Did the person who posted this mistake GitHub Issues for their personal Twitter account?
- mikalauskas 4mo ago
  Posting screenshot is the easier way of blocking automatic LLM responses, cause most of the time people use text models without vision as a cheaper solution
basilikum 4mo ago
This is anti-AI slop. Posting a screenshot of someone else's text as an issue is about as low effort as it gets. It's also just a completely random accusation. I experienced a bug; the software contains some amount of AI code; that must be the reason. Because there is no other way bugs are ever made. Bugs only came to life in 2023 with ChatGPT. No need to look at the actual code, see if the bug is in an AI generated part, judge the quality of the code, whether it's just large chunks of AI generated code taken as is or small parts of carefully chosen and moderated code where the AI only does busywork but the maintainer outlines the structure and understands every part of the code. By all means, if rsync is full of low quality AI slop that causes bugs that would otherwise not exist, give some actual evidence for that and criticize it. But that is not <edit>~~what's happening~~ what people are doing</edit> here.
- dwedge 4mo ago
  I disagree. Look at the number of recent contributions compared to the past few years, and given AI being everywhere it's reasonable to expect that it might have been directly caused by AI. In the thread someone found the bug and it was AI generated. But even if in this case it wasn't, if the introduction of AI and bugs are correlated it's a problem even if not every bug is caused by this. Stability everywhere seems to be getting worse, we have supply chain attacks everywhere, and if the bar for stopping this is throwing out 40,000 lines of generated code and shouting "show me the evidence" for each instability, then it's time to wonder what "maintainer" means if they are no longer the ones responsible for it. Of course the report was engagement bait, but it's useful. Before this I was not aware that I need to wonder about rsync updates and now I am. It was one of my most trusted pieces of software, and now it's not.
- lioeters 4mo ago
  > low quality AI slop that causes bugs That's exactly what's happening here. The tone of the issue was immature, but there is a legitimate problem that cannot be brushed away as "anti-AI". The real issue is the irresponsible use of buggy machine-generated code in a project that many people depend on. Users are pissed and rightly so.
smetj 4mo ago
I guess the people not complaining here are the ones who do not immediately upgrade production to latest non-security releases?
zbentley 4mo ago
Did anyone in that issue thread ever … describe an issue? As in steps-to-reproduce, expected vs. observed behavior, all that? Like, this was posted on an issue tracker. “Your commit messages reference Claude and some guy on bluesky thinks some unspecified issue he had is related to those commits” is not an actionable issue. All the rest of the discussion aside, if this were my project I would close and lock with “not enough info to reproduce”. There are better places for general discussion about AI and forking and emitting rage.
- newtonsmethod 4mo ago
  Yes, the actual issues seem to be: * People with linux < 5.6 can't build this from GitHub. This to me seems like a fairly minor regression: people using maintained versions of 5.6 (mostly extended security) will have distro maintainers pick up that the build is failing, allowing for it to be corrected in a timely manner. * Hardening against path-traversals causes failures for users with: no chroot; using the native rsync protocol. Ironically: chroot = no is deeply discouraged; you shouldn't really be using native rsync in an automated manner (and perhaps it seems I wouldn't advise using it at all); the CVEs the commits fix apply exactly to this use case. https://www.cve.org/CVERecord?id=CVE-2026-29518 https://www.cve.org/CVERecord?id=CVE-2026-29518 Requires daemon + no chroot. " daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false." So the workflows affected are those which are the most vulnerable, and yet people are recommending that people revert versions. * Furthermore, if a regression test picked this up, it would've been written previously.
RCitronsBroker 4mo ago
i gave up reading this after laughing my ass off at the israel rebuttal, very funny though.
pacifika 4mo ago
Reminds of the days when windows and macs folks were debating each other, made it impossible to announce Mac software on a software forum with windows users. The significant thing that will result from this is private issue lists and disabling open PRs. and then you’re worse off as an ai sceptic.
DonsDiscountGas 4mo ago
I feel really bad for anybody out there named Claude. Especially if they're a software developer.
mhh__ 4mo ago
So I think one of the main failure modes of vibe coding is that unless you have a very aggressive approach the onus is pretty much solely on the developer for the code to be good. The volume of code, addiction to said volume of code, and fact that the vibe coder may not have read it basically makes review impossible both logistically and in that IME it seems to upset the vibe coder to even suggest that it's fine to take a bit longer and do something good as opposed to some overfit mess. It might be that we look back on this as like trying to review the assembly output of a compiler but I don't see it that way at the moment.
poolnoodle 4mo ago
My god, the stupidity on display.
daishi55 4mo ago
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), but you see the witch-hunts every day online and as with all witch-hunts it really doesn’t matter whether the accusation is true. The hysteria is the point.
- hall0ween 4mo ago
  It’s tough to take your response seriously with loose thinking like “The point is the almost sexual release you get from (2).” Upon further reading, you use emotional language too - “witch-hunt” and “hysteria”. Are these witch-hunts? And can you tell if people over the internet are nearing sexual release? Are you responding to emotional language and other’s loose thinking with your own?
  - daishi55 4mo ago
    [flagged]
    - customguy 4mo ago
      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 easy targets, it just seems like projection to me. You declare the critics as witches that don't even get to make their own case, your high level smearing of them totally suffices.
      - daishi55 4mo ago
        > they are just looking for easy targets 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?
ewy1 4mo ago
i hate it when people i agree with act unhinged
shantnutiwari 4mo ago
I'll bring my pop corn to the comments section... Until then: It's interesting to see curl vs rsync in this space. Both have been hit by AI bots (or attempts to write/debug code by llm or raise llm bugs), but its interesting to see how the curl maintainer handled this vs how rsync is being affected.
melchebo 4mo ago
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 https://github.com/RsyncProject/rsync/commit/30656c5e Someone using AI to bisect recent rsync. https://github.com/themgt/rsync-compare-link-dest-341-343-regression 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 https://github.com/RsyncProject/rsync/pull/930 Related ticket: https://github.com/RsyncProject/rsync/issues/915 https://github.com/RsyncProject/rsync/issues/915 I'd recommend putting in more regression testing in the commit before 30656c5e, and rebase it forward while keeping functionality.
- rstuart4133 4mo ago
  That makes the original complaint look, well just plain wrong. 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.
mylons 4mo ago
the entitlement people have towards free, open source software, is incredible. this isn’t even a “new” problem. if you were around in the early 00s or before you probably worked with a BOfH sys admin that didn’t let you update system packages. that person cared deeply about system integrity and enforced it with policies around package managers. having outsourced all of that stuff over the years to the cloud, it seems like people forgot this reality existed and can still exist. the mob freak out is really a projection of a skill issue and it’s sad.
Kim_Bruning 4mo ago
This is brigading and it is not ok. It doesn't matter what the hot-button-topic-du-jour is. Oil? Think of the children? AI? Doesn't matter, they get to vent rage on a random subject at a Random Person On The Internet. I don't know what sets this kind of thing off, maybe it's not predictable, but it's never ok. I'd like to hope in a few years those people will look back on their participation in this particular brigade sheepishly; but sadly it's more likely they'll have forgotten about it by morning.
megamindbrian2 4mo ago
[dead]
socratic_weeb 4mo ago
Beware: AI is a fanatical cult here on HN
zzo38computer 4mo ago
My opinion is that they should not use AI/LLMs to program this, but I think this is not the proper way to make a bug report (and that the use of AI/LLMs is not necessarily itself a bug, even though I do have concerns and objections about their use). They should post the text directly rather than a picture of the text, and it (and the issue title) should describe what is not working in the correct details (in this case, they do provide a few details; it says incremental backups are not working correctly when using multiple --compare-dest= arguments, and it mentions which version does work). If they are also opposed to using AI/LLMs to program this, then they can mention that as well, but by itself it is not a proper bug report; they have to indicate what (if anything) is wrong with it (whether or not they used AI/LLMs to program it).
- newtonsmethod 4mo ago
  I don't actually see much evidence the usage of AI here was an issue. I think you can obviously identify areas where the code isn't perfect. I'd blame this slightly on human prompting, slightly on AI. But I'm not a sure a human on their own would've done better. There aren't enough resources to make the changes required.
YikiYiki 4mo ago
open source just means 'open the source code of the software', not maintaining and other stuff
jasonvorhe 4mo ago
You obviously don't have to use LLMs to get some kind of psychosis or derangement syndrome associated with it. Brainrot everywhere.
mizzao 4mo ago
Seems like a good reminder of https://xkcd.com/2347/ https://xkcd.com/2347/
cirelli94 4mo ago
The maintainer answer: https://github.com/RsyncProject/rsync/issues/929#issuecomment-4589128729 https://github.com/RsyncProject/rsync/issues/929#issuecommen...

553 points by justdotJS 4mo ago

nickdothutton 4mo ago

Torture testing required before acceptance of vibed/AI submissions?

freakynit 4mo ago

[flagged]

akerl_ 4mo ago
Are they? I've read them and they mostly just made me feel like shit. The amount of drive-by hate being thrown at project maintainers of an open source project is depressing.
- asp_hornet 4mo ago
  I guess both things can be true. Make you feel horrible and the reality of open source sometimes.
drdrey 4mo ago
Counterpoint: don't read the comments
cpard 4mo ago
The comments are definitely not worth reading. It’s a very sad thread, you literally had to go through all of them to find one that wasn’t about hate and stating some facts about the issues of the code.
- wjnc 4mo ago
  I found them worth reading for the following set of thoughts came up: - programmers had problems with delivering quality long before LLM’s - very much research and tools went into that, bringing us {Git, libraries, VSCode, reviews, …,} but the human factor stayed the same (and more pronounced imho than in other fields of engineering) - LLMs democratized programming, enhancing a few, dropping the bottom to no skill programming - the tools and practices created for the quality problems from the past turn out to be wholly incapable of maintaining quality in the present The main problem behind this is that those delivering the QA tools of the past are central in the AI race. Old school engineering would separate these concerns.
butterlesstoast 4mo ago
The bread shop analogy made my year
themafia 4mo ago
People are saying they detect a lot of "hate" in these comments which I don't see or agree with at all. People clearly have negative opinions about this and they're expressing them rather openly but to confuse this with actual "personal hate" seems like an equally overcharged response. When you do anything publicly, even something that's considered a 'public good' like contributing to open source, you are opening yourself to the full tide of humanity for better or for worse. The overwhelming majority of the time it's for the better, occasionally, and in response to unpopular decisions, it's for worse. What you shouldn't do is take any of this personally. It's open source. You have permission to take a break, you have permission to directly ignore issues and users, you have permission to do whatever makes _you_ happy. If your goal is to receive unremitting love and adoration from a crowd of strangers then you're going to be bitterly disappointed... no matter how you occupy yourself.

magarnicle 4mo ago

Aww, but I have such big plans for it!

rsyring 4mo ago

> 26k code changes in 2 months..... rsync was 67k LOC as of 236417c (latest not obviously vibecoded commit it seems?).[1] Wow. 1: https://github.com/RsyncProject/rsync/issues/929#issuecomment-4585065320 https://github.com/RsyncProject/rsync/issues/929#issuecommen...

scared_together 4mo ago
When I look at the commits themselves, most of the ones generated by Claude are testsuite changes, or at least labelled as such. https://github.com/RsyncProject/rsync/commits/master/ https://github.com/RsyncProject/rsync/commits/master/
- shimman 4mo ago
  Is that suppose to make this better? IME the most valuable tests are those that test specific regressions. It's the scaffolding we build for ourselves to enable feature development. Remove that scaffolding and you get accidents. Pray to your god of choice these accidents don't cause harm or loss of life. It should really be considered negligence at this point. Some of this software is extremely valuable, it's how we flourish as humans. Purposely fucking with that should bear some real world consequence. We do the same in every other industry, software is just as important too.
  - abuob 4mo ago
    In my perspective, "Analyze code, come up with edge cases and gaps and create unit tests for them" is one of the use-cases where AI was starting to get really good at, so I can see why someone would want to extend their test-suite dramatically using it. But yes, using AI to then generate code that still causes regressions doesn't quite square with that. Given the huge amount of test-changes I'd still assume good faith by the maintainer; possibly just a bit of overexcitement paired with a dash of too much confidence into the new tools that is now hitting reality.
  - ornornor 4mo ago
    I hear you, OTOH if this software was so valuable how come we aren’t funding it? A lot of the world runs on OSS with a coupe overwhelmed maintainers who get treated as if they owed everybody working software yet can’t make a living off it.

dnnddidiej 4mo ago

[flagged]

bfkwlfkjf 4mo ago
If I were a user, knowing that the maintainers just let Claude lose on rsync would be bad for my stress levels. In any case, I hate rsync owing to how easy it is to accidentally deleting everything. From my pov I don't care if it disappears.
- bathtub365 4mo ago
  Then I have bad news for you about a large chunk of both open and closed source development today. We also don’t know if it was “unleashed”. Claude will add a co-author line to your commit even if you just ask it to author or touch up your commit message or clean up your branch’s commit history or any of a number of things that result in the creation of a commit, even if it touched none of the code. This functionality actually saves me a ton of time and results in higher quality commit structure and messages. Has this specific issue actually been tied to misuse of Claude?
- egeozcan 4mo ago
  > If I were a user, knowing that the maintainers just let Claude lose on rsync would be bad for my stress levels. I think you are being too entitled.

krackers 4mo ago

Hm good timing with https://news.ycombinator.com/item?id=48334854 https://news.ycombinator.com/item?id=48334854 (OpenRsync)

em-bee 4mo ago
i suspect that post was made in reaction to the first AI/rsync post: https://news.ycombinator.com/item?id=48334021 https://news.ycombinator.com/item?id=48334021 , as i believe was this post too.
exe34 4mo ago
is this considered safe? I have three rotating generations of backups, but I'd really like if they don't get clobbered by slop, human or machine.

theonemind 4mo ago

I find the way that issue was opened incredible obnoxious, but it is baffling that the maintainers seem to have let AI loose on rsync. Like, why? Why try comparatively experimental crap when your fortune and reputation is made and you're the leader of a niche and immune to market pressure and the people love the thing and it does exactly what it's supposed to and works well? It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling. And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.

roenxi 4mo ago
Are you basing this opinion on the issue or actual evidence? Because this github link, although interesting, is almost completely context free on what the drama is beyond "Claude". The rsync maintainers could be anywhere on the spectrum from the perfect and responsible maintainer to incompetent children and we couldn't really tell.
- xiphias2 4mo ago
  The problem is the we couldn’t really tell part. Changes made to mature finished projects should be minimal and readable and understandable by humans. Also rsync is handling copying binary data, it’s a project that’s super sensitive to hardware faults for example, which means it’s not just enough for the tests to pass.
  - throwaway7356 4mo ago
    > finished projects rsync is not a finished project: it has hundreds of open issues (bugs, feature requests, ...). "Finished projects" are a mythical thing that rarely exists in reality and even less in actually used software like rsync or the Linux kernel.
- bulbar 4mo ago
  To me it seems people had actual problems with newer versions. Additionally, a significant portion of the code changed within a very short time frame. Doesn't matter if they did it by hand or with AI.

impure 4mo ago

Oh no, not Rsync. I guess that's one good thing about MacOS shipping with an ancient version of rsync. Oh, wait, they ship openrsync now, but the command is still called rsync.

jochem9 4mo ago

This is the third HN post I read on this topic. Everytime the same tweet (or whatever it's called for mastodon/bluesky/etc). Did anyone actually debug the issue? Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?

cwillu 4mo ago
https://github.com/RsyncProject/rsync/issues/929#issuecomment-4585695638 https://github.com/RsyncProject/rsync/issues/929#issuecommen... has a partial list
- Lerc 4mo ago
  That is a list of problems, not causes, which is what was being asked for. It's possible it's some LLM randomness that caused bugs. That would suggest that some AI hygiene is in order. If it is because of behaviour changes necessary to fix security issues, then the regressions might be from things that relied on unsafe features. Do we know of actual specific causes yet?
  - adrian17 4mo ago
    Yesterday's comment listed suspected commits alongside the issues: https://news.ycombinator.com/item?id=48334270 https://news.ycombinator.com/item?id=48334270
JdeBP 4mo ago
It's called a post, the same as you used for Hacker News. And yes, I debugged one of the issues. I made the second comment in one of them. Markus Mayer did some debugging, too. Then I had to deal with something completely unrelated to computers for the rest of that day and several days thereafter, and came back to this. The problem with compiling code that used new kernel features was a bit poorly done. Anyone with any experience knows that a simple #if defined(__linux__) , which is a platform test, does not cut it for feature testing. M. Mayer went with an autotools test, which is what I'd have done too. The problem with the on-the-wire protocol is a tricky one, and caused by suddenly being conservative in what rsync accepts apparently without much testing of what out-of-range stuff in-the-wild rsync sends.

z3t4 4mo ago

Few things can trigger me more then finding a bug/regression and when tracking it down the commit reads like "modernizing the code", replacing all var with let, etc.

ornornor 4mo ago
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)
- z3t4 4mo ago
  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 you wake up next morning and it's -10 C outside. Your house is now pink, you are cold, and nothing has improved. Next week another team comes by and offers to repaint your house for free... They say orange is the new pink.
  - Sacho 4mo ago
    > 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.

vsgherzi 4mo ago

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

Hendrikto 4mo ago
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 this.
- brabel 4mo ago
  What the hell why are you thinking you decide anything?? The man has his project and can do whatever he wants with it. Read the license.
  - bakugo 4mo ago
    Yes, he is free to do whatever he wants with it. And others are also free to say that what he's doing is bad and is causing them problems when trying to use this well established software that is known for being stable and reliable.
  - baobabKoodaa 4mo ago
    Freedom of speech goes both ways, not just the way you like.
- throwaway7356 4mo ago
  > Rsync was complete software. It was (and is) not: rsync has over 300 open issues with bugs and feature requests.
  - 4mo ago

sixhobbits 4mo ago

[dead]

himata4113 4mo ago

previous convo: https://news.ycombinator.com/item?id=48334021 https://news.ycombinator.com/item?id=48334021, has my comment so won't repeat myself.

koehler 4mo ago

I truly don't get it You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes. Why do we need AI here? And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched. What I have to do now, keep a fork of my entire system's toolkit?

nottorp 4mo ago
> Why is there a need of AI in here? For the same reason as some people would rewrite it in Rust.
- mike_hock 4mo ago
  No, that's usually to decrease the number of bugs and vulnerabilities.
  - lelanthran 4mo ago
    That's not why people rewrite in Rust. Rewrites brings new bugs regardless of the language.
    - Matl 4mo ago
      You're conflating why people want to rewrite it in Rust vs what is the likely end result i.e. I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs especially because there's been almost no meaningful improvement in this space for a long time. But of course in the short term it will mean regressions compared to the established C written version. That is different from AI where the calculus seems to be that if AI isn't involved, it aien't relevant.
      - lelanthran 4mo ago
        > I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs I don't believe that anymore - if that were true, the large portion of code now being rewritten in Rust wouldn't be vibe-coded slop. I'd be more willing to believe that "quality" was the reason if those doing the rewrite weren't fucking vibing everything!

m1keil 4mo ago

[flagged]

egeozcan 4mo ago
Comments in Github were usually horrible, but the AI stuff brought extra divisiveness. yt-dlp stops supporting bun because they call the rust rewrite a risk -> hate comments. rsync fixes security issues and gets some help from AI -> someone finds a bug and... hate comments. Poor maintainers. Crazy.
deleted 4mo ago
[deleted]
throwaway2027 4mo ago
"Cheap clients pay the least and complain the most."

relistan 4mo ago

Hacker News: “It’s unfair the burden put on maintainers of the core pillars of open source software. Show some respect for the maintainers, and do your best to contribute.” … little changes … Also Hacker News: “I have the right to tell you how to manage the project that you created and have maintained for 30+ years, because I feel very self-righteous about AI and code quality!”

marginalia_nu 4mo ago
As HN consists of more than two people, it is home to multiple contradictory opinions. Furthermore, both points may be valid. As a user you might want working software, and as an open source maintainer, you aren't beholden to what the users want.
- relistan 4mo ago
  Sure, but you cannot deny the hypocritical swarm behavior, which is the point.
  - marginalia_nu 4mo ago
    The "swarm behavior" is mostly an illusion created by your mind. HN is just a bunch of people and bots.
    - relistan 4mo ago
      Yep a bunch of people who often exhibit swarm behavior.
      - cyclopeanutopia 4mo ago
        By this logic, will you just start calling yourself "hypocritical Karl", as you clearly belong here? ;)
        relistan 4mo ago

GalaxyNova 4mo ago

What's next? Vibe coded coreutils?

akoboldfrying 4mo ago
Funny you should say that. The latest Ubuntu reimplemented coreutils in Rust, introducing a bunch of TOCTOU bugs. TTBOMK the reimplementation was done by humans, but the overall principle still applies I think.
- ornornor 4mo ago
  I think TTBOMK = to the best of my knowledge, for TOUWANFIA (those of us who are not fluent in acronyms)
  - r_lee 4mo ago
    IGIN! (I get it now)

kjellsbells 4mo ago

I sure would hate to be a human developer named Claude right now. You wouldnt get credit for anything and every problem would be laid at your feet.

deleted 4mo ago
[deleted]
GCUMstlyHarmls 4mo ago
On the plus side, the CTO, CEO and CFO all know you by name now.

simianwords 4mo ago

I get the feeling that the GitHub issue space is used to wage some ideological warfare. It’s interesting to see how all this is panning and out how it would look like in the future. This tech is going absolutely nowhere.

akoboldfrying 4mo ago

Nobody whose software you use for free owes you anything. It is so important not to lose sight of this. If you feel like they do owe you something, that's only because years of habit -- years of using other people's software for free, and having the good fortune of finding it generally to improve in quality over time -- has caused your baseline to drift from the true state of affairs, which is that nobody whose software you use for free owes you anything.

ianbutler 4mo ago
People here hate hearing this. You're entirely correct though.
tardedmeme 4mo ago
Indeed you can step down, but as one of the comments says: > Just because you're giving free soup to the homeless doesn't mean you can piss in it
- deleted 4mo ago
  [deleted]
- DonsDiscountGas 4mo ago
  Okay but if shipping software that has a bug counts as pissing in soup then a lot of people have been doing this for a long time.
  - saghm 4mo ago
    Honestly if this is the metric, I'm not sure anyone has ever made piss-free soup
    - jason_oster 4mo ago
      You best start believing in piss-soup stories. You're in one!
  - bigstrat2003 4mo ago

christkv 4mo ago

Can GitHub add a tag to repositories that says "probably vibe coded" or "ai code detected"

0123456789ABCDE 4mo ago
would you argue for an 'unsafe code' tag too, if it's attached to repos with C/C++?
- cyclopeanutopia 4mo ago
  So all the other languages are safe now?
  - 0123456789ABCDE 4mo ago
    is that what i wrote?
    - LtWorf 4mo ago
      Then not why tag all of them?
- christkv 4mo ago
  Would have to be on all repositories I think.
  - 0123456789ABCDE 4mo ago
    you're not required to include code in your repos, some are just a collection of markdown files. those could be considered unsafe, but they're not code. but i think you meant: tag all code repos as unsafe, because you assume all code is unsafe, and 1. i don't fully agree with that, and 2. that's half of my argument. 1. historically most languages bootstrapped their compilers with one of those, some eventually reaching the selfhosted milestone (ex: https://go.dev/doc/go1.5#implementation https://go.dev/doc/go1.5#implementation). 2. tagging repos with `unsafe code`, or if you prefer to stay with original `maybe vibes` tag, implies you have some level of confidence in the tag you are applying, and that you also can back that tag with some common understanding of its meaning. i do not think we have established what `vibed` or `ai coded` actually means. some know what their personal definition is, but it is not a shared understanding of the definition. as matter of non-exhaustive sampling we currently have vibe coded and ai code, ai co-authored and ai completions/suggestions, and ai aided. which one should be picked? nevermind the term ai is fuzzy, but how do you even begin the process of classification? a process that by it self, is likely to use more of the dreaded ai technology. where would github draw the line for this tag, such that it avoids backlash from users? pick your broad strokes: llm generated with no human revision; llm generated with human revision; llm wrote large parts of the change set, but a human made adjustments; lm generated small snippets — implying the contributor accepted the suggestions, llm aided with codebase understanding (RAG); lm picked symbol completion and types; ml model used for refactoring suggestions. for github the question† is: what is important for a user that sees this tag? what does the user care for? how does that affect their decision process when considering using, or participating in a project. there are much more interesting questions, than wether a repo accepts vibe coded contributions, still not easily answered. show me: total lines of code, or a ranking per language (only a percentage is currently displayed), code complexity stats, code churn, merged pull-requests vs total pull-requests, avg reviewers per pull-request, merge pull-request non-members vs members, mtt member reply on issues, mtt member reply/action on pull-requests, or split that between merged and non-merged pull-requests † also github has been absorbed into a large proponent of ai, microsoft

hugodan 4mo ago

Just use openrsync instead. And OpenBSD for that matter. There goes the bazar…

kdjkskdndn 4mo ago
Dude ssshhhhhhhhhhhh next thing systemd will come for openbsd...

contingencies 4mo ago

[flagged]

sciolist 4mo ago

When commenting, please assume good faith (in other commenters and maintainers). This is the third thread I've read on HN about the subject and I've sadly seen a lot of closeminded or shallow comments on each thread. Adding the above reminder, as I hope HN can engage in more thoughtful discussion.

DonsDiscountGas 4mo ago
One should assume good faith at first, or when in doubt, but after a certain point it's just denial.

21asdffdsa12 4mo ago

[flagged]

foldr 4mo ago
On the contrary: it's the people posting unhinged comments on an issue tracker that will be rushing to delete them in the years to come.

michaelmrose 4mo ago

This entire post doesn't belong here other than as a cautionary tale. Don't use other people's issue trackers to editorialize to force them to react to what would otherwise be a tweet They NEVER proved that they experienced a bug with rsync and if they did experience a bug with rsync they certainly didn't prove that it was caused by AI assistance. This useful research would have required real work. Their language and methodology of communication is abominable. Lest we forget the "crime" of the developer is providing for free something so useful that it became integral the the users workflow for years then potentially shipping a buggy version. People who labor for free for us deserve our thanks not our contempt.

throwaway2027 4mo ago

AI for me but not for thee.

croes 4mo ago

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.

LtWorf 4mo ago
> vibe code isn’t a problem if properly reviewed 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.

llbbdd 4mo ago

Crazy to watch the death of open source happen in real time like this. Why would anyone share any code to open themselves up for all of these wannabe main characters to pile on them? Given the choice I'd rather have a bunch of slop coded PR contributions to wade through than whatever this entitled nightmare raider thread is.

m132 4mo ago

Wow. Rsync has to be one of the worst spaghetti projects I've worked with. It's an incredibly decent tool built around a well-though out algorithm, but its code is an exact opposite of what you'd expect. And it's written in C. I'm not surprised letting Claude loose on it for roughly 2 months already caused visible breakage. The question is, with it being very obviously a bad idea, can the maintainer still be trusted if he let something like this happen?

eloisant 4mo ago

Is there any evidence this was broken by AI? I feel like these day any time users find an issue in software they blame it on "vibe coding". But software had bugs before AI.

reliablereason 4mo ago
The issue is apparently this commit (someone did a git bisect): https://github.com/RsyncProject/rsync/commit/859d44fa4f1420775e4ba050337ef32092f2894c https://github.com/RsyncProject/rsync/commit/859d44fa4f14207... Which is a fix to the security issue CVE-2026-29518: https://nvd.nist.gov/vuln/detail/CVE-2026-29518 https://nvd.nist.gov/vuln/detail/CVE-2026-29518 A CVE reported by VulnCheck which is a company that uses AI to find software vulnerabilitys. I would honestly blame this on bad test coverage. If you look at most of the commits where Claude is "co-author" you see that 80% of are just adding new tests. Which is exactly what would be needed if low test coverage was the issue. I have done the exact same thing long before AI was a thing. You are rushed to "FIX" some security issue that someone reported. It is a scenario where you are working in code that you did not write or you wrote it so long ago that you cant remember. You try your best to just fix the security issue but you perturb something else while doing it.
- nbaugh1 4mo ago
  This doesn’t even 100% mean that the code was generated using Claude, only really means the commit message was. Write some code and then ask Claude to diff your changes and write a commit message. Now the internet hates you
- deleted 4mo ago
  [deleted]

alkonaut 4mo ago

Would be interesting to know what exactly went wrong. How obvious was the mistake? How necessary was the change? What is wrong with the test suite that didn’t capture it?

vinyl7 4mo ago
What went wrong is using LLM generated code

SideburnsOfDoom 4mo ago

It seems that the person who opened this issue has a real and relevant point. But neither the original post nor the majority of the responses are productive, mostly due to the acrimonious language used.

rawoke083600 4mo ago

Been thinking of this mental model held by some "oh ai coding is always bad etc etc" (fair we all allowed opinions). But why are we okey with colleagues making from time to time terrible blunders (hey we all human ). But when ai makes mistakes its a sweeping judgment of "oh ai coding is terrible". We seen to not include all the amazing code they do right and security bugs they do find.. I feel if it was a human or colleague we be more fair with its failure and balance about his/her achievements also. Just a thought.ymmv

consp 4mo ago
When LLMs make mistakes, it is still the human making the mistake of trusting the LLM. And more often than not "AI" is hailed as costing no effort and being perfect in every way (yes exaggerated), which you can attack when it obviously is going to fail at some point.
sureglymop 4mo ago
Because AI can't take responsibility. Humans can. A human can not only learn from their mistakes and blunders but also, until very recently, the social pressure and fear of judgement would push (some) humans to try their best. Now however, it is less socially acceptable to judge a human for mistakes made with AI coding because we are in a time of experimentation. So the blame has to go towards AI coding. Of course, coding with AI can be acceptable, if the human using the AI is rational and responsible. But I think the bigger implicit point is actually that perhaps experimentation shouldn't be done on real projects and products as nonchalantly.
matt3210 4mo ago
AI mistakes are due to pure laziness and incompetence that appears well done. There’s a big difference between that and a genuine mistake from a knowledgeable person.
- rawoke083600 4mo ago
  Lol what ??

Ozzie-D 4mo ago

[flagged]

matt3210 4mo ago

When people realize the AI doesn’t work in the long run we can have a mass revert party

afshinmeh 4mo ago

Genuinely wondering though: is the problem that the patch was vibe coded, or is that no one reviewed the changes?

bakugo 4mo ago
"Vibe coding" implies the changes weren't reviewed. That's the most common definition of the term. Even if the developer himself didn't say that, though, it's safe to assume no AI generated commit beyond a very small size is ever properly reviewed (in the sense that the entire code is actually understood) because doing so would take longer than actually writing the code by hand like a caveman.
deleted 4mo ago
[deleted]

thevinter 4mo ago

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 this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing, seemingly forgetting that before AI people did mistakes as well. If you have proof that AI involvement in rsync has lead to a significant increase in open issues please show it to me - I'll be happy to change my mind.

consp 4mo ago
> I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing It's not silly to have issues with something. People act on their issues. Possibly not the issue underlying the commit at hand here but something else, and act on it which makes it something to consider. My guess is people are tired of the "AI is the greatest thing since [cultural reference]" being forced down their throat and grasp at every straw to combat it, which is a sane response in my opinion and should be taken into account.
- thevinter 4mo ago
  > It's not silly to have issues with something. I absolutely understand and agree. As I said, I understand the underlying reason. The silly part is the brigading - issues should be adressed on their own merits. The specific GH issue, and some of the comments therein, make the whole crowd they're affiliated with look bad. (imho)
  - consp 4mo ago
    I'd argue there would be two lanes as well: one where the issues are addressed in code, the other being the discussion of why people think this is a bad idea and speak so openly about it. This topic is the second I guess. Looking at the flow there is quite a bit of flamebait by the LLM and non-LLM camps which only muddies the water and doesn't resolve anything. The better discussion (imo) would be to decide if the vide coded fixes are worth it and if not, fork the project somewhere and let the distro's chip in to maintain that.

antirez 4mo ago

A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.

cafebabbe 4mo ago
Love that your comment is ambiguous enough to apply to both sides here :)
- antirez 4mo ago
  Nope my comment is against the folks that are criticizing rsync author. Editing the comment to make it more clear, thanks.
weiliddat 4mo ago
Maybe I'm getting too skeptical. I have a feeling increasingly many of the comments on HN and the GitHub issue are just bots ragebaiting other people (incl. the maintainer)...
- rf15 4mo ago
  [flagged]
  - weiliddat 4mo ago
    I'm not sure how to interpret your comment. It could be - a response to my comment saying that I am "illiterate" and cannot differentiate LLM output vs actual human comments (in that case I'm not sure what you're adding to the discussion here beyond a personal attack) - a general comment saying it's getting harder for people in a position similar to us (i.e. tech / tech-adjacent who interact a lot with others who write with LLM assistance or via LLMs) to differentiate human/AI output. I'll assume good faith and you mean the second. In that case maybe you can explain the "fundamental problem" you're referring to?

RustyRussell 4mo ago

I'm shocked that people are jumping on one of the most productive and powerful OSS maintainers in existence. The actual Claude "churn" is mainly test suite enhancement.

deleted 4mo ago
[deleted]
nuclearpidgeon 4mo ago
One of the most reliable OSS sync/backup tools on the planet for 2+ decades broke under people's daily backup use of it because of a large pile of LLM-driven changes basically out of nowhere from the project maintainer in a minor point release. I think they're right to be annoyed and to complain about it. Whilst a lot of the Claude changes are test related, there were still other changes that obviously broke things for people - and who's to say that some of the testing changes may not have thinned out the testing too given one commit "rewrote all shell tests in python" with over 4000 lines added and removed at once. And even after all that Claude churn on the testing, these breaking changes obviously weren't caught by tests, so it's not exactly an "enhancement" from the end user perspective.
- ilikehurdles 4mo ago
  It has broken many times before. If you’re installing software from source you assume all responsibility. Go use Debian if you don’t want to deal with breakage.
  - izacus 4mo ago
    Just because you got shat on the head once it doesn't mean it's fine to be shat on the head every day now.
    - deleted 4mo ago
      [deleted]
    - newtonsmethod 4mo ago

KolmogorovComp 4mo ago

Seem to me some people have forgotten about FOSS projects > 15. Disclaimer of Warranty. > THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

latexr 4mo ago
“No warranty” isn’t the same as “no complaints”. Otherwise there wouldn’t be an issue tracker and a discussions section. The issue in question has already gone to crap and your point has been made there as well. It could definitely have been handled better, by all parties involved, but blindly quoting legalese isn’t going to resolve anything or make it better.
- KolmogorovComp 4mo ago
  An Issue tracker is to track issues regarding the behaviour of the program, not the behaviour of the maintainer.
  - layer8 4mo ago
    If issues with the program are caused by behavior of the maintainer, it doesn’t seem inappropriate.
  - latexr 4mo ago
    And focusing on that after the fact does nothing to resolve the situation or advance the discussion, which should be the goal now. During an emergency situation where an issue is running out of control, the priority is to evaluate and contain the problem then address it, it is not the time to assign blame and quote regulations which weren’t followed. That’s for later, when everything is stable, together with understanding why the rules weren’t followed and if you can improve that process for the future.

irusensei 4mo ago

As much as I would love to see Anthropic going down in flames I think that developer doesn’t deserve to be targeted by such a low effort social media farming post. I am nothing but grateful for Samba and Rsync.

redsocksfan45 4mo ago

[dead]

abc123abc123 4mo ago

Jesus Christ... this anti-AI thing is getting ridiculous. If the code is good, bug free, and easily understood, who the f*ck cares? If a maintainer just accepts any code, without review or control, humans, just as well as "AI:s" can submit crappy code. I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.

Symbiote 4mo ago
The code obviously isn't bug-free as several issues were identified. It's also not easily understood, as there are multi-thousand-line AI-generated commits.
latexr 4mo ago
> If the code is good, bug free, and easily understood The whole point here is that it wasn’t. That’s the whole reason the submission exists, that allegedly bugs were introduced where it was previously working. > I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious. Be careful with assumptions. You are basically expressing that the people you disagree with have petty negative reasons to think how they do. That’s not empathetic and it’s colossally misinformed. I recommend you attempt a good faith search of the myriad reasons people may be against LLMs. Here’s a good faith question on HN to start: https://news.ycombinator.com/item?id=48172574 https://news.ycombinator.com/item?id=48172574
- newtonsmethod 4mo ago
  Can you tell me any of the bugs? All claims I have seen so far of people being affected by bugs seem deeply implausible. The current ones I see are: * Can't build on Linux < 5.6. But people aren't complaining strongly about this, since it requires a build from source / isn't a result of an update from a distribution (and people can wait for updates / implement them themselves). * An issue hit with chroot false + daemon. People running this in an automated manner (as some claims suggest) are already using it in a way fairly likely to be insecure, chroot false is strongly discouraged here, and the whole point of these commits was that they fixed CVEs impacting precisely these people.

veyh 4mo ago

This could be an opportunity for another xz-utils incident.

comrade1234 4mo ago

I'm pretty dependent on rsync across all of my ubuntu servers. I just checked and most of my servers are on openrsync but one, built most recently, is on classic rsync. Not sure why the old servers are openrsync and the new one on classic rsync - I would expect the opposite. Anyway, on that one server: sudo apt-mark hold rsync

pacifika 4mo ago
You rather open the server up to security issues than have software where the developer has been assisted by ai which you feel decreases the quality of the code or is it for moral reasons? Rsync is not being vibe coded, and it’s not become slop so would love to understand the position.
- LtWorf 4mo ago
  The integrity of the backups seems uncertain at this point. A backup tool that doesn't do backups properly is less useful than one with a CVE that might be exploited if the stars align.

vova_hn2 4mo ago

Since when github issues became a place to post a screenshot of a post from some other platform? I've seen this behavior before only in places where people post memes and other entertainment content. No actionable bug report/feature request. No text version. Not even a link to the original post. Did the person who posted this mistake GitHub Issues for their personal Twitter account?

mikalauskas 4mo ago
Posting screenshot is the easier way of blocking automatic LLM responses, cause most of the time people use text models without vision as a cheaper solution

basilikum 4mo ago

This is anti-AI slop. Posting a screenshot of someone else's text as an issue is about as low effort as it gets. It's also just a completely random accusation. I experienced a bug; the software contains some amount of AI code; that must be the reason. Because there is no other way bugs are ever made. Bugs only came to life in 2023 with ChatGPT. No need to look at the actual code, see if the bug is in an AI generated part, judge the quality of the code, whether it's just large chunks of AI generated code taken as is or small parts of carefully chosen and moderated code where the AI only does busywork but the maintainer outlines the structure and understands every part of the code. By all means, if rsync is full of low quality AI slop that causes bugs that would otherwise not exist, give some actual evidence for that and criticize it. But that is not <edit>~~what's happening~~ what people are doing</edit> here.

dwedge 4mo ago
I disagree. Look at the number of recent contributions compared to the past few years, and given AI being everywhere it's reasonable to expect that it might have been directly caused by AI. In the thread someone found the bug and it was AI generated. But even if in this case it wasn't, if the introduction of AI and bugs are correlated it's a problem even if not every bug is caused by this. Stability everywhere seems to be getting worse, we have supply chain attacks everywhere, and if the bar for stopping this is throwing out 40,000 lines of generated code and shouting "show me the evidence" for each instability, then it's time to wonder what "maintainer" means if they are no longer the ones responsible for it. Of course the report was engagement bait, but it's useful. Before this I was not aware that I need to wonder about rsync updates and now I am. It was one of my most trusted pieces of software, and now it's not.
lioeters 4mo ago
> low quality AI slop that causes bugs That's exactly what's happening here. The tone of the issue was immature, but there is a legitimate problem that cannot be brushed away as "anti-AI". The real issue is the irresponsible use of buggy machine-generated code in a project that many people depend on. Users are pissed and rightly so.

smetj 4mo ago

I guess the people not complaining here are the ones who do not immediately upgrade production to latest non-security releases?

zbentley 4mo ago

Did anyone in that issue thread ever … describe an issue? As in steps-to-reproduce, expected vs. observed behavior, all that? Like, this was posted on an issue tracker. “Your commit messages reference Claude and some guy on bluesky thinks some unspecified issue he had is related to those commits” is not an actionable issue. All the rest of the discussion aside, if this were my project I would close and lock with “not enough info to reproduce”. There are better places for general discussion about AI and forking and emitting rage.

newtonsmethod 4mo ago
Yes, the actual issues seem to be: * People with linux < 5.6 can't build this from GitHub. This to me seems like a fairly minor regression: people using maintained versions of 5.6 (mostly extended security) will have distro maintainers pick up that the build is failing, allowing for it to be corrected in a timely manner. * Hardening against path-traversals causes failures for users with: no chroot; using the native rsync protocol. Ironically: chroot = no is deeply discouraged; you shouldn't really be using native rsync in an automated manner (and perhaps it seems I wouldn't advise using it at all); the CVEs the commits fix apply exactly to this use case. https://www.cve.org/CVERecord?id=CVE-2026-29518 https://www.cve.org/CVERecord?id=CVE-2026-29518 Requires daemon + no chroot. " daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false." So the workflows affected are those which are the most vulnerable, and yet people are recommending that people revert versions. * Furthermore, if a regression test picked this up, it would've been written previously.

RCitronsBroker 4mo ago

i gave up reading this after laughing my ass off at the israel rebuttal, very funny though.

pacifika 4mo ago

Reminds of the days when windows and macs folks were debating each other, made it impossible to announce Mac software on a software forum with windows users. The significant thing that will result from this is private issue lists and disabling open PRs. and then you’re worse off as an ai sceptic.

DonsDiscountGas 4mo ago

I feel really bad for anybody out there named Claude. Especially if they're a software developer.

mhh__ 4mo ago

So I think one of the main failure modes of vibe coding is that unless you have a very aggressive approach the onus is pretty much solely on the developer for the code to be good. The volume of code, addiction to said volume of code, and fact that the vibe coder may not have read it basically makes review impossible both logistically and in that IME it seems to upset the vibe coder to even suggest that it's fine to take a bit longer and do something good as opposed to some overfit mess. It might be that we look back on this as like trying to review the assembly output of a compiler but I don't see it that way at the moment.

poolnoodle 4mo ago

My god, the stupidity on display.

daishi55 4mo ago

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), but you see the witch-hunts every day online and as with all witch-hunts it really doesn’t matter whether the accusation is true. The hysteria is the point.

hall0ween 4mo ago
It’s tough to take your response seriously with loose thinking like “The point is the almost sexual release you get from (2).” Upon further reading, you use emotional language too - “witch-hunt” and “hysteria”. Are these witch-hunts? And can you tell if people over the internet are nearing sexual release? Are you responding to emotional language and other’s loose thinking with your own?
- daishi55 4mo ago
  [flagged]
  - customguy 4mo ago
    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 easy targets, it just seems like projection to me. You declare the critics as witches that don't even get to make their own case, your high level smearing of them totally suffices.
    - daishi55 4mo ago
      > they are just looking for easy targets 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?

ewy1 4mo ago

i hate it when people i agree with act unhinged

shantnutiwari 4mo ago

I'll bring my pop corn to the comments section... Until then: It's interesting to see curl vs rsync in this space. Both have been hit by AI bots (or attempts to write/debug code by llm or raise llm bugs), but its interesting to see how the curl maintainer handled this vs how rsync is being affected.

melchebo 4mo ago

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 https://github.com/RsyncProject/rsync/commit/30656c5e Someone using AI to bisect recent rsync. https://github.com/themgt/rsync-compare-link-dest-341-343-regression 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 https://github.com/RsyncProject/rsync/pull/930 Related ticket: https://github.com/RsyncProject/rsync/issues/915 https://github.com/RsyncProject/rsync/issues/915 I'd recommend putting in more regression testing in the commit before 30656c5e, and rebase it forward while keeping functionality.

rstuart4133 4mo ago
That makes the original complaint look, well just plain wrong. 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.

mylons 4mo ago

the entitlement people have towards free, open source software, is incredible. this isn’t even a “new” problem. if you were around in the early 00s or before you probably worked with a BOfH sys admin that didn’t let you update system packages. that person cared deeply about system integrity and enforced it with policies around package managers. having outsourced all of that stuff over the years to the cloud, it seems like people forgot this reality existed and can still exist. the mob freak out is really a projection of a skill issue and it’s sad.

Kim_Bruning 4mo ago

This is brigading and it is not ok. It doesn't matter what the hot-button-topic-du-jour is. Oil? Think of the children? AI? Doesn't matter, they get to vent rage on a random subject at a Random Person On The Internet. I don't know what sets this kind of thing off, maybe it's not predictable, but it's never ok. I'd like to hope in a few years those people will look back on their participation in this particular brigade sheepishly; but sadly it's more likely they'll have forgotten about it by morning.

megamindbrian2 4mo ago

[dead]

socratic_weeb 4mo ago

Beware: AI is a fanatical cult here on HN

zzo38computer 4mo ago

My opinion is that they should not use AI/LLMs to program this, but I think this is not the proper way to make a bug report (and that the use of AI/LLMs is not necessarily itself a bug, even though I do have concerns and objections about their use). They should post the text directly rather than a picture of the text, and it (and the issue title) should describe what is not working in the correct details (in this case, they do provide a few details; it says incremental backups are not working correctly when using multiple --compare-dest= arguments, and it mentions which version does work). If they are also opposed to using AI/LLMs to program this, then they can mention that as well, but by itself it is not a proper bug report; they have to indicate what (if anything) is wrong with it (whether or not they used AI/LLMs to program it).

newtonsmethod 4mo ago
I don't actually see much evidence the usage of AI here was an issue. I think you can obviously identify areas where the code isn't perfect. I'd blame this slightly on human prompting, slightly on AI. But I'm not a sure a human on their own would've done better. There aren't enough resources to make the changes required.

YikiYiki 4mo ago

open source just means 'open the source code of the software', not maintaining and other stuff

jasonvorhe 4mo ago

You obviously don't have to use LLMs to get some kind of psychosis or derangement syndrome associated with it. Brainrot everywhere.

mizzao 4mo ago

Seems like a good reminder of https://xkcd.com/2347/ https://xkcd.com/2347/

cirelli94 4mo ago

The maintainer answer: https://github.com/RsyncProject/rsync/issues/929#issuecomment-4589128729 https://github.com/RsyncProject/rsync/issues/929#issuecommen...