I have been using NixOS for close to two months now. I was originally drawn by the modularity/configurability, large and up to date package repo,...
This is an automated archive made by the Lemmit Bot.

The original was posted on /r/nixos by /u/Mindless_Insect3743 on 2025-10-27 13:03:09+00:00.

I have been using NixOS for close to two months now. I was originally drawn by the modularity/configurability, large and up to date package repo, reproducibility and atomic updates to make sure your system is never unusable. Throughout this time I have spent countless hours working through the learning curve, with the Nix language, NixOS options & commands, flakes, etc. But I have run into too many issues, and I will not be using NixOS any more. Here is a very long review and retrospective, which will hopefully be of help to other NixOS beginners, or people (in particular developers) interested in trying the distro to evaluate whether it is really for them.

TL;DR: setting up development environments is a pain in the ass, especially with niche or vendor-specific tooling.

The Good

  • The package repository: nixpkgs is amazing, lots of non-FOSS apps that are not in other native package repositories (which I would either have to download a .deb or .rpm or AppImage, or get from FlatHub or Snaps) are literally just in nixpkgs. Spotify, Discord, Obsidian … Even Davinci Resolve (both free and studio) are in the repo, and I don’t need to go through DavinciBox (a distrobox project for Davinci Resolve).
  • System settings all configured in one place, at a glance: I can have a comprehensive list of all the software I’ve installed, my bootloader settings, my GPU drivers, extra fonts, desktop environment, etc, all in the same file or directory, at a glance. That’s pretty neat. If I want to try out a different desktop environment, that’s a few lines of configuration which I can easily roll back, and I don’t have to worry about leaving the system state unclean (other than user level configuration).
  • Reproducability: It’s nice knowing that whatever changes I’ve learned to configure on my desktop, I can easily copy over to my laptop. Or if my computer dies, I can get my old working environment back relatively quickly. This one is more of a peace of mind thing, but practically I found that it wasn’t as useful as I imagined - my desktop and laptop kinda need some different configurations, and my computer hasn’t died during my period using NixOS (touch wood).
  • Atomic updates: Also nice to know that my computer won’t be left bricked in an unusable state. But I think this one is practically not as important as one might imagine as well - you can use other distros and have a stable, reliable experience too.

The Bad

  • The wiki: NixOS seems to be notorious for having a poor wiki. This problem is excacerbated by the fact that many things on NixOS do, in fact, require referring to the wiki. In addition, there are multiple different wikis, and when I go to search for something, often there will be a nixos.wiki page ranking high in the search results (which is the old, unofficial wiki), and the wiki.nixos.org page nowhere to be found, only showing up when i specifically go to the home page and then search for the issue.
  • Non FHS compliance: in order to achieve its great reproducibility and atomic rollback features, NixOS does not follow the Filesystem Hierarchy Standard (FHS), making software that would usually run on other distros, have trouble running on NixOS. I first learned about this when I realised that trying to install Anaconda/Miniconda/Miniforge with the provided install scripts, or even using Mamba from nixpkgs doesn’t work. Ok, I guess I’ll just use conda from nixpkgs, go into a conda-shell subshell every time, and I have to manually go change the repository from anaconda to conda-forge, but at least that’ll work. Then I realise my Jupyter plugin in VS Code doesn’t work. Ok, I read about this, I’ll switch from vscode to vscode-fhs - it still doesn’t work for some reason? Ok well I don’t have time to figure out the syntax for the nix declarative vscode-with-extensions, I guess I’ll just install VS Code in an Ubuntu Distrobox. But then, more and more I just keep running into issues with trying to set up dev tools on NixOS, especially the more vendor-specific ones.

This is the long part of the post, detailing all my troubles with getting certain pieces of software to work for development. If this does not interest you, skip to the conclusion at the bottom

So NixOS is quite nice for keeping my general purpose desktop applications and environment configured, but I also have to do some coding and software devopment. I thought that for software development and coding, it’d be a good idea to stick to what is most well supported, which is something like Ubuntu. So I turned to Distrobox, Docker/Podman and containerised development, with the idea to get the best of both worlds - NixOS for desktop configuration, Ubuntu container for fast, frictionless development.

