Is there a downside to Flatpak?

0485@lemmy.world to Linux@lemmy.ml – 172 points –

Basically title.

I’m wondering if a package manager like flatpak comes with any drawback or negatives. Since it just works on basically any distro. Why isn’t this just the default? It seems very convenient.

165

There is some drawback. The main one : app can't communicate with each other.

Example firefox and his extension keepass. As keepass can't communicate with firefox, you have to open both apps and switch their windows.

You can use flatseal to manage communication between apps but that's not an easy process and may prove a security issue if you don't understand the technical jargon.

You only need flatseal on GNOME. KDE has it baked into the settings

Thank for the information. i didn't know since i use vanilla os :)

Kde has many things baked into the settings that gnome hasn't. GNOME is just more beautiful (and has PaperWM which is why I have to use GNOME)

can you elaborate on this? I'm on nobara and I had a hard time trying to get flatseal to work for syncthing

1 more...

to be fair there is a portal, it need to get implemented tho

1 more...

1- It takes a lot of space. jUsT bUy a bIgGeR dRiVe --stfu I'm not going to spend money for you to waste it

1- a) Everyone assumes you're an American with 20Gbps symmetrical fiber optic. My internet can't handle 2+ Gb downloads for a fucking 50 Mb app bro

2- Duplicate graphics drivers. Particularly painful with Nvidia

3- It puts a lot of security work with distro library trees straight into the shitter

4- Horrendously designed system for CLI apps (flatpak run org.whocares.shit.app)

5- Filesystem isolation has many upsides for security but also it can cause some pain (definitely nitpicking)

Where in America is there 20Gbps symmetrical fiber? Everywhere I know tops out at 1gbps if you are lucky that your ISP isn't shit, and lots of areas are still on slow cable.

In my area my options are 200mbps cable or 100mbps ADSL (which inexplicably costs more than the cable Internet)

Maybe is an hyperbole I have optic fiber straight to my door here and is 10gbps tops but usually it works around 80% of that with some conditions. And it's not symmetrical I don't recall the up speed tho.

Best I've ever had was like 60mbps down. Might be a budget thing though, I refuse to pay more than £30/month for internet

Lived in 8 different states in the US - never had anything above 1 Gbps. Typically been 300-500 mbps, with only the past and current state state where I’ve gotten 1gbps. Poster is just assuming because we’re a first world country that we have good internet. We don’t. I hear Europe has better speeds than us.

All of this. Plus often it just doesn't work.

And no. I do not want to blind fiddle with the permissions to fix it.

Yes, I love it and don't get me wrong but there are many downsides and they all result from poor planning and/or bad decisions around how flatpak was built. Here are a few:

  • Poor integration with the system: sometimes works against you and completely bypasses your system instead of integrating with it / using its features better. To me it seems more like the higher levels are missing pieces to facilitate communication between applications (be it protocols, code or documentation) and sometimes it is as simple as configuration;
  • Overhead, you'll obviously end up with a bunch of copies of the same libraries and whatnot for different applications;
  • No reasonable way to use it / install applications offline. This can become a serious pain point if you're required to work in air gapped systems or you simply want to level of conservation for the future - it doesn't seem reasonable at all to have to depend on some repository system that might gone at some point. Note that they don't provide effective ways to mirror the entire repository / host it locally nor to download some kind of installable package for what you're looking for;
  • A community that is usually more interested in beating around the bush than actually fixing what's wrong. Eg. a password manager (KeePassXC) and a browser (Firefox/Ungoogled) both installed via flatpak can’t communicate with each other because developers seem to be more interested in pointing fingers on GitHub than fixing the issue.

Flatpak acts as a restrictive sandbox experience that is mostly about "let's block things and we don't care about anything else". I don't think it's reasonable to have situations like applications that aren't picking the system theme / font without the user doing a bunch of links or installing more copies of whatever you already have. Flatpak in general was a good ideia, but the system integration execution is a shame.

The double-edged sword of isolation.

On the one hand, poor communication between apps and waste of storage.

On the other, relative safety from malicious applications, or from otherwise-safe applications built on top of a thousand libraries none of which have been audited by the dev.

I don't know how it's going to go down, but I suspect something will come along to address these issues and snatch the market away from Flatpak.

but I suspect something will come along to address these issues and snatch the market away from Flatpak.

