On Mon, 7 May 2012 17:39:35 +0200 Tom Gundersen wrote: > An event-driven init system would turn this on its head, and never > wait for "all the things to be ready", rather start things on-demand > and whenever their dependencies are satisfied. This leads to a much > simpler system (from the admin/system daemon developers point of > view), but it requires the init system to keep closer control over the > state of the system, listen to events, etc. But a much more complicated one from the admin/system user in terms of troubleshooting. Also in terms of auditing. Rather than seeing what ports are listening by default, we have to investigate (hopefully in one location) to know what will be listened to upon any future possible event. I hope efforts made to make that very clear. Thanks for the explanation, are there some examples of what this means we can do that couldn't be done in any way outside of init before.
