You might want to check on the snap labeled ‘core’ - - - it is neither independent from snapd nor is it independent from the host OS.
Any changes that may have been introduced were to maintain a working system following the directions of either the team producing the snap or the dev team here.
It does seem like the team here likes to work on the edge - - - for a business on the other hand - - - risky software is quite easy to justify discarding - - - - it tends to produce far too much stress.
Please don’t struggle - - - -you will only hurt yourself. The wonderful people here only want to help you so you don’t hurt yourself - - - - but you must do EVERYTHING as they tell you do. If you are bad - - - - things will not go well for you!
The core snap tracks the stable channel by default and the release process means that the core snap goes through the beta and candidate channels (spending considerable time in them) before reaching stable. People who need reliability are encouraged to find a way to test new versions coming through beta and candidate before they hit stable and report issues to the snapd team. If they find an issue, it will be fixed via a point release and a regressed version of core will not hit stable until the issue is fixed. You also have the Snap Enterprise Proxy if you need to hold back updates.
(Would like to mention that I’m not part of the snapd, snapcraft, or snap advocacy teams and thus, I hope, my opinion is independent)
I would also like to request that this topic is kept open and that if action needs to be taken on any posts that infringe the advice in the FAQ then that should be taken, rather than closing the topic
While I don’t agree with the developers decision to not allow toggling updates on and off, they do deserve to be treated with respect.
The biggest problem stems from Canonical developers ignoring user feedback in this case. There are valid use-cases, both in enterprise and in desktop usage where control over updates is beneficial if not critical.
The solution suggested here indirectly solves it in a bad way. Ask one of your user experience colleague’s what he thinks of the suggested workflow.
Moreover the suggested solution is proprietary. For those of us who factored open source into the decision to use Ubuntu, this is a red flag.
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.
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).
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).
