Disabling automatic refresh for Snap from store
forum.snapcraft.io
forum.snapcraft.io
I have been using Fedora 34/35 the last year or so, and Flatpaks are well integrated and mostly just works without any performance hit. Being able to adjust permissions per app (with Flatseal) has also been a great experience.
I have little experience with Snap, but the few times I have had to deal with it on Ubuntu-based distros, it has left a bad impression from a user perspective.
Snap wants to be a desktop, and server, system. Not with a 10 foot pole - Docker is literally 100x better. Not on my Desktop - Flatpak is superior there.
Without fail, on multiple machines, shutdown/restart is stalled for the maximum 2:30 timeout for snapd. It's a useful reminder to uninstall Snap whenever I find myself in the unfortunate situation of using Ubuntu.
The future of package management is NixOS/Guix System, the future of isolation are cgroups (see FireJail, BubbleWrap). The rest is absurd like full-stack virtualization on x86 to make VMWare profit, HW OEMs profit, consulting profits etc and people who should not, because of ignorance, running infra built by someone else a brick at a time, or the way to create disaster waiting to happen...
I see exactly ZERO good cases for snap, flatpak, appimage etc... ZERO, really.
This is why people hate snaps. They don't fit user workflows, make extra work and even cause show stopping problems.
Snaps could be great but the team really needs to listen. For me I'm removing snaps from my configs before I get surprised.
(edit: mobile autocomplete typos)
Chrome/Google did the same thing.
Snap clearly has a philosophy. And a lot of people clearly disagree with that philosophy.
Thankfully, instead of "advertised from google.com", Snap has less ability to push itself on users, and users have more ability to choose it... or not.
Seems like that philosophy is the user is not to be trusted. The problem here is that users in reality, not just philosophically, CANNOT trust snap because it will force updates (or dns trickery to stop it) that may cause a system to stop working.
Which I can't say is wrong.
Who probably shouldn't use Snap are users with mature patch application skills, who are willing the invest the time to review and patch regularly.
That class of users is far smaller than {all users}.
This is true. But there are so many situations where unpatched is better than bricked or bugged. The community's ask was reasonable.
But I think the goals might also be mutually exclusive.
Snap's philosophy, from what I read in the thread, boils down to: if an update bricks devices when it's pushed, the proper time to catch that update is before it's pushed, or as it's pushed, not after.
Which I do see the wisdom in. The majority of users are less well informed and equiped to test and patch than developers.
Well… what, five years later, here we are. They are still trucking on although the Linux community at large has turned against them, yet they remain in their echo chamber of a forum and don’t see it, convinced it will all work out or some crap.
Almost feels like malware on every level. Can't comprehend why they are pushing it so hard.
Ubuntu is on borrowed time.
I doubt this is the whole truth, compare https://news.ycombinator.com/item?id=30800957
Snap for GUI apps, okay, fine. Snap for system infrastructure, no thank you.
Quite bad timing and since I surf mostly in private mode I'm not so keen on a restart at inopportune times since my state will be completely wiped.
Plus, if you're OK with using a TPM, you can also get waking up from hibernation without having to enter type in your password.
Source: been doing exactly that (without the TPM part) on a laptop for a few years, and it just worked like a charm. No hoop-jumping involved or anything.
I went over the blog post, and it looks like it's a PITA to enable because they went out of their way to make it so by using a weird partition scheme. I've never installed pop OS, but according to that blog they're using LVM on LUKS, which should work fairly well.
> but as far as I know no distro does this correctly by default on an encrypted drive.
What does "correctly" mean here? On my previous laptop I had arch installed on ext4 on LVM on LUKS. Therefore, the swap was on the same LVM. Aside from having to manually set the "resume" kernel parameter, I never had to do anything, and it just worked.
Not only did it take multiple days for them to respond (me without laptop), their resolution was to attach an invoice for one despite me asking for two. I didn't want to open a new ticket so I just looked online for an AC that had the same voltage/amp/etc and head, then ordered three. I have multiple desks...
The three arrived approximately a week before the one they sent out.
Also, you can't actually open these the way they've glued them shut inside by attaching the heatsink to the outer case. Might be a manufacturing defect but definitely can't open mine after unscrewing the bottom.
Never buying a System76 laptop again after this thing dies.
Running sid is an option, but the amount of fiddly Debian magic you end up needing to learn when it breaks is IME not smaller than the effort of setting up a mostly-unpatched rolling-release like Arch (and I’m sure there are other options). Given that e.g. Arch’s packaging is simple enough it’s no big deal to package even your personal collection of handy scripts (and so the system does not develop funny-looking mold and bits of mystery food all over the place), I don’t really see the point. Just don’t update it when you’re on a deadline.
You can see that my arguments here are to a great extent a matter of preference and personal circumstances, though: do you have a reliable Internet connection for troubleshooting? do you prefer a more solid system that you have to fight and that fails badly but rarely or a less solid one that fails more often but in small ways? does getting locked out of the graphical environment every couple of years count as small?
(Offer not applicable on machines with cursed hardware like nVidia or Broadcom.)
the other subtlety is that security updates come later to testing than they do to either stable or sid, but this can be mitigated: https://gist.github.com/khimaros/21db936fa7885360f7bfe7f116b...
Debian or Fedora should become the new default recommendation. Debian probably fits better for novices, since Fedora doesn't have non-free packages out of the box.
Even from day one, forking Debian and breaking a bunch of packages as they went off on their own, then years later going oops how do we fix this Daddy Debian? Adding Amazon to their search by default in Unity initially. Creating a new desktop protocol to replace X11 rather than work with the Wayland teams so they could rush to ship their phone that nobody wanted.
Canonical is just a good marketing company. They want to do things their way and screw over as many Linux developers as they can to get their way.
For work, keep in mind that Fedora defaults to SELinux and a firewall. That's is a huge bonus when approaching IT about a switch.
But, unless I'm missing something about latest or future releases, isn't it still optional? Can't you use apt instead and uninstall snapd altogether?
I'd agree that needing to uninstall instead of opt-in is an annoyance, and that user-hostile actions tend to be a slippery slope..
There seem to be more and more things that are only delivered as snaps.
I haven't used Ubuntu on the desktop in a while (and even then, it was just trying it out), but I remember that trying to apt install <something> would say "use the snap". I think LXD is in that case, for example.
I'm on Ubuntu, and of all the software I use (I count around 20 programs installed not through the Ubuntu apt repositories), fortunately only two are available only on snaps - Chromium and Subsync. The first actually accelerated my move to Firefox.
Regarding Subsync, I had to write a ridicolous script to start/stop all the snap services - ridicolous because Snap has an integrity service that overwrites any change to the Snap system (!!), so one can't even hack the Snap system files without disabling such service. It actually gets worse - Ubuntu has a relatively tight intergration with snap: one can't have the `snapd` serviced disabled (without hacks), because the Ubuntu software upgrade invokes it if present, and if it's disabled, the upgrade will hang.
If Ubuntu will force more software to go through Snap, I'll abandon it (after many, many years).
For VSCode I managed to download a deb from their site IIRC, but from apt it only suggests to download from snap.
VScode wasn't as bad, as it usually seemed to work (but maybe flaky plugins were actually caused by snap?) but it was certainly annoying to lose the ability to switch between windows of the same app (alt+~, I think this was a custom setting to resemble mac) if the latest window/project was opened as a new version of the app (alt+tab)
Every other day it blows away all my open tabs and whatever I had going on in them.
I have a bunch of random tabs open, some with essentially "unsaved work", like shopping carts which may be the result of an hour of research, editing files in web interfaces like github or fluidd (web interface to a 3d printer) ... and randomly once every day or 3, I'll go to touch anything, any button in any of those tabs, like edit that config file some more, or try to save it... and kablooey, "firefox needs to restart" and I lose everything I had going.
This is a new thing that didn't used to happen.
Apparently the snap teams response to this story would be "Don't use FF like that."
The issue here is that the apt update changes firefox program files underneath it which needs a restart. Afaik, using the mozilla release directly is the only solution for this where the program files are changed only after exit.
Edit: This has become more common nowadays due to multiple point releases close to each other, to fix some important bug.
Maybe not what you want exactly but there are controls and claiming otherwise is misleading.
https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...
If you create a set of policies that users can choose from, you have limited your usefulness to just those cases that fit in those policies that you have implemented.
If you choose a single policy for everyone, only people who are willing to use that policy will use your system.
These patterns repeat across operating systems, services and applications.
It used to be a community focused distro. This bs feels outright user-hostile.
Which is really the largest drawback by far that I've found. GNOME 4 is user-hostile garbage made by people who really really wish they were designing for tablets. It's practically useless without third-party extensions, which are of course unsupported. It doesn't even have a system tray FFS.
If Fedora Kinoite worked as well as Fedora Silverblue, I think I could be reasonably content. Immutable base system with Flatpak and Toolboxes is pretty close to how I actually want a system to work.
Things like hiDPI support go funny, but that's just Linux for you.
But while we're on the topic of user hostility, I'm not really a fan of some of the changes the Gnome devs are doing either, so I may switch again in the future but at least for now I'm comfortable using it and they aren't outright antagonizing my system like Ubuntu does with snaps.
All four times was an exercise in a lot of googling, hacking configurations,etc. Sadly it was always too much work and I eventually gave up.
Hopefully one day the experience is seamless and I never have to go back to Ubuntu.
For example I just installed Fedora 35, I will probably install 36 at some point after 37 comes out, and stay one release behind current. Major upgrades are still relatively safe because of FS snapshots. I just personally prefer a slightly slower pace than “bleeding edge all the time”.
For a server I would just put Alma/Rocky Linux on it.
Also, in general the upgrades are quite reliable. I have a few systems that have been upgraded in-place for years without any issues (regardless of snapshots, since they're using ext4).
Snap and flatpak are massive compared to "traditional" packages.
Over distro repos - no dependency version hell.
I don’t really love snap/flatpak (too much “magic”, hard to tweak installs) but I see why they get used.
- Cross-distro packaging (no need to provide N package formats - this one runs on all distros)
- Faster update cycle for each app, if the package is maintained by the original developers
- Sandboxing
- Better compatibility all around, as the package runs the same on all distros (as opposed to some too-old or too-new module breaking something on X distro)
- Some other goodies, like checking new releases of the source on Github etc
Flatpak's drawbacks:
- Modules are not shared, which can result in somewhat larger packages and potential vulnerabilities
- Many packages are community-maintained by people who are not necessarily experts in the Linux ecosystem. Distro-provided packages usually have tighter requirements
Personally, I use Flatpaks for the sandbox. I restrict all apps very heavily.
I wish this were the case, but as a Flatpak user on Guix System I don’t think it’s entirely true. Flatpak apps still do seem to rely on some bits of the system, and they break in interesting ways when they aren’t where the app is expecting them to be.
As for Flatpak, I'd say use it if you need a more up-to-date version of a piece of desktop software than is in your distro's repository or desktop software that isn't in your distro's repository at all.
For example, I use the Firefox flatpak on Fedora to have the most up-to-date version (98.0.2) since the current version of Firefox on Fedora (98.0.0) was giving me some issues like crashing when downloading something and choppy gifs.
I also use it for some proprietary software like Spotify and a game called Vintage Story. Adjusting their sandbox permissions with Flatseal is useful in this case.
In practice for many apps the security protection is non-existent or very limited for compatibility reasons. So for now the benefits is indeed mostly a store model and auto updates.
If one really needs to run an untrusted app a VM is probably the only practical way. It is also possible to run apps in various containers, but truly secure setup is rather nontrivial with those.
I use it for Spotify, Zoom, Slack among others.
Installing and updating Flatpak apps for proprietary software works very well.
Also updating the system shouldn't accidentally break the application you use either. On rolling release distros this can be a pain. You'd typically want the application that the application developer tested properly (as opposed to relying on your package manager's "testing"). The packagers can introduce bugs while repackaging an application for X distro. My Cura was broken for so long on Arch linux that i gave up and started using their AppImages instead.
Depending on your distro, you also have to deal with headaches like XYZ software is only available on Ubuntu 20.04. Tough luck that you are running 18.04 on your laptops. (last week i had to deal with this problem with clang)
In addition to being self contained with all the dependencies, these solutions offer some level of sandboxing too.
On Arch, AUR usually does a nice job of packaging binary only applications, so i rarely need to use flatpack/snap/appimages but on other distros that can be a pain.
There have been a lot of 'universal package' standards over the years, and honestly Flatpak isn't the best one, but it is the one that the community finally seems willing to adopt to a degree that actually makes it worthwhile. Snap, however, is the worst of these formats, and by a wide margin, that I can recall ever existing. It's amazingly bad and extremely user-hostile.
- they are always up to date and therefore statistically more likely to have security holes fixed
- that are (to an extent) sandboxed by default and give you a lot of control over that.
- for developers it's much easier than maintaining hundreds of fixes for different distro peculiarities. Therefore (for the user) they are able to spend more time on the app itself rather than compatibility
https://ludocode.com/blog/flatpak-is-not-the-future
Maybe it is better than snap, but it's not good and its not better than a traditional package, on either philosophical or technical grounds.
I like snaps, I use them for everything I can.
- They are better confined than flatpaks, and come with a permission based model. Hence why there are some rougher edges. I appreciate the increased security.
- I appreciate the ability that when I remove a snap, the entire thing is removed with no littering.
- They are significantly easier to distribute on ubuntu than dealing with ppas or launchpad.
- They are a one-stop shop for finding the software I care about. I don't need to hit the command line, or add another repo.
- They save time and money because devs only need to support 1 base.
- I can install software on ubuntu without giving root privileges in a self-contained fashion.
Some common complains:
- The store isn't open sourced. Well yes, that is because they wasted time from the same whiny people over launchpad. Nobody else runs and supports launchpad. Hence nobody else would frankly bother running the snap store.
- People can't run their own store. Well yes, that is because Canonical learned from a decade ago with the security nightmare that is PPAs. Yea, it is a bad idea giving devs root access to 100k worth of machines to run arbitrary scripts. Also really bad UX.
-It's slow to startup with theming issues. Well the situation has improved 100x since a few years ago, and also I run an ssd, 32gb of RAM and a 3600, I don't really care for a few seconds in launch time.
The last half year or so went ok, but not being able to stop automatic upgrades is ridiculous. In general I like opinionated software, but sometimes it goes to far.
If you try to talk about how Linux distributions don’t like it, they’ll just say, “but Snap is available on all the distributions” or some crap cop-out.
I had a long forum thread about all the issues people are complaining about half a decade ago. They wouldn’t budge, and still won’t budge.
Snaps reduce reduce their maintenance burdens, and they have the stats themselves for how popular they are. They are by and far more used than flatpaks from what I remember from the video by Martin Wimpress.
Oh and they have third party buy-in from software vendors like Mozilla, Microsoft, VLC, JetBrains, Spotify, slack etc...
Why would they budge?
Vendor interest they have, community interest they lack. And if it continues, lack of community interest will result in a lack of vendor interest.
You see the map at the bottom with a list of OSes?
They have the interest, commercial and from the populace. Vendors have already integrated it into their pipelines.
What they don't have is the vocal minority. Frankly I don't get why people care so much, if you don't like it switch to something else. No need to whine about it online. They aren't preventing you from using flatpak.
> Frankly I don't get why people care so much, if you don't like it switch to something else. No need to whine about it online. They aren't preventing you from using flatpak.
Then, in that case, by that logic, there’s no reason for you to whine about my whining.
A dev at Canonical can absolutely see how many install counts are there and if the venture is worth it.
>no explanation on what the lengths actually mean.
>Then, in that case, by that logic, there’s no reason for you to whine about my whining.
They don't care what you say, they don't care about the whining here. You aren't paying to support it either.
Feel free to switch to another packaging solution, or even a new OS. It won't affect Canonical's bottom line.
They very much do not care about the end-user with Snap, only how to appear attractive to potential customers.
Of course, compared with other platforms and auto updates, it is clear why app developers prefer and expect to be in charge of updates.
We don't have ~/ssh or ~/dconf do we? We've had the XDG spec for decades now - this selfish decision makes me so irrationally angry that it's the one reason I'd switch to Fedora to avoid snaps.
https://snapcraft.io/docs/home-outside-home
> The snap daemon (snapd) requires a user’s home directory ($HOME) to be located under /home on the local filesystem. This requirement cannot currently be changed.
I've tended to use every second LTS release, replacing with new (cloud) servers during the overlap in support periods. I use Ansible to configure.
Should I be considering Rocky or straight Debian instead? Something else?
>@Romario74 That is not the case; while on Snap they packaged v77, if you look here you will find that the Spotify devs have not been updating the .deb releases. Re-packaging Snaps is less convenient than using a .deb tarball, and is being done through scripts by this Github project, which is in turn repackaged by @Edu4rdSHL.
https://aur.archlinux.org/packages/spotify
So i run snapd on system
sudo apt purge snapdI haven't verified that, but considering that nothing suggested that I was installing a snap app (other than me not paying attention to apt's output, I guess), I'm not sure if that's even possible. I was planning to stay with 18.04 LTS and then move to something else, but seems like either snap was there already or it has been added after I upgraded.
I feel like I've never seen anybody actually like snap.
The point is that you are the mercy of the snap publisher, and as the sysadmin, you cannot prevent the software from updating. Whether you should or not do that is a different debate.
You'd expect that publishers follow the same process, that a stable channel means it's really stable, whereas version breaking changes really end up in per version channel. Ideally you have the latest/{stable,beta,candidate,edge} which follows the latest version of the software, and eg. v1/{stable,beta,candidate,edge}, v2/{stable,beta,candidate,edge}, v3/{stable,beta,candidate,edge} for individual version. A simple concept but surprisingly hard to follow.
Maybe the publishers are really lazy and don't care about the users or the maintenance cost of keeping n versions around is just too high, in which case it's up to the users to make their effort worth it.
The point is that people want to be able to disable automatic updates, even minor ones, and that's not possible.
edit: I can see how my previous comment could have been confusing. To clear it up, I was trying to say that a workaround for the forced updates would be for vendors to publish a "single version channel". So version 1.2.3 would be a dedicated channel, with no updates ever. Version 1.2.4 would be a separate channel, with only that single version. This would of course be impractical, for both the vendor and the user.
More about how snap channels work here. https://ubuntu.com/blog/controlling-snap-releases-with-chann...
I’m sorry, who owns the machine here?
To offset this, two channels of releases can be maintained - one for security fixes, another for general features etc. But again here, we run into problems where maintenance of two channels isn't economical, and you end up testing security fixes on various versions.
How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?
There is an easy way to solve this problem. Default to auto updates, allow people to turn it off, by acknowledging what that means. Most users use whatever is the default anyways. Vendors gets to push their updates, users who don't want those, can reject them. If someone gets hacked because they turned off auto update, the vendor won't be on the hook for it, because the user said they were aware of it when they turned it off.
I think the core problem here is not that people are asking for auto updates to be off by default, they simply want to have the option. And frankly, for professional use cases, you have to be able to turn off auto updates, as otherwise it'll harm the workflow as you can't control when the update happens.
I totally agree your average end user is poor at managing updates themselves and thus it is justified to enable auto-updates by default. What that does not justify is totally removing the ability to turn them off. Feel free to make it a little harder to disable: the user has to run a CLI command or something, but the option should be there.
> How can these be addressed if upgrades are not forced, are there standard processes followed that provide the best compromise for both vendors and end users?
If you go through the extra effort to disable updates and don't grab a security fix, that's on you. How is "you have to do exactly what I tell you - wait why is nobody using my software?????" a best compromise for users? What are users expected to do when an upgrade breaks something and they can't downgrade?
sounds like a user problem
"x ProductX users impacted by Ransomware" will make headlines, your "well yes, we fixed it in v2.7.8 months back" won't.