People adopted systemd because it solved their problems.
People adopted Rust because it solved their problems.
Open-source has always been essentially a do-ocracy. Lots of work happens primarily because the people actually doing the work want it to happen, and they decide how to get it done, too. Systemd made maintaining a distribution vastly easier and solved problems that the alternatives weren't addressing, and the maintainers are doing the work, so they made the decision. This is no different.
It's also pretty ironic to call the Rust community culty - in comparison to GNU!
Don't like it, don't use it - same with systemd. I'm not sure what the complaint is. When Go is used to rewrite something, nobody complains. Also, you should find out what a cult is and do some research on past cults before you start accusing a project of being a cult.
We're commenting on an Ubuntu discussion where an Ubuntu developer is proposing to make this mandatory for Ubuntu. Even when the alternatives system is suggested, that's quickly dismissed, because the real aim is to boot out coreutils permanently and make written-in-Rust the default.
I don't mind people writing things in their favourite languages; I do mind them trying to compel me to adopt them through distro shenanigans. Even though Debian adopted systemd, it didn't do it without a _lot_ of discussion and voting.
> Even when the alternatives system is suggested, that's quickly dismissed, because the real aim is to boot out coreutils permanently and make written-in-Rust the default.
They have good technical reasons why they aren't using alternatives at this stage, and it's also suggested that if this gets closer to being real, the alternative system will be used.
What are those technical reasons? The only answer I see in the linked thread is https://discourse.ubuntu.com/t/carefully-but-purposefully-ox... which points out that it requires cooperation from the existing package (fair), but also notes that "Diversions would work"... before moving on and not even hinting at why, then, diversions were not used and a new tool was thrown in the mix.
> it requires cooperation from the existing package (fair),
That is a technical reason. I think it's a good one, you may disagree. I think it's fair to start out this way and then eventually move into the alternative system once it's proven itself out.
> but also notes that "Diversions would work"
I've never even heard of Diversions, so I can't comment on that.
> Diversions allow files from a package pkg-A to be temporarily replaced by files from another package pkg-B. When pkg-B is uninstalled, the files from pkg-A are put back into place.
> Do not attempt to divert a file which is vitally important for the system’s operation - when using dpkg-divert there is a time, after it has been diverted but before dpkg has installed the new version, when the file does not exist.
Thanks, that explains it. Coreutils certainly counts as "vitally important for the system’s operation"... Though I do wonder whether it wouldn't be reasonable to fix that limitation rather than make a new tool. That said, even if that is the better solution I do kind of get not wanting to go to that trouble for this one off.
