The technical aspect here is completely insignificant. All they did was remove a basic listener function that was already optional, used to communicate with systemd's socket activator without linking to libsystemd itself. And it seems only one Busybox daemon ever made use of it.
The political significance is quite high, and I have to say I feel that this move, though perhaps a bit childish, is a valid signal to express grievances with the absolutist attitudes of the systemd developers. Plus let's be honest here, they aren't the pinnacles of mature behavior either. I think this is the first time a major project has done a statement like this against systemd. I would expect more to follow their example.
I of course summarized my issues in "Structural and semantic deficiencies in the systemd architecture for real-world service management" [1] and hope to see systemd go the way of devfsd and HAL.
This is a lengthy write up that does an excellent job of pointing out technical details regarding my top issue with systemd. That is, it just doesn't make any damn sense. Everything is confusing and buried underneath layer after layer of indirection and dependencies. You can't do anything without touching several files and multiple directories. Try as I might, I can't get on board with systemd. It doesn't in anyway feel like it belongs in a Linux OS.
> The technical aspect here is completely insignificant.
I disagree. My initial reaction was to lament the fact that BusyBox syslogd has lost the ability to be passed its socket as an open file descriptor. One may debate whether systemd's mechanism or UCSPI-UNIX (extended to datagram sockets) is the better way to pass such descriptors along. But it now has no mechanism. BusyBox syslogd is now less than it was.
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. :)
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.
> 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.
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.
The political significance is quite high, and I have to say I feel that this move, though perhaps a bit childish, is a valid signal to express grievances with the absolutist attitudes of the systemd developers. Plus let's be honest here, they aren't the pinnacles of mature behavior either. I think this is the first time a major project has done a statement like this against systemd. I would expect more to follow their example.
I of course summarized my issues in "Structural and semantic deficiencies in the systemd architecture for real-world service management" [1] and hope to see systemd go the way of devfsd and HAL.
[1] http://blog.darknedgy.net/technology/2015/10/11/0/