623 Followers
425 Following
1.3K Posts
@gentoo developer. Spends a lot of time on alternative platforms.
IRC (libera, oftc)sam_
GitHubhttps://github.com/thesamesam
Websitehttps://cmpct.info/~sam

I actually worked at the same place as Andrew Tridgell, over a quarter-century ago. I got to know a few of the OzLabs folks during their immediate post-IBM years, and always had the highest respect for them in that way where you feel acute impostor syndrome when they're in the room.

Tridge almost walked backwards into implementing the Windows SMB protocol (he was just debugging some funny NetBIOS extensions IIRC). But his paper on the #rsync algorithm was groundbreaking, and actually writing the tool to implement it was brilliant. It's become one of those tools like #curl that just forms one of the major structural supports of the modern Internet. I still remember the day that the SSH transport became the default, and I remember being able to thank him in person when he came to the San Francisco office (although IIRC by that point he'd handed control of rsync over to mbp).

I remember at my next job he came to a summit of folks working on print driver/spooler software. When he pointed out that some problems were effectively a cache-consistency algorithm, we all kind of put our fingers to our temples and said "Oh wow, you're SO right!" He was always insightful and sharp, while being gentle and approachable.

I write in the past tense because I haven't crossed paths with him in two decades, and only know what I see him put out. A friend of mine in Australia noted that he hasn't posted to the Canberra LUG list since 2020, thanking someone for congratulating him on receiving the Medal of the Order of Australia. He's very much alive, but from what little I see I grow concerned for him.

In 2024 he took over maintenance of rsync once more. The 3.3.0 release was the last one from the previous maintainer, and Tridge is currently working on 3.4.x releases.

Well... Tridge and #Claude, it seems: https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345332213390

The issue tracker for rsync has recently lit up with regressions, showing features that worked reliably for almost 30 years are suddenly coming crashing down in 3.4.2 and 3.4.3. People are scrambling to find ways to pin rsync to known-good versions. The considerate, incisive mind I briefly knew is letting the stochastic parrots do his work for him, and it just seems so astonishingly *unlike* the person I met back in the day.

I am still willing to give him the benefit of the doubt. I hope all is well for him, but I will not cast aspersions on his goals or his abilities. No, instead I draw this conclusion:

If TRIDGE of all people can't handle #LLMs without a slopocalypse, no one can.

That means you. That means someone you admire who is intelligent and careful and considerate. Not even someone whose opinions on technology you respect a great deal.

No one.

Jeremiah Fieldhaven (@[email protected])

So my systems recently updated to rsync 3.4.3, and as soon as that happened my backup system - which does incremental backups using multiple --compare-dest= arguments - started to fail on anything but a full backup. Revert to 3.4.1 and it works. So I go look at the source in GitHub to see what might have changed, because there doesn't seem to be anything relevant in the changelog. Since 3.4.1, 36 commits by "tridge and claude" Oh for fuck's sakes.

Gamedev Mastodon

So, look. One shot rewriting the whole test suite in another language is probably not great to do, but what happened here is so much worse than you are expecting.

https://github.com/RsyncProject/rsync/pull/903/

This does not "translate tests into pytest" or a unit testing framework, it writes its own testing framework where tests are whole python scripts that redefine basic test functions in every script. Surely there would be a single way to "run rsync and get the results" - nope, well, there is, but then every test file will randomly redefine its own _run_and_capture function. So like now rsync needs a test suite for its test suite.

If instead of telling an LLM to "rewrite the tests in python" you just searched "python testing" you would find the pytest docs. And then you would find examples. And then you could write fixtures to deduplicate all the prior shell script setup and teardown stuff, and so on. But since it was just "rewrite the tests in python" its now worse than before, and the odds of the rewrite actually being a 100% faithful translation are close to 0.

edit: more on the social element of "what if you just asked people how to rewrite in python" vs. Being trapped with the Orb I incompletely nodded to here: https://neuromatch.social/@jonny/116671260017373441

@samueloph @icing @ariadne remember that Tridge stepped up to work on rsync again when the prior maintainer stepped down and it was in serious need of help.

It’s a really important piece of software that doesn’t get the attention it deserves as a rule.

https://lwn.net/Articles/968732/

Tridge returns to rsync

Wayne Davison has announced the release of rsync version 3.3.0, which contains a number of bug [...]

LWN.net
@icing @ariadne although the recent regression contained AI-generated commits, the root issue is that rsync needs funding and contributors, the first serious regressions started on the CVE fixes of January 2025 (before AI was involved) and it was clear at the time that the project was in serious need of contributors/funding. I've started packaging gokr-rsync for Debian but ended up without enough time to complete it. Reverting rsync to pre-AI commits will not solve the issue unfortunately.

@tokyo_0 @glyph @dalias It's about consent.

If I have that rule and you upload LLM-generated code to my project, you've done it without my consent. If I never find out, then you managed to trick me and violate my consent without my noticing.

If you're in my home and I say "Please don't touch the family heirlooms on that shelf" and your answer is "Oh, but how would you ever know if I did?"... I start to feel I don't want you in my home any more.

Ah, they're imported from https://github.com/openbsd/src/tree/545ae0a97078ba9469aa24234bb840fa4a517dd2/regress/usr.bin/rsync

I obviously don't look at OpenBSD enough..

src/regress/usr.bin/rsync at 545ae0a97078ba9469aa24234bb840fa4a517dd2 · openbsd/src

Read-only git conversion of OpenBSD's official CVS src repository. Pull requests not accepted - send diffs to the tech@ mailing list. - openbsd/src

GitHub
Klara Systems has https://github.com/KlaraSystems/openrsync/tree/a548ebb10646d593fa21aa7b2dffe810163a8ab1/tests where they mention merging w/ another repo..
openrsync/tests at a548ebb10646d593fa21aa7b2dffe810163a8ab1 · KlaraSystems/openrsync

BSD-licensed implementation of rsync. Contribute to KlaraSystems/openrsync development by creating an account on GitHub.

GitHub

wrt openrsync: the repo at https://github.com/kristapsdz/openrsync doesn't have any tests, but Apple's does as https://github.com/apple-oss-distributions/rsync/tree/708962b7b1ec0fa6af1cca68d0639099ddac1c8d/tests/openrsync

The README.md in there implies the tests were imported from a BSD?

GitHub - kristapsdz/openrsync: BSD-licensed implementation of rsync

BSD-licensed implementation of rsync. Contribute to kristapsdz/openrsync development by creating an account on GitHub.

GitHub

I don't know how I hadn't discovered this sooner, but the Gardenhouse project (https://gardenhouse.pinkro.se/) is everything I've ever wanted. The novel systemd utilities reimplemented in a distro (and kernel!) agnostic way and fully stand-alone. Their tmpfiles.d implementation is particularly impressive.

#GardenHouse #Linux

Gardenhouse - Gardenhouse

Gardenhouse front page

It's time to stop this madness https://gitlab.gnome.org/GNOME/libxml2#strict-no-llm--no-ai-policy

After reading this great essay about the harm that LLMs are doing to open source communities I've decided to go full strict about LLM https://linguacelta.com/blog/2026/05/LLMs.html

https://toot.wales/@linguacelta/116600964539347661

GNOME / libxml2 · GitLab

XML parser and toolkit

GitLab