5 ms·

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

by roenxi 5mo 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 5mo 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 5mo 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 5mo 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.
- seba_dos1 5mo ago
  I just had the first case of a file not being copied correctly after using rsync that I noticed a few days ago. It was a raw image file so it was visually noticeable, some lines of pixels just went black. It may be unrelated, it may not have even been rsync's fault, but this drama and timing just makes me wonder if I got clauded there.
  - Npovview 5mo ago
    Do you not do the md5 or sha hashes of the copied zip file?
    - zimpenfish 5mo ago
      That's ... what rsync is supposed to do for you.
    - seba_dos1 5mo ago
      zip file?... I was syncing photos from my phone.
  - pmarreck 5mo ago
    Related: I'm writing a file-format validator whose first focus is on image data. https://validate.pics https://validate.pics Also related: I'm using LLM assistance to write it, but I also have a test suite that proves it's working (I call it the "shotgun" suite: given a good image file, it first flips a random bit ("sniper"), then a random byte ("boltgun") and then a random 4096 byte segment which is the typical sector size ("shotgun"); each time it tries to validate the file by decoding it fully, and records what percentage of time it is detected at each scope, and it collects statistics about this over hundreds of times.) The point of it is to detect things like corrupt data and bitrot... across 240+ different filetypes so far... since no other tool really exists yet in this space to do that. Note that some formats, notably Apple's HEIC, are so data-dense that corruption only results in undetectable image corruption (well, a human would notice it, but an algorithm cannot!) So I have ANOTHER app coming to help with that which does detection AND repair (to a point). ;) The CLI will be free and open-source, but I'm also writing a for-sale-in-future private-source GUI for it.
nottorp 5mo ago
> is almost completely context free on what the drama is beyond "Claude" As soon as it happened their rsync based backup system that was working before started to fail. It says right there.
- michaelmrose 5mo ago
  The source code is all right there. An actual analysis would involve a complete description of what you were doing including code they are running proving that what you were doing is reasonable and correct and expected to work. An explanation of what actually happened and ideally the exact commit where it stopped working. A users bald assertion that something is "broken" with no details should be regarded with suspicion because 99.9% of the time the user is the cause of their own problems. NOTHING is right there. Nothing whatsoever. No commits no use code no error messages no description. Nothing but dripping contempt for their betters.
  - bakugo 5mo ago
    Why should a random user bother analyzing the code when the "developer" didn't bother doing the same before committing huge chunks of AI generated code? The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair.
    - michaelmrose 5mo ago
      Because they actually want something fixed as a long term user of a software.
    - msm_ 5mo ago
      >the "developer" didn't bother doing the same before committing huge chunks of AI generated code? This is something that you assume, not something that you have any proof of. To put it a bit more strongly, this is something that you (and hundreds of other people in that github thread) made up in your head. The maintainer is a very experienced OS developer and there's no reason to suspect they didn't review the committed code. Bugs happen, and the mere existence of bugs is not a proof that someone is doing a poor job. Assuming those bugs even exist. I am inclined to believe they do, but the issue does a poor job of reporting them. Instead of factually reporting regressions, the "issue" is a screenshot of a viral tweet. Your vicious reaction is not justified, and you should do better in the future. >The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair. It is not fair. The rsync maintainer does not owe you anything. You owe them for using their software. How much did you donate to rsync this year?
kzrdude 5mo ago
We could tell, if someone did independent work of reviewing a sample of the contributions and recent changes (and published in a blog post for example).

by roenxi 5mo ago

xiphias2 5mo 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 5mo 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 5mo 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.

seba_dos1 5mo ago
I just had the first case of a file not being copied correctly after using rsync that I noticed a few days ago. It was a raw image file so it was visually noticeable, some lines of pixels just went black. It may be unrelated, it may not have even been rsync's fault, but this drama and timing just makes me wonder if I got clauded there.
- Npovview 5mo ago
  Do you not do the md5 or sha hashes of the copied zip file?
  - zimpenfish 5mo ago
    That's ... what rsync is supposed to do for you.
  - seba_dos1 5mo ago
    zip file?... I was syncing photos from my phone.
- pmarreck 5mo ago
  Related: I'm writing a file-format validator whose first focus is on image data. https://validate.pics https://validate.pics Also related: I'm using LLM assistance to write it, but I also have a test suite that proves it's working (I call it the "shotgun" suite: given a good image file, it first flips a random bit ("sniper"), then a random byte ("boltgun") and then a random 4096 byte segment which is the typical sector size ("shotgun"); each time it tries to validate the file by decoding it fully, and records what percentage of time it is detected at each scope, and it collects statistics about this over hundreds of times.) The point of it is to detect things like corrupt data and bitrot... across 240+ different filetypes so far... since no other tool really exists yet in this space to do that. Note that some formats, notably Apple's HEIC, are so data-dense that corruption only results in undetectable image corruption (well, a human would notice it, but an algorithm cannot!) So I have ANOTHER app coming to help with that which does detection AND repair (to a point). ;) The CLI will be free and open-source, but I'm also writing a for-sale-in-future private-source GUI for it.

nottorp 5mo ago

> is almost completely context free on what the drama is beyond "Claude" As soon as it happened their rsync based backup system that was working before started to fail. It says right there.

michaelmrose 5mo ago
The source code is all right there. An actual analysis would involve a complete description of what you were doing including code they are running proving that what you were doing is reasonable and correct and expected to work. An explanation of what actually happened and ideally the exact commit where it stopped working. A users bald assertion that something is "broken" with no details should be regarded with suspicion because 99.9% of the time the user is the cause of their own problems. NOTHING is right there. Nothing whatsoever. No commits no use code no error messages no description. Nothing but dripping contempt for their betters.
- bakugo 5mo ago
  Why should a random user bother analyzing the code when the "developer" didn't bother doing the same before committing huge chunks of AI generated code? The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair.
  - michaelmrose 5mo ago
    Because they actually want something fixed as a long term user of a software.
  - msm_ 5mo ago
    >the "developer" didn't bother doing the same before committing huge chunks of AI generated code? This is something that you assume, not something that you have any proof of. To put it a bit more strongly, this is something that you (and hundreds of other people in that github thread) made up in your head. The maintainer is a very experienced OS developer and there's no reason to suspect they didn't review the committed code. Bugs happen, and the mere existence of bugs is not a proof that someone is doing a poor job. Assuming those bugs even exist. I am inclined to believe they do, but the issue does a poor job of reporting them. Instead of factually reporting regressions, the "issue" is a screenshot of a viral tweet. Your vicious reaction is not justified, and you should do better in the future. >The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair. It is not fair. The rsync maintainer does not owe you anything. You owe them for using their software. How much did you donate to rsync this year?

kzrdude 5mo ago

We could tell, if someone did independent work of reviewing a sample of the contributions and recent changes (and published in a blog post for example).