Those people are wrong. The 3.4.3 release passes all the integration tests in the 3.4.1 release’s test-suite, which is the last release without LLM code. You can easily test this yourself

That’s definitely a possibility, along with the possibility that countries with worse English language skills might be underrepresented on GitHub, despite having universal healthcare. Conversely, if the US is over-represented on GitHub, then the pool of US developers who are not already active on GitHub may also be depleted compared to other countries. However, that is not something we can read out of the available evidence.

The most we can conclude is probably that the US getting universal healthcare might result in an increase in available OSS developers, depending on which assumptions turn out to be correct, but suggesting that it would lead to an order of magnitude increase is surely premature

Universal Healthcare would increase the pool of willing developers by an order of magnitude here.

I’m not so sure. The problem is not a lack of developers. The problem is a lack of developers interested in working on rsync, or on any other specific project you can name. Most developers would rather work on their own projects.

I would also question whether or not universal healthcare (though unquestionably a good thing) would actually result in such an increase in available developers. The following study looked at the geographical distribution of OSS developers in 2021, via Github contributions, and found that the US had a similar number of OSS developers per capita compared to similar countries that do have universal healthcare (see table 2):

https://www.sciencedirect.com/science/article/pii/S0040162522000105

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

Yes, there’s been several regressions that would’ve been caught by the original tests, but missed by the new vibe-coded tests.

That is directly contradicted by what the developer of rsync wrote in the linked article:

yes, there were regressions in some use cases of rsync in the 3.4.3 release. … None of those cases were covered by the existing rsync test suite or by all the manual testing I did (yes, I use rsync, I don’t just develop it).

It’s possible that somebody in the issue you linked to pointed to a test that would have caught one of the regressions, but I was not able to find it in the 327 comment mess. A direct link would be appreciated, if that is the case.

But I doubt that you will find such a comment. Because I tried running the 3.4.1 test-suite with the 3.4.3 binary, and all tests passed

I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:

They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I’ve also had to write my own framework, for that reason, despite preferring pytest for unit-testing.

The author also greatly exaggerates the amount of code duplication: They claim that “tests are whole python scripts that redefine basic test functions in every script”, but in reality it is less than half of the tests that even define their own functions.

Most basic functions are imported from a shared module (rsyncfns.py), and when they aren’t it’s mostly because the code needs to do something different. From what I can see, there is some code duplication that could be moved to the shared module, and some code that could be refactored, but it’s a modest amount

That is not just a book about how to “cut potatoes”. That is “A Creative Cooking Guide for Exercising Knife Skills”, using potatoes as a medium. Similarly, your Rust book is an book on concurrency using Rust as a medium, as per the title: “Low-Level Concurrency in Practice”. Both are complex topics, and both have picked a medium. Thus, they do not necessarily reflect on the underlying complexity of the medium, though concurrency in Rust is a complex topic due to the fact that the core language itself does a lot of work to make it “safe”. Async would probably be an even better example of that.

However, in the case of initialization in C++ and in the case of move schematics in C++, these are topics that are complex because the core language has been accumulating complexity for a long time, and because the language designers cannot afford to break backwards compatibility. Which makes implementing and using move-schematics in C++, as an end-user of the language, much, much more complicated than in a language like Rust, that did not have to bolt this behavior on top of an already complicated language. Similarly with initialization, where C++ has accumulated many, syntactically overlapping forms of initialization, for both member and non-member variables variables

1. Crazy initialization That sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I’ve never seen used in the wild.

Initialization in C++ is so simple that somebody wrote a nearly 300-page book on the subject: https://www.cppstories.com/2023/init-story-print/

I plan to read it after finishing this 260 page book on move schematics in C++: https://www.cppmove.com/

But GCC did not improve their error messages (much) prior to Rust, despite Clang’s error messages comparing favorably to GCC even before Rust 1.0 was released, as for example discussed in

https://gcc.gnu.org/wiki/ClangDiagnosticsComparison?action=recall&rev=1

Rust itself is 14 years old, slightly older than above wiki page, and even back then it had great error messages, though they’ve also improved since. Here’s a fun site where you can see how error messages have evolved through Rust’s life:

https://kobzol.github.io/rust/rustc/2025/05/16/evolution-of-rustc-errors.html

It’s only very recently that GCC has started to catch up, for example with some nice improvements in GCC 15:

https://developers.redhat.com/articles/2025/04/10/6-usability-improvements-gcc-15

Hopefully nobody tells the corpos that they can just use BSD if they want a MIT licensed kernel and user-land

To be honest, they didn’t make it easy to find

While WinRAR is pretty great, it has also had several severe security vulnerabilities over the years, including one last year:

https://en.wikipedia.org/wiki/WinRAR#Security

Which isn’t quite what you’d expect from “perfect” software

The 2021 release of Tex included several bug-fixes, so not quite 12 years:

https://tug.org/texmfbug/tuneup21bugs.html

See also the following list of potential bugs, that may be included in the planned 2029 release of Tex:

https://tug.org/texmfbug/newbug.html

That said, Tex is still an impressive piece of software