G-P-M on the wrong track?!

[David Zeuthen]

Hi Matthias,

On Sun, 2005-10-16 at 12:26 +0200, Matthias Grimm wrote:
> Hi,
> Richard might not like to hear this but I think the G-P-M development
> is on the wrong track. It started with the aim to build a GUI for power
> management features. So far so good. But in the meantime it piles more
> and more power management functions and because it runs with user
> privileges and need someone to do the dirty work, clutters HAL with low
> level power management functions which it is not designed for.

"Dirty work"... Heh :-)

> 
> Continuing this path will cause a dilemma for the end user: He has to
> decide between a well working power management (for example on powerpc
> machines, see pbbuttons.sourceforge.net) and the gnome desktop, because
> G-P-M has the GUI he or she likes but the functionallity breaks all
> other power management concepts (daemons).

Slight confusion here - maybe it's because I work for a distributor
(though I think most people know that I'm not directly involved with
Fedora or RHEL work at the moment), but frankly if the user has to
*choose* between cryptic software like *pbbuttons*, *hal*, *gpm*, GNOME,
KDE or whatever you've already lost. 

Like it or not, but the days of "hey, let's configure my own L33t
distro" are gone as I see it. Assembling a Linux-based distribution is
difficult with all the features users require today - if you look around
you'll see a lot of small distros struggling to "get it right" and even
the larger players are having a hard time too.

I think that most people *seriously underestimate* the cost of adding
yet another system level daemon that has to communicate with other
daemons. It's just plain crazy. Especially when we have the framework in
HAL to have this is one place. 

If you didn't know, there's an IHV angle too; if I produce laptops I
don't need to go to 7 different open source projects to get my patches
in. I don't need to convince my e.g. top-3 distros to patch 7 different
packages. I don't need to deal with 7 different bug trackers. I need to
do only 1/7 of all that. Think about it.

> I would like to suggest a slightly change of project aims:
> 
> 1. HAL
> The HAL specifications tells that HAL provides a view and detailed
> metadata to attached hardware, not more. Not a word about building the
> mega-system-do-everything daemon.
> 
> Please return to this aim. Limit HAL's functionallity to collect data
> from various sources and provide it to the desktop for visualisation.
> According to the specification it is not HAL's task to actively control
> certain hardware or start scripts because of desktop programs wanted so.

The purpose of HAL is to abstract hardware and provide a simply, secure
and yet powerful API.

I believe we now have achieved both the "reporting about hardware and
fix up crappy hardware / crappy kernel-side support" goal as well as
having the groundwork for the things you are concerned about:
interacting with hardware. 

For the latter, we have a simple and extensible framework for adding
methods to device objects. And it's proven. We've been using this in
Fedora Rawhide (which has a significant amount of users) for some time -
I believe other distros too.

> 2. G-P-M (Desktop Part)
> The G-P-M project description on gnomefiles.org sais: "The main focus
> here is the user interface; e.g. allowing configuration of power
> management from the desktop in a sane way"
> 
> This is exactly what G-P-M on the Desktop should do. Visualize data
> provided by HAL and comunicate with a power management daemon through
> dbus, but don't perform any power management functions by itself.

You overestimate how complicated power management should be. Really,
look at the interface HAL provides

 Suspend()              # put the system into low power mode
 Hibernate()            # suspend to disk
 SetLowPowermode(bool)  # called when transitioning to/from AC

and that's it. Note also we have hooks for different distros to plug in
their implementation for they want to suspend. That's it. Maybe we'll
add some selective suspend features to specific devices at some point
but I doubt it. Maybe we'll add some methods to control laptop displays.
But that's about it.

Oh, we also report about hardware like special laptop buttons but I
assume that you are not unhappy about that. If you are, I'd be happy to
address your concerns.

Btw, it is my view that anything else related to power management should
be handled in-kernel, e.g. run time power-management (dynamically
adjusting power management of certain devices, e.g. suspend a USB
thumbdrive using USB PM).

> 3. The Power Management Daemon
> Power management is too critical to lay it in user's hands. It is an
> important system feature and must be handled by a system daemon running
> with high privileges. No desktop program is able to fulfil this task.

You seem to confuse two things here

 1. Selecting policy - that is the task of g-p-m, e.g. knowing when to
    put the system into suspend. g-p-m cooperates with e.g. the X server
    and e.g. gnome-screen-saver to decide this. Obviously you want to
    read the users settings too. Hence all this needs to run in the
    desktop session.

 2. Enforcing policy - actually doing the suspend. Here HAL simply
    dispatches e.g. the Suspend() method call to a (vendor provided)
    script and returns.

I cannot believe that this thread has gotten so big about something as
petty and trivial as HAL offering *three* method calls to applications
like g-p-m. What's the real issue here?

About the concerns that people have that HAL is growing into a
mega-daemon that does everything - well; the only thing I can say is
that we're not going to add stupid method calls for just anything - we
want to be careful about what to add.

    Best,
    David