things being tightly coupled to a single init is not good, it’s an absolute tragedy. projects that tightly couple to a single init are abandoning non-linux Unix operating systems
and who do you think runs and monitors kubernetes? oh that’s right: systemd or another alternative. low level task schedulers cannot be rendered obsolete, not unless you’re handing off responsibility entirely to another entity, but if you should do this, you still need to be aware that you are paying that entity to manage the task scheduler for you. it didn’t become irrelevant. you just shifted the shared responsibility model
I’m not sure why GNOME, the EU, etc should spend money on supporting Desktop BSD when that money could be better used building features to dethrone Windows.
Again, if another init had features that were better than systemd, then they’re welcome to step up. Sometimes software just becomes natural monopolies, not too many people complain that linux distros don’t support WolfSSH, or musl C. Nobody complained that sysvinit was a monopoly in 2010.
Of course, even kubernetes servers still run init, but their importance has greatly diminished, including the arguments about what features are needed and the best way to write service definitions. Most of the tasks are now handled by newer cloud-native service orchestrators.
My kubernetes nodes have 17 processes that are not managed by Kubernetes. 5 of them are systemd or systemd-project daemons (journald, oomd, udevd, and logind). 3 are dbus related daemons, 2 are prometheus metrics exporters, and then sshd, agetty, nsncd, chronyd, polkitd, and fwupd. Finally, there’s k3s, which starts and runs all my containerd processes for Kubernetes. On these systems, Kubernetes is managing 500 or more processes that systemd has nothing to do with.
I don’t actually interact with systemd at all on my servers, aside from scraping journald for system logs, seeing if services are down, and occasionally restarting services in a broken state. All the service definitions were included by NixOS.
I use systemd because I like all the features that NixOS and Gnome have, I couldn’t care less if they replaced it with whatever, as long as it stays out of my way.
wow a lot to unpack here…
I’m not sure why GNOME, the EU, etc should spend money on supporting Desktop BSD when that money could be better used building features to dethrone Windows.
Again, if another init had features that were better than systemd, then they’re welcome to step up. Sometimes software just becomes natural monopolies, not too many people complain that linux distros don’t support WolfSSH, or musl C. Nobody complained that sysvinit was a monopoly in 2010.
Of course, even kubernetes servers still run init, but their importance has greatly diminished, including the arguments about what features are needed and the best way to write service definitions. Most of the tasks are now handled by newer cloud-native service orchestrators.
My kubernetes nodes have 17 processes that are not managed by Kubernetes. 5 of them are systemd or systemd-project daemons (journald, oomd, udevd, and logind). 3 are dbus related daemons, 2 are prometheus metrics exporters, and then sshd, agetty, nsncd, chronyd, polkitd, and fwupd. Finally, there’s k3s, which starts and runs all my containerd processes for Kubernetes. On these systems, Kubernetes is managing 500 or more processes that systemd has nothing to do with.
I don’t actually interact with systemd at all on my servers, aside from scraping journald for system logs, seeing if services are down, and occasionally restarting services in a broken state. All the service definitions were included by NixOS.
I use systemd because I like all the features that NixOS and Gnome have, I couldn’t care less if they replaced it with whatever, as long as it stays out of my way.