[skarnet]

Honestly, the people who use Busybox are probably aware of the problems - political as well as technical - with systemd, and most likely not using systemd in the first place because it's not exactly a good choice for embedded systems.

Also, for busybox syslogd, it does not matter at all whether you can hold its socket. syslog isn't a reliable mechanism anyway, and busybox is light enough that the non-ready period is really short.

So, on the technical side, the impact is quite minimal. On the political side, however, it looks like Denys made a splash, and I'm not going to complain about it. :)

[JdeBP]

You've got socket-holding on the brain. (-:

The significant technical aspect is, as I mentioned, that now there's no mechanism to pass an already-open socket to the daemon. nosh has several service bundles supplied out of the box for providing syslog service. They provide the various combinations of two different syslog tools over /run/log, UDP port 514, and /run/systemd/journal/syslog. Each operates in the UCSPI(-like) way, opening the datagram socket specific to the service being run, dropping privileges (in the syslog-read case), and then invoking the daemon program. All sorts of fairly obvious (to those familiar with the daemontools way of doing things) consequences ensue, like separated streams for local clients and remote clients, and control of whether and whose remote client service is provided that is as straightforward as taking the individual services up and down.

Rainer Gerhards rsyslogd and the nosh toolset's own syslog-read both support this. The BusyBox syslogd used to be usable in this way, as well. udp-socket-listen and local-datagram-socket-listen have a --systemd-compatibility option that would have interoperated quite happily with the BusyBox code as it was.

But thanks to BusyBox syslogd now being less than it was before, the systemd compatibility won't work and there's no mechanism for this in BusyBox syslogd. In taking a sideswipe at systemd people, Denys Vlasenko has made BusyBox less operable with other systems that are not systemd. That's a shame, in my view.

[davidstrauss]

> it's not exactly a good choice for embedded systems.

I don't develop embedded systems, but systemd is actually popular in that space because of its watchdog capabilities and its inclusion in projects like GenIVI and Tizen.

More detail is in this post from an embedded systems developer here: http://www.phoronix.com/forums/forum/phoronix/latest-phoroni...

[skarnet]

I see nothing there that can't be achieved by a simple supervision suite. s6, nosh, even runit provide those features; the extra complexity of systemd isn't needed at all. If even embedded developers are getting pulled in by the sirens of systemd because OH MY GOSH IT HAS WATCHDOG CAPABILITIES, then we definitely need to work more on raising awareness about supervision.