[systemd-devel] Systemd --user and the role of DBUS API

[Michał Zegan]

I may not understand something, but how does it work when I have things 
like at-spi2-registryd running on my session? I cannot start one local 
and one remote gui session, for example? Of course I mean the user bus.

W dniu 19.08.2015 o 18:13, Simon McVittie pisze:
> On 19/08/15 14:12, Mantas Mikulėnas wrote:
>> sd-bus has better performance and native
>> kdbus support (and a better API than e.g. dbus-glib), but if you're
>> writing programs in GTK or Qt or EFL, then you'll still want GDBus or
>> QtDBus or Eldbus.
> To clarify, *everything* has a better API than dbus-glib. libdbus, the
> low-level reference implementation that is described as painful by its
> own documentation, is better than dbus-glib. Please don't use dbus-glib.
>
> If you don't care about portability beyond Linux, sd-bus is essentially
> a better libdbus; if you do care about portability beyond Linux, sd-bus
> is unsuitable.
>
>> The current devel branch (1.9.20) of dbus-daemon installs the
>> --user units dbus.socket and dbus.service necessary for this.
> It only does that if you configure with --enable-user-session. It is
> currently opt-in, because it changes the semantics of how the OS is put
> together, and some people seem to feel very strongly about the
> historical per-login-session buses. I might swap the user bus from
> opt-in to opt-out in 1.11 or 1.13 or something. On Debian and its
> derivatives, installing the dbus-user-session package has the same
> effect as --enable-user-session (and I'd encourage other general-purpose
> distributions to use similar packaging).
>
> dbus 1.9.20 is about to become dbus 1.10.0 with only trivial changes, so
> a stable branch with optional user-bus support is (finally) around the
> corner.
>
>> The user bus address is
> ... tried by default in libdbus 1.9, GLib 2.45, and sd-bus; so you don't
> need to set DBUS_SESSION_BUS_ADDRESS at all, unless you need
> compatibility with older versions, or reimplementations like dbus-sharp.
>
>> (Technically the same can be done with dbus 1.8.x as well, but AFAIK the
>> developers do not approve.)
> We don't add features in stable-branches, particularly features that
> change semantics, so libdbus 1.8.x does not have the necessary code
> changes to make the right things for a user-bus happen by default. You
> can backport them, at your own risk; or you can just parachute in the
> dbus.socket and dbus.service files and not make the code changes, but
> then setting DBUS_SESSION_BUS_ADDRESS appropriately is your responsibility.
>