On Thu, Dec 20, 2012 at 08:00:38PM +0100, Oliver Neukum wrote:

On Thursday 20 December 2012 19:52:12 Lars Müller wrote:

...

Hi,

a recent update to KDE made it impossible to the user to logout or to shutdown the system.

Therefore I suggest to change our default way how updates are applied.

a) Always download the updates in advance in the background

The user might be paying by the megabyte.

What's the difference if the required packaages for the particular system are downloaded in advance? The user sooner or later needs to download them nevertheless. If the goal is to ensure not to download while being on the road and not being connected to a broadband connection, then we need to catch this situation. Todays mobile phones apply updates only if the available network connection is good enough. But the current implementation leads to locked users. Last seen with openSUSE 12.2 and the recent KDE update.

...

We could even be more elegant and throttle the download speed if other processes use the same link.

b) Apply the updates on shutdown

This is a bit impractical if the patch fixes a security problem. Secondly shutdowns may be rare.

Nobody stops users from changing the default. And what's more impractical? A running X session you never can't terminate as I've seen it with a plain KDE as available with openSUSE 12.2 or a session you never can terminate on a regular way? How many non technical users out there know ctrl + alt + back space these days? As we have these nice notification systems we're able to inform the users about available updates and that these updates require to log off. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Thu, Dec 20, 2012 at 04:31:12PM -0300, Claudio Freire wrote:

On Thu, Dec 20, 2012 at 4:23 PM, Lars Müller <lmuelle@suse.com> wrote:

...

...

...

We could even be more elegant and throttle the download speed if other processes use the same link.

b) Apply the updates on shutdown

This is a bit impractical if the patch fixes a security problem. Secondly shutdowns may be rare.

Nobody stops users from changing the default.

And what's more impractical?

There's also the inconvenience of delaying shutdown considerably.

Nobody stops users from changing the default. But the current way lead to the trouble I described. Isn't that more painful? And till now the replies had been: we need to keep it how it is. But there is a bug. Claiming my suggestion doesn't work doesn't make the defect go away.

Imagine I'm running out of battery life, and the system starts applying updates?

Nobody stops us from checking the battery state too. If the system runs on battery we might skip applying updates. You know how the apply delta and apply update process works? We first apply the deltas. That's what would happen in the background process too. Then libzypp utilizes RPM and RPM first installs the new files and in a second step it removes the no longer needed files and cleans up the database. All what could happen is to have the same package installed two times in the database. But that could happen at the moment too. All I like to see is progress. The current approach leads to the described trouble. Please be this nice and reply with a suggestion how to address the described issue. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Am Donnerstag, 20. Dezember 2012, 16:31:12 schrieb Claudio Freire:

On Thu, Dec 20, 2012 at 4:23 PM, Lars Müller <lmuelle@suse.com> wrote:

...

...

...

We could even be more elegant and throttle the download speed if other processes use the same link.

b) Apply the updates on shutdown

This is a bit impractical if the patch fixes a security problem. Secondly shutdowns may be rare.

Nobody stops users from changing the default.

And what's more impractical?

There's also the inconvenience of delaying shutdown considerably.

Imagine I'm running out of battery life, and the system starts applying updates?

Suspend to disk. But anyway, I like the idea and your argument does not really defeat it. Simply add a checkbox or something like that to the logout/shutdown dialogue: "apply updates when logging out". If it is enabled by default users can disable it per usecase. Question is, if that checkbox is disabled should the updates be installed when starting-up or wait until the next logout? Also, what if people never shut down but simply hibernate. Whatever tool used, it must mediate that an update needs the logout. And since linux people are picky about their choices, it would have to offer to install them without logout as well. Apper can notify about "shutdown/logout needed" AFAIK, not sure about other update frontends. Yet currently it only does it after updates are applied not before. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Dec 20, 2012 at 09:17:21PM +0100, Sven Burmeister wrote:

Am Donnerstag, 20. Dezember 2012, 16:31:12 schrieb Claudio Freire:

...

On Thu, Dec 20, 2012 at 4:23 PM, Lars Müller <lmuelle@suse.com> wrote:

...

...

...

We could even be more elegant and throttle the download speed if other processes use the same link.

b) Apply the updates on shutdown

This is a bit impractical if the patch fixes a security problem. Secondly shutdowns may be rare.

Nobody stops users from changing the default.

And what's more impractical?

There's also the inconvenience of delaying shutdown considerably.

Imagine I'm running out of battery life, and the system starts applying updates?

Suspend to disk.

But anyway, I like the idea and your argument does not really defeat it.

Simply add a checkbox or something like that to the logout/shutdown dialogue: "apply updates when logging out". If it is enabled by default users can disable it per usecase.

We need to make this simple to use. Maybe we even offer a additional checkbox: [ ] don't ask me again

Question is, if that checkbox is disabled should the updates be installed when starting-up or wait until the next logout?

Applying the updates on startup might annoy users too. Even this should be possible to select. But having a huge matrix with all these options might lead to a useabilty nightmare. Here a User/ Useability Interface expert needs to speak up.

Also, what if people never shut down but simply hibernate. Whatever tool used, it must mediate that an update needs the logout. And since linux people are picky about their choices, it would have to offer to install them without logout as well. Apper can notify about "shutdown/logout needed" AFAIK, not sure about other update frontends. Yet currently it only does it after updates are applied not before.

It must be possible to decide once: I know what I do please get out of my way. In that case we never ask back again and never do anything. If the admin doesn't trigger to apply updates via YaST or zypper. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

El 21/12/12 17:36, Claudio Freire escribió:

Updates should never be compulsory, that's my opinion, but even when done compulsory (which is sometimes useful for non-tech-savvy users since they don't really know when it's best to do them), when it is, it shouldn't be getting in the way of the user's tasks. In this case, shut down, or startup.

IMHO in the "desktop user scenario" security updates of software that is running should be compulsory, particulary those that are used interactively like web browsers/email clients -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2012-12-20 a las 20:23 +0100, Lars Müller escribió:

...

...

a) Always download the updates in advance in the background

The user might be paying by the megabyte.

What's the difference if the required packaages for the particular system are downloaded in advance?

The user sooner or later needs to download them nevertheless.

I think that the idea is never download without asking root.

If the goal is to ensure not to download while being on the road and not being connected to a broadband connection, then we need to catch this situation.

Currently, even considering if there are updates available is prohitive for me while on the road, repo metadata update is too heavy. I can not allow things like apper to run automatically. When I can, I run YOU or sw-single as needed.

A running X session you never can't terminate as I've seen it with a plain KDE as available with openSUSE 12.2 or a session you never can terminate on a regular way?

Kill it, not a problem :-) No, I understand you. I consider updates to the desktop or X dangerous while running a session. I can do them in text mode at my wish, but that's not something most people will do. I think that desktop updates should be applied when the user logs out, and yast should tell the user in advance that this is going to happen before the user allows the update, so that he can decide the best moment. Probably X updates should do the same thing. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlDTebsACgkQja8UbcUWM1wuGwEAgkNr4k6aB2ZIDKuaOtNfz7BG M4wmWzvv3YCXoAMzw8IA/i1yjjab8kpZSjvXQp7r+nOi3487s97gC6nEJNO+3sAb =wwVR -----END PGP SIGNATURE-----

В Thu, 20 Dec 2012 21:20:53 +0100 Guido Berhoerster <gber@opensuse.org> пишет:

* Lars Müller <lmuelle@suse.com> [2012-12-20 19:52]:

...

Hi,

a recent update to KDE made it impossible to the user to logout or to shutdown the system.

Therefore I suggest to change our default way how updates are applied.

a) Always download the updates in advance in the background

We could even be more elegant and throttle the download speed if other processes use the same link.

b) Apply the updates on shutdown

Doing b) after the user finished the X sesison ensures we never lock her in.

Via a new setting is a /etc/sysconfig/ file we're able to change the default. For example to apply updates always at system startup or to keep the update process at the same way as it currently is.

Maybe we're already able to achieve this and I missed the configuration option. But our current default settings lead to the described desktop lock situation.

