Is Flatpaks the future for Linux?

Ziggyred@lemmy.blahaj.zone to Technology@lemmy.world – 82 points –

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.

66

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

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.

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?

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.

1 more...

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.

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.

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.

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

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.

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.

only played around with mint so no idea why folks hate flatpacks, it seems to be very seamless

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.

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.

Same for me, snaps work everytime, flatpacks rarely do.

Firefox would like a word….

Forced snap+Firefox is hell

I agree that the decision to force users to use firefox as a snap and take away their ability to use it as a .deb goes against the linux spirit in a meaningful way, but the firefox snap has been working really well for a while now and canonicals 'political' games don't take away from snap's fundamental improvements over normal packages.

I think it will make a great "app store" for Linux. Easy for the new or average user to find and install apps.

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.

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

well if flat pack dont work try snaps and from version of ubuntu?

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