I believe it could only be fixed by a team from GNOME or KDE, they're the one in a position to develop something like Flatpak but deeply integrated with the system instead of trying to get around it.

For what's worth Apple did a very good job when it came to the isolation and containerization of desktop applications, but again only possible because they control both sides.

Apple enforces a LOT of isolaton, they call it sandboxed apps and it is all based on capabilities, you may enjoy reading this. Applications get their isolated space at ~/Library/Containers and are not allowed to just write to any file system path they want.

A sandboxed app may even think it is writing into a system folder for preference storage for example - but the system rewrites the path so that it ends up in the Container folder instead. For example under macOS apps typically write their data to ~/Library/Application Support. A sandboxed app cannot do that - and the data is instead written beneath the ~/Library/Containers/app-id path for that app.

And here's how good Apple is, any application, including 3rd party tools running inside Terminal will be restricted:

I bet most people weren't expecting that a simple ls would trigger the sandbox restrictions applied to the Terminal application. The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.

I believe this was the best way to go about things but it would require to get a DE team to make it in a cohesive and deeply integrated with the system. Canonical could do it... but we all know how Canonical is.

The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.

No, Flatpak isn't the problem here, portals for these things exist. The problem is that apps would have to use them, and unlike Apple, there's noone restricting the old / unrestricted ways of doing things... So apps usually don't port over to the portals.

Even where the unrestricted APIs stop working, like with screen capture and Wayland, apps are excruciatingly slow to port over, because they don't get kicked from app stores for it, and because many users can still fall back to using the old system.

While what you say is true, the "portals" were an afterthought, an imposition to developers and a cumbersome and poorly documented solution. Just like the theming and most other things.

Instead of bluntly blocking things why can't Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path? A GUI capable of automatically enumerating those resources and a bunch of checkboxes like "app X and Y both have access to socket at /var/run/socketY would also solve most of the issues.

Instead of bluntly blocking things why can't Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path?

Because the user getting a hundred popups on app start for various files the app needs isn't exactly a usable experience. Also, blocking the app's main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too.

Aside from apps using the APIs meant for the purpose of permission systems, there's no good way to make it work.

Because the user getting a hundred popups on app start for various files the app needs isn’t exactly a usable experience

It doesn't but until apps can declare on a simple config file what paths they require that's the way things should work. I guess that would motivate the developers who are packing into Flatpaks to properly list whatever files the application requires. If they don't, then the application will still work fine but be a bit annoying.

Also, blocking the app’s main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too. Aside from apps using the APIs meant for the purpose of permission systems, there’s no good way to make it work.

Yet, macOS does and things don't go that bad, on the example how do you think they do it for command line tools? The system intercepts the request, show the popup and wait for the user input. I've seen the same happening with older macOS applications that aren't aware it could happen and yes, the main thread is blocked and the application seems to crash.

I thinks it's way better doing it this way and still have a somewhat productive container and isolation experience than just bluntly blocking everything - something that also breaks apps sometimes.

until apps can declare on a simple config file what paths they require

They can, and always could. Apps aren't doing it, most Flatpaks have just blanket "allow ~/Downloads" or "allow all of home" permissions by default - or no file permissions, and you have to go grant them manually yourself.

Again, unless apps actually support it, no matter how good the security system is, it won't work out.

Thanks for your comment! Both positive and negative for sure.

To the duplicate libraries

https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker

Do you know if flatpak leverages the memory side of this? With shared libs, you only keep one copy in memory, regardless of how many applications use it. Makes application launch faster, and memory usage lower.

For flatpak, it of course will load whatever it needs to load, but does it manage to avoid loading stuff across other flatpaks?

Thats a good question that came to my mind too, idk

For me it's lacking in user friendliness. Go easy on the downvotes if I'm doing it the hard way.

  • Flatpaks aren't really single-executables. You have to use to the flatpak command to run them.
  • I can't just say flatpak run firefox, I have to use the full app-id which could be quite long.

Yes, I could make this simpler with scripts or aliases but how hard would it have been for Flatpak to automatically do this for me?

I'm using KDE and when I download a flatpak it automatically creates a .desktop file. I think gnome does this too if I'm not mistaken. I do have to restart or relogin for it to put the file there but that's not that bad IMO.

I'm on Endeavour xfce and the .desktop files are just there immediately. I never even knew this wasn't the case on other systems

