[30.05.2026 10:05] andrewtridgell
I reviewed it. The rsync project has been essentially a single developer project for about 20 years now
[30.05.2026 10:06] andrewtridgell
Wayne did it all himself for a long time, now I'm back doing it
[30.05.2026 10:06] realketas
why is it one man job, it seems like too complex for that
[30.05.2026 10:06] realketas
i can't even imagine
[30.05.2026 10:06] andrewtridgell
nobody else volunteers. Its the same story with thousands of open source tools
[30.05.2026 10:07] realketas
it runs entire planet, just one man does it eh
[30.05.2026 10:07] realketas
sad too
[30.05.2026 10:07] andrewtridgell
the linux kernel has thousands of paid full time devs. rsync has zero.
[30.05.2026 10:15] andrewtridgell
the most insane part is that security releases can't be community tested. Those security releases are going to be a huge part of lots and lots of open source projects for a while to come yet, just look at the rate of CVEs over the last couple of months, its gone nuts. You can't do a beta release of a security fix as its embargoed. So for the most critical fixes you *can't* have anyone else look at it. The people reporting the flaws mostly don't have the skills as they used AI to find the bugs. So the maintainer is the sole person to review the most critical security changes, and that is how the madhouse called the internet and IT security is designed. The only defence I have is to build the most comprehensive and accurate test suite I can, so when I need to deal with yet another security report I can at least quickly identify what else the fix breaks. Luckily I can do that work (the dev of the test suite) in public.
[30.05.2026 10:22] andrewtridgell
bottom line is if you want to be useful then pick holes in the test suite, find things it doesn't cover, find interactions between options it doesn't pin down, report those and offer fixes for that.
Basically, it's a solo dev being swamped by LLM security reports, and since those are embargoed only maintainers can review them... and since nobody else has volunteered, he has to do it himself.
He primarily used several AIs to rewrite the test suite from shell (slow, lacking coverage) to python (parallelised, improved coverage). He says he's extensively reviewed everything, but I guess the suite doesn't cover everything. And the test suite changes can be community reviewed.
The dev has been actively inviting people to join as a maintainer and poke holes in the test suite, but it seems nobody has stepped up. I can't really blame the dev here, he just seems unable to keep up without others helping him out. He's tried to use AIs as sensibly as he could, and I'm not entirely sure if it's slop fixes that cause the issues (or if an "unassisted" fix would have caught it).
This is an older article. Ubisoft was (and is?) pulling some shady shit here though. What they're doing:
So for a new player to get started, they'd get the base game for free, with Valve paying for all the costs related to the download infrastructure, etc..., and then pay Ubisoft directly for their ingame starter gear, bypassing Valve entirely. This was just an attempt by Ubisoft to skirt by Valve's rules.
Valve is extremely lenient when it comes to this sort of stuff. But they're not going to allow a publisher to abuse the system to essentially get free game distribution via Steam while still making a profit via this side channel. It's basically a way to bypass the Steam key resell rule, where Steam keys may not be resold for lower prices on other platforms (but you don't have to pay the 30% fee when you do).
To put Ubisoft's case to the extreme, imagine a game comes out for free on Steam, but opening it opens up another storefront where you first need to pay 60 bucks to actually play the game. Does it make sense for Valve to continue offering their services here if they are blocked from making any money off of it?