4 ms·

Looks to me like DBus is actually pretty good and just needs some good implementations, some bug reports and some active contributors. I'm not super familiar wi

by tinco 11y ago

Looks to me like DBus is actually pretty good and just needs some good implementations, some bug reports and some active contributors. I'm not super familiar with non-server applications in linux, but isn't DBus also in widespread use? Most linux server apps I know communicate through the filesystem by leaving a .pid,.lock and/or a .sock somewhere and then setting up a custom channel using a handle to that. It feels kind of hacky, but at least you get to control the crappiness.

toyg 11y ago
The problem with DBus is that it's been around for ages now and still most developers say they support it because they have to, not because they like it. Basically, it's not going to get much better than it already is, or by now it would have.
- pzone 11y ago
  Providing an easy-to-use interface is the job of D-Bus client libraries, not the protocol itself. Client libraries are still a wild frontier, not at all settled.
  - zokier 11y ago
    I thought sd-bus was considered a good D-Bus client library? Haven't had the need to try it out myself, but the name has been popping up recently when dbus has been discussed.
    - vodik 11y ago
      ITts a lot better. I've ported libdbus-1 code to sd-bus and in practise I saw 100s of lines are replaced by about 20, with better error reporting on top of it.
rwmj 11y ago
kdbus actually supports a whole load of fairly sensible communications models, with a reasonably simple API, and ditches the horrible bits of dbus. It's a shame that it's (unnecessarily IMO) bound up in controversy. Edit: Poettering's talk about kdbus from devconf 2014: https://www.youtube.com/watch?v=HPbQzm_iz_k https://www.youtube.com/watch?v=HPbQzm_iz_k
- justincormack 11y ago
  It doesn't seem very general purpose unless there are also non kernel implementations, and you can't sanely remote it as it relies on the kernel for authentication.
  - rwmj 11y ago
    Its purpose is single host communication. If you assume a single host then you don't have to deal with distributing computing problems at all. Not sure why having non-kernel implementations is a problem. Is the fact that there is no non-kernel implementation of Unix sockets / TCP/IP / filesystems / name-most-other-Linux-kernel-features a problem for you? BTW I don't especially care about kdbus, but I do hate that there are no good, featureful communication primitives in Linux.
    - justincormack 11y ago
      The article was looking for multihost too which is why I mentioned it. There are some non kernel sockets implementations, but it is less of an issue as every kernel implements them, but kdbus is not implemented anywhere yet. It is also not possible to implement correctly in userspace as the security guarantees rely on a kernel, which is inconvenient. It is unlikely eg FreeBSD will ever implement it.

by tinco 11y ago

toyg 11y ago

The problem with DBus is that it's been around for ages now and still most developers say they support it because they have to, not because they like it. Basically, it's not going to get much better than it already is, or by now it would have.

pzone 11y ago
Providing an easy-to-use interface is the job of D-Bus client libraries, not the protocol itself. Client libraries are still a wild frontier, not at all settled.
- zokier 11y ago
  I thought sd-bus was considered a good D-Bus client library? Haven't had the need to try it out myself, but the name has been popping up recently when dbus has been discussed.
  - vodik 11y ago
    ITts a lot better. I've ported libdbus-1 code to sd-bus and in practise I saw 100s of lines are replaced by about 20, with better error reporting on top of it.

rwmj 11y ago

kdbus actually supports a whole load of fairly sensible communications models, with a reasonably simple API, and ditches the horrible bits of dbus. It's a shame that it's (unnecessarily IMO) bound up in controversy. Edit: Poettering's talk about kdbus from devconf 2014: https://www.youtube.com/watch?v=HPbQzm_iz_k https://www.youtube.com/watch?v=HPbQzm_iz_k

justincormack 11y ago
It doesn't seem very general purpose unless there are also non kernel implementations, and you can't sanely remote it as it relies on the kernel for authentication.
- rwmj 11y ago
  Its purpose is single host communication. If you assume a single host then you don't have to deal with distributing computing problems at all. Not sure why having non-kernel implementations is a problem. Is the fact that there is no non-kernel implementation of Unix sockets / TCP/IP / filesystems / name-most-other-Linux-kernel-features a problem for you? BTW I don't especially care about kdbus, but I do hate that there are no good, featureful communication primitives in Linux.
  - justincormack 11y ago
    The article was looking for multihost too which is why I mentioned it. There are some non kernel sockets implementations, but it is less of an issue as every kernel implements them, but kdbus is not implemented anywhere yet. It is also not possible to implement correctly in userspace as the security guarantees rely on a kernel, which is inconvenient. It is unlikely eg FreeBSD will ever implement it.