-----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----- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5408504a.70...@fastmail.fm