Re: gnome 3

[Sam Thursfield <ssssam gmail com>]

On Sun, Apr 17, 2011 at 4:15 AM, Nirbheek Chauhan <nirbheek gentoo org> wrote:
> On Sun, Apr 17, 2011 at 3:41 AM, Josselin Mouette <joss debian org> wrote:
>> Le jeudi 14 avril 2011 à 05:17 -0400, Jasper St. Pierre a écrit :
>>> Other people want it because suspend doesn't work on their hardware.
>>> Adding a configuration option is just putting wallpaper over the
>>> cracked wall; the real solution is to fix suspend.
>>
>> I’m sorry but I don’t buy this. Suspend is among the things that have
>> always been broken, mostly because of broken BIOSes. As long as we don’t
>> have control over the hardware, we can’t be sure it works.
>>
>
> You're absolutely right. This is precisely the reason why Apple is
> able to ship quality OSes that boot fast, work as expected, and give
> excellent performance (iOS and OS X). OTOH, my own machine has a
> partially-working suspend because the media keys stop working on
> resume[1].
>
> This is why I think GNOME should start a marketing campaign of
> "Awesome Hardware" which is known to work flawlessly, and "Sadface
> Hardware" which is known to work, but with glitches. This can help
> users make informed choices while buying machines (or building them),
> and would help us improve hardware support for Linux as well. In most
> cases, it's just the last 1% that's left.
>
> This is quite similar to the wireless hardware whitelists/blacklists
> that we've been using for a while.
>
>>> And in the meantime, the wallpaper should be to detect suspend works
>>> as intended, and do something else if you can't.
>>
>> How can it detect that? There are just way too many ways it can fail.
>> Some machines will suspend but never resume. Some will resume but in a
>> wrong state. At that moment it’s too late to detect that suspend doesn’t
>> work. (And if you are talking about a whitelist/blacklist, then think of
>> its maintenance too.)
>>
>> Even worse than the “suspend on lid close” behavior, is the idea to
>> suspend instead of shutting down. Computers are not all laptops, some of
>> them require to be unplugged sometimes. Laptops are not all used
>> everyday; they do not last more than 2 days in suspend mode.
>
> I honestly think that the solution to this problem is suspend-hybrid
> support[2]. Write hibernate image to swap, then turn off disk and
> suspend to ram. That way if you pull the plug or the laptop battery
> dies, the machine just resumes on boot, and you don't lost any of your
> work. This is precisely what Apple already does.
>
>> Add to that
>> the need to reboot to install kernel updates.
>>
>
> I think this would be handled via PackageKit integration — you get
> prompted to reboot/relogin when an update is installed that needs such
> a thing.
>
>> You need to take into account that the vast majority of our users use
>> PC-class hardware. And you might not like it, but with such hardware
>> they need to learn the difference between reboot, shutdown and suspend.
>> It’s true that it should not be the case, but if you want to fix that
>> you should develop hardware, not software.
>
> As I said above, if we get suspend-hybrid support added to the kernel,
> computers that run directly off AC mains are covered as well.

I've been watching this discussion with increasing disappointment.
Suspend and hibernate are both hacks around the fact that power on and
power off take a long time and that our session manager doesn't save
session state.

Lots of progress is being made on system boot up time, it's improved
massively in the last few years in various distros and more cool stuff
is still to come. There are movements towards replacing the ancient PC
BIOS as well. And the next version of OSX contains "Resume" - which
saves the session between restarts.

Let's do our batteries a favour and concentrate on the real problems,
rather than creating an increasingly complex set of workarounds. The
correct use case for any electronic device is power on when using it,
power off when not.

Sam