Hi, The Wanderer: > Thus, having systemd provide power management would at best have no > effect, more likely increase the likelihood of power-management bugs > (and make documenting power-management behavior harder),
You're forgetting a few things here. * The idea is for all the legacy code to go away eventually, * There is no "worry". Either the DBUS interface is available or it is not. If it is, use it, otherwise fall back to legacy code. That's hardly rocket science. * If you don't like your system's power management, you can now roll your own. You get a stable interface to code for, not five desktop systems which each do their own internal API (if that). * One comprehensive implementation of power management is easier to debug than five of them. * Multi-user/seat. I'd like to keep my damn laptop closed but awake while I'm logged in via SSH. Without reconfiguring the damn DE, which I can't even do from an SSH login. Same for a desktop system which should go to idle mode only when _all_ of its screens are asleep. * If I want my program to block power management, I now have _one_ interface to do so – the desktop library I'm already developing for, which will forward my request to the system's power management. Thus, suddenly a KDE TV viewer can keep the system alive when someone runs it on an LXDE desktop. > The first would indicate wasted effort; the other two would be bad. > "Wasted effort" is/was to implement mostly-the-same power management features, in a slightly different way, in each desktop environment. -- -- Matthias Urlichs
signature.asc
Description: Digital signature