I think I've been having an issue with the Steam Flatpak where after updating, the .desktop file breaks. If not, my icon is broken for different reasons. Either way, I've been running Steam through the command line for ages.

I don't put anything on my desktop but if I put Firefox in my krunner (alt-f2) box the flatpak shows up right away after installation

I agree, tho trivially solvable with aliases and Desktop app definitions, but still an extra step.

It's HUGE. That's the biggest downside for me. I'm always use a deb/native package first because they are way smaller.

Of course they are. they share dependencies with other software. flatpaks bundle all dependencies,which is great for sandboxing,even though some sort of break the rule and share some,they are still sandboxed.

Unless you "firejail" or "bubblewrap" your software, security is much better OOB for flatpaks.

That's a myth. Security of flatpaks depends entirely on the given permissions, and since most flatpaks just set their own permissions on installation, or require filesystem access to work, there is no meaningful difference in security OOB.

Flatpak apps cannot set their own permissions "on installation". If flatpak tells you some weather app uses only the network permission then that is all the app is going to get.

For an app to be able to change its own permissions, it first needs permission to the flatpak overrides directory. Any app that does this gets an "Unsafe" designation in gnome-software.

Also about most apps requiring filesystem access to work: I have 41 flatpak apps on my system (Silverblue so everything is flatpak). Only 6 have access to my home or Documents directory. (11 apps requested full filesystem or homedir permission, but 5 of these work perfectly fine after I turned off their permissions in Flatseal).

Notably, "large attack surface" apps like Thunderbird or Firefox don't have access to my Documents. File uploads and email attachments go through the file picker portals.

Those dependencies adenoid and no kept Upton date, unlike deb/rpm installed stuff. Best sandbox to not compromise your system. Also hope that sandboxing is done right...

The worst part of flatpaks is that they don't get to see the actual path of files that they open. Instead, they get a /var/run/1000/blah proxy. The proxy is forgotten after you reboot, so any flatpak that memorized that path is holding a bunch of dead links.

  • overly verbose way to launch them in terminal
  • can sometimess not even respect your gtk/qt theming
  • sandboxing/permission system can lead to you trying to figure out which directory you need to give access to when you want to save file if it wasn't preconfigured
  • uses its own libraries and not system libraries, want to play the hit new AAA game with steam flatpak? get fucked it requires a mesa commit that was merged 8 hours a go and you're stuck on 23.0.4 and can't use the git release.

Flatpak probably has it's specific uses like trying to use one piece of proprietary software that you don't trust and don't want to give it too much access to your system, or most GUI software clients having an easy way to install Discord on your Steam Deck (no terminal usage, Linux is easy yay), but native packages 99% of the time work better.

uses its own libraries and not system libraries, want to play the hit new AAA game with steam flatpak? get fucked it requires a mesa commit that was merged 8 hours a go and you're stuck on 23.0.4 and can't use the git release.

Can't you just install a git snapshot of mesa in a flatpak and use that? Then it'd be an upside

The downside is having to do that manually. Kind of ruins the whole point of it. Flatpaks will remain out-dated until the maintainer has time to push it out. Forever behind.

There's the org.freedesktop.Platform.GL{,32}.mesa-git runtime(?) so that seems wrong. What app always needs the latest snapshot mesa version anyway?

According to the example, a hit new AAA title on steam might need it.

That doesn't mean it constantly requires a mesa git snapshot.

1 more...

It's great for user apps, gui apps, and sandboxing. It's terrible for cli apps, libraries, development, and integration.

1 more...

Some people don't like it because it uses a bit more storage and can start a bit slower, (I think) they can't be used for system packages, and I've also had some issues with theming

This should be pinned somewhere https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/?ref=ypsidanger.com

Edit: the speed shouldn't be a real issue. You may measure a difference but that's not an issue as it was with snaps until they improved upon it.

Using flatpak on low end devices (like Linux phones), I can tell you from experience, the speed liss is noticeable. Specially for application startup. As is the resource overhead.

That's a fairly good point. On mobile startup can be crucial because sessions are short in comparison to desktop where you have longer sessions and startup time is negligable (even the slow startup times of snaps could be ignored for e.g. a video editing session)

Low specs shouldn't keep the community from moving into newer technology.

