How does it stack up against traditional package management and others like AUR and Nix?
I usually prefer not to use them, but they flatpak for Prism Launcher comes with all versions of Java preinstalled which is convenient because I play verious versions of Minecraf, other than that I try to use xbps as much as possible
deleted by creator
I have to agree. I tried some of the JetBrains IDEs from Flathub, and I switched back to the regular JetBrains Toolbox versions.
Have you tried granting additional permissions via Flatseal?
deleted by creator
People need to realize that before Flatpak, distributing a small-time Linux app was a nightmare. Appimages were your best option if you wanted to avoid distro specific builds, PPAs and AUR, etc. Ever since packaging 2009scape on Flathub I haven’t looked back. It auto updates. People can find it from software centers. It works on all distros. It connects straight to upstream’s CICD. It even forced us to adopt XDG compliance so we could sandbox it better.
Yes, Flatpak has downsides like the download size (on disk it doesn’t matter because it gets compressed and the runtimes are shared, same as literally any other package manager). But overall, I hugely welcome it over the options we had before. Much love to the Flatpak and Flathub devs!
Ever since packaging 2009scape on Flathub I haven’t looked back.
So YOU are the one to blame for my latest Runescape addiction relapse! I only learned of the project because I stumbled on it while browsing flathub
LOL
Flatpak shooould just download the diffs
They should, actually. Google released a tool for downloading only the diffs on binaries a few years ago
They use ostree afaik, so “they should” as in “I think they do”
The sandbox can be very cumbersome when there is not a way to break out. I’m thinking specifically of command line tools for developers. You can poke holes in the sandbox to access the filesystem, but the moment you want to run an executable it won’t let you.
Flatpaks aren’t meant for command line utilities.
Right. I mean something like an embedded terminal in an IDE that has full shell access to the host environment.
Flathub doesn’t accept CLI tools (unlike the Snap store)
Regarding modifying Sandboxes, try Flatseal
Other way around, accessing command line tools. As far as I know, there is no sandbox setting to allow access to execute commands directly on the host system.
Interesting, thank you. I’m definitely running into trouble for things like shells, but it works okay.
Why is helix there then?
good enough, still prefer the system package manager for most things though
Everything I’ve gotten as a flatpak has been borked in one way or another. I only use it if there is literally no other option available.
Doesn’t work properly, apps are bigger and don’t always apply GTK themes. I also can’t easily edit the desktop file to edit the icons. I therefore only use it as a backup when I can’t find an app on the AUR or office repositories, which is very rare.
“Dont ask yourself if it works, but how it works”
For editing desktop entries, copy it fron this strange directory
~/.local/share/flatpak/exports/share/applications/to your normal~/.local/share/applicationswhich will always override the others.
deleted by creator
Where’s that Chris Pratt meme? –
I don’t know what that is and at this point I’m afraid to ask
Flatpak is a project trying to fix many things at once
- make apps that work on every distro
- thus have apps officially supported by the devs, unlike distro packages mostly
- sandbox apps with an android-like permission system with a rating system
- use modern standards like delta-downloads, deduplication and BTRFS compression to save storage space
- make everything nice and user friendly
They have their uses. In particular they’re useful for easily getting applications your system repositories don’t have or getting more up to date version of applications. Downsides are certainly the space all the redundant dependencies take up and the sandboxing can be a PITA especially if you have an application that needs to run another application. Overall I think they’re the best “third party” package system available but they’re not great.
I really like them. They give us a reliable application that doesn’t depend the distro building a version for specific platform. For example if the newest versions are compiled for Ubuntu 24.04 but you’re on 22.04 it might take a while to get the update.
It does come at a cost though, it’ll have to package all the dependencies for 24.04 in a layer of the package so it’ll take a long time to start up and take a lot more memory than necessary.
This is mitigated by flatpaks using same base for their application (like Ubuntu with Electron) but it still isn’t the same as just starting up a proper
aptprogram.I really like it since we can have a modern version of a program for small distros and in general the barrier to entry so much lower so companies can’t just say “oh we can’t support all Linux distros, not feasible”.
Aur you compile yourself for your own distro instead of it being done already by
aptand the like.Nix is a super cool since you can just setup and configure pretty much everything so that you just press “install” and you’ll have your Gimp, VPN and whatever apps all done for you. You’ll have to do some heavy configuration so programming knowledge is not necessary but really helps.
Some of the under-the-hood implementation of Flatpak irritates me, like why the hell are we installing software in /var? Using it with the terminal is a pain because of the org.something.SomeThing shit it does, and I think Flatpak gives you all the drawbacks of app sandboxing with none of the benefits. It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn’t see anywhere I wanted to put my games library. That needs to be fixed.
That said, I think it’s the better of the three all-distro package managers, it’s got a central repository and package manager unlike Appimage so it’s a place to publish and get stuff, and it’s not tied to Canonical so it’s obviously better than Snap.
It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn’t see anywhere I wanted to put my games library. That needs to be fixed.
That has been fixed with the introduction of Portals: https://docs.flatpak.org/en/latest/portal-api-reference.html
https://github.com/trytomakeyouprivate/flatalias
Try this script I wrote and help improve it!
if you want to change app permissions, use Flatseal and add the needed directory. This is very easy. If it is something all users generally need, open a bug on their repo.
Installing a separate program to make the first program work the way it should in the first place, and opening bugs in repos, is abolutely 100% things end users are willing to do.
KDE has flatpak settings included, GNOME is doing their thing with unix philosophy and all. Flatseal works fine.
As I said, you should not need to edit those settings, maybe you need to, and if it generally makes sense (for example GNUmeric only has documents access, nothing else) this needs to be fixed.
Will not happen often for common apps
Reminds me of this XKCD.
The state of flatpak permissions currently is like that. They can never read each others storage, much like on Android with
/storage/emulated/0/Android/data. So it you keep stuff stored inside these apps its safe.Until they can use portals, many have permissions to read/write everything
My main problem with Flatpak is that it hands temporary /var/run/1000 file links to programs instead of real filenames. That would almost be bearable, if Flatpak also took responsibility for keeping those links from breaking sometime after your next reboot.
If I say “here is a path that an app is allowed to use”, flatpak should just allow an open() in there to work. It should not lie about the name of files in there. An app should be able to open a file there, remember that name, and count on being able to access it again in the future.
Other than that, Flatpaks are the bees knees. I love finding something I want to do, finding a solution in the flatpak store, and click-click I’m already doing shit. Finding Windows software is absolute garbage next to this.
Thats basically persistent portals. Would be possible if Distro portals had a button to give the app permanent (static) permission to that dir.
Would indeed be useful and not hard to implement. In the portal window just add a button “permanent” which does
flatpak override --filesystem=$PWD org.app.nameWant to open a discussion or Feature request for your desktops portal?
purely as an end user i hate how much it downloads with each update and how much it uses the disk space although that’s much less of an issue. i know it’s solving a real problem and relieving a lot of the headaches of developers maintaing packages for each distro’s specific package standard, but it’s simply not the software distribution solution for people without at least well enough internet.
i wouldn’t use any distro with flatpaks as its main way of delivering software and i would in almost all cases always choose alternatives even if it’s outdated. i don’t necessarily hate flatpak itself but for me i don’t want to spend money on extra data cap and wait 30 minutes for a small update for my game launcher to finish.
the appimage of one of the applications i was interested in was 3 times less than the average flatpak update so redownloading the appimage every time would be better. if i installed more packages yeah the math would be better but it’s still wasted data per update no matter how small it actually is. i found out after a while of using flatpak that i wouldn’t just update and was stuck with outdated software anyway.
the actual update size for the application is logical as far as i remember, it’s the other stuff alongside it (i think related to graphics card) which is the real issue. it added around 500MB each update while the actual update itself might’ve been 10 or 20 MB.
Yes, also it uses deduplication on the disk, where it is even less space actually used.
