They’ve said they’ll make changes to accommodate for any use case that could arise, just specify your use case that needs accommodating here!
This is not particularly respectful, I don’t think, because you’re pretty much just asserting that they should know better. Could you instead specify why it solves the issue in a bad way?
As a desktop user of snaps, my use case is to have the ability to run sudo snap refresh and control when snaps update on my own. Snaps that initiate updates on their own will end up updating at unfortunate times.
I don’t want to theorize as I haven’t had a snap accident yet (and several use cases have been mentioned earlier in the thread) - I only, currently, use the snap installed by default from Ubuntu MATE 17.10 and play-tested the flare-rpg snap as well. For example I 've gone out of my way to install skype and vscode from debs because I don’t like snaps updating them whenever they want. (I 'd be very unhappy if skype updated and broke that 1 day of the month I was going to use it because of an update I didn’t know happened.) Moreover in my specific use case I update through the command line to see what will get updated and have an eye for any warning that may pop up, so I can research it and address it if needed. Snaps auto updating in the background will hide that from me.
Regarding the snap enterprise proxy app that was suggested, the instructions in this page are way too much compared to an option on snap set on the command line. Adding all those steps (installing a new app, learning how to configure it and then making sure it is set up properly) is complicated and not how I 'd like to spend my time. I am not a UX expert but the little I learnt from my colleagues is that the more steps a user has to do to get to the desired outcome the more attrition you have. If that, or the tone in my previous post, sounds disrespectful I apologize. My intent was to show how the presented solution is not accommodating (according to me) for a home user.
Proposed this feature in a separate topic Snap refresh over metered connections
I am arriving quite late and admittedly confused by the lengthy thread, so apologies…
For me, I use a variety of intrusion detection methods on my systems. As a result, I need some hooks (e.g., similar to apt) or the ability schedule my own updates. Otherwise, it is a lot of work to wade through all of the “noise” introduced by automatic updates. Does that make sense? I will be happy to elaborate if anyone is interested.
Hello - I have seen this dicussion over the year and am not really sure what the status is (its a long read) I was direct here from my related questions (Updating daemon snap)
Just curious if anyone has given this some thought since it would handle most of my issues:
Deployment Groups (or sub channel)
These function just like channels… when installing a snap you can optionally enroll into a deployment group. These groups can have different update windows which are configured in the store or snapcraft that is published.
If someone was so inclined, they could create a group of 1, but in practice a group will coincide with say a IT policy for a specific set of users, ie “2nd Tuesday of the Month”
A simple cron expression would suffice for ‘schedule’
I saw the refresh option too, but could not seem to get it to work. Probably user error on my part but could have been a beta version issue (I was toying with Ubuntu 18.04; I’m actually a Debian user).
For me some kind of hook would be ideal. For example, check the file integrity database, apply updates, update the database.
However, scheduling updates could be good for other reasons. For example, consider a long running scientific computing job on a desktop (say doing some debugging or preprocessing prior to running on a super computer). I would be a bit cranky if an update caused me to loose a few days of compute. Of course, the proper solution here is to run the compute job in a VM (with automatic updates disabled). The VM can then be suspended/resumed to apply urgent security updates to the host.
[quote=“niemeyer, post:31, topic:707”]
In other words, whether you manually update or automatically update a snap, for using the snap at all you have to trust that the developer is not simply shipping your private conversations to arbitrary third-parties for example, in the case of a chat service.
[/quote]I am very new to snaps, so I may not understand how they work. With traditional updates, if you have any reason not to trust your developer, you could examine the source code before you update. I presume with snaps you could hold off updating long enough to do that?
[quote=“Don, post:54, topic:707”]
I’ll just block it by pointing api.snapcraft.io to 127.0.0.1 in the hosts file for now as a workaround, but I’d prefer to do it through a global switch in the future.
[/quote]Thanks for that, I will probably use it.
There are devices where I would be delighted to see automatic updates happen. (Most of them are other people’s, mind.)
There are devices where I would be horrified to see automatic updates happen. Some of us do have kit that has to stay up and if an update is not absolutely essential, it doesn’t happen until it can be bundled with one that is.
There has to be a simple way to say which category a device is in. Having two versions would be one option: one has a feature of doing automatic updates, the other has a feature of not doing them. The user picks one and if they get bitten by the choosing the wrong one, well, they had a choice.
I get developer frustration with people who don’t ever upgrade. But I’d be happier if the developers were prepared to put their money where their mouth is and pay every user affected by a bug in a version that was installed automatically, mind. For all the talk about ‘holding back releases if bugs are filed’, Ubuntu has - more than once - issued releases knowing that they break things, and at least one that turned out to brick some people’s laptops.
Snappy is not Ubuntu. If you report your regression (here on the forum for the most visibility) before the update hits stable, iirc snappy devs have promised above not to release the snappy version to stable until the regression is fixed. You have their word (perhaps they can renew this promise below).
After a regression happens because of an unexpected upgrade of a snap application the round is lost - as far as snap platform user experience goes. The idea is for the user to be able to schedule updates when and how it is convenient to him. The user knows best how to balance the risk of getting hacked because he didn’t update versus having his system going down because a snap got updated. Even Intel botched the firmware updates after the Meltdown vulnerabilities despite knowing about them for >6 months before shipping the updates. You can’t reasonably expect new software to not have bugs (even bugs as features when a workflow/usability change may negatively impact the system the snap application is part of).
Letting users schedule updates for when and how it’s convenient for them, if they so choose, is exactly what snapd enables, today.
Yep. @Iolaum please read these docs to find out how to schedule your updates within each month! 
Unless I missed some changelog snap does not allow me to not schedule updates and only perform them manually. I can configure apt updates to never happen unless I allow them through the Software & Updates app. But I cannot do that for snaps. My home computer is not like a server, it doesn’t stay on 24/7. I open my laptop to do work, and when I 'm done I update. I don’t want to have my computer auto update while I 'm working and I don’t want to lose the simplicity of updating when I say so versus becoming an oracle and imagining when I can have my computer on but not work on it so it can update. I also don’t want my snaps to update without me seeing the changelog - and relevant warnings - in my terminal so I can troubleshoot them before I need to use an application that misbehaves. Keep it simple please- allow home users the ability to tie snap upgrades to the options available in Software & Updates app (and therefore disable upgrades when they see it).
@Iolaum you can currently set snapd to only refresh snaps once per month as per the docs I linked above. However I know that’s not quite what you’re looking for…I wonder if snapd can get closer to what you’re looking for without using a global off switch though:
@niemeyer Maybe snapd could support an option that, when selected, means that snapd doesn’t automatically refresh for a month after the last manual refresh. That way @Iolaum can refresh only when they turn off their computer, as long as they do that once per month?
@Iolaum if you read what @niemeyer (the snapd lead) has said earlier in this thread (quite close to the start but also throughout), they’re not producing an off switch because they don’t want users to be stuck on outdated and insecure software. By not producing the off switch, they’re forcing themselves to grow features (like maybe the one I suggested above) which mean that users should never need an off switch. It’s not being kept ‘simple’, as you see it, because they want updated systems that are usable, which means somewhat complex (but very useful) policy.
Why can’t you work and update simultaneously though, not enough bandwidth?
As far as I know, snap updates don’t have changelogs anyway, @niemeyer is this an option that devs should be able to give? Perhaps someone could choose to configure snapd so that after snap refresh is run, before refreshing, all the changelogs come up for confirmation? Or, snapd could require that users refresh when refresh is run but provide the changelogs somewhere for access. Also how do you define ‘misbehaves’ @Iolaum?
@Ads20000 Yes, it would definitely be reasonable to have an option to say “skip refresh windows if the last manual update was within N days/hours/etc”.
Until this feature is implemented, I flat out cannot use Snap packages.
I recognize the desire to protect users—but the end result is that I cannot use snaps at all, or any of the other potential benefits they offer.
I’m toying with the possibility of just installing everything in -devmode, but that of course has it’s own, major security implications.
@Ads20000 Misbehaves means that it does not behave as the user expects it too. This can be a bug (incorrect implementation), a new feature that changes the user experience (UI or UX changes), or something else. Let me state an example:
Say that I have installed the skypeforlinux app through a snap (isntead of a deb from microsoft ppa as I 've currently done) in my parents laptop. And then let’s suppose that in a new version microsoft updates the UI as usually happens with this apps. As far as my parents are concerned this can be more of a bug than a feature. Right now I have set Ubuntu Mate to notify of updates that are available that they accept at their convenience. Therefor if after that something goes wrong (either because of a bug or because of a UI change) they can be ready for it (and hopefully figure out the UI change on their own). On the other hand, apps/snaps that update in the background without the user knowing when may surprise the user at inconvenient times.
On top of it it’s interesting that the snap enterprise proxy application allows (as claimed here, haven’t verified it) to defer snap updates, but the user on a laptop/desktop can’t. If it’s reasonable to allow the user to keep using an older kernel on his machine (e.g. by disabling updates) why is it unreasonable to give him the option to do that with snaps as well ? I am not saying that a user should do that, and if I met such a user I 'd try my best to help him solve the technical debt that made him make such a decision.
Snaps really need to have a way to plug into the centralized way an Operating System has for managing updates (e.g. the Software and Updates application in Ubuntu and derivatives). Snaps are a good technology, and I 'd rather have skype as a snap instead of a normal installed deb in my system, but not at the expense of losing, as a user, the unified workflow I have for controlling how my system updates.
I think I heard a while ago that a notification feature is on the roadmap, just be patient 
What stops you to set up such a proxy on a desktop/laptop ? It is just a question of installing and configuring software after all (there is no magic in running a proxy locally on a desktop/laptop and point your proxy settings to localhost, many people do that all the time)…
One of the bigger goals of snaps is to actually take away the need for having to control this. If you look at server snaps (any snap that starts a system service) they already do fully automatic rollbacks if the service fails to start after an upgade. The builtin rollback and selftest features in snaps aim for exactly that … not having to care for updates anymore and having a system that always works, no matter if something gets updated or not.
The target here is to take away a burden so that your parents will not even have to care if an update happens or not but will always have their applications fully functional without being bothered with maintenance work or reading cryptic messages in changelogs.
One of the bigger goals of snaps is to actually take away the need for having to control this.
This will never happen. Software always had and will always have bugs. Look for example the bugs Intel’s firmware updates had after the Metldown/Spectre vulneerabilities were announced. This is why people who professionally administer systems said in this thread that auto updates are a no go.
BWhat stops you to set up such a proxy on a desktop/laptop ?
I 'm not keen on installing a proprietary solution in order to use snaps properly. Moreover it adds complexity in managing the system. Lastly, as has been suggested here, one way to kill snap upddates is to block/redirect api.snapcraft.io. If I just wanted something for myself I could settle for that. But It’s a duct tape solution and I don’t like it. Moreover this feels like DRM on video games when they were shipped in CDs (legitimate users couldn’t make back ups of their CDs [to cover for scratches/damage] but cracks and images were available for people who didn’t buy them). People who want to go around auto updates can do so, but non-technical users don’t have a way of controlling their updates according to their needs. Moreover this approach prevents Ubuntu desktop distributions from integrating snap updates in the Software and Updates app that handles updates for the rest of the system. Why do we need two different update mechanisms in Ubuntu? This (not allowing snap updates to be fully controlled by the user - that includes never update -) is wrong and I hope Ubuntu developers will realize that allowing users to control updates does not harm the quality of snaps.
