sidebar: given that there is interest in alternatives to GPL software that is now being vibecoded, and these alternatives largely tend to not be copyleft...
1. alpine is interested in a reliable rsync implementation.
2. we presently use rsync, which is GPL, and now vibe-coded.
3. openrsync is an alternative rsync implementation, which is maintained by the OpenBSD project, and thus ISC licensed.
4. if we repeat this cycle over and over, to avoid other regressions from other unreliable vibecoded software, then the pool of influential GPL software wanes over time.
@AmyZenunim Except in most cases it's the other way around. rsync is rather unique here. For example it's LLVM embracing slop and GCC rejecting it. Usually because these lines match up with "corporate techbro open source" vs "free software as a social program".
the man has done far more for software freedom than most of us have.
but he is still a person, and people can easily be convinced by these LLMs that things check out when they actually don't.
they use very persuasive language. if you depend on them, you will inevitably commit mistakes that you should have caught, because nobody does a perfect job. nobody.
what I will say is this. there are pieces of software that are frankly "mission critical".
for example, pkgconf, as a key component of most build toolchains, cannot have regressions because those regressions will reverberate throughout the entire "software supply chain" in the form of build errors. it is a mission critical piece of software.
this is why as lead maintainer of pkgconf I have implemented a number of policies and initiatives to reduce the likelihood of software errors and promote correctness in pkgconf as part of the pkgconf 3.0 work.
these initiatives include banning LLM contributions, requiring DCO signoffs on commits, refactoring the codebase to remove entire classes of vulnerability, improving the quality of the windows port so it is equivalent to its unix counterparts and reimplementing and expanding the test suite from scratch.
why? because every single thing I listed reduces the likelihood for regressions.
rsync, like pkgconf, is used at all times of the day, all around the world. I try to visualize the scope to which pkgconf is used and it is just not possible.
rsync is the same way: everyone is using it somehow, either to back up their data, or to mirror data from one machine to another. there are numerous utilities which make use of it somehow to provide functionality.
a regression in rsync is even less tolerable than a pkgconf regression: if you have errors in rsync, they can potentially cause data corruption or loss.
but rsync goes in basically the opposite direction from pkgconf: it embraces LLM contributions. it also has had several regressions since doing so.
People at my job have suggested having the coding agents review themselves, because since they are nondeterministic, they'll notice different things the second time. Or, similarly, have different LLMs review one another.
I'm just sitting over here in my devops corner 😑 😐 😬
I want to trust tridge because of his tremendously impressive resume (plus I've also worked directly with him on ArduPilot and he's a debugging wizard) but I actually don't trust anyone to resist vibesickness
in theory i do think it's really cool that a nonprogrammer could make a program without going through a lengthy process of learning how to code. however, the history of low code and no code (and prior synonyms and related ideas) makes me wonder if that's something many people really want and whether it will be undermined by increasing complexity (or even existing complexity).
My work experience has been interesting. I do catch the LLMs introducing some things that if a human did them I would describe as very poor judgement (I'm not ascribing judgement of any sort to the LLMs). On the other hand, I've had them catch subtle downstream impacts that I missed, including avoiding introducing bugs that would have been a pain to track down. On balance they are improving, I think.
But I also don't count myself as a second reviewer and the LLM as the author; I am the author using the tool, and I still want real third party human review. Confirmation bias is there — I asked the agent to build something, so I'm clearly predisposed, even when consciously trying to read its plan and its code skeptically, to accept it at a light reading.
I'm not sure this is much different in practice from trusting people who have learned how to project confidence in their writing. The machine is statistically likely to produce writing that is at first glance like a person confident in their own analysis. I think it's a difference in degree, since the machines create so much more of it. But I recognize the same temptation to accept specious confidence.
I feel like it’s import to distinguish vibe coding the odd one-time script or tool for personal use, and slopping out parts of essential, load-bearing infrastructure. The latter just has much higher stakes.
Oh, I was actually considering packaging openrsync myself in response to the recent release's bug reports (as a fail-safe for pmOS), but nice to see you beat me to it. I don't know enough about openrsync other than it is an OpenBSD version to really make any solid statements other than thanks 😀
Now I try to see how far I've got with the prototype of a pre-generated git-like bundle of metadata and http as transport protocol. Okay, only for non-chunked transfers.
Jonathan Lamothe
in reply to Ariadne Conill 🐰 • •David Gerard likes this.
Ariadne Conill 🐰
in reply to Jonathan Lamothe • • •Jonathan Lamothe
in reply to Ariadne Conill 🐰 • •Ariadne Conill 🐰
in reply to Ariadne Conill 🐰 • • •🇺🇦 haxadecimal 🚫👑 reshared this.
Ariadne Conill 🐰
in reply to Ariadne Conill 🐰 • • •i honestly do not know how i feel entirely about vibe coding? i think it is cool that people can theoretically get any program they want at any time.
but that's theory.
in practice, the code the tools generate has a tendency to be unreliable and frequently also has security issues.
and rsync is being vibecoded by just tridge without any supervision.
Ariadne Conill 🐰
in reply to Ariadne Conill 🐰 • • •Ariadne Conill 🐰
in reply to Ariadne Conill 🐰 • • •sidebar: given that there is interest in alternatives to GPL software that is now being vibecoded, and these alternatives largely tend to not be copyleft...
will vibe coding mean the death of copyleft?
✰ Alice D. ✰
in reply to Ariadne Conill 🐰 • • •Ariadne Conill 🐰
in reply to ✰ Alice D. ✰ • • •@AmyZenunim that wasn't the question.
let me break it down:
1. alpine is interested in a reliable rsync implementation.
2. we presently use rsync, which is GPL, and now vibe-coded.
3. openrsync is an alternative rsync implementation, which is maintained by the OpenBSD project, and thus ISC licensed.
4. if we repeat this cycle over and over, to avoid other regressions from other unreliable vibecoded software, then the pool of influential GPL software wanes over time.
Cassandrich
in reply to Ariadne Conill 🐰 • • •Mina
in reply to Cassandrich • • •@dalias @AmyZenunim rsync going slop is wild, because: chaos.social/@dentangle/116657…
Brett Sheffield (he/him)
2026-05-29 11:26:12
dch
in reply to Mina • • •Kevin
in reply to Cassandrich • • •Neil E. Hodges
in reply to ✰ Alice D. ✰ • • •If that's the case, doesn't that mean components of rsync that were LLM-generated aren't under the GPL?
(This is a response to only the comment I'm replying to, not OP.)
Ariadne Conill 🐰
in reply to Ariadne Conill 🐰 • • •anyway: mad respect for tridge.
the man has done far more for software freedom than most of us have.
but he is still a person, and people can easily be convinced by these LLMs that things check out when they actually don't.
they use very persuasive language. if you depend on them, you will inevitably commit mistakes that you should have caught, because nobody does a perfect job. nobody.
Ariadne Conill 🐰
in reply to Ariadne Conill 🐰 • • •what I will say is this. there are pieces of software that are frankly "mission critical".
for example, pkgconf, as a key component of most build toolchains, cannot have regressions because those regressions will reverberate throughout the entire "software supply chain" in the form of build errors. it is a mission critical piece of software.
this is why as lead maintainer of pkgconf I have implemented a number of policies and initiatives to reduce the likelihood of software errors and promote correctness in pkgconf as part of the pkgconf 3.0 work.
these initiatives include banning LLM contributions, requiring DCO signoffs on commits, refactoring the codebase to remove entire classes of vulnerability, improving the quality of the windows port so it is equivalent to its unix counterparts and reimplementing and expanding the test suite from scratch.
why? because every single thing I listed reduces the likelihood for regressions.
rsync, like pkgconf, is used at all times of the day, all around the world. I try to visualize the scope to which pkgconf is used and it is just not possible.
rsync is the same way: everyone is using it somehow, either to back up their data, or to mirror data from one machine to another. there are numerous utilities which make use of it somehow to provide functionality.
a regression in rsync is even less tolerable than a pkgconf regression: if you have errors in rsync, they can potentially cause data corruption or loss.
but rsync goes in basically the opposite direction from pkgconf: it embraces LLM contributions. it also has had several regressions since doing so.
Neil E. Hodges likes this.
reshared this
Neil E. Hodges reshared this.
yak
in reply to Ariadne Conill 🐰 • • •UnlikelyLass
in reply to Ariadne Conill 🐰 • • •People at my job have suggested having the coding agents review themselves, because since they are nondeterministic, they'll notice different things the second time. Or, similarly, have different LLMs review one another.
I'm just sitting over here in my devops corner 😑 😐 😬
Neil E. Hodges
in reply to Ariadne Conill 🐰 • • •gaytabase
in reply to Ariadne Conill 🐰 • • •Brahms
in reply to Ariadne Conill 🐰 • • •even without these, the ethical and the environmental issues one thing that bothers me is that someone has to maintain all that code.
there is a reason why software engineering is hard and it certainly isnt because we aint producing enough code.
aburka 🫣
in reply to Ariadne Conill 🐰 • • •alys
in reply to Ariadne Conill 🐰 • • •Michael K Johnson
in reply to Ariadne Conill 🐰 • • •My work experience has been interesting. I do catch the LLMs introducing some things that if a human did them I would describe as very poor judgement (I'm not ascribing judgement of any sort to the LLMs). On the other hand, I've had them catch subtle downstream impacts that I missed, including avoiding introducing bugs that would have been a pain to track down. On balance they are improving, I think.
But I also don't count myself as a second reviewer and the LLM as the author; I am the author using the tool, and I still want real third party human review. Confirmation bias is there — I asked the agent to build something, so I'm clearly predisposed, even when consciously trying to read its plan and its code skeptically, to accept it at a light reading.
I'm not sure this is much different in practice from trusting people who have learned how to project confidence in their writing. The machine is statistically likely to produce writing that is at first glance like a person confident in their own analysis. I think it's a difference in degree, since the machines create so much more of it. But I recognize the same temptation to accept specious confidence.
Billchenchina 🏳️⚧️
in reply to Ariadne Conill 🐰 • • •Actually rsync sometimes regresses. Security update sometimes breaks things. rsync's codebase is indeed complex.
Previously:
bugs.debian.org/1093052
bugs.debian.org/1093089
lists.debian.org/debian-securi…
Not sure whether to blame vibe coding this time..
#1093052 - rsync: Error in 3.2.7-1+deb12u1: "Internal hashtable error: illegal key supplied!" using -rH - Debian Bug report logs
bugs.debian.orgjaseg 🔜 GPN24
in reply to Ariadne Conill 🐰 • • •James M.
in reply to Ariadne Conill 🐰 • • •Billchenchina 🏳️⚧️
in reply to Ariadne Conill 🐰 • • •bugs.debian.org/1138239
#1138239 - rsync: Consider reverting to pre-LLM version - Debian Bug report logs
bugs.debian.orgfosdembsd
in reply to Billchenchina 🏳️⚧️ • • •Jacob Something
in reply to Ariadne Conill 🐰 • • •justsoup
in reply to Ariadne Conill 🐰 • • •justsoup
in reply to justsoup • • •Mason Loring Bliss
in reply to Ariadne Conill 🐰 • • •It'd be useful for them to update the "please wait" page with more detail.
It'll be nice having a more heterogenous ecosystem. Thanks in advance for your planned port.
openrsync.org/
OpenRsync
www.openrsync.orgnieuemma
in reply to Ariadne Conill 🐰 • • •waldi
in reply to Ariadne Conill 🐰 • • •I think about replacing rsync for several years.
Now I try to see how far I've got with the prototype of a pre-generated git-like bundle of metadata and http as transport protocol. Okay, only for non-chunked transfers.