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

Re: If Not Systemd, then What?

On 11/16/2014 at 12:33 PM, Laurent Bigonville wrote:

> Le Sun, 16 Nov 2014 13:53:24 +0000, Nuno Magalhães 
> <nunomagalhaes@eu.ipp.pt> a écrit :
>> On 2014-11-16 11:40, Klistvud wrote:
>>> 1. Reviving the existing init systems. Modernizing them, making
>>> them into true, interchangeable drop-in replacements of each
>>> other, which do the task assigned, and do it well. Each of them
>>> accomplishing at least the common subset of tasks an init system
>>> is supposed to provide.
>>> 2. Complementing them with existing or new tools (again, drop-in
>>> interchangeable replacements of each other) which build on them
>>> and provide the next layer. For example, the kernel autofs
>>> facility provides very nice automounting and could be deployed
>>> to the majority of desktop installs (instead of being just an
>>> optional package, as it is now), thus making the various
>>> automount daemons of the various desktop environments/file
>>> managers virtually superfluous. As a further example, the former
>>> udev (prior to being merged into systemd) has already been
>>> forked and could/will serve us well for years to come. And so
>>> on.
>> +1 for being reasonable and making sense
>> It's an approach that would keep a lot of people happy and, more
>> importantly (at least to me), it gives the user choice instead of
>> taking it away. At least this way each user could choose the
>> loosely-coupled components s/he wanted.
> Are you aware that this is the approach that systemd and upstart have
> taken, right?
> 1) Both systemd (PID1) and upstart are drop-in replacement for the
> good old SysVinit as they both support the common "standard" that
> are LSB scripts (A really good share of the existing LSB initscripts
> in the debian archive are just working out of the box).

Not a "full" drop-in replacement; with systemd replacing sysvinit,
unless you change configuration settings elsewhere, you will see
behavior changes that aren't unambiguous 100% improvements.

A drop-in replacement must, at minimum, Just Work in all of the same
environments and with all of the same configurations where the thing
being replaced already worked. systemd mostly does that, but not
entirely - fstab-related boot failures (lack of noauto / nofail leading
to a boot failure with systemd, where with sysvinit it would not),
issues with booting on/from/to encrypted filesystems, et cetera.

A drop-in replacement should, theoretically and ideally, work *exactly
the same way* as the thing being replaced, when presented the exact same
configuration, except possibly when it can work in a way which is
obviously and incontrovertibly better. There are cases in which systemd
does not do that - consider the "quiet" kernel command-line option, for

Now, there may be good reason to have systemd prefer to not behave in
the same way as sysvinit in these regards, and there's certainly nothing
saying that it can't or shouldn't do so in its own configuration.

But to the extent that it does not do so *by default*, in a
configuration inherited from a sysvinit machine, it is not a full
drop-in replacement for sysvinit.

> But then you cannot blame the systemd project for 3rd party software
> taking advantages of these new functionalities if they think they
> fit their usecases.

I can, however, blame the systemd project for having implemented these
new functionalities in a way which only works in the presence of
functionality which is only provided by their own init system. But
that's a mostly separate argument, which I don't really care to rehash
at present.

   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: