As part of our combined efforts, the Ubuntu flavors have made a joint decision to adjust some of the default packages on Ubuntu: Going forward, the Flatpak package as well as the packages to integrate Flatpak into the respective software center will no longer be installed by default in the next release due in April 2023, Lunar Lobster. Users who have used Flatpak will not be affected on upgrade, as flavors are including a special migration that takes this into account. Those who haven’t interacted with Flatpak will be presented with software from the Ubuntu repositories and the Snap Store.
We think this will improve the out-of-the-box Ubuntu experience for new users while respecting how existing users personalize their own experiences. However, we don’t want this to come as a surprise. If you have comments specific to this change you are welcome to respond here on discourse.
Canonical’s got Snap to peddle, so FlatPak is a competitor. That’s all there’s to it. I maintain they’re all bad and unnecessary – a .deb, an .rpm, and your source code is all you need to cover 99.9% of Linux users in a standard, easy-to-use, uncompromising way.
I guess I’m old school. I prefer .deb files as well. However, the Steam Deck, with a rolling read-only OS core and solid FlatPak integration, is at least showing me why I might care about this newfangled way of distributing software.
I haven’t taken the time to look at the technical merits of FlatPak vs Snap, but I do notice the performance hit on Firefox’s Snap in 22.04 and find the junk showing up every time I run “df -h” on newer Ubuntu releases to be annoying. I do not see such annoyances with FlatPaks on the Steam Deck, which is reason enough for me to prefer FlatPak to Snap.
Are any other major distributions using Snaps? Is this like Mir vs Wayland and Canonical is backing the wrong project again?
That’s because snaps are distributed as stacks of compressed filesystem images layered together using overlay filesystems, which means you’re paying the decompression cost every time you launch them and Canonical keeps trumpeting “fixes” which are more or less just switching to algorithms with higher decompression throughput or helping big-name packages like Firefox to restructure themselves to need to download fewer optional components (e.g. localizations).
Flatpak instead decompresses as part of installation and uses a web of hardlinks to deduplicate files across different packages based on their hashes… something snaps can only do by manually providing more ability for package authors to separate dependencies out into separate compressed filesystems that can be shared between multiple packages.
(If you want compression rather than just deduplication, Flatpak leaves that to the underlying filesystem to provide.)
Yeah. That’s just shoddy workmanship. Flatpak also uses a bunch of mount hackery, but they make proper use of cgroups to set up a separate mount scope so you only see them if you use something like
flatpak enter <AppID>orflatpak run --command=sh <AppID>to look at what the application sees from inside the container.Canonical helped port it to various distros, but there are flaws in it they didn’t finish resolving (eg. I think I heard that it has security issues without AppArmor, similar to how Binder is not secure without Android’s SELinux rules.) and it immediately started to languish.
…and yes, it is like Mir vs. Wayland. Pretty much everyone else is throwing in with Flatpak (which began as xdg-app, a product of the same Freedesktop.org collaboration that produced things like D-Bus and xdg-open) and, if they want something for immutable system packages, OSTree. (Flatpak is a containerization layer on top of OSTree to allow distro-agnostic application packages with shared dependencies.)
Here are some other reasons to prefer Flatpak. Last I checked…
1. The Snap client has no facility for disabling or delaying automatic updates. Flatpak treats updating the same way something like APT does and, if you use the integration plugin for something like KDE Discover, it’s just blended into your usual update workflow.
2. The Snap client is coded to assume a single upstream package repository with no provisions for adding more and provided builds are hard-coded to use the Snap store. Flatpak’s
flatpak remote-addsubcommand is demonstrated as part of the three-minute setup instructions on Flathub.3. The Snap Store is proprietary. Flathub has a link to the repository for its source code in the footer of every page and the README for the repo in question has quick instructions for installing it yourself.
Snap argues their ability to also install system components is an advantage over Flatpak but, first, that’s just code for “we knocked off OSTree and Flatpak but didn’t use a cleanly factored architecture with well-separated porcelain and plumbing” and, second, that reintroduces the same problems that killed Linux Standard Base. (It’s the containerization that allows for successful cross-distro packages.)
Thank you for taking the time for this reply. It was very helpful and confirmed many of my suspicions.
Much appreciated.
I don’t have many objections in case of games, or other 3rd party software (which used to land in /opt directory). However
1) Firefox snap is a bridge too far in my opinion. Browsers are still part of the common desktop. These should be reserved for stuff that are not traditionally aligned with OS releases.
2) They pollute the kernel namespaces a lot. Want to check mount points? There are not tens of additional ones which don’t make useful sense. This is of course a tooling issue, and might be “fixed” with reverse grep. But, we need better integration, so they are ignored by default.
1) I actually find browsers one of the best things to Flatpak, because I can add an extra layer of isolation onto one of the most unavoidable places to be running untrusted code downloaded off the network without prompting (eg. It’d theoretically be a good protection against stuff like this once Wayland is mature enough to close that final hole for me) and they can receive updates direct from upstream for faster updates. (eg. both the Snap Store and Flathub have official Mozilla-made packages for Firefox)
2) I’ve got eleven Flatpak’d applications running right now, including the copy of Firefox I’m posting this from, and not one of them has its internal mountpoints showing up in my
mountoutput because Flatpak uses cgroups properly.If I run
mount, I get 46 lines which are mostly the usual/sys/...stuff but also things like my six partitions across five physical hard drives and an sshfs mount or two.If I run
flatpak enter org.mozilla.firefox bashand runcat /proc/mountin that shell to work around themountcommand being absent from the relevant Flatpak runtime to save space, I get 119 lines, mostly down to how Flatpak uses bind mounts to very finely control what stuff under/etcgets mapped in from the host system but also a dozen or so fine-grained grants I added using Flatseal because I like to keep my sandboxes locked down but, due to there not yet being a portal to allow Firefox to load or savefoo_filesor other sibling subresources when givenfoo.htmlvia portal, I still need to grant it at least read-only access to certain places.1) Interesting point. Browsers already have their sandboxes, however yes additional security would not hurt. But then, there is also the Qubes OS way, and running the browser in a VM + no network access (only Tor based routing). Maybe keeping this an option for those who want tight integration vs a bit more security might be a good compromise.
2) I think this depends on the setup / individual apps, but I still see that behavior occasionally. (I see EmuDeck on Steam Deck for example).
Again, this is something that is not a fundamental issue with flatpaks, and if they are improving cgroups to filter those out, it will soon be a non-issue.
My biggest issue with Snap vs the other container style distribution methods is that Canonical controls the Snap ecosystem completely, and they do so using a closed source server infrastructure[1][2]. It’s impossible to replicate the Snap system to run self-hosted, whereas with Flatpak you can do that fairly easily.
You can also look into AppImage, but it lacks one important feature of Snap and Flatpak: it doesn’t sandbox the package. It’s simply a self-contained executable archive similar to how macOS apps are distributed.
[1] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/
[2] https://www.techrepublic.com/article/why-canonical-views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/
And I maintain that Flatpak’s growing popularity is the general user base voting with their feet that it’s not enough, similar to how systemd may have its shortcomings, but it won out because it solves real problems that sysvinit proponents refuse to acknowledge as legitimate or meriting solutions.
Archlinux and its derivatives aren’t exactly niche choices and don’t use RPMs or Debs. Not all Debian-family distros and versions can be supported reliably by a single .deb without doing what Flatpak does (overlaying an alternative dependency tree). Likewise for RHEL vs. Fedora vs. openSUSE vs. …
Not everyone knows how to (or should have to know how to) compile things from source (possibly including dependencies) without mucking up their installed system.
You’re essentially arguing for rule by the elites as far as choosing who gets access to what software because, if the provided packages don’t work and the distro hasn’t packaged it, users are left begging some power user to please please please deign to help them. (And doesn’t that say something itself that “power user” on Linux tends to include “knows how to build things from source”.)
I am not against newer distribution methods, but there are too many issues with the new ones. The containerization especially, when it doesn’t cause performance issues, breaks all our traditional expectations for where to find files. snaps still can’t see files outside your home directory and they’ll probably never change that. it’s not obvious where certain files go for flatpaks. For instance the bottles flatpak I tried not long ago didn’t have the correct instructions for where to put the Windows EXE, and it wound up hanging the whole OS (!) if it wasn’t there: https://github.com/bottlesdevs/Bottles/issues/1051 (in the related issue I wrote that I compiled Bottles myself from git and did not have the problem, so the lockup issue came about from using the flatpak, but who knows how that’s even possible)
I think probably AppImage is the one I’ve seen that’s most successful, I’ve used it for both 86Box and Audacious and it’s worked pretty well, though I wish there was an easier way to integrate them into my system. If a newer distribution method comes along that is transparent and better than existing distribution packaging, we’ll all be for it. But the new methods have real disadvantages, similar to how Wayland desktops aren’t feature complete with Xorg and there are real use cases that aren’t covered yet.
Greatquux its a sandbox issue caused by cgroups mount restrictitons. But if you have a drive set noexec same level disaster happens wine does not handle the case of application being on a drive that does not have permission to be mapped to executable pages.
AppImage sandbox options can cause this as well. Greatuux there is the isolate option with AppImage that enabled sandbox around applications as well yes this can bring out all the issues flatpak sandbox has.
Lot of applications are not designed to deal well with the case of a sandbox saying no you cannot access that or no this file cannot have its pages set executable. Flatpak application sandbox application causing system to be locked up/hung that is a bug with both flatpak and the application. Lots of cases the applications go and do stacks of stupid thing including never ending loops.
AppImage has a stack of cases where it does not work out for all users.
https://github.com/openscad/openscad/issues/3625
Just you have not found them yet.
Greatquux the fact you cannot do incorrect usage and have it fail safely that a bug. Bottles complied yourself was not in a sandbox. Flatpak failures in lots of cases is just showing the application has poor handling of the sandbox case.
Flatpaks with
filesystem=hostcan see everything that’s not on a built-in blacklist, though the host/usrand/etchave to be accessed through/var/run/hostto avoid interfering with the container-provided versions.It’s simple to reconfigure the manifest-defined sandbox permissions using either the
flatpak overrideCLI subcommand or the Flatseal GUI.In fact, I came to Flatpak in large part for that because it’s less of a papercut-squashing hassle than wrapping APT-installed packages using Firejail.
Packaging guidelines say to map anything that would normally go into dotfiles/dotdirs under
$HOMEunder the~/.var/apt/the.id.for.the.Appdirectory that’s provided for each package. (And which are mutually sandboxed even when you usefilesystem=host, so an application can only see its own one of them.)Anything which obeys the environment variables for relocating
~/.config,~/.local/share, and~/.cachewill automatically have them moved in there with no effort.Beyond that, packagers who really care about doing it right are doing things like using the
directoryoption in the file chooser portal so that you can install an application like a game engine re-implementation, it’ll present a desktop-native directory picker for the “please point me to your game assets” (possibly using a wrapper script and Zenity), and then that directory will be permanently mounted into the sandbox as a path under/run/user/[Your UID]/docthat then gets returned to the application.Aside from seeing the
/run/user/[Your UID]/docpath if the application shows the previously selected path in an un-privileged UI, you don’t even notice the difference and it Just Works™.Then your OS has a bug that needs to be fixed. It’s not as if I blamed aMule because my ATI Rage 128 drivers would bluescreen within minutes of launching it back before I switched to Linux where the open-source drivers were rock-solid.
Flatpaks really do help the entire Linux community.
They allow work to be reused across many distros. One person packaging an application can cover Endeavor, Elementary, Void, Gentoo, Alpine, and many more. They even help Fedora. I can remember when many desktop applications from companies were Ubuntu only deb files. Very few companies supported Fedora at one time, and Fedora has RH behind it. A little community distro has no chance at getting tier 1 company support.
They help companies port software to Linux desktops. The companies only have to learn one thing instead of X million Linux distro specific packaging guidelines.
As a Linux desktop user, I’m very happy I’m not stuck with one distro because of application support. I’ve been playing around with Gentoo lately, and I might test drive a Gentoo based desktop for a little bit. 🙂
” a .deb, an .rpm, and your source code is all you need to cover 99.9% of Linux users”
And then you start getting into the stories of “I accidentally destroyed my entire system by running a command to remove app x”, with the helpful advice from the Linux community that “they just should have looked into what every package they were removing did”, or “been suspicious about the fact the package manager reported 1000 packages to be removed”. Once again I say these package manager systems introduce far more problems than they solve. Flatpak/Snap/Docker/Etc. are at least attempts to solve those problems, but I notice a fair amount of times when they break, thus breaking all app packages for them on the user’s system.
Title feels poorly worded? They’re removing Flatpak from the default installations, not removing it from the repos or breaking compatibility with it (which would be really scummy and shortsighted).
This does diminish Ubuntu a bit as far as my personal distro preferences, but it wasn’t very high on that list to begin with.
Re: Flatpak. There are a number of advantages – sandboxing nosy proprietary apps like Discord, allowing proprietary or other finicky apps to use the specific library versions they need, standardizing installation of Electron apps (which suck but are a thing we have to deal with) across any distro that supports Flatpak. Providing a standardized way to distribute proprietary software independent of system libraries. Providing current versions of important software, with current libraries, on enterprise distros that try to limit changes to system software. I could go on a while; suffice to say that Flatpak is one of the things that keeps Linux being a viable desktop OS for me, and I use it and its features on a daily basis.
Unfortunately IMO the same doesn’t apply for Snap, because it is both more centralized and has a less well administered and curated repo than e.g. Flathub.
Is this some kind of joke? Traditional .deb and .rpm has the obvious problem of new versions of -say- VLC not working even on current LTS versions, and the fact you have to wait for some repository maintainer to “repackage” the app for you before your distro before you can have it. Meanwhile, even something like Windows 7 can install the latest VLC from the software vendor’s official website, no need to wait for anyone to “repackage” it for you. And then there is the fact Deb and RPM is not suitable for proprietary software unless you want to download an external rpm or deb and take the risk of having to resolve the possible dependency hell yourself.
Meanwhile, no other OS has this problem. Apps on other OSes are shipped either as self-contained installers (.sh or .exe) or self-contained packages like APK on Android.
Deb and RPM is what you get when you let idiots obsessed with efficiency run amok and who are supervised by maliciously compliant FOSS zealots who see the whole “repository” structure as a way to covertly sabotage proprietary software on Desktop Linux.
I’ve worked with proprietary Linux software, and it was fine. The devs were smart enough to not replace files in base.
They even supplied a RPM repo!
They have the same problem. Most software on other OSes ships an entire dependency tree per application to get around the problem, which is also what proprietary Linux software does.
Naw. It’s what happens when people build package managers for C and C++. Linux distros are platforms for C and C++ software more then anything. Contrast this with Nix which is what happens when people decide an OS should include it’s own build system.
It doesn’t seem to be much of a deterrent. (I’ll also vehemently argue, RMS and most of the open source crowd are strong capitalists.) The number of Linux distros being greater then 1 is the biggest detriment to desktop Linux. Companies don’t want to do any work.
* for you before your distro before you can have it = for you before your distro and version combination you can have it (sorry)
As far as i know there is close to zero chance Fedora and its spins to allow snapd by default. On top of that there is close to zero chance Ubuntu or Fedora to allow AppImage integration daemon by default. So i am not taking sides here. As far as snap or flatpak apps go. They are rather useful for installing proprietary apps. Hence the industry will decide the winner. If there will be one.
“snapd” is in the official Fedora repos, and if something is in the official repos, legal has cleared it. If someone wanted to create a Fedbuntu spin, they could. You know, to show Canonical how much better Ubuntu could be if they switched to Fedora from Debian. 🙂
OpenSUSE is the only distro that packages appimaged.
There is an entry about AppImage in the Fedora wiki though. It talks about how to work with them, and gives a link to the AppImage hub.
https://fedoraproject.org/wiki/AppImage
This are not defaults. And good luck in convincing Ubuntu/Fedora to include competing packaging solution by default. The chance is close to zero. On all mentioned distributions end users can install or use them manually after. Ubuntu here really shouldn’t be the only one to blame. For stating the obvious. Fedora is just as bad in this regard. Historically speaking. Lets not forget that the chance for one of them to drop .deb/.rpm packages. And for the unified “traditional” packaging solution to be used instead. That chance is close to zero. True that you would still need to build the package for every distribution out there. But at least the procedure would be unified and standardized. Compared to now where you should learn 10 different packaging standards for being able to deploy a todo app. Imagine if Linus would made git in a way you would need to learn 10 different ways to push your code. So instead of “Fedbuntu” hopefully popular GNU/Linux distributions will use unified solution and package manager for “traditional” packages in the future. That would be something. The chance being close to zero. So you can perceive this whole Snap/Flatpak debate as continuation of .deb/.rpm. This was never solved. And it doesn’t look like it will be anytime soon.
Interesting, I tried snapd on fedora back when canonical provided the rpms for it. And oh man it was terrible. It had zero understanding of selinux.
So sure, you could run snaps on fedora if
1) You turned of selinux and hate secure systems.
2) You are a selinux guru and love making wise policy decisions for every package you install, and Love doing it every time the snap updates itself.
I am pretty sure that we could have long discussions about things like security. Only to find out both snap and flatpak are rather lacking in this area. Regardless of the PR. Then we could nitpick about some technical aspects of it. Just like i am sure was/is done when debating deb vs rpm. On why we surely need both. In the end at least we can say that one can run GIMP if packed as deb/rpm/snap/flatpak. And now obvisuly if you are on Ubuntu you should use deb/snap and on Fedora rpm/flatpak. As this two camps are so so smart and great. That we should praise them by taking sides. For gimps that they and we all are. Long story short i am sure that you can run GIMP on Fedora or Ubuntu using both snap or flatpak.
I don’t particularly mind this as the actual flatpak tools will still be available. They’re just removing the unified software center experience. I personally found the integration of even just snaps into the software center a pain. You will have multiple versions of the same app (deb, snap, flatpak…) in the same software center confusing people.
I’m sure there’s a lot of just trying to push SNAPs, but as just a user I don’t even like the current integration with Snap.
I know this is an imperfect example, but to me trying to mix all these stores into one ‘store’ would be like Microsoft app store trying to have steam store and EA store all mixed in with it’s store. Maybe it sounds like a good unified idea, but the experience will overly complicate things and just make it annoying.
I have the same view of the command line tool adjustments they’ve made. Like using apt to install say firefox will actually go to the SNAP store. This to me is a complicated ‘convenience’ to hide something that isn’t that complicated.
I find it much simpler to just have different interfaces for each ‘store’ on both the GUI and the command line. At most, maybe have a note that a certain package is available in another ‘store’.
Personally I’ve defaulted to using flatpaks, but I keep the default Ubuntu snaps and some packages that there are not flatpaks for. My main reason is just the file system mount points annoyance. Beyond that, I don’t really care and speed is ‘good enough’ for me on SNAPs. I don’t know why they don’t give the option to simply not use compression for either snap hosts or on the client end.
Because that would require writing extra code so the client can deconstruct and rebuild the compressed filesystem images (SquashFS?) that they distribute… sort of like how nVidia binary drivers involve a bunch of infrastructure to install GCC and run it automatically to build the nVidia “GPL condom” when you update your precompiled kernel.
Snaps are similar to compressed DMGs on macOS in that respect, except you don’t drag-and-drop the application out of them to make the decompression only happen at install time.