El mar, 21-09-2004 a las 23:19 +0800, Davyd Madeley escribió: > On Tue, 2004-09-21 at 10:58 -0400, Sean Middleditch wrote: > > On Tue, 2004-09-21 at 16:52 +0200, Carlos Garcia Campos wrote: > > > > On Maw, 2004-09-21 at 14:12, Davyd Madeley wrote: > > > > > > You want more than monitor - a lot of the systems can set policies so > > > > you want policy selector. These tend to include "performance", "maximum > > > > battery life" and the like. Sometimes you need to switch at runtime (eg > > > > when playing bzflag) to avoid the CPU speed change messing with your > > > > game. > > > > > > For to set a policy is necessary to be root and in a common case an > > > applet is not running as root. I think it can be solved by using an > > > external program as a policy selector. It will prompt for root password, > > > like the clock applet does calling to gst to set the time. The problem > > > is that it could be an annoying process for a so simple task. > > > > A laptop system will likely be configured for this to not be the case. > > If I handed out a laptop running Linux to employees here, I'd definitely > > do that. Laptops are usually single-user systems and it's not like > > adjusting the policy is going to severely damage anything. (Assuming > > the available policies _are_ locked down.) > > > > The applet could provide a menu of the policy options. When one is > > clicked, an external tool is run to do the actual change. This tool > > can, on systems that are designed that actually care about ease-of-use, > > use something like console-helper - it'll either just do its job without > > any complaint (and the applet will be updated to reflect the new > > policy), or it'll popup the authentication dialog to pester users about > > the root password. (or the user password, or whatever policy the admin > > has configured.) > > Someone has written a CPU Freq applet thing to do this called Emifreq. > > http://zzrough.free.fr/emifreq.php > > I haven't had time to have a look at it besides what the screenshots > show. Or pit it against the applet that Carlos wrote (which has always > been quite sturdy). However, I think it covers what you're talking > about. I don't know if using a daemon running as root is the best solution. IMHO a better solution could be to use a command line tool to set the policy. In a single user system the user could choice to set the SUID bit for the command line tool or not. If the applet haven't got permission to exec the command line tool, it could prompt for root password (for example by using gksu or writing its own authentication system). I think it's not necessary to have a process running all the time. If you like the idea I can write the command line tool. > --d Greetings, -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carlos Garcia Campos a.k.a. KaL elkalmail yahoo es carlosgc gnome org http://carlosgc.linups.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente