19 ms·

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 w

by 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.
  - mikepurvis 12y ago
    dbus handles a lot of cases where you have an unprivileged process like a GUI widget communicating information to a root process like a network manager. Because it's centralized and everything flows through the dbus process, a lot of it is about policy enforcement— ie, these methods can be called by this user or group, these other ones by this other group, etc. Examples of the configuration which controls this kind of thing: https://github.com/mungerd/vncbox/blob/master/data/dbus-config.xml https://github.com/mungerd/vncbox/blob/master/data/dbus-conf... http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman-dbus.conf http://git.kernel.org/cgit/network/connman/connman.git/tree/...

by hp 12y ago

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.
- mikepurvis 12y ago
  dbus handles a lot of cases where you have an unprivileged process like a GUI widget communicating information to a root process like a network manager. Because it's centralized and everything flows through the dbus process, a lot of it is about policy enforcement— ie, these methods can be called by this user or group, these other ones by this other group, etc. Examples of the configuration which controls this kind of thing: https://github.com/mungerd/vncbox/blob/master/data/dbus-config.xml https://github.com/mungerd/vncbox/blob/master/data/dbus-conf... http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman-dbus.conf http://git.kernel.org/cgit/network/connman/connman.git/tree/...