Real talk: NixOS

For the last few days, I have been informing myself about NixOS. A podcast I regularly listen to has a NixOS advocate, so I have been exposed to propaganda in that regard. And although it currently is considered a “fad”, or “the next big thing everyone is chasing”, I do not want this to be a reason to be uninformed about Linux developments.

Why am I on EndeavourOS:

I am a Linux gamer. I have been for a few years now. While Valve Steam makes it very easy to use Linux as a gamer, a bleeding edge system is - if not a must, then at least very conductive to a good gaming experience. Current state drivers, Mesa, Kernels help with gaming, and a distribution who supports these edge-case packages makes it easier to game. And in that regard, Endeavour with the AUR support helps tremendously.

I am using a BTRFS root to mitigate possible problems with bleeding edge software, doing both scheduled and before-system-upgrade snapshots, which are listed in my boot loader to boot into. Pretty neat!

Now, learning about NixOS and the way it works seems to reproduce my use case pretty well. Not only does it sport an impressive amount of packages (much more than the AUR), it also solved the danger of breaking a system with a new package installation by keeping old installations around to boot into.

Now, while many articles I have read and videos I have watched praise NixOS’ ability to go back to a previous system configuration, one of the questions I am asking myself is: Will this prevent all f*ckups? I’ve read threads here where a kernel upgrade suddenly broke certain file system types from mounting, or breaking an integrated graphics driver, or not mounting the EFI partition anymore.

Does the NixOS package way help with these problems? Or do advocates conveniently not talk about these possibilities while overselling NixOS as a safe system?

I do not care about the declarative way of system configuration, because I do not see any advantage for my use cases in the ability to completely reproduce my system installation. And this is not even true. Not only does this not help with files and configurations in my home directory, it also does not help with Firefox extension configurations, or my Freetube database, my KeepassXC files, and so on.

So, from one purple entity to another, peeps, tell me your most unbiased takes on NixOS. What did you experience? What was the biggest drawback for you?

Nixos has been around for quite some time now. I am not sure why it would be a “fad” at this point. :slight_smile:

Yes, it does help with that. It isn’t universal protection. For example, if it you erase your disk, there is no coming back from that unless you have a backup.

However, it helps with two things that you discussed:

  • Breakage caused by package changes
  • Running different versions of software without having to worry about libraries shifting in most cases

That being said, there is a substantial cost for that. Additional complexity and a substantial learning curve.

Then you shouldn’t use NIxos. That is one of the core underlying principles of Nixos and something that you will have to invest significant time in learning.

There is Home Manager for that.

I have been using Nixos for about 5 years now. I use it mostly on servers.

I tried using it on a desktop when I first started and gave up on it after about 6 months. It was just too much of a pain to do certain things and there was some software that just couldn’t run on Nixos.

Coincidentally, I decided to give it another shot 3 days ago and have installed Nixos on my laptop and am trying it out again. 3 days is not really enough time to report on it though. Also, my laptop is not my main computing device so it isn’t nearly as complex as my main desktop.

The biggest drawbacks for me compared to an Arch-based distro are:

  • There is a steep learning curve. Working in Nixos is very different than most other distros.
  • Some of the less common desktop packages are not well maintained
  • Declarative setup has pros and cons. Having to edit a config file to do basically everything adds complexity.
  • Some things on nixos on quite complicated. I remember needing a crazy derivation to change the sddm background since it needs to be done declaratively.
  • If you have no scripting or programming experience at all the learning curve will be even higher. To be clear, you don’t need to be a software developer but if you don’t understand basic concepts like assignments and how blocks of code work, you will need to learn.

That being said, there are many great things about it too. As with every other distro, for every problem it solves, it creates another and you need to decide which trade-offs you prefer.

I would recommend trying it out in a VM.


NixOS is but one of many so-called, immutable Linux OS’s. I know next to nothing about NixOS. So I’m not sure if I can contribute much here, though I will certainly follow this topic. But, while I’ve barely scratched the surface on any of them, I’m assuming this discussion could be about any of them? Or are you curious about the specifics of NixOS in particular?

Well, the advantages I see in NixOS are both the rolling release/bleeding edge nature of the unstable branch, and the protection that the nix package manager idiosyncrasies provide. I am open to discussing distributions that support both these advantages, as those are the protections I currently get from EndeavourOS and my setup (BTRFS snapshots + boot entries).

1 Like

I’ve never actually used nixos, but I know people who have, and my understanding is the declarative way of system configuration is a major pain in the ass, at least when you’re first getting used to it, maybe it gets better after using it a few months, i’m not sure. But from what I’ve heard of it I know I personally would hate it which is why I haven’t tried it myself.

And yes, they are in fact overselling how safe NixOS is, there are cases where an ‘old configuration’ can break, and I don’t actually think they’re that rare, so the system restore thing while extremely useful (if you don’t know what you’re doing…) isn’t perfectly reliable, and for new users i’ve seen it become more of a crutch than an actually helpful tool.

As dalto said though, it sounds like it would be extremely good for servers.

The funny thing is - and that’s more a story than anything else - that I am decently well versed in a system setup and configuration tool called Ansible. I had an incredible training in it with Jan-Piet Mens where I learned about the tool. It, too, uses a declarative way of describing a state in which you want a system to be, and the tool, when run with that configuration, figures out how to get to that system state. You can declare users, packages, and ten thousand other things in that way. That means that the idea of declaring your end state and then letting a tool figure out how to get there is not unknown to me, and I do not find this alien.

Friends who work as DevOps even do their whole cloud configurations this way (infrastructure as code).

So I would not consider the idea of declarative system configuration to be a drawback. But of course the process and management can still be a major PITA.

The interesting thing about immutable diistros is that they are almost all radically different.

If you compare Nixos, Fedora Silverblue, OpenSuse Micro and VanillaOS they couldn’t be more different. They don’t even have the same pros/cons.

1 Like

So, it seems, there is no “learning immutable Linux”. More learning a specific immutable Linux distro?

Sorry, @DromundKaas . It wasn’t my intention to hijack your topic. Apologies.

I heard that it is already more than 20 years old. Crazy! It even predates Ubuntu.

That’s probably not going to be a problem, I have a software development background and am currently developing in Python.

That is a good suggestion, I think. I have never reinstalled my system without a hardware change (where I consider that mandatory).

I might try it that way.

Thanks for your input.

1 Like

No worries. This is the talky-talk part of the forum. That’s why I am here.

Thanks for your input.

1 Like

Yes, exactly.

For example, Nixos has a steep learning curve but Fedora’s Atomic editions don’t have much of a learning curve at all.


I discovered NixOS for myself last summer. It was a revelation. The concept felt marvelous. Four weeks later everything was set up to perfection. I was ready to switch. But over time reality set in.

From the top of my head.

  1. There is a steep learning curve. And you won’t be cuddled. The Arch wiki is poetic prosa compared to the NixOS documentation. Compare the topics in this forum to the level of technically in the nixos forum.
  2. Stable doesn’t mean it wont break, it just becomes unmaintained. Everybody moved on to Unstable - which has its own issues.
  3. Nixos may have more packages, but God forbid that package breaks, it can take weeks or months until someone fixes it.
  4. Yes, snapshots are great, but I rather roll back a single package for a few days than have the whole system being stuck in an old state (see the point above)
  5. You have to understand a new language and a complete system to tweak little things that would be a ten second one-liner in an Arch PKGBUILD.

There are absolutely great features in nix/NixOS - I still run in on my laptop - but I wouldn’t consider NixOS for my main system at this point. It requires too much head-space to keep a computer going. Maybe if I were younger, or someone would pay me for it …


So, would a good start be to try out Fedora’s Atomic editions to get a feel? or perhaps just jump straight into NixOS?

That’s really the kind of hot-ish take that I was looking for. I read so much praise for NixOS that I could only wonder what the praisers wouldn’t want to tell me. Thank you for your personal experience.

If it’s not too much trouble, could you hint at some of those problems? I would consider a rolling release like EndeavourOS similar to running unstable in NixOS, and I am curious about how the problems line up between these two.

I don’t remember precise packages and occurrences, so I can’t provide a hard data-point.

But for example there was security issue and a package was updated upstream. Did you get the update on NixOS stable? No. You get a message that this package has a security problem and you have to manually allow that package to run in that outdated version. The “solution” is to use Unstable.

What’s the point of all the “we isolate packages and dependencies so you can update and run them individually” if you don’t update them?

Or big packages like - from the top of my head - VirtualBox constantly switching between precompiled binaries and local compilation. Doing an update and randomly compiling for an hour on a laptop isn’t exactly fun:tm:.

This is my laptop for weeks now. Granted, that is Unstable, but there are NixOS people who will tell you that Unstable is fine.

      … while calling the 'head' builtin

         at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/attrsets.nix:1575:11:

         1574|         || pred here (elemAt values 1) (head values) then
         1575|           head values
             |           ^
         1576|         else

       … while evaluating the attribute 'value'

         at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/modules.nix:809:9:

          808|     in warnDeprecation opt //
          809|       { value = builtins.addErrorContext "while evaluating the option `${showOption loc}':" value;
             |         ^
          810|         inherit (res.defsFinal') highestPrio;

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: Package ‘kompare-24.02.2’ in /nix/store/rjxjnql4ccch77050smhsavfayrjas8c-nixos/nixos/pkgs/kde/gear/kompare/default.nix:3 is marked as broken, refusing to evaluate.

       a) To temporarily allow broken packages, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_BROKEN=1

          Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                then pass `--impure` in order to allow use of environment variables.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowBroken = true; }
       in configuration.nix to override this.

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowBroken = true; }
       to ~/.config/nixpkgs/config.nix.

And this is after disabling a few other packages already, I just don’t care anymore on that device.

But maybe this is just “me”. Test it for yourself, maybe your impression is different. Obviously there are people happily using it.


They are totally different. Using Fedora Atomic wouldn’t help you at all with Nixos and vice-versa.

I would try some of them and see what you think. Fedora Atomic is pretty easy to get started with if you want to play around.

Nixos isn’t really something to quickly test. You need to dedicate some serious time to learning how it works or you won’t have a positive experience.

1 Like

I’ve only run NixOS in VMs, although a couple were with GPU-passthrough. Getting your first configuration.nix setup correctly is not for the faint of heart, that’s for sure. But once it’s done, and you actually have a working system, you feel like you really accomplished something. I felt the same way after getting my first Gentoo w/systemd system running.

As others have pointed out here, the documentation is just not up to par. After 2+ years, I still don’t know how to use - or even why to use - flakes. I really hope it works out in the long run, though - NixOS is my 2nd-favorite distro.

I remember trying it out for myself over a year ago. While I certainly enjoyed the declarative system configuration at first, I quickly started to run into issues just as many others have. Things I remember having trouble with were:

  1. Installing packages (Yes really). As others have mentioned the nixos documentation leaves much to be desired. I believe the default way that it shows you to install a package at the time. I don’t remember the exact command, but it was something along the lines of nixenv [some flags] [package] or something. The problem is that this completely defeats the whole declarative configuration thing. So here I am installing a bunch of packages the wrong way.

  2. Package availability (Again, yes really). While nix boasts the most packages of any linux repository including the AUR. Something that people often don’t mention is that the vast majority of those packages are essentially the entire python / perl / [some other language] ecosystems multiplied by different versions of those collection of packages. Think python 3.12 and all python 3.12 built packages and python 3.11 and all python 3.11 built packages and so on and so forth. This means that it is still very common to come across packages you may want to use that haven’t been packaged for nixos. Installing those packages are nowhere near as simple as any other distro or even making your own pkgbuild. This means that I ended up running into a lot more of the complexities of this unique system sooner rather than later.

  3. Building off point number two. Even if you know how to create you own nix package that conforms to their way of doing things. The fact that you have to do this is a time sinker if you are in a hurry.

  4. I don’t know if this is still true. As I said at the beginning of the post, it was over a year ago since I tried nixos. The community and documentation didn’t seem to have reached a consensus on flakes. I can’t tell you what a flake is, but I know it was supposed to solve a bunch of problems. However, it wasn’t recommended to be used in any official capacity. It certainly left me in a state of confusion.

  5. I have never personally benefited from the rolling back thing. Downgrading a package and restoring from my system backups that I make with borg has always done me just fine. I haven’t moved to btrfs snapshots for this same reason. They both solve a problem that for me has already been solved.

In conclusion, I didn’t benefit enough from NixOS’s uniqueness to justify learning it. The learning curve was too steep in some areas and lack of documentation combined with the community settling on experimental solutions while not officially documenting it proved to be too confusing for me.

Finally, a lot of linux knowledge is distro agnostic. I have personally made use of the Arch wiki, Gentoo wiki, Debian wiki and Fedora Magazine on other distros. You are giving up a lot when going with something like NixOS which is just so different from the rest of the linux distros and even other immutable distros. For some people the declarative configuration thing is worth far more than what they lose out on. If that isn’t something you are attracted to, I would recommend using a traditional linux distro combined with whatever tools you need to achieve similar results to whatever nixos provides.


2 questions

  • If I use BTRFS (snapshots) on Arch & use Nix package manger to roll back multiple versions, then is there any reason left to use NixOS?
    Preference for Arch or any other distro that follow FHS compliance because I’d like to learn & use FHS, especially as Nix documentations are bad/not uptodate.

  • Is there any reason not to prefer AppImage instead of Nix packages? Both takes space & I can use multiple version for AppImage. So the main question is which one takes more space? No other major differences?
    (Ignore the fact that Nix has highest number of packages vs less number of programs support AppImage)

One more question…From arch-wiki I discovered abut lix…is there any practical benefit of using lix?
I’m testing nix packages on EOS & android, so far the terminal based programs experience is quite good.