← Back to context

Comment by spookie

9 days ago

From my own experience the alternatives are fine as long as the distro maintainers put on the effort to make them work.

I've used Devuan and others with runit, sysV, s6 and openrc. And honestly, openrc is the better alternative from an user perspective.

Nevertheless, it is hard to argue against systemd when the critical mass is there, and you run into eventual problems.

Still, I find alternatives such as runit and openrc easier to reason about than systemd. Perhaps this is due to the need to fully grok them, so you're able to fix issues yourself. Contrast that with systemd, where there are plenty of drag and drop solutions out there, so that requirement is lessened. You could also argue the real reason is systemd's complexity, but personally that doesn't feel like the core reason.

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.

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

      1 reply →