Please no, lets not copy this awful design from Windows/OSX. Rather get some inspiration from beadm and utilize snapper to create a snapshot of the system fs, mount and chroot into it, apply the updates, and finally make it the default to boot into on the next reboot. That not only avoids the downsides such as annoyingly long shutdown times for desktop users or long downtimes for servers but it has also the advantage that it makes updates safe. If something goes wrong during the update no harm is done and if the updated boot environment does not boot or is broken you can simply reboot into the pre-update environment. Of course that'd require a fs with writable snapshots like btrfs and would put some constraints on the fs layout but since this can remain an optional feature that should not be a problem.

Sun did this for years with Alternate Boot Environment, long before ZFS was invented (or at least made available). There is no need to have fancy filesystems for it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2012-12-21 a las 06:59 +0400, Andrey Borzenkov escribió:

Sun did this for years with Alternate Boot Environment, long before ZFS was invented (or at least made available). There is no need to have fancy filesystems for it.

And ATT/Lucent did it too, on the 5ESS. No fancy filesystem there, the design is old. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlDUT28ACgkQja8UbcUWM1xtrwD+Mvq2gWkcEWwZnR7NVmkycbNz qEzAoXksuJx+MMjFujQBAIk2Ydn1EcMF+Bpw60xrW2HVPx270GNhjMjOyKQap+uy =ScwX -----END PGP SIGNATURE-----

* Lars Müller <lmuelle@suse.com> [2012-12-21 19:29]:

On Thu, Dec 20, 2012 at 09:20:53PM +0100, Guido Berhoerster wrote:

...

* Lars Müller <lmuelle@suse.com> [2012-12-20 19:52]:

...

a recent update to KDE made it impossible to the user to logout or to shutdown the system.

Therefore I suggest to change our default way how updates are applied.

a) Always download the updates in advance in the background

We could even be more elegant and throttle the download speed if other processes use the same link.

b) Apply the updates on shutdown

Doing b) after the user finished the X sesison ensures we never lock her in.

Via a new setting is a /etc/sysconfig/ file we're able to change the default. For example to apply updates always at system startup or to keep the update process at the same way as it currently is.

Maybe we're already able to achieve this and I missed the configuration option. But our current default settings lead to the described desktop lock situation.

Please no, lets not copy this awful design from Windows/OSX.

With intention I didn't wrote: others are able to keep it simple and stupid and made this work since ages.

Please make a better and as simple suggestion to circumvent the described issue.

I disagree, what I suggested is both a conceptually simple and proven solution e.g. on Solaris 11 (as others have pointed out again) and simple to implement since most of the bits and pieces for it already exist and just need to be connected for a solution.

We already have the multiversion feature you must enable by hand in /etc/zypp/zypp.conf for the kernel and then you still need multiversion.kernels = latest,latest-1,running and grub2 to get a simple and more reliable setup without much extra cost.

That is not comparable, we are talking about a snapshot of the complete system not just a kernel, there is a multitude of things that can make a system unbootable.

Something like this is easy to use and understandable by our userbase.

I am sure our userbase is able to handle that and to the contrary that it will make things easier. It would probably not even be noticed by most people who just apply the updates and reboot. However, if something goes wrong there's a much easier path to recovery than we have now. And it also provides benefits to server users.

...

Rather get some inspiration from beadm and utilize snapper to create a snapshot of the system fs, mount and chroot into it, apply the updates, and finally make it the default to boot into on the next reboot.

btrfs is nice to have. But I don't like to push btrfs as mandatory.

btrfs isn't the only way though probably the most performant and straightforward way to implement this. Given that it is supposed to replace ext4 as the default fs I don't find it unreasonable to require it if one want to use this functionality. But AFAICS it might also be possible to make use of the new device mapper thin-provisioning which is independent of the used fs or simply reserve a sparse partition/LV although the latter would be rather inefficient.

...

That not only avoids the downsides such as annoyingly long shutdown times for desktop users or long downtimes for servers but it has also the advantage that it makes updates safe. If something goes wrong during the update no harm is done and if the updated boot environment does not boot or is broken you can simply reboot into the pre-update environment. Of course that'd require a fs with writable snapshots like btrfs and would put some constraints on the fs layout but since this can remain an optional feature that should not be a problem.

The feature I suggested isn't optional.

Well it should be the default but not mandatory for people who know what they're doing, I surely don't want shutdown/reboots to take minutes. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org