4 ms·

I really liked the "predecessor" DCOP better. Applications publish objects, others can call methods (one-shot) or functions (wait for response). From DBUS' own

I really liked the "predecessor" DCOP better. Applications publish objects, others can call methods (one-shot) or functions (wait for response). From DBUS' own (old) FAQ: > 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. IMHO DBus suffers from the kind of overengineering that's been endemic in Desktop Linux in the last few years: DConf/GSettings (as a less flexible, IMHO unneccessary replacement for GConf), PulseAudio and NetworkManager (initially really bad, now work nicely, as long as you don't have to debug problems...), all the *Kit stuff, systemd, and so on. For me, libraries like this don't really solve problems on average, but cause regressions.

guard-of-terra 12y ago
The main problem is, DCOP was explicit about it being a quick hack. While DBus featured a huge amount of bombast from the day one while being really slow on useful things. I think they did not even have a proper console client a few years into development and some shipping. "due to data validation and more "layers"" You can't really have data validation and proper layers without a spec. You just can't, it would be an annoyance instead of useful feature.
- hp 12y ago
  Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implementation was the most important thing (threads or main loop, no dependencies, etc) in order to be adopted. And then validation was required to use it on system contexts not only trusted in-user-session contexts. It also had to swap in for both DCOP (KDE) and CORBA (GNOME). These were the choices that made it viable and why it became widely used. Many years later people decided it would be nice to have performance too so they reimplemented with more assumptions that didn't used to be safe, and did the kdbus work. The result is still compatible with the original protocol because it was always possible to make a fast implementation. This is how open source works. People do what they care about. When speed came to the top of the list people did it. Adoption speaks for itself. Things are adopted when they are a viable solution. Others thought speed was the key and they were wrong; dbus was adopted precisely because it focused elsewhere. But speed wasn't precluded by the design and when people cared they solved it.
  - guard-of-terra 12y ago
    I'm not talking about runtime speed or latency, rather about development speed.
    - hp 12y ago
      I should have mentioned here earlier, the original thought with dbus was that nobody would use libdbus directly; KDE would use an API more or less exactly like DCOP and GNOME would use soemthing like gdbus. For that reason, libdbus was lowlevel and flexible in a way that made it annoying to use - convenience API in libdbus would have been bloat. What actually happened is that the high-level wrappers didn't get written for a long time because libdbus was just good enough that people didn't bother to work on alternatives. So that sucked, but it does seem to have finally been sorted out and libdbus is now on the way out AIUI.
  - toyg 12y ago
    > Adoption speaks for itself Well, DBus was politically pushed onto KDE back in the day, when there was a strong interest in making a success out of cooperation efforts in the Linux desktop space. IIRC, KDE was basically strong-armed out of DCOP. Once it was established as "the official IPC on the two dominant Linux desktops", it would have been difficult to ignore it regardless of its actual quality.
    - digi_owl 12y ago
      That seems to be the story of freedesktop.org in total. It was, iirc, supposed to be a place for KDE and Gnome to hammer out some cooperative issues, so that programs related to each project would coexist better. These days it seems like Gnome (or maybe i should say Red Hat?) is running the place, with KDE doing its own thing and glancing over the fence from time to time.
      - johnny22 12y ago
        i really don't see how you're getting that impression. We've seen cooperation on shared menus, mime types, dbus, and wayland (among others).
tenfingers 12y ago
I'm not against any of these projects in particular (they all solve a specific problem), however as you describe, all the recent infrastructure being pushed on desktop and servers is poorly designed and initially badly implemented. I cannot even blame the distributions, as projects such as DBus/-Kit/etc were initially just part of other, unrelated, projects that got mass adoption. The implementation got better (actually, systemd partially got rid of many -Kit components which never truly worked, which IMHO, doing us a favor), but the design is still wonky, still poorly documented, very difficult to debug as a result and understand as a whole. The fact that these tools rely on self-describing protocols with one single implementation without documentation also results in very tight coupling. It's also shifting the idea of having a cli interface to perform a task to a dbus interface. Often without any documentation of the dbus interface itself to begin with (or with a crappy cli wrapper).
- catern 12y ago
  How exactly is a CLI wrapper supposed to work without some kind of IPC? Most components of the system have an associated daemon running and maintaining them. You need some kind of way to communicate to that daemon. DBUS is the most common and easiest way.
  - stevejones 12y ago
    Most components of the system /are/ a daemon. Most of the terrible decisions in Linux infrastructure of the last 10 years have been making daemons where a protocol would would do the job more simply.
hp 12y ago
I think people who haven't hacked on making nice UIs for system features don't understand what problems these things solve. But people who have do, and that's why they code them. Is there a simpler, less-engineered way? Probably, in the truism sense that all software sucks. But then, anyone could have coded this better way and made it work, and they didn't. So the current work has the advantage that somebody did it and it exists. I'll take that. Knowing the problems solved here I actually think the current stuff is pretty good. Not flawless -it's software - but good. It does pretty much work. Go use 15 year old Linux if you want to replace nostalgic memories with a good dose of how much it sucked :-p
- djcb 12y ago
  Agreed -- I remember some of the alternative ways to solve the same problems, such as CORBA and various custom protocols, but they were painful to use... Now, early DBus was a bit lacking in that respect as well, but with GDBus (GLib's DBus implementation) it's become as straightforward as IPC can be, even in plain C; I've seen quite a few people new to the technology that were able to get up to speed with it quickly. It'll be interesting to see how people are taking DBus and pushing the boundaries of what it can be used for, such as kdbus. Thank you hp!
  - emcrazyone 12y ago
    Interesting perspective. I thought I read somewhere that ZeroMQ was championing becoming apart of the Kernel. I work in the embedded space and not knowing much about DBUS other than it's some fancy IPC and ZeroMQ, we went with ZeroMQ just because we saw a clear path for what we needed get done. Granted all our IPC communication was between our own apps. but after reading your post I keep wondering what REAL problems does DBUS solve besides having a standard messaging format? Could someone explain why a simple messaging format couldn't be deployed on top of something like ZeroMQ?
    - hp 12y ago
      This probably deserves a long blog post or something (maybe I already wrote it somewhere) but here's a teaser. dbus is not mostly about IPC. Linux desktops, including gnome, KDE, and those before them and alternatives to them now, use a "swarm of processes" architecture. This is as opposed to an alternative like smalltalk, Eclipse, Firefox, or Emacs where lots of plugins are loaded into one huge process. Problems common in server side IPC which aren't as big an issue here: scalability; network partitioning; protocol interoperability. Problems which are more of an issue: service discovery (can't just use DNS); tracking lifecycle of other processes; inherent singleton, stateful nature of hardware, the kernel, and user interfaces. The main way dbus helps with this is the star topology with a daemon that can start on demand and track all the processes. IPC is then coordinated with this in such a way that race conditions can be avoided, for example you can start a service and send it a command without a race that your command arrives too soon. Anyhow this is just enough to get an interested person tracking down the details, I'm not spelling it out obviously.
userbinator 12y ago
IMHO DBus suffers from the kind of overengineering that's been endemic in Desktop Linux in the last few years It's not just Desktop Linux; I've noticed the overengineering trend in basically... all software. There's many contributing factors, probably one of the biggest being the second-system effect ("there were some problems with the old way of doing it so let's find a new way that fixes them - and all the problems that could possibly occur in the future, whether or not they may actually become problems"). I think YAGNI needs to be applied far more often than it currently is. The solution to complexity should not involve adding more complexity.

guard-of-terra 12y ago

The main problem is, DCOP was explicit about it being a quick hack. While DBus featured a huge amount of bombast from the day one while being really slow on useful things. I think they did not even have a proper console client a few years into development and some shipping. "due to data validation and more "layers"" You can't really have data validation and proper layers without a spec. You just can't, it would be an annoyance instead of useful feature.

hp 12y ago
Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implementation was the most important thing (threads or main loop, no dependencies, etc) in order to be adopted. And then validation was required to use it on system contexts not only trusted in-user-session contexts. It also had to swap in for both DCOP (KDE) and CORBA (GNOME). These were the choices that made it viable and why it became widely used. Many years later people decided it would be nice to have performance too so they reimplemented with more assumptions that didn't used to be safe, and did the kdbus work. The result is still compatible with the original protocol because it was always possible to make a fast implementation. This is how open source works. People do what they care about. When speed came to the top of the list people did it. Adoption speaks for itself. Things are adopted when they are a viable solution. Others thought speed was the key and they were wrong; dbus was adopted precisely because it focused elsewhere. But speed wasn't precluded by the design and when people cared they solved it.
- guard-of-terra 12y ago
  I'm not talking about runtime speed or latency, rather about development speed.
  - hp 12y ago
    I should have mentioned here earlier, the original thought with dbus was that nobody would use libdbus directly; KDE would use an API more or less exactly like DCOP and GNOME would use soemthing like gdbus. For that reason, libdbus was lowlevel and flexible in a way that made it annoying to use - convenience API in libdbus would have been bloat. What actually happened is that the high-level wrappers didn't get written for a long time because libdbus was just good enough that people didn't bother to work on alternatives. So that sucked, but it does seem to have finally been sorted out and libdbus is now on the way out AIUI.
- toyg 12y ago
  > Adoption speaks for itself Well, DBus was politically pushed onto KDE back in the day, when there was a strong interest in making a success out of cooperation efforts in the Linux desktop space. IIRC, KDE was basically strong-armed out of DCOP. Once it was established as "the official IPC on the two dominant Linux desktops", it would have been difficult to ignore it regardless of its actual quality.
  - digi_owl 12y ago
    That seems to be the story of freedesktop.org in total. It was, iirc, supposed to be a place for KDE and Gnome to hammer out some cooperative issues, so that programs related to each project would coexist better. These days it seems like Gnome (or maybe i should say Red Hat?) is running the place, with KDE doing its own thing and glancing over the fence from time to time.
    - johnny22 12y ago
      i really don't see how you're getting that impression. We've seen cooperation on shared menus, mime types, dbus, and wayland (among others).

tenfingers 12y ago

I'm not against any of these projects in particular (they all solve a specific problem), however as you describe, all the recent infrastructure being pushed on desktop and servers is poorly designed and initially badly implemented. I cannot even blame the distributions, as projects such as DBus/-Kit/etc were initially just part of other, unrelated, projects that got mass adoption. The implementation got better (actually, systemd partially got rid of many -Kit components which never truly worked, which IMHO, doing us a favor), but the design is still wonky, still poorly documented, very difficult to debug as a result and understand as a whole. The fact that these tools rely on self-describing protocols with one single implementation without documentation also results in very tight coupling. It's also shifting the idea of having a cli interface to perform a task to a dbus interface. Often without any documentation of the dbus interface itself to begin with (or with a crappy cli wrapper).

catern 12y ago
How exactly is a CLI wrapper supposed to work without some kind of IPC? Most components of the system have an associated daemon running and maintaining them. You need some kind of way to communicate to that daemon. DBUS is the most common and easiest way.
- stevejones 12y ago
  Most components of the system /are/ a daemon. Most of the terrible decisions in Linux infrastructure of the last 10 years have been making daemons where a protocol would would do the job more simply.

hp 12y ago

I think people who haven't hacked on making nice UIs for system features don't understand what problems these things solve. But people who have do, and that's why they code them. Is there a simpler, less-engineered way? Probably, in the truism sense that all software sucks. But then, anyone could have coded this better way and made it work, and they didn't. So the current work has the advantage that somebody did it and it exists. I'll take that. Knowing the problems solved here I actually think the current stuff is pretty good. Not flawless -it's software - but good. It does pretty much work. Go use 15 year old Linux if you want to replace nostalgic memories with a good dose of how much it sucked :-p

djcb 12y ago
Agreed -- I remember some of the alternative ways to solve the same problems, such as CORBA and various custom protocols, but they were painful to use... Now, early DBus was a bit lacking in that respect as well, but with GDBus (GLib's DBus implementation) it's become as straightforward as IPC can be, even in plain C; I've seen quite a few people new to the technology that were able to get up to speed with it quickly. It'll be interesting to see how people are taking DBus and pushing the boundaries of what it can be used for, such as kdbus. Thank you hp!
- emcrazyone 12y ago
  Interesting perspective. I thought I read somewhere that ZeroMQ was championing becoming apart of the Kernel. I work in the embedded space and not knowing much about DBUS other than it's some fancy IPC and ZeroMQ, we went with ZeroMQ just because we saw a clear path for what we needed get done. Granted all our IPC communication was between our own apps. but after reading your post I keep wondering what REAL problems does DBUS solve besides having a standard messaging format? Could someone explain why a simple messaging format couldn't be deployed on top of something like ZeroMQ?
  - hp 12y ago
    This probably deserves a long blog post or something (maybe I already wrote it somewhere) but here's a teaser. dbus is not mostly about IPC. Linux desktops, including gnome, KDE, and those before them and alternatives to them now, use a "swarm of processes" architecture. This is as opposed to an alternative like smalltalk, Eclipse, Firefox, or Emacs where lots of plugins are loaded into one huge process. Problems common in server side IPC which aren't as big an issue here: scalability; network partitioning; protocol interoperability. Problems which are more of an issue: service discovery (can't just use DNS); tracking lifecycle of other processes; inherent singleton, stateful nature of hardware, the kernel, and user interfaces. The main way dbus helps with this is the star topology with a daemon that can start on demand and track all the processes. IPC is then coordinated with this in such a way that race conditions can be avoided, for example you can start a service and send it a command without a race that your command arrives too soon. Anyhow this is just enough to get an interested person tracking down the details, I'm not spelling it out obviously.

userbinator 12y ago

IMHO DBus suffers from the kind of overengineering that's been endemic in Desktop Linux in the last few years It's not just Desktop Linux; I've noticed the overengineering trend in basically... all software. There's many contributing factors, probably one of the biggest being the second-system effect ("there were some problems with the old way of doing it so let's find a new way that fixes them - and all the problems that could possibly occur in the future, whether or not they may actually become problems"). I think YAGNI needs to be applied far more often than it currently is. The solution to complexity should not involve adding more complexity.