Le Sun, 16 Nov 2014 13:53:24 +0000, Nuno Magalhães <nunomagalh...@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 -- 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/20141116183351.3bd37...@fornost.bigon.be