i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
-
@ariadne I haven't been paying particular attention. What's the problem with rsync?
@me its now being coded by Claude and there have been regressions
-
@me its now being coded by Claude and there have been regressions
@ariadne Ugh. I use rsync daily. Thanks for the heads-up. -
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
@ariadne 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.
-
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
@ariadne thank you
-
@ariadne
Bug#1138239: rsync: Consider reverting to pre-LLM version
https://bugs.debian.org/1138239@billchenchina @ariadne and avoid the latest security release with 6 CVE? 🤯
-
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?
@ariadne I don't know, but I've thought about this exact scenario way too much and it seems like it's at least a real concern.
I guess we'll see how the next few years play out.
-
that is also not relevant, but i am not sure that your assertion is true anyway, as at least one debian developer has suggested that the regressions are bad enough to revert back to the last non-LLM version.
interesting
-
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?
@ariadne I'd be a bit surprised, since copyleft is in theory a lot more legally resistant to being *used* for vibecoding. Not that courts will likely care, because when a corporation does it it's generally legal (though maybe I'm being too cynical, or not cynical in a complex enough fashion—the ongoing lawsuits from the NYT and such haven't been decided yet). But, it does seem like in the longer term this could naturally lead to people against LLMs using licenses that attach *more* stipulations rather than fewer.
As a random internet commentator, my specific prediction: by the end of this decade, we'll see reasonably wide and/or notable adoption of a software license that breaks the traditional taboo against having clauses like the CC NC clause where field of use is restricted. -
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
@ariadne 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.
-
@meena this is like discovering Jesus middle name was actually Lucifer @dalias @ariadne @AmyZenunim @dentangle
-
@ariadne @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".
@dalias @ariadne @AmyZenunim linux is GPL and embracing LLMs.
-
@dalias @ariadne @AmyZenunim linux is GPL and embracing LLMs.
@dalias @AmyZenunim @ikke yes, but I think from a software reliability perspective, the kernel is still being appropriately reviewed for the most part.
the larger problem will be regressions from the smaller projects where we have solo maintainers using LLMs as a force multiplier without appropriate review, and so far that's where we are seeing regressions from what I've been noticing.
and this is nothing to say about the legal status of these projects given that mechanically generated code of any kind does not qualify for copyright protection under the Berne convention...
-
@ariadne Quite the opposite I think. I think it leads to a resurgence in interest in copyleft, since these are largely the projects not embracing slopware and the fraudulent "non-copyleft" "rewrites" are pandering to techbro asshats and the corporate AI-slop program.
@dalias it very well could be. but there's a lot of copyleft software adopting this stuff because the maintainers adopting it believe it can act as a force multiplier.
-
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?
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.
-
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 yeah, i feel the same about this as for phishing, or cults
there is no amount of "smart" you can be that leaves you immune to ending up in a cult. none. it's a category error. these entities take advantage of vulnerability, which is something you can be, and likely will be at some point, regardless of your skill or achievements
-
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 "You are not immune to propaganda"
-
@ariadne yeah, i feel the same about this as for phishing, or cults
there is no amount of "smart" you can be that leaves you immune to ending up in a cult. none. it's a category error. these entities take advantage of vulnerability, which is something you can be, and likely will be at some point, regardless of your skill or achievements
@ariadne i remember very well how categorical vulnerability feels. that particular instance was due to a war, but i don't think there's a fundamental difference. even beyond falling to persuasive language, if you're in a certain place mentally, you could know someone is lying to you and still go along with what they say.
is tridge in that position? dunno. don't know him. but i do believe that this scenario is playing out over and over in so many places around. perhaps here too
-
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 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.
-
@ariadne 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
@Unlikelylass I’ve found that while sometimes they make stupid mistakes that they catch when you point them at the thing a second time, there also exists a large category of “blind spots” in these models that they are seemingly unable to address even given extensive human guidance. This category seems to have a weird, amorphous shape that makes it hard for humans to grasp which parts are hard, and which are easy for the LLM.
-
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.
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.
