You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd.
That's Lennart speaking there. Claim everyone is misinformed when a raw nerve is touched. Lennart has clearly stated that he sees systemd as the one way of configuring cgroups in userspace and kdbus is the way that will effectively be locked in as the interface between kernel and userspace. Can't possibly have competing ways of doing this.
It seems you haven't understood the basics of this. Let me clarify:
1. On systemd-distros it is systemd that will be the sole cgroups writer, and the sole owner of the shared bus as setup on kdbus. Poettering are only stating the obvious about this, because realistically that is the only working option.
2. Non-systemd distros can make their own cgroups writer or mechanism for controlling kdbus. They are free to do so, and the API's they use will be stable kernel API's. systemd doesn't in any way prevent them for making their own software for controlling cgroups and kdbus.
This is the way it is supposed to be; everyone makes their own stack. This is what gives competition, not the rather strange assertion that systemd developers somehow should make a independent cgroups writer that works on all Linux distros.
As I said, cgroups and to a lesser extent kdbus, are tremendous opportunities for the non-systemd distros to make their own stack (I am thinking containers mostly) that might even attract both capital and paid developers.
You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.
Bollocks. I find a lot of kernel developers who have issues with it though. See, easy this isn't it?
Really, I challenge you to find even single kernel developer who thinks the old cgroups API is secure, and who doesn't agree on Tejun's proposal as the only way forward. AFAIK, both Al Viro and Andy Lutomirski discussed this recently on LKML.
kdbus is great technology, especially for the non-systemd distros.
Kernel developers who have attempted to review the code have stated otherwise, and kdbus is simply not going to be merged until those concerns are addressed. What happens is things go silent, a patch is pushed to Linus with no changes and the mailing list thread kicks off again with the response "But it does this in userspace, so this is how it has to be and of course, putting it into the kernel will automatically make it go faster, because, you know, KERNEL!". There are a litany of huge issues with it too numerous to discuss here.
Most of it is just the usual LKML noise when something important is merged, people want to test even the basic assertions of everything. Don't take it too seriously if eg. Al Viro says that some code is bad. His standard is that at best, all code sucks badly, with most codes being even worse than that.
It looks like the usual Linux kernel process works fine, with kdbus being improved really well from every round of patches on LKML, especially the two first rounds.
You will find that all actionable kdbus criticism is being dealt with, Greg KH is a seriously experienced kernel developer who doesn't shy away from technical problems.
Anyway, the point is that having a shared bus kernel IPC is a good thing that non-systemd distros could benefit from. Instead they try to trash talk it, pretending it isn't good and doesn't solve any problems. In short, repeating the same total failure tactic as they used against systemd and PulseAudio.
So kdbus seems to be yet another technology that are "taboo" for the anti-systemd crowd. Their loss really.
Using the Spinal Tap line of "But it goes all the way up to eleven" to any argument is all the systemd proponents have. It's quite sad that we're going to spend a great number of years of pain over this thing until it has to be dumped. Just wait until the security holes start getting found as well (you can drive a coach and horses through docker), but that's a whole other can of worms.
systemd won't be dumped. You are fooling yourself in thinking so. It is pretty mature at its core giving developers/users plenty of opportunity to find fundamental problems if they existed.
systemd really works very well and has been in wide scale deployment for years now.
Regarding security: systemd has done really well in that area too. It even has external code audits done by professional security experts.
It probably helps they have been developing after good security guidelines since the beginning and use static code checkers too. Also, the developer community is quite large with lots of people scouring over different code sections.
But just as important, systemd have really improved _daemon_ security making overall systemd security far better than on non-systemd distros. Look at the service file for Apache and how it is locked down per default. And remember, the options are inherited by program forked from this, so even if a black hat exploits another program after exploiting Apache, that program will inherit all the Apache limitations too, so eg. /home can't be read, even if the second exploited program normally have privileges to do so. See man systemd.exec for explanation of what "NoNewPrivileges=" etc. means:
After=network.service systemd-networkd.service network-online.target
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE
RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX
AF_NETLINK AF_PACKET AF_X25
The bottom line is that systemd distros will be hardened ever more per default for every iteration they go through, making them much more secure than present non-systemd distros.
Combine the systemd lock-down of daemons with MAC's like SELinux, and we are suddenly getting serious defense in depth security in Linux. Sure, more process containerization would be nice, but people are working on that too.