On 10/21/2014 at 10:03 AM, Josselin Mouette wrote: > The Wanderer <wande...@fastmail.fm> wrote: > >> This is the problem. The init system should not be providing >> "features" which other software might, post-boot and pre-shutdown, >> want to make use of. (AFAIK sysvinit never did, and most - possibly >> all? - of the other init-system candidates don't either.) Such >> features should be provided separately, independent of what may >> happen to be running as PID 1. > > These features cannot exist separately.
If that is the case, then they should not be provided at all. That is a core disagreement here; the systemd upstream plainly rank those as features more valuable than either the principle(s) which is(/are) violated by having them be provided by PID 1 or the real-world consequences (in terms of other software depending on a particular init system) of providing them in PID 1, and other people invert those relative values. > Quoting the systemd position statement: > > […] while it is true that a handful of trivial interfaces are not > really related to systemd (and could be split out if needed), most of > these features cannot be implemented without close integration to PID > 1. It is not possible to split the system cgroups arbitrator from the > process which starts services and sessions in cgroups. It is not > possible to ensure the relation of a log to a service if you do not > have awareness of how the service was launched. Et caetera. I am aware of this statement. I am not convinced that this is necessarily true, but even if it is, that simply means that the decision should have been to not implement those features at all rather than to implement them with integration to PID 1. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
