Looking at the #rsync fiasco with Claude, I cannot believe project maintainers would do this to themselves
Take foot, apply gun
rsync
It's very sad to see #rsync getting polluted with LLM slop now.
Even more sad, given who is doing it.
People are talking angrily about "the maintainer" and suggesting "this guy" [should have his commit bit revoked] etc. apparently not realising that "this guy" is Tridge, both the original author of rsync and creator of samba. His PhD thesis "Efficient Sorting & Synchronization Algorithms" describes the original rsync algorithm. Still worth a read, even now.
Edited 124d ago
I used to sync 300 GB with #Syncthing. Now I'm syncing 5 MB with #Nextcloud. It's baby steps. I'm still doing double backups of the entire filesystem (#DejaDup and #rsync) to separate USB hard drives.
Edited 120d ago
There was an article written recently about an rsync rewrite in Golang not being vulnerable to some vulnerabilities found in rsync.
The author went the extra mile and had some kind words to write about OpenBSD's OpenRsync as well:
https://michael.stapelberg.ch/posts/2026-05-24-minimal-memory-safe-go-rsync-vulns/#openrsync
Ironically, I saw this not long after closing a Pull Request to submit an OpenRync port to MacPorts: https://github.com/macports/macports-ports/pull/28096
Not that I don't still have an interest in such things, but it seems as if there are some other things going on (if I observed things correctly, it seems as if Apple maybe commissioned Klara Systems to port OpenRsync to macOS [e.g. https://github.com/KlaraSystems/openrsync]? Yet, it didn't seem as if they did so in a very collaborative spirit with the lead developer Kristaps Dzonsons?). Moreover, I didn't want to just leave that dangling when other MacPorts contributors were side-eyeing the PR as being left open for so long.
#OpenRsync #rsync #vulnerabilities #OpenSource #Security #Infosec #SecurityResearch #OpenBSD
The author went the extra mile and had some kind words to write about OpenBSD's OpenRsync as well:
https://michael.stapelberg.ch/posts/2026-05-24-minimal-memory-safe-go-rsync-vulns/#openrsync
Ironically, I saw this not long after closing a Pull Request to submit an OpenRync port to MacPorts: https://github.com/macports/macports-ports/pull/28096
Not that I don't still have an interest in such things, but it seems as if there are some other things going on (if I observed things correctly, it seems as if Apple maybe commissioned Klara Systems to port OpenRsync to macOS [e.g. https://github.com/KlaraSystems/openrsync]? Yet, it didn't seem as if they did so in a very collaborative spirit with the lead developer Kristaps Dzonsons?). Moreover, I didn't want to just leave that dangling when other MacPorts contributors were side-eyeing the PR as being left open for so long.
#OpenRsync #rsync #vulnerabilities #OpenSource #Security #Infosec #SecurityResearch #OpenBSD
Edited 127d ago
ICYMI: some dork used #Claude #LLM to 'fix' an issue in #rsync and broke it (v3.4.3).
#GenAI is shit and shld not be used for code that needs to work, even if you have the morals of a billionaire skunk.
Lots of critical tasks, such as backup 🤦♂️ will be broken as people update their #Debian #Linux thanks to this stupid obsession and psychosis.
How much will that cost? On top of all the costs inflicted on people who never touch the stuff and don't want to run anything built with it, like me.
This
I think "free as in beer" software is more appropriately called "Libertarian and Open Source Software", or LOSS. Among other things it involves no obligations on other people, and expects no obligations in return (*). But this means it's an everyone for themselves, anti-communitarian endeavor. We should be honest about this. We should also be honest when a project changes state from FOSS to LOSS, because that's a meaningful change, and actually is a loss in my view.
I continue to believe that enthusiastic embrace of AI/LLM coding tools is a leading indicator of an impending FOSS→LOSS transition.
It seems to me at least one driver of the uproar over
#tech #dev #software #SoftwareDevelopment #FOSS #freedom #rsync #AI #GenAI #GenerativeAI #LLMs
(*) Putting aside whether this principle is consistently applied or hypocritical.
rsync thing has me thinking about the difference between the "free as in beer" model of free software and the "free as in freedom" model the FSF originally put forward. There are important differences, and it's meaningful when a project changes from one model to the other, which is one way to narrativize what's happened to rsync.I think "free as in beer" software is more appropriately called "Libertarian and Open Source Software", or LOSS. Among other things it involves no obligations on other people, and expects no obligations in return (*). But this means it's an everyone for themselves, anti-communitarian endeavor. We should be honest about this. We should also be honest when a project changes state from FOSS to LOSS, because that's a meaningful change, and actually is a loss in my view.
I continue to believe that enthusiastic embrace of AI/LLM coding tools is a leading indicator of an impending FOSS→LOSS transition.
It seems to me at least one driver of the uproar over
rsync is that a bunch of people thought it was a FOSS project but it had, in a short period of time, converted into a LOSS project and the shock was jolting (understandably). As a FOSS project, rsync served a community function, leading people to depend on it, make assumptions about its longer-term stability, and so on. Those are reasonable expectations of a communitarian project. As a LOSS project, rsync is under no obligations to anyone and the maintainer(s) can change the software at any time, for any reason, at their discretion alone. It seems rsync is a LOSS.#tech #dev #software #SoftwareDevelopment #FOSS #freedom #rsync #AI #GenAI #GenerativeAI #LLMs
(*) Putting aside whether this principle is consistently applied or hypocritical.