Snaps vs Flatpaks vs Appimages vs Packages: benchmarks, missing features & differences

[@TheLinuxEXP]

Try Proton VPN, my pick for a secure and private VPN: protonvpn.com/TheLinuxEXP

[@The8BitPianist]

I've been using the free version of this, it's actually very good. Solid sponsor

[@LeeMaiden]

The Linux version doesn't have Secure Core or Wireguard, unless on the Wireguard you do a lot of things, I haven't been able to get Wireguard to work. I asked therm about Secure Core and it looks like it's coming to Linux.

[@LeeMaiden]

I use the Plus version I pay for.

[@tylerfox5003]

This link doesnt seem to offer a free version like you said? Is it because its a few days old?

[@The8BitPianist]

@@tylerfox5003 If you make a normal proton account you can make a free version. This also includes the VPN by default

[@currentsubset6885]

i like how mint handles packages, a graphical store for both system packages and flatpaks, with a dropdown to swap between package formats

[@ReflexVE]

That's how it works on most Gnome based distros. Same on Fedora which I use...

[@cameronbosch1213]

Same with KDE Plasma and its graphical store Discover, which got a redo in Plasma 5.27 and will be redone again in Plasma 6!

[@sobieckil07]

Yeah, that's basically how modern KDE Plasma or GNOME experience looks like. Debian 12 stable here with KDE: exactly the same experience with Discover.

[@Linux_ASMR]

Mint's AppStore is awesome. While both Discover and Gnome Software are nice too, they do run on top of Package kit which is pretty average software imo.

[@stephenwilson0386]

@@Linux_ASMR as an openSUSE user (and Mint on my laptop and a secondary SSD on my PC), PackageKit is literally the worst, at least on suse. Not sure why it doesn't do the same elsewhere, but seems like 80% of the time I try to use the package manager, either through Zypper or Yast, it gets blocked because PackageKit is always busy doing who knows what in the background.

[@The8BitPianist]

I think once the Linux community can resolve the package wars and manage the switch to Wayland, the possibility of the year of the Linux desktop is finally upon us

[@TheLinuxEXP]

Yep!

[@bodlouk7011]

The year of the Linux desktop is one of the oldest myths in history, the messiah that will never come :D

[@Arxari]

Completely agree, if Linux figures out it's own ".exe" it'll actually have a shot.

[@DrewTNaylor]

@@ArxariThat would be ELF files, comparing literally without taking into account package formats.

[@meeponinthbit3466]

The community did settle. Flatpaks and distro packages. It's a private corp decision that allows snaps to be a stupid thing.

[@InstantDesign]

At this point the fact that snap doesn't work over nfs and Ubuntu one depends on snap is astonishing.

[@RedCocoon]

We should make a new, universal format that solve everyone's problems! Edit: Now there's one more competing standards

[@talkysassis]

The only way is to enforce it. But it makes linux folks really angry. Canonical enforces Snaps (and will probably get a lot of packages because of that)

[@Greenmarty]

@@talkysassis Or simply make it better than the alternatives and it will take over naturally .

[@rolaca11]

@@Greenmarty tell me two things in the linux ecosystem that was just simply better than the alternatives and took over naturally

[@SnakePlissken25]

@@rolaca11 Systemd, Wayland.

[@rolaca11]

@@SnakePlissken25 okay, I'll give you systemd, but what is wayland competing against? (and no, abandoned projects don't count)

[@RipCityBassWorks]

I really like Flatpak and it has a huge advantage for developers: just one format to maintain that works the same on all distros. Much more efficient than maintaining a slightly different package for each distro and much more secure than delegating that task to the distro maintainers. Less variables to consider with bug reports also. Flatpak does need better options for non-FOS software though.

[@avrahamhollander9296]

Another point worth mentioning is that snaps require systemd, and so cannot be used on distributions such as Void Linux, which do support Flatpaks and AppImages.

[@Beryesa.]

Also note AppImages depend on glibc compatibility so they won't work on distros like Alpine. Flatpak is the truest universal package 🔥

[@mgord9518]

​@@Beryesa.Not necessarily 100% true as they can package glibc itself But yeah, 90%+ of the time they won't work

[@Beryesa.]

