Hi, On Sat, Feb 26, 2011 at 11:39 AM, Gendre Sebastien <[email protected]> wrote: > Le samedi 26 février 2011 à 09:02 +0100, Johannes Schmid a écrit : >> There is absolutely no information about why suspend is the default >> apart >> from telling that this is what happens when you close the lid on a >> laptop. >> I think you can argue that it might be a reasonable default for >> laptops >> but it is not at all a reasonable default for a desktop PC. And this >> is >> not discussed at all in the linked page. > > About suspend when close the lid, it's juste a change of logic. > > Before, you need to change yourself the parameter depending to the > situation. In some cases, you need to keep the laptop in activity (ex: > download files) when you close the lid. But in other cases, it's not > necessary. > > Instead of require a constant change of the parameter like before (in > Gnome 2.XX), Gnome 3 change it automatcaly. So, by default, Gnome 3 > suspend the laptop when you clode the lid and when a software should not > be stopped it interrupts the proceedings of standby. > > This solution has some advantages. Ex: You start a long transcoding of a > HD video and you want to go sleep. You just close the lid and go to bed. > The laptop don't go to standby and continue to transcode. When it > finish, it turn to standby.
This seems to be a very common misconception of how inhibit works. The reason I chose the word inhibit was to differentiate it from "block". Inhibiting suspend does not block suspend. An inhibit informs the system proactively of a certain condition. For example, inhibiting idleness doesn't mean the system won't honor an explicit user request to lock the screen (go idle). It informs the system that despite other indications of idleness (lack of mouse and keyboard activity), there is something still going on (say, watching a video). This information is used to inform automatic behaviors of the system. So, in this case, the screen won't lock or power off automatically while the inhibiting activity exists. Inhibiting automatic suspend works in a similar way. It doesn't block the human initiated request to suspend. It only informs the system that automatic suspend shouldn't occur for some specific reason. So, inhibit is closer to inform than mandate. And we respect humans more than apps. But the nice thing about apps is they don't have any feelings to hurt (yet). ... > And the choice to have Suspend but not Power Off in the User menu > encourages them to waste energy. I'm usually inclined to ignore claims like this that don't provide any supporting evidence. But since you're probably going to keep on saying it anyway... Encouraging the use of suspend will very likely result in a dramatic power savings for many people. If you only have the options: a) continue to run at full power b) stop everything you're doing, save all your work, close all your apps, lose all your state, wait for the system to power off; you have a problem. In this case, your selfish motivations are in opposition to low power consumption. That's not going to turn out well. And no amount of preaching will change that. What you need is something that doesn't have to make that trade. Maybe something that doesn't force me to abruptly and jarringly interrupt my activities and efficiently uses power at the same time. Do we have such a thing? It is also worth pointing out that you can't really measure waste in absolute terms anyway. Waste is subjective: it means to use carelessly or without value. I think it is pretty clear that, for many, there is value in suspending instead of stopping activities. So, we're spending a tiny tiny bit of energy here in the suspend case in order that we may save a tremendous amount of energy in others. That isn't waste - that is investment. We'll achieve even more impressive power savings when we enable suspend on system idleness. Which for portable systems will result in much improved battery run times. There's that win-win again. Jon _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
