A useful way to frame this isn’t “is it worth tens of hours to avoid a future reinstall” but “where do I want my entropy to live”. You’re going to invest time somewhere: either in a slowly-accumulating pile of invisible state (brew, manual configs, random installers) or in a config that you can diff, review and roll back. The former feels free until you hit some cursed PATH/SSL/toolchain issue at 11pm and realize you’ve been paying that tax all along, just in tiny, forgotten increments.

I think where Nix shines isn’t “one laptop every 6 years” but when your environment needs to be shared or recreated: multiple machines, a team, or a project with nasty native deps. At that point, nix-darwin + dev shells becomes infrastructure, not a hobby. You don’t have to go all-in on “my whole Mac is Nix” either: keep GUI apps and casual tools imperative, and treat Nix as the source of truth for the stuff that actually blocks you from doing work. That hybrid model matches what the article hints at and tends to give you most of the upside without turning your personal laptop into a second job.

▲

bsimpson 2 hours ago | parent | next [-]

> keep GUI apps and casual tools imperative, and treat Nix as the source of truth for the stuff that actually blocks you from doing work

I landed somewhere similar for gaming.

When I first got my Legion Go, there were a whole bunch of gaming distros, but none was more popular than the other. I read a bit about immutability, got curious, and installed Jovian-NixOS (which is to NixOS what Bazzite is to Fedora).

I liked that it gave me the Steam Deck experience on unofficial hardware, and it was neat to be able to play with e.g. replacing the desktop shell. However, a keyboard-centric configuration scheme is a bad pairing for a touch-centric device. Little things, like changing the timezone, became needlessly frictionful.

Now I'm on the official SteamOS, with Nix as the package manager. It seems to be a good pairing. Nix lets me install Linux utilities on Steam's otherwise-immutable filesystem. And I can use the Steam UI to change things like the time.

I'll probably write an article in the next few weeks on using Nix to make Linux-native copies of Windows-built games.

▲

jorvi 9 hours ago | parent | prev | next [-]

One of the biggest annoyances I have with doing this with Nix vs another tool is that Nix doesn't natively communicate back state changes so that you can make them reproducible.

If I make a git repo, place '~/.config/newsapp.conf' in there and then symlink it back to '~/.config/', if NewsApp introduces a new variable in its settings I am immediately aware because Git will complain about being dirty. However, Nix will happily just nuke that .conf and rebuild whatever is in your configuration, without letting you know about state. Which is ultimately bad for reproducibility. It's a huge blind spot in Nix.

▲

conradev 2 hours ago | parent | next [-]

This really hinges on whether you let state accumulate, and where you let it do so. NixOS generally creates a dedicated user and data directory for its services, for example. I make some of my XDG config directories symlinks to the nix store because I want those configurations to be read-only. home-manager should ask before making modifications outside of the nix store (or make a backup).

This is not only a Nix problem, fwiw. I first encountered this with, say, running ZNC in Docker. It will happily write logs and configs to a temporary directory in the container and get blown away on restart unless you mount persistent volumes in just the right spots. Syncthing can be configured to manage its own config or it can be configured fully by Nix, etc.

▲

karlshea 8 hours ago | parent | prev | next [-]

I tried getting Nix working a couple of months ago and ditched it because changing some Tower settings updates the global gitconfig (as it should in this circumstance) and Nix would wipe them out.

All of it seemed way too annoying compared to just having a dotfiles repo, and if it couldn’t handle the Tower/gitconfig issue I know for sure everything else I was going to run into wasn’t worth it.

	▲	jorvi 7 hours ago \| parent [-]
		For what it's worth, you can put a git repo inside a nix configuration / flake folder and it will tell you the repo is dirty. 'nh' also has commands to tell you about state. But it shouldn't require outside tools. The way I do it is have config files in my Nix config folder, then use Nix to symlink them and I use git to make me aware of state changes, that I might want to make reproducible. But that's just me being used to my old git ways, using 'nh' gives much more clarity. The "true" Nix way is putting the entire contents of whatever config file in a .nix file, then erasing the original config and have Nix recreate the config (preferably read-only) in place. You become truly reproducible but for obvious reasons applications get mad when you make their config file read only.

▲

16 8 hours ago | parent | prev [-]

It sounds like you're talking about home-manager, which is a third-party Nix module, not Nix itself. I've been using Nix happily for several years now for work and personal without needing to use home-manager at all (since I don't like it either).

▲

jorvi 7 hours ago | parent [-]

It was just an example. Other packages could also set new variables / parameters in their configuration. It might not be a problem in the beginning if the variable is just repopulated, but it might blow up in your face in the future.

If you use Nix you're completely blind to that unless you A) religiously check your state or B) use another tool like 'git' or 'nh'. Like I said, it's a blind spot, both figuratively and literally.

▲

copirate 6 hours ago | parent [-]

This problem may be specific to Darwin because on NixOS I've never had a file overwritten by nix (even with home manager). When a file is managed by nix it's a symlink to a read-only filesystem (/nix/store), so no program can overwrite it. If the symlink is replaced by a regular file, nix refuses to reapply.

▲

jorvi 5 hours ago | parent [-]

Correct for data, not for config files. Config files are stateful unless you do the procedure I mentioned, because they're generated at first application launch.

If you try to symlink into an existing file Nix will indeed complain, which is why you have to erase the config file and then put yours in place. You can either write it out from a .nix file (pure reproducibility) or from symlink copy from a file managed by git (technically impure but effectively reproducible).

	▲	copirate 5 hours ago \| parent [-]
		But my config files (/etc, ~/.config, etc.) are either managed by nix (and no program can modify them), or they are not and in that case nix will never touch them. In what situation would nix overwrite a file?

▲

Jhsto 9 hours ago | parent | prev [-]

>I think where Nix shines isn’t “one laptop every 6 years” but when your environment needs to be shared or recreated: multiple machines, a team, or a project with nasty native deps.

I'd like to add the third thing, which is just iteration. It's very tricky to maintain advanced workflows even locally. I'd guess many won't even try to compose things that could work in combination (often self-hosted services), when they know they can't reliably maintain those environments.