l.lunak at suse.cz
Fri Mar 30 15:34:32 PDT 2007
On pá 30. března 2007, Brian J. Tarricone wrote:
> On Fri, 30 Mar 2007 23:19:26 +0200 Lubos Lunak wrote:
> > I thought supporting an opinion did not require one to repeat it, but
> > if you
> >want: Shutdown/Reboot are basic functionality but power management
> >features are an add-on that not everybody may be interested in having
> >(see above for my feedback on that part). Since a DBUS interface
> >cannot be split that makes the whole org.fd.PM interface optional and
> >therefore Shutdown/Reboot should not be part of it.
> There's nothing stopping someone from implementing a daemon that
> handles org.fd.PM and only supports the Shutdown/Reboot methods. For
> the CanStandby/CanSuspend/CanHibernate methods, just return FALSE. For
> the Standby/Suspend/Hibernate methods, return the NoHardwareSupport
> error. For GetPowerSaveStatus and GetBatteryState, return FALSE. If
> other methods are added, I'm sure dummy non-implementations can be
> added for people who really care about saving 200k of RAM.
Or, since the two things are[*] independent, they can have independent
interfaces and supporting either only one of them or both of them is simple.
No dummies needed.
[*] Unless you have another reason why shutdown/reboot should go together with
PM besides the Inhibit functionality, which for shutdown/reboot exists in the
form of session management.
(In fact, thinking of it right now, perhaps even having Inhibit in PM
interface is not quite right? A DVD burner app strictly speaking probably
doesn't care about the machine being suspended, it just wants to keep the DVD
device until it's finished and the machine shouldn't shutdown with the DVD
device being busy - so in fact maybe it should be HAL preventing suspend in
such case. You can have Inhibit for the screen, which is a bit like keeping
the screen, but that has nothing to do with shutdown/reboot again. But maybe
this is overengineering it already and irrelevant to the 'should
shutdown/reboot be part of PM' topic anyway.)
> At any rate, you're complaining about a specific implementation being a
> memory hog. Take your beef to the authors of that software. The
> org.fd.PM interface is mostly orthogonal.
> Of course, the ridiculously ornery among us can just open a terminal
> and type 'sudo poweroff'; they won't even run g-p-m or kpowersave or
> whatever, and any apps they run won't be able to make use of the
> advanced features org.fd.PM can offer. Your average user who would
> benefit from org.fd.PM features won't care about a meg or two of RAM
> gone missing.
This is not about g-p-m being a memory hog or not, this is about the
principle. Everything has its cost and you want to make a power management
daemon compulsory even just for shutdown. Okay. Next week somebody proposes a
WIFI access daemon should be made compulsory for some reason, because, after
all, your average user will benefit from it and who cares about a meg or two.
Actually two or four, by now, things add up. Do I need to continue to the
next month and later and add up more? I'd prefer not to, I feel strongly
tempted to point out some flamewar material. Let's just say that there are
users who also care about this, ok?
Besides, the main reason is that having shutdown/reboot seen as a part of
power management functionality simply seems technically wrong.
SUSE LINUX, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12 tel: +420 284 028 972
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http//www.suse.cz
More information about the xdg