Nix’s package repository is gigantic and you can use Nix outside NixOS (Linux systems and MacOS, and soon in a future version FreeBSD too), but not many people mention it as an alternative to Flatpak.
I don’t like Flatpaks for a few reasons:
They are not source-based but really should be. A universal packaging system that aims to be system-agnostic (in the Linux space that is) should also be CPU-agnostic. Most packagers only distribute for x86_64.
Flatpak’s sandboxing gets in my way, with little security improvements. If I wanted proper sandboxing I’d run a virtual machine.
Tons of library duplications, which wouldn’t be necessary if Flatpak was declarative (similar to NixOS), since it would still avoid dependency hell while not bloating the system
While libraries are not shared, runtimes are, but you still get duplicate runtime versions. You just have to install a handful of Flatpaks and you immediately have multiple versions of your GPU drivers, gnome runtime, and more. This is an even bigger bloat concern than not sharing libraries, making Flatpak only worth it if you install most of your software from it.
Flatpak is not appropriate for CLI and TUI programs, and as such the Flathub repository barely has any.
Many upstream developers treat Flatpak as their only official distribution of their program to Linux, which sucks really bad. Not enough developers distribute binaries/jars/etc.
Flatpaks are only for Linux, no BSDs. Source-based packaging would make this easier.
I don’t even consider Snap as an alternative, I think Snap is really bad.
I don’t like Appimages much, static binaries do a better job since they don’t have a dynamic link to libfuse.
More people should give a try to using Nix instead of Flatpaks. You get source-based packaging with a repository bigger than the AUR, with no library duplication or runtime bloat but still immunity to dependency hell. You can choose between a stable channel and rolling release channel, with the stable channel updating twice a year. Proprietary software is available too, just like Flatpak.
Sure, you don’t have sandboxing, but not many people really care about that, and those who really care about strict sandboxing would run a VM or container. Nix’s repository is an audited system downstream repository either way, so risk of malware is significantly lower.
Flatpak has upsides besides all of this, and it’s a good alternative, but it should not be the main way of distributing software.
You could say the same about systemd, as in not all software made for Linux is compatible anymore with other Unix-like systems because a lot of Linux software now days has systemd dependencies.
Not really. Since 5 different flatpaks can include 5 different versions of the same library, they won’t be deduplicated. Additionally, flatpaks often ship with out of date libraries because the devs don’t update them.
Indeed, if different apps depend upon different versions of the same library, then it must be stored again.
Its their design choice to let packager pull in whichever version of a dependency they want. Not something I like from an end user standpoint.
In my view, this is more of an issue with Flathub, than Flatpak. In fact, the Flathub package repos have FEDC pre enabled. If the packager has provided relevant metadata in the build specification file (example), then anytime a dependency has upstream update, there will be a pull request created automatically. Upon the maintainer merging it, the package is automatically built and updated on Flathub (example)
The process has been made smooth for maintainers, but the way Flathub works, there’s a lack of quality control. Random people end up publishing applications without the intent of actively maintaining it.
I packaged/maintained apps for KDE; we are active with updates. I know that the stuff we published were all by trusted maintainers from KDE. Still, I can’t extend this ring of trust to whole of Flathub and personally, I don’t use Flatpak at all.
Flatpaks are good and improving. On an immutable distro/installation they are fantastic, almost a requirement for a smooth experience. Devoid of dependencies on a read only OS they simply fit in as designed. On a regular distro they are great for one off programs that would either pull in a large number of dependencies or one where it is not packaged by said distro. They are still a work in progress, and primarily targeted towards client, and edge devices. Regular packaging is not going anywhere, it is still needed for most server use cases and particularly hosts with build services or virtualization. That being said I think we will definitely see immutable distros and items such as flatpaks become the standard. They are just one piece of the puzzle.
Immutable distributions aren’t the answer to everything, maybe for a subset of users that don’t like to tinker with their distributions but just want something to work without having to configure anything themselves and not have to worry about breaking updates, so basically the Android experience. For this same reason I won’t see distributions like Arch, Gentoo and other tinkerer distributions heading this direction but it takes the way part of the freedom of being able to manage your own installation because it limits what you can do because of the way it works.
This tells me a lot, 1) you don’t really understand what an immutable distro is, or what it’s capabilities and limitations are, and 2) you did not really understand what my post was about. I see this a lot when anyone brings up atomic or immutable systems.
You can in fact tinker with your install, the steps are different and simply harder for a bad actor to take advantage of, but once you know how, it is trivial. Nothing comes any more pre-configured than any other distro. It is nothing like the android experience, you have just as much ownership as if you ran a regular distro, it’s just a hell of a lot harder to break. Just because it uses similar concepts to how android is constructed does not make it remotely the same.
Last I checked you can create an immutable distro with both Arch and Gentoo, in fact there are several under development, neither will likely offer it out of the box in the near future. They take away zero freedom, they simply change the way you manage the installation. They can make every distro a rolling distro or turn them all into a stable enterprise like distro, simply by rebasing to another image.
Immutable systems are once again for edge devices i.e. devices likely to face attacks from bad actors in a DMZ or Public facing location. Immutable systems are for clients i.e. laptops or workstations, which once again have a number of security risks related to their use case or nature that an immutable installation helps mitigate against. It is even for servers in many cases.
Immutable systems are simply a better way of doing things, and all the tooling for them is almost prime time.
I admit I don’t have any actual experience with immutable distributions, I just read and hear about them, from my understanding the way to customize your installation is to change an overlay or the os image which sounds limiting to me. I do have a Steam Deck and if I remember correctly that runs SteamOS which is an immutable distribution, I haven’t had any problems with it so far but I haven’t had the need to do so because I just use Steam on it. I am open to learning more about immutable distributions but from what I have seen about them I don’t really like the sound and first looks of them, if I were to want to experiment with one which one would you say to try? Fedora Silverblue or another and can you run a Qemu/KVM/libvirt setup with an immutable distribution and how is the gaming experience?
To simplify things, see them as “layered” distros rather than immutable. You can freely change / modify layers. One layer for base system. Another for packages you want to install. Another for the specific configurations you make. Yet another for any “experiments” you want to do with your system. If it breaks, just boot into the previous layer.
For a (bad) analogy, compare ext4 and btrfs. Both let you freely store/read/delete files, but btrfs adds an added layer of complexity that makes it a bit harder to bork your system. Btrfs doesn’t impose arbitrary limitations on how you can use your storage.
I’ve used Fedora Kinoite. Not a bad choice for most “regular users”1. Its slightly different from traditional OSes, but not “locked up” in the way “immutable” sounds like.
1. Don’t use Kinoite if you’re averse to Flatpaks.
Thanks for the explanation, that’s sort of what I had in mind but wasn’t quite sure how that would exactly work when it comes to customizing things. What’s the difference between Kinoit and Silverblue? Does a Qemu/KVM/libvirt setup work on an immutable distribution and how is the gaming experience on an immutable distribution?
If you really want to give a try, and really want to dig into it, then go with Fedora Silverblue. Make sure you are prepared to be frustrated, and be prepared to be patient. There is a learning curve is a case of an initial steep hill to get over preconceptions and trying to make it do things the way you would on a normal linux distro. Once you get past that it is actually quite easy. It took me maybe 4 hours of frustration to really get it, I had the advantage of being used to SElinux so the curve might be longer without that, but Fedora’s SElinux policy is pretty seamless these days so maybe not.
Don’t avoid the flatpaks, embrace them. They make a number of items easier in the long run and since flatpak is a flatpak manager you can easily manage what is going on with this packaging system.
Yes you can run qemu/kvm/libvirt however note you may run into some minor issues not because of Silveblue but because Fedora has split libvirtd into a variety of virtqemu systemd units to offer more granularity over how the virtualization stack is handled. I think everything in a fresh install of Silverblue 40 should be resolved. I will however say that since Silverblue is container centric I have moved away from using full VM’s and stick mostly with containers. My VM usage is pretty much strictly restricted to my servers, and if I feel the need to spin one up on my laptop it is usually for a short term testing scenario in which case Boxes (It still uses KVM under the hood) has proven to be sufficient. Another useful tool is toolbox which allows you to run a Fedora container that can interact with the system.
As to gaming, I have no personal experience, however the consensus on the community is that Steam in particular runs particularly well on the system.
If you have any direct questions or want some recommendations (i.e. pitfalls to avoid) to setting up a system, feel free to PM me.
I’m familiar with RHEL systems so I know selinux as well.
I would start by just experimenting in a vm just to get some experience with it., not planning to directly install it on my main system. That way I can get a better understanding of it, before I make further decisions.
Atomic operations are a concept in computer science, where an operation (or set of operations) either happens or it doesn’t. It can never happen partially. Eg. Atomic operations are used in databases because you want operations to run completely or roll back if there was an error. You never want a db query to execute partially, because that will cause inconsistency and/or incorrect data.
In context of Fedora, they mean that system operations (like installing packages, updates etc) will be atomic. You’ll never have an update that failed midway causing chaos. The “layers” I talked about earlier are how Fedora ensures this. Changes are added to a separate layer and only when the operation is completed, the system can use the new layer. Otherwise, you’ll remain in the previous layer. Again, if you know how Btrfs works, this should be simple to grasp. 1
Just for sake of comparison, this is, for example, not possible on Arch, where an update may fail midway and cause partial changes to system. Do note, if at all this happens, its almost always due to a user fault. I find Arch to be a perfectly stable. Its just that from a technical standpoint, Arch updates are not atomic and incidents like a power loss during update can lead to a broken system.
Also, Fedora doesn’t mention immutable, at least on their main pages, because the system is not immutable as such. Layers once created are immutable. But you can freely add changes to a new layer and then use it.
1. I’ve totally dumbed down the concept of atomic operations just to make it simple to understand. It is in fact, much larger topic.
While you bring many good points, I feel like its technical downsides are more or less outshined by the fact that Flatpak tries its best to be as universal as possible, with extremely minimal setup from the end user to install and use applications from. If that’s a good or bad thing is up to you. One is more than free to try and use whatever they please and want on their systems to solve their own problems and follow their idiosyncrasies at the same time.
