Re: New modules in 2.14

[Richard Hughes <hughsient gmail com>]

On Tue, 2006-01-17 at 22:37 -0500, Ryan Lortie wrote:
> Hello.
> 
> On Mon, 2006-16-01 at 19:13 -0700, Elijah Newren wrote:
> > Ok, here's what I'm guessing is the rough module consensus after
> > having re-read or skimmed a ton of emails:
> > 
> > In:
> > - gnome-power-manager
> 
> I don't think it's appropriate to include gnome-power-manager at this
> point.  There are a number of reasons for this.
> 
> First, I don't think that g-p-m itself and the technologies that it
> depend on are mature enough that we should standardise on any particular
> solution yet.  g-p-m is one way of cracking the power management egg and
> I think there are a lot of better possibilities.

Sure, but non that are even close to be ready for a GNOME release.

> Certainly, at the current time, it appears to be the best offering.
> However, after discussing this at length at Ubuntu Below Zero, I
> believe, that we'd be better served by a system with the two following
> key properties:
> 
> 1. Based on system daemon.
>   This would make the system more secure as a normal user process
>   wouldn't be given the ability to 'suspend now' as g-p-m (and 
>   any system which makes policy decisions at user privilege) currently
>   requires we provide it with.

I know a few ppl know the details already, but for those that do not:
policy is left to the FDI files in HAL, where you can specify certain
users, groups, or even just leave it as "console users" who are
physically logged in (default).

>   This (and other privileges that g-p-m
>   need to be provided with) have serious security implications.
>   Having a system daemon would also mean that the policy system runs
>   when the user is not logged in without resorting to hacks like gdm
>   invoking a private copy of g-p-m.

David Zeuthen put a lot of information in his blog
[ http://blog.fubar.dk/?p=63 ] of a way of doing this properly with
DBUS. I expect g-p-m and gnome-screensaver can use this framework when
complete.

> 2. More platform-neutral approach.
>   The technologies on which g-p-m is based have seen wide acceptance
>   from other desktops.  We should try and create a power management
>   system that has the same acceptance.  g-p-m is very Gnome-centric.
>   With a faceless system daemon doing all the real hard work we could
>   have multiple configuration front-ends (Gnome, Qt, etc).

g-p-m is the little cherry on top of the cake that is HAL, from where it
gets it's information, and then uses for methods to actually do stuff
like SetLCDBrightness() and Suspend() -- there's no reason the KDE p-m
session framework (which already exists) couldn't be modified
(simplified?) to use the information from HAL, and do policy using HAL.

> Of course, this wonderful system does not exist.  Again,
> gnome-power-manager is the best offering we have at this time.

Thanks! Making g-p-m very closely tied to other GNOME stuff allows it
and other programs to play nice, e.g. g-p-m telling g-s to lock the
screen after hibernating, all via a nice DBUS interface. g-s can also
use g-p-m to blank the screen using DPMS.

> This does not mean, however, that we should put include it in Gnome
> proper.  Once things are in, they have a tendency to stay around
> forever.  Applications form hard dependencies on them.  If we are going
> to standardise on a solution it should be the best possible solution --
> not just the best thing that we have right now.  If we aren't sure that
> the thing we have now is the best possible solution then it's
> appropriate to wait.

That's up to you guys, I would *love* to support g-p-m in a proper
release, but equally would continue to do so if just an external
program.

> Another issue is that right now some distributions are using power
> management systems that are vastly different from how g-p-m works.  If
> we include g-p-m we are encouraging people to depend on it and making
> life difficult for those distributions that do not want to ship it.

Sure, but those distros can just plug into the scripts provided by HAL,
SetLowPowermode(), Hibernate(), etc so that there is a common solution
between distros and desktops. At the moment one call to Hibernate() on
the HAL pm interface will use:

Redhat	pm-utils
SuSe	PowerSave
Ubuntu	pmi

but which also supports suspend2, and kernel suspend-to-disk by default,
for distros that do not have their own scripts.

This is how g-p-m stays so clean of architecture bodges and distro
specific hacks, because HAL abstracts the detail.

> Essentially, I think that (a) we should not rush into this and (b) we
> should, at the current time, leave this up to distributions to decide.
> We do them no harm by not including it since they can include it anyway.
> I'm not subscribed to the list so please cc: me on any replies.

Sure thing.

When would we know if the proposed modules get accepted? I want to know
whether the next release of g-p-m should be 0.3.5, or 2.13.x

Thanks,

Richard.
(g-p-m author)