Native vs. Flatpak

hdansin

I have always preferred native packages to flatpaks, but using the software center on Ultramarine/Fedora has me wondering. What are the significant advantages of native apps over flatpaks? Does it depend on the application? Are flatpaks better for certain things (besides being more Distro agnostic and sandboxing)?

The Fedora software center seems to default to flatpaks, but Ultramarine adds the non-free repos so you can choose an rpm. I also had a case where a native app fail to run, but the flatpak worked (OPENRCT2). If there is an FAQ that answers these questions, please point me there so I don't waste your time. I know that sometimes the flatpak is unofficial, in which case the official native version is obviously preferable, but given the choice between two official, fully updated packages, is there a user noticeable difference?

For Solus I've been wondering whether the new software manager will prefer flatpaks or native packages.

Brucehankins

hdansin One advantage of native apps is theming. Flatpak and snap apps don't play as nicely with themes outside of Breeze and Adwaita, and even then they don't always integrate the best.
Another potential advantage of native apps is permissions and system access. Since Flatpak apps are "sandboxed" they don't always have the same access or capabilities of native packages. KDE has done a lot of work to integrate Flatpak permissions into settings and apps like Flatseal make managing permissions really straightforward.
Just my feelings on it.

tomscharbach

I prefer Flatpak for some outward-facing applications because Flatpaks run in a sandbox, providing a level of additional protection.

brent

1) you know who curated it vs you don't know who curated it. I would pick #1 all day long
2) all flatpaks and appimages are 97% of a real application since the sandboxed stuff cannot assimilate spellcheck libraries, some browser plugins, etc. They have limitations vs native
3) flatpak is always Plan B for me is there if no rpm or eopkg. a great Plan B, but plan b all the same
2 cents

qsl

What I had gathered from asking people to do flatpak versions of their applications was: 1. flatpaks inherently lead to bloat. Apparently you will have redundancies as opposed to something integrated, which can mean performance issues and increased storage. This seemed more reactionary to the way MS does things, and wanting a sleek, clean OS.

People can always compile an application to their liking, essentially having a custom build. There is also a certain differentiation between distributions, using natively supported applications to draw someone to a particular flavor rather than being distribution agnostic. There may also be intricacies something native can take advantage of.
Support. Something native should have better support over time, where it seems flatpaks are often orphaned and an afterthought.

I'm still rooting for flatpaks (or something similar) as it opens the door for commercial software on linux and reduce fragmentation. It gets rid of the complaint "but will it run on linux" and puts OS on equal footing (instead of defaulting to MS since you will have the best software selection).

brent

qsl
3b. flatpak update -y && flatpak remove --unused -y **
**credit to @WetGeek , I try to manually update at least weekly

While I love Flatpaks when there is no native....I still abhor the linux distro trend away from Native and pushing users towards more Flats/Snaps. Including Solus's intentions to do that (thought I read that sentiment somewhere forgive me if I got it wrong). I can't think of any good that will come from having less curations and more Snaps/Flats/Appimages. I can't see this a good trend at all but it's possible I've not heard all sides of the issue.
edit>sp

qsl

brent

Give and take.

Argument against native/curations is trusting someone else's judgement what is best for my use case. For most things, it may be a case of "good enough" and learning to live with the quirks of the application. But it really, really sucks when you want an amalgamation of things only offered natively on different distributions beyond this distro is optimized for this purpose.

Also, again, the commercial aspect weighs heavily on me. Especially for niche apps, there is no justification for a developer to make something that works on all distros (or at least beyond a vanilla user to make work on their distro). Flatpaks solve this by only having to maintain one release.

Having something like RX 10 on linux is a game changer and opens the door to people who would have forgone linux from the onset since the programs they want to run aren't available there.

Essentially argument of integration vs. modular. Integration means more finite control and optimizations. Modular means flexible but with added cruft.

Pick your poison.

[deleted]

As far as I know, native uses system libs instead of whatever's bundled with Flatpak. So since there are some optimizations applied in distros like Solus, using native packages may yield actual performance benefit.

WetGeek

[deleted] So since there are some optimizations applied in distros like Solus, using native packages may yield actual performance benefit.

Good thought. I've also wondered why folks would sometimes prefer to store a long list of dependencies with each application. The purpose of libraries in the first place is to prevent that by allowing multiple applications to link with a library as needed, rather than including the same code in each app.

For one or two apps that you need and can't get any other way, flatpak makes sense to me. But to adopt it as the only source for all the apps in a distro, as seems to be a popular theme these days, I'm not such a big fan.

Semenov

I prefer native packages and AppImage.

Soutaisei

Personally prefer native packages. While flatpak sounds great and is. I only use it for small time applications that don't require too much work to make them work as I want them (themes or getting Steam setup etc.)