Precisely. I've been playing with Mobian on a One Plus 6 (works great) and while I really like the idea of using mostly sandboxed app much like things work on Android, right now it certainly negatively impacts the experience.

One thing I always wondered is whether libraries in memory would be duplicated or not. I have seen a lot of people talking about storage space which is cheap and shouldn't really be the focus for desktops. But I haven't seen anything about in memory usage.

Good question. With 16 GB RAM 8 haven't seen RAM issues for normal stuff

Me neither but I if we're considering having all but the core of the distro in Flatpacks, this policy might mean Linux becoming less accessible to more modest configurations.

Unless Flatpacks deal with it somehow like regular packages do. If two app packages contain the same library within (as opposed to packaged in a dependency), can Flatpack figure out they're the same and share code memory between the two? For library packages with two apps depending on different versions of the same third party flatpack, does it assume the newer version can be applied to both, optimizing memory usage? If so, wouldn't that break the premise of flatpacks?

Can I convince my autocorrect that flatpacks and flapjacks are different things?

Inquiring minds want to know.

I think its biggest weakness is also its biggest strength: isolation. Sometimes desktop integration doesn't work quite right. For instance, the 1password browser extension can't integrate with the desktop app when you use flatpak firefox.

That’s a good pint actually. A double edged sword for sure!

No proper estimate of download size.

To say nothing of a signed manifest of contents. It's like 1995-era package management was lost on the kids who built this dreck.

This is one of the biggest annoyances I've come across with them for sure.

For me, the question is why I should add an extra layer of complexity. If the things I use already work well using apt, and if most things are bundled in the default distro install, then my life is already good.

This all depends on your software needs, if course. Some people are using a lot of new stuff, so the above setup leads to annoying situations.

Flatpak is a distro on its own, but with original dev support. Its like a Linux Distro replacing others.

So it adds complexity but with the potential to remove it from the OS. For example Libreoffice, Browsers, Thunderbird etc are huge and its a good approach to use official versions here.

Then what's the point in having different distros lol we don't have duplication for the sake of duplication there are reasons why there are different distros, philosophies and packaging method. I see this mistake from many usually newer Linux users, there are different distros because there is a point in packaging the OS differently.

Flatpak for example completely abandons makig apps use patched system libraries. Or having different packages for different init systems. Or , god forbid, supporting BSDs

I dont know tbh. Flatpak is a bit like Android apps I think, but those apps only have a single OS to support.

Some developers don't want to deal with building an app for multiple versions. Sure some DEBs can work without needing to deal with that, but some don't.

It ruins single source of truth for apps and their installed state. It hides installed state from standard enterprise tools.

That seems like a shortcoming in those tools, that I'd expect them to fix as Flatpaks are pretty commonplace.

Man I still need to learn a lot of Linux that was Klingon for me.

I’ve had my first downside with flatpak.

VSCode’s flatpak version won’t let you use certain packages because they’re installed on the system and flatpak is a sandbox with no access. You need to enable some stuff but I’m far too lazy to troubleshoot that shit.

I got the Snap version so I’m ready for the hate.

Yes. That’s quite a downside actually!

In Gajim flatpak too, plugins only can be used if packaged for Flatpak.

  • no OS level components
  • duplicate libraries as some core apps (editor, filemanager, Desktop) cannot be flatpaks (yet?)
  • old runtimes etc. dont force developers to keep them updated. Often thats because or 3rd party packagers though
  • complicated packaging, I heard that the Flatpak builder is better for certain languages.
  • theming issues I heard (on Fedora Kinoite Wayland it just works, and I can also force themes per app)
  • bad permissions by default (best we have though)
  • bad run commands (this could easily be fixed, and I have a script for it)

For OS components / packaging every part, Snaps may work, but for GUI apps they seem subpar and nobody really cares.

Nix may be way better for installing just anything compartimentalized, but there is no permission system (thats why packaging is easier).

But Flatpaks are really great overall, Bubblewrap, KDE Settings / Flatseal, Portals, official app support. Its really really important.

complicate packaging, XML sucks (are there good editors or something?), I heard that the Flatpak builder is better for certain languages.

What has XML got to do with it? Flatpak manifests are either JSON (not great but OK) or YAML, which is great.

YAML, which is great

countries:
  - fi
  - se
  - no
  - dk

