It's quite amusing to notice that almost no-one does what you did and actually looks at the original, rather than relying upon someone else, be it some pseudony

It's quite amusing to notice that almost no-one does what you did and actually looks at the original, rather than relying upon someone else, be it some pseudonymous person on the WWW or things like Phoronix, to do the analysis. The systemd people are probably immensely grateful for that, otherwise they'd be having to deal with stuff that would give the cranks a field day like ... * ... "Kay Sievers is writing a replacement for udev named /usr/bin/org.bus1.devices." * ... "Kay Sievers is writing a replacement for Dracut init named /usr/bin/org.bus1.rdinit." * ... "Kay Sievers is writing a replacement for gummiboot that hardcodes support for Microsoft's Boot Manager for Windows." (https://github.com/bus1/boot-efi/blob/c7f3a8a25acc838677b08d8a7dd4fd979cef9939/src/boot.c#l1050 https://github.com/bus1/boot-efi/blob/c7f3a8a25acc838677b08d...) * ... "David Herrmann is writing a replacement for kdbus named bus1." * ... "Kay Sievers is writing a replacement for systemd named /usr/bin/org.bus1.init." * ... "Lennart Poettering made no comment when asked about Herrmann's bus1 and kmscon, systemd-consoled having been quietly pulled from systemd in July 2015." (https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8fQ9t9pmUuT https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...) The simple fact is that it is an IPC mechanism, and it almost certainly indeed is an attempt to come up with a replacement for kdbus, given the latter's withdrawal a while back. It was Herrmann himself who pulled systemd-consoled, and he did so citing the fact that he was working on kdbus. (https://github.com/systemd/systemd/pull/747 https://github.com/systemd/systemd/pull/747) It's not shocking to find him working on a successor. The mechanism is currently a filesystem like devpts, containing a pseudo-file named 'bus' that client applications open and perform ioctl()s on. The caveat "currently" is because there's no design documentation there, and the thing is far from finished. There's no guarantee that that will be its final form. The replacement plug-and-play manager, EFI boot loader, and process #1 programs look like the majority of the project because the test infrastructure for using the new bus, essentially a very feature limited bootstrap system, has been written more quickly than the actual kernel IPC subsystem itself has been. It's fair to say that this is at roughly the same stage of development as SystemXVI is, albeit that SystemXVI does have design doco (https://github.com/ServiceManager/ServiceManager/blob/master/doc/DESIGN.md https://github.com/ServiceManager/ServiceManager/blob/master...).