@@mgord9518 they don't even package some basic stuff (proper libfuse) to run on modern ubuntu (arguably the top market share distro), can we really expect to see the whole glibc

[@FlorinArjocu]

​@@Beryesa.Not true as you cannot distribute low level apps, which snaps can handle.

[@Beryesa.]

@@FlorinArjocu distributing low level apps doesn't change the fact its fundamental dependencies are less universal (works on less distributions in total). On the other hand flatpak can extend and improve in the future, given enough resources/contribution.

[@speedytruck]

One thing about Snap sandboxing, though; if your distro doesn't use Apparmor, say goodbye to sandboxing. On Fedora, a distro that uses SELinux, Snaps provide no security or confinement whatsoever. And if you don't have any security modules installed (say for example, DIY Arch Linux), there won't be sandboxing for Snap either. Meanwhile, Flatpak sandboxing works on all Linux distros because they use kernel namespaces and stuff that are already built in to the Linux kernel.

[@Racsu]

I love the concept of appimages, especially for the familiarity they can generate for macOS or Windows users, however there is a lot of controversy surrounding them, and they are far from working properly, apart from the lack of official support from developers, which leads to many apps not even have an AppImage, and if they do, it is of dubious origin and works poorly. Flatpak for me so far has been the best option, it just works.

[@daycred]

If appimages were cleaned up, they would hands down be the best option unless flatpaks added a standalone package option, IMO

[@softwarelivre2389]

​@@daycredAppimages lack deduplication of runtimes and libraries, so it's far from ideal

[@daycred]

​@@softwarelivre2389 That's just part of cleaning up, and even then it's not tragic. It's just amazing because the idea that you just double click a file, instead of adding a flatpak source and then installing some app through cli because a company want's full control, speaks to a lot of mac/windows users and is way easier/simpler

[@NorbiPeti]

I can imagine a place for appimages for running apps just once or twice so you don't want to install them on the system properly. But for me I only really use them when that's the only option (or the other options suck). Appimaged is great in that case for system integration (although not perfect).

[@eDoc2020]

What I like about AppImages, at least for specific uses, is that it's stupid easy to have more than one version of the same program installed at the same time. This advantage is also a disadvantage; if you want to use the latest version than Flatpaks are better.

[@WolfiiDog13]

I usually just go straight for the Flatpak version, cause I think standardization is just better. I want a future where Flatpak is THE Linux format, and traditional packages are just used on rare specific cases. Traditional Linux desktops already have such a small portion of the desktop OS market, dividing it into sevral distros and package manager only makes things worse. I think this fragmentation is one of the reasons many software companies just don't support Linux, it's not the only reason, but it's a big one

[@trapexit]

Flatpak does not work for non-gui software. While the average gui desktop user may not see them a very large number of packages are not gui packages. I want to see more standardization too but this seeming lack of interest in the fundamental system packaging is not ideal.

[@llothar68]

@@trapexit It's total non understandable for me why they don't want to support command line tools. I see the problem with system tools. I argued for a long time that the security aspect should be optional. You should run servers from a fatpak and only use the packaging/library handling for it. At least make them installable natively. Servers usually recquire much less libraries so with increased backward compatibility it is much easier to run servers. But using flatpak as deplyment tool is even the least demand. Just like GTK the team is disgustingly closed and non willing to accept outside ideas.

[@Yep6803]

What I like of Fedora is their Flatpak use. I like what is steady and Flatpak are steady. Snap is good too but messy and in general I don't have good relationship with Ubuntu and Ubuntu-based (maybe I'm the only? I don't know, each time an issue). AppImage isn't for me, I care too much about my privacy and I avoid everything isn't trustable what to me AppImage isn't. (ps: kill me if you want but for now Homebrew is the cooler packages manager LOL)

[@llothar68]

@@Yep6803 Homebrew like all this package managers are 100% insecure as they run untrusted build scripts anyone can inject. You don't trust AppImage but use Homebrew? ROTFLMAO.

[@justahumanwithamask4089]

@@trapexit linux users probably use more cli tools than windows and macos combined, who thought this was a good idea?

[@merthyr1831]

IMO I'm with the creator of bottles on this - Nix and Flatpak are the only decent package formats - Nix is truly native and Flatpaks are truly universal.

[@that_leaflet]

My Nix experience hasn't been great. Many apps don't use the right cursor and there's no sandboxing.

[@merthyr1831]

It's not perfect but if you need a "native" app without sandboxing (say, for development) then it'd be great to see Nix continue improving there. For general purpose stuff I'm more inclined to support Flatpak@@that_leaflet

[@yeshey5443]

Can't nix be considered truly universal as well, as it can also be installed on other distros?

[@keilmillerjr9701]

Nix doesn't follow FHS, which will create a steep learning curve. I have absolutely no issues using a normal distro with regular repository packaged apps that follow FHS. Are people trying to solve a problem that doesn't occur often?

[@theviniso]

AppImages are pretty universal methinks.

[@kpcraftster6580]

The video: Instead of considering ideological and personal preferences, let's look at the performance of each format and what's still missing from each. The comments: No, let's talk about ideological and personal preferences like we always do!

[@SSquirrel1976]

My epilepsy isn't photosensitive, but nice touch keeping an eye out for folks. Not something I see too often. Already watched a bunch of videos the last month, but subbed now. :)

[@TheLinuxEXP]

Thanks 😁

[@kylamkv]

this is how I use the different packaging formats: Flatpak: GUI apps System packages: CLI Apps (or when flathub doesnt have what I need) Snaps: Server apps Appimages: Apps I need to keep on a flash drive

[@Daniel_VolumeDown]

Appimages are great for example for games. Games often are created and not maintined later, so getting package that works with all of the original dependencies is good I guess.

[@DeathEnducer]

Great point, my windows needs 5 versions of visual studio for 5 different games. An app package 📦 would be nicer

[@blackjam_alex]

If flatpak had a way to run the apps using a file like AppImage it would be the best package system.

[@eDoc2020]

The way I see it, choosing Flatpak is a good idea when running a proprietary application. I want the most sandboxing to keep my data safe in such a case. I also don't want to deal with dependency issues which could arise when the community can't recompile for newer library versions.

[@juandavid6609]

Do flathub or flatpack support propietary software?

[@eDoc2020]

@@juandavid6609 Yes they do.

[@theaveragecactus]

​@juandavid6609 yes, there is plenty of both

[@SteveMacSticky]

I found snap made Ubuntu unusable on very low end hardware. Disk thrashing galore. Rather use deb, then appimage, then flatpak for very low end hardware

[@speedytruck]

Flatpaks load faster than Appimages because Flatpaks aren't compressed. Appimages use SquashFS compression which takes slightly longer to load as shown in the video. I imagine it might take even longer on low-end hardware.

[@SteveMacSticky]

@@speedytruck well not in my experience. I guess the user must see which is better

[@bodlouk7011]

I use the AUR, btw

As "relatively new" user: Flatpaks. Not because they are "better" or more efficient, but because from my experience... They just work. DEB/RPM there is always a dependency something in need 9f a cli to check logs... Appimage misplaces the appicons, and snaps... I dont like to give way to corporate tantrums.

[@ToyKeeper]

I was at Canonical during the creation of Snap and its predecessors, and did QA for it. That's why I don't use Snap. Well, that, and because "apps" are inherently limited by design and app stores are generally built for profit instead of collaboration, built for the vendor's benefit instead of the user's.

[@hopelessdecoy]

Flatpak= Most Secure but least versatile Snap= Most Versatile but least open Appimage= Most Portable but least secure All= Cool is what I gathered from this :) I also am a big Appimage fan.

[@TheLinuxEXP]

Yep, they all work!

[@cameronbosch1213]

And Snap is also really forced down Ubuntu users and only works on distros with systemd. The first two points (the one you made and the first one I made) are important to why I don't use Snaps, however, the systemd requirement doesn't really affect me except I hate software that is dependent on systemd...

[@richardz6049]

Simply apt for me with a flatpack now and then.

[@wilh3lmmusic]

Me too, except for one app that ships as AppImage for some reason (Musescore)

[@JohanAdrian]

Fantastic video, Nick! Thank you for explaining everything so well. Could you do a video like this one but focused on desktop environments and window managers? Like what is GTK, what is QT, XFCE, GNOME, KDE, Plasma. What is what and what does what. Thanks!

