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.
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.
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.
@@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.
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
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.
@@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 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.
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)
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.
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.
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
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.
@@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.
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)
@@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.
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.
@@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
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).
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.
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. :)
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!
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
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.
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
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?
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.
You overlooked how Snap slows your boot time. Mounting all those Snap images at boot slows things down a lot, but I doubt Canonical will fix that, because then Snap app start-up times would look a lot worse compared to Flatpaks...
Really cool deep dive, I learned a lot about what exactly makes Flatpaks useful. Even then, Pacman and regular binaries in ~/applications still work just fine for me. Never understood why anyone would use Snaps or Flatpaks, until I saw this.
Pretty cool comparison Nick. It's interesting to see that startup times depend mostly on how well the individual app is optimized. I like using flatpaks but I might give snaps another try, to see how they evolved.
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.
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.
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
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.
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.
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.
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.
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...
Thank you for this video. I in the context of Snaps you forgot to mention two important things IMHO: - There are distributions like Fedora or RHEL that don't use AppArmor at all! - Snaps still are very slow when you have to use an older, less powerful computer - e.g. single- or dual-core, like many people in the "third" world or people who don't have much money in general (slower than Flatpaks for example and a lot slower than in your VM).
I'm a System packages Person. If a System package doesn't exist (or misses Features I need) I go for an official appimage (if IT exists) and only if that does Not exist I use the flatpak.
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!
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.
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.
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
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.
@@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
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...
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 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!
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.
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.
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.
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.
@@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).
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!'
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).
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)
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
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.
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.
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.
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...
Informative video. I use all of the above. Snap, because I use Kubuntu and that's how Firefox is packaged. A little slow to load, but I'm usually not in a hurry and can always use Waterfox, which is not a Snap. I have a few Flatpak programs, which are also slow to load but these are programs I don't have in any other format. Appimages are convenient, except that they don't upgrade so easily, but they're fine for programs like Celestia which don't need so much upgrading. But the vast majority of my software is what Kubuntu provides through Discover, and in general, I'm happy with that.
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.
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
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.
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.
Even though it probably would be a very technical thing: I would like to know in what way dep and rpm packages are different. Could you _convert_ one to the other or not? And how is it that flatpack seems to work for many distros as compile-only-once-solution?
You _can_ convert from one format to another but in practice this is difficult because different distro families use different package groupings. For instance one distro might have a single "LibreOffice" package but another might have separate packages for "Writer" and "Calc". Dependency lists will likely need to be manually adjusted to account for these differences. I do believe this is sometimes done for proprietary software packages which are only available in one format, but otherwise it's not worth it.
snaps would be fine if: 1) I can turn off the redundant copies 2) I can turn off the sandboxes - I want to open media files outside of my home directory dammit! I want to use hardware acceleration!
I tried flatpak recently after a fresh KDE install on Arch and it wasn't horrible. Not like my experience with snap packages which always seemed to make you wonder if the app was going to actually start or not. Personally I like the concept of the AppImage much better since it's by default self-contained. I hadn't experienced any difference between them and flatpak and like the idea of protibility. Ultimately I'm left wondering how much security should we need to take with each individual program? While you might have installed firefox from your package manager, that does not mean you gave firefox full run of your operating system. It does mean you gave your package manager that ability. If there's an issue with that, then there's a hole in the OS, which one of these other packaging systems can probably exploit too.
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.
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.
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.
LibreOffice snap isn't just slow to open at first start, it is slow to open at every start... On my X1 yoga with an i7 7th gen it takes almost 8 seconds to start always even at max cpu speed. I had to replace it with the deb
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.
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.
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?
@@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.
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
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.
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.
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.
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.
I use all types of packages, depending on which one suits me best in each case. Obviously I would like a format that contains all the advantages, but I think that something like this cannot possibly exist, there will always be a tool that works better than another in different use cases.
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
Try Proton VPN, my pick for a secure and private VPN: protonvpn.com/TheLinuxEXP
I've been using the free version of this, it's actually very good. Solid sponsor
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.
I use the Plus version I pay for.
This link doesnt seem to offer a free version like you said? Is it because its a few days old?
@@tylerfox5003 If you make a normal proton account you can make a free version. This also includes the VPN by default
i like how mint handles packages, a graphical store for both system packages and flatpaks, with a dropdown to swap between package formats
That's how it works on most Gnome based distros. Same on Fedora which I use...
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!
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.
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.
@@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.
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
Yep!
The year of the Linux desktop is one of the oldest myths in history, the messiah that will never come :D
Completely agree, if Linux figures out it's own ".exe" it'll actually have a shot.
@@ArxariThat would be ELF files, comparing literally without taking into account package formats.
The community did settle. Flatpaks and distro packages. It's a private corp decision that allows snaps to be a stupid thing.
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.
Also note AppImages depend on glibc compatibility so they won't work on distros like Alpine.
Flatpak is the truest universal package 🔥
@@Beryesa.Not necessarily 100% true as they can package glibc itself
But yeah, 90%+ of the time they won't work
@@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
@@Beryesa.Not true as you cannot distribute low level apps, which snaps can handle.
@@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.
We should make a new, universal format that solve everyone's problems!
Edit: Now there's one more competing standards
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)
@@talkysassis Or simply make it better than the alternatives and it will take over naturally .
@@Greenmarty tell me two things in the linux ecosystem that was just simply better than the alternatives and took over naturally
@@rolaca11 Systemd, Wayland.
@@SnakePlissken25 okay, I'll give you systemd, but what is wayland competing against? (and no, abandoned projects don't count)
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.
At this point the fact that snap doesn't work over nfs and Ubuntu one depends on snap is astonishing.
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.
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
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.
@@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.
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)
@@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.
@@trapexit linux users probably use more cli tools than windows and macos combined, who thought this was a good idea?
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.
If appimages were cleaned up, they would hands down be the best option unless flatpaks added a standalone package option, IMO
@@daycredAppimages lack deduplication of runtimes and libraries, so it's far from ideal
@@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
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).
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.
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. :)
Thanks 😁
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!
One commonly overlooked feature of flatpaks is the ability to install them in a separate drive. This is a big advantage over deb packages.
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
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.
My Nix experience hasn't been great. Many apps don't use the right cursor and there's no sandboxing.
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
Can't nix be considered truly universal as well, as it can also be installed on other distros?
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?
AppImages are pretty universal methinks.
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.
Great point, my windows needs 5 versions of visual studio for 5 different games. An app package 📦 would be nicer
You overlooked how Snap slows your boot time. Mounting all those Snap images at boot slows things down a lot, but I doubt Canonical will fix that, because then Snap app start-up times would look a lot worse compared to Flatpaks...
Really cool deep dive, I learned a lot about what exactly makes Flatpaks useful. Even then, Pacman and regular binaries in ~/applications still work just fine for me. Never understood why anyone would use Snaps or Flatpaks, until I saw this.
Pretty cool comparison Nick. It's interesting to see that startup times depend mostly on how well the individual app is optimized. I like using flatpaks but I might give snaps another try, to see how they evolved.
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.
Do flathub or flatpack support propietary software?
@@juandavid6609 Yes they do.
@juandavid6609 yes, there is plenty of both
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.
If flatpak had a way to run the apps using a file like AppImage it would be the best package system.
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
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.
@@speedytruck well not in my experience. I guess the user must see which is better
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.
Yes, I was confused about this too -- Nick, please clarify! 😕
Yeah, I noticed that too. Uncommon mistake from Nick.
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.
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.
Yep, they all work!
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...
Thank you for this video.
I in the context of Snaps you forgot to mention two important things IMHO:
- There are distributions like Fedora or RHEL that don't use AppArmor at all!
- Snaps still are very slow when you have to use an older, less powerful computer - e.g. single- or dual-core, like many people in the "third" world or people who don't have much money in general (slower than Flatpaks for example and a lot slower than in your VM).
I'm a System packages Person. If a System package doesn't exist (or misses Features I need) I go for an official appimage (if IT exists) and only if that does Not exist I use the flatpak.
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!
Simply apt for me with a flatpack now and then.
Me too, except for one app that ships as AppImage for some reason (Musescore)
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.
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.
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
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.
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 .
I mean, it could have prompts like on Andorid, iOS and macOS. Automatically allowing apps to access stuff is also not good.
@@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
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...
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.
You got one thing wrong though. Snap was created way before Flatpak and therefore the latter is modeled after the former.
@@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!
I was using Flatpaks extensively on Arch, but after switching to NixOS I dropped flatpak for good. Only system packages!!
I stick to Arch packages because of its simplicity and customizability.
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.
And it follows FHS.
This was vary helpful. Me being new to Linux. Thank you.
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.
That’s more Wayland problems than Flatpaks problems though
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.
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.
Yep, it’s needs AppArmor
@@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).
Snaps would work in theory if Canonical wouldn’t half-ass them. Like its sooooo apparent.
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!'
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).
That's pretty much the only positive about flatpak.
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)
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
Best packaging format for linux: NIX, change my mind.
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.
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.
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.
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...
Informative video. I use all of the above. Snap, because I use Kubuntu and that's how Firefox is packaged. A little slow to load, but I'm usually not in a hurry and can always use Waterfox, which is not a Snap. I have a few Flatpak programs, which are also slow to load but these are programs I don't have in any other format. Appimages are convenient, except that they don't upgrade so easily, but they're fine for programs like Celestia which don't need so much upgrading. But the vast majority of my software is what Kubuntu provides through Discover, and in general, I'm happy with that.
You know I really really like flatpaks, but the fact that you should write a sentence to run a program from terminal really hurts.
Yeah it’s super annoying
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.
I propose we post floppy discs to each other
The gap between regular packages and Flatpaks is smaller than the gap between Flatpaks and Snaps.
Nice overview! Thanks, Nick!
Flatpak always seems to take up unreasonable amounts of space in my experience
THANK YOU !!!!
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
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.
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.
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.
Even though it probably would be a very technical thing: I would like to know in what way dep and rpm packages are different. Could you _convert_ one to the other or not? And how is it that flatpack seems to work for many distros as compile-only-once-solution?
You _can_ convert from one format to another but in practice this is difficult because different distro families use different package groupings. For instance one distro might have a single "LibreOffice" package but another might have separate packages for "Writer" and "Calc". Dependency lists will likely need to be manually adjusted to account for these differences. I do believe this is sometimes done for proprietary software packages which are only available in one format, but otherwise it's not worth it.
Didn't try distrobox, a normal, regular old binary file.
snaps would be fine if:
1) I can turn off the redundant copies
2) I can turn off the sandboxes - I want to open media files outside of my home directory dammit! I want to use hardware acceleration!
When was the last time we all Linux users agreed on something?? 😂😂😂
Yes 🤓
It'll be interesting to see if the immutable Linux variations will drive more activity towards these packaging formats.
I tried flatpak recently after a fresh KDE install on Arch and it wasn't horrible. Not like my experience with snap packages which always seemed to make you wonder if the app was going to actually start or not.
Personally I like the concept of the AppImage much better since it's by default self-contained. I hadn't experienced any difference between them and flatpak and like the idea of protibility.
Ultimately I'm left wondering how much security should we need to take with each individual program? While you might have installed firefox from your package manager, that does not mean you gave firefox full run of your operating system. It does mean you gave your package manager that ability. If there's an issue with that, then there's a hole in the OS, which one of these other packaging systems can probably exploit too.
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.
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.
Finally a RUclipsr with a GOOD VPN placement. That's the reason I subbed xD
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.
LibreOffice snap isn't just slow to open at first start, it is slow to open at every start... On my X1 yoga with an i7 7th gen it takes almost 8 seconds to start always even at max cpu speed. I had to replace it with the deb
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.
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.
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?
@@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.
A unified format would be great :) We need this. Linux needs a unified way of handling software.
Excellent video 👍 Thank you 💜
flatpak my beloved
Thanks
Thanks ❤
Question: so appImages are like the old Portable Programs in windows? Something you don't install, just execute?
yes
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
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.
8:09 small error in the graphs for Jetstream appimage results.
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.
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.
Its awesome we have ao many options. Everyone has the choice to use the ones they like!
Almost nothing is missing from pacman + aur just saying..
It would be interesting to throw Docker in there, at least for apps that have a Docker version.
i love snaps for its CLI feature.
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.
I wish these existed for the CLI.
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
7:54 , why is Appimage 158 is smaller than DEB 146? That's kinda condusing
Thanks.
thanks for the benchs im curious with arch packages and rpm
I use all types of packages, depending on which one suits me best in each case. Obviously I would like a format that contains all the advantages, but I think that something like this cannot possibly exist, there will always be a tool that works better than another in different use cases.
Flatpack is the way forward imo
12:37 oh my
Would you do a performance/feature comparison of popular file managers?
I'm sticking with pacman for my daily use apps, but for development I'll use docker
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
enterprise storage costs a lot, and why flatpaks put everything in /var partition? Can we change that to other mount point eg. /test ?
Seems like deb packaging is the best overall by most criteria.