Op Thu, 28 Sep 2006 01:29:14 +0100 schreef Stephen Gran <[EMAIL PROTECTED]>:
> This one time, at band camp, Tim Dijkstra said: > > Op Thu, 28 Sep 2006 00:00:28 +0100 > > schreef Stephen Gran <[EMAIL PROTECTED]>: > > > > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]