User: Password:
|
|
Subscribe / Log in / New account

The unveiling of kdbus

The unveiling of kdbus

Posted Jan 25, 2014 15:24 UTC (Sat) by makomk (guest, #51493)
In reply to: The unveiling of kdbus by ovitters
Parent article: The unveiling of kdbus

There's also stuff like the discussion later on, where Lennart makes it clear that he doesn't think users should have more than one session open at once and will refuse patches that make this work. He talks about their views as being political and portrays them as having some kind of unneccesary attachment to the idea this should work, whilst spinning his own insistence on dictating how people use their computers as an entirely technical "design choice" - yet one that he will not budge from even if other people do the hard work and come up with patches to make it possible. Frankly, the whole thing reminds me of the tactics that some of the more unpleasant ideologues use to dismiss people who won't go along with their ideology.


(Log in to post comments)

The unveiling of kdbus

Posted Jan 25, 2014 16:11 UTC (Sat) by kmacleod (guest, #88058) [Link]

I misunderstood the "one session" part too.

Lennart's design goal appears to be (from his comments to the ml and irc) that there is only one user bus (and one process manager per user) and that each login on any graphical display be merged into one compositor+shell, xinerama-style.

The GNOME guys are insistent on having only one logical session (where session in this context means the compositor+shell doesn't treat multiple displays as independently usable workplaces).

It seems to me that a different compositor+shell could easily support merging multiple logins into one user bus (and one process manager) but still treat some displays as independent workplaces by presenting a menu/topbar/hot-spots and attached devices on separate workspace displays, even to the point of allowing someone to simply throw a running app from one workplace to another.

So having one user bus and one process manager per user seems like a very reasonable low-level approach that allows the desktop environments to handle multiple workplaces however they want.

The unveiling of kdbus

Posted Jan 26, 2014 20:46 UTC (Sun) by ovitters (subscriber, #27950) [Link]

He said the lower levels would allow it, just that the higher levels (GDM) would turn everything back into one session.

> Frankly, the whole thing reminds me of the tactics that some of the more
> unpleasant ideologues use to dismiss people who won't go along with their
> ideology.

Frankly, that kind of comments are inappropriate.

The unveiling of kdbus

Posted Jan 26, 2014 23:22 UTC (Sun) by smurf (subscriber, #17840) [Link]

I wonder what the use case of having multiple sessions per user is.
Power users can easily create another login if they need a separate session for whatever reason.

Everybody else should just get attached to their existing session. That already happens today, you get a strongly-worded "either you use your existing session or something might break" warning (I cannot remember which desktop environment does that, as I usually only use the login screen directly after boot-up).

What's the problem, beside "it has always worked that way and now Lennart says it's nonsense, therefore Lennart is full of it"?

The unveiling of kdbus

Posted Jan 27, 2014 1:50 UTC (Mon) by kmacleod (guest, #88058) [Link]

Use cases I see:

  • Remote desktop: When I VNC/RDP into my desktop from another location (home or conference room). This shouldn't "replace" my primary session (log me off or mess up all my apps on my desktop screen) and I should get my own menu and hot-spots.
  • Remote apps: Same thing, but just one app thrown rootless to my phone or TV, which has its own input and audio devices. In reverse: where I'm running apps on a VM back to desktops.
  • Microsoft's PixelSense (nee Surface): All about having multiple user's remote apps on shared displays, moving between common workspaces and personal workspaces.
  • Multiple terminals: Seats/workplaces in the kitchen, bedroom, bathroom, wallscreen. Might be a dumb USB seat or a tablet/laptop/wireless touchscreen not running the same OS or version of Linux (ie. you can't just migrate the running app container to the other location, only the I/O).
  • Development/testing: With one user bus and user process manager it's still necessary to run different "desktop sessions" to develop and test alternate desktop environments, compositors, and shells on the same host (with containers and, given the above, with VMs). They need to be able to function reasonably (or better) under one bus and manager.

As I said in my comment earlier, one user bus and one process manager per user/host is good, I'll go further to say one "instance" of GNOME/other DE is good too but there should be (probably freedesktop.org-level) support for multiple session-like support for different desktops, seats, workplaces, apps, etc.

This might take the form of namespace hierarchies in the D-Bus user bus or, more likely across different machines, some other way to provide "localilty" to apps that need to know.

X11 was originally intended to fulfill this and did extremely well for years (and for many legacy cases still works great). Over time as apps got closer to the hardware X started performing poorly and really doesn't work well for this anymore. Wayland and remote display protocols are much better placed for doing this today.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds