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."
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.
My first experience with systemd was on OpenSUSE. Although it seems like a good idea, it seems to add some unneeded complexity. /etc/init.d/someservice restart now redirect to systemctl, with no real output. Oh I have to run status to see if it succeeded. Now I have to use journalctl to see why it failed.
I'm all for dependency based init systems, but I feel Gentoo got that right with OpenRC. It gets rid of all that rc1,2,3,4,5 crap while keeping the /etc/init.d/ structure we're familiar with.
Gentoo can not be setup to use systemd too. I guess it's now the future; better get use to it.
Btw: Why is KDBUS code full with 'goto' calls ?
For the same reason the kernel uses them. Because they aren't mindless ideologues.
Actually, overall I would prefer sticking with /etc/rc[1-5]. It is simple and functional.
All the new crap strikes me as some combination of fixing what's not broken and a solution desperately seeking a problem.
You realize that a lot of systemd is supported by kernel developers. These things just don't get integrated by accident. The kernel has features, kernel devs want them used. If you want classic Unix, go head over to the BSD world.
because RC[1-5] works so well with sleep and hibernate states on Laptops....oh wait....no it doesn't.
Nope, it's because gotos are very nice for error handling over rats nests of if/else. Which is what its predominate use in the kernel is.
The unneeded complexity, moreover, does not befit a Unix. If you want one of those, you need to steer clear of most everything the freedesktop crowd, most notably mister Poettering, come up with. Otherwise, what you get is a sort of linux in windows-like sauce, compatible with nobody like a good little redmond product. If that's what you want, go for it. But software developed for this environment will no longer play well with other Unices. In fact, it is no longer a Unix, certainly not in spirit.
Note that I'm not condemning this per se, but it does have far-reaching implications that honesty compels you to be aware of.
I am a user, an admin of a few systems, and an engineer of a numbers of systems.
And I am really very happy by the KDBUS and systemd move.
Not only there are technically good, but I hope that others concurrent projects will fork this common code base and start talking together what will be valuable to merge, instead of creating a yet another pointless unconnected project that will never gain enough audience to change anything but increasing the number of choice problems for a lot of distributions.
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.
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.
Pretty obvious typo for "can now be".
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.
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?
C++ automatic stack unwinding is even nicer, but you can't have C++ in the kernel because mindless ideologues.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});