User bus conclusion

[Havoc Pennington]

Hi,

On Wed, Nov 10, 2010 at 10:31 AM, Ryan Lortie <desrt at desrt.ca> wrote:
> hi,
>
> On Wed, 2010-11-10 at 10:14 -0500, Havoc Pennington wrote:
>> If you did the user bus differently - so you had N sessions, with N
>> displays and session buses, and you shared the user bus among those -
>> then now the user bus has multiple X displays on it, and it's
>> genuinely distinct from the session bus. However, I think that model
>> is too complicated and difficult for app developers, personally, and
>> it's overkill.
>
> There is another subthread in this conversation demanding that we allow
> for exactly this.  I don't agree that it's useful, but I'm not
> completely convinced that we can write them off just like that.

Well, I always have - not "just like that," it's been discussed to
death already. This is the age-old user bus thread. I've never much
liked that proposal.

The proposal today, though, is new and I like it a lot: a per-user
singleton session. That seems to simplify things *and* solve new
problems. But I'm not sure it's really a dbus change primarily, and as
I've said ad nauseam here, I don't think it's a "user bus." A "user
bus" is adding yet another bus, to the existing mostly unspecified
free-for-all multi-session model, which nobody understands as it is.
Witness that bug about sudo/su behavior where nobody is willing to
take a stand and document how it should work or how dbus or apps
should be set up - most importantly, document what _won't_ work.

I feel like this thread is kinda mixing up the two issues. The thing I
took away as the heart of the original email you guys posted, was
per-user sessions. I love that. I think they have zip to do with user
buses.

Per-user session gets you the benefits of a user bus without having to
deal with all the weird shit if you have a session-spanning bus. Win.

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

If it's both, then I think user bus spanning N sessions should just go
back and read the (many) archived threads, and still think adding
another bus is Not Worth It. In fact the prospect of per-user-sessions
makes it even less worth it, because in per-user sessions having an
extra user bus is completely gratuitous/worthless bloat.... per-user
sessions obsolete the user bus.

Maybe we can have a "user" bus always, which sometimes goes with a
singleton session and sometimes spans sessions. But the
session-spanning user bus is more complex and different to use,
because there can be more than one session (and presumably even X
server) on it. So do you have to display-scope your services? Can
services use X at all?  I think session-spanning bus creates a lot of
questions that I would love to never think about, and per-user session
keeps us from ever having to think about them.

There could be a proposal for this. But the start of this thread
didn't address any of the complexities or problems of a true
multi-session user bus. It instead proposed, _correctly_, that we make
the _session_ per-user instead of the bus per-user, and that way we
_avoid_ all that complexity that we haven't been able to figure out
with one bus on N sessions. Hurrah!

Now, it's a mistake to go back and start trying to have that
complexity again. ;-)

If we're going to it needs some kinda proposal though and it's almost
totally orthogonal to per-user sessions imo.

> At the same time, if someone doesn't like what we are proposing here and
> runs multiple session busses, I'm just flat out of luck with regards to
> the guarantees that I want.

So make your code abort. If you want to require that an OS has
per-user sessions, then require it. Or to be a bit more friendly to
unmodified, current distributions, only abort when someone tries to
log in to the second session. At that point say "sorry, you already
have a session. you lose." We could even add stuff to libdbus, or
elsewhere such as glib, to make this easy. Call it a "session lock"

If everybody is going to try to support multiple sessions _anyway_
then doing all the work to make sessions singleton has _no value_
because you've retained all the complexity to support multiple! So you
may as well just allow multiple and not try to uniquify, right?

> 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.

Personally I think some things need to be defined as not allowed, and
then other ways of accomplishing the same goals that are more
tractable (such as rootless X servers, frontends that run as one user
and talk to a system backend, VNC instead of remote X apps, stuff like
that) will emerge.

Some problems are not solvable without major work. For example, shared
network home directories have no very easy solutions that are Correct.
Unfortunately, they have a pretty good solution which is Good Enough,
i.e. last-write-wins, no-locking. So nobody is going to do heroic
Correct Solutions, they're just gonna complain when you break
last-write-wins, no-locking.
Unfortunately the two-sessions-on-two-machines problem is still there
with a LOCAL_USER bus, and if you support it, then the LOCAL_USER bus
does you no good. (If you take network homedirs seriously, the only
use of a LOCAL_USER bus is when you have a machine-local resource -
such as hardware - that should be shared among sessions, but NOT
shared among users. Hardware shared among users could as easily be
directly shared among sessions. Homedirs have multiple LOCAL_USER
buses. So the utility of LOCAL_USER is very limited, it can't be used
to scope to a homedir.)


Anyway, concretely: why not go do the per-user session stuff; just use
the session bus as-is for it. If that pretty much works, then you can
start to make services and apps not work or abort if they turn up in a
second session, and deprecate multi-session. It's a very simple
approach, I like the proposal.

I don't see a reason to block on the user bus idea (i.e. spanning
multiple sessions with the same bus). If per-user sessions don't catch
on maybe come back to that user bus idea. But per-user session kills
off the user bus which is part of the win. Whatever you think about
the user bus, it is clearly obsolete and irrelevant in a per-user
session world, so why not just jump to the per-user session world and
skip all this.

The alternative path, I think, is to say per-user session is pointless
because the demand for multi-session is too high. At that point
per-user session gets you nowhere because apps and libs have to
support multi-session anyway. So you'd drop the per-user session
concept and come back to the user bus discussion and just have that
discussion, ignoring the per-user session idea.

Anyway are you changing the session model or adding another bus to the
existing session model? not the same proposal.

My .02 is that per-user session will get you flamed to death and it
will break all the thin-client/computer-lab-with-NFS-AFS setups.
However, it will make a lot of single-machine use-cases much easier to
think about, and be more what app developers expect, and set you up
better for a post-X world. I think it's a mistake to try to do
per-user session and then cave and support multi-session also. Pick
one model or the other... take the heat. ;-) stop wussing out

Havoc