People (speaking about home users) who want to stop snaps from updating can do so by blocking >api.snapcraft.org either at the OS level or at the router/network level.
I can shed a little light in this area. Have been following this thread for quite some time and have interacted with a number of the dev team with my questions. Followed the instructions given to use IPtables to stop the updates.
Well - - - here - - - it doesn’t really work. What happened was (happened 2 times now) is that there is enough software banging on the system from inside and a reboot results. As my server needs some manual intervention to complete the booting sequence it wasn’t initially (the first time) clear what had happened. After the second time I spent a number of hours searching through the /var/log files looking for why the machine had gone down. (I am working toward having my server monitor and control processes.) In became quite clear that it was snapd (or snappy or snap or snapcraft whatever the software is actually called) that was triggering the behavior which resulted in the reboot.
Because this kind of behavior (outside control) is not only quite antagonistic to my needs (a server that is monitoring AND controlling processes) I have started setting up another complete system so that I can determine how to run LXD from source code rather than having to use software that doesn’t allow my choices to be used.
Interesting to me is looking at the total environment. When I look at ubuntu’s stated goals and then their specific team’s actions I am starting to see movement away from the idea of independent systems as is espoused in the idea of FOSS to a centrally managed (and controlled) environment (the 800# gorilla of the microcomputer software world is already doing this all). I can remember reading the advertisements way back when the IBM pc (and the pc jr) was released and one of the ideas espoused was ‘computing - - - YOUR way’ (my emphasis). I’m thinking that the IT departments of yesteryear might actually have been easier to deal with that the IT thinking that is now dominating microcomputers and their use. (Especially fascinating is when debate is halted by a sysadmin - - - not because of uncouth language - - - but merely because of a need to shut the topic down.)
@Iolaum Our goal is to establish a proper flow for software updates that tend to work very nicely both for users and for publishers. We’re not actively preventing the system from being hacked by such home users, though. It’s just that if it breaks when doing that you get to keep all the pieces.
With that said, we continue to hear feedback from everybody about the good and the bad cases that arise from the implementation, and we’ll continue to improve it until it has achieved that goal. So don’t take the current system as final, and keep the feedback coming. There’s a lot we want to do still.
@dabeegmon That’s unexpected, and snapd should definitely not be rebooting a classic system like that. Can you please provide the logs that made you believe that this had happened?
Are you really sure that you want all of this information?
To put this together I looked through something like over a hundred pages worth of material and from that likely at least 20% would need to be pulled along with the editing needed to outline what each section came from in the log files. It would be a very large amount of work!
You know what is really fascinating - - - anyone that disagrees with you is denigrated - - - most often subtly (but not always) - - - like here. You’ve done this quite a number of times in this thread especially when a use case for having things NOT in the way you want - - - you make the person raising the issue seem inept or stupid. Are you having issues?
Re: the amount of time - - - well as it involved reading through a lot of material first to find the points in common and then to read backward trying to see what things could mean and then cross correlating the various different logs - - - well on the first incident I couldn’t understand but then after the second time I asked for advice and when given more information (specific log files to focus on) I was able to correlate things and step back in time to find when the issues had started. As this was a lot of work spread out over a number of days I don’t really want to replicate this effort just to have someone dismiss it as nothing just because they don’t like it (as you have already done with the idea).
I’m not a moderator but please can we stick to the argument and not attack the users of this forum in such a fashion? You’re in danger of violating the ‘Always Be Civil’ part of the FAQ (and I would request that moderators give you a warning on this rather than closing the thread again). In my humble opinion the snapd developers are being very generous by keeping these controversial threads open rather than simply closing them and I think we can make progress if we remain productive and give what they ask for. If you would really like to see progress on this issue then yes, please provide the logs, it doesn’t matter how long they are! Attacking the snapd developers by saying things like ‘Are you having issues?’ will not progress things, it will just make them irritated and angry and the current way that this feature works won’t change. Niemeyer has said that he’s still taking feedback on this issue and it could change, but we the users need to be patient, we don’t work on this software, the devs do.
I also back change to the status quo, but I understand where the developers were coming from and I don’t think getting angry at them will help the situation - we need to keep this thread open and keep providing use cases where the status quo is unhelpful. Software is not, actually, developed by democracy, if it were features would be created and then reverted according to the outrage of users which is usually against the status quo because the objecting voices are nearly always the loudest voices. See Ubuntu. When Unity was default, people were angry at Ubuntu for having Unity as the default (fragmentation! It’s horrible!) and now GNOME is default, people are angry at Ubuntu for having GNOME as default (Unity was better! Over-simple! or Just use vanilla!), if Ubuntu always followed the outrage then the default would be changed with every release (and maybe even several times in the development cycle too). KDE has also been suffering from this issue.
Despite software not being developed by democracy, providing use cases as evidence of problems with the status quo for the developers to consider is still very helpful and can progress things. Please read this controversial GNOME Files Issue for an example. Use cases were provided to show why the status quo was bad and, eventually, the decision was overturned (when the devs were convinced). I think it was the use-case of building custom scripts and applications in a corporate environment really swung it for the developers but Simon Peter (probonopd) engaging with the developers on the issue and appealing to them because it broke the AppImage user experience was also helpful in creating change (though sometimes he was a little too strident for the developers’ liking, but I think the use case he raised and his advocacy of the issue, promoting it for others to chime in, was helpful - even more use cases were provided to show that the status quo on the development branch was problematic).
It’s possible that your conclusion is wrong, this is simply a fact, one doesn’t just trust what anyone says on any issue without a sufficient demonstration of why they think that their view of events is indeed the correct view of events. They may not end the forced automatic refreshing if your demonstration of the problem is correct, but they may fix the issue so that reboots are no longer forced on computer systems, isn’t this a bug you want fixed?
It has been more than a year now since the feature to disable auto-update was requested. 166 comments with 9.1k views, only topped by the “Snap wishlist - suggestions wanted!” with 244 comments and 10.5k views.
It’s very clear that what users and developers want to see from snap the most is an option to disable auto-update. I can’t believe this feature still doesn’t exist. I like the snappy as a package but as I user I literally have no idea what apps are updated, what are still waiting to be updated, what update failed. I know nothing, as a user it’s completely out of my control and I don’t like it. Snapd should prompt the user with updates, user should be able to see the changelog.
There are many reasons to make those updates more visible. Let’s say I’m supporting some dev trough patreon or I bought an app like the ones from JetBrains. As a user I wanna be prompted to update so that I can see the changelogs to learn about the new changes and features so that I can look for them in a software and take advantage from it.
Having a choice, I’d rather have a choice to update than be in an illusion of security because the apps are auto updating.
I like the Android way, it’s on auto by default and I kept it that way since it shows me the entire updating history and there is an active notification for every app that is being updated at the time but I know that I always have the option to disable the auto-update and just do it myself. Also play store or apkm is smarter, it knows not to update while on low bandwidth connection, mobile hotspot or devices mobile data. It can update only using WiFi, it can update only large apps over WiFi and the rest as it feels like. I can control every setting and just configure it myself if I want or disable the auto-update for one app, multiple apps or the entire app library all together. And that’s the way package management is done.
As a user, there are some drivers or software that I simply don’t wanna be the first to update. I wanna wait for at least 50% of users to update in a first few days and if nothing was reported then I’ll update. Let me explain. If you have for example a video editor and you are in the middle of the project, you don’t want to update before you finish that project because what if they tweaked some effects that you are using or the working file format? You could potentially have a real mess, someone in the office opens the working project in a new app, doesn’t notice the changes, saves it and breaks weeks worth of work.
That has already been a case with Krita, Kdenlive, Inkscape 0.92 breaking all the files from the previous version. Gimp… Even Ubuntu 18.04 I updated, couldn’t log in anymore man was I furious
There are cases where I don’t want you to say to me that I can roll back because by then it would be too late. I also don’t want me or any of my employees spending time checking if maybe the snap updated over night of while they were getting coffee. I want the software updater to make me aware that update exists and then I know to update it after we finish that particular project which we started editing using that version of the software.
Also I want my admin to take care of that, not Canonical, they don’t know anything what I’ve outlined here and they shouldn’t know it. What they need to do is make the update process more flexible for me.
As a dev, there’s no way I’d be using this for a non IoT app that doesn’t get tested extensively, I don’t wanna push an update just to discover I made some mistake in the code and everyone got the bad update. I’d rather it be a few users that report the issue and I push another update making most of the users skip the one with the bug. It happens to the best so it’s best to expect it.
You can say but that’s what edge, beta and rc channels are for and we’ve seen how that’s working out even for the snapcrafters team. Most of the snaps with multiple channels have the same version of software across all of them.
I just remembered, while we are on the topic of auto-updating, look what came up to me like 2 weeks ago when I was shutting down my laptop in a hurry to board a plane!
I mean, imagine my shock, it was the first time I’ve seen that on Ubuntu ever. I might as well have been using windows all along…
I really do hope that Ubuntu devs start making FLOSS philosophy as they might say it “a first class citizen” on Ubuntu again.
P.S. I didn’t miss my flight but I was holding my laptop opened in one hand on the terminal and trough the boarding lol. I was shockingly staring at this newly discovered Ubuntu screen and other ppl and flight attendants were shockingly staring at me #ubuntuproblems
Not all of those views are from objectors, only a few people of those few thousand who have viewed have actually commented or Liked comments to register their opinion (even though I’ve been encouraging people to engage in that way, they don’t always do so), so we don’t know what their opinions actually are, so you can’t claim that that view number demonstrates ‘what users and developers want to see from snap the most’, and many of the comments are actually from snappy devs and myself engaging with objectors rather than making reasoned objections ourselves.
I think I back change here but I get where the devs are coming from and I’ve driven much of the traffic to this page because it’s one of a few places where I think snappy is currently going wrong (but I understand why it’s making this decision and it does have positive consequences, not only negative ones) and I’m honest about snappy’s downsides and want people to try and engage with the devs productively rather than simply get angry about it. Giving specific use-cases as to why this doesn’t work for people (rather than just ‘I don’t like it’) and suggesting changes short of an off switch (since the devs aren’t willing to contemplate an off switch yet) will move this issue, more of that productive input, I think, will create more change We’ve already made progress, the snapd refresh timer enables one to just schedule an update once per month. If people can give good reason as to why that should be extended, and to what period of time and why that particular time period, then it may be… I’ve filed a bug against Ubuntu for Ubuntu to surface this option in a GUI, please mark yourself as affected by that bug
Just because you (and many others) don’t like it doesn’t mean it should be changed. Users will always dislike certain parts of software but other users will dislike the change. The protesting voices are usually the loudest so the objectors’ views can’t always be heeded because, if that’s always done, there’d be constant flip-flops in design. Personally I really like the background updates. It’s completely hands-off and lets you get on with your work, Chromium OS-style. And not allowing a global off switch forces developers to get to grips with the feature and develop tests etc to ensure that their updates don’t break people’s experience. As for the changelog, yes that should be available somewhere and easily accessible from the command-line and from software centres. Was this something that came up at the sprint for GNOME Software @willcooke? Would the home screen surfacing of ‘updates from your favourite application publishers’ cover this? Could it be accessed in a more reliable fashion (i.e. on clicking an application, access to the changelogs is there on the application page)?
In theory those new features should be discoverable enough that you’d find them through just using the software but I get the idea. I think updates on GNOME Software’s home screen will help with that.
It’s not an illusion. There’s some risk because the apps are coming straight from upstream and sometimes the dependencies will be out-of-date but, on the other hand, you get updates, often including security updates, as soon as they come from upstream, there’s no distribution middleman delay.
If your connection is metered, snappy will hold back the refresh for up to 60 days, if you think that should be extended then make your case in the topic and give a specific use-case as to why you may need longer than 60 days. Maybe one could be in a developing country and with no Wi-Fi access but metered mobile data access? Is that a real use-case?
I’ve asked if the metered bandwidth toggle in GNOME 3.28 will work with the above feature, if so then it should cover your use-cases above too (and graphically). You can do this with the command as it is: snap set system refresh.metered=hold then snap set system refresh.metered=null when updating is fine.
Personally I notice when snappy is taking up bandwidth when I’m on a low bandwidth connection so I run snap changes then snap abort foo to end the refresh, but the refresh.metered command is neater than that, and the refresh scheduler.
I didn’t think this was possible in Android? Huh.
What if snappy wants to do things differently?
The former is a good point, I’d like to see some comment on that from, say, @niemeyer, perhaps holding back refreshes on particular snaps for that use-case is a good idea? Or maybe they’d have to say that this is something that snappy can’t provide and you need to use something like AppImage or Flatpak instead for that use-case. The latter (‘working file format’) should be covered by the epochs feature which is currently in development (no ETA yet), as I understand it, if there’s an update that changes something like the file format, the dev should give that a new epoch number and you won’t be automatically refreshed to that new epoch? Is that correct @niemeyer? This would cover your Krita, Kdenlive, Inkscape, GIMP use-cases. Your Ubuntu issue sounds like something different
Once epochs is a feature, if I understand them correctly, that won’t be necessary, everything should just work (though I understand there’s some risk here…I guess the snappy devs reckon that it’s a risk that you should just have to take, sorry!)
Your admin can already take care of that. A feature that has grown out of this topic is the Snap Enterprise Proxy which allows your admin to manage the refreshes!
Staggered updates is an idea (like how Ubuntu pushes out Stable Release Updates to around 20% of users at a time), @niemeyer? Maybe snapd does this already though, not sure.
That’s usually because there hasn’t been a new release recently In theory it works fine, we just need more early adopters reporting bugs… @popey could possibly comment on this, I can’t recall specific occurrences where an update is pushed to a non-stable channel and regressions are fixed, thanks to user reports, before they hit stable, but he may be able to recall occurrences
I like this product very much. It could rise a bar of quality linux software. It is exactly what consumers want.
But, from my perspective, force auto-updates or anything else is a big step back in this world, especially in the open source community.
We’ve already made progress, the snapd refresh timer enables one to just schedule an update once per month.
I would say OK to auto-refresh consumer like programs. But, there is a difference between simple consumer programs, like calculators, and professional software. Especially if you are writing custom plugins and configuration. If an update causes the problem just before you need to finish a work, you will have huge problems. And more customizable software is the more chances to make something incompatible with future updates. It is common to not find time to fix issues within a month.
I didn’t think this was possible in Android? Huh.
Actually, this is possible in the Android. And you don’t need to be a developer to do that. However, Google still notifies users about potential updates.
I created an account here just to let you know that I think that having something installed on a Long Term Support release distro that is automatically updated is extremely counterintuitive. What happens to the user when someone pushes a broken snap? How is the user supposed to know that the snap broke because of an update? If I were that newb user, I would blame myself. Hell, even as an experienced user, I would probably blame myself first.
What if I’m on a connection with metered bandwidth? I just have to let snapd use up all my bandwidth and be ok with it?
Turning Ubuntu into a half rolling release with snaps is not at all acceptable. Ubuntu is meant to be newb friendly. Newbs should never be forced to have packages that are automatically updated. We have stopped recommending stock Ubuntu due to shipping snaps that are automatically updated by default to newbs in our Linux group. We now only recommend Ubuntu flavors.
Sorry, but that is not acceptable. The user needs to be able to disable this entirely. This should be disabled entirely by default. What happens when the user has enough snaps to sap all of their bandwidth in one month. You would give them no choice but to use all of their bandwidth on snaps every other month. This is highly unacceptable.
You guys are turning Ubuntu into a half rolling distro with all of these snaps that auto update themselves. Please stop it. Rolling distros are not newb friendly. You are making Ubuntu not newb friendly. No other packages are updated automatically by deault on Ubuntu. The user is not expecting packages to be updated by default on Ubuntu. You are not only doing something they do not expect to happen, you are giving them absolutely no choice in the matter. This seems like something Microsoft would do.
This is not true since 18.04 anymore, security updates are downloaded and installed automatically by default, even for normal distro packages (check the software settings)
I created an account only to heart simonizor’s reply and second every word he said.
Here is my short opinion: Not being able to manually disable updates is almost obnoxious. Many, MANY valid reasons has already been pushed in this thread. And what Snapcraft comes up with is some metered connection voodoo?? Guys WTF hahahaha. Give me the choice, boom. Easy peasy and the world would immediately have become a better place.
And for the record, I (and probably many more ppl) will not try to hack my connection into being metered and succumb to hours worth of study of manuals to figure out if this metered-voodoo even suit my needs or how to reach the end goal. Again, giving me an option to manually disable updates would have been so straight forward and easy.
I think overall, we as developers should STOP trying to “think” for our customers and users or otherwise add “features” and hacks all over the place. Just give the end user a real choice!
Not saying the following rant applies to Snapcraft, but time and time again I hear of developers adding effort and energy into building something that actually limits the usability. And the reason is because they decided they know better than millions of users out there. These developers often respond with a; “why would you wanna do that” and then cross their arms. Well excuse me, because I am tethering a WiFi from my phone over a limited roaming data plan in the Sahara desert into a VM that runs a Docker container that…
Developers must understand that the reality is far too complex and demanding for us to dictate and instruct our users what their reality is or “should be”. KISS: Just give them a choice. So simple.
Ok, now something that nobody has mentioned just happened to me. A couple of weeks ago I was on a road trip and I needed to send some emails, login on some servers and check some work stuff, nothing fancy. I activated my cell phone hotspot and started with my business, but something felt off. Everything was going really slow, so I ran nethogs to find the culprit. Guess what, snap was happily updating itself over my data plan and by the time I disconnected my laptop it had already chewed 400MB from my 2GB monthly plan. I couldn’t work with my laptop until we arrived to our destination 2 hours later or I risked to lose more. We are talking about money and time. Don’t you think this story could have been completely different if I could disable the automatic updates and manually choose when I want to install them?
Regards
Mauricio
Another good reason to allow system administrator to do updates when they need.
I’ve got a lxc cluster with lxd installed from snap, because it’s easy and the official documentation says it’s a good way to get the latest stable version.
Today lxd from snap refreshed at 11.44am and all my lxc containers crashed. On a production server. When I really didn’t need it to happen.
Now who’s fault is that? snap for not allow updates when I say I need them? lxd for releasing an update poorly tested? Mine for trusting snap on a production environment?
Sorry for this rant, but it’s ridiculous that you force updates to people perfectly capable to do their own testing and then schedule it when it suits them.
man was I furious 
We’ve already made progress, 
