i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
-
@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.
-
@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
@whitequark @ariadne I feel like in general, “smart” people tend to over-generalize the effects of (their or others’) raw intelligence. Raw intelligence doesn’t equal wisdom or common sense and smartness in one area of life (say, technology) rarely translates across categories.
-
@whitequark @ariadne I feel like in general, “smart” people tend to over-generalize the effects of (their or others’) raw intelligence. Raw intelligence doesn’t equal wisdom or common sense and smartness in one area of life (say, technology) rarely translates across categories.
-
@whitequark @ariadne I feel like in general, “smart” people tend to over-generalize the effects of (their or others’) raw intelligence. Raw intelligence doesn’t equal wisdom or common sense and smartness in one area of life (say, technology) rarely translates across categories.
@whitequark @ariadne I feel like one reasons LLMs caught on in the tech sphere so well is that they are essentially psychological weapons in the way they’re optimized for persuasiveness, and they’ve been unleashed on a population of technically smart people who often don’t have the best social skills.
-
@whitequark @ariadne I feel like one reasons LLMs caught on in the tech sphere so well is that they are essentially psychological weapons in the way they’re optimized for persuasiveness, and they’ve been unleashed on a population of technically smart people who often don’t have the best social skills.
-
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.
another sidebar: I haven't found a great less-capitalist alternative to "software supply chain" to describe components of software and their dependencies.
there is the commons, but that is a collection of all libre software. not the same thing.
-
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.
@ariadne I'm curious though, how much *active* development is going on in rsync nowadays. It seems like a good candidate to fork from the last known pre-"ai" version and stay focused on critical bugfixes / security fixes.
-
another sidebar: I haven't found a great less-capitalist alternative to "software supply chain" to describe components of software and their dependencies.
there is the commons, but that is a collection of all libre software. not the same thing.
@ariadne what exactly is capitalist about a supply chain?
-
another sidebar: I haven't found a great less-capitalist alternative to "software supply chain" to describe components of software and their dependencies.
there is the commons, but that is a collection of all libre software. not the same thing.
@ariadne i don't think "supply chain" is a particularly capitalist term, at the very least because the soviet union also had to deal with these (in fact, supply chains in the ussr were often built across constituent republics to boost interdependence)
-
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 Tridge is responding in the rsync discord, I won't quote him, his perspective is understandable but worth challenging (ok I will quote one thing, he mentions using three LLMs for checking
) -
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 had the discussion with work mates about the services (I think it was called Malus) where you can pay for letting your software vibecoded to avoid GPL.
And then we realised that Palantir and other big tech software vendors loose market share because people also use AI to vibecode alternatives to proprietary software as well. So I think we lose some and gain some benefits here. In the end it evens out.
GPL as Licence will probably still be important in the future.
-
@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
@whitequark @ariadne It just struck me that "tokenmaxxing" really isn't a million miles removed from AI Waifu, and now I worry about the psychological consequences of recent price hikes
-
@jpm @swetland @ariadne I said I wouldn't quote tridge from the rsync discord but his stated intent is
>basically I'm tring to get rsync into a state where we can withstand the storm of AI generated security reports
which is a noble goal but hasn't been achieved with his use of LLM coding agents. Also the usual complaint of being an unpaid maintainer, which true, but LLMs aren't a solution to that -
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
Be aware that openrsync isn't a drop-in replacement for rsync. We ran into problems when Apple replaced rsync with openrsync in Sequouia. Scripts that had previously worked broke. We ended up installing the real rsync using homebrew because we couldn't get things to work with openrsync.
-
@billchenchina @ariadne and avoid the latest security release with 6 CVE? 🤯
@fosdembsd
Better than a bunch of regressions.Breaking stuff in security updates is far worse, because users that are hurt by that usually stop applying all security updates.
-
i plan to package openrsync this weekend in alpine as an alternative to rsync (and probably switch the default rsync implementation in future)
@ariadne that could be a fun life stream
-
another sidebar: I haven't found a great less-capitalist alternative to "software supply chain" to describe components of software and their dependencies.
there is the commons, but that is a collection of all libre software. not the same thing.
@ariadne
"Dependency network" or something along those lines?
