This one time, at band camp, Tim Dijkstra said: > Op Thu, 28 Sep 2006 00:00:28 +0100 > schreef Stephen Gran <[EMAIL PROTECTED]>: > > > 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 | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
