Originally posted by pixo
View Post
PID1's job (whether it is a script, a old-school linux's "init" style executable daemon, or the current systemd's replacement) has always been being in charge of starting-stoping things.
Except that, in the past, that function has been spread across several completely different daemons ("init" for startup/shutdown, "cron" & co for time schedule-based execution, "inetd" for network triggered, various esoteric solutions like tinydns' very own "/service" system, dbus' own sub-service spawning, various watchdogs, etc.) and would require extensive hacking (the introduction of isolations system like CGROUPS (which also enabled fun stuff like LXC) means that starting a new user-session while leveraging all this technologies would require massive non-standard hacking of the various X init script (cue in lots of crappy copy-pasta from users trying things found on google and which DO NOT work with their specific distribution) or even patching of the X server itself).
From that point of view, it's Unix itself which didn't follow the unix KISS principle ("software should do one thing and do it well"). Instead you had a single concept (starting/restarting) spread across dozen of software, none filling all needs, and maybe requiring a bunch of scripting if you use case doesn't fit any peculiar pre-existing solution.
So systemd is indeed a "less broken" Unix init system.
...Then of course, you have the hundreds of other separate deamon which are managed by systemd's project. Whether those are really that much useful remain to be seen. Although I understand systemd's rationale (they want to provide a self-sufficient set of building blocks "everything included". Other solutions are full blown multi-feature daemons, systemd want to provide minimalist alternative for those who only want the base function and nothing else, and systemd targets embed applications and lightweight virtualisation (like LXC) where the full blown daemon are overkill). But on the other hand there are ALREADY several good alternative (yup "dhcpd" is an overkill. But "dnsmasq" is a very successful DNS forwarder + DHCP server, which is successfully already used in routers and for containers. Was systemd project's own dhcp server necessary ?)
But that's another debate and those not interested in these daemon can simply keep using the full-featured one.
Leave a comment: