org.freedesktop.PowerManagement

[Carsten Haitzler (The Rasterman)]

On Wed, 21 Mar 2007 20:53:17 +0000 Richard Hughes <hughsient at gmail.com> babbled:

> On Wed, 2007-03-21 at 21:19 +0100, Oswald Buddenhagen wrote:
> > On Wed, Mar 21, 2007 at 07:26:43PM +0000, Richard Hughes wrote:
> > > On Wed, 2007-03-21 at 20:02 +0100, Oswald Buddenhagen wrote:
> > > > that's not the point. i was talking about privilege elevation through a
> > > > password dialog and similar.
> > > 
> > > That's not the job of a session power management interface. You're not
> > > going to present to the user:
> > > 
> > > ===== Suspend ======
> > > You have not got the permissions to suspend
> > > Enter root password: [_______________]
> > > 
> > actually, i *am* going to. the login managers (can) do the same for
> > complete shutdown, so there is no reason not to do so for "partial"
> > shutdown (which also suspends network services, etc.).
> 
> No offense intended, but I think this is really crazy.

agreed. the admin (or distribution setup) should set the policy - can normal
users at the console shutdown, reboot, suspend etc. for "desktop distros" this
will likely be turned on by default. i see no point in exposing the need to
enter authentication to do such a basic thing that the vast majority of users
will simply EXPECT to be able to do with THEIR desktop. as below - they can
just yank the power cord and cause much more damage instead.

> > > Either the user can suspend or not.
> > > 
> > quite simplicistic world view. :)
> 
> Well, yes. I can't think of a single use case where we would want to
> raise a privilege to do something like shutdown. If a user has physical
> access to a machine they can just pull the power cord.
> 
> > > > generalizing it, a simple "may/may not" answer might be
> > > > insufficient, as the user might be able to change the situation.
> > > 
> > > How? Got any real-world use-cases?
> > > 
> > ask the thin client user at the next desk to log out from this box.
> > wait for a download to complete (okay, we miss quite a lot of
> > infrastructure to actually detect such a situation).
> > cancel/reschedule the cron job in ten minutes.
> > i can go on forever ...
> 
> Err, real world power management use cases? Can you elaborate on these a
> little please.
> 
> > > Sorry I don't understand - are you saying that we shouldn't split the
> > > session and system stuff? If so, all the UI will have to abstract all
> > > the hardware again, and we are back to abstracting HAL in each
> > > application with no gain.
> > > 
> > i guess this is not what i'm saying, as i really have no idea what you
> > are talking about. :}
> > a policy brings together event sources, matches them against conditions
> > and triggers actions. from may 2006 mail it should become clear that
> > both the events and actions can be of very different kind, but still be
> > subject to one policy. this also means one user interface, unless you
> > want to make it completely incomprehensible (like the current dmps vs
> > screensaver situation in kde). splitting the api by actions but still
> > providing policy functions in them (fooAllowed) is just odd in that
> > context, as all clients and all servers of these apis are the same two
> > programs.
> 
> Err. We just need a simple API for stuff like beagle to ask "is this
> laptop on AC power" so it can avoid burning the disk on battery power.
> It's not about policy control, that's up to the dameon which will vary
> between implementations.
> 
> > > We need the session interface to present stuff that is trivial for
> > > applications to process. Anything more, and they can query HAL
> > > directly and do their own logic.
> > > 
> > that makes your "standard" redundand, because a fully-fledged
> > implementation would always opt for the latter (even if it would offer a
> > simple frontend by default).
> 
> No. Beagle shouldn't have to worry that we have a UPS attached, and two
> batteries, which discharge sequentially, just to make a *trivial* policy
> decision.
> 
> Richard.
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)