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.

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..

© Copyright 2015 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.