On 16/11/14 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.
Given the profundity of disagreement about what "init systems" are "supposed to provide", I believe that this would be a Sisyphean task. Positions people hold on the topic include, but:
1. The init daemon should fork exactly once; in the child it should exec another program, while the parent (PID 1) does nothing except reap zombies.
2. As (1), except that if the initially-forked child process exits, PID 1 should repeat the fork and exec-in-child procedure.
3. The init daemon should have a simple integrated service management mechanism akin to sysvinit's "/etc/inittab".
4. The init daemon should have a complex integrated service management mechanism, perhaps akin to those of upstart or systemd.
5. The init program should do some basic setup, then exec a service manager daemon *within PID 1*.
Moving on from *there*, let's take a look at two of the things you suggest, each of which are quite reasonable in isolation.
On the one hand, "making them into true, interchangeable drop-in replacements of each other" suggests to me that you think they should all have exactly the same set of interfaces and functionality. I don't agree with this position, but it's reasonable, though it's rather stifling (since now you can't add new functionality unless you can persuade all the other init maintainers to add it).
On the other, "each of them accomplishing at least the common subset of tasks an init system is supposed to provide" suggests to me that you think it would be all right for some of them to have extra interfaces and functionality - but as soon as you allow extra interfaces and functionality, you no longer achieve the "true, interchangeable drop-in replacements" part.