User bus conclusion

[Lennart Poettering]

On Wed, 10.11.10 12:22, Havoc Pennington (hp at pobox.com) wrote:

> So, I dunno. Let's clarify what's being proposed. Is it per-user
> sessions, or a user bus spanning N sessions?

It's N+1 really. N tty/ssh logins, plus 1 graphical login.

> > There's this certain "DBus is difficult for developers" urban myth
> > that's been floating around, and I'm not really sure that it's true.
> 
> All this multi-session/sudo/ssh/network-homedir stuff is difficult for
> developers, because there really is no decision on it. I don't think
> there's a sane solution that solves all cases. It's one of those
> things where it's either so complex nothing ever works (as you guys
> started this thread by saying, multiple logins are often broken
> anyway); or it's simplified and something is just defined as
> not-allowed/will-never-work which means people get pissed. In practice
> people just kind of flail around changing their app and OS behavior
> back and forth and going in circles.

To properly answer the question what a session is supposed to be we
probably should have something that doesn't just keep X or D-Bus in
mind, but the whole stack, from the kernel, over the system manager to
the display. In this is kinda what Ryan and I have in mind here, we want
to define the session along the lines of auditing, of systemd, of the
bus, of a cgroup, of the lifetime of XDG_RUNTIME_DIR. The end result of
this is that developers can rely on a very clear, very specific (and due
to only two busses in total also very simple) definition, that is the
same on every level of the stack.

The only remaining issue then is $HOME on NFS, which would still require
people to deal with file locking or the non-existance of it in some sane
way. NFS is unfixably broken at this time, so maybe GApplication should
simply take a special flag that would block multiple instances of the
same app running across the network. i.e. some simple flag that does the
right thing to implement Firefox-like "run-me-only-once" behaviour. That
way everybody who is able to do fine with lock-less atomic-rename-based
file atomicity should fine without this flag, and everybody else can
just set the flag if he doesn't want to spend to much brains on this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.