This is the guy who accidentally forced the creation of git, by reverse engineering the BitKeeper protocol and getting all the Linux kernel developers' licenses revoked. Chaotic Good energy.
this post was submitted on 03 Jun 2026
248 points (97.7% liked)
Programming
27159 readers
341 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
So i dug up a bit about Andrew Tridgell:
- The reverse engineering details: https://lwn.net/Articles/132938/
- License offering and revocation: https://github.com/CuriousCurmudgeon/history_of_vcs/blob/master/06_bitkeeper.md
Hooray! It's good to see another retired dev with 40 years exp respond more eloquently than I ever can to the flood of anti-AI rage. What gets me most about the rage is the absolutism - the flat assumption that anyone who uses AI is either stupid or evil. Period. There's almost no genuine engagement on the topic, mostly just angry shouting. But you see that a lot online - some people think social media is Fight Club.
If you read through the comments here you'll see a ton of nuanced comments, I think undercutting your claim. At the same time, this is also an interesting issue because you're trying to play the centrist role. But on this issue there is no centrist role, and actually you've just played the pro AI role while pretending you didn't do that.
Because think about what happened. The developer used AI and it introduced bugs and that was bad for people. These are the facts. So the people are saying hey can you stop using AI and the developer is shrugging their shoulders.
What's the middle ground that you're looking for here? Recognizing that it's possible to use AI harmlessly? But that's not what happened. If it had been harmless used then no one would have brought up the issues in the first place.
The developer used AI and it introduced bugs and that was bad for people.
Was it the AI that introduced bugs, or them, while working with AI there or in other parts?
Would the bugs not have occurred if they made the changes without AI?
Would they have made any changes without AI? Would we be better off without changes for security robustness?
You make it sound like a direct correlation. Having read their response, that seems like an assumption without reasonable foundation.
Changes always have a risk of introducing bugs.
I'm no friend of using AI without the necessariy expertise, but from their response, they seem to have taken a very thorough, reasonable approach, and they seem to have the expertise to do so.
I think there is more nuance or spectrum than good or bad. Vibe is one extreme, but along the dial from traditional to pure vibe are degrees of involvement. I'd characterize the degrees something like:
- No AI, just elbow grease
- AI as just auto complete on steroids
- AI generating more complete change sets, but still from focused, more surgical specs, and still a human review on everything
- "Spec-driven development" where, as I see it, you're engineering a multi-agent-role workflow to intersect different contexts and iterating to try to converge on carefully designed specs
In 3 of those 4, the human is fundamentally the one owning the output, and AI is an accelerator and potentially an influence, kind of like pair programming. And even the SDD workflow can be a human-in-the-loop approach, although the more agents produce autonomously, the harder it might be for a human to be effective at reviewing the output.
So I'll agree that "use it or don't" is a binary, but I'd just add that there's still a spectrum of how it's used.
When I rant about polarization of AI discussions I'm talking about on social media generally, not this one remarkably civil thread. But even your use of the term "roles" is doing it - you're assigning black hats and white hats to the participants instead of focusing on what they're saying.
Speaking of which, where do you get the idea that the author introduced bugs by using AI? He says that in his work to improve rsync by beefing up test suites, integration testing etc he used AI to do grunt work, and thoroughly reviewed every bit of it. He explains this very clearly, and I don't see the part where his use of AI created more bugs.
I am pro-AI - I'm interested in its development and looking forward to it getting better. What we have right now can be very useful, but it's kind of like 1980s 8-bit graphics video games. It hallucinates too often and is unconscionably resource-heavy. I'm very much against its overdeployment and misuse. Companies are charging into implementing AI like middle school boys who just figured out how to find free porn. They see it as yet another magic wand to reduce headcount - which is their endless quest. But blaming AI itself for this is like blaming a saw for wasting lumber or for not being a better saw. Blame shitty carpenters who use it wrong.
Repost of my reply elsewhere:
This guy is already retired, he wants to spend his days sailing and here we are bitching about rsync not being good enough while we all use if for free
Most of us won't be able to help code, fine.
But most of us could help with translations
Many of us could help with documentation
Some of us could contribute regularly with small financial donations
Some of us might have enough knowledge and expertise and experience to help code
Others could come up with other tasks that could be done.
The point is: rsync need more resources. Either we get him more resources or we STFU about the retired dev using AI. We can't have it both ways.
I think it's unreasonable to complain that the guy is not working enough for free.
I think it's reasonable to alert people that rsync is not being properly maintained anymore and to seek alternatives.
I would prefer the maintainer to announce publicly that he can't maintain the project anymore and is looking for help/someone to take over instead of breaking the project silently.
But where will the maintainers for these alternatives come from, when barely anybody has stepped up in the 30 years of rsync's existence? Your comment implies that tridge didn't call for help before, which is far from the truth.
This is thankless maintenance on critical software, not some *-arr toy project for hobbyist self-hosters.
But where will the maintainers for these alternatives come from, when barely anybody has stepped up in the 30 years of rsync's existence?
Universal Healthcare would increase the pool of willing developers by an order of magnitude here.
load more comments
(7 replies)
https://github.com/rclone/rclone
https://github.com/restic/restic
https://github.com/bcpierce00/unison
The thing with old, critical software is that after some time people don't really want to dig through decades of C code and prefer to write something new using modern tools. Those projects get plenty of support because people actually do want to work on them. If no one wants to work on rsync than what the maintainer is doing now is just prolong it's agony a couple of years. I would say he should do the minimum work, announce end of life date and move on. People that need tools like rsync will develop something.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
I'm sorry to say 90% of the internet's load bearing infrastructure is in this situation. It's just how the story goes, everybody wants to build low-stakes toy projects, nobody wants to do high-effort low-reward infrastructure work.
"Writing something new using modern tools" is all fun and sparkles, but then you run into the same issues as rsync except without the experience. Then you get attention from attackers, you get security issues, which you have to patch with defensive code which is not appealing to read and zero fun to write. Before you know it your project is "decades of Rust/Zig/Lisp" which nobody wants to touch and you're back at square one. All you've accomplished is give the attackers a few years of low hanging fruit and easy exploits.
There's a reason why we get a million shiny toys a year but solutions like rsync stay entrenched for decades.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Here are the percent of commits from the top committer in each repository you mentioned, as well as rsync, over the last 3 months:
- rsync: 99.0%
- restic: 93.2%
- rclone: 87.5%
- union: 82.9%
- syncthing: 74.4%
As you can see, each of this projects depends heavily on a single person, though to a lesser degree than rsync. That's just the nature of most open-source software.
Note that I excluded dependabot commits from the calculations and counted Claude commits as the lead developer for rsync
load more comments
(10 replies)
load more comments
(1 replies)
load more comments
(5 replies)
This whole debacle is making me extremely black pilled about open software in general. Just like cheap computing has died in recent years, I suspect non corporate free software is about to meet the same end to the acclaim of people who think they're doing a good thing for the world.
Do you mind describing what black pill means in this context? I'm familiar with the red/blue pill references, but could only find the incel context of black pill online. Is it just a "harsh truth" kinda thing?
Sorry for bringing terminally online slang to the table haha
In my head yeah it's the pill that teaches you a bleak and depressing truth but shows you no way out of it. I may be misusing the term.
load more comments
(6 replies)
load more comments
(2 replies)
load more comments
(8 replies)
Seems like he’s been pushed into using LLMs as a way to cope with the deluge of LLM-generated security reports
It's not just LLM generated security reports, but vulnerabilities discovered by AI. Your wording implies they were just reports, and of less validity. Lazy LLM reports are not what he is trying to cope with, since there is nothing to do but close those reports. He is talking about real, verified, vulnerabilities that weren't discovered until AI tools. Not because humans couldn't find them, but none ever did. When it comes to finding, it really doesn't matter if it's found by human or AI, since that doesn't change its existence or severity.
And the side that noone else talks about, threat actors are highly likely to be using ai to find these potential vulnerability. So you you are not doing the same you are immediately at a disadvantage
I am reporting that every line of your code has 17 errors. I just generated 1562364 bug reports for you. Now you just need to close those that are false, no big deal.
load more comments
(4 replies)
I used AI tools to do the grunt work because they are good at that.
This is something people complaining should remember. AI is good at some parts of the work of a software engineer: the grunt work.
People pointing at new breakages are trying to say "No it isn't and here's the proof".
load more comments
(5 replies)
Apparently not good enough, if we look at the case of rsync. Remember, this while conversation started because of some show stopping bugs caused by generated code.
As a software engineer, the grunt work is reasoning about my code, something a statistical model can't do.
I can't wait for companies to finally price out most of developers out of AI use, especially the FOSS ones.
I just hope most of them won't get too addicted to the tech crack they are getting free/cheap samples of currently, and will be able able to find back their motivation and skill to work without a feel-good dopamine machines.
Also, lol at all the coments being like "if you're 100% against the tech crack, you're delusional. The cat is already out of the bag, it makes you way better at coding, if you use it responsibly!"
The problem isn't that it's not somewhat good, the issue is that soon you won't be able to afford it, while also being addicted and dependant on it. But I'm sure y'all are able to use crack responsibly and will be fiiine.
load more comments
(21 replies)
Also, nobody actually knows if human intelligence is just finer grained stochastic prediction as well.
An interesting but valid argument. It doesn't make AI better than it is, but any human contribution and change can and often is also faulty. People have gaps of knowledge, sometimes unwarranted confidence, other times lack of care, or just miss things. It's not like we're comparing the perfect human vs faulty AI.
If you don’t mind the security risk then you can of course use an older release.
I haven't read the original rage/drama but I can imagine if from other drama instances.
This post is certainly a good, founded response.
There's some valid concerns in AI usage, but unwarranted or inappropriate harsh criticism when it's an established trusted developer and engineer - if we assumed good practice before then we could assume continued good practice. Maybe LLM is one point of increasing skepticism, but criticism should be open, respectful, and fair.
They invested a lot of time and effort into a public good project. In that context, they deserve at least respectful and non-worst-assumptuous criticism.
load more comments
(14 replies)
view more: next ›