The launchd on FreeBSD/NetBSD/OpenBSD train is never coming.

launchd on the BSDs is an exercise in jam tomorrow.

In 2014 I wrote:

A while ago, I lived in a comfortable little world. Yes, everyone else was getting the likes of Solaris SMF, AIX SRC, systemd, upstart, and whatnot. But BSD was alright. Someone was bound to come along and package up launchd. After all, MacOS is BSD … right?

Then I did some investigation.

There have been, to my knowledge, three attempts (in 2005, 2008, and 2013) to give launchd to the general BSD world that have involved more than just talk. All have foundered. The discomforting truth is that we aren't going to get launchd for doing service and system management for the very same reasons that we aren't going to get systemd for doing service and system management. systemd is full of Linuxisms. launchd is full of Machisms. It's simply not a BSD program. It's a Mach program. (The fact that the initial process program isn't portable is obvious in hindsight. I kicked myself. I've written several initial process programs before. They aren't, and cannot be, limited to non-operating-system-specific stuff.) One attempt to port launchd involved stubbing out the Machisms. There has been a recent attempt to port systemd to FreeBSD that is in the same boat: stub out or remove all of the operating system specific parts, and one can get a program that will compile (with a lot of compiler warnings); but it doesn't function.

The launchd train is never coming. It's this realization, in addition to several other motivating factors, that spurred me to aim high with nosh, and actually set that task of converting those rc.d scripts. Feel free to thank the valiant and noble failures of the launchd porters for the fact that there's one alternative to BSD init that doesn't put an XML parser into the program for process #1. (-:

In response, there were more promises and plans, but no results. There was the waving around of a completely theretofore unadvertised fourth attempt. That put an XML parser into process #1, a suggestion that for the previous few years I had been using as joke example of the sheer design lunacy that no-one in xyr right mind would actually do. Amusingly, other people including Jordan Hubbard pointed out the silliness of that idea.

It took less time to write nosh from scratch than it took to do even a mad and bad port of launchd.

It is now 2015, and nosh is at the point that it runs working systems, has a repository of a couple of hundred pre-built services, and even comes pre-packaged for those who don't want to assemble from kit form. If you are about to suggest that nosh is clearly an exceptional case and not a good thing to compare to, consider the evidence that it isn't an exception and that other comparisons only make the non-arrival of launchd look worse: upstart has both risen and then fallen again in the time since attempts to port launchd started.

• On 2006-06-06 Scott James Remnant wrote that one of the motivations for writing upstart in the first place was the "unescapable licence problems" with launchd. It was licenced under the Apple Public Source Licence at the time.

• On 2006-08-06 Apple released the launchd source under the Apache Licence.

• On 2006-10-26, Ubuntu version 6.10 was released with upstart as the out-of-the-box system and service management.

• On 2013-10-26 Steve Langasek wrote of the difficulty with adopting upstart in Debian Linux because of Canonical's Contributors' Licence Agreement.

• On 2014-02-14 Mark Shuttleworth observes that the Debian Technical Committee chose not to make upstart the out-of-the-box system for the (then) forthcoming Debian version 8.

• On 2015-04-23 Ubuntu version 15 is released replacing the out-of-the-box system and service management with systemd, upstart remaining installed (and indeed still used in subordinate parts of the system) but no longer the system and main service manager.

nosh is of course simply licensed under the MIT Expat Licence, the ISC Licence, and the FreeBSD Licence (in the belief that they are all in essence identical and in order to avoid BSD Licence Hell).

I wrote this FGA, and what I wrote in 2014, in the full knowledge that it would spur people to prove the prediction wrong. That was fine by me; after all, as I began by saying right from the get-go, I was for a long time one of the people waiting for launchd myself. Indeed, I wrote nosh in part to prove something wrong: the oft-made statements that one couldn't do service dependency management and ordered startup/shutdown with the daemontools architecture; nosh proving by example that one can.

11 months after the initial public prod, NeXTBSD was announced. This tackled the problem by (essentially) porting a vast chunk of Apple infrastructure to FreeBSD, including libraries for message passing and event handling, kernel changes to support (amongst other things) Mach ports as if they were file descriptors, and a Mach message-passing API. If launchd cannot come to FreeBSD, then FreeBSD can come to XNU.

I did say the BSD world and the BSDs, though, not specifically and only a FreeBSD fork. There's still nothing visible, even on the far distant horizon, for NetBSD, OpenBSD, DragonFlyBSD, MirBSD, et al..