Anyone else starting to favor Flatpak over native packages?

I don't like flatpak or snap or any of them. System libraries exist for good reason, just because your computer is stupid fast and you have enough disk for the library of Congress a couple times over doesn't mean you should run a veritable copy of your whole operating system for each program. IMO it's lazy.

Sandboxing is a different thing though, if that's the purpose then it's doing it right.

For a long time now, if a flatpack is available and maintained, I use it.

Quite the opposite, after fiddling with it for six months I fully uninstalled flatpak and deleted the directory to get away from the fact it kept downloading copies of nvidia drivers when I had moved to an AMD a year ago, and the drivers were locked from being manually removed even after I uninstalled all flatpak packages.

I'm an Arch user, trust me when I say I read the documentation.

After wasting hours on it I nuked it.

I accept that I'm in the minority on these things, but I value simplicity really highly, and I mean "simple" as a very specific concept that's different from "easy". It can be harder to resolve library dependencies on a system where everything is installed using the native package manager and common file systems, but nothing is as "simple" as ELF binaries linking to .so files. Nested directories branching off of / is "simpler" than containers.

Do I have any practical reason for preferring things this way? Not really. There are some ancillary benefits that come from the fact that I'm old and I already know how to do more or less anything I need to do on a Unix system, and if you tell me I need to use flatseal or whatever, I'd rather just use users and groups and tools that have been fine for me for 25 years. But that's not really why I like things this way. I have no issue with embracing change when it otherwise appeals to me --I happily try new languages and tools and technology stacks all the time. What it really is is that it appeals to the part of my brain that just wants to have a nice orderly universe that fits into a smaller set of conceptual boxes. I have a conceptual box for how my OS runs software, and filling that box with lots of other smaller little different boxes for flatpack and pyenv and whatever feels worse to me.

If they solved practical problems that I needed help solving, that would be fine. I have no problem adopting something new that improves my life and then complaining about all the ways I wish they'd done it better. But this just isn't really a problem I have ever really needed much help with. I've used many Unix systems and Linux distributions as my full-time daily use systems since about 1998, and I've never really had to spend much effort on dependency resolution. I've never been hacked because I gave some software permissions it wouldn't have had in a sandbox. I don't think those problems aren't real, and if solving them for other people is a positive, then go nuts. I'm just saying that for me, they're not upsides I really want to pay anything for, and the complexity costs are higher than whatever that threshold is for me.

I use Flatpaks for everything I can. I like how Flatpak keeps apps in a container isolated from my system. Also, Flatpaks contains every lib in every version I need for my installed apps, which means It does not rely on my system libs, and I like It, cause my system libs is to make my system works only.

Flatpaks are just the future of packaging

ag to be honest I'm so frustrated by having to remember what package manager was used for installing which binary. I don't have time for this horse shit

I want a stable OS, but I want the latest versions of applications (programs) without messing up anything. For me flatpak and snap meet that need, but I prefer flatpak.

I'm glad to see you've gotten a ton of feedback here, and I just wanted to add another comment in support of flatpaks and image-based computing. I've been using Linux extensively for about 15 years now, mostly Arch and Debian Sid. I've been a distro packager, and I've compiled plenty of my own apps over the years.

This past year I took Fedora Silverblue for a spin after following the project for quite some time, and I am convinced that the image-based system approach, coupled with containerized and sandboxed userspace applications, is the future of Linux for most users. It makes so much sense from nearly all perspectives; whether security, reliability, or flexibility.

Integral parts of the system are mounted read-only by default. Simple commands can rollback unwanted changes, upgrade to a new distro release, or even sideload an entirely different OS. System updates are automated, as are flatpak updates, and there is little-to-no risk to stability due to the very nature of the essentials-only system images. And if something catastrophic did happen, you're just a reboot away from rolling it back.

Consider for a moment the collective energy and time that distro package maintainers must undertake on a weekly basis. Much of it simply repeated by each distro, building the same applications over and over again. Flatpaks are built once and deployed everywhere. Think of the collective potential that could be directed elsewhere.

Couple this with containers and the choice of distro matters even less. Arch, Debian, Ubuntu and Fedora are just a keystroke away. Yes, you can run containers on any distro of course, but you don't gain any of the other ostree benefits mentioned above.

I have since moved all of my workstations to Silverblue and I don't see myself ever going back to a traditional system again. If anything, I may start automating my own image deployments, similar to Universal Blue.

