Page 6 of 6 FirstFirst ... 456
Results 51 to 54 of 54

Thread: D-Bus Implementation Aiming For The Linux Kernel

  1. #51
    Join Date
    Jan 2009
    Posts
    1,195

    Default

    Quote Originally Posted by curaga View Post
    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.

  2. #52
    Join Date
    Nov 2011
    Posts
    263

    Default

    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.

  3. #53
    Join Date
    Jan 2009
    Posts
    1,195

    Default

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

  4. #54
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •