__ __ _ _____ _ _ _
| \/ | ___| |_ __ _| ___(_) | |_ ___ _ __
| |\/| |/ _ \ __/ _` | |_ | | | __/ _ \ '__|
| | | | __/ || (_| | _| | | | || __/ |
|_| |_|\___|\__\__,_|_| |_|_|\__\___|_|
community weblog
Whatabout reputation and experience?
Andrew "tridge" Tridgell, a historied free/libre software hacker with contributions to the Linux Kernel and the creator of Samba filesharing tool, has become embroiled in an argument about slop.
"Like many developers of open source packages I've been hit by a flood of security reports lately in my role as the rsync maintainer. ... As this flood started to get more intense I realised I needed to raise the defences on rsync a lot " explains tridge (at medium). Changes to rework a test suite using Claude as a digital amenuensis following tridge's design and guidance landed alongside a regression while fixing security bugs. People conflated the 'tridge and Claude' signoff as blaming the GenAI tool for the errors that caused basic backups to fail.
While semi-retired, tridge returned to maintain this longstanding tool after a successor ceased due to exhaustion.
From the main link: "I rewrote the rsync test suite in python from the old shell script design. I did the design for that myself (and I'm really quite pleased with it), but used claude with cross-checks from codex and gemini to do the grunt work. I did not just vibe-code "convert test suite to python". I'm a software engineer with 40 years experience (yeah, I'm OLD!), so I did a design first and had a plan for how to validate it. I used AI tools to do the grunt work because they are good at that. I reviewed every part of it myself and ran through a huge amount of CI time getting it right (I'm since moved to having a bunch of local VMs to do most testing to reduce the CI wait time)."
For me, there's a question not asked in the frenzy about new tools: what of the masters whose work it improved? Is there room for a 'digital amenuensis' that we trust and creators with good reputation whose use of amenuenses we trust?
posted by k3ninho on Jun 04, 2026 at 2:18 AM
---------------------------
Maybe the concept of "masters" or Great Men in open source is bad, actually.
posted by Four String Riot at 3:48 AM
---------------------------
I think the word you are looking for is amanuensis, though amenuensis is the name of a UK based code generation company.
posted by Lanark at 3:58 AM
---------------------------
So... here's my developer hot take:
I get that he's frustrated that a lot of people assumed that he committed vibe-coded slop and this broke something, but it doesn't follow that he is completely vindicated and we should all be very sorry and never question a maintainer's use of generative LLMs again (I say "we" not because I participated in this pile-on, but because I am very firmly in the "stop fucking using this" camp).
It is by no means a given that his 40 years of experience should have granted him any degree of trust when he used LLM tools for a sweeping rewrite of an entire test framework. We are all surrounded by tech veterans (who should know better) egregiously misusing LLMs, so deep in denial about the quality of the output that they are unreachable to reasonable discussion. It's depressing, it's demoralizing, and we've burned the fuck out. My personal default trust level in these situations is zero. He should have read the room, and explained up-front how he was using these tools and what he was doing to validate the output. Is this a valid use case of generative LLMs? Maybe. I would never do this, but I'm willing to hear him out -- but I need a more detailed description of the methodology than "trust me bro".
This rewrite should not have gone in the same release as security updates. Releases with security fixes should have minimal changes, and include no changes that are not directly related to the security fixes.
We can argue forever about whether he allocated his time well, whether the time he spent on the rewrite (which, if he really did validate it properly, could not have been negligible) would better have been spent checking the security fixes more extensively, and whether this could have prevented the regressions. I think that's backseat driving, and I'm not really interested in doing that. We can also argue about whether the amount of time he spent wading through security reports, "many" of which were LLM-generated, was a good use of his time, and whether the issues he elected to fix were urgent enough to outweigh the risk of breaking functionality in a tool that is so ubiquitous that it has become infrastructure (one frustrated commenter on the article seems to be arguing that it's pointless to fix vulnerabilities because they're unlikely to affect anyone and there will always just be more vulnerabilities, which... is certainly A Take).
And of course there are broader underlying problems in open source -- both the extreme toxicity and bad behaviour in various communities, and that so many projects that have become critical digital infrastructure are relying on the unpaid labour of Some Guy [gn] who additionally gets yelled at no matter what they do and is sometimes subjected to abuse as targeted social engineering by state actors. These are genuine problems! But a genuine problem doesn't magically make a bad or untrustworthy solution less bad or more trustworthy, and you don't get an automatic pass for using it because "what else are you supposed to do?".
TL;DR if in the current climate you, an experienced tech person, commit a large volume of generated code to your widely used project, with no explanation of what steps you took to validate it, and you are surprised that this is met with hostile pushback, I don't know what to tell you. Similar vibes to those graduation speakers getting booed.
posted by confluency at 4:03 AM
---------------------------
I think "trust" and "improved" is doing a lot of work in the OP. People who have looked at, for example, the rewritten test code have not been impressed.
To me it's particularly troubling, because when working with LLMs, the tests are theoretically the thing that keeps the chatbot from going completely off the rails. Yes, it's preferable to have those tests in something like Python and not a bunch of Bash scripts. But if you let the chatbot rewrite the tests, even assuming that you directed and reviewed it scrupulously (and historically, people are not very good about catching bugs in code review), you've basically undermined the foundation of the project and made it easier for slop bugs to creep in.
posted by Four String Riot at 4:08 AM
---------------------------
As with many development fads, one can look to the BSD community for sanity.
posted by sagc at 4:16 AM
---------------------------
I've been seeing some attempts to push the crap in the building-physical-things sphere. So far nobody was insane enough to let the things do anything real. I guess people do make a real distinction between 'this will kill my backups' over 'this will kill my body and it will hurt'.
posted by mayoarchitect at 4:17 AM
---------------------------
Also, this post reads more like an editorial than an unbiased account of what happened - I would make sure to read confluency and Four String Riot's posts for the broader context.
posted by sagc at 4:17 AM
---------------------------
Like, this is a terrible example of "what of the masters whose work it improved?". The work was not in fact improved.
posted by sagc at 4:18 AM
---------------------------
I am as bigoted an AI hater as any you'll find, any my main reason for that hatred is that LLMs lend themselves so incredibly well to being misapplied by complete fools who have no clue what they're actually good for. That makes their potential social downside almost infinite compared to their frankly minuscule upside.
That said, experienced software developers making cautious use of LLM tools to get volunteer work done that they would not have been in a position to do without those tools is not something I can find it within myself to worry about.
Specifically on rsync: anybody who doesn't like the way tridge is handling that project is completely free to fork the latest version they're happy with and maintain that fork according to whatever they consider best practice. If there's one thing that pisses me off more than LLM hucksters, it's entitled whingers shitting on people who've given them useful stuff for free.
Rsync is licensed under the GPL v3, and section 15 of the GPL v3 says this in big shouty letters: THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
Seriously, what part of that is hard to understand?
a genuine problem doesn't magically make a bad or untrustworthy solution less bad or more trustworthy, and you don't get an automatic pass for using it because "what else are you supposed to do?"
Quite so. And any person inclined to put that point to a volunteer free software developer with respect to that developer's maintenance practices really needs to be putting it to themselves first with respect to their own choice to make use of that developer's freely offered software.
posted by flabdablet at 4:36 AM
---------------------------
Lanark: "I think the word you are looking for is amanuensis, though amenuensis is the name of a UK based code generation company."
Amen to that. Flagged with note delegating this fixup task to correct these spellings.
posted by k3ninho at 4:55 AM
---------------------------
Lurking in the background of this is the uncomfortable fact that the vast majority of essential open-source are woefully understaffed and underresourced (see xkcd). A single developer effectively having total power over a project is just one of the symptoms.
posted by tommasz at 5:05 AM
---------------------------
I'm so mad about this. Not the AI use; at the way tridge has been treated. The agreement since the dawn of open source has been "if you don't like the way it's going, fork it." If you read that as "pile virtriol on the volunteer maintainer until they want to quit", well, I don't know what the hell to tell you. If you can't show basic decency to someone who's trying to help you, don't make arguments about how AI is dehumanizing.
posted by phooky at 5:20 AM
---------------------------
If a volunteer at the soup kitchen spoils dinner for hundreds of people by ignoring their training or some obvious blunder, I'd be mad at them too. Being a volunteer is nice and all but it still comes with responsibility.
Seems like there's a lot going on here, but "you can't hold volunteers accountable for their mistakes" is not a lesson I'd want people to take from it.
posted by SaltySalticid at 5:58 AM
---------------------------
I'm seeing parallels here to when someone thoughtlessly says something offensive and they get called out on it and instead of recognizing that maybe they didn't put a whole lot of thought into what they said they get all self-righteous and defensive about their right to say it and that then provokes a community pile-on which then incites another community to come to their defense and the whole situation spirals out of control until they become a guest on some Fox News show explaining how there's no longer any room for sensible people like them anymore.
posted by RonButNotStupid at 6:09 AM
---------------------------
If a volunteer at the soup kitchen spoils dinner for hundreds of people by ignoring their training or some obvious blunder, I'd be mad at them too.
Sure. But the soup kitchen is a terrible analogy for software development because software doesn't get used up.
Freely offering the user community an updated version with a bunch of old bugs fixed and a few new ones introduced does not stop previous versions from working as well as they ever did. Almost always, it's doesn't even stop previous versions from being readily available.
The bleeding edge is called that for good and sufficient reason. If you choose to rely blindly on bleeding edge releases and end up getting cut, that's on you.
posted by flabdablet at 6:20 AM
---------------------------
If a volunteer at the soup kitchen spoils dinner for hundreds of people
There are several important differences between that situation and the situation people in this thread are discussing. For example, people need to eat every day, and new food needs to be made for them to consume. In contrast, people who do not want to use newer versions of rsync can use the ones that were released before changes they dislike.
Regardless, there is a root problem here which is that individual volunteers are scrambling for leverage and support in order to support infrastructure that the world collectively depends on but does not fund. We have a pretty well-proven way to collectively fund infrastructure that we collectively depend on: taxes. The Sovereign Tech Agency in Germany provides a model for many governments. Tridge is in Australia. I'd love for the Australian government, or a consortium of users (funded by a combination of institutions who use the tool), to manage a working group that governs of the project, and to collectively fund ongoing maintenance work.
posted by brainwane at 6:25 AM
---------------------------
That link posted by Four String Riot is really great and it's not only about the rsync drama - you should all give it a read. Come for the similarity between LLM use and gambling, stay for running tests as root, making the tests less comprehensible and horror stories from other projects using LLMs for test generation. Also, this comment is gold:
Yes right - and after reading about a dozen of the test scripts I can definitely see why using pytest would be useful here to consolidate some of the behavior that was repetitive and ad-hoc in the original testing scripts. Like the tests need to do repetitive things like set up test directories with different names and structures, run and capture results, setup and teardown a server, parameterize over a range of values. Done right, a pytest suite would have made perfect sense and improved both the existing tests by making them more systematic and uniform, but also made it easier to add new tests over time. However that is not what happened, and what did happen is much worse because it did the opposite of almost all those desirable qualities.
An unstated part of this is the "trapped with the orb" mentality - if you would have made a post like "hey everyone I'm thinking about rewriting rsync's tests in python, how should I do that" you would have been absolutely swamped with python nerds such as myself telling you how to do that, writing examples, and hell helping you with the actual change. But since LLMs trap you into Just Orb Time where you feel like you are in touch with collective wisdom, that wonderful generative intelligence known as human intelligence never kicked in, the wisdom and work of the commons never came, and instead now everyone is yelling at you - which one only imagines is pushing tridge further into the sanctum of the orb.
posted by kmt at 6:28 AM
---------------------------
instead of recognizing that maybe they didn't put a whole lot of thought into what they said they get all self-righteous and defensive about their right to say it
That's not what tridge has done here. Rather, he presented what struck me as a remarkably patient explanation of what he did and why, and that he had in fact put considerable thought into it.
That said, I do seem to recall that it was a bit of political carelessness from tridge that forced Linus to write Git in such a tearing hurry and annoyed him enough to name it "Git".
posted by flabdablet at 6:30 AM
---------------------------
Tim Bray (who leans AI skeptic) weighs in on the topic.
Bray points out another reason the soup kitchen analogy fails: this is expert work, and people who can do it are hard to find. And particularly for old and unglamorous tools like rsync, nobody is really in the mix giving you feedback. You're pretty much on your own.
posted by billjings at 6:30 AM
---------------------------
Ok, maybe soup kitchen isn't the perfect analogy. And yes these FOSS projects should have more support, I'd love it if govts and other institutions stepped in to do that! I'd happily pay a little more taxes if I knew that's where the money would go.
But volunteers do take on responsibility, and there are real consequences when they mess things up. The idea that you can't be accountable if you're not getting paid is just a bit wild to me, no matter that software is different that physical goods. The warranty frees them of legal repercussions, but not social backlash.
posted by SaltySalticid at 6:32 AM
---------------------------
The warranty frees them of legal repercussions, but not social backlash.
That para in the GPL is not a warranty. It's an absolutely explicit and unambiguous denial that a warranty exists and an absolutely explicit and unambiguous declaration on where expectations around risk need to be.
Just because it's in all caps doesn't make it Lawyers Only. It says what it means and it means what it says. Don't like it? Don't use it.
Gifts are not work for hire, and yelling at people who give them is just plain rude.
posted by flabdablet at 6:45 AM
---------------------------
The buried lede here is tridge came out of retirement because the previous maintainer was exhausted That's the problem that needs fixed in Open Source.
Using claude etc, is not going to help, it's like that old saying about using a regular expression, now you have two problems.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 6:54 AM
---------------------------
But volunteers do take on responsibility, and there are real consequences when they mess things up. The idea that you can't be accountable if you're not getting paid is just a bit wild to me, no matter that software is different that physical goods. The warranty frees them of legal repercussions, but not social backlash.
That's absolutely true, and also a huge problem here. Because all these folks look at rsync, and they say "I'm absolutely not expert enough to contribute to rsync or fork it, but I am expert enough to say that this sucks" and the resulting accountability is that the maintainer of rsync abandons the project and rsync is unmaintained. Which isn't great in our new age of overwhelming LLM driven security issues.
Plus, when that social backlash is coming from a social media mob it's going to be a poor signal, to the extent that when I see something like this my kneejerk sympathies are with the target. None of the analysis of these changes are compelling enough to justify the kind of nasty opprobrium being levied at tridge or anyone, and that's sadly typical.
There is a fruitful accountability mechanism, which is for someone to fork the project. (Replace the line cook, in the soup kitchen metaphor.) But that has been in short supply, especially for old, boring, stable, essential tools (like rsync).
It's not great! It's a crisis, in fact, one that open source people have been talking about more and more. I don't know what the solution is.
posted by billjings at 6:55 AM
---------------------------
I see a lot of people talking about how much abuse the rsync maintainer is taking. I see a fairly heated GH issue with a lot of back and forth by people who don't seem to actually be the maintainer. I don't actually see links to people sending abuse or vitriol, and I certainly don't see anyone here defending that if it happened. I'm not on X Dot Com The Everything App, so maybe it's gotten vicious there (they had a head start!), but the responses I've seen on Mastodon have mostly been of the "I'm not mad, I'm disappointed" variety. I see people upset at the actions, but not the person.
posted by Four String Riot at 6:57 AM
---------------------------
Just because something says in text "we're not responsible if something goes wrong" doesn't mean you can come in and ignore that rsync is a tool depended on by probably anyone in the world who wants to automate backups in a reliable way on a Linux-based system (which includes MacOS and Windows at this point).
And then to get huffy when people point out that an unreliable tool was used to make changes that both degraded the test suite and introduced breaking bugs... that's just the icing on the cake.
Quality software development process was not adhered to on many levels (not least of all, marking a major version change for introducing vibe coding into the mix... that would have at least saved people who version locked to 3.x).
posted by kokaku at 7:05 AM
---------------------------
sagc: Also, this post reads more like an editorial than an unbiased account of what happened
I'm grateful to you and the commenters for adding to this situation that I don't fully understand. Basing it around the core character's defence of their actions is going to be biased, but this is a blog and not journalism or, idk, whatever you expect. Andrew Tridgell went into this in a high level of trust for me, and the commentary and evidence show that I need to reassess that downwards. My entry to this story was his blog and I did assume I can trust what he says and the technical choices he's made.
posted by k3ninho at 7:35 AM
---------------------------
This whole brouhaha is confirmation for me that LLM use is a sufficient, but not necessary, precursor to complete fucking loss of plot.
doesn't mean you can come in and ignore that rsync is a tool depended on by probably anyone in the world who wants to automate backups in a reliable way on a Linux-based system
Indeed you can't and indeed it is. I rely on it myself.
What I don't do - what no software user should ever do, be it obtained from cathedral or bazaar - is update stuff I rely on without then ensuring that the updated version still works for me.
It is, or should be, generally understood that sometimes updates break things. If an update breaks my world, I roll it back and wait for one that doesn't. In my experience, free software authors don't need to be accountable to anybody but themselves to make that happen; most take enough pride in what they do that they fix their shit pdq after becoming aware that they broke it. In particular, tridge has consistently done this, which is exactly why rsync and samba are as widely relied upon as they are.
If you've bought software from a vendor who has made rolling back the occasional broken update too hard for you to do, that's on your vendor. If you've accepted it as a freely offered gift, it's on you.
If you refuse to accept somebody else's clear and explicit statement of the conditions under which they are willing to offer such a gift, and yet accept the gift regardless, that's on you too. So no, no volunteer who releases software under GPLv3 is accountable for its quality or performance, not to anyone but themselves. The gift economy runs on generosity, not accountability.
to get huffy when people point out that an unreliable tool was used to make changes that both degraded the test suite and introduced breaking bugs... that's just the icing on the cake
I just read through tridge's Medium piece for the third time and I'm seeing no such icing. Simple disinclination to grovel in unwarranted abject apology does not amount to "huffy". Nor does presenting a rationale for steps already taken and a heads-up for steps to come. There is huff all over the online commentary about this issue but none of it is coming from tridge.
posted by flabdablet at 7:42 AM
---------------------------
The agreement since the dawn of open source has been "if you don't like the way it's going, fork it." If you read that as "pile virtriol on the volunteer maintainer until they want to quit", well, I don't know what the hell to tell you.
Has there ever been a fork that wasn't preceded by some amount of drama and vitriol piled on maintainers?
posted by RonButNotStupid at 7:53 AM
---------------------------
Sometimes forks grow out of "I rewrote it as a learning project and put all this new stuff in" and then the drama is afterwards.
I do like the major-version-update tactical repair.
posted by clew at 8:06 AM
---------------------------
You could argue that as rsync isn't a python project overall, writing idiomatic python tests, specifically those using pytest, is unnecessary because your need is some sort of executable that gets from point A to point B and validates inputs and outputs accordingly and you haven't introduced yet another dependency. I'd err on the side of those who are advocating for using a standard test library.
It's a catch 22 because this is a discussion that probably should have happened, but any sufficiently large/popular open source project is going to attract the kind of people who will incessantly debate this type of choice and cause drama regardless of LLM involvement. Apparently without such a discussion, the orb will not use pytest unless you ask it to use pytest.
I suspect if you told it to write the tests using python testing best practices it may have injected pytest. It sounds like it did the thing many have found, where it just cranks out an individual corresponding test in a format that mimics the output of something like a testing framework without ever using it, or considering that you're in a suite of tests and not just creating a bunch of singletons.
posted by mikeh at 8:17 AM
---------------------------
What I don't do - what no software user should ever do, be it obtained from cathedral or bazaar - is update stuff I rely on without then ensuring that the updated version still works for me.
Corporate IT promptly installs every update that fixes a CVE and nothing short of the apocalypse is going to get them to roll anything back.
posted by RonButNotStupid at 8:18 AM
---------------------------
It is also not realistically feasible to ensure that the updated version works. The sheer volume of software updates in a modern system means you're either sitting on a pile of security problems or you're letting someone else do at least part of the job of making sure that things aren't too broken.
The unspoken social contract is that open source projects won't make unnecessary (and therefore risky) changes in a security fix release.
(Also: it really annoys me when someone says "I have XX years of experience, so I know what I'm talking about." Years of experience raise the skill ceiling, but don't do much of anything to the floor: I've known plenty of industry veterans who I wouldn't trust to write much of anything.)
posted by reventlov at 8:25 AM
---------------------------
I'm too old and stupid to think anything but "if you want guaranteed service, provide a guaranteed paycheck" or fuck off into the sea.
posted by seanmpuckett at 8:39 AM
---------------------------
Right there with you on that, but I'd prefer "bolshie" to "stupid" if it's all the same to you.
posted by flabdablet at 8:42 AM
---------------------------
The unspoken social contract is that open source projects won't make unnecessary (and therefore risky) changes in a security fix release.
That copyleft licenses like the GPL need to exist at all tells you roughly what unspoken social contracts are worth.
posted by flabdablet at 8:45 AM
---------------------------
You could argue that as rsync isn't a python project overall, writing idiomatic python tests, specifically those using pytest, is unnecessary because your need is some sort of executable that gets from point A to point B and validates inputs and outputs accordingly and you haven't introduced yet another dependency. I'd err on the side of those who are advocating for using a standard test library
Given that the existing tests were shell scripts, and not testing Python code per se, it doesn't seem too implausible that he would think that moving to a similar approach in a more ergonomic language was the conservative decision? And, uh, not to stereotype but a 40 year *nix/OSS veteran preferring something that looks like "plain code" to the popular framework doesn't shock me too much, either.
Whether it ultimately turned out well is another story but I don't find it too hard to take him at his word that he meant to do it that way. That one graph of code contributions gets to the real issue which is that people don't expect rsync to change much, and expect that if you have to start changing it, it will be approached very conservatively.
posted by atoxyl at 8:47 AM
---------------------------
Is this a problem that unionization could have solved? I remember 10 years ago there had been a lot of talk of such among the programmers.
Alas
posted by eustatic at 8:48 AM
---------------------------
I am not a prgrammer, but it was interesting to mw that there was a social failure, in that the master's apprentice had prevously bowed out of this role. I think it s worth thinking about why that happens--it s happening a lot in the generational shifts, there s a lack of continuity in professions, and founders are callled back in intoan emergrncy situation.
I think formal apprenticeships are good. That us all.
posted by eustatic at 8:53 AM
---------------------------
Is this a problem that unionization could have solved?
I mean, maybe some sort of organization of OSS maintainers could have helped but they mostly weren't working for anyone or getting paid when these projects started so it wouldn't have been a traditional union exactly.
posted by atoxyl at 8:53 AM
---------------------------
That copyleft licenses like the GPL need to exist at all tells you roughly what unspoken social contracts are worth.
And yet, the vast majority of open source software that people depend on mostly adheres to a number of conventions. Especially the old, deeply-integrated projects like rsync.
(To be clear, I don't think Tridgell is under any obligation to do any maintenance whatsoever, but once he does maintenance it is entirely reasonable to criticize what he does do. (Though not at the internet-amplified mob level; we haven't figured out how to moderate that.))
posted by reventlov at 9:09 AM
---------------------------
I never owned a project as big or foundational as rsync. I was the owner and primary developer on the best code editor on ChromeOS for a number of years. I did have a fair number of annoying or entitled people filing PRs or bug reports. There were a couple of forks, neither of which I think was very successful (although I wished them the best). There were also a lot of very lovely people who pitched in.
However: one of the things that I never expected was that if you write software for ChromeOS, most of your users are students in middle school and high school, because Chromebooks were huge in education. And I've never been very good about test coverage. So every now and then I'd break something, and I'd get a bunch of (usually very kind) e-mails letting me know that I had just disrupted classes around the country, and I would usually scramble together a quick fix or roll the code back.
All of which is to say that there's no legal obligation as an open-source dev to perform free tech support. My code was GPLv3, it had the prominent WITHOUT ANY WARRANTY text. But I still on some level felt responsibility to my users, who had come to depend on me. I think "fuck you, pay if you want fixes" is a valid emotion to feel, but I can't imagine feeling that toward users, even the ones that were assholes. I reserve that anger for the big companies who either undermined the platform or made demands without contributing any budget to support the work (and let's be clear: their LLMs are almost certainly trained on my code, so they continue to do both to this day).
posted by Four String Riot at 9:17 AM
---------------------------
I mean, maybe some sort of organization of OSS maintainers could have helped but they mostly weren't working for anyone or getting paid when these projects started so it wouldn't have been a traditional union exactly.
The idea of a FOSS union isn't so far-fetched. There would need to be some organizing to get a reasonable proportion of currently-unpaid or -underpaid maintainers to join up, but I bet a bunch of tech corporations would sign up to fund that organization really quickly if an OSS maintainer strike happened. (All the trillion dollar tech companies make extensive, unpaid use of OSS code, to the point that it would be at least a moderate crisis for them if even a dozen or so core projects stopped getting security updates.) (And yes, there would be collateral damage to noncommercial users; hopefully minimized, but unavoidable.)
(Striking without having that org in place would likely mean tech companies just hiring maintainers and/or forking, which is a much worse outcome since it would put those companies even more firmly in control of the OSS ecosystem, and also mean no protection for the next round of maintainers.)
posted by reventlov at 9:24 AM
---------------------------
And yet, the vast majority of open source software that people depend on mostly adheres to a number of conventions. Especially the old, deeply-integrated projects like rsync.
The vast majority of open source software that people depend directly on is also maintained by paid developers.
The main reason why volunteer-maintained projects continue to be capable of causing as much widespread disruption as they do is the mind-boggling size of pretty much all modern software's dependency tree. One failure in one component can now have consequences that spread faster and wider than anybody not inured to the monstrous jankiness of the IT industry would ever consider plausible.
posted by flabdablet at 10:02 AM
---------------------------
meanwhile my 10 line bug fix PRs are carefully scrutinized for stray whitespace and grammar mistakes in the comments, lol
posted by ryanrs at 12:48 PM
---------------------------
I agree that the soup kitchen analogy isn't super helpful here. I prefer the one that a friend of mine came up with: shitting in the swimming pool. It doesn't matter if you're the sole owner/operator of the pool! It doesn't even matter if you hang a sign on the wall explicitly disclaiming responsibility for shit in the pool! If you shit in it, people do in fact have a right to be mad that you just shit in the pool they were swimming in!
posted by adrienneleigh at 2:23 PM
---------------------------
Once again, no. The old pool is still there. You can still swim in it. He built a new pool. Don't like the new pool? Stay in the old pool.
Seriously, I despise gen AI, but that analogy is stupid.
posted by agentofselection at 4:53 PM
---------------------------
If there's one thing that pisses me off more than LLM hucksters, it's entitled whingers shitting on people who've given them useful stuff for free.
Have you met the internet?
posted by Greg_Ace at 6:08 PM
---------------------------
Maybe the concept of "masters" or Great Men in open source is bad
Maybe. But having worked with Old Hands in software engineering, I've learned the hard way that their own experience is Hard Earned and that they are Rarely Wrong. I'd put more stock in their views than what some randos with Little To Zero Experience at this craft have to say. Especially where there is often a, say, 1:1 million developer to (ab)user ratio in open source projects for core tooling Every One Of You are using in one way or another, either directly or indirectly - And For Free, no less. In My Own Humble Opinion, of course, based on my own lived experience.
posted by They sucked his brains out! at 6:15 PM
---------------------------
It would be a little easier to take that kind of hagiography seriously if one of the exemplars of the type you're lionizing hadn't just shipped multiple regressions under cover of a security fix after slopping up the test suite.
posted by Four String Riot at 1:08 AM
---------------------------
I wrote what I considered to be a charitable analysis of what had happened before Tridge wrote his medium-dot-com piece. The point I tried to make in there is that if someone as skilled and insightful (and, yes: careful) as Tridge couldn't avoid slop-collapse when using LLM tools, then no one can.
That is, if you were to ask me who I thought it would be possible to make judicious and effective use of any programming system they saw benefit in, I'd have a short list of maybe a dozen names and Tridge would absolutely be on that list. Since it looked like he'd bottled it, that seemed a pretty strong argument against LLM coding overall.
Now, Tridge wrote in his essay that we're all misinterpreting the causal chain here, and it was actually some rushed security fixes that caused these regressions. But others fired back that the regression tests were exactly what was LLM-coded in these newer versions. I'm not sure if anyone's found a smoking gun either way, yet. This is specifically why when I wrote my little post, my conclusion was structured "if x then y". Some extremely capable folks are still convinced that x holds true.
To those of you talking about licenses, that's a stopgap. Yeah sure the right to fork is enshrined, and that was absolutely understood by everyone. That doesn't mean "stop complaining you bozos": what was going on in all this discourse was largely a bunch of people scrambling to work out who they'd trust to take over human stewardship of software that is a fundamental piece of modern information systems. The broken versions are slowly dripping into OS releases, and when they do things will start breaking.
So yeah, some said openrsync, some said a rust rewrite, others talked about cool hacks involving zlib chunking, and still others just held their head in their hands and wondered how we'd get all these distributions of Linux to agree on the same replacement in a short timescale. Scolding people about the right to fork is a lot like XKCD 1357: human interactions are the main point here, and the formal legal systems are a last resort.
posted by rum-soaked space hobo at 1:22 AM
---------------------------
agentofselection: "Once again, no. The old pool is still there. You can still swim in it. He built a new pool. Don't like the new pool? Stay in the old pool.
Seriously, I despise gen AI, but that analogy is stupid."
Unless you pin your dependencies carefully, you're going to get picked up and put in the new pool regardless of your feelings about it! Downstream package managers are going to give you the shit-filled swimming pool instead of the older, shitless pool!
posted by adrienneleigh at 2:14 AM
---------------------------
There is some more context here, in that what Tridge is experiencing is not the kinds of threads you've been seeing on Mastodon or perhaps on bluesky or tocktick or fabecook or poob or whatever.
It's targeted 4chan-style raids on the github issue tracker.
One thing Mastodon teaches us is that the conversations we see aren't the same as what other people in the same thread see. We grow accustomed to this, and tend to take it for granted that the OPs will receive a lot of other stuff that we don't have access to due to moderation or privacy settings on posts. But I guess not a lot of other systems work this way, and people don't often stop to think that they're not seeing the whole picture.
So I also don't fault Tridge for feeling aggrieved at the response he's receiving for all this. He's taking the worst of it, and it's not going to look good for anyone in the end.
posted by rum-soaked space hobo at 3:16 AM
---------------------------
Look, at the end of the day, if rsync is that important to your workflow and a new release breaks it, then the question really is:
"Why are you testing in production? Don't you have some combination of development, test, staging, and quality assurance environments where production critical changes are vetted before moving forward?"
Also: Yeah, it tridge couldn't do it well with these tools, then maybe it's just not possible to do it well with these tools.
posted by mikelieman at 5:54 AM
---------------------------
>"Why are you testing in production? Don't you have some combination of development, test, staging, and quality assurance environments where production critical changes are vetted before moving forward?"
Taking responsibility for your own computing environment is hard, boring, and thankless work. Pointing fingers at LLM's is easier, more emotionally satisfying, and more social media algorithm friendly.
The LLM spin on this is new, but the fundamental problem is not. IME everyone is hoping (and worse, assuming) that someone else is doing the testing, because nobody wants to pay for something that everyone will benefit from.
posted by mrgoldenbrown at 7:00 AM
---------------------------
"Why are you testing in production? Don't you have some combination of development, test, staging, and quality assurance environments where production critical changes are vetted before moving forward?"
In my IT job, our testing is at best an approximation of production. We do tons of testing in production. Of course we do an test run through various environments first, but that doesn't really guarantee anything. The real environment is just more complex than our testers can manage in a reasonable timeframe - which is always crunched. testing always gets the short end of the stick.
This rewrite should not have gone in the same release as security updates. Releases with security fixes should have minimal changes, and include no changes that are not directly related to the security fixes.
This line is funny too. If you run a decent sized app, the number of managed security fixes is huge -like a guy working full time huge just to review and track them. There are literally thousands per week across the thousands of software products. Here's an example of just one . And that's not even talking the ones specific to your app, just to the 3rd party software you use! That's different.
You have to have amazing production procedures just to manage all this. Things have to be bundled because there are only so many days in a week.
posted by The_Vegetables at 7:50 AM
---------------------------
Another aspect of this is that we rely on frequent updates to get security fixes to essential components. That is, after all, what was in the changelog entries for 3.4.3 and the other affected versions of rsync.
We trust our operating system vendors to test builds and carefully only allow through changes that are trusted. Some of this trust gap shocked them as well, and they passed on broken code to end users without realising what dramatic changes were made in recent releases.
This isn't a new problem, and if anything the discourse on LLMs has shone a spotlight on events that have happened many times in the past. Some rolling-release distribution vendors are now stuck with the decision of when to package the latest rsync versions in their distribution channels. It's a difficult situation for absolutely everyone involved.
posted by rum-soaked space hobo at 10:04 AM
---------------------------
Thorough software testing is difficult, expensive work. It can be automated, but after a certain point the automation becomes a dedicated software project all its own, which needs to be managed like the product itself. It's a pain in the butt and not easy.
... Which is why I'm honestly quite annoyed at everyone yelling at tridge!
By all accounts rsync is effectively a single-maintainer project, and the maintainer is retired. Every layer between tridge and production is equally or (more likely) better-resourced than the project itself, from the Linux distributions doing packaging to the users running the code on their own systems. If your IT department is forcing updates, they should be doing testing, and however swamped they are they probably have a better chance of catching workload-specific issues than the upstream project.
I wouldn't personally have handled things the same way tridge did (I dislike LLM coding), but honestly if I'm mad at anyone it's the distros. While some of them are themselves volunteer projects, they are much larger and afaik they all have extensive automated testing of their own. And certainly the big orgs — Canonical, Red Hat, SuSE — should have caught this before their own releases.
posted by learning from frequent failure at 10:22 AM
---------------------------
I saw a post (on Mastodon, so I won't ever be able to find it again) that pointed out that even a tiny fraction of the trillion+ dollars (!!!) that have been spent on AI so far would be enough to provide thousands of open source maintainers with salaries.
Tridge says he wants to be sailing. We should fund a team that can take up the burden of rsync.
posted by aneel at 12:28 PM
---------------------------
others fired back that the regression tests were exactly what was LLM-coded in these newer versions
having chosen to ignore tridge's point that the existing test suite would not have caught those regressions either. Which was the entire point of improving the test suite. Which he did conservatively enough that the initial release of the replacement test suite performed the same tests as the suite it replaced.
If he's done it right - and I have absolutely no reason to believe he wouldn't have - adding more tests that do cover those regression cases is now a more straightforward exercise than it would have been before.
Basically what this whole thing is about is folks just feeling entitled to their little whinge. If I were in tridge's shoes I'd be saying fuck that noise and going sailing. We're all incredibly lucky he's more conscientious than me.
posted by flabdablet at 4:18 PM
---------------------------
Depending on your take, the statistical analysis of bug rates in commits at rsync that include work by Claude is (a) too early to tell or (b) same as it ever was.
posted by k3ninho at 2:25 AM
---------------------------
→ one can look to the BSD community for sanity.
openrsync.org: an almost-bare web page with six links. Three of those links — Goals, Features and Presentations — are empty pages with the body content being "...". None of the other links seem to be to directly downloadable anything. Tridge also notes that openrsync fails roughly 86% of the rsync test suite.
rsync on Mac is now openrsync because of Apple's allergy to GPLv3, compared to the old-enough-to-vote version of rsync they'd been using previously. And — surprise! — rsync functionality that worked on older versions of macOS may not be working now. Whee!
posted by scruss at 10:19 AM
---------------------------
I don't think the volunteer maintainer of an open source project owes anyone an explanation of their development processes, and it's always unpleasantly shocking to see how many people apparently disagree.
Or at least, if I was Tridge, I'd certainly let people who wanted to discuss my tooling preferences know what my consulting rate would be for that conversation. Otherwise... the "Fork" button is right there.
posted by Kadin2048 at 10:28 PM
---------------------------
More generally, is there a conversation to be had about what, and how to measure ,the effect LLM-aided tools have on software quality? Definitely—but good lord, was this not a good test case.
I think in the next 12 months we'll probably start to have some decent numbers on AI code and various quality metrics.
We'll know when the jury is back in, if we start to see the really adversarial, competitive corners of the software world—exploit generation, drone warfare, or maybe stuff like payments / fraud analytics—start to develop a consensus opinion on LLM tools. Because in those areas, there's a brutally objective yardstick for quality, formed by other humans' efforts. If AI tools actually let you do better credit card fraud detection than traditionally-built software, just as an example, it should be pretty obvious in a year or two when nobody else can compete.
posted by Kadin2048 at 10:57 PM
---------------------------
My firm expectation is that LLMs will enable orders of magnitude more fraud than detection. Way easier to break stuff by throwing spaghetti at the wall until something sticks than it is to fix stuff that way.
posted by flabdablet at 1:29 AM
---------------------------