Re: If Not Systemd, then What?
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).
2) Again that's exactly what systemd and upstart are doing, they have
added extra features to PID1 like socket activation, process tracking
or the fact that the daemons are started in a clean environment. And
then to that, the systemd project (outside of PID1) has consolidated
services (some of them dead upstream for _years_) under the same
umbrella project. All of this without preventing the already existing
implementations to be used. journald is _not_ preventing a syslog
daemon to be used, the .timer unit files are _not_ preventing cron to
be used and so on...
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.
Laurent Bigonville
Reply to: