

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


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:
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


- 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


Logic gates are hardware, not software


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


He has made a large number of questionable comments, including the argument that the solution to human trafficking includes legalizing child prostitution:
27 April 2015 (Human Trafficking Act)
The Senate’s Victims of Human Trafficking Act is dangerous in several ways.
When it talks about having the customs agency do more to enforce “intellectual property”, I am sure that refers to something bad. Whenever that term is used, something nasty is afoot.
The way to protect children from being forced into prostitution is to legalize prostitution by licensed prostitutes. Customers could be required to check the prostitute’s license. If the customer fails to check, that concrete omission would be legitimate grounds for punishment.
Minors should not be denied prostitution licenses in a blanket way, but the state should ask them why they want one and probe their situation, then offer help so they can avoid prostitution.
https://www.stallman.org/archives/2015-mar-jun.html#27_April_2015_(Human_Traffickting_Act)


Frankly, it sounds like neither of the two should lead the FSF


Well, maybe you’d better wait 10min instead of one, to make sure the led lightbulb heats enough, but still…
I tested this with a 5W IKEA LED light-bulb, since I was just doom scrolling, anyway:
This means that the solution either breaks down entirely, or is unreliable, since you are not (reliably) able to tell the first two buttons apart


Loop labels are rare, but they lead to much simpler/clearer code when you need them. Consider how you would implement this kind of loop in a language without loop variables:
'outer: while (...) {
'inner: while (...) {
if (...) {
// this breaks out of the outer loop, not just the inner loop
break 'outer;
}
}
// some code here
}
In C/C++ you’d need to do something like
bool condition = false;
while (...) {
while (...) {
if (...) {
condition = true;
break;
}
}
if (condition) {
break;
}
// some code here
}
Personally, I wouldn’t call it ugly, either, but that’s mostly a matter of taste


C++ is even worse, due to templates and the so-called most vexing parse. Initializing with {} mitigated the latter somewhat, but came with its own set of woes
Once you’ve learned it, Rust is just a very nice compiled language to work with.
You get higher level constructs than in C++, a language without a billion weird edge cases, a modern package manager, and much more. In my experience, my code written in Rust is more likely to work as intended, both because of the stricter compile-time checks, but also because language features like sum types make it easier to check the core logic at compile time.
I work in both C++ and Rust, among other languages, but these days I never reach for C++ for a new project