[@Ibix5]

There was a bar graph error around 7:38. I can't tell if DEB test is supposed to be the higher number or if APPIMAGE was supposed to have the larger bar. I would appreciate that the time is taken to list a correction so we the audience can be certain what the data was supposed to represent.

[@relsre]

Yes, I was confused about this too -- Nick, please clarify! 😕

[@darknightmike10yearsago]

Yeah, I noticed that too. Uncommon mistake from Nick.

[@АлексейШилин-д1ф]

The Firefox performance comparison has an issue: its performance greatly varies depending on compilation flags used, so given that all the builds tested were not the same, you were mostly testing compilation flags differences rather than packaging formats. Taking something closed source (which guarantees that actual executables are the same as they come from a single vendor) would've been way better suited for comparison purposes.

[@boltsj]

AppImage basically has no wayland support and the creator rejects patches to improve the situation because of an idealogical opposition to wayland, meaning appimage apps (at least qt ones) can only run on xwayland meaning no hidpi support and thus blurry fonts. Also, missing host libraries preventing appimages from working is really really common outside of ubuntu.

[@mgord9518]

This is untrue. AppImage itself doesn't "support" anything. It's literally just a runtime slapped on a SquashFS that mounts and runs what's inside. The developers of the specific AppImage are responsible for supporting Wayland or whatever else, but yeah, probono seems to be pretty hardcore anti-Wayland and has a few articles trying to sway devs to not support it.

[@mgord9518]

The library issue is legitimate, although it's an issue with how the developer has chosen to build the AppImage. I try to make mine work on essentially any distro made in the last 15 years, which takes a ton of work if also trying to keep them somewhat compact. The biggest issue with AppImages is that it's harder to make a good AppImage than it is to make a good Flatpak or traditional package, which trickles down on users through worse AppImages than ideal

[@long-live-linux]

I stick to Arch packages because of its simplicity and customizability.

[@laurentbrock4796]

I agree. Super simple to write a PKGBUILD, all easily redistributable in the AUR (so huge size of catalogue), lightweight (small disk usage because compressed) and no performance impact from sandboxing. Honestly if we could all just move to Arch-based distros Linux packaging would be better off.

[@keilmillerjr9701]

And it follows FHS.

[@slickjim861]

Flat pac isn’t going to be a thing till they enable read write permissions by default. It’s a pain in the ass to deal with .

[@WolfiiDog13]

I mean, it could have prompts like on Andorid, iOS and macOS. Automatically allowing apps to access stuff is also not good.

[@bigpod]

@@WolfiiDog13 thats the plan but not everything can yet work with it plus portals(they will in future enable this kind of thing) arent done yet therefore permission system

[@jirib.8280]

As I work a lot with old computers with serious RAM/CPU/disk limitations I prefer to use standard distro packages, not the universal ones. Besides that universal packages looks to be against Linux principles (shared components) and more like Windows/Mac style. So, I try to avoid Flatpaks, Snaps and AppImages as much as I can...

[@felderup]

my experience with appimages, perfectly functional, my experience with flatpak 'how do i make it use the directories? my crono trigger saves were never written! it's sandboxed somehow, sandboxed with a cover to keep the cats out!'

[@frangrau3750]

I do not understand how the community is not fed up with Canonical at this point. Wayland work gets started, they decide Mir... Flatpacks, they create Snaps... Canonical is the Apple in the Linux community, they always have the need to reinvent their own standards to keep their ecosystem as controlled and closed as they can. I've been using linux for more than 20 years and I'm tired of seeing so much parallel work done with little (or none) benefits to the end users. Choice is good in some things, but in basic stuff like packages is just another hurdle for people to use linux hassle free.

[@albussd]

You got one thing wrong though. Snap was created way before Flatpak and therefore the latter is modeled after the former.

[@frangrau3750]

@@albussd not really. Flatpak started as xdg-app in 2014. Snaps were only for IoT, and then repurposed for desktop/general apps later. The snap store was released afterwards too (2016) Anyway, that a company in the Linux ecosystem creates a solution for managing open source ( and non open source packages) and that solution runs in proprietary (non-open source) code... Stinks in a way that we should put all hazmat suits to use it. We should run from companies that their marketing says open source, community driven, etc... and then produce and rely on close source code. RUN!

[@parheliaa]

Linux packages situation is exactly like the one shown in XKCD episode about "competing standards". What missing here, is testing how many resources (especially memory) each variant consumes

[@josephferren6372]

I think Canonical can do something really good with Snaps, especially in regards to their immutable system, Ubuntu Core. Fedora and Ubuntu competing in the immutable distro space can only lead to revolutionary advancements in how we fundamentally use our computers.

[@felixjohnson3874]

Sandboxing is only more secure when doing something like running WINE. Applications set their own permissions & can change them with updates, so any malicious application can just get whatever permissions it wants. It IS great for running things with WINE but otherwise its pretty moot as a point and is largely just security theatre. Plus flatpaks have a ton more compatibility issues then mentioned here in my experience, particularly with wayland & electron applications. The reality is downstream native packages are what give Linux a good portion of it's benefits. For fire & forget distribution appimages reign supreme and flatpaks have a VERY narrow range of relevancy as far as I'm concerned, especially since their size balloons once you start installing a decent amount. They are good for sandboxing applications that can run arbitrary code, but even then that sandbox isn't often treated with much care and still has a lot of holes.

[@TheLinuxEXP]

That’s more Wayland problems than Flatpaks problems though

[@OcteractSG]

Flatpaks are really nice. You can install them into your home partition, and then you’ll still have them if you distro hop or upgrade by reinstalling (e.g., Debian Stable).

[@matyasmarkkovacs8336]

That's pretty much the only positive about flatpak.

[@olnnn]

There is a slight difference in security with appimages vs packages since packages in most distros are installed using root priviligies while appimages never go via root priviligies unless you explicitly give it to them but are just a binary ran with user priviligies. That doesn't stop them from messing with anything the user account has access to of course but it's a step down from what installing a distro package from an untrusted source is capable of.

[@Blueeeeeee]

I'll add that Snap sanboxing does *not work* on non-Ubuntu distributions. Also Flatpaks use OStree to achieve additional sharing of libraries on top of the runtimes, and can update in the background contrary to Snaps.

[@TheLinuxEXP]

Yep, it’s needs AppArmor

[@constancies]

@@TheLinuxEXPsadly that is not enough; distributions like openSUSE and Pop!_OS lack proper sandboxing bc Snapd relies on special non-upstream patches to apparmor. So really, the only distros that support snap properly are Ubuntu, a couple derivatives, and Manjaro (they seem to apply the patches as well).

[@seansingh4421]

Snaps would work in theory if Canonical wouldn’t half-ass them. Like its sooooo apparent.

[@GraveUypo]

as a linux noobie, i learned this the hard way. i had installed a community flatpak version of steam and i was having ENDLESS storage issues with it. i struggled with it for weeks, until yesterday i decided to fix everything that was bothering me in my linux. Cloned the drive from a 256gb ssd to a 2tb one, fixed all my AI stuff that wasn't working on linux, and tackled steam. i tried uninstalling and reinstalling, everything bugged remained bugged. so i went around cleaning every trace of steam before installing it via terminal instead of the flatpak from the store. tada. everything's working as it should now. if only i knew it before...

[@marufbepary100]

The gap between regular packages and Flatpaks is smaller than the gap between Flatpaks and Snaps.

[@sylvershadow1247]

I personally use Snaps with few Flatpaks, if we're talking about the modern packaging formats. I still use Debs or Pacman, but I try to rely less on PPA or AUR and only go for official sources.

[@redo1122]

Didn't try distrobox, a normal, regular old binary file.

[@SnowyRVulpix]

I prefer debs because for the most part... They just work. Yes, I've had the dreaded dependency hell, but for the most part... they just work. I'm willing to consider flatpaks in the future if they work better with interoperability... both with messaging and theming. I will never touch snaps due to how Canonical is forcing users to use it, so my distro disabled snaps. And appimages are just... They work, but it's like a Windows portable app. There is no updating support, and you need to download them directly from websites (Not a bad thing, but not easy either)

[@EQuivalentTube2]

My only pet peeve with flatpak it that it doesn't work as well for CLI and server applications, because of odd launch scheme, whereas snap supports both no problem. Flatpak, if you're going to be the unified format (and I hope you are) - Please fix.

[@rainmannoodles]

Exactly. Right now, Snap's CLI support is the only thing keeping it going. The problem is the longer we go without an alternative, the more likely Snap is to actually succeed. And that would be pretty much the worst outcome here. We need to have a better alternative and relegate Snap to the garbage bin of history where it belongs.

[@RucadiDev]

Best packaging format for linux: NIX, change my mind.

[@corviraptor]

I do find AppImages very endearing, considering they contain the entire filesystem and dependencies in the AppImage file itself. One thing that's always bothered me about programs that require installation is that they have the potential to leave a bunch of gunk in your file structure, whereas if you want to remove an AppImage you just delete the file. It's also nice because you can move the AppImage file to anywhere else in the system and it won't have trouble locating the files it depends on, so it's just a lot easier to reorganize your system. I hope there's ways to apply at least some of these concepts to Flatpaks, since the sandboxing is a huge advantage for them and they're likely to become the de facto standard for most applications, but the way they install themselves into the file system drives me kinda mad LOL

[@Destide]

I propose we post floppy discs to each other

[@RedSntDK]

I appreciate this comparison. Has taken me maybe 3 videos and a lot of replaying the same parts to understand it, but I think I've figured out why snaps get a bad rep now.

[@alicethegrinsecatz6011]

Snaps doesn't require containerization, yes. But the default installation method requires containerization! Snaps that don't want to be containerized can't be installed from the GUI and can only installed by using the terminal and only with the correct addition to the install command. See for example CLion.

[@connivingkhajiit]

Flatpak always seems to take up unreasonable amounts of space in my experience

[@Temet79]

THANK YOU !!!!

[@rami-succar7356]

absolutely, and it redownloads ~1.5gb of IDENTICAL "dependencies" ever single time i install or update something. People tell me Snap does too but come on, i'm gonna notice an hour difference in download speed like please i'm not a moron. snap is superior

[@spartanbeef9491]

Fine for me. It used to take up tons of space on Arch for some reason, but on Fedora and NixOS it's about a 1-3GB more than system packages, depending on how many runtimes you use. On the one hand that's 3GB gone. On the other hand it's a small price to pay for apps that are always up to date and always work, and my overall install size is still less than half a typical windows install.

[@Deinorius]

On my Steam Deck I have to check how many GB more space it takes for my apps on it. I'm considering to mix my usage with Flatpaks, nix and AppImages.

[@themedleb]

The Flatpak taken disk space totally depends on if the apps you installed are using: 1. The same (less space) or different libraries (more space). 2. If using the same libraries, some apps depends on older version and others depend on a newer version of the same library, so Flatpak keeps all the seemingly "identical" libraries so all apps still work. 3. The same library version but from 2 or more different Flatpak repos (Not recommended to use another repo than Flathub unless you trust it). So whenever you see "identical" libraries/dependencies, when using `flatpak list` command, always check the "Version", "Branch" and "Origin" (repository), that way you can see that they are different, not identical. All in all: I would rather deal with the more needed disk space and internet connection than dependency hell (app breaking, or app breaking other apps or whole system breaking … ) while I really need to use my system for production at that time. They are not the same "hells" to me.

[@royborgen]

A unified format would be great :) We need this. Linux needs a unified way of handling software.

[@walter_lesaulnier]

I use Fedora as my daily driver and it has Flatpak support out of the box. But Fedora also has its own Flatpaks for some things. I get worried because a lot of the reviews of the Flatpak versions for various apps frequently mention that the app is missing features that the original software had. This causes me to avoid Flatpak versions where possible.

[@talkysassis]

One thing that makes flatpak really messy is that I can't choose a place to install them. I don't know why it have those limitations, but it should not be a problem.

[@Daniel_VolumeDown]

It is the sme problem as with regular packages of I am not wrong: dependencies. I guess it could be done (and I would be happy if it will be done) but the question then is where should dependency go? Into the place where application is? Then what if you install another aplication on other drive that uses the same dependency?

[@talkysassis]

