My blog about replacements for SysV init received a significant number of comments Monday, revealing a solid base of community support for systemd. One reader was even generous enough to contribute a pull request fixing the reSIProcate package systemd artifact
The blog wasn't intended to disparage any of the init replacements or suggest that these types of issues are show-stoppers. Rather, it was simply to demonstrate the fact that developers need to divert attention from other activities (like bug fixing, new features, etc) to correctly adapt things and support the wide range of init replacements that have emerged. As revealed in some comments like this one, systemd can even assist with privileged port assignments: it's nice a feature, but also likely to require more development time to integrate.
None of these things are difficult though, they just take time.
The biggest headache is that it becomes tedious for any upstream developer to start getting into that much depth learning about each system they want to support. That is before we even start talking about how daemons and other services are managed in cloud deployments (e.g. the Juju charms from Ubuntu). For a developer to seriously integrate and test their daemon in all of these environments and make maximum use of all their features could easily take a month: without adding any new features to the application itself.
In the last five years, I have personally come across all of these platforms and formal packaging systems:
This is nothing to boast about: with enough time (and bandwidth to download the installer ISOs) I'm sure anybody could set up all these environments and many more. The question, though, is whether developers can afford to stretch themselves so thin, particularly on smaller projects that are not commercially supported.
My first impression of systemd was that it is not widely documented. This is not the developers fault, they do provide some great documentation. Rather, at the time I was looking for it, Google's search algorithm was under the impression that systemd was a typo. Several other forum posts reveal other people had the same problem. I wasn't immediately aware of the fact that systemd has to be quoted in Google searches although I've since discovered quoting it can help find significantly more helpful details in a search. Nonetheless, this initial experience wasted time for me and it is more likely that I would have discovered things like tmpfiles.d if I hadn't lost time on that issue.
In my mind, this is not a fault with systemd at all, it is just bad luck and limited time to allocate on the task.
This brings me back to one of the points I made Monday, that it would be good to see a single solution that allows upstream developers to auto-generate artifacts for all common init replacements. Maybe it wouldn't exercise all of their cool new features. One further comment on Monday even observed that such a tool does exist for invoking systemd artifacts from SysV init. Obviously we already have tools like alien to convert package formats (although it is obviously not used to auto-create packages for Debian's archive). Nonetheless, developers of free software would be able to see their code deployed much more widely, more quickly, if they could get away with using a common tool for this job, just as a single autotools or cmake can support compilation on platforms the developer never even heard of.