D-Bus Implementation Aiming For The Linux Kernel

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

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

[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]

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.

[Ericg]

I don't think that is an entirely accurate summary. KDE developed dcop. Rather than adopting KDE's existing technology, Gnome created an incompatible clone of it, then had it declared an fd.o standard. So KDE, trying to be cooperative, abandoned dcop and adopted dbus (dbus at the time was technologically inferior). This seems to be how many fd.o standards come about.

And I am not sure what you mean by "back then", Gnome still doesn't collaborate beyond telling everyone else to do things their way.

Dbus FAQ:

10.

How does D-Bus differ from CORBA?

Start by reading Q: 9.

CORBA is designed to support object-oriented IPC between objects, automatically marshalling parameters as necessary. CORBA is strongly supported by the Open Management Group (OMG), which produces various standards and supporting documents for CORBA and has the backing of many large organizations. There are many CORBA ORBs available, both proprietary ORBs and free / open source software ORBs (the latter include ORBit, MICO, and The ACE Orb (TAO)). Many organizations continue to use CORBA ORBs for various kinds of IPC.

Both GNOME and KDE have used CORBA and then moved away from it. KDE had more success with a system called DCOP, and GNOME layered a system called Bonobo on top of CORBA. Without custom extensions, CORBA does not support many of the things one wants to do in a desktop environment with the GNOME/KDE architecture.

CORBA on the other hand has a number of features of interest for enterprise and web application development, though XML systems such as SOAP are the latest fad.

Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems work in terms of objects and methods, and have concepts such as "oneway" calls. Only D-Bus has direct support for "signals" as in GLib/Qt (or Java listeners, or C# delegates).

D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended, because CORBA is more generic and D-Bus has two specific use-cases in mind. This makes D-Bus a bit simpler.

However, unlike CORBA D-Bus does not specify the API for the language bindings. Instead, "native" bindings adapted specifically to the conventions of a framework such as QObject, GObject, C#, Java, Python, etc. are encouraged. The libdbus reference implementation is designed to be a backend for bindings of this nature, rather than to be used directly. The rationale is that an IPC system API should not "leak" all over a program; it should come into play only just before data goes over the wire. As an aside, OMG is apparently working on a simpler C++ binding for CORBA.

Many CORBA implementations such as ORBit are faster than the libdbus reference implementation. One reason is that D-Bus considers data from the other end of the connection to be untrusted and extensively validates it. But generally speaking other priorities were placed ahead of raw speed in the libdbus implementation. A fast D-Bus implementation along the lines of ORBit should be possible, of course.

On a more trivial note, D-Bus involves substantially fewer acronyms than CORBA.

16.

How does D-Bus differ from DCOP?

Start by reading Q: 9.

D-Bus is intentionally pretty similar to DCOP, and can be thought of as a "DCOP the next generation" suitable for sharing between the various open source desktop projects.

D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus should not be more complex for programmers. The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus.

D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though.

At this time, KDE has not committed to using D-Bus, but there have been discussions of KDE bridging D-Bus and DCOP, or even changing DCOP's implementation to use D-Bus internally (so that GNOME and KDE would end up using exactly the same bus). See the KDE mailing list archives for some of these discussions.

Sounds like dbus is more dcop than bonobo/ORBIT/Cobra

[TheBlackCat]

Of course its NIH, Gnome and KDE didnt collaborate at all back then so you had KDE with D-Cop which eventually became D-bus, and you had Gnome with ORBit. KDE's solution won out as far as community support

I don't think that is an entirely accurate summary. KDE developed dcop. Rather than adopting KDE's existing technology, Gnome created an incompatible clone of it, then had it declared an fd.o standard. So KDE, trying to be cooperative, abandoned dcop and adopted dbus (dbus at the time was technologically inferior). This seems to be how many fd.o standards come about.

And I am not sure what you mean by "back then", Gnome still doesn't collaborate beyond telling everyone else to do things their way.

[Ericg]

It's a NIH IPC mechanism

Of course its NIH, Gnome and KDE didnt collaborate at all back then so you had KDE with D-Cop which eventually became D-bus, and you had Gnome with ORBit. KDE's solution won out as far as community support

[curaga]

I fail twice with its vs it's, good indication that it's a morning

[curaga]

Glad you liked that
Thanks for the link, but, as you say, a lot has changed since then.
Honestly I don't know why dbus gets the bad rap. Sure, I wish the commandline tool handled some sort of introspection so I could more easily examine the messages, but this can be done, in principle, and, more importantly, it provides well defined interfaces and is pretty performant.

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.

[liam]

Sure, here it is: http://eleceng.dit.ie/frank/rpc/CORB...ceAnalysis.pdf.
Seems rather outdated, though (tests were done on Slackware 10.2, released in 2005), so D-Bus had a lot of time to improve since then.
I got quite fast, indeed! File descriptor passing was implemented in 2009 by Lennart Poettering, so that paper I read is obsolete, thankfully.

Glad you liked that
Thanks for the link, but, as you say, a lot has changed since then.
Honestly I don't know why dbus gets the bad rap. Sure, I wish the commandline tool handled some sort of introspection so I could more easily examine the messages, but this can be done, in principle, and, more importantly, it provides well defined interfaces and is pretty performant.