Hacker News new | comments | show | ask | jobs | submit login

You can write software ignoring how it will be started and you (or others) can write init scripts for various traditional systems. This is way harder if you use systemd; suddenly you need to care about the init system, and you might sacrifice init independence for pragmatic reasons (I want to support systemd, but I don't want to write this yet-another-abstract-wrapper-layer so that someone else might use it with other type of init system).

You always had to care about the init-system: There are some differences between e.g. debian and redhat (start-stop-daemon only on debian, tools for creating the symlinks to install a service), then there's upstart with a different shell-script-esque syntax.

To support systemd, the number of configs you provide will go from maybe 4 to 5, not from 1 to 2! And, looking at the examples provided by ArchLinux, the systemd services look as if they are a lot less boiler-plate than the typical debian init-script.

https://wiki.archlinux.org/index.php/Systemd/Services (e.g. dropbear is very simple)

No, generally you didn't have to care about the init-system unless you wanted to provide an init script. But it didn't matter how your daemon was/is started. With systemd that is no longer the case, you can use certain systemd only features thereby locking out people that want to use your service/daemon without systemd.

Why would systemd suddenly change this? It is one of the init systems with best backwards compatibility with sysvinit. And writing a systemd init configuration for your daemon is trivial and it is also easy to maintain.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact