unity-design team mailing list archive

[Alex Launi <alex.launi@xxxxxxxxx>]

On Tue, Jul 7, 2009 at 2:21 AM, David Siegel <david.siegel@xxxxxxxxxxxxx>wrote:

> Also, as there is no user state before login, we can reboot the machine
> without user confirmation. With fast-boot and KMS, we completely remove the
> pain from rebooting after updates -- in fact, the user probably won't even
> notice the reboot (we should suppress startup sounds on the reboot).
>
> David
>

I'm lovin it.


On Tue, Jul 7, 2009 at 5:30 AM, Dylan McCall <dylanmccall@xxxxxxxxx> wrote:

> Why is there an assumption that updates on shutdown would work like
> Windows, where it basically tricks the user by doing that as a default?


Whether or not it asks you, the idea is still flawed. Shutting off your
computer is an, "ok- I'm finished" activity. It's really not safe to walk
away during an update. David and Ivanka are working Friday evening, 18h
roles around and it's more than time to leave. They go to shut off their
workstations and now have to decide whether to stay longer and wait for the
upgrade to complete, or have to upgrade on Monday when they return (which if
it was at login would be perfect since they'd be tired from a long weekend
of binge drinking and could use the extra minute to get some coffee and
advil). If they leave without upgrading that's it- they leave but they
remain ungraded and that's the problem we're trying to solve, getting people
to actually upgrade. If they decide to upgrade they have two options, stay
and wait for it to complete, or leave and hope everything goes ok. If they
stay we've just given them a bad start to their weekend, if they leave it's
quite possible they could arrive Monday morning and have never actually
logged out because debconf was asking them a question and the upgrade STILL
isn't finished.


For the rebooting end of things... how well is GNOME's session saving
> working in 9.10? Perhaps the user's session after an update could be
> saved, so when the system reboots he gets something reasonably close to
> what he left. A hack to automatically log in could be interesting, too,
> although possibly a security disaster. (I'm no security expert, so maybe
> there's a good way to do it).


Even if their desktop is restored, you've still destroyed mental context,
and that's the hardest part to rebuild. It's easy to open a text editor, or
open office back up, the hard part is getting back to where you were
mentally.


On Tue, Jul 7, 2009 at 6:16 AM, Scott Kitterman <ubuntu@xxxxxxxxxxxxx>wrote:

> On the other hand, fast boot is an explicit Ubuntu design goal for a
> variety of reasons including users typically start their computers because
> they want to use them.


This is a similar case to fsck, it's not that often so it's not really a
huge deal wrt boot times.


On Tue, Jul 7, 2009 at 7:42 AM, mac_v <drkvi-a@xxxxxxxxx> wrote:

> ^+1 to Scott,
> The only problem with constant reboots is, the delay to get your work
> started, this leads to people not installing the updates at boot at all,
>  but rather later during the system use.


Constant meaning "once every long while". It's not like we have updates that
require reboot daily. Mmost people don't mind an extra 45 seconds to get
started if it means not being bothered once they're already going.


So is there a way to mark the packages which require reboot , and Not
> start them during the boot , but to update them and this would just
> *delay the boot by a few seconds during which the present icon is shown*
>

How are you going to not start the kernel?


This way the user never actually reboots .
>
> But, i guess ,this can be done better with updates at shutdown.
> With *updates at shutdown the user never has to actually reboot* . the
> word Reboot doesnt even have to be used!


Rebooting isn't a problem in and of itself, the interruption is the problem.
Updates during use can be very disruptive (in the reboot case especially)
and difficult to present in a way that actually encourages users to Update
(see the debate on notification icon, pop under, etc., etc.). Updates on
shutdown totally avoid the disruption if a reboot is needed, you're
absolutely right about this; however, they absolutely do not help the second
case. Windows is case in point. Windows desktop go notoriously unupgraded,
the upgrades on shutdown has been shown to *not work*. At all. Upgrade on
login however has not (to the best of my knowledge) ever been attempted. Is
this because it's a terrible idea? Maybe, but from the discussion on this
list I'm not inclined to think that's the case. It's just *new*, and new
things are scary. In the reboot case we minimize the disruption, granted we
don't eliminate it, but we take enough of the pain away that it's
effectively no longer an issue and also we have a much more prominent
display that updates are needed. Your full attention is now given to "Should
I upgrade", instead of having a pop under window or a notification tray icon
that you don't notice. I think people are likely to say yes when it's so
prominently displayed in the UI, and they're not already focused on
something else.


The only scenario which is against updates at shutdown is for laptops ,
> needing immediate shutdown.


And unfortunately for updates at shutdown, laptops are a huge primary use
case, probably more than desktops at this point. I know I haven't owned a
desktop for years, and neither have most of the people I know. Show of
hands, how many of you are on laptops right now? Desktops are a use case for
corporate environments, and I addressed that Scenario earlier- see my short
story about David and Ivanka's long weekend.


*So doing updates at shutdown and allowing option to instant shutdown*
> is more logical and user friendly.


QED, Ipso Facto, but not really.


-- 
-- Alex Launi