I can't wait to see this guys face when he finds out that Jordan Hubbard wants to implement something very much like systemd in a future version of freebsd.
Not OP, but it depends. If they take the good bits (simple unit files, process monitoring), and ignore the bad bits (trying to do everyone else's job, sinister plans for world domination, no fun at parties), than I'd be cool with it.
heck, just stick process monitoring into the rc.d model. You'll get the Best of systemd. Especially if you don't take the Rest of systemd.
Sometimes I run end user-ish stuff under /usr/ports/sysutils/py-supervisor and sometimes under the rc system.
The features of supervisord are very nice, the simple config, the password protected web interface for semi-sysadmin users to access and restart their memory leaking Java processes. Basically what you list as killer features.
On the other hand its not ready for prime time as a /bin/init replacement, I don't NEED the features they're just nice, and the only thing more annoying than having to learn all the peculiarities and bugs and workarounds and syntax of one init system, is having to learn two init systems.
I can imagine a world where freebsd base uses rc and "Everything in ports and pkg-ng uses supervisord". I'm not sure if I like it or dislike it, but it is at least imaginable.
In my infinite spare time I was writing a compiler that translates supervisord.conf files into shell RC files. Most of the time its pretty simple.
Yeah, that's what I mean. I'd be pretty happy if FreeBSD picked up s6, or something else in the daemontools family, if it really wants to go in that direction.
Frankly, even SMF would be better. For all its faults, its still got a good idea of its place: It's an init system, no more, no less.
Here is a list of things I would be concerned about my init system doing: anything other than being a good init system. By coincedence, that's exactly what systemd does.
The goal of systemd was to eliminate the differences between Linux distributions. FreeBSD doesn't have that problem, it's not a standalone kernel, it's developed as a whole base system.
Ironically, this means that systemd is the most BSD-like thing that ever happened to Linux userspace. As in, everything developed together. If only it was better quality and not overcomplicated…
I strongly doubt that a 'systemd like' in FreeBSD would have quite the same issues. I still wouldn't see the point of fancier startup/shutdown dependencies or process supervision because I run FreeBSD on hardware that doesn't change while running with daemons that don't crash; but I imagine it wouldn't include: a DNS resolver, but broken; an ntp client, but broken; a login daemon, but broken; etc. I also would expect the rc.d scripts to be kept, because the service scripts are simple (rc.subr is a bit complex).
As you can see, one doesn't actually need to keep all of the rc.d scripts. I manage well without any of them, in fact, including running desktop GUIs on PC-BSD under service management.
logind is a much misunderstood part of systemd. It is somewhat difficult to state that it is "broken", given that there really isn't a spec for it to be compared against for conformance, and it is largely the only implementation in existence. It's what Ian Sutton reported as being the most difficult part of SystemBSD, as noted in https://news.ycombinator.com/item?id=10176275 and as I said beforehand in http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html#s...
There are a few things about it that can be stated to be wrong, though, inasmuch as they interfere with the operation of the services that service management is supposed to be managing. The limits on the number of threads that database services and suchlike can run are a largely unreported problem, for more on which see https://news.ycombinator.com/item?id=11675129
Personally, for resolving proxy DNS service and content DNS service I use modified versions of Bernstein's dnscache and tinydns. The modification involves my own well-known, and years-old, patches; and making dnscache and tinydns capable of receiving their listening sockets as already-open file descriptors, via the LISTEN_FDS protocol, making it possible to integrate them with UCSPI-style tools that open the sockets for them.
Given that bluetooth is complex, I'm not surprised it has a complex rc.d script. In any case, I feel these scripts are less complex than the equivalent scripts in Debian init.d; removing a lot of the argument for a 'simplification'. For example inetd on my FreeBSD box is a 20 line rc file, and openbsd-inetd is an 85 line init.d file (much of which is using start-stop-daemon for common cases). I don't have bluetooth installed on Debian to compare.
Jordan Hubbard is a very small voice in a very large chorus of people running FreeBSD. My money is on a new kind of init system coming to FreeBSD, but it not being anywhere near as controversial as systemd.
Jordan Hubbard hasn't actually committed anything in years. He does like to suggest FreeBSD adopt mach and launchd. That has seen some push back (people don't want mach IPC and people seem to think XML is required for launchd plists—it isn't).
