Ariadne Conill 🐰
it is beyond frustrating how much damage / misinformation the anti-systemd/anti-wayland/anti-woke Linux weirdos have spread throughout the years
i just want to ship an operating system using the best technologies available that are relevant to the mission. sometimes that means working with technology introduced by red hat, other times it means rejecting technology introduced by red hat
mcc@ariadne I found the complaining about systemd super irritating but then I tried actually using systemd and Wayland and they actually are vry frustrating technologies! I think the problem with both these systems is that when there are problems they inhibit you from fixing them yourself. If part of systemd doesn't work right it's hard to just replace it because systemd is greedy & wants to manage so many things. Wayland encourages hyper fragmentation, so if GNOME lacks the bit you need you're SOL
ShutterBugged@mcc @ariadne Modularity, to the point where components could actually be swapped out, would cure many of systemd's ills because better alternatives could step in. If you look at what systemd "replacement" projects spend most of their time doing, it's building things like elogind that replace some critical portion of systemd's functionality without dragging in the rest of the elephant.
JdeBP@developing_agent @mcc @ariadne
That's because systemd-logind, which is massively coupled to everything and not very cohesive, and is also never packaged as an individual thing, is and was one of the root causes of the problem.
Even just separately packaging it would have avoided much of the original Debian Hoo-Hah in 2013, as I pointed out back then.
@developing_agent @mcc @ariadne
Even simply separately packaging binaries and hooks *today* would avoid the problem whereby the systemd-all-in-one package always installs all possible runtime hooks, some of which try to spin up systemd-logind, and systemd itself, by various surprising back-routes.
http://jdebp.info/Softwares/nosh/guide/services/systemd-logind.html
Gerrit Pape had packaged runit-run and runit-init separately from runit, and this was the model to follow.