From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management…
That’s almost like complaining that GNU coreutils is a disaster from KISS point of view because it includes too many things in a single project - cat, grep, dd, chown, touch, sync, base64, date, env… Not quite, because coreutils is actually a single package unlike systemd.
The core systemd is big (IMHO it needs to be in order to provide good service management, and service management is a reasonable thing to include in systemd), but everything you listed are optional components. If your distro bundles them into one package, that’s on them.
Systemd includes many complex things, coreutils includes many simple things. And coreutils are ported to many different OS’es, systemd is linux only. Ask why?
Lets imagine, my linux distro runs with openrc/upstart and I like systemd-journal features. Am I able to run system-journal without any other systemd components running?
It is well known that systemd’s service management is built around cgroups, which is a Linux-only concept for now. Other OSs have their own ways to accomplish similar things, but adapting to that would require huge changes in systemd.
Am I able to run system-journal without any other systemd components running?
No, the only part of systemd project that doesn’t depend on systemd core is systemd-boot. And there’s also elogind, which is an independent project to lift systemd-logind out of systemd.
But honestly, I don’t see the issue here. You can’t use systemd’s components elsewhere, but your previous complaint was the opposite - that systemd is everywhere, as if you were forced to use networkd, resolved (which pretty much no distro uses AFAIK because it’s way worse than other DNS resolvers), homed, timedated etc. when you use systemd as init.
Also, I have a correction for my previous comment: systemd-journald is not an optional dependency, as it’s used as a fallback if the configured log daemon fails. I’ve only learned after writing that comment.
That’s almost like complaining that GNU coreutils is a disaster from KISS point of view because it includes too many things in a single project - cat, grep, dd, chown, touch, sync, base64, date, env… Not quite, because coreutils is actually a single package unlike systemd.
The core systemd is big (IMHO it needs to be in order to provide good service management, and service management is a reasonable thing to include in systemd), but everything you listed are optional components. If your distro bundles them into one package, that’s on them.
Systemd includes many complex things, coreutils includes many simple things. And coreutils are ported to many different OS’es, systemd is linux only. Ask why?
Lets imagine, my linux distro runs with openrc/upstart and I like systemd-journal features. Am I able to run system-journal without any other systemd components running?
It is well known that systemd’s service management is built around cgroups, which is a Linux-only concept for now. Other OSs have their own ways to accomplish similar things, but adapting to that would require huge changes in systemd.
No, the only part of systemd project that doesn’t depend on systemd core is systemd-boot. And there’s also elogind, which is an independent project to lift systemd-logind out of systemd.
But honestly, I don’t see the issue here. You can’t use systemd’s components elsewhere, but your previous complaint was the opposite - that systemd is everywhere, as if you were forced to use networkd, resolved (which pretty much no distro uses AFAIK because it’s way worse than other DNS resolvers), homed, timedated etc. when you use systemd as init.
Also, I have a correction for my previous comment: systemd-journald is not an optional dependency, as it’s used as a fallback if the configured log daemon fails. I’ve only learned after writing that comment.
I can see you are much more familiar with systemd and thank you for details.
But still I think systemd hardly follow KISS principle.