@@Daniel_VolumeDown Apps should not share extra dependencies that are not in the runtime. Just do it like Steam with the games (Base system runtime and then the game with ALL the dependencies) Those are not big like QT or Mesa that are runtime libs. So the answer is: Not all libs are equal so those libs are not a problem.

[@OmnisArchives]

Would you do a performance/feature comparison of popular file managers?

[@Raspikabekk]

Question: so appImages are like the old Portable Programs in windows? Something you don't install, just execute?

[@ThaitopYT]

yes

[@gerlosv]

I agree with you - I just use anything, as long as it works! Since I'm on Ubuntu I use a lot of snaps, and just don't care. If something I need doesn't exists (or it's too old) as a snap or as a deb in the repos, I use flatpak or appimage, in this order. But usually i don't need them. Actually, I guess too that the future may be in flatpaks, but I hate all the flame wars about snaps out there. They work fine after all, and if/when Canonical will drop them we can just flatpak, or anything else will be there.

[@PaulG.x]

I found all my snaps really fast except for Libre Office which was much slower to save a document. So that one I replaced with the .deb version

[@cheako91155]

There is also the issue that you can't at all or easily use mesa git branches or in simple terms testing the latest(newer than git main) video drivers are unavailable.

[@bharatkumar6458]

I use nixos and try to use everything from nix but whenever something breaks i look towards flatpak because it can never break that has gotten hard-coded in my mind through these years.

[@alibozkuer5022]

8:09 small error in the graphs for Jetstream appimage results.

[@TruthDoesNotExist]

I liked flatpaks and was using them for everything because they were more stable but recently I've had to switch away from them completely because they constantly crash or refuse to open

[@Your_Degenerate]

Thinking of the start up times reminds me of the first PC my family had. It took roughly 2 minutes to boot into Windows 98 and then another couple of minutes to load something like Photoshop. Things sure have changed since then.

[@teszaract.8783]

Should have also included Nix Packages. It's by far the best one in my opinion. Would rather prefer Nix packages to any of the others mentioned in the video.

[@chaoshub]

When was the last time we all Linux users agreed on something?? 😂😂😂

[@setoman1]

Yes 🤓

[@Insightfill]

It would be interesting to throw Docker in there, at least for apps that have a Docker version.

[@ericneo2]

I've always wondered with the isolation features why Web Servers, PHP, Python, and Docker containers aren't available as Flatpaks or Snaps. It just seems to me that they would be perfect instancing and isolation.

[@bigpod]

docker itself is containerization that uses most of same kernel technologies as flatpak

[@ericneo2]

@@bigpod If your docker instance gets hit with ransomware you lose your whole drive, not just the instance. And if your docker instance gets hit with privilege escalation the attacker has access to the whole system not just the instance. That's why docker recommend not using their default install in production and instead recommend installation as a non-root user or rootless mode. With all the technologies they use that are similar, I just don't understand why they don't go all the way and do it properly. Per user isolation would also be a godsend on shared hosting if each instance had it's own self contained files instead of sharing files.

[@bigpod]

@@ericneo2 Btw they dont use similar technologies under the box but the same unly difference is that flatpak uses user namespaces while docker uses namespaces, yes if something escapes from docker container they will be a root user on host which is why they introduced docker rootless which is now recommended which uses user namespaces like flatpak. So technologies are the same not similar

[@ericneo2]

@@bigpodDude lower the elitism you are coming across as a total asshole.

[@alexvass]

Thanks

[@urlhnd]

12:37 oh my

[@Waffles8626]

flatpak my beloved

[@CompuB1t]

just to mention to change of names between packages on packages managers makes me anxious

[@sashimisub8536]

Almost nothing is missing from pacman + aur just saying..

[@jasonls221]

