News for hackers. Stuff that matters.
Re:The Sorry State of Convenient IPC (2014) by tinco on Sunday August 30, 2015 @12:18PM (#10143690)
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.

Re:The Sorry State of Convenient IPC (2014) by rwmj on Sunday August 30, 2015 @02:48PM (#10144145)
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

Re:The Sorry State of Convenient IPC (2014) by justincormack on Sunday August 30, 2015 @06:11PM (#10144636)
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.
Re:The Sorry State of Convenient IPC (2014) by rwmj on Sunday August 30, 2015 @06:33PM (#10144674)
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.

Re:The Sorry State of Convenient IPC (2014) by justincormack on Monday August 31, 2015 @08:44AM (#10146545)
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.

Re:The Sorry State of Convenient IPC (2014) by toyg on Sunday August 30, 2015 @01:54PM (#10144000)
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.
Re:The Sorry State of Convenient IPC (2014) by pzone on Sunday August 30, 2015 @02:24PM (#10144091)
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.
Re:The Sorry State of Convenient IPC (2014) by zokier on Sunday August 30, 2015 @02:37PM (#10144124)
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.
Re:The Sorry State of Convenient IPC (2014) by vodik on Sunday August 30, 2015 @03:17PM (#10144215)
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.