Kernel DBus Now Boots With Systemd On Fedora 341
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."
Re:Why, oh why? (Score:5, Informative)
Canonical is innocent - it's Red Hat's doing. Just like Pulseaudio and a million other innovations (some good, some less then good). But Red Hat has had a hand in most of the desktop development that people see.
Re:Why, oh why? (Score:4, Informative)
The biggest audio performance boost I have gotten was when I killed pulseaudio so that everything would use ALSA.
Re:Why, oh why? (Score:5, Informative)
Re:More Bloat ? (Score:4, Informative)
Seriously? BSD has had such a system forever. Linux used to have a "sane" init scripts system (admittedly for some subjective definition of "sane") until very recently. Debian's system used clean Bourne shell compatible scripts. This meant /bin/sh could be a symlink to /bin/dash. Dash is a very lightweight shell without all the Bash overhead. It is about 1/10 the size of Bash. Bash is an excellent interactive shell, and a very valuable scripting shell, but Dash is excellent to have where you don't need a vast profusion of features but you are interested in performance.
Here [ubuntu.com] we learn that most of the performance benefit seen in Ubuntu 6.10 was due, not to Upstart, but simply by switching from Bash to Dash in the init scripts.
Redhat decided it was "too hard" to make their init scripts Bourne shell clean. They all reference /bin/sh in the shebang line, but they lie. They rely on Bash features. As a result, rather than do what Debian showed could readily be done, Redhat established and has adopted Systemd as the Only Supported Init System.
Now that Debian is caving in to systemd, it seems safe to say we can forget the fantasy of Systemd being relegated to any kind of "trashcan". Quite the contrary, as far as linux is concerned, it is the init script system that will be trashcanned.
There are honest pros and cons for the move. The pros are pretty compelling (and I say that as a holdout from the beginning). Linux is in many ways about monolithic solutions. This is just one of those ways.
For those who have doubts, not just about Systemd but about other monolithic consolidations and discarding many time tested and good working systems, there is still a refuge: BSD. That may change, but for now BSD is not jumping on all this stuff (quoting the AC near the top: Wayland, Gnome3, Pulseaudio, Systemd, Journald, "Alienating [subsuming] Udev"). BSD is still all about the Unix Philosophy [wikipedia.org], as expressed by Mike Gancarz.
It is really an embarrassment of riches that BOTH Linux and BSD are prospering as freely available systems.
Re:Listen to A.S.T. (Score:3, Informative)
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?
That word does not mean what you think it means. In fact, kernel dbus is probably the most microkernel-ish feature I've seen added to the Linux kernel (although I haven't been paying close attention).
A microkernel is defined as a kernel composed of a large number of very loosely coupled modules, with an absolute minimum of functionality in the modules that are loaded initially or by the bootloader. Because of this, microkernels tend to have slightly greater overhead (both processing and memory) than comparable monolithic kernels, while (ideally) making up for this in flexibility and ease of debugging. Modularity in ring 0 is a double-edged sword: there are few protections against screwing everything up in a monolithic system (although Linux is now more like a hybrid, with an emphasis on supporting both static and dynamic modules, and it's been decades since a single minor change in some static module has caused some unrelated module to do something silly like scribble all over my disk), but it's almost always easier and faster to write non-modular systems in ring 0 (particularly early in the process, when many of the basic facilities need to be implemented and debugged for the first time -- it's extremely difficult to debug module loading in a microkernel when something like printing messages to the screen are in a separate module). In a sense, the microkernel-vs-monolithic debate mirrors object orientation vs procedural programming debates of the past (and both are fairly moot -- it's a decision about which much ink and many pixels have been spilled, and in the end, the decision is one that probably should be based upon the requirements for the particular project. An atmel device with 500 bytes of ram doesn't need a microkernel; a system intended for something fairly exotic like transparent heterogenous distributed computing can benefit greatly from it).
As for whether or not this is a good idea -- I'm in agreement that it's a bad idea, but primarily because of poor past experience with userland dbus implementations. I've used many distributions over the past fifteen years, and I've never had dbus work properly out of the box on any system that wasn't either debian-based or red hat based (and most of the distros I use on a regular basis are neither). If the developers working on top-10 distributions can't get it working properly and consistently and only the top two distributions can (for the sake of argument, I'm considering all debian-derivatives to be debian and all red hat derivatives to be red hat), then it's something that I don't trust to work in any kind of fringe situation, and it's not something I'd trust in kernel space except in the most well-tested situations (say, running a ten year old stable implementation on ten year old best-selling consumer hardware after five or six years of heavy automated testing). Much like some other systems being pushed by canonical (PulseAudio, systemd), dbus seems like it was released far too early and really isn't ready for prime time. Back in 2003, I'd expect and tolerate this kind of cavalier behavior from mainline distributions (remember Fedora Core 2's problems with ejecting CDs and then keeping them registered as mounted?), but Linux is now a perfectly reasonable desktop OS for most situations and enterprise-grade linux is big business, so shipping with completely broken non-solutions to already-solved problems (PulseAudio, which completely randomizes mixer settings on startup, etc.) seems unforgivably irresponsible.
Re:More Bloat ? (Score:4, Informative)
hHe short version: http://lwn.net/Articles/551969/ [lwn.net]
At first, this sounds like the kernel developers have raided LP's [wikipedia.org] "private stash", but it turns out the reason for kdbus is preceeds it - in fact in even preceeds d-bus itself. Specifcally, kdbus is intended to be a alternative version of Android's binder. Android doesn't use d-bus, because it didn't exist (or was too immature) back when it was concieved. While binder is in the staging tree, it'll never be part of the kernel proper for various - some fixable, other unfixable. Binder is not just a hard pill to swallow for the kernel developer, its a spiked ball the size of a fist in a bottle labelled "NOT TO BE TAKEN ORALLY".
There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS.
No one suggesting putting the entire dbus-daemonm and protocol in the kernel with kernel XML parser (and so dbus-daemon will still be needed for authentication and the inital connection setup, but then steps out of the way after that), kdbus is "just enough" to implement an accelerated and robust message bus.
Re: "Slashmirrored" (Score:4, Informative)
Pretty obvious typo for "can now be".
Re: "Slashmirrored" (Score:5, Informative)
Even on fast SSDs I've never seen 8 cold boot it in 3 seconds. 9-12ish maybe. Add in windows networking and it's much slower. Also Windows delays a lot of tasks so you are to the GUI but your actual services are not running yet. In the server market your boot speed is highly dependent on network resource dependencies with varying delays.