Another NixOS user (and minor package maintainer, if it matters) here. Essentially, NixOS is actually rather simple to write a configuration file for a particular program once you get the knack for the nix language and learn how to workaround the sandboxing. I would actually consider it substantially less involved as compared to (for instance) creating your own Debian package.

However, getting to this point will take a bit of effort, and this step is more or less obligatory to use software on NixOS, whereas it generally isn’t (but still is a good idea) on other distributions.

(There is a learning curve to packaging stuff yourself.)

“Learning curve” is an understatement. Nix is one of the most poorly documented projects I’ve seen, next to openstack. Coming into it with no background in functional programming didn’t help.

Maybe I shouldn’t have tried to package openstack on nix.

But I’ve tried to package other stuff, like quarto, and that was a nightmare. Nixpkgs didn’t have an updated pandoc and I spent an eternity asking around for help, to try to package it. An updated version just got pushed to unstable a few days ago. The same matrix channels I joined to ask for help have been discussing this since then. Props on them for getting it working, but anyone who says that you can easily package anything, is capping. You need to have an understanding of the nix language, nix packaging (both of which are poorly documented), and a rudimentary packaging ecosystem of what you are trying to package.

Don’t even get me started on flakes vs nonflakes.

I still use nix-shell for all my development environments, because it’s the best way for reproducible environments I can share I’ve found.

The single killer feature that convinced me to move to NixOS is the ability to very easily keep separate development environments separate. For instance, if you’re working on multiple dev projects that have different minimum requirements, and you want to ensure that (for instance) you don’t accidentally use features from after boost 1.61 for project A, because that’s the stated requirement, but you need features from boost 1.75 in project B.

In a normal distribution, in order to set up an environment that has the proper version for project A you’d need to set up a chroot, a virtual machine, a complicated set of environment variables in a bespoke script with custom installation paths that you need to set up manually and remember to source, or just install a newer version of boost and rely on continuous integration to catch it if you screw up.

In NixOS, you can set up different shells which all reference the exact correct version of the libraries required for every project, you can have them installed simultaneously and without conflicts, and there’s even a shell hooking program that will automatically load and unload this configuration when you change directories into and out of the project folder. It makes managing many different projects much easier. It’s like a better version of venv, but for everything.

Well, for playing games I use the flatpak version of steam and it works OK.

For dev work, it’s great overall. Especially its ability to create separate reproducible environments with whatever dependencies you need for every project. However, there are some tools (rare, but they exist) that don’t work well with it, and if your dev work happens to need them, it can becomes a problem.

For day to day (i.e. web browsing), it works the same as anything, with one disadvantage: there is a disadvantage here: it downloads a lot more than other distros on update, and uses more disk space. The biggest difference between NixOS, and say Arch, is not how it behaves once it’s up and running, but in how you configure it. Specifically, you have to invest a lot of time to learn how, and set up your system initially. But then reinstalls, and (some of) the maintenance, become easier.

To clarify, I was referring specifically to its ability to specify the full system configuration in its config file - not overall. But I haven’t used blendos, and my impression is mostly from a quick look at their documentation. They have a snippet with sample configuration. There, they have a “Modules” section, but I couldn’t find what modules are available, what options they have, how to configure them if we want to do something more complex than the available options.

Then containers are clearer: they have a list of installed apps, and then commands to bring them to the desired state (somewhat similar to a dockerfile). But even then, i imagine that if you have a more complex configuration, that’s going to get clunkier.

For other systems I think distrobox and toolbox are kind the intended way to mess with them. For configuration as code ansible is a popular answer.

Also: I think rpm-ostree only supports rpm-based packages, tho; right?

Can I install .deb software too?

I don’t think rpm-ostree could support .deb softwares, just like dnf/yum can’t support deb packages.

Can you share your use case for trying to install a deb package in Fedora? I’m just curious.

And is there any kind of system-as-a-config-file kind of solution available like in NixOS or blendOS?

Good question. I only have a few computers, so I had never considered about it.

It just makes so much sense in a way other distros don’t

Listen to the “Linux User Space” podcast, episode 404. They explain every immutability model af of now. Ubuntu Core is missing.

Ubuntu is creating something new, looks really great but based on snaps, which are not bad packages but rely on a nonfree store that cant be replaced. So meh.

VanillaOS and BlendOS also use containers to install apps, just like Fedora Silverblue. In fact, it’s easier to install native packages on Silverblue than it is on VanillaOS. Just set your terminal to start a container by default.

Also, can I “normally”/traditionally install software on NixOS, e.g. through Steam?

Depends on what you mean by traditionally. Steam works without needing any special setup by enabling it in your configuration, just programs.steam.enable = true. There’s also imperative package management with nix profile (don’t use nix-env -i which you will probably come across, it’s broken by design). Personally though I recommend sticking with the declarative configuration and nix-shell which temporarily brings packages in scope for the current shell only.

Oh no. The rebrand is not done. There is no Atomic site yet, Atomic= Fedora Desktop with OSTree (Silverblue, Kinoite, Sericea, …)

If you like GNOME, yes I recommend Silverblue a lot.

Fedora has a very different system of the core distro. But with defaults I mean that they dont have apx by default but the same underneath.

You could use a bash function for DNF for example, but in general it is

distrobox-create Fedora39
distrobox enter Fedora39
sudo dnf install PACKAGE
distrobox-export --app PACKAGE

for GUI packages

Is there something that attracts you to NixOS for that purpose?

I’ve got Nix OS running on one of my computers, and honestly, haven’t found it to be worth it for those usecases.

Dev work is not specific enough. Pip is a nightmare because it just wanted to modify folders that were read only and you never know what it wants to do to your system. Your experience may vary depending on how much the language package manager assumes about your system. If you’re in a container, it will work perfectly, though

Firefox just works, and I installed Steam from nixpkgs and it worked after enabling a few settings. Then I just enabled Proton on every game and it works okay, with a few weird bugs sometimes (although I blame Gnome for messing up alt tabbing sometimes)