The elephant in the room: I refuse to use flakes to set up my dev environments - yes, flakes where you have to search <insert dev tool> nixos reddit, and then find a Reddit post linking to a GitHub repo with 100-200 stars, with a 40 line flake file and possibly extra documentation (case in point, the ESP-IDF flake). Not only would my workflows rely on stuff maintained by volunteers on GitHub (or, god forbid, I have to “just write and maintain your own flake, bro” like people say online), but also, it’s just extra hoops to jump through, extra time, energy and mental overhead, and possibly, extra troubleshooting - on top of the existing burden of having to read through and learn the vendor’s documentation already. The reproducibility sounds good in theory, and I acknowledge that it’s an awesome feature if you’re part of a team that’s fully onboard with Nix, but realistically, if you sampled 100 software engineers or data scientists out in the wild, how many use Docker, vs how many use Nix? How many use Conda/uv, vs how many use Nix?

So the first slight challenge was to get ESP-IDF working, for coding up ESP32 microcontrollers. As a sanity test, I tried installing it according to the vendor instructions natively on NixOS, to make sure that yep, sure enough, it doesn’t work. So I try installing it in the Ubuntu distrobox. There was an issue where I had to sudo apt install udev for the ESP-IDF VSCode extension in the container to detect the right serial port (which took me about an hour to figure out), but other than that it worked fine. But then I was trying to get STM32 working, a different microcontroller. STM32CubeMX is in nixpkgs, but not STM32CubeIDE, STM32CubeProgrammer, or any of the others. I needed those vendor specific tools to collaborate with my university engineering team, so I installed in the container. Once again, I am not using the janky looking flake I found off a google search maintained by one anonymous volunteer - this one looks even less well-supported than the ESP-IDF one. Thing is, after installing in the container, I couldn’t figure out how to detect the ST-Link (this time it’s not a simple serial port, it’s a SWD or JTAG debugger, so it might be a bit more involved). From some research, it seems like I neede to fiddle with some udev rules for the container or something, but that’s something I haven’t gotten around to figuring out to this day.

I was working on another university group project with a Qt GUI, and I couldn’t get it to work in the ubuntu distrobox no matter what. It kept saying it was missing some libxcb dependency even though I’ve installed it. I was telling everyone “guys our Qt GUI doesn’t work on Linux, we gotta fix this”… until I decided to try running it on my other computer with Ubuntu, and lo and behold, it worked on the first try. For this project we also needed to integrate some bioinformatics genetics tool where you need to compile the source code from a github repo. We decided to compile one version for Mac, and one version for Linux/WSL, so our group can use it easily. But then the Linux compiled version wasn’t working on our other WSL setups. After like half an hour of fiddling, I found that it’s because I compiled it on NixOS, and it was pointing to some linker in /nix/store/ instead of the usual /lib64/ld-linux-x86-64.so.2, and had to recompile it.

Then at some point I wanted to try out NVIDIA Isaac Lab. The native installation method was obviously not going to work on NixOS, so I tried it in the ubuntu distrobox, and even though I had made the container with the --nvidia flag, my GPU was just not passing through for some reason - I search it up, and there’s a reddit comment somewhere saying it’s a NixOS specific problem with distrobox. Ok, luckily NVIDIA do provide a Docker container to try out Isaac Lab. I spent another bit of time figuring out what’s the current way to enable the NVIDIA container toolkit on NixOS, since the API seems to change every few years (had to read through a reddit comment and a lengthy GitHub issue to find the right option), and then spent like half an hour building their docker image. Surely this will work, right? I go to launch the docker container, and get:

Error response from daemon: could not select device driver "nvidia" with capabilities: [[gpu]]

Now keep in mind, it’s not like NVIDIA just provide some simple docker commands that I could easily troubleshoot. In true vendor-specific fasion, it’s a 100+ line python helper script that then spawns the container depend…

Content cut off. Read original on https://old.reddit.com/r/NixOS/comments/1ohdtln/a_use_case_where_nixos_is_more_trouble_than_worth/