> Would
>this approach keep systemd installed just to provide for services
>directly
>depending on it?
>
># rpm -q --requires openssh-server | grep systemd | sort -u
>libsystemd.so.0()(64bit)
>libsystemd.so.0(LIBSYSTEMD_209)(64bit)
>systemd-units
>
>I am not sure why any service would depend on these. Is there
>functionality
>in libsystemd.so.0 that an ssh service actually needs?
Not really, but that is exactly what I'm talking about when I speak
of vendor lock-in.
libsystemd provides some library functions that applications can use
to interface themselves with systemd and allow it to provide advanced
functionality such as fd-holding, readiness notification, etc. But
all that functionality could be achieved in another way, without
needing a specific library: s6 provides tools to perform fd-holding
and an interface to perform readiness notification without needing
the application to link against a specific library.
The fact that systemd encourages applications to link against
libsystemd is one of the way it ties itself to a system and makes
itself unremovable. That is the definition of vendor lock-in; that is
also, incidentally, the definition of cancer.
You will not be able to entirely remove systemd from a distribution
that has chosen to embrace it - not until there is a will from the
higher technical management of that distribution to revert the
process and untie application software from systemd interfaces.
Switching a distribution such as Fedora or Ubuntu to a different
init system is really difficult work. My approach is to first work
with other distributions, such as Alpine, Void or Devuan, which are
systemd-free, and get an integrated s6 init system working on those,
and get traction. Only when we have a fully integrated, easy to
use, widely spread platform will we be able to start turning the
tide and reclaim distributions from the systemd grasp. But this will
likely not happen for several years.
--
Laurent
Received on Mon Jun 26 2017 - 16:17:34 UTC