Exactly what the AI evangelists are doing.

But not because anybody asked for that. It is part of the force feeding so execs can make this exact argument, and pretend that demand is there.

Even if they were an option, your 300ms latency requirement would exclude them anyway.

This has been tried extensively e.g. in Germany, France, Sweden, Canada, …. It did not work out great.

I guess they will have to introduce some kind of trust-based system.

I do not think we should be eternally grateful for monopoly building.

I do not think subpar means what you think. Or maybe you rewrote the sentence and forgot to change that word? Anyway, this does not make sense.

> Why do you decide what is in scope for the rsync project and what not?

If you are arguing for making sandwiches being in scope for rsync, you proved that you are just a troll. We have reached the end of reasonable discussion.

And you will not notice the obvious errors in its answers to even basic questions, because you are no expert and should have really consulted with one.

When talking about their own area of expertise, almost everybody immediately notices the glaring faults. But then they are very impressed and take LLMs as gospel when talking about anything else. I do not get it.

That would require clearly (a) knowing what you want, and (b) expressing it unambiguously and in detail, including all edge cases. Essentially producing a spec.

Most people are not able to do either. Talking to an LLM does not change that.

2. Of course bugs should be fixed. I even say so in the comment you replied to. You are attacking a strawman.

3. People will always make feature requests. Some want rsync to be able to make a sandwich. That is not really in-scope for the project though.

I think the GNU coreutils are doing this largely right. New features are almost never added. ls, for example, is pretty much complete, and too foundational to mess around with. If you need fancy new features, use something like eza.

As an example, the entire test suite was recently vibe-replaced. An essential component for reliability and stability. And you can already see the results in the decreased stability and increased defect count.

If the author used AI for small, well-reviewed maintenance changes, that would be okay. But instead he is making large and sweeping changes that are entirely uncalled for and cause breakage.

If the maintainer is overworked, that is even more reason not to do this.