Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Op Thu, 28 Sep 2006 01:29:14 +0100
schreef Stephen Gran <sgran@debian.org>:
> This one time, at band camp, Tim Dijkstra said:
> > Op Thu, 28 Sep 2006 00:00:28 +0100
> > schreef Stephen Gran <sgran@debian.org>:
> >
> > The advantage HAL has over acpid, is
> > that it is very well integrated in to the users (kde or gnome)
> > session. That way it is able to notify the user (he, your battery
> > is low!) get user feedback (should I suspend to ram, to disk?) and
> > act on user configuration (suspend to ram when closing the lid, but
> > only when on AC, else suspend to disk).
> >
>
> Only a little. Perhaps I am just of the old skool 'do one job and do
> it well' mind set, but all of those events appear to be acpi events
> which acpid handles rather well, even in the brave new world of single
> user linux on laptops that Ubuntu and others have brought us. You do
> know that acpid can run arbitrary scripts on acpi events, like say,
> lid close, right?
Yes of course. But acpid does next to nothing by default. HAL is
more of a 'should-just-work' approach. Also what I wanted to stress; HAL
is trying to fit in the brave new world of systems (lots of desktops
have acpi, can suspend, etc) where the user at the active X-session
should be able to influence what happens at these events -on the fly-.
I'm also more of an old skool guy, but I also have several people
using the machines I administer who are not. Also, I must confess,
it's nice to click on some icon to temporally disable suspend (because
of idle time) because I'm watching a movie.
> I understand that this package is no different than
> a dozen others, in that it tries to provide policy layers and cute
> gui things on top of acpid, but it just seems like too many layers of
> abstraction and replicated code bases to me.
HAL does not need acpid, it will listen to acpi events just fine
without.
HAL, dbus, etc are already installed on a modern desktop (both kde and
gnome), they already define that policy layer. So why not take
advantage of that?
> But, as I say, whatever, one more won't hurt. I just feel a little
> perturbed when I see some new project that needs HAL, dbus, and a half
> dozen other things to handle something that can already be handled
> with shell scripts and a very small daemon.
Note that all discussion above is about HAL, not pm-utils. HAL will
depend on pm-utils, not the other way around. And what pm-utils means
to bring is a consistent interface and a should-just-work experience for
bringing the machine a sleep state, not listen to acpi events. Heck,
you could even use pm-utils in combination with acpid.
(Funny, I'm arguing in favour of pm-utils, here while I've just been
expressing my reservations on the hal-list against it...;)
grts Tim
Reply to: