The problem as I can see it is that the "solutions" don't really work either. Here's your options, in order of viability:
- AppImage. Basically the idea of "Apps" ripped straight out of MacOS and injected right into Linux. Works fine, but clutters your home directory with Another Folder and doesn't integrate with your desktop like a native package.
- Snap. Works on any system that can install snapd, is owned by Canonical (a pro or a con depending on who you ask), but also auto-updates and has occasional performance problems. Plus, snapd is generally kinda fussy.
- Flatpak. Sandboxing taken to it's (il)logical extremes. If you like random data loss, confusing package manifests, low-performance and generally broken software, this is the way to go. Of course, most people like it when their compositor doesn't break when installing third-party programs, so they avoid it like the plauge. It's a uniquely bad format, almost worth spinning up a Linux VM to try it for a laugh. Just make sure to use GNOME, it's useless anywhere else. That's the true hallmark of a cross-distro packaging solution!
So yeah, we're probably due in for Another Competing Standard. At this point though, I think most developers are contented to just ship an RPM and an Arch package and let everyone else figure stuff out for themselves. Honestly, I prefer that approach when compared to the blasted wasteland that is cross-distro package management.
As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything).
For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former two candidates. It tries to complement package systems for some special cases (like for example commercial software, or for the cases where the user "just wants to try something out" without "polluting" the whole system with a lot of dependencies).
For my desktop needs AppImage is like "Docker, the good parts". A simple self contained format that runs everywhere without any further dependencies. Compared to that Snap and FlatPak are bloated annoyances.
And even AppImage, a solution I frequently praise mind you, doesn't always work right.
It's 2018 and the Linux Desktop still doesn't have a consistent way to... well do anything now that I think about it, but that you can't even reliably distribute an application is pretty insane.
Flatpak and Snaps are a typical Linux Desktop solution: Over-engineer the shit out of it.
It seems that Flatpak, Snap and AppImage are the present and future of packages that work on multiple distros. There are no other new alternatives in the article.
I get the idea behind snap, flatpak, and appimage. But what I don't like is:
1.) config file locations end up all over the place depending on which you use. I like taking my .thunderbird data and just dropping it from one system to the next as one example. Snap makes that harder. Likewise for firefox - the snap version is behind as well.
2.) It solves a problem already long since solved in linux systems - package management. You still need APT or what ever the distro is built with. Two systems solving the same problem often seems like one cook too many. Hell even homebrew in macos is a pain.
Well the problem of Snaps is complex sandbox, lack of user control, forced updates and so on which is disliked on many non-Ubuntu distributions.
Flatpack attempts to solve the dependency hell problem by providing standard runtime, a set of libraries, Glib-C, Gtk or Qt with a fixed version which requires the developer to build an application linking against those runtime, which avoid binary compatibility problems and dependency hell. The trouble of Flatpacks is the integration with the desktop.
AppImage attempts to solve the dependency hell by bundling everything into a single launcher executable with a SquashFs file system image payload. The disadvantage of this approach is that it is only possible to use a single executable. AppImage are also not free from GlibC compatibility issues.
A MacOSx-like app bundle and a changing in Linux development culture to build and design applications as self-contained from inception would strength the Linux desktop and reduce the application packaging work duplication that still affects Linux distributions.
maybe it's indeed time to let the system package management(apt,rpm,etc) just manage a solid BASE system, and let Flatpak etc to manage their own application sandboxes on top, kind of like dockers.
Appimage is macos flavor, it never needs your sudo to install the package, which is nice.
Flatpak is a redhat flavor(kind of), it needs sudo sometimes, but OK.
Snap is a ubuntu flavor(kind of), it is like systemd that can overtake the whole system, it can install package and even the whole system I was told, too much as a package manager for me.
I don't use Snap. Appimage is not as widely adopted as the rest two? I think Flatpak is a great middle ground.
It will be really cool if KDE and Gnome work together to build this.
To me, Snap and Flatpak are less about security than they are about universal application distribution that doesn't rely on third party maintainers and is free of conflicts. There are much simpler ways to achieve that goal[0], but the fragmentary nature of the Linux Desktop community makes the necessary standardization all but impossible. Similar to your statement about security, I loathe the traditional package manager/repo model because it consistently makes software unavailable to me either because it is missing from the repo, isn't updated yet, isn't maintained at all, or has library conflicts. All of its supposed advantages are useless if I can't actually run software.
To that end, I've put my money on Flatpak. I have my issues with it, both in practice and in design, but it isn't as user-hostile as Snap and seems decently popular and growing.
[0] AppImage is a valiant attempt, but simple AppDirs before it were much simpler
I find AppImage files quite annoying, I must admit. I understand that it's annoying packaging for all the different Linux distros, but this doesn't feel like the solution. Maybe renaming them and dumping them in /usr/local/bin would make them integrate better with the OS, but I usually just avoid them.
Flatpak has been quite nice when I've used it, if a bit more awkward to figure out first time.
Snap is fine, but the actual publishing side of it I found quite confusing and arduous when I tried it, so from a developer point-of-view I would probably avoid it (unless it improved a lot in the last year).
The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support.
The old model works for established software, but breaks down a little now that it becomes easier to write software applications.
Personally I use my distro packages for foundational stuff (DE, systemd, tools and utilities) but I use an alternative package manager (flatpak) for most other applications.
What Flatpak, Snap and AppImage try to achieve is to limit the packaging burden for both distro maintainers and application developers, so that end-user applications can become immediately available on a wide variety of distros.
The Linux packaging ecosystem works extremely well for open-source software, and it produces a much leaner, more integrated system than bundling approaches like are common on macOS (and in a less extreme way, Windows).
There are two things that Snap and Flatpak are trying to 'fix':
1. The Unix security model, which relies on the user as a main boundary for security/policy. These tools are trying to add sandboxing that makes running untrusted software safer and accounts for the fact that being able to access everything in a user's home dir (and so on; this isn't just about the filesystem) is 'bad enough'.
2. The Linux packaging ecosystem (and whole userland, down to glibc's ABI policies) has never been intended to serve proprietary software developers/publishers/vendors who want to be able to throw their binaries over the wall or test only on an extremely limited range of library versions.
(AppImage only aims to 'fix' the latter, and poorly at that, since it doesn't even attempt to encapsulate huge parts of the runtime environment that vary from distro to distro.)
The only thing 'fragile and complicated' about Linux packaging itself is the practice of installing everything into a shared global namespace on the filesystem, which is already better addressed within the packaging infrastructure itself, as has been done on NixOS, GuixSD, GoboLinux, and Distri. (The latter two being more research projects than practical distros.) Those distros all prove that resource sharing and dynamic linking are actually red herrings when it comes to what is problematic about distributing software on Linux— you can keep both of those things and escape dependency hell forever (with or without containerization).
I take your point (it's the general point many use to argue for Snap/Flatpak/Nix/AppImage/0install/Homebrew/&c.) but if you want to ensure you're not replacing per-distro-package-manager-fragmentation with completely-arbitrary-chaotic-package-manager-fragmentation there needs to be some unity & consideration for what users want in order to ensure they'll willingly subscribe to your system of choice.
While I wouldn't call Flatpak "popular" with users per se, it's probably one of the least-worst alternatives that have come out. The horse Ubuntu has backed (Snap) may be the most used by virtue of being rammed down user's throats by projects with existing user capture (e.g. LetsEncrypt), but that's not going to make the debate go away: it just strengthen's the argument to return to distro packaging.
The goal is to be distro-agnostic, but I find that Flatpak and Snap both add more bloat than is worth it. Either just use distro packages, or, if you really want cross-platform, get an AppImage and be done with it.
Snaps are Canonical's choice for "cross distro" package management that they are trying to force on everyone else. They came out of nowhere and it doesn't play well with other distros.
If you want a nice-from-first-principals approach to package management for desktop apps, Flatpak is the shit: it uses a Git-like distribution system that's specifically built for operating system size snapshots. You get to pick your underlying distribution (or roll your own) and the sandboxing mechanism just wraps around secomp-bfp so it stacks well with SELinux or AppArmor or whatever.
But now we are going to have yet-another-bifurcation of OSS solutions: RPM vs DEB, KDE vs GNOME, Wayland vs Mir.
I'm going to vent a bit about this. My perspective is as someone who was a Windows user who moved to Linux 6 years ago after getting fed up with Microsoft.
I love the package managers on Linux distros. They are amazing. I feel physical pain whenever I have to jump through hoops to get software up and running outside of a package manager. That being said, I do a lot of hobby work on a Raspberry Pi 4. Not every package is built for arm64. Packages break, have issues with their dependencies, or fail cryptically for me. Building software from source for programs that do run on linux systems can be hit or miss. I understand I chose this with my specific platform of choice, and I have accepted this. But if I can support a solution that will make my life easier I will.
It's 2021 and we have Flatpak, Snap, and AppImage, and it's super frustrating. None of these tools solve the problem entirely and they all come with their own sets of drawbacks. That's okay it doesn't have to be perfect. But there are people who hate the entire concept of using these tools and will crap all over them every time they come up. They have valid criticism don't get me wrong, but in my opinion doing something and shipping it is better than doing nothing at all. I would love to see the solution to Snap, Flatpak and AppImage by I've yet to see anything from their biggest proponents. I just can't be bothered anymore wasting my energy listening to people who aren't actively trying to find solutions. If you are reading this and are working on a solution, I appreciate you.
So which to choose? I think based on Canonical's past and present behavior Snaps just have too much baggage for most people in the Linux community. This sucks as you have software packaged in Snaps from Microsoft, Nvidia, etc that aren't available as a Flatpak or AppImage.
AppImage has the blessing of Linus Torvalds, but if you say that aloud then you will have people say "So what?" as if Linus Torvalds is some just some guy. For better or for worse it means something when he supports things, and he does provide his software as an AppImage so take that for what you will.
Then there is Flatpak. If you look at Flatkill.org then the tool is just a pile of lies and security holes. With that being said my money is on either AppImage or Flatpak
The only reason I have been using Ubuntu is because it was the distro with the most installable software available.
I'm ok with default GNOME, I'm beyond cool desktop, I just want something that works. On the other hand I need to be able to install a large selection of software easily, and recent-ish versions of them (hence why not Debian). I also can't have things that upgrade themselves on their own schedule (kids in school with capped bandwidth).
Having done it myself in the past, I understand how taxing creating official .deb and .rpm is for the developers, and how difficult dependencies issues are. Given how Ubuntu is digging itself into the snap hole, what's the best solution here?
Why pick Flatpack vs Appimage? Reading about it they both seem to have pros and cons.
I see a lots of PopOS proponents here, but found that they don't produce that many .deb packages, and the choice will dwindle as Ubuntu's moving more and more stuff to snap. It also was a lot of work to un-customize (going back to a vanilla GNOME).
I'd honestly be happy with even Fedora, if I could easily install most OSS.
I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard.
As a user I want to download the thing and run it. AppImages provide that.
As an app developer I want to create one single package that works everywhere that users can just download. AppImages provide that.
Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it.
Most software is best installed by the native package manager. For the few exception AppImages are perfects.
I don’t think there are any distros that are pushing Flatpak as the ultimate solution the way Ubuntu is snaps.
Ubuntu’s aggressive approach with snaps would have been bad enough if snaps were the perfect desktop app solution. It’s a lot more frustrating considering snaps are probably the 3rd best new packaging option behind Flatpak sand appimage.
I didn't look closely into either flatpak nor appimage. But I get the advantages of such a system and I think it might actually help with the "Linux on the desktop situation". It's very easy to deploy something with restricted access to the file system, something that has all its dependencies in one place, that updates atomically, etc. It's also nice for random app vendors to be able to know that all their users are on the latest version, or not far behind. Could even push some devs to consider going back to desktop apps, as opposed to the web, knowing that they wouldn't have to deal with 1234 different, obsolete versions because someone's grandma didn't update her system in years.
After spending some time reading the exchanges on the posted link, I've come to the conclusion that the actual problem with snaps might not be snapd nor the automatic updating in and of themselves.
Rather, the problem seems to be a scope mismatch. This whole snap thing looks to me as something that should be aimed squarely at the "desktop user". I use that term as opposed to "system use". So distributing Spotify or whatever via snaps? Great! LXD for a home user to test? Sure! But as a way of managing low-level system components on production boxes? No way!
So I have to say I don't necessarily take an issue with Ubuntu pushing this on the desktop version. Sure, it is a pain by certain aspects, main one being slow startup for apps. But pushing this on Ubuntu Core in its actual state is, to me, the real issue. Sure, apparently you can run your own "Snap Proxy" or whatever they call it, which allows you to manually approve upgrades, etc. But why go through this trouble? It seems easier to just run apt-get from a central location when you want and for the packages and versions that you want.
- AppImage. Basically the idea of "Apps" ripped straight out of MacOS and injected right into Linux. Works fine, but clutters your home directory with Another Folder and doesn't integrate with your desktop like a native package.
- Snap. Works on any system that can install snapd, is owned by Canonical (a pro or a con depending on who you ask), but also auto-updates and has occasional performance problems. Plus, snapd is generally kinda fussy.
- Flatpak. Sandboxing taken to it's (il)logical extremes. If you like random data loss, confusing package manifests, low-performance and generally broken software, this is the way to go. Of course, most people like it when their compositor doesn't break when installing third-party programs, so they avoid it like the plauge. It's a uniquely bad format, almost worth spinning up a Linux VM to try it for a laugh. Just make sure to use GNOME, it's useless anywhere else. That's the true hallmark of a cross-distro packaging solution!
So yeah, we're probably due in for Another Competing Standard. At this point though, I think most developers are contented to just ship an RPM and an Arch package and let everyone else figure stuff out for themselves. Honestly, I prefer that approach when compared to the blasted wasteland that is cross-distro package management.
reply