=> { "countries": ["fi", "se", false, "dk"] }

YAML, which is great.

Well, someone had to finally believe that.

Weird? One I saw was XML or maybe JSON

Probably JSON. I haven’t been involved in Flatpak for a long time but I’ve never seen XML. JSON is quite close to XML in it’s layout sometimes I find so easily mistaken.

the main drawbacks I see are related to the sandboxing of apps, e.g. that several firefox addons that I just, such as the KeePassXC connector don't work in flatpak packaged firefox, because they require native messaging support which is unavailable in flatpak. There is a three year old bug report on this at github, and an even older bug report in the Firefox bugzilla. Unfortunately, there seems to be no capacity to solve this or this is not a priority, although this problem affects quite a few users. I have similar issues with the Flatpak packages Nextcloud client: Do to the poor system integration, neither autostart works not integration with Nautilus or other file managers, unless you do some manual tinkering (which isn't particularly difficult, but with native packages it will just work™ out of the box.) These issues have been known for many years, yet there seems to be no activity to solve them.

Why isn’t this just the default?

One may notice that for every new method, the old ways stay around, possibly forever. It is not the default because there were things that worked prior to flatpak. The distros that from before flatpak have likely added the capability, but won't likely change their default for another decade, or more.

IMO yes but it might not be an issue for you, flatpaks work like windows standalone executables where each app brings all their dependencies with them, the advantage is the insane stability that method provides, the downside is the huge size the app will ultimately take, flatpaks are compressed and they don't really bring all their dependencies with them (because they can share runtimes) but the gist of it is a flatpak is usually much heavier than a system (.deb .rpm .PKG) package.

If you are ok with tweaking I recommend nix pkgs as they work on any distro and only take slightly more space than system packages. I have a terrible connection and low disk space, flatpaks aren't something I can use on the long run.

Oh and if you're wondering flatpak >>>> snap > appimages (IMO)

flatpaks work like windows standalone executables where each app brings all their dependencies

No thats appimage. Flatpaks run on shared libraries and even different runtimes containing the same packages share those using deduplication

https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker

A Flatpak is exactly as heavy as a system app, just that on the system you already have some libraries installed.

Initial download size is bigger, okay. And in general more downloads, I guess the deduplication happens on the disk.

Its like, shared runtimes but also not. Its a bad situation tbh.

flatpak >>>> snap > appimages

I didn't know we were ranking the horsemen of the apocalypse. Leave room for shitty supply-chain victims like cpan/composer/npm and other irresponsible shortcut tools that throw security out the window.

