Slashdot Mirror
Kernel DBus Now Boots With Systemd On Fedora
An anonymous reader writes "Red Hat developers doing some holiday hacking have managed to get a bootable system with systemd + KDBUS on Fedora 20. KDBUS is a new DBus implementation for the Linux kernel that provides greater security and better performance than the DBus daemon in user-space. Systemd in turn interfaces with KDBUS for user-space interaction. Testing was done on Fedora 20 but the systemd + KDBUS configuration should work on any modern distribution when using the newest code."
So do we just mirror phoronix on slashdot, now?
Why do we need in-kernel DBUS implementation. And please don't tell me about performance, lot's of software with much higher performance requirements is more than happy in userland...
Why is this NOT another example of kernel bloat, and the opposite direcion they should be heading (ie getting user stuff out of the kernel)? Seems like the primary use of D-BUS is for the desktop components, which already abuse/overuse inter-process communication. The "huge performance improvement" is only for those processes that shouldn't be abusing this anyway.
The corruption of GNOME and other opensource projects by tying it specifically to Linux comes with this; it represents giving up on being cross-platform, giving up on the BSDs and other Unices, and giving up on openness. No thanks.
For every problem, there is at least one solution that is simple, neat, and wrong.
Andrew S. Tanenbaum had a point about Linux not being micro kernel.
This is getting crazy: moving perfectly fine userland systems to the kernel.
Isn't the kernel large enough already?
Bram Stolk http://stolk.org/tlctc/
http://lwn.net/Articles/551969/
Linus is okay with it. Have to worry about Al Viro. :-)
Here is an updated talk by Greg K-H that he gave on KDbus, he posted this about 3 days ago. https://github.com/gregkh/presentation-kdbus
Let's stop all the FUD, and educate yourself on the reasons behind on this.
The really really stupid thing is that desktop isn't even the reason why Linux. Obviously no server needs dbus let alone kdbus, and plenty of desktops don't either. Yes, it's amusing that I get a popup when I plug in a USB stick, but is that essential functionality? Sure, some very simple form of event multicast would be good, but is this it?
Everything LP touches seems to epitomize rebellion against, or ignorance of, the *nix/OSS philosophy (you know, modularity, loosely joined, liberal-in-what-you-accept, etc). systemd is the USSR of rc systems. pulse only remains because apps can still bypass it.
Dido, the British singer-songwriter ("White Flag," "Life for Rent")? -- or did you mean, "ditto"
Linux exists soley because HURD has been such a dismal failure, the FSF can't manage something as complicated as the building of a kernel
Binder is "weird", Kroah-Hartman said. It came from BeOS and its developers were from academia. It was developed and used on systems without the System V IPC APIs available and, via Palm and Danger, came to Android. It is "kind of like D-Bus", and some (including him) would argue that Android should have used D-Bus, but it didn't. It has a large user-space library that must be used to perform IPC with binder.
Binder has a number of serious security issues when used outside of an Android environment, he said, so he stressed that it should never be used by other Linux-based systems.
http://lwn.net/Articles/551969/
Modern systems often aren't a single purpose hardware server any more. Mobile devices that have to switch on services like GPS, several networking modems, voice over IP, hotplug hardware and start/stop associated services and such will make you have to run numerous daemons that control just restarting the one small group of services and hardware for every corner case you can imagine if you keep using RC scripts.
Even servers often have nested dependencies these days. You'd want the system to restart a failing middleware application in the correct sequence after you've fixed the filesystem on the storage that ran out of space that caused it to remount r/o on all your web server platform VMs. Try doing a bunch of init.d scripts for that. Either you custom write a script to do it remotely just for your app, or you have the systemd-like control that will just figure out what to do all by itself.
Yes, it adds complexity to very simple single use systems, but it makes dealing with all the glue you have to do to get dependencies on other services and corner cases so much easier. I used to think it was a solution looking for a problem too, until I found out that I could now stop worrying about getting my systems up again after I just solved the single cause of all the problems that got them down in the middle of the night.
I was promised a flying car. Where is my flying car?
Sorry to double reply, but systemd would be a lot more acceptable if it and it's project leaders would be just a bit more conservative (especially in dependencies) and a bit more open to porting to non-Linux systems. As it stands, I hope that failing prompts Debian to pick upstart.
Since rc scripts are currently universal, it makes sense to consider them a gold standard even after moving to an alternative init. In other words, any new init needs to consider support for scripts dropped into init.d and linked in rc[1-5].d to be first class citizens. Ideally, it would auto-generate init.d scripts so that legacy scripts using /etc/init.d/service [start|stop|status] would continue to just work. As opposed to the current case where that is considered to be a 'problem' that needs some sort of remedy.
That compatability should be retained until nobody is using rc scripts anymore (read as "for years to come").
Right now, systemd feels like it will have all of the charm of Gnome3, complete with it's "our way or screw you" attitude that has people avoiding it in droves. Init is too important to hand over to that.