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
Actually for postponing I meant exactly that 
Thank you for the clarification
Hi @popey, first of all thank you for opening this task and revisiting that settings.
I would also like to freeze a specific snap version and update only some security vulnerabilities maybe.
Not sure if the following packages are in snap (yet), but their update caused a lot of trouble in the past for me and my projects: GCC, clang, CMake, curl. (change of behaviour, my projects did not compile anymore, etc).
I would like to have it in XFCE as well of course, but I can manage it in cmdline until then (to switch off automatic refresh)
Best regards.
This should already be possible using “channels”. A publisher creates a track for each major version of their applications and users chooses which track they want to follow. By default, every new major version gets installed immediately but if users manually choose a specific track, they will stay on that major version until they manually upgrade. Since you mentioned cmake; it is available in the Snap store and it does support tracks:
$ snap info cmake
name: cmake
publisher: Crascit✓
...
channels:
latest/stable: 3.18.2 2020-08-20 (549) 112MB classic
latest/candidate: ↑
latest/beta: ↑
latest/edge: 3.18.20200822-g08170b1 2020-08-22 (556) 113MB classic
3.18/stable: 3.18.2 2020-08-20 (549) 112MB classic
...
3.17/stable: 3.17.4 2020-07-30 (507) 111MB classic
...
3.16/stable: 3.16.8 2020-06-01 (401) 129MB classic
...
Is this what you are looking for @taw_moto?
@galgalesh thanks for the idea.
Currently I am not using snap(because I did know about channels and I hate automatic updates), but I will give it a try, it doesn’t sound so complicated 
2 Likes
@galgalesh I researched a bit your idea and is nice indeed, but very few packages have the option to track a specific major version, for example skype and valgrind do not have this option.
So I have valgrind 3.16 and I will be upgraded to 3.17 when that version will become stable, which I don’t want to. I want to stay with 3.16 for ever. (just an example)
Thanks for the idea though.
I think in those cases, it’s best to contact the publishers and ask them to create tracks for that snap. There is no way for Snap to know whether something is a security/minor update if the publisher doesn’t mark them as such. If the software is expected to be backwards-incompatible, the publisher really should create a track for each major version.
1 Like