In the case of NPM (don't know enough about the others) it's not a general purpose package manager, it's only for node related packages.

And yes I think ranking them is relevant Appimages are pretty terrible security wise(let's download random executables on the internet yayyy!), snaps are getting better but used to be really terrible and to be fair NixPkgs aren't that safe either.

Flatpaks are pretty secure, they work well, the stack is fully open source and allows you to host your own flatpaks repos, as well as manage sandboxing parameters. If only they were lighter I could easily see them become the "Linux executable format"

I think using AppImage like Flatpak is silly. It is perfect for keeping some programs on a USB drive for example, but not as a way of installed software.

There's still a few edge cases that Flatpak is not great for. The Flatpak version of Kdenlive video editor can't see Whisper, which it uses to generate subtitles. The Appimage and native builds work flawlessly.

I'm assuming these problems will be addressed eventually but it takes time.

IPC and the correct location may be able to fix that. Have you opened an issue?

I ran into an issue with flatpak version of Kdenlive that it would render only the topmost V track if it was a simple still image.
Preview worked fine.
Luckily, someone in Kdenlive's Matrix suggested that I use an appimage. I used my distro's version and the final render was fine.

Other than that I had positive experience with flatpaks in general.

Have you reported that bug?

Appimages are pretty bad

They dont integrate well into your system like they should, (theming, bookmarks, storage, etc), and to fix that you gotta do some work arounds that should be done automatically

Bloated and unnecessary if freeSW or openSW. That's what system shared libraries are for. If sandboxing is a thing, then firejail is availble, which can be combined with apparmor if looking for extra MAC security.

It is the default on atomic distros. And many people who got to know flatpaks use it as a default on traditional installs as well.

But there are still bugs and quirks with some apps. Not all apps have all the functionality as a traditional install. E.g. dolphin or terminals.

It is up and coming and gradually replacing traditional installs. You rarely find an app that you can't install via flathub.

There are theming issues with older flatpaks.

Edit:

I have no idea how to view logs in the terminal with flatpaks.

You can't easily run flatpaks by their common known names. You have to use the reverse flatpak name which is annoying and difficult.

Endlessly reading on social media that is not a good from Linux "gurus". LOL

It's been great for me, but I wish it had a official gui for permissions management.

Are you aware of flatseal?

If you are, is there an issue with using it for you?

Flatseal is good, just not official.

I'm not sure why/if that matters honestly, aside from discoverability I guess.

It's as official as it gets. The XDG team provides the underlying infrastructure, and the community provides the tools.

I wish there was an option for an android style system where, when an application wants to use a permission for the first time, you get a pop up asking you to grant that permission.

Or, more generally, just some way to ensure that (a) a flatpak isn't granted the permissions it wants automatically and (b) I can then manually grant those permissions as conveniently as possible

I believe it's the packaging process. It favors the standatd procedure of builds, and does not take account of various build systems (Seems C-centered). Seems this is why many apps end up providing AppImages instead.

All that was said here, plus sometimes they don't work. I've reported a bug where the kdenlive flatpak version doesn't render titles or fades - and that's on Debian Testing, Arch, and Asahi Fedora. Native version works perfectly, but forces me to download an untidy amount of KDE stuff on my gnome installs ; flatpak would've been a cool solution to that.

I am yet to report another where Ardour nukes pipewire, at least on Asahi, but on Arch it was misbehaving also. Native, distro-provided version works perfectly.

I don't trust flatpak because no one single publisher can test every possible config, and I'm afraid distros become "lazy" and stop packaging native versions of stuff since it's a lot of work.

Flat pack install OBS? works awesome! Try to install plug in afterward not so much.

I'm a little put off by the inconvenient command line and the mandatory bells and whistles (flathub is nice and all, but must it be baked into the main executable rather than having the package manager as an optional thing on top?).

So far, AppImage just looks superior to me. Works without installing a runtime into my system, no need to become root and integrate an app into a system-wide managed package repository, I can just run it.

Others have mentioned disk usage and desktop integration. There is some truth to them, but shared runtimes keeps disk uasge down (although worse than native apps). Desktop launchers now search /var/lib/flatpak/exports/share/applications by default, but I'm still having issues with themes in one or two niche apps.

Trust is the big one. The benefit of your distro's packages is that they are maintained by a limited number of maintainers. Flatpaks have a much, much larger number of maintainers, which is where sandboxing comes in. Flathub now marks apps with lax permissions as "potentially unsafe", which is a huge step in communicating this to the average user.

Most desktop apps can get away with having next to no access, as long as they support the appropriate XDG desktop portals.

Ultimately, your mileage will vary, as there are many classes of application which are ill-suited to being sandboxed. Program launchers, programming languages, IDEs, file managers are a few.

I've used flatpak for a while because it's the default ob Fedoras GUI Software Center, but I've recently switched back to dnf and native packages where I can.

The thing is, that I have a shitty 500GB SSD with a shitty 50Mbit Internet connection (which is closer to 30Mbit because my house still has lead cables instead of copper). So downloading 300+ MB of libraries for a 2MB Program is just not feasible for me.

3 more...

As everything in life, yes, there is downside. Major downside is that it can occupy more space in your hd or ssd.

However I think the downsides are not that bad to justify all the hatred some guys have.

Flatpak positive sides are way more relevant then the downsides

Space is one thing, bandwidth is another when you don't have a gigabit connection or ability to upgrade to one

One of the use cases I would like to have used Flatpak for is Visual Studio Code. Unfortunately, I found the isolation to be too onerous for developer needs. Take the Rust compiler toolchain. There's no way to access that from VSCode. There are ways to add on tools to the VSCode environment, but that feels like a kludge when I already have everything installed and set up. And if the toolchain isn't available for Flatpak, tough luck. Other features just simply don't work. I eventually switched to using the Ubuntu builds from the VSCode developers.

Edit: The Rust compiler toolchain can be added onto Flatpak because there is a packaged version of the toolchain, but it's not the host environment's version. Other tools like the fish shell might be entirely unavailable.

Take a look at this site that goes into the details of the shortcomings of Flatpak, its from 2020 but I'm sure some of this is relevant still

Thank you! Very interesting read!

I don't think anyone dislike this comment is really correct: When they said you can use flatseal, they are making user become security expert overnight.

Too much for anyone claim themselves "practical" "security"

What could be wrong with random foreign executables in your system?

just like every other executable downloaded from the Internet, man. doesn't seem too scary

It is. I like Linux exactly because I trust the packages from the distribution. Everything else is an attack vector and untrusted

Edit: you install random binaries from the internet? Oo

As a basic end-user I have not been too happy with my experience with flatpaks. I do appreciate that I can easily setup and start using it regardless of what distro I'm using. But based on standard usage using whatever default gui "app store" frontends that usually come with distros, it tends to be significantly slower than apt, for instance, and there seems to be connection problems to the repos pretty often as well.

The biggest downside is that it's only for distributing applications with a graphical user interface. Command line utilities still need another method of distribution.

I keep seeing this criticism, but flatpak provides a run command on its cli that works just fine. It is a little clunky though.

Clunky as in flatpak run io.neovim.nvim instead of just nvim

Can't you alias that?

I don't need to do it with native-installed programs. And they are properly integrated with the OS, if you install them:

  1. You get a menu entry in gui
  2. You get a binary or a wrapper in /usr/bin

There is no .desktop menu entry and i need to remember a lengthy fqdn which does not autocomplete, great ui

I don't use Flatpak much, but I rarely see issues. Sometimes I see minor things like themes not quite being right, but its never been bad enough for me to spend the time to fix it.

I suppose another downside is the need to have the base runtime packages, so it could take more disk space if each app uses a different one. In practice apps will share runtimes though.

The main reason I don't use them is because when I move my nixos config to a new machine as far as I know you cant get them to auto install. I have to remember which ones I had installed and redo them manually.

Which is why if for some odd reason I don't want to just install from the nix pkgs repo. I use app images. I can keep them in a directory which I can just copy over to the new machine with my nixos config files.

GPU drivers. It uses the Ubuntu 22.04 (LTS) userspace side of drivers. Could be incompatible with your kernel. Had all sorts of graphical weirdness with my AMD GPU with flatpak Steam.

If you have an unusual setup, it can be annoying trying to give programs permissions and sometimes it just outright doesn't work. For example, I mainly game on a laptop which has a pretty small hard drive, so I tend to put most of my games on an external hard drive. Flatpak really doesn't play well with that.

Don't you just need to give them permission to access it? Works perfectly fine with my Steam and Lutris Flatpaks... Well I had to restart once I think

Yes, the confusion that results when things don't work because of isolation.

I feel like this should be required reading for a lot of Linux users. That article is a couple years old now, but I think is even more true now than it was when it was written. Having a middleman (package maintainer) between the user and the software developer is a tremendous benefit. Maintainers enforce quality, and if you bypass them, you're going to end up with Linux as the Google Play Store (doubly so if you try and fool yourself into thinking it won't happen because "Linux is different")

What I find most annoying is the extra drive space required. It makes backing up and restoring my computer so much more annoying. The upside of this is that I've ended up learning how to install from source so I can avoid them when a deb package is not available!

I personally don't really like it, since it sidesteps what is supposed to be the all-in-one package manager for the system, and integration can be poor.

It's an alright idea, but I like the native package managers better. We're not Windows, we don't need so many different places to download our stuff.

Flathub is just one place. But it has verified apps, so you have no distro packaging issues, which is a Linux/BSD only problem.

I use flatpak for all GUI apps I use.

Flatpak usually ships very outdated drivers.

I've been in the support channel for yuzu linux, and you would not believe all the issues people have with games freezing, etc that are instantly fixed by using the appimage instead of the flatpak.

Also flatpaks are non-xdg compliant, since it creates the useless ~/.var directory. And they have said over and over that they won't fix that. So fuck them.

Not to mention all the issues people have with their theming and integration into the system.

Appimages are just simpler and better, the other day I was thinking how many issues would be fixed if Steam shipped as an appimage.

  • It would allow for shipping a patch glibc with EAC
  • It would allow for moving all the nonsense that steam puts in the home user dir, since appimages support a portable home.
  • It would allow for shipping the 32bit libraries instead of having to install them system wide.

And depending on how you go about, appimages will even take less disk space than flatpaks or native packages even though you don't get shared libraries with those, because they are compressed which reduces their size significantly.

Like for example the LibreWolf appimage is 110MiB while a the native package for librewolf 300MiB. Same with LibreOffice, the appimage is 300MiB while the native package is 600 MiB.

It also makes it easier to downgrade if you run into an issue, like I had to had an older appimage of ferdium because the latest version is affected by an electron bug that broke its zoom functionality.

Interestingly I've currently crashing issues with running CS2 through Steam native on NixOS, while the Steam flatpak works like it should.

The part about drivers is true though, as GPL is the reason I'm using native Steam.

You don't have steam-runtime instead of steam-native on nix?

I mean the native NixOS package of Steam (instead of flatpak), not that the Steam package uses native libs.

I believe Steam on NixOS always uses the Steam runtime, because NixOS isn't FHS compliant, thus apps wouldn't find any libs. No, I don't think there's steam-native on NixOS.

Problem I have with Flatpak is their way of naming packages which makes them very akward to run in a WM. That's basically the only reason why I haven't used Flatpak since I switched to WMs, pacman and AUR also work really well so there isn't even a reason to use something else.

Yes, security

How? Security is one of its selling points.

libxyz has security vulnerability:

Your distro updates libxyz. Fixed and every piece of software gets the fix for free.

Every single flatpak that uses libxyz has to update to include the fix. Let's hope all those package maintainers are on the their game.

That's not how Flatpak works.

Flatpak has runtimes, which is where most shared libraries are. There's a common base one called Freedesktop, a GNOME runtime, a KDE runtime , an Elementary runtime, and more. (The GNOME and KDE ones are built on top and inherit from the Freedesktop base runtime.)

https://docs.flatpak.org/en/latest/available-runtimes.html

Additionally, at least for Flathub, they have shared modules for commonly used libraries that aren't in runtimes. (Many are related to games or legacy support like GTK2.)

https://github.com/flathub/shared-modules

Lastly, some distributions are building their own runtimes and apps on top, so the packages they build are available as flatpaks as well. This is the case for Fedora, Elementary, Endless, and others.

https://fedoraproject.org/wiki/Flatpak

That's not how Flatpak works.

That's exactly how flatpaks work if the library you need is not in the runtime. Which is very often the case.

I know because I made one for my personal use and the package was not available elsewhere.

Additionally, at least for Flathub, they have shared modules for commonly used libraries that aren't in runtimes. (Many are related to games or legacy support like GTK2.)

So we're just reinventing the wheel with more bloat? Brilliant.

Yeah, that's a big, weird if though. Most modern apps can rely on the runtimes for their dependencies and not have to ship their own custom dependencies.

It's different from something like AppImage, where everything is bundled (or Snap, where a lot more needs to be bundled than a typical Flatpak, but not as much as with an AppImage).

Additionally, there's always some level of sandboxing in Flatpaks (and Snap packages) and none at all for RPMs, Debs, or AppImages.

Also, Flatpak dedupicates common files shared across flatpak apps and runtimes, so there isn't "bloat" like what you're talking about.

https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

I think bringing in an entire operating system, which may well include libraries and other files that I already have installed, to run something small can be considered bloat.

I currently have multiple versions of Nvidia's libraries installed for some reason on my system through flatpak. I have no idea why that's necessary but if I don't allow this to happen I get dropped down to software rendering.

It sells security through isolation, but packages are not cryptographically verified after download. This is done in package managers like apt, but not flatpak

Unless you are using like a 64GB drive, not really. Ig flatpaks are as bit more annoying to start from the terminal

I like Flatpak, especially now that it has upstream providing packages. It does not have auto updates yet as far as I know. Not a big deal, if there are important security updates in the news, it is time to check for updates.

No downside, only flatpak

The upside over Snaps is that they're not so controlled by a central source

I'd say they still share a couple downsides: a) use a lot of them and stuff is gonna get bloaty vs native packages

b) updating a library etc for security on your system can still leave you with vulnerable apps where the packages aren't updated

Snaps are very much controlled by a central source. With flatpak you can add custom repos

Yeah that was what I said.

Generally using only a few flatpaks is where it's generally "bloaty". Adding more actually balances out the equation ans you have more apps using generally shared runtimes.