Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Package: wnpp Severity: wishlist Owner: "Tim Dijkstra" <[EMAIL PROTECTED]> * Package name: pm-utils Version : 0.0.1 Upstream Author : Bill Nottingham <[EMAIL PROTECTED]>, Peter Jones <[EMAIL PROTECTED]>, David Zeuthen <[EMAIL PROTECTED]>, Richard Hughes <[EMAIL PROTECTED]> * URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/ * License : GPL Programming Lang: C, Shell Description : utilities and scripts usefull for power management Provides simple shell command line tools to suspend and hibernate computer that can be used to run vendor or distro supplied scripts on suspend and resume. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote: > Provides simple shell command line tools to suspend and hibernate > computer that can be used to run vendor or distro supplied scripts > on suspend and resume. This is something like the fifth package in Debian that attempts to do this. What sets is apart from the ones already in Debian? Do we really need another one? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Op Wed, 27 Sep 2006 23:41:01 +0200 schreef "Steinar H. Gunderson" <[EMAIL PROTECTED]>: > On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote: > > Provides simple shell command line tools to suspend and hibernate > > computer that can be used to run vendor or distro supplied scripts > > on suspend and resume. > > This is something like the fifth package in Debian that attempts to > do this. What sets is apart from the ones already in Debian? Do we > really need another one? This will make all others obsolete;) More seriously, this will be a dependency of HAL and with that of the whole gnome power management stack. So I think we can't go around it in the future. I wanted to package it to make sure it plays nice with uswsusp (another package I maintain). grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
This one time, at band camp, Tim Dijkstra said: > Op Wed, 27 Sep 2006 23:41:01 +0200 > schreef "Steinar H. Gunderson" <[EMAIL PROTECTED]>: > > > On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote: > > > Provides simple shell command line tools to suspend and hibernate > > > computer that can be used to run vendor or distro supplied scripts > > > on suspend and resume. > > > > This is something like the fifth package in Debian that attempts to > > do this. What sets is apart from the ones already in Debian? Do we > > really need another one? > > This will make all others obsolete;) > > More seriously, this will be a dependency of HAL and with that of the > whole gnome power management stack. So I think we can't go around it in > the future. I wanted to package it to make sure it plays nice with > uswsusp (another package I maintain). 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. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
On Wed, Sep 27, 2006 at 11:41:01PM +0200, Steinar H. Gunderson wrote: > On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote: > > Provides simple shell command line tools to suspend and hibernate > > computer that can be used to run vendor or distro supplied scripts > > on suspend and resume. > > This is something like the fifth package in Debian that attempts to do this. > What sets is apart from the ones already in Debian? Do we really need another > one? * Upstream Author : Bill Nottingham <[EMAIL PROTECTED]>, Peter Jones <[EMAIL PROTECTED]>, David Zeuthen <[EMAIL PROTECTED]>, Richard Hughes <[EMAIL PROTECTED]> * URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/ I think this is the one to rule them all. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
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 grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
Op Thu, 28 Sep 2006 01:04:40 +0200 schreef Michael Banck <[EMAIL PROTECTED]>: > On Wed, Sep 27, 2006 at 11:41:01PM +0200, Steinar H. Gunderson wrote: > > On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote: > > > Provides simple shell command line tools to suspend and hibernate > > > computer that can be used to run vendor or distro supplied scripts > > > on suspend and resume. > > > > This is something like the fifth package in Debian that attempts to > > do this. What sets is apart from the ones already in Debian? Do we > > really need another one? > > * Upstream Author : Bill Nottingham <[EMAIL PROTECTED]>, Peter Jones > <[EMAIL PROTECTED]>, David Zeuthen <[EMAIL PROTECTED]>, Richard Hughes > <[EMAIL PROTECTED]> > * URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/ > > I think this is the one to rule them all. Are you being cynical or serious? grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 <[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
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 <[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]
