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.
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.
The kingpin linux OS
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
Our Lord and Saviour Nix
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.
Please no. I don’t have enough hardware for it.
it is the present of linux
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.
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.
Of course, if you actually want to sandbox something, there’s always firejail and docker
Yes it is
I’m liking them especially for long complile-time binaries that are otherwise difficult to keep up to date.
I’d say it’s the future but it’s kind of already the norm. They’re just a lot better then system packages in a lot of ways. Predictable, one system developers have to target, portable, immutable, and system agnostic. Linux has needed this for a long time. This is similar to how apps on your phones work. Windows is going this route too, and I think OSX does it too but I don’t use that garbage os to know.
MacOS is similar but better. The sandboxing and permissions were planned and implemented long ago, and getting a new app is as simple as downloading its .app bundle and running it.
MacOS apps are sandboxed and signed by default now. The biggest problem I see with sandboxed apps is they require more disk space and ram, for example each electron app can’t leverage the same underlying WebKit engine. The real benefit is that you don’t have to worry about incompatible dependency versions wreaking havoc on your system. It’s very difficult to modify the underlying OS, which is overall a good thing for most users.
Mac OS X is based on some really good design, portability, security, and development environment. BUT some of the direction Apple has been taking for the last decade+ has made the platform less open and a lot less appealing to me (and others in my family).
I give them credit for vision that matches what some people want, and providing and experience that just works within that vision, but that vision doesn’t match what I want (or even need) from of desktop anymore.
The very fact that they work like mobile apps is a reason to dislike them, honestly. At least Flatpaks aren’t total fucking crap like Snaps.
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.
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 believe that will always be a linux distro that dont use it by default
I feel like there will always be some applications that will limited by being a flatpak.
Off the top of my head NeoVim comes to mind. My workflow uses libraries/config files/code from all across my home directory. I can’t imagine trying to shove everything inside a flatpak, or using flatseal to give it 10 billion permissions (at that point it may as well not be sandboxed).
What’s flatpak
It’s a universal package manager for Linux.
