I enjoyed the article. I think this point though is incorrect.
Another reliability concern is that configuration parsing is done in PID 1, too. With Apple’s launchd, the format is XML. With NextBSD’s launchd, it’s a bit saner. They chose JSON, instead. But in general, parsing should probably be handled outside of the critical base of PID 1, since parsers have long been notorious sources of bugs and particularly adept to input fuzzing.
From what I understand, launchd itself does not parse the json. Instead, I believe that during startup launchd spawns launchctl, which does the parsing of the plist files, and sends the results to launchd over a mach namespace using a native binary format (XPC?).
I guess when it comes to systemd, or launchd, or any other thing that is complex, the evaluation, in my opinion, should come down to: “am I better off with this, than without it?”
What is systemd doing for me that wasn’t being done before by other tools? And, is it doing it better? I have no evidence in support or against that, so I think not.
I’d ask the same question about launchd. Is it making the operator’s life significantly better? If it’s not, why change? If it is, is the added complexity and disruption really worth it?
The main issue for me is that I really, really hate the tangle of shell scripts that is sysvinit. They are a bug-ridden, unpleasant-to-use mess. Now it’s certainly possible to replace them with something even worse. But I don’t think we’re in a situation where the status quo works well. So I’m interested in at least evaluating alternatives, whether systemd, launchd, Solaris/Illumos’s SMF, or the nosh project that this article mentions.
I think what a lot of distros are driven by is more specifically containers and cgroups, which at least in the Linux design of them, require an init system that can supervise services and manage resources, in addition to the actual startup. I’m less sure what iXsystems’s motivation is; they do seem to feel that there’s a significant business case for porting launchd (and friends) to FreeBSD, but I couldn’t tell you what it is.
I enjoyed the article. I think this point though is incorrect.
From what I understand, launchd itself does not parse the json. Instead, I believe that during startup launchd spawns launchctl, which does the parsing of the plist files, and sends the results to launchd over a mach namespace using a native binary format (XPC?).
I guess when it comes to systemd, or launchd, or any other thing that is complex, the evaluation, in my opinion, should come down to: “am I better off with this, than without it?”
What is systemd doing for me that wasn’t being done before by other tools? And, is it doing it better? I have no evidence in support or against that, so I think not.
I’d ask the same question about launchd. Is it making the operator’s life significantly better? If it’s not, why change? If it is, is the added complexity and disruption really worth it?
The main issue for me is that I really, really hate the tangle of shell scripts that is sysvinit. They are a bug-ridden, unpleasant-to-use mess. Now it’s certainly possible to replace them with something even worse. But I don’t think we’re in a situation where the status quo works well. So I’m interested in at least evaluating alternatives, whether systemd, launchd, Solaris/Illumos’s SMF, or the nosh project that this article mentions.
I think what a lot of distros are driven by is more specifically containers and cgroups, which at least in the Linux design of them, require an init system that can supervise services and manage resources, in addition to the actual startup. I’m less sure what iXsystems’s motivation is; they do seem to feel that there’s a significant business case for porting launchd (and friends) to FreeBSD, but I couldn’t tell you what it is.