Announcement: Common Power-Management Framework
Greetings -devel, It is my pleasure to announce the creation of a project to create a common power-management framework[1] for Debian (and eventually, the world). This idea, in various forms, has been discussed several times in the past[2][3] with a generally positive response. These ideas have even been implemented, to some extent, in the laptop-mode-tools and pbbuttonsd packages. Now we finally have enough interest and coordination to make some real progress in putting together a coherent solution that can provide a valuable service to Debian. Fundamentally, our goal is to create an architecture-independent, power-system-independent, and power-daemon-independent system to handle power-related events (e.g. lid close, battery events). This will likely happen by hooks from the power daemons (scripts in their event handlers) that will invoke a common event handler. This common handler will run its system-independent scripts (possibly in the style of a runlevel) based on its configuration, then return control to the daemon to complete its handling. Now to the big question... Why? At first glance, this may seem like just another level of cruft to unnecessarily complicate a system that currently works just fine. Quite to the contrary, the design goals of the common power-management framework is to simplify the system and provide many useful features to developers, administrators, and users. There should be no need to modify anything in the daemon's event handler for all but the most daemon-specific contexts. In fact, it has been suggested (although it is probably a pipe dream at this point) that the common event handler could completely replace the script interface of the existing power daemons. Some of the benefits of this system: Developers will be able to respond to power-related events, regardless of architecture, daemon, and OS by installing a single script for the common event handler.[5] This script will be properly handled even as new power-systems and daemons are created with no necessary changes from the developer. Administrators will be able to easily share configurations between computers with different power systems and operating systems, and easily upgrade from one power system to another. Users will be able to choose from several standard actions for power events during install and to easily change/customize these actions.[6] We have not yet finalized any of the design decisions, and invite anyone interested in the specifics to join the conversation on the powermgmt-devel mailing list.[4] On behalf of the Common Power-Management Framework team, Kevin 1. http://powermgmt.alioth.debian.org/ 2. http://lists.debian.org/debian-devel/2004/08/msg01307.html 3. http://lists.debian.org/debian-powerpc/2004/04/msg00455.html 4. http://lists.alioth.debian.org/mailman/listinfo/powermgmt-devel 5. It has also been suggested to provide DBUS messages on power-related events and status that programs could respond to/query. Also, inclusion/creation of command line tools for querying power status is being considered. 6. This will probably be implemented using a -scripts package that will install scripts to run based on debconf questions during installation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
On Fri, 2005-12-02 at 10:47 +, Matthew Garrett wrote: > Kevin Locke <[EMAIL PROTECTED]> wrote: > > > Fundamentally, our goal is to create an architecture-independent, > > power-system-independent, and power-daemon-independent system to handle > > power-related events (e.g. lid close, battery events). This will likely > > happen by hooks from the power daemons (scripts in their event handlers) > > that will invoke a common event handler. This common handler will run > > its system-independent scripts (possibly in the style of a runlevel) > > based on its configuration, then return control to the daemon to > > complete its handling. > > To a large extent, this sort of work is currently being done in HAL. Is > there any need to create another level of abstraction, or should we just > work on that? Interesting. I wasn't aware to what extent HAL is able to notify programs about power-related events. In fact, we had briefly discussed receiving events from HAL in addition to the power-daemons. Perhaps with some work, we would be able to rely completely on HAL. The common power-management framework is really intended to be a policy layer, so it may still have some value for running scripts based on power events (it could fill the roll of the "small daemon" you talk about in your second mail to this thread). However, I realize that the GNOME Power Manager[1], and likely a KDE equivalent, already handles several of the tasks normally associated with power-management, so perhaps there is no need for another program to be handling events. What are your (or anyone else's) thoughts about the value of a daemon to invoke scripts based on the power-related HAL events? Is this unnecessary given the function of the GNOME Power Manager and equivalents, or would it have enough value to be worth implementing? Would it be better to spend our time adding features to the Gnome Power Manager and equivalents instead of creating a separate program? I'm sure we will be discussing this extensively on the powermgmt-devel list in the near future, but I would like to hear what the -devel community thinks of this idea (it's too easy to justify ones own work in ones own mind). > It also sounds (though I'm not certain) like you're > concentrating on system-wide power management transitions, whereas I'd > argue that it needs to be possible for configuration to be done on a > per-user basis (you wouldn't believe the degree of argument over whether > closing the lid of a laptop should trigger a suspend or not) You are correct that we had been talking about this from a system-wide perspective. Per-user is a nice idea, it would be great for each user to be able to configure their own preferences for what actions are taken. We will probably need to address the issues of no users logged in and users with differing actions (where one would want to suspend and the other to ignore the event). But that should be doable. Cheers, Kevin 1. http://www.gnome.org/projects/gnome-power-manager/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Fri, 2006-11-17 at 18:08 +0200, Jari Aalto wrote: > I'm sure someone can rephrase the above better, my idea being: > > - /bin/dash is the measure (the minimum) > > - It is encouraged that maintainers accept patches and seek ways to > generalize scripts (= pay attention to lintian warnings) > even further so that they are not restricted to even > /bin/dash alone. It is preferred that scrpts could also work with > /bin/posh /bin/pdksh /bin/mksh etc. as well, if this does not require > overly complex constructs in the programs. Forgive me if I am wrong, but I was under the impression that posh was created for the purpose of providing a shell which supports a minimum of functionality required by policy against which scripts could be tested. If providing such a shell as a measure is the way to go, would it not make sense to modify posh in the respects that it does not represent policy?[1] -- Cheers, | [EMAIL PROTECTED] |[EMAIL PROTECTED] Kevin| http://kevinlocke.name | kevinoid on freenode 1. Of course, if the policy decision is to list supported shells this becomes somewhat less meaningful... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
On Sat, 2007-08-04 at 19:17 +0200, Sam Hocevar wrote: > http://wiki.debian.org/Proposals/CopyrightFormat > >I therefore would like your opinions about this proposal, its > shortcomings, and a strategy to implement it quickly and as widely as > possible. This is great! One possible shortcoming might be the lack of information provided for less widely used licenses (anything requiring an 'other' value in the License field). How much Debian should be concerned about such licenses is no doubt up to debate, but especially in non-free there are likely many such cases. One possible solution that I have in mind would be to add information about the terms of the license in a machine-readable way. Perhaps something along the lines of what Creative Commons has done with mod_cc[1], but with several additions that suit Debian's (and Debian's users) requirements. I am imagining another field something like License-Terms: Requires-Attribution, Noncommercial, Choice-of-Venue, SSL-Exception, GPL-Compatible Clearly the exact terms and their meaning would require a bit of discussion, but should ideally include tags which would be as unambiguous as possible and would cover as many of the properties of licenses as we can that are important to Debian end-users, without making the License-Terms field longer than the license itself... Of course, this idea does have several limitations: * It is not particularly useful for well known licenses. Perhaps for any license besides "other", these values could be inferred? * There will be both mistakes and misinterpretations of these terms, regardless of how well defined they can be made in proposals. Mistakes happen. Does this pose a legal problem for Debian if individuals act based on the tags and are later held liable for license violations? * There will no doubt be different interpretations of whether or not a license deserves a particular tag (as there are now about whether or not a license meets the DFSG). Who will be ultimately responsible for the tags, and is that influenced by the previous point about potential liability? * This is not a replacement for people actually reading the licenses of the software they are installing. The tags can not cover every possible facet of a software license and any license-conscious end-user (individual or corporate) will still need to read the licenses of their software to make sure they are in compliance with its terms. That said, I hope that this does provide meaningful benefit. The primary benefit that I envision is to eventually allow users to select which license terms they find acceptable and which they do not and to limit their package installations on that basis. As mentioned above, this is not a complete solution, since the licenses must still be read in full, but it would cut down on the amount of packages which require consideration. For example, corporate users may select a policy which would not consider packages tagged Noncommercial, allowing their license review teams to only look at packages which may be usable by their company. It could also allow users with their own particular definitions of freeness to easily select packages that fit their desires. Thoughts, comments, and criticisms welcome. Cheers, Kevin 1. http://web.resource.org/rss/1.0/modules/cc/ P.S. By making this suggestion, I am volunteering to help with the huge amount of work that it requires. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
