Frankly, absolutely, yes. The owner of the system has the right to make decisions about it. It is not Canonical’s or Snap’s job to force them into certain decisions. Linux gives the owner/user the power to do things, and sometimes it’s the power to shoot themselves in the foot.
Who knows, maybe they have good reason to prevent updates. Maybe security holes are being handled by a firewall or something else external to the system. Maybe an update would break their payroll-check-printing system. You and I and Canonical and Snap can’t know the right thing for every situation.
The user (or system owner) should make an informed choice. Having a deb that really installs a snap seems underhanded. Inform them that the deb path no longer exists, or the version they’re using has security vulns, give them the opportunity to change to the better/newer snap. But don’t force them or deceive them.
well, not sure you read my words, i dont care at all if they shoot themselves in the foot but i do care about the fact that their unmaintained server becomes part of the botnet that kills my server with a DOS attack … or that they provide hackers a platform to operate from to steal your data … i dont care about their feet but about ours …
they are free to use slackware from 1995 instead of ubuntu, nobody forces anyone to pick Ubuntu and snaps over anything else but if they do pick Ubuntu, snaps are there and come with a secure update mechanism that gives you enough abilities to adapt them to your own schedule.
And nobody forces them to use snaps or Ubuntu as i said in my last paragraph
(note that i’m working a lot with customers. most of them grok snaps and thier update mechanism and actually picked snaps explicitly because of it to run critical infrastructure in their factories, robots, IoT setups and embedded systems.
it isnt like people run away screaming from it, despite there being some loud complainers in the community.
from a business perspective it is exactly the opposite, people take snaps because of this)
Okay, every debate about snap updates that I’ve seen has said you can postpone updates, but not completely stop them. If true, this ability to disable updates forever should be publicized by Snap/Canonical.
To me, as a normal desktop user and an as observer… all of this discusión are artificial, there are number of ways to plan / pospone / remove all snaps and, if you want to, remove completly snap or use another linux distro. All the comments that scream that they are forced to swalow snap down their throath are to me just nonsense.
Nobody is forcing you and if, snaps are a failure then we can allways choose something else. The developers are open to discuss to constructive conversations, but as always you sometimes have to say “no”.
I for one, like the idea of snaps, and there are getting better with each release.
they are free to use slackware from 1995 instead of ubuntu, nobody forces anyone to pick Ubuntu and snaps over anything else but if they do pick Ubuntu, snaps are there and come with a secure update mechanism that gives you enough abilities to adapt them to your own schedule.
That sounds exactly as I said, like take it or leave. Nothing wrong with the approach, it’s fine with me - but I do understand why it’s not to others. It’d be easier if the third path existed: some people do want to use Snaps, but don’t want to have them auto updated. Sounds reasonable to me, but it seems you at Canonical see differently.
Edit: I know there are ways to prevent them form updating at all, but they all seem hackish; should be “official”.
My main point is that while I understand Canonical’s perspective and motives regarding auto-updating, I think that the alternatives (i.e. Flatpak, AppImage) are just a much more compelling, less “my-way-or-the-highway” approach for distribution operators. Distribution operators are the key here: Developers aren’t going to be happy if this “universal” format turns out to be not universal after all.
Canonical seems to think that distributions will fall in line with their “my way or the highway” approach. While Snap is nice, the highway (a certain alternative) is looking pretty attractive and is just “good enough.”
Please note that while I work at Cannical, and do largely agree with the update design, I am an individual, only expressing my own opinion here, I do not speak fo the company.
That said … note also that the update policy chosen for snaps by Canonical is actually a result of 16 years of experience dealing with update and security issues of users and customers. In my very personal view (having been around for that time) it is an awesome step forward in the evolution of packaging. Still though, please take my optiinon as mine…
All formats are built with distribution-centered design in mind except Snaps. Snaps are built with user-centered design in mind. This is what makes Snaps different and good and the reason users like it and distribution devs dislike it. I don’t want Snaps to become yet another format that is harder to use because it’s better for distros that way. I like what is better for users way.
If you prefer distribution-centered design it’s good all other formats are to your requirements. IMHO users are the key and it doesn’t matter what distro devs support out of box if users want something else. Just like you, the user, have chosen right now to use something else.
Wikipedia would require a citation here with a “who?” tag. If you are not in the demographic that wants this then please point those that are to come here to elaborate on why they want this. As you have implied you are not one of these people then what you’re saying is anecdotal.
There is a lot of noise with no real substance other than complaining. Without understanding the reasoning for people to want to disable updating we have nothing to go on. Until we have that clarity we will continue with our plan to ensure that people are updated so that their systems remain secure.
I must raise my hand here. I use snaps, I build snaps and I love snaps but I hate when snapd unexpectedly brings my machine to a halt. Yes, I could schedule the updates but I can’t predict when I’m going to be working on something important. I’d much rather get a prompt to update instead of this happening beneath my feet.
One thing I’ve noticed is long boot times if you haven’t used Linux for a while and all your snaps need updating. It would be nice to have snapd moderate it’s update process to do updates after the system is booted rather than during the bootup. I agree that updating when you’re about to go onstage for example would be really bad. I would like to see a “I’m doing important stuff now” button that holds updates until you close the lid, logout, or the screen idles to turn off or some other more reliable indicator that you’re finished with your important task and that updates can resume. What I don’t want, though, is for that “important stuff now” button to be permanently effective once set; I would want some automated mechanism to reset it to “off” again.
I want this, I am a sysadmin who wants to lock down updates and get emails for potential ones, schedule maintainance windows, and then perform a controlled rolling update, and do this on a monthly basis if updates exist within that timeframe.
The keyword here is “control”.
Edit: I need to put a disclaimer here, which is that I have a vandetta against snap’s nonexistence of control as such caused me to lose a TB worth of in-flight data in a sigkill shutdown of snap-managed docker (long-running process operation, snap refresh, systemd timeout (which was already at 30m), sigterm, sigkill, data corruption).
I want to prevent this, I want my employer or clients not to suffer from this, but snapd does not give me this option, while also advertising itself as an universal app/software manager.
Edit 2: no, I don’t see “I am busy” hooks as an answer here, I see OOB control delegation as an answer to this problem, and many potential other ones.
The latter one will eventually fall through into updating anyways, you can’t hold packages forever, since snapd will eventually force a refresh after X amount of time, whatever the latest “max delay time” has been hard-coded into the software this time.
Edit: looking at this closer, this also seems like a half-solution, I simply want to turn off automatic updates and then do a controlled and manual snap refresh/revert whenever I want, be it in a year. The current behaviour will eventually refresh anyways, which is non-deterministic for an admin workflow, and thus a non-solution.
the “max delay time” is 60 days … so if you do monthly maintenance this should fit well into your window…
details at:
EDIT: also note that you can always snap revert any installed snap to the former version in case something slipped through … and that such a reverted snap will stop auto-updating
This isn’t about fitting my hypothetical workflow, this is about my gripe and demand for snapd; a config value that disables updates for specific or all snaps, is that so hard?
I’m sorry if I seem flared up, but this question has been met with nothing but hacks, workarounds, and diversions to the question.
The question to allow for a complete out-of-band control flow of one of the most crucial parts of this system: updating.
