Re: I'm not a huge fan of systemd
-----BEGIN PGP SIGNED MESSAGE-----
On 07/06/2014 09:54 AM, Martin Read wrote:
> On 06/07/14 00:10, The Wanderer wrote:
>> Can you run logind without systemd or journald?
> If you have something else that provides the systemd interfaces
> logind depends on, you can run logind (and timedated, localed, and
> hostnamed) without using systemd as PID 1. This is what the
> systemd-shim project is intended to allow (but see below).
So in other words, at least as far as the systemd project itself is
concerned, you can't. (I'm assuming systemd-shim is not a product of the
systemd project, since that project's developers seem entirely content
with just the main implementation and it seems unlikely they would want
to host two parallel implementations of the same interfaces in the same
collection of projects.)
Also, I wasn't talking about running logind without systemd "as PID 1",
although of course that's a major consideration; I was talking about
running logind with systemd possibly not even present on the system at
all. I.e., completely independent components, which may simply be able
to interact with and enhance one another.
>> Can you run journald without systemd or logind?
> I don't know. The question seems somewhat moot to me, since I've seen
> people who like systemd in principle but think journald is a
> terrible idea, but I don't think I've seen someone who likes journald
> but thinks systemd is a terrible idea.
The question isn't about what someone necessarily wants to do, but about
whether systemd et al. are monolithic or (independently) modular.
systemd's advocates claim that it is highly modular, and (to quote from
this very thread) "anything but monolithic".
If the various components of systemd are independently modular, than
each one can run - possibly, though it would be to be hoped not, with
degraded functionality - without any of the others present.
If they cannot do so, then they are not independently modular - and, by
implication, are at least partially monolithic.
>> If you can, then why is it that libpam package dependencies which
>> appear (if I've understood the discussion correctly) to be about
>> functionality now provided by logind are pulling in systemd *as the
>> active init system* automatically?
> There appear to be two facets to this:
> First, the dependency on systemd's interfaces is expressed as a
> Depends entry of the form "systemd-sysv | systemd-shim", so as I
> understand it "install systemd-sysv" ends up being the default method
> of resolving the dependency because it's the first entry in the
> Second, logind >= 205 has a further interface dependency on systemd
> (logind <= 204 sets up cgroups by itself; logind >= 205 relies on
> systemd >= 205 to do it) which the current version of systemd-shim
> does not yet fulfill:
Which seems to indicate that far from being non-monolithic, systemd et
al. are moving towards being *more* so, by making something that
previously was capable of running independently no longer capable of
(As far as I can tell, logind itself exists only as the binary
'systemd-logind', which is packaged as part of the systemd package
rather than in its own logind or systemd-logind package. The same sort
of thing appears to be true of journald, hostnamed, localed, shutdownd,
and timedated, the latter four of which I hadn't even heard of. That's
another aspect of the "can't get one without the others" factor which is
what leads people to describe systemd as monolithic.)
This type of change gets made in the name of tighter integration and
increased efficiency, and it probably does provide that. But it does so
at the expense of decreased modularity and interchangeability, and makes
the system as a whole more monolithic - with all the negatives that
(I have further discussion and possibly argument on the topic of
init-system-related dependencies, which does relate to the modularity
vs. monolithism argument, but I've deleted it here as being a
distraction from that main topic.)
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----