> systemd being Linux-only is not nice to the BSDs.
>Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it
systemd is not portable, it wasn't made to be portable, it relies on far too many linuxisms. Therefore the BSD's don't care about it. It is not 'the BSD's don't care about it so we didn't make it portable.'
The BSD folks may not be interested in systemd itself, we are still interested in running various bits and pieces of software on top of the platform. When software starts requiring systemd just to run we have no chance what so ever at porting that software.
The same is true for a lot of Linuxisms. I have spent an awful lot of time getting software that states on the tin it is written for POSIX to run on BSD because its source code uses all kinds of Linuxisms.
The same holds true for people assuming that /bin/sh is bash, which may be true on certain Linux distributions but isn't so most other systems. I've started noticing the same issues with other things as well, such as the symlink from /bin to /usr/bin, /sbin to /usr/bin ... whereby software believes all software lives in /usr/bin when in reality that isn't the case for the BSD's.
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.
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.
There are currently 23946 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.
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.