While I don’t like the idea of having updates turned off, I think the (loud) message we’re receiving from outside our community is that the ability is a big issue for people to even consider using snaps. Therefore, even though we don’t like it, I believe that it is in the platform’s best interests to provide the knobs to let the user decide. This will improve the perception of the project and it’s direction along with getting more people to consider giving it a try.
17 Likes
To avoid a scenario where a user disabled updates and forgot about it, I think when people put any or all app updates on hold, the UI should show this as an “insecure” state. Ideally the update manager should remind the users about this insecure state every time it runs.
5 Likes
I kinda threw the “turn off all updates” in there knowing there’d be pushback. There’s a ton of other things in my strawman argument we could also look at 
I too worry that if we make it easy to disable fully the update process it’ll get left switched to that state. Some, yes, will want that.
1 Like
I personally think there should not be an option to turn off all updates, but I do think the current “tools” a user has to control updates are not well adapted to desktop users. The current tools seem mostly fitted to server and iot use-cases where updates are managed/configured by an admin.
The concerns a desktop user has are things like “I don’t want updates right before a big presentation”. This is not solved by setting update intervals or an update time. The ability to revert updates also doesn’t solve it; even if this capability was usable from the GUI and easily discoverable, you will still lose your trust in Ubuntu if you’re in front of an audience and have to fiddle around with package reverts because your presentation/demo isn’t working.
The current desktop update-manager is well suited for this because every time before the system does major updates, it asks user confirmation. At that time, the user can make a quick decision of “is this the right time?”. Could we have the same thing with snap updates? The current apt approach isn’t perfect, of course, because it allows users to delay updates indefinitely by just ignoring them. But the idea of asking users if now is the right time for updates is a good UX pattern for desktop users, imo. You give users the ability to say “this is not the right time” but if they ignore the question, or if they delay it for too long, auto-updates should still happen.
So to continue the discussion; what do you think about this proposal:
- Every time snapd wants to update snaps on a desktop distro, it notifies the user.
- This notification has a button “delay updates for 24 hours”
- If the user ignores the notification, the updates will happen.
- If the user keeps delaying the updates for more than a week, the notification informs the user that this is the last extension, after which the updates will still happen.
This proposal is of course without any regard of what is easy to implement/feasible.
4 Likes
Leave auto-updates a very strong default and have the user specifically disable auto-updates on a per-snap basis if they so desire. The average user will keep it enabled anyway, I believe. However, edge-cases where a manual update process is required are covered by this.
For example an admin needing to greenlight a critical application first before it gets used on workstations or a crucial piece of infrastructure that may not have any unpredictable downtime. Easy pinning of specific versions would also be a use-case.
For the average case, @galgalesh’s proposals + the work on refresh app awareness ([WIP] Refresh App Awareness) will solve nearly all perceived problems on the desktop and thus I believe such a setting could be implemented without it becoming the go-to hack for frustrated users.
2 Likes
Previous discussion: “…a ‘Details…’ button, which would open a secondary dialog for controlling the schedule as well as listing recent updates … A simple first step — useful and releasable by itself — would be to add a caption below the new label, of the form ‘Last check: Yesterday 16:27’. If someone submits a merge proposal to do that, then I’ll design the next bit.”
Yes — I reported that issue in 2012. It predates snaps because it isn’t specific to snaps.
However, following the principle that things more closely related should be closer together, that is #3 on the list:
-
All snap update settings should be together. (For example, it would be awful for some to be in GNOME Settings and some outside, simply because some happen to be in common with another packaging system while others are snap-specific.)
-
Snap update settings should be together with .deb update settings. (Though they behave in different ways, these differences are most easily explained to users with them next to each other.)
-
Update settings in general should be together with other system settings. (The structure of the GNOME Settings UI is quite awkward at the moment — because it’s optimised for phones rather than desktops — but even so, Software & Updates settings would still be easier to find inside it rather than outside it.) This would also reduce the problem of Software Updater and Software & Updates being hard to distinguish in the shell, and fix various other bugs (as well as, I’m sure, introducing new bugs).
Ideally, all three of these can be satisfied at once. But if they can’t be, they are in order of importance.
That’s a case where you might sacrifice #3 to achieve the other two. That is, you might put snap update settings in software-properties so that people using other environments can access them in the same place they currently access .deb update settings.
1 Like
No need to make 2nd Windows. The update should insist on its update but not force it to install. Imagine a person who rejected blender updates for a long time since he was rendering a heavy movie. And then the moment came when he simply could not cancel the update. it will break him many hours and maybe many days of work.
1 Like
That seems like exactly the kind of issue that would be fixed by the App Awareness already mentioned.
But the “2nd Windows” slur raises a general question, which is why people complaining about automatic updates compare them to automatic updates in Windows, and not to automatic updates in Firefox, Chrome, or Chrome OS.
It might be partly that people using snap systems have more experience of Windows than of those other three.
It might be partly that the kind of people using snap systems are more likely to think that something is wrong because Windows does it, regardless of whether other systems do it.
And it might be partly that browsers change less visibly, less often, and less incompatibly, than other apps do.
But those other systems might also have subtleties that are worth copying in the way that they schedule, reschedule, download, and install their automatic updates.
5 Likes
Note; I’m a community member, not a snap/snapcraft developer.
A few notes about the scenario you talk about
- Snap updates do not change running applications. If blender runs while the snap update happens, blender will continue running. Once you close and restart blender, only then will you use the new version.
- In one of the next releases of snapd, it will default to not updating an app while it’s running. This is not required for the scenario you talk about, but it will further improve the user experience of updates.
A significant part of the security issues on Windows are due to users not installing updates. Most Windows viruses use exploits which are already patched. It’s also important to not become Windows in the sense that there are millions of insecure devices out there. This is not only an issue for the users of the devices, but also for every other user connected to the internet. It’s easy for attackers to weaponize insecure devices and use them to attack secure devices using DDoS etc.
Although I agree the current update policy is not ideal, I would like to see a better solution to these problems than simply “disable automatic updates”. It’s important to have people like you in this discussion so the developers can see what other solutions you can live with apart from “disable automatic updates”.
1 Like
This is true, but if clicked, it will not work quietly.
I explain why.
During the upgrade, the interfaces will be reconnected. For example, a telegram loses its old icon in the ubuntu-doc panel, and if I want to show a minimized telegram window, it is duplicated and I get 2 simultaneous applications.
due to reconnecting interfaces, it may happen that some functionality of the application will stop working.
1 Like
Note that this has some undesirable side effects:
- if you click the Blender dash icon in this state, it’ll launch the new version while the old one is still running
- if the application does any session management, the new version will see the saved state as it was at the moment the snap refresh happened, and not at the moment when the user closed the old version of the app
Point 2 is especially noticeable with Chromium: if you don’t restart as soon as snap refresh happens, your browsing history and open tabs will not reflect any browsing you’ve done since the refresh. This was especially painful on 19.10, it’s much better on 20.04 now that you get the notification about the snap refresh of a running application.
2 Likes
Thanks for the explanation! These issues should be fixed by refresh awareness and update inhibition.
For more info and future plans, see [WIP] Refresh App Awareness
Having this option set you can try to manually refresh a snap to another channel or to simply refresh to a new revision arriving on edge. For as long as the snap is busy it the refresh will be inhibited. A snap is busy if it has running non-service applications or hooks.
That doesn’t solve the problem, only postpone it for up to 7 days:
The refresh timeout is not indefinite, though. After a certain period (current default is 7 days), the update will be triggered.
I don’t know about you, but I always have a browser open (and since I work with a laptop that has working suspend, I reboot only when Ubuntu tells me I have to, after a kernel security update and such). I had that experimental snapd option enabled in 19.10 and was still bitten by a lost browsing session once a week because the snap would refresh, and I wouldn’t notice.
The notification in 20.04 solves this problem in a much better way. (I thought it was a snapd feature, but apparently it’s a hack implemented in the chromium snap specifically.)
Yes, creating the notification from snapd is part of the future work of Refresh App Awareness. I included the WIP/roadmap doc in my previous post.
4 Likes
I m really happy the Ubuntu team is re-considering snap update controls. This is the reason I have moved from Ubuntu MATE to Fedora MATE over a year ago.
It would be great if snap updates were integrated in the Software Upgrades program. My favorite option is to automatically check for upgrades but prompt the user for authorization before installing them. No need for thinking about a user’s routine to define snap upgrade schedules, metered connection or anything else. Just train them to approve when there’s time and disaprove when it is inconvenient to upgrade. Simple and efficient.
2 Likes
You may have more up-to-date information than I do, but last I knew this was not the case. When a snap updates out from under a running application, it actually updates the confinement profile of the running application. This is why the signal-desktop app eventually crashes with cryptic “unable to write to something something” type errors after a while: it wants to write to $HOME/snap/signal-desktop/300, but its confinement profile got rewritten to only allow access to $HOME/snap/signal-desktop/321 (revision numbers are made up for the sake of this example).
Inhibiting the refresh of running applications improves things, but I think it’s not a solution to the OP.
1 Like
We don’t have anything like this supported ATM. We have discussed and do plan to implement supporting holding refreshes for single snaps for a period of time (up to some amount), like we do already for the entire auto-refreshes (via refresh.hold config option for that case). There’s no defined ETA on this for now though.
[I’m just a user.]
I’d say: give all the options. Option to turn off (forever) auto-updates on individual snaps, and to turn off (forever) auto-updates for all snaps including future-installed ones. Give stern warnings, but ultimately the user / system owner decides.
More than just an “insecure” or “not updated” warning tag for each app that has not been updated, you could give a way to click through that tag to see changelists (from the app dev) for all updates that have not been applied. That way the user easily could check to see if any security / CVE stuff is in the changelists. The app dev also could put non-security notices in there (e.g. “fixed a crash which could make the whole database unreadable”).
1 Like
This are the 3 options that I think it should be included:
-
Auto-update snaps (or maybe download the app and notify the user to update, but this would only work better for small snaps);
-
Postpone updates, but not disable;
-
Put updates on hold on metered connections (just show a notification of new update) so the user can update manually
This is the current default.
I think the important part here is that users are notified of pending updates, and then get the option to postpone them. I think very few users will remember to go into settings and postpone all updates until after their big presentation. However, if a user has a big presentation the next day and they get a dialog asking to run updates, they might say “postpone them until after my presentation”.
So in short, snapd should warn desktop users that an update will happen and give them an option to postpone updates then and there.
Holding updates on metered connections is already possible, see Keeping Snaps Up To Date.
3 Likes