So a few popular Linux distros decided to drop a few major packages like how red hat dropped rpm packages for libreoffice in favor for the flatpak packages.
If more distros decided to drop more packages from their main repository in favor for flatpak packages, then are there any obvious concerns? From my personal experience, flatpaks didn’t work well for me. If flatpaks become mainstream and takeover the linux distros, then I might just move to Freebsd. I just want to know if there is any positives to moving away from official repositories to universal repositories.
You must log in or register to comment.
Flatpaks are here to stay but they can exist alongside traditional packages.
Completely agree. I like the idea of Flatpaks and use them when I can but I’ve ran into issues that existed only in the Flatpak version of a program. Installing the traditional package resolved all issues.
I’m relatively newish to Linux and have come to notice that system packages run better for me than Flatpaks a lot of the time.
System packages only install packages that is missing. Flatpak brings with it everything. Something similar to Docker containers for applications.
It’s the midpoint before we ascend to enlightenment with NixOS
What is NixOS and how does it iterate on flatpak?
NixOS is a distribution built around the package manger Nix. Nix is not necessarily an iteration of Flatpak ( especially since it’s been around since 2004), but it does accomplish many of the same goals in a more robust way with fewer trade offs.
The main idea of nix is that EVERY dependency of a package is tracked, from the exact glibc version all the way up to e.g. Python packages. I am not a Nix expert, but my surface-level understanding is that this is accomplished by hashing the package and all its dependencies, very aggressively, so that even if a hot fix patch is released that doesn’t change the version number, the new package is still different (as is every package that depends on the new version). That enables Nix to be the best of all worlds as far as sharing system packages like a native dependency while assuring stability and encapsulation like a flatpak. So it ends being as fast and small as the former while being as convenient and cross-distro as the latter. There are other innovations, like declarative dependency management and perfect rollbacks, that make Nix/NixOS stand out, but the above is it’s main innovation over Flatpak and older system package managers.
It doesn’t iterate on Flatpak, it’s its own thing.
Describing Nix in detail would require a PHD thesis but in short it takes the concept of a version to the extreme; capturing every property about some package and encoding that into the “version”; a package bar-0.1.0 that depends on foo-1.0.0 and a package bar-0.1.0 depending on foo-1.0.0 that has been built with the same GCC but a patch applied to it are considered entirely separate. This implies that your package bar cannot accidentally depend on the wrong foo and that both can be present at the same time.
Using a functional DSL, you implicitly build up a tree of such “exact versions” of dependencies and this tree is then “realised” bottom to top.
It takes many inspirations from functional programming such as purity and immutability. The build takes place in a sandbox with no filesystem access outside the declared dependencies and not networking whatsoever and cannot be changed after the fact. This aims to ensure that a build really only depends on the paths it claims to depend on (those paths must also be “exact” versions) such that running the build again with the same inputs results in the exact same output.Again, describing Nix in detail would go beyond the scope of this comment but this approach comes with many useful properties which prevent entire classes of issues you could encounter with classical package managers such as dependency hell.
It’s not tied to NixOS either (that’s its own thing again; doing Linux system configuration management using Nix), you can install Nix packages on pretty much any Linux as it doesn’t interfere with your classical package manager. Give it a try: https://nixos.org/download.html
Considering the Steam Deck accounts for a huge portion of Linux installs, I think flatpaks are going to be here to start and only grow in popularity.
I have to ask though, why do people dislike flatpaks?
deleted by creator
Flatpaks are slow and take more resources. It is only useful for the riches who can afford 16 GB+ RAM and TBs of storage.
Ram and storage are both dirt cheap, I’d consider any new laptop/pc with only 8gb non upgradable RAM ewaste these days. 2tb NVMe drives have dropped below 100€ already and 1tb below 50€
question, just how much bigger is say flatpack version of a program over the native package? Like right now I am running steam in back ground and I have like 8 youtube video loaded to play latter. Together my browser and steam are using 6 gb of ram. Witch I believe are snaps. How much bigger and slower are looking at?
The program itself isn’t really bigger, what makes the difference is that it won’t use the dependencies installed by your native package manager, it will download them, it also will download various runtimes if needed for the program, these runtimes are not really supposed to be ran if you compile the package yourself for your distribution, but if you use Flatpak, it is going to run all these runtimes for the program to work, these runtimes will use more RAM than the native build, if the runtime is not optimised, then it will also contribute to higher use of CPU and everything else in general.
It will differ from program to program, but I’ll let you know that I have natively compiled EasyEffects (real-time audio manipulation) and also have tried the Flatpak build. The native version hardly uses more than 5% CPU, and is also lightweight in terms of RAM. But the Flatpak build took significantly more RAM usage and my CPU went 80% whenever I played music with the same preset that I tested on the native build. Flatpak also had to download 700-900 MB worth of internet (no idea how much space it took after installation) for the program to run.
It makes sense to drop them in favour of flatpaks but flatpak, snap or appimage are still not fully developed. I think that universal packaging makes sense for some (most) apps.
For core OS apps it makes sense to package them the old way but everything added like office, games, browser … it is just not sustainable.
well if flat pack dont work try snaps and from version of ubuntu?
I have also avoided flatpack and the like.
On Arch and other Arch based distros, if something isn’t in the community repo it’s extremely likely it’s in the AUR.
Flatpak just sucks for us with potato level hardware. It is much slower and crashes. Some things just didn’t work until I got mine built from source using AUR scripts. I had checked the memory usage, the flatpak version of EasyEffects took much more memory than the native one. I don’t want Linux to become Windows with this Flatpak nonsense that wastes my desktop’s resources more than it should. Whenever I played music with EasyEffects flatpak, my CPU usage went up literally 80%, but with the native build, EE now does not go beyond like 5% CPU.
Any package that will force me to use Flatpak, I simply won’t use it at all, or find some workaround. I will not donate a single penny to the project itself, but I will to the one who found the workaround.
I recently installed Manjaro, and tried to install VSC.
In the official repos there is only a free version called Code with which the synchronization failed, and I could not synchronize my settings and plugins. I tried with the Flatpak version and although the synchronization was working, the interface was inconsistent and using zsh from my distribution and not bash in the integrated terminal was complex. Then I gave up when I saw that I could not get a Git-flow plugin to work because although I had it installed, VSC did not see it.
Install the Snap version, the interface is consistent and 0 problems.
So I think it’s not a bad thing to gradually move towards more contained apps like snap or flatpak, but there is still a lot of work to be done to make them fit all needs.
Have you checked the github page? It lists solutions for (some of?) your issues: https://github.com/flathub/com.visualstudio.code#usage
But I agree with you, flatpak needs a lot of work. In saying that though, I’d never touch Snap - that just brings in a whole host of other issues. I’d rather just use the official tarball or install the official .deb/.rpm into a container.
Yes, I looked for the zsh problem and found the solution, I also looked for the git-flow problem. But this one seemed more complex to solve with the solutions I found, and I had no more time. So I opted for the quick option which was to install the snap version and everything flowed smoothly until today.
There will always be distros that buck the trend. I’ve never had to use one in Arch or Manjaro. I doubt Arch would ever make it a default/requirement since Arch is largely about building the system out yourself with what you need. I also don’t see Flatpak being integrated to the Linux base system (yes, I’m aware Linux is just the kernel) like Systemd is.
Every graphical app I have installed that isn’t a basic system application included with the distro install is either in a podman container or flatpak.
I haven’t really kept up with flatpak, so maybe my view of isn’t right.
but what is your reasoning behind using flatpak for all your GUI apps instead of your distributions package manager?On the fly atomic updates (the recommended update path for DNF installed apps requires a system reboot.) Though you can do it live, doing offline upgrades is safer so you don’t replace some runtime something is using midflight.
Also, flatpaks have some system isolation and have to use flatpak portals and explicit permissions/mounts giving them less ability to negatively affect my system.
Also, Flathub just has everything that I need to run anyway, at least for GUI apps.
only played around with mint so no idea why folks hate flatpacks, it seems to be very seamless
flatpak seems to be adopted by everybody who’s not directly affiliated with canonical. Which is only about half of the linux desktop space. Snaps are controversial, but I like them. Currently I’m on Ubuntu with 23.04 and snaps, they work really fine for me. Most of my VMs now use OpenSUSE Tumbleweed with flatpaks though, and that works really nicely as well. ‘Normal’ users probably don’t care, so I’d say that both packaging formats will slowly replace everything else, but only snaps can form a complete system. Flatpaks cannot be used without apt/pacman/rpm/zypper/whatever. Edit: the main benefit of moving to universal repos is consistency. Flatpaks and snaps on ubuntu work exactly the same as snaps and flatpaks on arch, there are no version differences, no differences in dependencies.
The snap install I did of nextcloud on my server was sooooo painless compared to manually doing it or the AIO docker crap they have. It was a trivial install with snap. Upgrades have been easy peasy.
I only use ubuntu on my servers, but for this specific use case I’ve been very happy with the snap.
I don’t think the average user cares tbh. I have OpenSuSe, Fedora, Win 11, RHDesktop currently running. From an admin level though, so long as it’s well documented, transparent, and standard packages are available and maintained, I’m happy to continue to learn and be adaptable
Please no. I don’t have enough hardware for it.
