[Pm-utils] Re: Better integration with power management scripts

Matthew Garrett mjg59 at srcf.ucam.org
Thu Apr 27 08:42:07 PDT 2006

On Thu, Apr 27, 2006 at 04:31:23PM +0200, Holger Macht wrote:

> And exactly that it the crucial point: "we care about". Who is this "we"?
> You? Me? Someone else? And exactly because you don't know who "we" is and
> which application he is using, IMO it is most desireable to support as
> many applications as possible. Because also users which aren't programmers
> and aren't able to fix programs use applications ;-)

We've got two options here:

1) We (the distributions) are shipping the software. We can fix it, so 
this is unneeded.
2) Third party vendors are providing the software. They can either (a) 
provide a drop-in file that fudges with power management, or (b) fix 
their code to properly conform to the new interfaces.

(1) doesn't require what you're proposing. (2) only does if they choose 
course of action (a). Course of action (b) is not significantly more 
work, but is significantly more correct. Why should we support option 
(a) at all?

> > Do you have any use cases where policy decisions need to be made during 
> > the suspend process? I honestly can't think of any - all the information 
> > is available beforehand.
> You need this feedback definitely at least at one point: You need to know
> if the suspend succeeded or not.

Naively, that's trivial - you're still executing and time has passed in 
a continuous manner. But hal already has support for this - the dbus 
method simply returns an error if the script doesn't exit correctly.

> As soons as vendors put their scripts into this architecture, you don't in
> which case it might be helpful. But if you don't want to support special
> setups, but just the plain basic methods that come along with Hal or the
> distributions you think to know of, that's ok. But then I'm sure it's not
> the solution that fits most peoples needs.

No, now you're arguing "We need this feedback because we're providing 
the ability for people to do broken things". A better solution is "Don't 
provide the ability for people to do broken things". Figure out what 
vendors need, and then design for that - don't leave the design so open 
that people can ship completely crack-addled addons, because they'll do 
so and the world will be a worse place.

Matthew Garrett | mjg59 at srcf.ucam.org

More information about the Pm-utils mailing list