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."

Comments

"Slashmirrored"

[Anonymous Coward]

So do we just mirror phoronix on slashdot, now?

Re: "Slashmirrored"

[Desler]

Btw: Why is KDBUS code full with 'goto' calls ?

For the same reason the kernel uses them. Because they aren't mindless ideologues.

Re: "Slashmirrored"

[sjames]

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.

Re: "Slashmirrored"

[Sri Ramkrishna]

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.

Re: "Slashmirrored"

[modmans2ndcoming]

because RC[1-5] works so well with sleep and hibernate states on Laptops....oh wait....no it doesn't.

Re: "Slashmirrored"

[Desler]

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.

Re: "Slashmirrored"

[Anonymous Coward]

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.

Re: "Slashmirrored"

[jcdr]

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.

Re: "Slashmirrored"

[whois]

I agreed with you until Windows 8 came along and could cold boot to GUI in less than 3 seconds. I would still agree for servers. Boot up speed doesn't matter if you never shut down, but the market is changing.

Boot speed matters if you spinup and shutdown instances all the time. It also matters on the desktop, both markets are larger than the "pure server" market. So you can either maintain two boot sequences for different purposes or you can put all your attention into the new sequence. The advantage of the second is that even people who don't need fast boot now are learning how the new stuff works.

And it sucks, but that doesn't mean it can't be improved and made as good as the old system or better.

Re: "Slashmirrored"

[Pseudonym]

C++ automatic stack unwinding is even nicer, but you can't have C++ in the kernel because mindless ideologues.

Why, oh why?

[Anonymous Coward]

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...

Re:Why, oh why?

[Anonymous Coward]

We don't need in-kernel DBUS. Userland can run such things just fine. Is there a "need for speed" and prompt response? Well, so raise priority of the userland dbus daemon then. Right up to real-time priority if need be. That works for jack, which have real-time constraints that can be hard to meet. It works for robot control software. So surely a userland approach will work for something as benign as dbus.

You can even run a linux system without any dbus at all - it is definitely not needed in the kernel.

Re:Why, oh why?

[Anonymous Coward]

Lennart Poettering, nothing he touches is easy to remove once it has a foothold. And it seems everyone who packages it is drinking the same coolaid. Sometime I wonder if packaging tools should have a 'shit can list' that allows packages to be block per developer.

Just blocking this guy would prevent pulseaudio, systemd and avahi.

Re:Why, oh why?

[sjames]

I'm not convinced we need DBUS at all, much less in the kernel.

Re:Why, oh why?

[x_t0ken_407]

Amen to that. I was mildly irritated when I first saw systemd take over Fedora (I forget what release it was), so I moved to Arch Linux -- which I figured I could count on to be the Unix-like system I always loved and forever adhere to the K.I.S.S. philosophy...then they ALSO shoved systemd down our throats. Have been using FreeBSD on the desktop [where practical] ever since; it was already what I used on my servers.

Re: Why, oh why?

[jcdr]

Developers have no ideas of the real requirements and demands of systems engineers, administrators, network specialisty or users.

For proprietary code managed by dummies, maybe. But the Linux community developers count a lot of systems engineers, administrators, network specialists, and users that are code in the kernel precisely because there want to make it better at handling there real requirements and demands. You are free to do the same if you think that you can improve Linux for your need.

More Bloat ?

[fluffy99]

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.

So this is the thing killing portability

[Improv]

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.

Re:So this is the thing killing portability

[olau]

You, sir, are a confused person. The protocol is open and free for any other OS to implement, and will remain so.

If the BSDs are left in the dust, it's because they're lacking the manpower to do the things a new GUI needs. This was not a big problem for GNOME 2, which is architecturally more than a decade old. But things have changed.

I can understand if people disagree with the path the GNOME developers have chosen because it does not fit with their ideals - but you have to understand that these developers are not your serfs you can command. There are still plenty of GUI environments with modest requirements of the OS, and while they may not do the same things you can choose from any of them as you wish. So quit the whining.

Re:So this is the thing killing portability

[Jah-Wren Ryel]

you have to understand that these developers are not your serfs you can command

Ugh, I hate that sort of extremist straw-man. The developers are working on public projects, that means they are subject to both public praise and public criticism. It is a package deal.

Re:So this is the thing killing portability

[Flammon]

There's already a D-Bus implementation available on BSD and other Unices. The API is documented and anyone has the freedom to implement it any way they want, userspace, kernelspace or outerspace.

I fail to see how one more implementation, more specfically the Linux kernel one, has anything to do with giving up on anything.