[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management

This one time, at band camp, Tim Dijkstra said:
> Op Thu, 28 Sep 2006 00:00:28 +0100
> schreef Stephen Gran <sgran@debian.org>:
> > Not that I actually object to the package, but why can't HAL let acpid
> > manage acpi events?  I am continually confused by the profusion of
> > packages that offer to work around acpid in order to provide the
> > functionality it could and should be providing.
> Note that this package is not really related to acpid, but I'll try to
> answer anyway. Acpid is just another deamon listening
> to /proc/acpi/event. It doesn't have a good way of communicating with
> a user. 
> HAL is also able to listen to acpi events (by listening
> to /proc/acpi/event or acpid). 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).
> Now acpid has technically nothing to do with bringing the machine in a
> sleep state. For that to work you have basically three options: 
> 1) Patch your kernel with suspend2
> 2) Use swsusp build in kernel
> 3) Use uswsusp which is partly in kernel, partly user space.
> I think that with the profusion of packages you talk about are the
> packages (like pm-utils) the try to work around bugs in drivers and
> offer functionality before and after the actual sleep. Things like
> syncing the clock, stopping services, networks, fixing the state of
> the graphics card.
> I hope this clears it up a bit

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?  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.

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.
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |

Attachment: signature.asc
Description: Digital signature

Reply to: