[lfs-dev] dbus, systemd, polkit, and consolekit

Bruce Dubbs 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 
price.

  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.

Yes.

   -- Bruce





More information about the lfs-dev mailing list