Appimages, snaps and flatpaks, which one do you prefer and why?
Flatpacks give me the least trouble so I guess those. All though appimages seem alright too. Snaps however seem to never want to install. I like the idea of easy one click installs for every distro but I think we are a few years away from that.
yes flatpaks are great but their only downside is the download size of an application
And, uhh, security?
Flatpak is the best one imo. Never used appimages, and snap is pure trash (close source, slow, made by canonical). Overall, native packages are imo the way to go, but flatpak is also fairly good.
Snap isn’t really closed source, it’s common misconception, the closed source is only backend (canonical servers), the snap core itself, which is installed on Ubuntu, is fully open source
Edit: snap definitely sucks tho
@KotoWhiskas @sohrabbehdani @Rega If you can’t effectively use it without the closed source part being open doesn’t mean much.
Flatpak for sure, appimages are okay in certain circumstances and snaps are trash.
Snaps. Everyone seems to hate them for ideological reasons rather than practical reasons. But for me, they just work. And if Canonical gets out of line, there’s already been proof of concepts of third-party snap repositories, so that’s a moot point.
Flatpaks seem like a solution in search of a problem to me. Not everything is a gui app, so not sure why the devs aren’t supporting cli apps well. But the biggest problem is that most software I use simply isn’t available as flatpaks.
And if Canonical gets out of line, there’s already been proof of concepts of third-party snap repositories, so that’s a moot point.
That’s not really a moot point. A proof of concept is much different than an implementable specification. And especially in the commercial space, you’d want to host your own snap repo just for that handful of software you want to customize and then reference upstream for the other things. Snaps, to be useful to that user, need to have the same sort of design considerations apt/deb an yum|dnf|zypper/rpm have about multiple repositories and an implicit promise to not break the 3rd party stores version to version.
Additionally an open source server component was a day one promise from Canonical about Snaps (along with monetization and a functional license model for closed source software) and the gas lighting from Ubuntu about why that stuff isn’t here and doesn’t appear to be close gets harder to ignore every year it goes on.
Cli apps not being available as flatpaks is a huge oversight. It makes using flatpaks as my main source of applications a non starter.
i use arch just so i don’t have to use any of these
debs
I’ve used Flatpak, it feels somewhat sluggish;
I had once upon a time used Snap (unwittingly), never again;
Appimages… with a lack of options, they seem to run well, although the two I’ve used seem to take away quite the chunk of memory.But if it’s a reasonable choice, I’ll always go with natively distributed or locally compiled binaries. They may be janky sometimes, but in my opinion they beat the “just ship the entire computer br0” philosophy that clearly comes from the Windows ecosystem.
How does that philosophy come from Windows? Windows was all about tying your application directly to the host OS via the old .net framework and COM. You had to wait for the OS to update before your app could, or the OS could randomly update and break your app
Containers as a technology are almost entirely a Linux thing as well, Windows ships with a full Linux kernel to support it now.
AppImage is a nice idea, and avoids some of the performance overheads from containerised systems, but lacks a reasonable self update mechanism, lacks code signing and the desktop integration (having icons show up in the start menu) is poorly implemented.
Snap is essentially a Canonical-proprietary apt replacement with some very serious drawbacks around performance and desktop integration (themes).
Flatpak has some drawbacks but it largely achieves it’s design goals, and actually provides some advantages over installing things via the system package manager.
Snaps is too well controlled by Canonical and does have it’s limits.
Flatpaks can be very secure, and works in most distros. It is one of my favorites.
AppImages are real easy, and is designed to work on most distros. The only problem is that many apps aren’t current. So I don’t recommend it unless an app provides it on their own sites. AppImages are often made by somebody else.
Flatpaks are not secure. Please don’t spread misinformation.
Flatpaks because their updating works (compared to my experience with Appimages) and the Apps starting instantly (compared to my limited experience with snaps). But sadly, a lot of production software doesn’t want to support either of this package formats? I haven’t seen support from Davinci Resolve or Mari, as an example.
Not sure if one would call this support, but technically Davinci Resolve can be installed as a flatpak.
those softwares are released with their own installer ( davinci resolve for example )
Definitly Flatpaks. Although snaps have improved since I last used them. But of all I still prefer the good old shell based Package manager.
For personal use, Flatpak when there’s no native option, in most cases. They always seem to work and with Flatseal, you can more finely control permissions and local filesystem access of them.
For servers, if it’s a single-purpose VM (like I do with my PiHole/AdGuard servers), I’ll also go native. Otherwise, Docker for compatibility and ease of management.
If I’m not using the package manager, I use mostly Flatpak. I will use a random AppImage here and there.
I prefer those two because I can pick when I update them, and I’ve not had a lot of issues so far. I don’t like Snap because it reminds me too much of Windows Update. I know it can all be adjusted to my taste, but I already have an option that works out of the box.
None of the above. Native debs/rpms/whatever for desktops, docker images for servers.
but what about the apps that are not in the official repository?
for example tuba the mastodon client
package myself; I chose Gentoo (and previously Arch) in part because its reasonably easy to package things there.
Most build systems are covered by eclasses ( libraries) that handle the repetitive minutia every package that build system needs.
Here’s the tuba ebuild for example (from GURU, the Gentoo equivalent of the AUR), 90% of it is just listing the dependencies and telling it to use a few eclasses to handle everything else.
Oh, and here’s the lemmy back end ebuild, the giant wall of crates is automatically generated/updated from a tool that reads the cargo files. (needed because Gentoo doesn’t allow internet access during the build for normal packages so crates are downloaded ahead of time)
Then a tgz that I unpack to /opt/ or somewhere in ~/
Tuba is in the AUR
The aur has now broke your system congrats
Nope, nothing broke but
Aborting… error: failed to build ‘tuba-0.4.0-0.1’:
and I can’t be arsed troubleshooting why for a package I have no intention of using. LOL
Basically this. Not saying the “AUR breaking your system” thing isn’t, well, a thing but I get “error aborting installation” warnings waaaaay more often than my system just outright dying because of an AUR package (which is to say, it’s never actually happened to me).
And usually, when I see that warning, I go “kay, not even gonna bother” because if I ignore it and try to brute force the install…yeah, that potential breakage is on me, not the AUR
Ditto. I’ve literally never had an aur package break my system either, but like you if it doesnt want to play first go, I’ll almost always find an alternative.
aur is limited to arch based distros only
aur is limited to arch based distros only
And rpms are for redhat tree, so ?
OP said
None of the above. Native debs/rpms/whatever for desktops, docker images for servers.
Your example package is readily available in my distro in native was my point. If your distro doesn’t have it then maybe you need to change distros.
Do you check packages you install from the aur? I ask, because it seems like people don’t. I did, and it was a pain in the ass, and that’s why I stopped using arch and arch based distros.
Arch users being like “I have it in my AUR. What more could other people ask for ?”
You should realise it’s a possibility not to want to change a system just to use (possibly broken) AUR
Which, again, misses the point. Original OP said “install native” replying OP said “but what about (package)” (obviously intending that to be a gotcha) and I replied with “well it’s in mine”
I have no idea what debs& rpms are available, nor do i care.
And what is this “possibly broken aur” rubbish ? It’s a repository, and it most certainly isn’t broken.
Individual packages may be broken but they can be broken in any repository. Are you saying there’s never been a broken package in a debian repository ? Lol.
Edit to correct “you” to “OP” as you aren’t the original person doing the “whataboutism”
I hope you turn on DCT because docker image downloads are totally insecure by default.
What’s DCT? I’m not actually running Docker but Kubernetes.
Docker Content Trust. Its the (off by default and pretty broken) way that docker would verify what it downloads wasn’t maliciously modified
Appimages are good for downloading off sketchy websites, Snaps are good for server CLI apps, Flatpaks are good for GUIs
But honestly they all solve the main issue pretty well
