The poisoned NUL byte, 2014 edition (Project Zero)

su, sudo, sudoedit, ksu, etc. can be replaced with a lightweight equivalent to 'ssh root@localhost' with various options. You can even reuse most of the exisitng sudo code unmodified (it just has to know that uid comes from SO_PEERCRED instead of geteuid()).

mtr, ping, traceroute6, etc. need a socket in raw mode. There are better ways that a process could get one, e.g. put permission bits on network interfaces in the kernel, so an admin can authorize any process to listen to the local WiFi interface without having completely unrelated root privileges. I gather OSX does something like this, so ping just works without setuid there.

Mail has long been available on Unix through a wide variety of servers that don't need setuid bits. Ditto user account management tools like chfn and passwd (NIS is well into decade #3, although a more lightweight replacement that isn't network-accessible and full of bugs might be a good idea).

User mounts and VM management tools are already available through dbus servers, so deprecate the legacy interfaces.

'at' and 'crontab' already communicate with a privileged server through an IPC (FIFO), so they're half done. Just implement the other half.

pkexec is...wrong. It already talks to a privileged server process for authentication, but it doesn't use that server process to provide the privileged process's execution environment. It's all right there, all it has to do is move some FD's around and fork()...*headdesk*

Yours is a very laudable goal, and I wish you all the best in your endeavours.

Unfortunately though, systemd these days is much more than an init system. It offers standardised and generally reasonably well-designed replacements for huge swathes of base functionality which Linux distributions used to have to provide themselves, and which they generally provided in an insular and non-standardised fashion. As such, systemd has the potential to (a) save Linux distributors loads and loads of drudge work and let them concentrate on more interesting and important issues, and (b) make Linux that much easier to understand and deal with for administrators, instructors, and authors of books and training manuals, no matter what distribution they're using. Both of these are great and important benefits.

Anybody who thinks they will be able to supplant systemd by providing (only) a better »init system« will probably find that the major distributions are reluctant to buy into that, because the non-init features of systemd are too compelling to pass over, and are likely to become even more so in the future. This may or may not be an actual problem depending on who the target users of your replacement init are, but it is fairly safe to say that if you want to take over the Linux world it's not going to happen unless you get the mainstream distributions on board, and they won't take you seriously unless you offer something that improves on all of systemd.

If systemd was so good, you wouldn't have to use these dishonest and coercive tactics.

Actually, systemd is pretty good. At least it's good enough that all mainstream Linux distributions have either made it the default already or have declared that they will. This includes communities like Debian that don't generally let themselves be fazed by underhanded tactics such as the ones you're ascribing to the »systemd supporters«, and communities that used to have their own horse in the race, like Canonical/Ubuntu.

There is no way systemd could have ended up where it is now if it didn't present compelling technical advantages vis-à-vis the competition. Nobody claims that systemd is perfect, but on the other hand nobody has been able to point out specific architectural problems other than the vague waffling along the lines of »It's not Unix!« that one tends to get from the likes of you. (Note that you still need to provide a few specific examples in support of your claim that systemd increases the »attack surface« of a system.) In fact, there are various testimonials from people who used to argue vehemently against systemd but then after actually having had an in-depth look at it decided that it was in fact quite good. It is also very instructive to study the deliberations of the Debian technical committee on the subject.

Systemd detractors will have to learn to live with the fact that the caravan has moved on. Three years from now we will look back and wonder what all the flap was about, and how something like the earlier SysV init/inetd/cron/… kaboodle could ever have lasted as long as it did. This is not to say that systemd is the last word in its area – as the Upstart camp has had to find out to their disappointment, there is always room for something noticeably better. Arguably with systemd, the bar for »something better« has been raised considerably but if systemd is really so bad (and nobody noticed) and other solutions are so good, it shouldn't be a problem for you – or like-minded folks – to present an alternative that is technically so vastly superior that people will move over in droves.

s6 may be great for the supervision of individual services but reading through its web pages it seems that s6 does not handle inter-service dependencies at all. That disqualifies it right out of the gate as a viable alternative to even the process-supervision part of systemd. And that is before considering features like resource control or child process tracking that systemd does out of the box, in a unified fashion across services, based on simple declarative configuration settings, but which users of s6 must provide piecemeal in their own script code as part of individual services' »run scripts«. (And s6 even comes with its own shell that people will have to learn to use.)

It is probably possible to come up with something that will shoehorn dependency management into s6 the way insserv has shoehorned it into SysV init. This will undoubtedly do wonders for keeping s6 simple and straightforward to understand. As it is, it looks as if there would have to be considerable work on s6 for it to be as good as systemd even on s6's own turf. It is not what I would view as a reasonable contender.

And it has exactly zero relevance. Depending on your opinion of Bill Gates, it could be considered an ad hominem argument as well.