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."
"Slashmirrored" (Score:2, Insightful)
So do we just mirror phoronix on slashdot, now?
Re: "Slashmirrored" (Score:5, Interesting)
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.
Re: "Slashmirrored" (Score:5, Insightful)
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: (Score:3, Insightful)
because RC[1-5] works so well with sleep and hibernate states on Laptops....oh wait....no it doesn't.
Re: (Score:2)
All that was required was to either wake from sleep OR go through the usual rc[1-5] scripts.
waking up requires special cases, so does moving (Score:4, Interesting)
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.
Re: (Score:3)
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
Re: (Score:3, Interesting)
because RC[1-5] works so well with sleep and hibernate states on Laptops....oh wait....no it doesn't.
It would if it were used as it is intended. That is to say, sleep and hibernate states ought to themselves be runlevels. I have never been able to puzzle out why this is not so already.
Re: (Score:2, Insightful)
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 o
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.
Re: (Score:3)
Boot up speed is incredible with /service (see http://cr.yp.to/daemontools.html [cr.yp.to]) and dependencies aren't hard to wire into those scripts at all. What kills me is that systemd is so much more complex for no gain over something so simple as an auto-restarting shell script.
Re: (Score:3)
What makes you think I don't? Of course, that's on my own systems since once the pollution is allowed in, the old stuff doesn't work so well anymore.
Re: (Score:2)
So what you're saying is that there is already a maintainer? Me not being from the universe with a bearded Spock, I figured I probably shouldn't kill anyone to take their place.
Re: (Score:3)
>> Gentoo can not be setup to use systemd too
Are you sure? My laptop begs to differ:
$uname -a
Linux jglaptop 3.12.6-gentoo #1 SMP PREEMPT Sat Dec 28 11:22:53 GMT 2013 x86_64 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux
and spits out things like this:
gerdesj@jglaptop:~$ systemctl status apache2
apache2.service - Apache Web Server
Loaded: loaded (/etc/systemd/system/apache2.service; enabled)
Active: active (running) since Sat 2013-12-28 12:18:
Re: "Slashmirrored" (Score:4, Informative)
Pretty obvious typo for "can now be".
Re: (Score:3, Insightful)
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
Re: (Score:3)
Re: "Slashmirrored" (Score:4, Insightful)
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" (Score:5, Insightful)
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" (Score:4, Insightful)
C++ automatic stack unwinding is even nicer, but you can't have C++ in the kernel because mindless ideologues.
Re: "Slashmirrored" (Score:4, Insightful)
Re: (Score:2)
Don't tempt us. The users, admins, and engineers that have to keep these systems running are not happy.
Re: "Slashmirrored" (Score:4, Insightful)
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: (Score:3, Interesting)
"go head over to the BSD world."
I already have. As a Linux user from very near it's beginning(93-94) and dumping Windows completely over it's shenanigans in the early 2000s. I'm now seeing Linux become Windows. Unfortunately BSD is affected by the influence of the shadow(guess the reference) as well(applications and support systems). Guess Plan9 if it's developers would stop treating it as their personal toy and expand it's application support to something a wider audience could actually use.
Re: (Score:3)
That's the most ignorant thing I've read all day -- the vast majority of people using Linux are not kernel developers, and I'm quite certain they don't navel-gaze enough to think they are.
I'm quite literally nervous about moving client servers to systemd in the future and we've purposely held back because the old init system is predictable and easy to manage.
Re: (Score:2)
Hi Theo!
Why, oh why? (Score:5, Insightful)
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: (Score:3, Funny)
Fortunately, the BSD world is much less insane.
Re:Why, oh why? (Score:4, Insightful)
Re: (Score:2)
Re: (Score:3)
Gentoo is currently pushing over to systemd. About a month ago they set stable keywords for gnome-3.8 and systemd, so that pretty much everyone who uses any gnome software, not just the gnome desktop, got pushed to systemd as well.
There is not any official word, but that was what happened. It's still possible to run an OpenRC system, but it takes a fair amount of work. The forums still have systemd migration problems, a month later.
There was an item on the Gentoo Bugzilla for upstart, but that was recent
Re: (Score:3, Interesting)
I'm just gonna leave this here.
https://plus.google.com/111049168280159033135/posts/4KJxFY8VvT1 [google.com]
Re: (Score:2)
Is OpenBSD really suitable for typical desktop uses? Does it perform well?
Re: (Score:3)
Re: Why, oh why? (Score:4, Interesting)
Re: (Score:2)
Honestly, I was happy with KDE 3 + compiz. And still am on some days (TDE is great!). I was not happy that I had to move my old work laptops (Dell C400 and D510, I needed the serial ports) back to Windows because they're no longer supported in Linux (and I was required to run 'supported and up to date' software and such by workplace requirements at the time).
Re: (Score:2)
What do you mean by supported, and why do you think your laptops weren't?
Re: (Score:3)
Uhhhh....
http://www.ubuntuupdates.org/package/xorg-edgers/precise/main/base/xserver-xorg-video-intel [ubuntuupdates.org]
If you're telling me it doesn't work (don't have one to verify myself), fine, sounds like it needs a bug report. KMS has nothing to do with anything. Using an older AMD driver doesn't preclude you from using a new and updated distribution. Ubuntu has had "nvidia-legacy" packages for similar reasons for years. Not sure why you don't like the radeon driver, but https://launchpad.net/~makson96/+archive/fglrx [launchpad.net]. It
Re:Why, oh why? (Score:4, Insightful)
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? (Score:4, Interesting)
I good reason is the future possibility to manage kernel features in a more formal way than with the /proc or /sys interfaces.
It has taken about a decade to bring a standard IPC protocol to Linux. I mean a protocol that truly work between applications from different team of developers.It's now time to use it from a wider audience. Making it part of the kernel not only make it a bit more fast, but it clearly make it a more appealing choice for applications that need IPC.
Re:Why, oh why? (Score:4, Interesting)
I good reason is the future possibility to manage kernel features in a more formal way than with the /proc or /sys interfaces.
What's wrong with /proc and /sys for kernel and hardware configuration tasks? It's easy and twekable, you can poke around in it without writing a program first, and it conforms to "everything is a file".
It has taken about a decade to bring a standard IPC protocol to Linux. I mean a protocol that truly work between applications from different team of developers.It's now time to use it from a wider audience. Making it part of the kernel not only make it a bit more fast, but it clearly make it a more appealing choice for applications that need IPC.
IPC is between processes, not between a process and the kernel.
Re: (Score:3)
I thought those vulnerabilities were vectors because IE6 ran with escalated privileges..
Re: (Score:3, Interesting)
Comparing a KDBUS to a JPEG or a PNG decoders ?
Try instead to compare the Linux KDBUS code to the Linux TCP/IP stack...
Seriously, the Linux kernel is only bloated by the fact that it need thousands of drivers to handle decades of hardware diarrhea that released incompatibles devices as fast rate. Certainly not by the KDBUS code.
Re: (Score:2, Funny)
Re: (Score:2)
So you believe I have no right to an opinion? Or just no right to express it?
Re: (Score:2)
Re: (Score:2)
So why all the sarcasm then?
Re: (Score:2)
Re: (Score:2)
Someone COULD have offered a rationale for DBUS (or at least some benefit they believe it offers) or it's inclusion in the kernel. They might have even convinced me making wrangling with LKML unnecessary. Apparently, nobody on /. has one. It would be rude to just bust in on LKML without at least attempting to gain some background first, eh?
Re: Why, oh why? (Score:2)
Re: (Score:2)
Tell me, was HAL the right thing? They seem to have changed their minds and abandoned it.
I've read the reasons for systemd. Faster boots, cleaner, more flexible, better at handling dependencies. Did I miss anything? Now, the reasons against systemd would seem to be that it adds dependencies, especially dependencies on systemd of other system tools such as dbus, it's more fragile, it certainly isn't as well tested, and it may not be so good at managing dependencies and being flexible as it proponents s
Re: (Score:2)
Argument from authority?
Re: (Score:2)
And you are just an Anonymous Coward.
Re: (Score:2)
Yes, and also because he is not alone at wanting DBUS in the kernel.
Re: (Score:3, Insightful)
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? (Score:4, Informative)
The biggest audio performance boost I have gotten was when I killed pulseaudio so that everything would use ALSA.
Re: (Score:3)
That would make doing useful things with sound that much harder though. I like my per-application sound controls without having to screw around with config files.
Re: (Score:3)
KDBUS sounds okay to me. Apparently it, in a lot of people's views, boils down to "DBUS done right" -- the protocol is completely different under-the-hood, and will be (or is intended to be, if the userspace side people don't fuck it up like they constantly do to udev) supported in userspace by a translation layer for old-DBUS programs.
Further, the kernel devs have a habit (substantially creditable to Linus Torvalds) of doing a lot of things right, and making sure they don't break anything in the process, s
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:5, Informative)
Re: (Score:3)
Why do those features need a kernel dbus?
Re: (Score:2)
KDbus ... A lot of this is driven by desktop projects, so things like smooth transition to a login screen ...
I'll bite- how does K/Dbus help with a smooth transition to a login screen?
Re: (Score:3)
Re: (Score:2, Insightful)
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.
Re: (Score:2)
I thought the idea for a kernel dbus came out of Nokia's Maemo team originally?
Re: (Score:2, Interesting)
What kind of OS is that?
An OS ready for the radiant fascist/socialist future where the user has no control over the computer driven devices he supposedly owns.
Dido? (Score:3)
Re: (Score:3)
Windows.
Re: (Score:3)
A sandbox would be a good idea. If I install software to interface to a printer, or read a spreadsheet I should reasonably expect that the software should only be permitted to what it claims to do. A good, working sandbox for drivers and applications would be good for the user and a significant advantage over windows.
Re: (Score:2)
Most of those people are hired and paid by Red Hat to code what Red Hat envision.
What happens right now is the biggest and most agressive consolidations process since the existance of Linux.
systemd and jounald as coreOS that consolidates all we had known. Logging, inetd, sysvinit, timed, udevd, ipc etc.
Gnome3 for dumb people as main Desktop dealing a lot with systems. Kernel that now implemented kdbus to explicitly communicate to systemd.
Wayland to replace X11 to work close to Gnome3.
All a big consolidation!
linux (kdbus) -> systemd -> wayland / gnome3
What remains from what we know ? Nothing!
I am not against consolidation but I am against this sort of agressive behaviour!
In 2-3 years nothing remains that reminds of Linux to be Unix related. Even worse there are talks to have some sort of iPhone or Android like package mechanism to place apps with all deps (libs etc) in a sandbox within an apps directory. Even systemd already provides dealing with that.
What kind of OS is that?
What's wrong with a sandbox? For application developers it is now easier to target only one platform "Linux" regardless of distribution. Are you telling me you never ran into a problem when you ran across a tool or application and find out that the only packages available are for Ubuntu, and you had to go and compile the thing yourself? Then spend about 2 hours because it didn't quite work right. Come on...
More Bloat ? (Score:5, Insightful)
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.
Re: (Score:2)
Seems like the primary use of D-BUS is for the desktop components, which already abuse/overuse inter-process communication.
DBUS is already used on a number of embedded projects since many years.
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:More Bloat ? (Score:4, Interesting)
I like Gentoo's OpenRC. Much better than SystemD.
Re: (Score:2)
"sane" and "rc.d" are mutually exclusive requirements. Maybe systemd is not the answer, but we know from decades of experience how bad rc.d is.
Re: (Score:2)
I find ssh_agent very useful. That's why I stuck it in my .bashrc like a sane person. There's no need for a bunch of unremovable crap when a couple lines in a script can take care of it for people who want it.
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: (Score:2)
Good luck if you try for example to use Bluetooth or Avahi without D-BUS...
Re: (Score:2)
Re: More Bloat ? (Score:2)
So this is the thing killing portability (Score:4, Insightful)
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: (Score:2)
Portability also means giving up on system-specific optimizations and features. Some people have decided that Linux's market share means it's time to bank on those optimizations. Why not?
Re:So this is the thing killing portability (Score:5, Insightful)
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 (Score:4, Insightful)
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: (Score:2)
Then we should turn away from GNOME3. Because they're taking compatibility lightly. Because they're wrongheaded. We should make sure that no distros ship GNOME3 or systemd as default. Sure, they're not serfs, they're just people promoting an inferiour solution that damages Unix.
Re: (Score:2)
Re:So this is the thing killing portability (Score:5, Insightful)
There's already a D-Bus implementation available on BSD and other Unices. The API is documented [freedesktop.org] 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.
Re: (Score:2)
I don't see giving up on openness, but yes, it represents a cavalier kiss-off to BSD. Developer privilege. And it is user privilege to turn one's back on this.
Re: (Score:2)
Re: (Score:2)
You forgot that Linux was created precisely because there was no truly open UNIX running on a PC a his time. Even 386BSD arrived after Linux started to gain a growing community. The Linux community always tried a lot of different approach, and this is the reason why it is do dominant today.
But I agree that Linux is more and more a norm by itself and that his UNIX part is slowly mutating into a simple compatibility interface layer. I am not even surprised about that since UNIX was created at his time for har
Re: (Score:3)
In other words, Linux isn't being engineered anymore, it's being driven by the masses.
You can use your own conclusion, but Linux was always driven by the masses of engineers that work on it. There is no other kernel project with so much authors. And this is precisely what make it so successful.
Now if you think that Linux is not a good engineering work, a lot of peoples will be more than happy to learn from you how to make it even better.
Re: (Score:2)
What?
D-Bus is still portable across multiple free Unices and even Windows. The standalone daemon isn't going away anytime soon, and I can't see the multitude of projects depending on it giving up cross-platform compatibility.
In-kernel IPC reduces context switching and other related overheads. I'm not sure exactly how much of a performance gain this gives D-Bus clients and the system as a whole but if someone wants to spend their Christmas playing around and seeing if something is better then great! And that
Listen to A.S.T. (Score:3, Interesting)
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?
Re: (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 compara
Re: (Score:3)
I agree that Linux isn't a microkernel, but I don't think adding an IPC framework like KDBUS to Linux makes it bloated compared to a microkernel. I believe that an IPC system is the one thing that all microkernels include. Including an IPC framework in the kernel should help move other functionality from the kernel to standalone user space process that expose services over IPC.
Too much navel gazing (Score:5, Interesting)
http://lwn.net/Articles/551969/ [lwn.net]
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 [github.com]
Let's stop all the FUD, and educate yourself on the reasons behind on this.
why not use binder (Score:2)
why not give up on dbus, and just use binder, which is already supported in the kernel?
Personally, I _do not want_ this.
While, we are at it, I do not want do-everything daemons like upstart or systemd. These monolithic programs of undefined scope are poor examples of software engineering, and not needed.
The stupid thing is (Score:3)
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.
Re: (Score:2)
You maybe have a service sending a lot of DBUS messages, because usually a dbus-daemon is very very low in processing time.
root# uptime /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session /usr/bin/dbus-daemon --system
00:18:50 up 17 days, 10:15, 9 users, load average: 0.25, 0.35, 0.39
root# ps -C dbus-daemon fw
PID TTY STAT TIME COMMAND
4616 ? Ss 0:12
2508 ? Ss 0:04
Re: (Score:3)
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