[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: piece of mind

On 10/21/2014 at 10:03 AM, Josselin Mouette wrote:

> The Wanderer <wanderer@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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: