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.
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)
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.
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.
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.
Thanks for your comment! Both positive and negative for sure.
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?
- Flatpaks aren’t really single-executables. You have to use to the
It’s HUGE. That’s the biggest downside for me. I’m always use a deb/native package first because they are way smaller.
- 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.
Startup time and disk space.
No proper estimate of download size.
This is one of the biggest annoyances I’ve come across with them for sure.
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.
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.
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.
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.
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.
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.
some devs don’t want to debug last arch/ubuntu broken setup.
Indeed.
Yes. It is not pacman
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.
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
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”
Thank you! Very interesting read!
Flat pack install OBS? works awesome! Try to install plug in afterward not so much.