[charcircuit]

>IPC socket

This IPC is a custom built IPC that has no security. This means that any program can do stuff like steal focus or drive other window manager policy if the plugin is there. There is also a plugin that exposes the ability to send key or mouse events.

Applications should just use DBus instead of creating their own custom IPC protocols just because they feel like it.

[bsder]

In what way is DBus better than something like Cap'n Proto? What does it cover and not cover? What other IPC/RPCs compete with it?

When I start seeing C++, AUTH, and Kerberos I start getting concerned.

When I don't find a Python-only module for something claimed to be "simple", I start getting very concerned: https://pypi.org/project/dbus-python/

[charcircuit]

>In what way is DBus better than something like Cap'n Proto?

In this specific context it is less about being better and more about being the standard for apps that are part of the Linux desktop except for Wayland which has its own. There are benefits in developers all being familiar with dbus, not having to use different clients for each program you want to talk to, it is easier to secure, etc.

[bsder]

> There are benefits in developers all being familiar with dbus, not having to use different clients for each program you want to talk to, it is easier to secure, etc.

Is it those things?

People don't seem to use DBus at all outside of Linux. That would seem to imply that, by and large, it isn't those things. And the fact that someone on Linux in exactly the situation where it should be used wasn't willing to use it suggests that maybe there are significant issues.

[charcircuit]

>People don't seem to use DBus at all outside of Linux.

Because it is a part of freedesktop, a project largely about creating software and specifications for the Linux desktop. Windows has COM. Mac / iOS have XPC. Android has Binder.

> And the fact that someone on Linux in exactly the situation where it should be used wasn't willing to use it suggests that maybe there are significant issues.

It is from cultural and educational issues. It isn't just a coincidence that all operating systems I listed above have a standard IPC mechanism that they use for services.

[junon]

DBus is a great protocol. It's also a very slow protocol. It's also very cumbersome to implement. The official libraries are quite messy and very opaque. It also assumes you're using systemd, which isn't always the case (I love systemd personally, but there are valid reasons, even non-technical ones, for people to choose not to use it).

[ammen99]

The IPC plugin is optional (you don't have to enable it) and nothing stops you from writing a dbus plugin to accomplish the same tasks :)

Personally, I prefer IPC because it is simpler to implement, debug and use.

[nickstinemates]

Isn't dbus a pretty heavy dependency to bring in to a project?

[vidarh]

Dbus can work peer to peer and the protocol is lightweight, so using the protocol and giving the option of either binding to a socket or connecting to the message bus isn't that much effort, and then you cater for both people who want to run the message bus and those who don't.

[charcircuit]

If a program is targeting the Linux desktop (freedesktop) then it should be assumed that dbus exists.

[junon]

Not really. It's just a bit cumbersome to use and assumes a lot about the system's setup. The protocol itself is actually pretty lightweight and simple. The library is a pain to deal with at times, at least it was several years ago.