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.
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.
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.
For VSCode I managed to download a deb from their site IIRC, but from apt it only suggests to download from snap.
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--...
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.
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.
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.
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.
Snap and flatpak are massive compared to "traditional" packages.
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.
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.
- 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.
I use it for Spotify, Zoom, Slack among others.
Installing and updating Flatpak apps for proprietary software works very well.
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.
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.
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.
- 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?
They very much do not care about the end-user with Snap, only how to appear attractive to potential customers.
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.
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.
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?
I feel like I've never seen anybody actually like snap.
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?
