D-Bus User Bus

[Havoc Pennington]

Hi,

On Wed, May 19, 2010 at 9:42 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> I don't see how the network problem makes a difference for whether we
> share a single gconfd between two local sessions of the same user or
> have two instances instead.

Because in the network case, you *must* have two instances.

So, if you support the network case, there's no advantage to have one
instance in the two local sessions; two instances ought to work fine,
since they do in the network case too.

If you make the instances-are-per-session model work, then network
case automatically works. If you have instances shared in the
same-machine case, then the network case is some other special case
(that probably does not work).

In brief, instance-per-session covers all cases (multiple sessions
either local or on separate machines); instance-per-(user,machine)
covers only the local case, and leaves network unsolved (and in fact
probably broken).

> Well, I acknowledge that, but what I propose would simply make it
> official that most programs cannot deal with multiple simultaneous
> logins at the same time.

However, historically this is not true. Historically running sessions
sharing a network homedir does pretty much work - except for people
trying to do per-user or per-homedir locking, which breaks it. So
GNOME was broken with Bonobo, and with gconfd for a while until we
hacked around it. But GNOME 1.4 worked before that, and
post-Bonobo-gconf-fixes GNOME worked at least a while after that. And
KDE and the pre-desktop fvwm/twm/mwm type desktops more or less always
worked and quite likely still do.

Lots of people used to wail about this GNOME breakage in both upstream
and distribution bugzilla.

Yes, there is theoretical failure with the last-wins loss of data. *In
practice* this has not been important, for several reasons:
* people can understand and cope with this failure mode
* the data being lost is rarely anything very important (whatever
couple prefs I just now changed, for example)
* it isn't as bad as simply not being able to run two sessions

The two-sessions case usually involves things like leaving yourself
logged in at work and then also trying to log in at home (using say
AFS), or having multiple computer labs plus your office machine,
things like that.

I assume people at universities and animation studios and so on still
do this, though I don't really know. But, you might want to try
blogging an intention to not support it and see what people say.

With the per-user bus you're basically just saying network homedirs
are unsupported, which is pretty radical. I'm all for radical but know
what you're getting into...

> Well, I am not too concerned with the display handling stuff being too
> hard. As I tried to point out multiple times I'd say that already many
> programs are broken when they are started more than once. With the
> scheme I proposed we'd just change the default from "broken but claims
> to work" to "refuses to work".

Well not all broken is equal. "last wins and overwrites" is a kind of
minor problem, which some stuff has now. "will not let me log in" /
"won't start up" is a big problem (if you're affected by it).

> Also, I think that the upcoming GTK application class could play a role
> here. With a simple flag the developer could express whether his app is
> multiple-display-safe or not. And GTK would then care about the rest and
> suffix the bus name that it registers with the display identifier.

If you can make the toolkit magically get it right that certainly helps.

> Well, I don't think dbus-session makes a good session manager. We should
> not confuse it with one. Process babysitting should be done by process
> babysitters, e.g. systemd.

it's not a session manager (please kill the term, it covers a bunch of
functionality that should not be bundled)

What the X server and dbus-daemon are doing here is like the killall
at the end of the OS shutdown scripts. Just doing in anything that
wasn't behaving itself. It works. It worked for the X server to do
this, and that's why dbus-daemon just copies the same known-working
model for things that may not connect to X. (Unlike Xlib, providing an
opt-out, of course.)

It'd be nice if there were some kind of broadcast "we are logging out
now" event that let you close cleanly and even block the logout to
open a dialog, etc. That's all prior to the exit-on-disconnect thing.

Havoc