Flatpak is one of those pieces of software that's clearly made by people with nice computers on fast internet
You want to install a calculator app? That'll be multiple gigabytes of download. Mere mortals now have to wait half an hour to get the app.
What's even more insane is at the command line when you Tab to autocomplete the thing makes network requests and hangs! It's the only CLI app I know what requires the internet to autocomplete!
I think the thing has been a complete flop. The multi gig "backends" are all versioned weirdly and I find they're very rarely reused between applications.
Static builds in AppImages are smaller and faster and don't have weird UI issues. AppImages just need maybe an external update mechanism and more standard system integrators. But I'm glad that fundamentally the app format and the updater and system integrator are decoupled. These kitchensink app "systems" seems just big and ugly
Flatpak itself is not enforcing this. You can ship a statically linked binary with no dependencies if you want.
The runtime thing that flatpak supports is, ironically, to minimize and deduplicate common dependencies, and to be fair they are only downloaded with the first app that needs it with many apps using the same handful of runtimes. The fetish for shared dependencies within Linux and the pains it causes are a bit frustrating, but that's not new to flatpak.
> What's even more insane is at the command line when you Tab to autocomplete the thing makes network requests and hangs! It's the only CLI app I know what requires the internet to autocomplete!
nit: CLI tools do not implement auto-complete themselves. What you are seeing are auto-complete scripts for your shell that make network connections.
Not sure if flatpak keeps a local repo list. That would be the only way to implement tab-completion of installable items without making network connections.
It does not keep a repo list bc the CLI needs to be constantly directed to the particular repo you want to use/inspect. It doesn't default to flathub and there is no sources.list equivalent. So therefore there is no cache and it needs to constantly ping the server to do anything. This makes the whole interface incredibly sluggish to the point that it's frustrating to navigate and explore. So you end up using the crappy website (as compared to something snappy like aptitude)
Frankly shared dependencies makes sense when they're sort of wide-consensus. Debian-stable or Ubuntu-LTS. Everyone is building to work with the same set of version numbers and they are all rock stable for years. Rolling shared dependencies is just a recipe for broken apps. It's just a combinatorics problem. You can't test against every combination of every version of all your dependencies.
And multiversion shared dependencies .. I don't even understand the point (and why Nix has always confused me)
AppImages are also very big. Example: Blender [0] (210MB), OBS [1] (105MB), Ungoogled Chromium [2] (166MB)
The only alternative that does not lead to downloading 100s of MBs of files is .deb/.rpm files and the associated "the prebuilt binary needs libfoo.so.4.0.1 but Debian ships libfoo.so.4.0.0" problems. Which ultimately means you pull even more dependencies than the Flatpak runtime for building (gcc, make, CMake, libfoo-dev, libfoo-dev's *-dev dependencies,...) and spend a long time compiling the application (also suited only for high memory, high core count machines).
Right; one way or another a program needs all of its dependencies. The traditional model was that a distribution would include one version of each dependency (most of the time) and share that between all the programs on the machine. Of course, that didn't work if you couldn't use that version, so the alternative is to somehow bundle dependencies in with your program (appimage, Firefox-like tarballs, plain static binaries) or ship them separate (flatpak, maybe docker).
I've been using it as a digital nomad on shaky southern european airbnb and hotel connections for the past year and I have no complaints.
I was skeptical to it, until I realized it uses cgroups for isolation. Now I'm actually quite fond of it, because I've recently converted to using immutable linux distros.
As others have pointed out, in reality the SDKs are very often not really shared and you end up with multiple copies. This doesn't happen (and is basically impossible) with a traditional package manager
Not sure if you've used Flatpak before, I have 108 flatpaks installed with just 3 runtimes, and one of those runtimes is for a deprecated app that won't even update for my distro anyway.
Flatpak means I can continue to use it far into the future.
I have a similar 5.7" 32 GB eMMC device that runs a debian-ish distro with Phosh GUI, where I have been installing flatpaks left and right (without caring which runtimes they use) for a reason ([0]) since early 2022.
I am now at 107 total flatpaks, 18 of which are platform packages (= 89 apps+locales). If I were to remove five outdated apps, that are archived or inactive upstream, I would be able to get rid of four platform packages (I really should, but I don't want to for sentimental reasons).
I have found things to scale similarily across devices: The more flatpak apps you use, the better the ratio gets.
If you just use one app, you may end up with 3 Platform packages for it if you are unlucky, making that one app an incredible disk space eating monster. When you have 50 flatpak apps, things will look way better.
Now, would I like to have all these as native deb, rpm, tar.xz (arch), apk? Yes.
But I would also like to use the latest version, making that pretty much a pipedream - and in some cases the distro packages (mostly on Alpine and the AUR) aren't always as functional.
I am really glad flatpak and flathub are a thing.
OT, regarding alternatives discussed in other threads:
AppImages aren't really a thing on aarch64 (also, I use Wayland, which probonopd does not seem to be a fan of [1]).
Snaps: I had 'wrong arch' failures when attempting to run what was promoted as arm64 on Snapcraft.
Oh, don't get me wrong - Flatpak is definitely better in a lot of ways than Snap or AppImage. Just let's not pretend that it doesn't eat a lot of space, because it does. It does not scale linearly with number of apps because of deduplication, sure, but you still can easily get the runtimes alone to consume more space than your whole underlying OS with a full set of apps installed natively, and for little benefit - Flatpak makes it unreasonably hard for users to switch the app runtime to a newer one even it it's perfectly compatible and could instantly free gigabytes of disk space.
I don't think app distribution should be dominated by "app store" type solutions; distro repos are an important part of the system too. But there's definitely a use case for "app stores" too and Flatpak fills that niche pretty well, although it still has some really annoying details to sort out before it can actually be as useful as it should be. Thankfully, these issues are mostly about the frontend - the backend seems rather solid already, which is great, so maybe it's just a matter of time until better frontends appear.
> I have a handful of apps and 3 flatpak runtimes on my phone right now and that's only because I'm the latter (and have to be because of 32GB eMMC).
I mean, yes Flatpak will use more disk space than everything being packaged with the distros native package format, although in larger amounts you get a better ratio.
This is the trade off that has to be paid, Linux has no stable userspace ABI like Windows (so, Microsoft doesnt need to ship multiple versions of a dll), it's already the norm in the server space with containers, where it's been extremely successful. Flatpak goes a step further than OCI by having native deduplication due to OSTree (although there is push to get this on servers too)
Do I think the trade off is outweighed by the advantages? Yes, absolutely. I have used Fedora for 10 years (currently using uBlue/Silverblue) and Flatpak makes installing things like Discord, Slack, Steam etc 10x easier on Fedora than it's ever been (partially due to no or outdated rpms).
Ah, that's a very fine point. The rpmfusion RPM isn't officially supported by Valve either.
Edit: Valve releases tarballs and a .deb package. Why would they release a .deb when Arch (which steamos is based on) doesn't use .deb? Releasing a .deb makes me think they test the thing on Ubuntu or Debian
> The multi gig "backends" are all versioned weirdly and I find they're very rarely reused between applications.
I find that they're generally rather well shared between apps. I use Tumbleweed and only install apps via Flathub. I have around 40 apps and I don't have this problem. It was a problem when I used 4 Flatpaks and the rest came from system repos.
>You want to install a calculator app? That'll be multiple gigabytes of download. Mere mortals now have to wait half an hour to get the app.
The top 2 calculator apps were under 5mb in size. I'm not sure what point you are making because the hyperbole was too extreme. <2s?
I have every shade of computer and wifi connectivity and waiting <60s-<5min for a download, one time, isn't going to change any experience. We forgive one time downloads. We do not forgive weekly forced reboots and dealing with autosaves M$.
> What's even more insane is at the command line when you Tab to autocomplete the thing makes network requests and hangs! It's the only CLI app I know what requires the internet to autocomplete!
I'm pretty sure that it's a bash-completion feature / "fault".
No command is really executed while your are typing in a terminal until you press "enter".
> It's the only CLI app I know what requires the internet to autocomplete!
Oh that's actually a killer feature of kubectl for me. It's also used by a lot of tools around Kubernetes as well. It makes me not only faster, more certain of results of my commands in advance, but also makes me easier to understand to others when I share what's going on on environments.
Yeah, it does suck if API is far away, but the benefits are too great.
> Flatpak is one of those pieces of software that's clearly made by people with nice computers on fast internet
But like, it's 2023... Having that requirement isn't a hard sell. Especially considering the base of Windows and macOS have fancy requirements as a base.
Also, Flatpak allows for lib dependencies to avoid duplicate libraries from filling up your disk. Not really sure what else you expect.
> But like, it's 2023... Having that requirement isn't a hard sell. Especially considering the base of Windows and macOS have fancy requirements as a base.
I think this is a sad attitude, when software actually has quite a high carbon footprint[1] on par with the aviation industry. There is so much old hardware that would work just fine if we actually cared to make software that works for them.
I think new software should lower the requirement, and better hardware should mean faster software, not that developers can get wasteful.
There was a video from Twitter shared on HN a while back of Windows 95 or 98 (I don't remember which) running on a modern computer, and all programs and menus loaded instantly when clicked, not like now where there's often a small delay. It would be great if better hardeware meant the same thing but snappier, rather than the same thing but more inefficient.
However, that speed came at the cost of laborious optimization for the low-end computers of the time and millions of dollars spent by Microsoft debugging defective C and assembly code within Windows.
The only way to force software to be more efficient would be some sort of cap on how inefficient software were allowed to be, which doesn't seem possible. At most, you can have a carbon tax, or increase taxes on electricity use, indirectly incentivizing the use of energy-efficient software.
Another way can be to try to lower the bar to write performant code. For example, the work in languages like Rust, Nim, Hare and Roc might also unlock capabilities to write low-level performant code with the same productivity as high-level languages.
I def. agree though tat a carbon tax to force companies to be more frugal would help too.
I've heard too many times to not think about optimization and just throw more hardware at problems, I think that's a mentality we really need to start questioning.
I agree Rust lowers the bar to write low-level performant code (especially considering that it was always harder to write correct C than, say, correct Ada) but I don't think it's always necessary to write code in non-garbage-collected for decent performance. We just need to use garbage collected programming languages that are statically typed, don't rely on a runtime on the host computer (e.g. the JVM), are memory safe and have predictable performance characteristics. All I can think of are Swift, OCaml, and Standard ML. In Go, your program causes a segmentation violation if it dereferences a null pointer, so I won't call it completely memory-safe, but it's still an improvement in abstraction compared to C while still providing performance.
> Also, Flatpak allows for lib dependencies to avoid duplicate libraries from filling up your disk. Not really sure what else you expect.
Assuming that the app developers play nice and all agree to use the same (latest?) version of the libraries. In which case Flatpack becomes just a clone of Debian/Arch.
If app developers don't play nice (which is most likely), Flatpack becomes more of a bloated version of Nix/Guix.
> But like, it's 2023... Having that requirement isn't a hard sell.
I know several people who are on a shitty data limited connection. Their internet becomes basically unusable after a windows update tore through it.
Hell the company I work for still hasn't found anyone willing to replace its ancient line with anything remotely modern and the multi connection + mobile network workarounds we have going breaks down the moment there is even a drop of water in the air.
2023 just like the years before it is a year where the network providers don't give a shit about decent service.
There are still plenty of people who do not have access to fiber or even cable. I am one of them. I have a single flatpack app installed, and I rarely apply available updates because each update weighs in at close to 1 GB.
You might find this shocking, but in many parts of the world "nice computers on fast internet" is kind of a given now. So for those, even if it is "gigabytes", it is worth it for the various benefits like security or convenience, for example.
> And what kind of security do AppImages offer you?
None and no one said that it does offer any kind of security. The criticism was entirely unrelated to that.
On the other hand, flatpaks sandboxing is also severly limited by the fact that most packages do not make use of it much. In the past the runtimes offered by flatpak were also lacking behind on critical security updates [0]. Did that change in the meantime?
Flatkill is full of misinformation or no longer true information. There're many posts debunking most of their points [1]. Some parts were true a few years ago but aren't anymore.
Edit: They removed many of their examples at some point, so it's no longer as bad of an article.
For example if VSCode wouldn't have direct access to the file system, it would be unuseable since it doesn't support portals to ask the user to grant it access to specific folders (by selecting them through the file picker).
In the process of packaging an app for flathub, the packager has to provide some reason for why for example full file system access is necessary. The discussion to add or remove permissions are always open [2].
Security of my calculator..? Is this a theoretical or actual concern? Are you getting hacked through outdated AppImages? The Snap/Flatpak sandboxing has been widely criticized but I'm not an expert to judge. I'm guessing you can run your AppImage from something like a chroot if that's a real concern
I've never had an AppImage hacked.. (or honestly anything else hacked on a Linux machine) though I'm not running AppImage servers
> in many parts of the world "nice computers on fast internet" is kind of a given now
Well if they want to be an appstore solution for the Linux ecosystem then they need to cater to everyone, not just rich kids in silicon valley
The concern isn't the calculator getting hacked, but the calculator itself being malicious, and there being a desire to safely install programs without opening up your whole system to them.
A calculator should be run as a fully isolated application, with no filesystem access and no ability to damage anything even if it tries.
I could upload a "Calculator" application that looks harmless, and even functions as a calculator, but actually steals your GPG keys and logs keyboard input. With a sandbox this would not be possible (in theory).
A "calculator" app isn't really unique here, it can be malicious just as well as anything else could be.
You do not want "apps" to be able to do this at all!
A calculator shouldn't really have access to many things anyways, ideally only access to things it requires to function.
You can enjoy security and convenience without requiring users to download, install and update a dozen different system images just to run some simple apps.
I have a few apps installed via Flatpak there are multi-gigabyte updates several times a week, usually for the base images under the apps themselves. I apparently have 3 different copies of GNOME, more than half a dozen platform images, and several copies of the Freedesktop SDK.
It doesn't, it's the whole "do one thing and one thing well", where it's only concerned with having a single executable without any dependencies. You run them with Firejail for security/sandboxing.
When the RPM felt out of time, I switched from SuSe Linux to Kubuntu. Now I use a ubuntu based distro (Bodhi). This flatpak stuff may make me leave ubuntu.
My current version uses mainly DEB. Due to some personal issues I am not up to date with my OS. I install 99% of my software with apt and deb packages. I don't like Snaps and Flatpaks.
Yes, I have to update soon but I will do this when I buy a new Dell XPS
I use Flathub, but I do not like that they support the ability for third parties to package commercial software on behalf of the publishers.
https://flathub.org/apps/com.bitwarden.desktop - looks great, right? You have to click on "show more" to see "This wrapper is not verified by, affiliated with, or supported by 8bit Solutions LLC.", and prior to clicking "show more", everything looks like it is in fact published by 8bit Solutions. Because it's a third party packager, you end up with bugs like https://github.com/flathub/com.bitwarden.desktop/issues/147 (because they haven't used a particular flag to launch it, which the deb/rpm version apparently does use by default.) Yes, the attack surface is relatively minimal, but it's still there -- https://github.com/flathub/com.bitwarden.desktop/blob/master...
One thing I don't know about (which maybe somebody can inform me/us about): the wiki states that PRs are reviewed by Flathub reviewers, but I see no sign of human review on e.g. https://github.com/flathub/com.bitwarden.desktop/pull/167 (or others in that repo). What's the actual process?
The other small irony that won't be lost on fellow 90s graybeards is that by sitting on github, we're moving significant parts of Linux infrastructure's distribution to be hosted by Microsoft.
> Apps that are published by their developers themselves can verify to get a blue checkmark.
OK great. Why don't apps that are published by third parties get a giant red exclamation mark? If you read all the way through this thread, you'll see a very feasible supply chain attack on BitWarden. For FlatHub to have a credible security posture, they need to do something like very clearly identifying third party packaging as "experimental" or "dangerous". This has been a known issue for years, and yet they appear to be taking a "our volunteers are nice people, thanks community" collective shrug.
FWIW the website isn't everything, since a) you can install from the CLI without viewing the website[0], and b) there are third party tools like KDE's Discover which quietly integrate with FlatHub. My father would never understand the difference between FlatHub, Snap, and the Canonical deb repositories, even if I explained 50 times - and yet he's been a happy KDE user for 15 years. How is he supposed to know that he's no longer necessarily accepting properly audited software when he clicks the "update" button?
[0]:
> flatpak install bitwarden
Looking for matches…
Found ref ‘app/com.bitwarden.desktop/x86_64/stable’ in remote ‘flathub’ (system).
Use this ref? [Y/n]: y
Required runtime for com.bitwarden.desktop/x86_64/stable (runtime/org.freedesktop.Platform/x86_64/23.08) found in remote flathub
Do you want to install it? [Y/n]: y
I don't believe third parties maintainers packaging software on flathub is a big issue but I'm also not familiar with how other distro repos trust their maintainers. Hopefully more developers maintain their flatpak themselves (or someone they trust) and get their apps verified. If most apps are verified, warning users of unverified apps might be a good idea.
There's ongoing discussion about splitting open source and proprietary apps in to seperate repos [1]. Additionally having seperate repos for verified and unverified apps might make it more obvious where an app comes from in the cli.
But I don't know how seamlessly an app could transition between being in the third party repo and being in the official repo. Having the user quietly stop receiving updates seems like a bad idea, but automatically migrating might not be desirable either.
I also think flatpaks cli interface needs some work. It is functional but far from distro package managers.
Being verified is especially important for critical apps. Recently someone added malicious versions of apps to the snap store [3]. This lead to people getting their cryptocurrency stolen.
> One thing I don't know about (which maybe somebody can inform me/us about): the wiki states that PRs are reviewed by Flathub reviewers, but I see no sign of human review on e.g. https://github.com/flathub/com.bitwarden.desktop/pull/167 (or others in that repo). What's the actual process?
In this case, I think the lack of human involvement is mostly a good thing. Flathub was criticised for having outdated packages[1]. Using automation to automatically update packages is mostly a good thing.
Obviously, we want to see thorough review of new packages, but that's a separate issue.
> Using automation to automatically update packages is mostly a good thing.
Maybe. The CI rules should be made public in that case, though, surely? Maybe they are?
The enormous amount of value the distros bring (aside from sponsorship of the ecosystem) is audit of packages (and packaging). If we want to move application packaging away from the distros, Flathub needs to be at least as competent in its process, automated or not.
> The enormous amount of value the distros bring [...] is audit of packages (and packaging).
Yes, auditing against supply chain attacks is good! But there's also a risk in running outdated software. I don't have easy answers. But if automation leaves more time for the hard part, great.
Maybe unfair to ask you (but thanks for the helpful answers so far).
Is there a check for "this distribution comes from the official source"?
Let's say some state actor compromises taaem's desktop computer, and changes the url in the manifest to (say) https://xn--githb-bjg.com/bitwarden/clients/releases/downloa... (that's a unicode lookalike ս in there, which in github at least renders without expansion as "github.com" - HN is smart enough to expand it), or something equally nefarious. CI's not going to catch that, right? And nobody's actually paying attention to changes?
Not an expert, but unfortunately I think you're right in identifying a potential attack vector with the Flathub maintainership model. Even if flathubbot is being used, manual changes can still be made by maintainers.
And I think there are far more maintainers to trust, than for say scoop or winget. The difference is, Flathub has one repo per package (and hence allows more maintainers).
I see a lot of negativity in this thread. Personally I think flatpaks make it super easy to use a rock solid stable distribution as your base OS, and then run the latest and greatest software on top.
In years gone-by if I wanted the latest versions of software I'd have to use an unstable rolling release distro. Now I can just use Debian stable and essentially get the exact same experience.
Agreed. Just looking at the Steam Deck and how well flatpak works as a distro independent way to install apps is great.
Flatpak supports mutliple remotes (repos), everything is open source and apps are partially sandboxed.
Locking down network permissions with Flatseal [1] is great for situations like with PolyMC, were a maintainer's gone rogue without having to worry about leaking data.
As long as the Snap store doesn’t allow for arbitrary repos like flathub and is limited to only those apps Canonical have blessed to be present on their store (assuming of course you haven’t forked over tens of thousands of dollars to them to have your own enterprise version of the Snap store), I don’t understand how it can even be in the discussion as a legitimate software distribution mechanism on Linux.
Yeah, between flathub (+ appimage) and linuxbrew, distros mean very little to me anymore. I can finally just work instead of worrying about of the program I'm trying to run has been blessed.
I found it a more practical alternative to the Arch AUR in many cases (especially the -bin packages which don't have any benefit of being a part of a "build" system anyways)
Similar (perhaps slightly lower given verification efforts) concerns about integrity/supply chain (who is maintaining this package really? Is it a clean build from the correct source?), but distro independent and often works good enough with some exceptions. Sandboxing is limited but better than nothing.
Once I somewhat understood the process and where everything is on GitHub (fairly transparent with CI stuff) I felt a bit more comfortable with things, but a lot of the store interfaces leave a lot of questions unanswered about the source (location) of the software.
If something is out of date I can usually make a GitHub issue and it'll get sorted soon enough.
> more practical alternative to the Arch AUR in many cases (especially the -bin packages which don't have any benefit of being a part of a "build" system anyways)
The AUR package would still use less disk/network since the flatpak is carrying around effectively its own distro / base image layers. OTOH no sandbox so weigh as you will.
>which don't have any benefit of being a part of a "build" system anyways
Building a package doesn't imply compilation of the binaries the package is composed from. Packages are meant to provide easier distribution and maintenance.
I don't particularly disagree, but rather I've viewed the AUR as having value in that you can change build options (for instance enabling/disabling features) that may not exist in pre-existing binary builds.
The distribution aspect of the AUR is useful given the various tooling/helper utilities around it, but I don't see it as more effective than flatpak if you're just using binaries that already exist. While the AUR is a bit more of a direct path, you don't have to worry about system level dependencies changing and breaking the binaries with flatpak (even if that does result in more disk usage as a side-effect).
I use flathub pretty much to run proprietary software (which does not have the source available and
can't compiled against musl/alpine) and for that it works pretty nicely. But I would 100% rather
have those on my package manager, easier to install with a smaller footprint.
While this may make Flathub unsuitable for you, there are other Flatpak repos.
Fedora and PureOS each offer their own Flatpak repos, which presumably follow those distros' security policies, so they may be more useful than Flathub for some people.
I love flatpaks. If I need to run a newer version of some software, I'll use it because any backported dependencies won't break my OS.
My only gripe is that officially maintained apps (that is to say, apps published by the actual dev team) are listed alongside wrappers for apps that are 3rd party maintained.
You want to install a calculator app? That'll be multiple gigabytes of download. Mere mortals now have to wait half an hour to get the app.
What's even more insane is at the command line when you Tab to autocomplete the thing makes network requests and hangs! It's the only CLI app I know what requires the internet to autocomplete!
I think the thing has been a complete flop. The multi gig "backends" are all versioned weirdly and I find they're very rarely reused between applications.
Static builds in AppImages are smaller and faster and don't have weird UI issues. AppImages just need maybe an external update mechanism and more standard system integrators. But I'm glad that fundamentally the app format and the updater and system integrator are decoupled. These kitchensink app "systems" seems just big and ugly