[avakand]

I tried using NixOS on a laptop for a month and switched back to Arch a couple of months ago. It was an interesting experience - I never used functional programming language before, but nix was pretty ok as a configuration language. It looks like funny version of JSON with functions.

Debugging it was a real pain though - I was trying to write (or copy from someone else config) a function to recursively import all modules from a folder and the error messages were hard to understand with stacktraces ending somewhere deep in standard library.

The other problem was with nixpkgs, i.e. I haven't found a clear list of packages that were going to be updated. Jetbrains IDEA was updating very slowly and when I wanted to pin a version of it simply overriding version variable in the overlay was not enough - there were also some other linked variables. Emacs package from custom overlay constantly tried to compile itself, requiring me to check build status on hydra build system.

In the end I decided that it's not really worth it. I don't have many systems and services to manage and for a raspberry pi and a vps multiple docker-compose.yaml files in git repo is enough. I think Henrik Lissner (author of Doom Emacs) wrote a really good piece about why someone should choose to use NixOS - https://github.com/hlissner/dotfiles#frequently-asked-questi...

[2pEXgD0fZ5cF]

Same here, tried NixOS for ~3 months, I tried to go all-in too, I spend time to really read the docs and work out an intricate configuration that leverages features like flakes and covers my system setup and dotfiles (got inspired by Lissners NixOS configuration) and was ready to handle multiple systems in preparation to roll it out to my 2nd and 3rd machine.

Ultimately there were warts that I was able to solve, but still annoyed me greatly and felt ugly and forced me to step outside the convience of my nixos config system (like wifi with iwd, btrfs + swap files) and at one point I was no longer able to `nixos-rebuild switch --upgrade`, the command kept failing even on versions of my config that I was able to confirm working, I spent some time trying to find the problem but eventually came to the conclusion that it might not be worth it in the long run.

In the end I went back to my previous distribution of choice. I still find the whole concept interesting and I will give Guix a try next.

Fixing NixOS problems that the community hasn't encountered or solved yet really fills me with a special kind of dread compared to regular distributions where finding a solution to a rare problem is usually just a mix of taking a look at upstream and writing a patch or adapting general solutions from other distributions.

[ris]

I honestly think that Nix is one of those things where "going all in" is one of the worst things you can do. Running a desktop system on NixOS is quite a tricky prospect for someone with no experience of Nix and you'll likely get frustrated with having to learn some potentially alien concepts to achieve simple things.

I tend to recommend people start in the shallow end, using Nix on a regular Linux distribution (or even macos) for a while. Use it to manage development environments and for ephemerally accessing tools as you need them.

For me, the place that NixOS itself really shines is on servers.

[mst]

Being able to spin up an entire network of qemu+kvm VMs easily to do proper integration testing of my system configs was a revelation.

[trexd]

I found that building my configuration on a virtual machine was the best way to go. This way I was not desperate to get things working and simply moved when I felt like all my essential programs were in place.

[amarshall]

> I haven't found a clear list of packages that were going to be updated.

The ideal here, IMO, is to use flakes and the nix-diff to compare the build before switching. E.g.

    nixos-rebuild --flake '.#myhost' build
    nix-diff /nix/var/nix/profiles/system result
    sudo nixos-rebuild --flake '.#myhost' switch

Could do the same without flakes after the fact by running nix-diff on different generations in /nix/var/nix/profiles (there may be a way before switch). It’s unfortunate that how to do the above is non-obvious.

[tazjin]

There's nothing there that needs flakes (an experimental feature which people should not enable without understanding the implications). You could build a system derivation and run a diff against /run/current-system on it.

For what it's worth, nix-diff has very verbose output (it literally diffs everything that is different in the inputs & outputs). A slightly nicer way to diff systems is nvd[0] (example output[1]) which only shows version changes and added/removed packages.

[0]: https://gitlab.com/khumba/nvd

[1]: https://deploys.tvl.fyi/diff/4xmyvkr9nw0cwkn5q38p0cfc58x3jdy...

[flurie]

Flakes are "experimental" in the sense that gmail was in "beta" for however many years. I feel like it's important to mention that you're attempting to rewrite nix[1] and explicitly ignoring flakes[2]. Many people using nix are coming to the conclusion that flakes make things much easier to use and understand, and they obviate the need for a lot of secondary tooling that has become standard. There's an easy way to gauge support for flakes: look at how many high-profile nix repos have an up-to-date flakes.nix file.

[1] https://tvl.fyi/blog/rewriting-nix

[2] https://lobste.rs/s/ypwgwp/tvix_we_are_rewriting_nix#c_zvtze...

[remexre]

> experimental

Haven't flakes been non-experimental since 2.4?

[nitsky]

No, using flakes still requires enabling the “experimental feature”. The difference in 2.4 is that you no longer need to use a prerelease version of Nix to have the experimental feature available.

[avakand]

I was using flakes, yes. I remember seeing nix-diff, but most of the time nixos-rebuild dry-build was enough. Sometimes dry build was failing with error, but switching or activating it ran without errors. Never figured out what was wrong :(

[chriswarbo]

> Jetbrains IDEA was updating very slowly and when I wanted to pin a version of it simply overriding version variable in the overlay was not enough - there were also some other linked variables. Emacs package from custom overlay constantly tried to compile itself, requiring me to check build status on hydra build system.

The way I solve this is to import multiple versions of Nixpkgs, since they're all self-contained.

For example, if I'm upgrading from Nixpkgs/NixOS 21.05 to 21.11, and I find that package 'foo' has broken, or been removed, I'll do this in an overlay:

    self: super: {
      foo = self.nixpkgs2105.foo;
    }

Where nixpkgs2105 is a pinned revision of the Nixpkgs repo, defined in another overlay. My current Nix config has pinned Nixpkgs versions going back to 2016. For example, here's a bunch of such overrides:

https://github.com/Warbo/nix-config/blob/master/overrides/fi...

At the moment I'm using niv to manage the pinned Nixpkgs versions (the 'repoXXXX' entries):

https://github.com/Warbo/nix-helpers/blob/master/nix/sources...

[epage]

Another problem I ran into is trying to figure out how each package wants me to define plugins. There are common examples for Python environments (Python packages are like plugins into Python) but when it came to other software, I was at a loss when digging into things, even after reading all of the general documentation.