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
The kingpin linux OS
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.
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?
it is the present of linux
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
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.
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
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.
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.
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.
As others have said flatpak is not just the future, it is the present of Linux. Many mainline distros have fully adopted it and many smaller community distros, especially immutable ones like blendos and vanillaos, are all in on flatpak completely abandoning native packages for containers and flatpaks. I’d say for the average non-technical user, using Flathub through gnome software or discover is as good or better than the mac AppStore. The future of apps on Linux is very bright imo. Flatpaks have already brought in way more developers than before.
Linux is Linux - Nah.. there will be distros like Arch where you can just use the AUR (someone started a project to bring AUR like functionality to other distros), and there will be distros that go mostly or all in on other packaging methods. There's also wrappers like topgrade for those of us that don't want to bother with multiple commands to update all.
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.
Linux as a whole? Probably not, but that’s one of my favorite things about Linux, ones that use them and ones that don’t can coexist.
only played around with mint so no idea why folks hate flatpacks, it seems to be very seamless
I'm a software engineer, but when it comes to configuring and managing my OS I think I have more in common with the average user than a power user. I just want to install programs and I want them to work.
The other day I wanted to install valgrind. Should be easy, right? I'm on the latest LTS version of Xubuntu. That should be the easiest thing in the world, just sudo apt install valgrind. Lo and behold, apparently I'm in an unresolvable dependency hell.
But turns out there's a snap version of valgrind. Worked fine!
So what am I supposed to think? People bitch about snap, even here, but it works every time for me. Flatpak is the same thing to a guy like me.
I had the same experience trying to get a game (Stepmania) to work on Fedora. I could not resolve the damn dependencies. 3 hours later I found a flatpak of the game and it just worked immediately. I think I'm sold.
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
I think it will make a great "app store" for Linux. Easy for the new or average user to find and install apps.
well if flat pack dont work try snaps and from version of ubuntu?
Seems like so. It's far from ready though. Until it is (if it ever is...), I'll be happy on NixOS or MacOS (if I buy a macbook).
This is a most excellent place for technology news and articles.