Yes, flatpak as a platform still needs some work, and so does ostree, but both are evolving quickly and will only get better with time.

To others who complain about needing Flatseal...in my opinion, this is a feature to be embraced, not loathed. Sane defaults are rarely sane for everyone, and Flatseal exists to give you complete control over what an app can or cannot see and do.

9/10 desktop applications I use are flatpaks. Am on Arch and even when there's an AUR for a package I'd prefer to use Flatpak. Just so I can use Flatseal to control permissions access on my applications.

Yes, but only for apps that which I want to be on the very latest versions. One might ask why I don't use a rolling release distro, that's because I prefer a solid LTS base.

Probably never. They're my third option after native packages and built-from-source packages/installs either manually or using the AUR. They're convenient and the only option I tolerate of those newer package styles (Flatpak/Snap/AppImage), but seemingly having to download a new 800+MB runtime for small 32MB applications is ridiculously wasteful and I wouldn't touch them if I didn't have at least a TB of storage.

This is exactly what flatpaks were meant to do. Simplify the program deployment across all distros

I'm running Ubuntu now and I'm in Snap hell.

It works well enough for some very basic apps, but for me personally, Snap has created far more problems than it has solved. With Firefox, for example, it makes it a lot harder to use some extensions, and FileBot is entirely useless without file system access (I mean, that's the entire point of the program).

I've heard Flatpak is better but my experience is somewhat limited. It could hardly be worse, though...

100%. I just wrote a long post surmising this somewhere, but I'm switching my 5 year old Arch install to something like Debian Stable/Testing because I use almost entirely Flatpaks for my user applications (I would do 100% of them if every app I used had a Flatpak), and it's really just a much better idea to run bleeding edge on only the stuff you care about instead of an entire system.

It depends. Kind of prefer Flatpaks as they are always working as expected on any distro, but some of them are giving me just too much struggle.

For example, dealing with sandboxing, or especially VSS code app. Yes, there are instructions, but then I install Golang SDK via Flatpaks the hard way (using CLI) for Go development, then having a nightmare trying to setup everything in vss code. Then how tf should I access go binary within my host terminal?

On Arch Linux I just tend to install from official repos, while the rest of apps - from Flatpaks.

Personally I don't like the way they are sandboxed, bit as long as it works I am fine.

I personally still prefer native, but flatpak is my goto for whenever something isn't working or when the official repos are outdated.

The other day I tried to use Malt for blender but it wouldn't work on the native version because it was using the wrong version of python. The flatpak version works perfectly with Malt, but for some reason I don't feel like troubleshooting, the OptiX denoiser doesn't work.

Still though, flatpak is a welcome option and is way better than snap.

Nope, don't like them. Nor snaps. I find the sandbox nature annoying and many developers don't actually seem to understand it correctly anyway meaning you have to use flatseal etc. Then having to deal with some apps writing config within the sandbox and some writing it outside the sandbox...

My order of preference is generally I pick the "official" supported version as opposed to any community maintained ones. Then within that:

• Install via the language's package manager (cargo, npm, pipx, cabal etc.)
• Appimage
• Native package (.deb, .rpm etc.)
• Plain binary
• Build from source
• Snap
• Flatpak

For convenience, it's great. The sandboxing is good as well. Flatseal is a must have for me, though.

I had fedora installed the last few years, and was digging flatpak.... until I wasn't. One day I ran out of disk space - 230 Gb of flatpak dependencies. I run a pretty slim system, so what the actual heck? Did some research, learned how to flush cached and redundant packages, shrunk my flatpak deps to.... 150 Gb

I've since been trying Endeavor

I still favor native packages, but I don't have a problem with Flatpaks. I'll use them when a program isn't available in the repo or there's a compelling reason to have a never version of an application. I'm on Debian Stable, so I'm obviously not obsessed with having the newest, shiniest version of everything.

Containerised everything is the future of computing and I think we'll look back on how we do things currently with horror!

But yes, I am slowly starting to use more contained desktop applications. Server-wise, everything I deploy is now in containers.

When using Fedora Silverblue, there is no other option, which I do!

No, because the updates are in GBs and my internet is limited. I'd rather install nixos and spend time learning it than install flatpak apps.

Nope. I’ve been running Debian for the past six years after I got tired of messing with arch. I’m over my shiny new thing syndrome and am happy with old but stable software. I’ve tried some flatpaks but the only two that I use are Spotify and signal. They take a lot of space and updating is slow.

Flatpak and Snap definitely make installation more simple. The packages come with their own dependencies so you have way less issues with conflicting dependencies. I like them when they are officially supported by the distribution or developer, but I prefer the official installations over supporting a random person making a package (not sure if this is a thing with Flatpak, but with Snaps that was definitely a thing).

Some software really benefits from not begin inside flatpak though, I had to switch back to the deb version of Visual Studio Code as the integrated console didn't have access to some software outside the package and was also logging weird errors.

I use system packages for everything unless I need a newer version of a specific package for some reason.

Yeah, having apps updated in the last year is enjoyable

i avoided flatpacks before.
but now that i tried out silverblue and had to rely heavily on them,
i have to admit that flatpacks are not nearly as bad as i thought.

the only issues i encountered are with steam (might not start propperly on first launch)
and with ides(terminal starts inside the sandbox)

other than that it works great.

No, because I don't have a very powerful computer

Even if I did, I would still prefer to have native applications because it would be more permissive

I use flatpaks mostly. Flatpak dependencies (runtimes) are stored separately from the host system so and don't bloat my system with unwanted libraries and binaries. App data and configs are stored separately and better organized. Everything runs in sanboxes. I use overrides extensively. All these are very convenient for me.

I was using Flatpak and Toolbx exclusively until I discovered Nix. It's much better than using those two.

I didn’t like them before I used flatseal. Now I love them.

I prefered AppImages, but now that I'm on Nix, I've gone back to native. Native packages work well in the NixOS ecosystem.

In place of snap OF COURSE.

I can state without any doubt that i had problems with 80% of the programs coming from snap..

No

Definitely not me. I am on LiveUSB right now which makes my disk volume limited. And native packaging satisfies my needs (even when packages are old)

Absolutely not, and this article goes into quite a few reasons why:

https://blog.brixit.nl/developers-are-lazy-thus-flatpak/

Sadly there's reality. The reality is to get away from the evil distributions the Flatpak creators have made... another distribution. It is not a particularly good distribution, it doesn't have a decent package manager. It doesn't have a system that makes it easy to do packaging. The developer interface is painfully shoehorned into Github workflows and it adds all the downsides of containerisation.

While the developers like to pretend real hard that Flatpak is not a distribution, it's still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it's still a distribution you need to target. Instead of providing seperate packages with a package manager it provides a runtime that comes with a bunch of dependencies.

If you need a dependency that's not in the runtime there's no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you're also the maintainer of all the dependencies in this semi-distribution you're shipping under the disguise of an application. And one thing is for sure, I don't trust application developers to maintain dependencies.

Even if there weren't so many holes in the sandbox. This does not stop applications from doing more evil things that are not directly related to filesystem and daemon access. You want analytics on your users? Just requirest the internet permission and send off all the tracking data you want.

Developers are not supposed to be the ones packaging software so it's not hard at all. It's not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in.

Another issue is with end users of some of my Flatpaks. Flatpak does not deal well with software that communicates with actual hardware. A bunch of my software uses libusb to communicate with sepecific devices as a replacement for some Windows applications and Android apps I would otherwise need. The issue end users will run in to is that they first need to install the udev rules in their distribution to make sure Flatpak can access those USB devices. For the distribution packaged version of my software it Just Works(tm)

For me the perfect example is GNOME Builder (I use KDE Plasma) but this package has it all. No, you dont need to download any dependencies, the sandbox handles it all!

Flatpaks are okay but they take too much space

I prefer my binary over every other universal packages.

I haven't used any flatpacks, mostly because they don't seem to have a good solution for running terminal programs. (Also I don't like that the application developer chooses the permissions to expose rather than the user.

However, I have been using bubblewrap which is what flatpack uses under the hood to sandbox. This allows me to run both gui and non-gui programs, and I have the control of exposing the minimum required permissions that I'm comfortable giving an untrusted piece of software.

Flatpaks are my second choice when there isn't a recent enough version in the repos. They're fine but take 1. too much storage space, and 2. are usually slower

I'd rather have 5GB of binaries than deal with unmet dependencies one more time (despite many people claims, it is still easy to fall into), my only criticism for flatpak though, is that any kind of modification for a file requires you to navigate through at least ten directories.