Snaps vs Flatpaks vs Appimages vs Packages: benchmarks, missing features & differences
Вставка
- Опубліковано 14 чер 2024
- Try Proton VPN, my pick for a secure and private VPN: protonvpn.com/TheLinuxEXP
Grab a brand new laptop or desktop running Linux: www.tuxedocomputers.com/en#
SUPPORT THE CHANNEL:
Get access to a weekly podcast, vote on the next topics I cover, and get your name in the credits:
UA-cam: www.youtube.com/@thelinuxexp/...
Patreon: / thelinuxexperiment
Liberapay: liberapay.com/TheLinuxExperim...
Or, you can donate whatever you want: paypal.me/thelinuxexp
👕 GET TLE MERCH
Support the channel AND get cool new gear: the-linux-experiment.creator-...
🎙️ LINUX AND OPEN SOURCE NEWS PODCAST:
Listen to the latest Linux and open source news, with more in depth coverage, and ad-free! podcast.thelinuxexp.com
🏆 FOLLOW ME ELSEWHERE:
Website: thelinuxexp.com
Mastodon: mastodon.social/web/@thelinuxEXP
Pixelfed: pixelfed.social/TLENick
PeerTube: tilvids.com/c/thelinuxexperim...
Discord: / discord
#Linux #Flatpak #Snap #AppImage
00:00 Intro
00:47 Sponsor: Proton VPN
02:17 Quick summary of formats
05:52 Performance benchmarks
08:52 Sandboxing
11:41 Missing Features
15:24 Parting Thoughts
16:59 Sponsor: Get a PC made to run Linux
18:00 Support the channel
So, what we call "packages" are debs, for Debian and Ubuntu based distros, and RPMs for Red Hat and SUSE based distros. These packages can contain libraries, or apps, and all libraries are shared between applications.
We then have Flatpaks, which are distro-agnostic. Flatpaks are sandboxed, and while they share a lot of libraries through runtimes, they can use more space over time.
Snaps are basically the same concept as flatpaks, made by Ubuntu. There are a few technical differences with flatpaks, the big one being that Snaps are suitable for graphical apps, and for command line programs.
AppImages are a more portable format: the whole app is shipped inside a single file, with most, if not all of its libraries. This means you can copy/paste apps from a system to another, and they run on any distro that has access to FUSE2.
Now, let's look at some performance comparison between different packaging formats.
I ran all these tests on the same Ubuntu 23.04 VM, with 16 gigs of RAM, 4 cores of my 13th gen i7 13700h.
Judging from the results, we can see that all packaging formats take longer to start than basic deb packages. It's especially visible with heavy apps that need to do some setup when they first open, like LibreOffice or GIMP. But we also notice that on subsequent openings of an app, all packaging formats are pretty close.
I ran the Speedometer test in all 4 versions of Firefox: the snap performs worse for jetstream, but much better for Speedometer, while flatpak performs on par for SPeedometer, but worse for jetstream. Deb packages perform well for jetstream, but worse for speedometer., and the Appimage is generally just a good performer.
A sandboxed application runs in its own environment, with very few ways to access things outside of that sandbox. This is similar to how web browsers run each tab in a separate process.
Regular packages aren't sandboxed by default: basically it means that you should only install these packages from sources you trust: either your distro's repos, or well vetted third party repos.
As per Flatpaks, they're all sandboxed. The sandbox isn't 100% bulletproof, nothing is, but it does limit what the app can access. This is all managed through app permissions, much like what you'd find in Android or iOS apps.
Snaps can be sandboxed, but the sandbox isn't mandatory: developers can decide to not use it, although this triggers a manual review of the snap app when it's uploaded to the Snap Store, to check if it does anything weird. As per AppImages, they don't have a sandbox natively.
Now let's see what's missing in terms of features. Regular packages can access everything, so there are no missing features there.
Flatpaks and snaps have more restrictions. The main missing piece is native messaging support: this is what lets an app communicate with another, and one main use case is for password managers: currently, no web browser packaged as flatpak or snap can interact with a third party password manager reliably.
Support for the system theme is also not perfect for snaps and flatpaks, or for AppImages.
As per various problems with these packaging formats, you also have the size of packages: while Snaps and Flatpaks do share libraries between apps, they don't share as much as regular packages, which means they can take up more space.
Snaps also have the added problem that they mount each app in its own virtual filesystem, that is decompressed on the fly: this can clutter your mount points, which can be annoying if you need to manage these regularly. The Snap Store backend is also proprietary, and it's centralized. - Наука та технологія
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.
At this point the fact that snap doesn't work over nfs and Ubuntu one depends on snap is astonishing.
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 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.
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!
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)
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.
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?
One commonly overlooked feature of flatpaks is the ability to install them in a separate drive. This is a big advantage over deb packages.
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.
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.
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 😁
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.
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...
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
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
If flatpak had a way to run the apps using a file like AppImage it would be the best package system.
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.
I use the AUR, btw
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.
flatpak my beloved
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.
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.
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
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!
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).
Simply apt for me with a flatpack now and then.
Me too, except for one app that ships as AppImage for some reason (Musescore)
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! 😕
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...
Nice overview! Thanks, Nick!
This was vary helpful. Me being new to Linux. Thank you.
Excellent video 👍 Thank you 💜
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.
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.
I was using Flatpaks extensively on Arch, but after switching to NixOS I dropped flatpak for good. Only system packages!!
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
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...
Finally a UA-camr with a GOOD VPN placement. That's the reason I subbed xD
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.
thanks for the benchs im curious with arch packages and rpm
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.
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
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!'
Best packaging format for linux: NIX, change my mind.
Thanks ❤
Now that I've upgraded to Slackware 15 I can finally use FlatPaks and the complaints were right. They have an abnormally slow startup time. For most programs that's still perfectly fine, because I'll be using them for possibly hours, but I'm definitely going to build my own copy of mpv because I just need it to start up fast. Also, I love those framed photos of old consoles behind you. At the time when it was popular, the Game Gear really was the best handheld.
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.
It'll be interesting to see if the immutable Linux variations will drive more activity towards these packaging formats.
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.
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.
i love snaps for its CLI feature.
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).
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).
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
The gap between regular packages and Flatpaks is smaller than the gap between Flatpaks and Snaps.
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.
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 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 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.
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.
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)
@TheLinuxEXP I wonder what is the Linux district you would go for if you want to customize it and it has good support but has a gui (NOT ARCH)
Gentoo for customizability and also has good gui
Thanks.
enterprise storage costs a lot, and why flatpaks put everything in /var partition? Can we change that to other mount point eg. /test ?
Its awesome we have ao many options. Everyone has the choice to use the ones they like!
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.
Good video.
Literally had trouble with steam flatpak not seeing my external SSD. Switched to system package on Fedora KDE 39 AND it works now
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.
You should include compiled images as well, because I have noticed significant differences, especially on handbrake when compiling it myself, 2 3X difference
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 :|
that permission settings was added in plasma 5.27.4 located in system settings and then under applications
Would you do a performance/feature comparison of popular file managers?
There are some libraries not available in Fedora's repositories, so i download ubuntu packages to implement the missing package
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
I love flatpaks!
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 wish these existed for the CLI.
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.
A unified format would be great :) We need this. Linux needs a unified way of handling software.
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.
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 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.
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.
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 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
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...
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.
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 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
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.
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.
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.
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...
Can we have XAMPP in flatpak form for Linux please?
Didn't try distrobox, a normal, regular old binary file.
Can you increase font size? I am vision impaired ,I cannot see small font
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.
It would be interesting to throw Docker in there, at least for apps that have a Docker version.