4 ms·

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.

qwertyuiop924 10y ago
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.
- VLM 10y ago
  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.
  - qwertyuiop924 10y ago
    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.
kchoudhu 10y ago
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.
toast0 10y ago
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).
- JdeBP 10y ago
  The "service scripts are simple" belief is not borne out by the reality, as I reported in https://news.ycombinator.com/item?id=10357589 https://news.ycombinator.com/item?id=10357589 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 https://news.ycombinator.com/item?id=10176275 and as I said beforehand in http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html#systemBSD 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 https://news.ycombinator.com/item?id=11675129 And as I pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 the problem that did reach the news is something that one fixes properly by correcting the incorrect behaviour of logind. 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.
floatboth 10y ago
No, something like launchd, but without the XML: https://github.com/mheily/jobd https://github.com/mheily/jobd — and that's great. 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…
- loeg 10y ago
  No, actually launchd: https://github.com/NextBSD/NextBSD https://github.com/NextBSD/NextBSD :-). XML isn't required; plists can be JSON or UCL or whatever.
loeg 10y ago
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). Matt Macy already did a port of both pieces; they're ready and sitting in the NextBSD repository: https://github.com/NextBSD/NextBSD https://github.com/NextBSD/NextBSD .

qwertyuiop924 10y ago

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.

VLM 10y ago
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.
- qwertyuiop924 10y ago
  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.

kchoudhu 10y ago

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.

toast0 10y ago

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

JdeBP 10y ago
The "service scripts are simple" belief is not borne out by the reality, as I reported in https://news.ycombinator.com/item?id=10357589 https://news.ycombinator.com/item?id=10357589 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 https://news.ycombinator.com/item?id=10176275 and as I said beforehand in http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html#systemBSD 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 https://news.ycombinator.com/item?id=11675129 And as I pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 the problem that did reach the news is something that one fixes properly by correcting the incorrect behaviour of logind. 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.

floatboth 10y ago

No, something like launchd, but without the XML: https://github.com/mheily/jobd https://github.com/mheily/jobd — and that's great. 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…

loeg 10y ago
No, actually launchd: https://github.com/NextBSD/NextBSD https://github.com/NextBSD/NextBSD :-). XML isn't required; plists can be JSON or UCL or whatever.

loeg 10y ago

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). Matt Macy already did a port of both pieces; they're ready and sitting in the NextBSD repository: https://github.com/NextBSD/NextBSD https://github.com/NextBSD/NextBSD .