Flatpak is a universal application packaging standard for Linux. It allows devs to create a single application that gets bundled with all necessary dependencies including versioning.
These apps run in their own semi-isolated “container” which makes immutable distros possible. (Distros like Fedora Silverblue that are effectively impossible to break by installing or removing critical system files.)
This means that a Linux app doesn’t have to have a .deb version, an .rpm version, or be pre-compiled for any other distros. A user can simply go to Flathub, (the main repository for Flatpak apps), download the flatpak, and install it on their distro of choice.
It’s quickly becoming the most popular way for users to install apps on Linux because it’s so easy and quick. But there are a few downsides like size on disk, first party verification, per-distro optimizations, and the centralization of application sources. That’s why some users aren’t fully endorsing or embracing how popular they are becoming.
It’s more like android apps from early versions of Android before the permissions became user-managable.
It won’t prompt you to give the application access to certain permissions, all the permissions are predefined in the manifest by whoever published the application to flathub. When you run the application you just hope it won’t cause too much havoc (you can of course verify the permissions before running it, but I guarantee most people won’t)
Flatpak supports sandboxing but due to how most desktop applications want access to your home folder, network etc many apps simply disable it.
Regardless of the level of sandboxing applied to the app, Flatpak is a great way for a developer to package once run anywhere. Prior to Flatpak, if you wanted to support multiple distros, you had to build a package for each distro or hope somebody working on that distro would do it for you.
Inb4 AppImage was here first. And if you mention Snap then GTFO
Appimage is probably the most similar to a naked .exe in Windows. They are useful for small apps or simple indie games, but I prefer Flatpaks for my everyday big applications.
Agreed, Snaps are like Flatpaks but worse because locked down back end and Canonical’s sketchy nature. Imagine a really delicious pastry that anybody can make and sell, then imagine the same pastry but only one bakery in the world can make and sell it. Which would you prefer? Lol
a single application that gets bundled with all necessary dependencies including versioning
Does that mean that if I were to install Application A and Application B that both have dependency to package C version 1.2.3 I then would have package C (and all of its possible sub dependencies) twice on my disk? I don’t know how much external dependencies applications on Linux usually have but doesn’t that have the potential to waste huge amounts of disk space?
Most dependencies are bundled in the “runtime” images, and it uses file deduplication to reduce the size of the dependencies, but it’s still a little more than a normal package manager.
Essentially yes, if you start using lots if older applications or mixing applications that use many different dependency versions, you will start to use lots of extra disk space because the different apps have to use their own separate dependency trees and so forth.
This doesn’t mean it will be like 2x-3x the size as traditional packages, but from what I’ve seen, it could definitely be 10-20% larger on disk. Not a huge deal for most people, but if you have limited disk space for one reason or another, it could be a problem.
It CAN get pretty wild sometimes, though. For example, Flameshot (screenshotting utility) is only ~560KB as a system package, while its flatpak version is ~1.4GB (almost 2.5k times as big)
Weird, the software manager (using LM 21.3) reports 1.1GB dl, 2.4GB installed (which is different from when i checked yesterday for some reason?).
flatpak install reports around 2.1GB of dependencies and the package itself at just 1.3MB
EDIT: nvm im stupid, the other reply explains the discrepancy
Flatpak is a universal application packaging standard for Linux. It allows devs to create a single application that gets bundled with all necessary dependencies including versioning.
These apps run in their own semi-isolated “container” which makes immutable distros possible. (Distros like Fedora Silverblue that are effectively impossible to break by installing or removing critical system files.)
This means that a Linux app doesn’t have to have a .deb version, an .rpm version, or be pre-compiled for any other distros. A user can simply go to Flathub, (the main repository for Flatpak apps), download the flatpak, and install it on their distro of choice.
It’s quickly becoming the most popular way for users to install apps on Linux because it’s so easy and quick. But there are a few downsides like size on disk, first party verification, per-distro optimizations, and the centralization of application sources. That’s why some users aren’t fully endorsing or embracing how popular they are becoming.
Interesting breakdown, thank you.
Do you happen to know if the containerization is similar to docker containers? Or more like android apps?
It’s more like android apps from early versions of Android before the permissions became user-managable.
It won’t prompt you to give the application access to certain permissions, all the permissions are predefined in the manifest by whoever published the application to flathub. When you run the application you just hope it won’t cause too much havoc (you can of course verify the permissions before running it, but I guarantee most people won’t)
Flatpak supports sandboxing but due to how most desktop applications want access to your home folder, network etc many apps simply disable it.
Regardless of the level of sandboxing applied to the app, Flatpak is a great way for a developer to package once run anywhere. Prior to Flatpak, if you wanted to support multiple distros, you had to build a package for each distro or hope somebody working on that distro would do it for you.
Inb4 AppImage was here first. And if you mention Snap then GTFO
Appimage is probably the most similar to a naked .exe in Windows. They are useful for small apps or simple indie games, but I prefer Flatpaks for my everyday big applications.
Agreed, Snaps are like Flatpaks but worse because locked down back end and Canonical’s sketchy nature. Imagine a really delicious pastry that anybody can make and sell, then imagine the same pastry but only one bakery in the world can make and sell it. Which would you prefer? Lol
Cool, thanks for the explanation.
Does that mean that if I were to install Application A and Application B that both have dependency to package C version 1.2.3 I then would have package C (and all of its possible sub dependencies) twice on my disk? I don’t know how much external dependencies applications on Linux usually have but doesn’t that have the potential to waste huge amounts of disk space?
Most dependencies are bundled in the “runtime” images, and it uses file deduplication to reduce the size of the dependencies, but it’s still a little more than a normal package manager.
Essentially yes, if you start using lots if older applications or mixing applications that use many different dependency versions, you will start to use lots of extra disk space because the different apps have to use their own separate dependency trees and so forth.
This doesn’t mean it will be like 2x-3x the size as traditional packages, but from what I’ve seen, it could definitely be 10-20% larger on disk. Not a huge deal for most people, but if you have limited disk space for one reason or another, it could be a problem.
It CAN get pretty wild sometimes, though. For example, Flameshot (screenshotting utility) is only ~560KB as a system package, while its flatpak version is ~1.4GB (almost 2.5k times as big)
Flameshot is 3.6MB on disk according to
flatpak info org.flameshot.FlameshotWeird, the software manager (using LM 21.3) reports 1.1GB dl, 2.4GB installed (which is different from when i checked yesterday for some reason?).
flatpak installreports around 2.1GB of dependencies and the package itself at just 1.3MBEDIT: nvm im stupid, the other reply explains the discrepancy
no, that number don’t reflect the shared runtimes and deduplication