Re: I'm not a huge fan of systemd
On Sat, Jul 19, 2014 at 8:00 AM, The Wanderer <wanderer@fastmail.fm> wrote:
>
> I suspect it may be the principle which I've been turning over in my
> mind lately, and which I think would be expressed as:
>
> "No functionality which anything not part of the init system might
> legitimately want to depend on should be implemented (primarily) as part
> of the init system."
>
> Or, more concisely but less clearly, "Software not part of an init
> system should be init-system-agnostic." (With obvious exceptions for
> e.g. tools designed to manipulate the config files or init scripts for a
> particular init system.)
>
> E.g., the functionality provided by systemd-logind is something that
> things outside of the init system might (and do) legitimately want to
> depend on, so it should not be implemented as part of the init system.
>
> If systemd-logind is not part of the systemd init system, all
> functionality which it depends on should be implemented outside of the
> init system.
>
> Conversely, if systemd-logind is part of the systemd init system, the
> functionality which outside programs want to depend on should not be
> implemented as part of it.
>
> I suspect, with little evidence except the design choices that have
> already been made, that the systemd maintainers/developers would
> actively reject this principle.
Sure.
It would've been nice if the systemd developers had packaged
"/lib/systemd/systemd" separately from
"/lib/systemd/{hostnamed,localed,logind,timedated,and_others}",
ensured that logind didn't depend on systemd as pid 1, created a
cgroup manager separate from "/lib/systemd/systemd" (as well as a
future dbus manager), and said "if you use /lib/systemd/systemd as pid
1 you'll be able to take advantage of all the goodness that
/lib/systemd/systemd/system/ provides but if you don't you'll still
have all the other executables available to your system".
But this isn't what they chose to do.
Reply to: