On Sat, 14 May 2016 18:26:17 +0000 hellekin <[email protected]> wrote:
> On 05/03/2016 06:10 PM, Steve Litt wrote: > > > > IMHO the package should install [every init] > > > > Some time ago I suggested an init-freedom package for that purpose, > that would provide init, and require at least one of the init systems > to be installed, like, e.g., mail-transport-agent does. Then it > would propose you to "use N at next boot" or something useful like > that, only for init systems ready to use (i.e., you need to configure > them properly first) > > The prospects sounds interesting but usually one would use one init > system per physical host, and testing can be done with virtual > machines. When test on real hardware becomes necessary, having this > might help. I don't remember the exact context of the discussion, but I always recommend that installing a given init doesn't remove the others. Even on a production machine, if for *some reason* the init suddenly fails, it's nice to be able to use another init. And, as you mention, when experimenting on a VM, init switching is a regular part of the scientific method. > > Using the alternatives system such program might be even simple to > implement. > > More generally I'd like to consider "init" as a set of components you > can combine to form "the init process": > > - boot What is boot? Is that the stuff in the hardware's permanent memory? Does it include the initramfs? > - PID1 (init proper) > - process management > - device management What is device management? Is that the stuff udev and vdev and eudev usually do? > Each component can be covered by one or more programs (e.g., systemd > does all these an more, openrc can do PID1 and process management, OpenRC can't do PID1. It needs sysvinit, Busybox, Suckless Init, or some other PID1, to pass control to it. It has no PID1 capability at all. In reality, this lack of PID1 is no problem: There are plenty of PID1s to stand in. The only problem is that OpenRC can't respawn, which means it needs something else to run gettys (virtual terminals). Sysvinit works perfectly in this role because it can respawn the gettys early in the init. If you used Suckless Init, you'd need to run a respawning process manager on top of OpenRC in order to get your gettys, and this prevents an early getty (for when boot stops early and you have to investigate). You could probably run daemontools-encore (via svscanboot) early in the first rc file to get your early gettys. SteveT Steve Litt May 2016 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
