D-Bus Implementation Aiming For The Linux Kernel

[liam]

It's a NIH IPC mechanism that has many downsides (weird protocol, requires a daemon) while most of its users do not make use of its strengths (multicast simpler than via networking).

It's existence has so led many apps that do not need it to use it, just because it's the official fd.o alternative. Which brings the downside of having to run the unnecessary daemon to users.


It's security and other issues like performance do not concern me; its primary downside to me is the requirement on a daemon. I'm sure others have other reasons to dislike it.

Are you calling it NIH b/c of dcop, or were you a fan of corba?
What's wrong with the protocol? What's wrong with a daemon (addmittedly I'm not super excited that we need two instances running but it's not that big of an issue)?
Your point about misuse is well taken, but that is more the fault of application/framework developers. Can't blame the bread makers if someone decides to build a house out of their product.

[Ibidem]

Trivia: From what I've read, D-Bus is pretty close to ToolTalk, which is the message-passing part of CDE. ToolTalk runs on top of Sun or DCE RPC (glibc2 includes sunrpc, and tirpc is another version of the same).

One criticism of dbus I remember hearing is that it's pretty much reinventing an RPC system (in the name of IPC), when there are already several ones out there. I wouldn't be qualified to verify that, though. Another line is that it's "over-engineered" and needlessly complex.

Considering curaga's involvement (Tiny Core Linux), I suspect he's looking at it from the aspect of bloat.
When you're dealing with a distro that runs on a 486 with ~48 MB RAM and the CD is 12MB, extra daemons look a lot more wasteful than they do for an average Ubuntu or Fedora user.

[liam]

Trivia: From what I've read, D-Bus is pretty close to ToolTalk, which is the message-passing part of CDE. ToolTalk runs on top of Sun or DCE RPC (glibc2 includes sunrpc, and tirpc is another version of the same).

One criticism of dbus I remember hearing is that it's pretty much reinventing an RPC system (in the name of IPC), when there are already several ones out there. I wouldn't be qualified to verify that, though. Another line is that it's "over-engineered" and needlessly complex.

Considering curaga's involvement (Tiny Core Linux), I suspect he's looking at it from the aspect of bloat.
When you're dealing with a distro that runs on a 486 with ~48 MB RAM and the CD is 12MB, extra daemons look a lot more wasteful than they do for an average Ubuntu or Fedora user.

More interesting info. Thanks.
I certainly get the memory concern (that was all I could think of as a criticism as far as being a daemon is concerned), but I don't consider that a problem for most. This kernel implementation should be piggyback on the networking infrastructure so it may not represent much in the way new code (IOW, reliable). That and being transparent to current dbus uses should make it a nice choice for tiny distros.

[curaga]

Are you calling it NIH b/c of dcop, or were you a fan of corba?
What's wrong with the protocol? What's wrong with a daemon (addmittedly I'm not super excited that we need two instances running but it's not that big of an issue)?

I'm calling it NIH because of the few dozen existing IPC designs that existed before it, including dcop and corba. I'm not a fan of dcop or corba. Most of the existing IPC mechanisms do not require a daemon, and those would be suitable for the majority of d-bus use on the desktop.

The daemon has many downsides, mainly wasting your cpu and ram from my POV. The other bad parts (performance due to many context switches) are what brought this thread. Also the quality standards in other places (kernel, glibc) are a lot higher than with random userspace apps.

This is relevant on more than old cpus: consider Atoms and Bobcats, running current *Ubuntu on them is just painful, even with a light WM, due to all the crap in the background.