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

I disagree, I think that Lennart is right. Nobody really cares if systemd is not portable. Upstart was not portable to BSDs, and nobody cared. The traditional sysvinit system was, AFAIK, not portable until the debian/freebsd people bothered about it. Heck, the init scripts in Linux used to be not portable even between different Linux distros.

launchd (OS X) and SMF (solaris) weren't portable, either.

By the way, when was the last time a BSD operating system cared about making their init system portable to Linux?

I'm not sure why systemd not being portable to other operating systems is suddenly a big deal.

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.

> I'm not sure why systemd not being portable to other operating systems is suddenly a big deal.

Because software being written that has systemd as a dependency will be Linux only software.

> Because software being written that has systemd as a dependency will be Linux only software.

And this is news, and suddenly it's systemd's fault?

If you hate Linux-only software, software that depends on systemd is the last of your problems. Software that depends on glibc and the Linux kernel are probable the main offenders.

There are currently 23946[1] FreeBSD ports. Nothing I ever needed in the last 15 years of using FreeBSD was missing. Yes, dependency on glibc and the Linux kernel is sometimes annoying, but in practice it is not an insurmountable problem. Dependency on the Linux kernel is rare and dependency on glibc can usually be easily fixed and upstream is usually happy to accept patches. Systemd is different because there is a lot of software that might decide to use it and you can't just work around it.

[1] http://www.freebsd.org/ports/

Generally when software relies on glibc or the Linux kernel it can be patched so that it works on the BSD's. In my time of porting to OS X for example I haven't had anyone not take my patch to fix a problem an upstream it with a "thanks!". This becomes more problematic with systemd, whereby we can't port systemd, and since the software depends on systemd (most likely for some reason or another the software developer thought it was a good idea) we can't easily replace/rip out those parts of the code and make it run on the BSD's.

The only one greatly affected by systemd not being portable is Debian. Their BSD distribution uses the Debian version of sysvinit.

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