Tracking users/sessions on the console

[David Zeuthen]

On Thu, 2006-01-12 at 12:05 -0800, Artem Kachitchkine wrote:
> David,
> 
> > To get to the next level of the Linux desktop experience, I'm of the
> > opinion we need framework for tracking what is happening on the various
> > consoles attached to the system.
> 
> Could you summarize the motivation for such a framework.

Simply to reuse the policy engines from the desktop and make
multi-console and fast-user-switching work. 

> I read the blog, but the picture is still a bit hazy. I understand the 
> desire to apply policies (power mgmt, screen saver and such) outside 
> user sessions, but it seems to change the policy scope from 'desktop' to 
> 'system'. At the system scope we cannot assume desktop, e.g. we cannot 
> assume policies are stored in GNOME specific store. 

Depends on the vendor. Most vendors don't even run daemons like the ones
I talked about while no-one is logged in today, and if they do the
configuration is specific to the vendor. 

(for example, I think SUSE has a daemon for sharing optical discs put in
drives on the network if no-one is logged in).

> As an example, 
> assume a case of three console users: one running GNOME, another running 
> KDE and yet another running CDE. It seems to me that under the system 
> scope things are done a bit differently, and that desktop policy engines 
> should be system-aware, not the other way around.

I read "being system-aware" as it implies a split into two daemons 1) UI
bits; and 2) system bits much like NetworkManager. Correct?

I don't think this is necessary nor desirable (just ask the NM folks how
painful it is) for e.g. networking, power management, the screen saver,
volume management and so on. It's so much easier just having a single
process, look at e.g. g-v-m and g-p-m and how simple these daemons are.

Also, nothing in my proposal precludes you from splitting e.g. power
management into a GNOME, KDE and CDE front-end and a single system
back-end; personally I just think it's a waste of time and it
complicates things a lot without giving you any benefit.

Btw, do you have comments to what I'm proposing specifically for D-BUS,
e.g. the ConsoleTracker (instead of the big picture bits though I don't
mind discussing those)? I'm curious; would this be feasible / easy to
implement on Solaris too? Do you have something like this already?

Thanks,
David