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.
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