Snaps broke too much for me to see them as an option at all, had to stop using ubuntu because dist upgrades could reinstall snap (Few proposed solutions didn't work). Though I definitely prefer debian testing now that I've switched, and I've had very few issues with flatpaks

[@swbusby]

Seems like deb packaging is the best overall by most criteria.

[@13thravenpurple94]

Excellent video 👍 Thank you 💜

[@redlionstudio2750]

8:15 appimage line supposed to be bigger than deb line xd

[@drakemallard6100]

Distro packages have not always the best compatibility. For example Gnome Boxes does not run as a rpm package on Fedora with btrfs, but as a flatpack package it works well...

[@FedJimSmith]

I'm sticking with pacman for my daily use apps, but for development I'll use docker

[@Insightfill]

I may eventually take the jump on Flatpak for a few things on my Debian Stable system. While things are generally fine, the included version of Firefox is not supported by a lot of financial sites. I've got Chromium, and also Firefox (current) in a portable format, but the juggling is annoying.

[@ronm6585]

Thanks.

[@EHKvlogs]

i wonder why davinci resolve is not available as a flatpak, i mean it will be easier to install, update etc.

[@Deinorius]

Isn't one big advantage of nix the capability to use the same package with different versions? It always sounded like the perfect solution for dependency hell and need space. And it's even universal because you can install and use it on (nearly?) every distro. I guess sandboxing might be the only thing missing. I have no problem with Flatpaks but they use soooooo much more space, it's just annoying. I'm talking about many GBs if more space!

[@wombatdk]

Good overview. IMO, there's currently no perfect solution. Theming and consistency is one, sandboxing the other. Gimp for example... can't access network folders of any kind unless it's installed via distro package.

[@JermaineBurrell]

I will use both snaps and flat packs. But I will use snaps primary as it will come with kubuntu by default. I really don't see what the big deal is because I'm not going to be racing to get things done.

[@theilluminatimember8896]

Flatpack is the way forward imo

[@locatemarbles]

Deb packages are the best way. Always has been. Everything else is just nonsense reinventing the wheel and making the end user experience worse.

[@aidan8583]

personally i have zero flatpak theming issues, i just have given flatpaks access to my themes directory, that's it.

[@MotownBatman]

I Love the Tried & True apt-get But lately, I have been enjoying Flatpak. The Only issue I am having, is I need it to install the Images to my /home Partition, NOT /. I've messed with it a bit, but haven't really pressed it yet

[@matyasmarkkovacs8336]

System package ftw. Always the best.

[@FlameSoulis]

Larger concern for me is the memory differences and some cases where a Flatpak doesn't work. My laptop only has 8GB of RAM and Firefox/Waterfox cannot use PWA with the sandboxing nature of Flatpak.

[@tr3y417]

To be honest, I feel like snaps get a bad rap. There are some apps I use which don't have a deb format and only offer snap for the best experience or appimage. I haven't really had any issues with Snap packages myself and find it incredibly easy to just install a snap and be done with it on my personal computer. It installs every library needed to run it so it almost always runs flawlessly. That being said I use a lot of flatpaks too and haven't had any trouble with simultaneously running any side by side. I think the takeaway is that it really just depends on what you feel most comfortable using.

[@cogitator1213]

As a Mint user I prefer snaps, because they are updating much faster.

[@Wreighn]

How do you have flatpak permission settings in the kde settings menu? Flatseal does a great job, but if a native solution exists, I'm curious to how I missed it :|

[@Silver_Adventures]

that permission settings was added in plasma 5.27.4 located in system settings and then under applications

[@MorganEdgy]

I know. Some are longer, some are thicker, some are curved, it's all perfectly natural. Wait, we're talking about Linux?

[@Piorunik18]

My chodzimy do Polskiej Kliniki w UK gdzie przylatują Polscy dentyści, ceny podobne do lokalnych (brytyjskich) ale nie trzeba urlopu na loty i jakość inna

[@xade8381]

for those looking for short answer currently, flatpak is your best option without a doubt.

[@crism8868]

I'm confused about something 😅 you say snaps use apparmor for sandboxing and don't provide portals. I messed around with snaps just briefly but from what I remember interfaces provide the same permission based model as bridges on flatpak, so afaik there's no need to mess around with apparmor, it is as simple as enabling an interface with snapd

[@bigpod]

snapd uses apparmor in the background to enable those interfaces

[@crism8868]

@@bigpod thank you! I figured it was something like that, as I said I didn't use Snap that much (I tried the Firefox snap but had issues opening local files) but I knew using Snap was simpler than how Nick made it seem

[@amigaworkbench720]

Can we have XAMPP in flatpak form for Linux please?

[@prezlamen]

Can you increase font size? I am vision impaired ,I cannot see small font

[@Janemayank]

Unification is important..