User bus conclusion

[Lennart Poettering]

On Wed, 10.11.10 08:56, Thiago Macieira (thiago at kde.org) wrote:

> > Anyway, all that is unimportant. Because, here's the thing: If you
> > really want to create your own desktop environment supporting multiple
> > simultaneous graphical logins, then, hey, feel free to do so - no-one
> > is stopping you or taking anything away from you. But if you expect
> > GNOME or KDE or whatever [1] to support this, then, hey, talk to those
> > projects - don't complain on a list for an IPC library and message bus
> > system.
> 
> For the record, KDE hasn't decided that multiple logins are wrong. In fact, 
> they work and kdm does not block you from logging in. So I posted to kde-core-
> devel to check whether this is intentional and it is a use-case that KDE wants 
> to actively support, or whether it's just accidental and legacy because no one 
> thought of the consequences.

Note that many programs that are often used in KDE already break if you
do this (firefox, ...). Also, are you sure that KDE's gnome-panel
equivalent can properly deal with this?

> However, what happens if KDE decides that this is supported? 

Well, my secret hope that I can convince KDE to switch to adopt systemd
as session manager eventually. In systemd I definitely don't want to
support three levels of busses and babysitting managers. So I really
hope KDE doesn't decide to stick with the broken 3-level metaphor. (3
levels = systemd, user, session). With systemd we want to define the
user context programs run under as something that transcends all levels
of our stack, from the kernel to the session manager, including cgroups,
XDG_RUNTIME_DIR and everything else. I don't want to complicate that by
adding a 3rd abstraction layer.

> I'll probably ask that the session bus be left as it is: continues to get 
> started, no repurposing, no deprecation warnings.

Well, we wouldn't drop --session anytime soon anyway. But I think in the
longer run it would be great if everybody could agree on using the same
babysitting manager on all desktops.

That all said, the question whether I can convince KDE to adopt systemd
as session manager is probably nothing we should discuss here, and
there's some issues we'd have to find good answers to because we can
make this happen, i.e. KDE probably insists on support of
fork()+dlopen() for spawning processes, but in systemd this is not going
to happen. Also KDE probably cares about non-Linux much more than other
desktops.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.