Several value-added init systems have emerged in recent times. Most notably, Upstart has become the default on Ubuntu while systemd is now default in Fedora.
Let's not forget the crusade to move beyond traditional init was given a big boost back in 2005 by Sun's introduction of SMF on Solaris 10 some years before the main Linux solutions gained prominence.
Debian is currently debating whether to use one of these alternatives as a default. My own position on the matter is not decided, but I do feel that some of the debates are asking the wrong questions. Some of the most interesting issues here are likely to have ramifications for other distributions.
I've come across systemd in my efforts to package reSIProcate on Fedora. One of the challenges I came across was trying to both create a /var/run/repro directory and telling systemd to launch the process as a non-root user. I tried using the ExecStartPre directive in the systemd manifest to invoke mkdir. Unfortunately, it runs as the non-root user too and could not create the PID directory. The conventional init script doesn't suffer this problem.
In the end, I have patched the repro binary to start as root and drop privileges itself, but that was only when it became apparent that we need to do that for WebRTC support (listening on port 443). While most daemons have the ability to drop privileges, there will be edge cases like this that need more than just a systemd manifest.
Maintainers who encounter such issues may have to give feedback to the systemd and Upstart upstreams and give them the opportunity to provide generalized solutions. Then again, the most generalized solution would be another scripting language and then we'd be back where we started.
Some people have argued that Debian should change simply because other distributions did so. This is not a compelling technical argument alone. The fragmentation of init-alternatives is not something that makes upstreams excited either.
It would be interesting to see if Upstart and systemd could agree on a common manifest format - maybe even a format that could be parsed by a wrapper from SysV init. Then Debian wouldn't really have to give up support for kFreeBSD and other non-Linux kernel efforts. A slight alternative to this approach would be using a system like cmake to read a single service XML manifest and spit out permutations readable by each of the different init schemes.
It has also been well argued that the simple and well known solution of scripts is much less complicated to understand and maintain and is extremely stable.
While I don't know which solution is the best, one thing I do believe is that if there is a change and if it is going to be disruptive to maintainers and users then it should aim to bring in as many benefits as possible to offset the pain and encourage people to support the migration effort.
Some of the potential road-map items are not only possible for Debian but could also become part of other platforms. Here are some of the issues that came to my mind:
What other potential improvements do people feel to be worthwhile?