No announcement yet.

D-Bus Implementation Aiming For The Linux Kernel

  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by Ibidem View Post
    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.


    • #52
      Originally posted by liam View Post
      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.