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 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.
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)
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 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
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.
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
@@ContraVsGigi 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 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. :)
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?
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.
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.
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...
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.
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.
Finally a RUclipsr with a GOOD VPN placement. That's the reason I subbed xD
Год назад+6
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.
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 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.
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!
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...
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.
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.
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
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.
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
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.
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...
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...
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
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 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!
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.
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.
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).
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 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!'
@@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
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.
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 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 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)
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).
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.
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!
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.
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.
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.
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 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.
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.
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.
A couple years ago, I had all of them on my Linux Mint laptop. Mostly because some of the applications I wanted to use only came in one of the "universal" package formats. Yes, they all worked, but some took much more RAM than the .deb packages.
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
You should include compiled images as well, because I have noticed significant differences, especially on handbrake when compiling it myself, 2 3X difference
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
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 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
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.
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 :|
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.
Snaps broke too much for me to see them as an option at all, had to stop using ubuntu because dist upgrades could reinstall snap (Few proposed solutions didn't work). Though I definitely prefer debian testing now that I've switched, and I've had very few issues with flatpaks
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.
I've always wondered with the isolation features why Web Servers, PHP, Python, and Docker containers aren't available as Flatpaks or Snaps. It just seems to me that they would be perfect instancing and isolation.
@@bigpod If your docker instance gets hit with ransomware you lose your whole drive, not just the instance. And if your docker instance gets hit with privilege escalation the attacker has access to the whole system not just the instance. That's why docker recommend not using their default install in production and instead recommend installation as a non-root user or rootless mode. With all the technologies they use that are similar, I just don't understand why they don't go all the way and do it properly. Per user isolation would also be a godsend on shared hosting if each instance had it's own self contained files instead of sharing files.
@@ericneo2 Btw they dont use similar technologies under the box but the same unly difference is that flatpak uses user namespaces while docker uses namespaces, yes if something escapes from docker container they will be a root user on host which is why they introduced docker rootless which is now recommended which uses user namespaces like flatpak. So technologies are the same not similar
"Flatpaks take more memory and more storage" not a problem on my 32GB RAM + 1TB NVMe Slimbook Excalibur! I installed Fedora Silverblue and, despite the current grub incident (do NOT update Silverblue to 41 / Rawhide) I just... Don't care anymore. Like, I just install a Flatpak, choose when to update it and everything just works :)
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 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?
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)
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 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.
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.
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.
@@ContraVsGigi 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.
At this point the fact that snap doesn't work over nfs and Ubuntu one depends on snap is astonishing.
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 😁
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.
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 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
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.
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...
If flatpak had a way to run the apps using a file like AppImage it would be the best package system.
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
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.
Finally a RUclipsr 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.
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 use the AUR, btw
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.
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!
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...
Simply apt for me with a flatpack now and then.
Me too, except for one app that ships as AppImage for some reason (Musescore)
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
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.
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
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 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
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.
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...
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...
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
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 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!
This was vary helpful. Me being new to Linux. Thank you.
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.
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
Best packaging format for linux: NIX, change my mind.
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.
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 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!'
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
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.
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 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 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)
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).
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
The gap between regular packages and Flatpaks is smaller than the gap between Flatpaks and Snaps.
It'll be interesting to see if the immutable Linux variations will drive more activity towards these packaging formats.
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.
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!
Question: so appImages are like the old Portable Programs in windows? Something you don't install, just execute?
yes
Flatpack is the way forward imo
thanks for the benchs im curious with arch packages and rpm
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.
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.
Snaps would work in theory if Canonical wouldn’t half-ass them. Like its sooooo apparent.
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.
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 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.
Its awesome we have ao many options. Everyone has the choice to use the ones they like!
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.
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.
A couple years ago, I had all of them on my Linux Mint laptop. Mostly because some of the applications I wanted to use only came in one of the "universal" package formats. Yes, they all worked, but some took much more RAM than the .deb packages.
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
flatpak my beloved
You should include compiled images as well, because I have noticed significant differences, especially on handbrake when compiling it myself, 2 3X difference
When was the last time we all Linux users agreed on something?? 😂😂😂
Yes 🤓
Didn't try distrobox, a normal, regular old binary file.
for those looking for short answer currently, flatpak is your best option without a doubt.
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 love snaps for its CLI feature.
A unified format would be great :) We need this. Linux needs a unified way of handling software.
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
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 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
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.
Would you do a performance/feature comparison of popular file managers?
enterprise storage costs a lot, and why flatpaks put everything in /var partition? Can we change that to other mount point eg. /test ?
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
i wonder why davinci resolve is not available as a flatpak, i mean it will be easier to install, update etc.
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.
Excellent video 👍 Thank you 💜
Snaps broke too much for me to see them as an option at all, had to stop using ubuntu because dist upgrades could reinstall snap (Few proposed solutions didn't work). Though I definitely prefer debian testing now that I've switched, and I've had very few issues with flatpaks
For now... good old native distro packages :)
There are some libraries not available in Fedora's repositories, so i download ubuntu packages to implement the missing package
Thanks
@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
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.
I've always wondered with the isolation features why Web Servers, PHP, Python, and Docker containers aren't available as Flatpaks or Snaps. It just seems to me that they would be perfect instancing and isolation.
docker itself is containerization that uses most of same kernel technologies as flatpak
@@bigpod If your docker instance gets hit with ransomware you lose your whole drive, not just the instance.
And if your docker instance gets hit with privilege escalation the attacker has access to the whole system not just the instance.
That's why docker recommend not using their default install in production and instead recommend installation as a non-root user or rootless mode.
With all the technologies they use that are similar, I just don't understand why they don't go all the way and do it properly. Per user isolation would also be a godsend on shared hosting if each instance had it's own self contained files instead of sharing files.
@@ericneo2 Btw they dont use similar technologies under the box but the same unly difference is that flatpak uses user namespaces while docker uses namespaces, yes if something escapes from docker container they will be a root user on host which is why they introduced docker rootless which is now recommended which uses user namespaces like flatpak.
So technologies are the same not similar
@@bigpodDude lower the elitism you are coming across as a total asshole.
"Flatpaks take more memory and more storage" not a problem on my 32GB RAM + 1TB NVMe Slimbook Excalibur! I installed Fedora Silverblue and, despite the current grub incident (do NOT update Silverblue to 41 / Rawhide) I just... Don't care anymore. Like, I just install a Flatpak, choose when to update it and everything just works :)