[lfs-dev] dbus, systemd, polkit, and consolekit
bruce.dubbs at gmail.com
Sat May 10 09:43:13 PDT 2014
Armin K. wrote:
> On 05/10/2014 05:29 PM, Aleksandar Kuktin wrote:
>>> On Sat, 10 May 2014 13:15:16 +0200
>>> "Armin K." <krejzi at email.com> wrote:
>>> On 05/10/2014 04:37 AM, Bruce Dubbs wrote:
>>>> I tried to step back and see just what is all this dbus, systemd,
>>>> polkit, and consolekit stuff all about. My conclusion is that it
>>>> is to manage multiple simultaneous desktops on a single system.
>>> Almost true. It's rather there to manage multiple simultaneous *users*
>>> on a single system, aka "multiseat" but its modern interpretation, not
>>> the old stuff from 70s.
>> Okay. Now we're talking. :) It there somewhere a place where we can
>> read the new ruminations about the new interpretations and develop our
>> beliefs about them?
> I remember Bruce mentioned a multi seat setup that had several physical
> consoles (each with monitor and keyboard or other input device)
> connected to one ugh, machine, and all could use that machine at the
> same time.
Not exactly. When I was in grad school, we had Sun workstations
(basically thin clients) hooked up as X servers accessing several
central systems that had the home directories and X clients. IIRC, the
workstations had 100M (not G) disk drives.
That type of network is really quite obsolete due to advances in HW and
One of "modern" multi seat implementations is what I tried
> (but it seems I failed) to explain in my reply. UNIX and UNIX Like OSes
> are multi user systems by design. While setups mentioned at the
> beginning of this message are not common nowadays (not that I've seen
> any in my life), network and serial console access to the machine are
> not so uncommon.
I doubt serial connections are common, but network one are.
You can have physical access (keyboard, mouse and
> monitor connected to the machine), network access, be it VNC or SSH or
> what not and other ways of having access I'm not familiar with. That's
> what "modern" multi seat interpretation I was talking about (at least
> that's how I managed to interpret it).
>>> In that way, several users can be logged in, while the only one of
>>> them will get permissions to access the input and output devices that
>>> are tied to the workstation he's currently working at. Others, while
>>> they may be logged in via SSH or who knows what other way won't be
>>> able to use such devices because they are not using them physically.
>> It should be noted that there are few situations where this is actually
>> usable in the real world. What I am picturing right now is technical
>> support logging into a workstation to "do something" while the
>> workstation user (or the System) doesn't trust technical support to not
>> mess things up. But in that case, why the **** have you hired them? Or
>> took on a contractor whose people you do not trust?
> Imagine a corporate network with thousands of users accessing some sort
> of server with gui from a remote location. You don't want them to be
> able to "see" what's for example, GPU rendering, what CD in the cd drive
> contains, to "hear" what's playing through sound card, etc. But when
> some of these users physically interracts with the machine, you want it
> to be able to see what's on the screen, to be able to play sound, mount
> usb and/or cd drives, etc.
I really doubt this. There would be way too much network overhead.
What you would see is a DB server providing data to remote clients.
There is no need to do the rendering remotely unless doing something
that takes a supercomputer (e.g. weather simulation) and then you are
only accessing bits and not any sort of hw.
> As for second question, hardware is not accessed by DBus. Programs
> merely ask DBus if the user is able to access certain device and if so,
> session manager will grant access to the device node using ACL's. Disk
> and Power management are done by separate daemons running as root,
> udisksd and upowerd most commonly.
Yes, I agree with this description.
> I am not preformance expert, but if you are using stuff that relies on
> things mentioned above, the preformance impact this delivers over the
> modern desktop environments is rather small.
More information about the lfs-dev