Comment by rollcat
9 days ago
> Either way, it's good that there are alternatives. I like how heterogenous the whole Linux ecosystem can be, it helps mitigate large scale security issues.
IMHO all it does is drive fragmentation and marginalisation. Either your alternative is successful enough that third parties are compelled to care about it (making the integration work on their part more painful, which is often "solved" by using Electron); or it isn't, so you have to bring in your own integration (aka glue).
Sorry but Ballmer was right: developers, developers, developers. Users add value, developers multiply it.
I see your point, fair if you prefer it.
But I don't see it as fragmentation, but as competition. The better idea tends to prevail, and it's nice that the environment allowed alternatives to even try :)
hell, systemd itself happened as a esult of this environment :)
Some competition is OK. For example, similar programming languages (e.g. Rust and Zig) - they inspire each other, fit slightly different niches, and there's plenty of space for both.
Experimentation is OK. DNF started as a yum fork, with a different solver algorithm. IMHO yum should've just adopted the algorithm, but Fedora/CentOS ended up switching. That's mostly fine (people had to update docs, retrain their muscle memory).
The level of "competition" we see in package managers, desktop environments, initrd builders (!), resolv.conf managers (!!!), is just wasted effort. There's no "pick the winner", it's "everyone is a loser".
<https://tailscale.com/blog/sisyphean-dns-client-linux>
DNF didn't start as a competitive fork of Yum, it started as the Python 3 rewrite of Yum from the same developers. It was really just Yum version 4, using a different name so it could be installed in parallel with Yum for an extended period of time. Yum changing algorithms was never on the table, as that Python 2 code had to get phased out. Fedora, CentOS, and RHEL switching to it was always the plan.