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 some aur packages may require you to compile it.
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.If the distro is rolling release, it can always support the latest software in theory, you’d just need to have the correct package formula, which is exactly what AUR offers.
The problem with AUR is just that the author of the package is likely not the author of the software and not affiliated with the distro, so you should normally check what the script is doing.
Just use Nix. It can run all the packages on whatever platform. It has the largest repository of software & are some of the most up-to-date.
But then I’d have to run Nix.
So? Not everything is packaged on all distros & you can benefit from sharing & reusing declarative configuration even if for specific scopes (meaning not just NixOS).
That’s why Arch has the AUR. :)
AUR has a lot of packages but still nowhere near as much as Nixpkgs
If your distro provides everything you need then I would avoid flatpak. Getting apps to speak to each other is a pain, updates use more data, backups and restores take much longer, they don’t perform as well and config files are not necessarily where you expect them to be.
I have Debian Stable on an older laptop and only install apps as flatpaks if they are not available otherwise. I also have a very new laptop with Fedora on it (because it needs a newer kernel) and have had to install more flatpaks just to make things work properly, because they include their dependencies, codecs etc which are missing in Fedora. Appimages seem to do this too and I find them preferable to flatpak because they integrate more predictably with my system. Apps are slower to launch though and have to be manually updated.
Like you, I’d prefer to just have a package manager and a single source of software and plan to go back to Debian when my newer machine is supported by it.
There are tools to update AppImages, like AM and Gear Lever.
Nice, I will have a look 👍
FLOSS used to include the ability to build software. Perhaps that’s not important anymore but now a days some developers don’t attend problems with their build recipes because they only consider what they release through binaries, whether on flatpak or whatever other binary repository they like. At least I dislike that, it’s ok to me some or most users would prefer to grab a bloated binary rather than building anything, but that doesn’t mean forgetting about those actually wanting to build from source, or wanting to use shared libraries and software from their distros, actually that’s a requirement for free/libre software repositories. Not sure if the tendency is to move the gnu+linux users into app stores like the ones on windows, now ubuntu snaps, android play store and the like. Sure there’s more security with sandboxing, but nothing one can’t get with firejail, and if wanting MAC as well then firejail + apparmor for example.
At any rate, just my little rant. And if you’re wondering, I use AUR on Artix, and I really hope I won’t have a need for a flatpak stuff.
Maybe but probably not. People that develop applications can save a major headache by choosing flatpaks so the ecosystem will gravitate towards it.
At some point new applications that didn’t launch a Linux version will do so but only on flatpak and older applications will start moving towards flatpaks since it’s less dev time.
It looks to me as inevitable that the best versions of an app will be a flatpak but if you’re on Ubuntu based system you can probably get by for very long without them.
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.
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.
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. Distros need to support their own packages but the AUR is not part of the Arch distro. Arch does not support the AUR. The only support I should expect would be from the package author (the AUR package) and they likely do not have the ability.
I think the right way to understand Flatpak is that it is essentially its own Linux distro without a kernel. You have to be running that version if you expect support. People think of Flatpak as a “sandbox” which it is. But it is also like running an app in a Docker container or Distrobox where you have to pick a distro to run in the container. With Flatpak, you are running on the “freedesktop” distro. It is not the same environment as the rest of your system (right down to the filesystem layout and C library).
Yes. Yes you can.
Ignore it. Move on.
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.
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.
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.
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 uses 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?
The real thing that Flatpak offers is one place to publish for Linux. You put your app in the App Store for Apple, you put it in the Play Store for Android, you put it in Flathub for Linux.
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.
I really understand how hard is maintaining something for every single package manager and distributions
But for apps distributed in your system’s package manager, it’s not the devs that are distributing them in every package manager. It’s the distribution itself that goes to each repository, checks and tests the dependencies they need and creates the package for the distribution, along with a compiled binary.
When they aren’t offered in the distro’s package manager (or the version is outdated because the distro isn’t rolling release) things become more complicated indeed, and sometimes you can’t even do it because the dependencies are older than the ones you require.
You’re just not the target user.
The whole OCI mindset is geared towards absolute noobs like me, and cloud native devs that develop inside containers on a daily basis.
Take me for example. I use Bazzite, it’s the first distro I couldn’t break. On top of that, flatpaks, appimages and brew are my only options for software. Since Bazzite is an atomic distro (think immutable ) I could also use Distrobox but I don’t want to deal with it.
Everything just works for me, I don’t care about anything. I broke so many distros before. Sure, I don’t control every nut and cranny but I don’t want to.
If you know how to not break your stuff then that’s great, but I don’t, and I don’t want to learn that. I just want to learn other things.
I just use it if the package/dependencies aren’t available or functional in the default arch repo. I like to be able to turn nuts and bolts but also avoid it when it’s inconvenient.
2 package managers is fine for me.
Not to be that person, but you aren’t restricted to those solutions for software, that’s what
rpm-ostreeis there for. It layers applications over your system image and installs software in a similar manner to a “normal” package manager.rpm-ostree is intended to be the last resort because layering causes issues with updates and other things
Sure, I was just saying that you could use it and aren’t necessarily restricted to the other options.
I’ve used it here and there when there is no other option, still no problems yet for the OS itself, but I have run into issues installing certain things, most likely due to my lack of knowledge.
I think I may be giving arch another shot soon as my needs have changed and it was so godamn close to everything I needed.
I like package managers just fine. I don’t want to have to have a plurality of software management tools.
Same. I grumble when I have to install things through the AUR. I’d prefer if it was in the official repos.
can continue to blissfully ignore
That’s what I’ve been doing. I haven’t run into a situation where I’ve needed to mess with Flatpak. 🤷 Curious to hear other folk’s experiences though.
Also for your consideration, Flatpak seems to be mainly used for desktop GUI apps. You’ll still need your regular package manager to install CLIs. So… if you wanna keep your software management tools to a minimum…
The AUR is a different kettle of fish entirely, though. I do see your point, but the AUR is solving a problem common to all distros; hosting a repository for applications that there isn’t willingness or capacity to host in the official binary repos.
Installation, removal, dependency management, etc are all still handled by pacman. As others have pointed out there are great tools available to aid in AUR usability. My favorite is aurutils.
doesn’t
yaysimplifies the AUR installation? Things have been pretty easy for me after I started usingyayyaysimplifies the AUR installationSimple to me means not having to install some random extra tool and just using
pacmanlike normal. That’s why I grumble.Haa understood. In that perspective yes it is not simple. I would also be happy if
pacmanhad better support for AUR.But I have a different perspective on this. I always look for the right or the best tool available to do something. So I’m not that hesitant to use another tool for AUR. I guess it’s a personal preference after all.
You don’t have to use an AUR helper, you could build it all with makepkg, but the helper just allows you to save time searching, downloading, and building.
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
