Hubbard wants FreeBSD to use launchd. Hubbard is in no position to enforce this if the project doesn't like it.

He used launchd as his example since opinions backed by code have always had more weight in BSD communities. This led to all the systemd comparisons. But in reality, you can ignore all of that.

What his talk was about was a keynote about the ongoing paradigm shift from 'big unix iron' to ever more ephemereal OS instances that move, live, change and die faster and more rapidly. This conflicts with a number of UNIX designs where boottime matters and sets things in stone for the remainder of the current run.

These are problems that need addressing; people need to think about them and come up with ideas and solutions. The project and the community needs to decide to tackle these issues or declare them out of scope. In that context systemd is an interesting case study, since some of it tries to solve similar problems to provide a more dynamic and more MP-friendly runtime. The actually used software to accomplish this is secondary (while acknowledging that everybody has of course personal favourites and preferences).

Well he developed launchd for OSX, that was a partial inspiration for Poettering to develop the init part of systemd. Note the launchd stops well short of the scope creep that systemd has engaged in.

That said i think Hubbard has given up on getting one of the existing BSDs to adopt launchd. Instead he has forked Freebsd into Nextbsd and added launchd there.

Note the difference between that and how systemd is crawling its way into every big distro out there by absorbing (udev) or replacing (consolekit) existing, loosely coupled, projects.

A more likely contender is Nosh. It's additionallyy inspired by SMF and systemd and can import systemd's unit files. it also works on BSD and Linux.

> can import systemd's unit files

That's actually pretty neat. I don't have any real complaints about systemd, but every alternative I've looked at is more painful to use for service management. No longer having to hack together init scripts has been wonderful for me, it took a 10 line unit file to get YouTrack configured as a proper service on my CentOS 7 VM - I used to run JetBrains teamware products on Windows just because dealing with custom init scripts was such a pain in the ass.

> it took a 10 line unit file to get YouTrack configured as a proper service on my CentOS 7 VM

If you did it the way that other people have done it, wrapping youtrack.sh start and youtrack.sh stop in a systemd service unit, with a sprinkling of erroneous Type=forking to get around the fact that that ends up running the Java process as a quickly orphaned grandchild of where systemd expects the daemon to be, and with log output explicitly redirected away from where service management could handle it into an ever-growing private log file under /usr ... then you have entered systemd House of Horror territory. "proper" is not really the word.

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...

I initially tried the Type=forking method, but systemd kept yelling at me (as it should have) because it doesn't really fork correctly. I actually just run the service in simple mode with a launcher script that contains this abomination of a command:

/opt/jetbrains/youtrack/internal/java/linux-x64/jre/bin/java -Dlauncher.app.home=/opt/jetbrains/youtrack/ -Djl.service=YouTrack -Djl.home=/opt/jetbrains/youtrack -ea -XX:+HeapDumpOnOutOfmoryError -XX:HeapDumpPath=logs -XX:ErrorFile=logs/hs_err_pid%p.log -Dfile.encoding=UTF-8 -XX:MaxMetaspaceSize=250m -Xmx1024m -Dorg.eclipse.jetty.server.Request.maxFormContentSize=5000000 -Dorg.eclipse.jetty.server.Request.maxFormKeys=10000 -Djetbrains.jetpass.admin.name=default_admin_name -jar launcher/lib/app-wrapper/app-wrapper.jar AppStarter com.jetbrains.bundle.bootstrap.Bundle

Just remember to do things the daemontools way, and chain to the final daemon binary from that script with the shell's exec command, and systemd should be happy.

Contrast:

* https://plone.lucidsolutions.co.nz/software-development/issu...

And the redirection to $LOG and Poor Man's Daemon Supervisor in some people's youtrack.sh:

* https://www.howtoforge.com/running-youtrack-issue-and-projec...

Well, if anything good comes of that is a different question, but with his NextBSD project he looked to trying something with OS X's init system IIRC.