Tracking users/sessions on the console

[David Zeuthen]

On Thu, 2006-01-12 at 15:28 -0800, Artem Kachitchkine wrote:
> > I read "being system-aware" as it implies a split into two daemons 1) UI
> > bits; and 2) system bits much like NetworkManager. Correct?
> 
> Yes.
> 
> > 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?
> 
> Well, I was trying to come up with a use case for ConsoleTracker in 
> Solaris and couldn't find a compelling one, so that's why I asked by 
> first question.
> 
> Power management: Solaris device power management is implemented 
> entirely in the kernel. PM settings are system-wide. It is fully 
> automatic: the kernel PM daemon detects periods of inactivity and 
> attempts to power down leaf devices or even entire branches by calling 
> respective driver ops. That worked out pretty well in the past on sparc 
> systems, and x86 port is in progress. So there doesn't seem to be a need 
> for desktop-specific power management daemon at this time.

(oh, I envy you guys.. if only the Linux kernel only was capable of
run-time power management (like turning off my wired ethernet adapter
now that I'm on wireless) I'd get more out of my battery.. some day
however..)

So, yes, I strongly believe in solving run-time power management in the
kernel proper, yes, but at the same time I also believe that the system
power management policy belongs in the desktop session. See below for
some ramblings...

> Networking: a project was recently started, called Network Auto-Magic 
> [1] that is taking a broad look at network configuration in Solaris. 
> It's too early to say how would that interact with the desktop, but I'm 
> pretty confident the UI will be separate (or even different UIs for 
> desktops and servers, who knows).

Did you guys investigate NetworkManager, btw?

> In terms of volume management, as you know this is still work in 
> progress. We haven't quite worked out volume sharing among multiple 
> users, but so far our requirements indicate one owner per device is the 
> most common case. Assigning devices to users is a separate issue though 
> - once we know who owns what, different users' copies of g-v-m should 
> not conflict. When noone is logged in on the console, it is assumed all 
> devices belong to root, and we'll run a root's copy of the volume 
> manager - not g-v-m; a basic, non-GUI, HAL-based volume manager. So 
> there isn't a use case for ConsoleTracker here either.

Thanks for the insights, very interesting. I guess, in contrast, that
the way it looks like on most Linux based systems we do enforce a lot
policy from the desktop session and it seems that the community at large
continue to expand on this.

My proposal is simply to run these desktop policy daemons system-wide
when no other user is logged in. To do this in a distro and OS
independent way we need infrastructure like ConsoleTracker.

Btw, the single biggest reason I think this approach makes a ton of
sense is the fact that that we can reap the benefits of the desktop
configuration system, e.g. gconf for GNOME or the KDE equivalent. Not
only is it easy to configure policy in terms of a user interface, it's
per-user, we have lock-down, we have Sabayon.. and... some day we can
utilize e.g. an LDAP back-end for gconf such that an admin for an
enterprise can change e.g. the power management defaults (or whatever
policy) for all of his 2000 deployed desktops.  The home server / SMB
markets are covered too by this proposal... the sysadmin simply presses
the "Make these settings system-wide" button in his GNOME UI, enters the
root password and things just work. In short, gconf just rocks, thanks
Havoc!

Thus.. I'm just not sure I can see the point in rewriting a policy
daemon for the system-wide case when there are so many benefits of
reusing the one we have for the desktop. In fact, I can't see why one
would ever write a policy daemon not using this scheme unless it's not
configurable at all. And.. for power management.. surely Solaris desktop
users will need to tweak preferences, don't you think they'll need
something like this

 http://freedesktop.org/~david/g-p-m-preferences.png

and don't you think the admin story above makes sense?

Oh.. I keep talking about GNOME, sorry, but nothing in my proposal
prevents a KDE oriented distributor to do the same using KDE
technologies. At the same time all this can even interoperate.

Argh, I'm rambling again and probably off-topic for this list. Sorry.

> 
> -Artem.
> 
> [1] http://www.opensolaris.org/os/community/approachability/nwam/
>