Re: brasero requires systemd-sysv
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 09/03/2014 at 01:52 PM, Martin Read wrote:
> On 03/09/14 17:14, The Wanderer wrote:
>
>> IMO, any functionality which anything not part of the init
>> system might legitimately want to depend on - such as the
>> functionality needed by libpam-systemd - should be implemented
>> first, primarily, and indeed probably *only* as something that is
>> *not* part of the init system.
>
> A reasonable position. There's some awkwardness in this particular
> case, though...
>
>> Indeed, my understanding is that the cgroups-management
>> functionality needed by libpam-systemd was initially implemented
>> separately in logind and in the 'PID 1' systemd (and possibly
>> elsewhere), and then refactored so as to have only one
>> implementation - the one in PID 1.
>
> ... because this change (from systemd-logind manipulating cgroups
> itself, to systemd-logind sending cgroups manipulation requests to
> the dbus interface that is provided on systemd-as-PID-1 systems by
> systemd's PID 1)
Which would bring up my opinion that having PID 1 provide that interface
is a Very Bad Idea, because it violates this principle: something that
is not part of the init system might legitimately want to depend on such
an interface (indeed, being available for such dependencies is the very
reason for such an interface to exist), so that interface should not be
provided by the init system, or at worst should be provided only
secondarily by the init system.
(I'll note that I do consider systemd-logind to be effectively part of
the init system for at least some purposes, if not necessarily for any
stronger reason than that it's packaged with the init-system binary.
Having it implement such functionality is considerably less of a problem
than having PID 1 implement it, though.)
> was done in response to the decision of the kernel's cgroup
> subsystem maintainer, Tejun Heo, that the way cgroups hierarchies
> worked was terrible and a single hierarchy single-writer model
> would be far more sensible.
I'm *way* behind on my LKML backlog (as in sometime in 2009, I think),
but I may have to jump forward long enough to read this discussion. Any
idea when, or under what thread title, it took place? Or if it wasn't on
the LKML per se but on one of the subsystem lists, got a link?
>> One of the problems is that the systemd project seems to default
>> to implementing potentially-independent things internally,
>> instead of implementing them standalone and then making systemd
>> (or whatever it is they wanted the new things for) depend on the
>> standalone implementation. This leads to there being only the
>> systemd-internal implementation, in at least some cases, and
>> thus to the systemd lockin which is one of the things people
>> complain about.
>
> It seems to me that it's likely to be hard to maintain that kind
> of discipline in respect of components you're only implementing at
> all because you want to use their functionality in something else
> you maintain. That's not to say it isn't worthwhile, but it may
> not always be worthwhile *enough* from the perspective of the
> people doing the work.
Understood, agreed, and "unfortunate" isn't a strong enough word for it.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJUCFBKAAoJEASpNY00KDJrhbUQAKFw4CSC3Hq7D/VKtggHgeBY
xgVTZKaUbVuqctIhO7kbZzA5Fq5p0fAjRBLGzKqVTgHoyP3FuZPaD2Rwf4V3trLJ
r65fFPCh1FZT5PiFqVCgineaMkMcUzn0txu4wpVB2Ty1/YbupOPouQeljjcR378Q
oBz0WcaCCzF0TzyrJ0Roo3Xs1VpPJw0bSDafuCre+/dJyMCSmqyhUahJtNMQj3I8
RGwf3n9SrPrmtZaG2m1sCnHLHhWTHDcHQNKxUGfICEiHTu/imrI+iKvVqJiAcIrK
d0lr6iXo6uWJYYXJxL2qLwQDKj1JrGccZ9dUIAxRQTiusq4Rk3dwTb6RXh9/+Zl+
bIuWTF6h5vu6QikvNlAY8LzvnPoz5UXIosBXbEdRZxQ9BsXBCzfMGP7+9Vkz76s6
1ibrgH/vfQSGR8+NSZAv+KAsNR1GCHYNtwy+6NXw6coHOrIF2DCf3dIbHsv8J2T0
DYV8dF6gygTZPRP3XhRgJUjDYf+HM74mW1/HYf4okrgMCAJBkMbnYjRDIeLcFRTS
riqznJRWDuFxf7gz8W0LGfV9FXKXwE+QTZq1OpDPiTd9KdhZIcjIhO+Y5f0DpUXG
d1la7V6WhSTb6fhPHqoqF1UBDOSBVBleKxUkrb4dnvmE3+Pmq+tKg/Nrr1IB6YiG
mWCplADInhjJbKwa+Alp
=rEWp
-----END PGP SIGNATURE-----
Reply to: