Can I ignore flatpak indefinitely?
-
Or use a stable distro and need a package newer than 2 years.
-
As someone who develops an distributes a small application exclusively on Flathub, I prefer that everyone uses the exact same package on every system. That way I know that if something doesn't work, the issue should be easy to reproduce.
Recently, there was a situation where a user indicated in the comments of a release announcement that a newly introduced feature “doesn't work”. It turned out that they installed a third-party package from the AUR (that wasn't updated yet) without knowing that this isn't the official and up to date version.
This seems to be a dependency failure.
I'm sad that we had this solved 20 years ago. It's like Texas measles.
-
I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.
I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?
Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?
Is it because developers are often using dependencies that are ahead of release versions?
Also, how is it so much better than images for your applications on Docker Hub?
Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.
Personally it depends on distro and package manager.
If your on arch yes you can in a easyish way
Other distros you can either compile the software from source or convert .deb to .rpm (for example) this is mediumish and takes time to do. -
It depends a bit on perspective and use-case, really. A flatpak'd application can be a fully-featured (all dependencies bundled) package in order to be portable. However, most flatpaks you might commonly encounter don't quite do this. A good portion of the libraries may be distributed in common runtime packages. This will be the case if you use flatpaks from Flathub or Fedora. There still can be bundled libraries with vulnerabilities, but in many cases, there are basic dependencies from external, common library sets.
As far as varying dependency versions, a developer may be on a host with either newer or older dependencies than expected by the user, but as long as the developer's application (and any unique libraries) are compiled against a common runtime as previously mentioned, it does make distribution to a wide variety of distros (LTS, 6-month, and rolling alike) relatively easy.
In comparison to OCI images (the kind of images that make up Docker, Podman, and a good portion of Kubernetes container images), flatpaks are a bit less extreme. Flatpaks contain much the same kind of files and structure that a standard distro package would, but simply get sandboxed into their own environment (via bubblewrap). Additionally, flatpaks don't necessarily need system-level access for installation and usage (full userland confinement). It heavily depends on host environment and configuration, but typically OCI containers are a full, minimal, immutable filesystem structure run in a virtual environment. Not quite a virtual machine, as (in Linux anyway) they are run on the host (almost always in a sandbox) without extensive virtualization capabilities being needed. The general difference in security capabilities depends on the differences in sandboxing between a flatpak behind bubblewrap and an OCI container's runtime sandboxing. There is also the notion with OCI containers being able to run as virtualized users, including root. With OCI containers that can obtain root access and a flaw in the sandboxing of say Docker in its standard rootful mode could allow for root level processes in the sandbox to act upon the host.
From what I can think of in comparison, there is the big problem with Flatpak in that it really isn't suitable for packaging command-line applications: only GUI applications and libraries. OCI container images are often tailored for running web apps and other persistent CLI applications
OCI CLI apps can also be obtained from brew
-
Thanks for the detailed answer. I think I have a clearer picture of the problems it's trying to solve and the solutions it's delivering.
It also now seems connected to immutable distros I've also heard about recently. So I guess the idea there that the OS is just a tiny core set of libraries that never have to change, then the applications have their dependencies bundled, instead of requiring them as system dependencies.
I'm not convinced it's something I want as a user, but more importantly not something I need.
From a development perspective, it seems downright seductive, allowing almost total freedom of opinion.
As a user I definitely want flatpaks and use them over distribution packages whereever possible. First I can sandbox the flatpak, but not the native package. Why would my browser need to be able to read my ssh keys?
Secondly I just have seen too many distro packagers sabotaging packages in the most braindead ways possible. Debian removing almost all the random data during key generation because some static analysis tool did not like the code. To this day there are servers using one of the 32k keys debian could produce during that time (they are of course all brute forced by now). Fedora removing Codecs from a video encoder, dependencies that upstream knows are broken and listsmas such in its documentation being used anyway. Random patches being applied, or versions years out of date getting shipped...
-
As someone who develops an distributes a small application exclusively on Flathub, I prefer that everyone uses the exact same package on every system. That way I know that if something doesn't work, the issue should be easy to reproduce.
Recently, there was a situation where a user indicated in the comments of a release announcement that a newly introduced feature “doesn't work”. It turned out that they installed a third-party package from the AUR (that wasn't updated yet) without knowing that this isn't the official and up to date version.
It just has to always be the first question in a big report or forum question. Have they verified their issue with the Flatpak version?
I prefer packages from the AUR myself but I do not expect the software authors to support me. Arch does not support the AUR either. The only support I should expect would be from the package author (the AUR package) and they likely do not have the ability.
-
I'm using MX Linux AHS, it is Debian based, it is always up to date, like latest firefox a few hours after it's out, kernel 6.12.17 as of today, etc.
It has no systemd, no snap, no flatpak. It just use the good old .deb and everything is working fine.
Glad it is working well for you. What does that have to do with this post?
-
I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.
I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?
Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?
Is it because developers are often using dependencies that are ahead of release versions?
Also, how is it so much better than images for your applications on Docker Hub?
Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.
This is what's so great about Linux, you can use whatever the hell you want.
Flatpaks provide some cool security functionalities like revoking network access to a specific application. Maybe you care about this, maybe you don't.
My personal policy is to always install from the repos. Occasionally something is only available in flathub, which is fine for me. I really understand how hard is maintaining something for every single package manager and diatributions and totally respect the devs using a format that just works everywhere. If I were to release a new Linux app, I would totally use flatpak.
-
Arch based distros (except for Manjaro) has every FOSS and some proprietary software on the AUR
Let me try to clarify what you are saying.
You are saying that the AUR “has every FOSS and some proprietary software”. Yep. That is why I add an Arch Distrobox to every system regardless of the host distro.
But what do you mean by “except Manjaro”? Most Manjaro fans will say that Manjaro also supports the AUR. They are correct that you can certainly enable it and start installing packages from there.
I assume you are warning that, because Manjaro maintains its own base repos and has different package versions in it than Arch does, that Manjaro is incompatible with the AUR and that using the AUR with Manjaro will cause problems. If that is what you are saying, I agree with you.
-
Adopt
nixand you will be able to ignore it forever!
Seriously though, as others have said, use whatever fits you best. I avoided snaps and flatpaks due to the increased size requirements. So many things were duplicated for no apparent benefit (to me). However, with their introduction of permissions and portals, it does seem like a safer option. Although, we're in a phase right now where not everything is flatpakked and applications trying to talk to each other is a pain (keepassxc unable to talk to flatpak
firefoxlibrewolf, chromium, etc.).Now that I use nix, I have a whole bunch of other problems, but at least getting packages is quite low on the list.
Thanks for the suggestion. I am interested in nix, but haven't explored it yet.
-
Do you have a resource I can take a look at for what this implies at what it accomplishes?
Sure, here are some:
http://security.stackexchange.com/questions/259088/ddg#270934
https://en.wikipedia.org/wiki/Digital_signature
The main feature would be that if flathub (or a hacker with access to flathub) acted maliciously, digital signatures would prevent them from issuing malware infested updates to flatpaks. Only the software's originator would have the cryptographic key needed to sign releases of the software.
-
Thanks for the suggestion. I am interested in nix, but haven't explored it yet.
I wasn't being very serious about
nix. IMO, it's quite the time investment due to its poor documentation and it has a lot of gotcha's if you aren't on NixOS e.g one example is that it's great for terminal applications, but horrendous for GUI applications as it'll be hit or miss. Again, this is if you're not on NixOS. So, it can feel like an "all or nothing" approach.If you have the time and will, then it can be very rewarding. But if you just "want something that works
" side by side in your current system, personally, I wouldn't recommend it - unless it's hidden by some other tool like devenv(which is a great tool for reproducible developer environments). -
I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.
I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?
Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?
Is it because developers are often using dependencies that are ahead of release versions?
Also, how is it so much better than images for your applications on Docker Hub?
Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.
I never use flatpaks and am doing just fine. I don't want my packages to be installed from a bunch of different places; I want it all managed by one package manager, which for me is my distro package manager. I've never noticed a problem arising out of not using flatpaks; everything I want is either already packaged for me, or I can make a package myself.
-
Another upside is the easy permission management.
You can revoke network access from your password manager to reduce attack surface; you can revoke camera access from your chat app to prevent accidentaly enabling it; You can restrict an App's file system access to prevent unwanted changes; etc.
It's not yet fit to protect from malicious apps, but it still finds some use.
It’s not yet fit to protect from malicious apps, but it still finds some use.
That it is "not yet fit to protect from malicious apps" is an important point which I think many people are not aware of.
This makes sandboxing something of a mixed bag; it is nice that it protects against some types of incompetent packages, and adds another barrier which attackers exploiting vulnerabilities might need to bypass, but on the other hand it creates a dangerous false sense of security today because, despite the fact that it is still relatively easy to circumvent, it it makes people feel safer (and thus more likely to) than they would be otherwise when installing possibly-malicious apps packaged by random people.
I think (and hope) it is much harder to get a malicious program included in most major distros' main package repos than it is to break out of bubblewrap given the permissions of an average package of flathub.
-
I wasn't being very serious about
nix. IMO, it's quite the time investment due to its poor documentation and it has a lot of gotcha's if you aren't on NixOS e.g one example is that it's great for terminal applications, but horrendous for GUI applications as it'll be hit or miss. Again, this is if you're not on NixOS. So, it can feel like an "all or nothing" approach.If you have the time and will, then it can be very rewarding. But if you just "want something that works
" side by side in your current system, personally, I wouldn't recommend it - unless it's hidden by some other tool like devenv(which is a great tool for reproducible developer environments).Lol thanks for clarifying your sarcasm.
I can be an airhead at times.I was actually interested in trying NixOS on a laptop that is gathering dust. I did see a few months ago that there was some drama surrounding the project owner, though. I never investigated enough to understand what that was all about, but I'm less excited about digging into something if it may suddenly end.
-
This seems to be a dependency failure.
I'm sad that we had this solved 20 years ago. It's like Texas measles.
What do you mean by this? Flatpak definitely solved the Linux distro balkanization problem for application developers without trying to destroy the benefits of having different distros. Having a distinction between system software, utilities, and advanced end user applications does solve a problem.
-
This is what's so great about Linux, you can use whatever the hell you want.
Flatpaks provide some cool security functionalities like revoking network access to a specific application. Maybe you care about this, maybe you don't.
My personal policy is to always install from the repos. Occasionally something is only available in flathub, which is fine for me. I really understand how hard is maintaining something for every single package manager and diatributions and totally respect the devs using a format that just works everywhere. If I were to release a new Linux app, I would totally use flatpak.
Same boat. As a user, I greatly prefer everything to come from the repos. However, as a distributor, Flatpak makes so much more sense.
The only Flatpak I have installed is pgAdmin. I looked at the build on Flathub with the idea of porting the package myself but got scared off. It was a maze of Python dependencies running in Electron. That seems like exactly the kind of thing that may be better off in its own sandbox.
-
Glad it is working well for you. What does that have to do with this post?
no flatpak. chill.
-
Ok, show me how you compile Emacs 29/30 on a fresh Debian 10 install in a few minutes...
-
I'm admittedly yelling at cloud a bit here, but I like package managers just fine. I don't want to have to have a plurality of software management tools. However, I also don't want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.
I don't develop distributed applications, but Im not understanding how it simplifies dependency management. Isn't it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?
Don't maintainers have to release new bundles if they contain dependencies with vulnerabilities?
Is it because developers are often using dependencies that are ahead of release versions?
Also, how is it so much better than images for your applications on Docker Hub?
Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it's something I should adopt, or if I can continue to blissfully ignore.
So far I have also completely ignored them. From what I understand they technically allow you to install old versions of software, potentially having multiple at the same time. This could come in a clutch when working with stuff like Godot or Blender where constantly upgrading to the latest version would cause issues on bigger projects.
This is the only thing I can see myself using them for, at least in the near future.
