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 example. 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