> 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.

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.

>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.

Very nice, I think I'll be moving my "must-have" homebrew packages to a Brewfile. FYI tho, Homebrew no longer supports Brewfile.lock.json (it was always just a log anyway, not a lockfile). https://github.com/Homebrew/homebrew-bundle/pull/1509

> the comparison here for flakes should be to Homebrew bundles.

The bundler integration for nix-darwin actually just bakes tightly-controlled Brewfiles. It’s still worthwhile though, since part of the “tightly-controlled” means better cleanup when you remove things.

Long-time (by now) Nix user here. It's even worse than a few hours of debugging. In my experience it requires continuous maintenance, options tend to be deprecated and moved around on a regular basis (at least in NixOS and home-manager), things like NeoVim break regularly as a result of friction between the immutable world and a lot of plugins expecting a mutable world, etc. I do install my Mac from scratch every 6 months or so (I like a clean system), but with a dotfiles repo and Homebrew, it takes me about an hour to set everything up again, which is far less time than maintaining a Nix-managed system.

For me Nix/NixOS is by far the most effective for deploying servers, development VMs, etc. I do this regularly, so it pays off - I have a familiar environment completely set up in minutes. Another place it pays off, even on macOS, is for development environments, especially if you have to pull in a lot of native dependencies (which can happen in mixed Python + C++ projects, mixed Rust + C/C++ projects, etc.).

Nix shines in all difficult cases, like setting up complex cross-compilation environments, building for old glibc versions, etc. You set it up once and then it's really easy for yourself and other project contributors to get the same build environment.

Like any tool, a good engineer knows when to apply it.

Nix is not worth it if all you want is configuring your home computer. The learning curve is steep and has a tall onboarding cliff.

The only way you get positive ROI from Nix is either you enjoy the journey, or you use it to do more than just managing a single computer: you manage a fleet, you build thin application container images, you bundle all your software, you have devshells, repeatable tests and deploys, etc. It's the same tool for all of them.

In the six years you are using your computer, do you ever expect to run into versioning issues and conflicts? Homebrew packages conflicting with local packages, something you compile give needs a different python/ruby/node/rust/whatever version that you have locally installed, you want to quickly try out a new package or upgrade without changing your system but have the option of rolling back safely, need to quickly install a database, want to try out a new shell and shell config but don't brick your system and have the option to roll back, etc. Nix gives you all of that and more for a one-time setup cost. Your argument is correct only if you expect to never change anything on your computer for the 6 years. But if I think about how often I have fought with homebrew or some kind of versioning/path/binary conflicts in the past then the investment in nix has paid off exponentially.

It's also about peace of mind like you said. Before nix I sometimes felt anxiety installing or upgrading certain things on my computer. "Will this upgrade break stuff?" - and often it did and I'd have to spend the next few hours debugging. With nix I don't worry about any of that anymore.

> I change computers once every 6 years or so, maybe more. To me this looks like exchanging a couple (hypothetical) hours of debugging 6 years in the future by tens of (guaranteed) hours trying to climb up the nix learning cliff.

yes, it sounds like it's not worth it for you -- you will have to spend a significant amount of time converting your system to do things "the nix way". you can try to do this incrementally, but it's a time sink, and really easy to get stuck bikeshedding instead of doing work.

for me, it feels like a near equal trade-off between debugging nix, or debugging some random env issues that pop up. i know nix, claude code "knows" nix, a lot of other people online know nix. random env issues are random, and yield worse results on google, and frankly are much more frustrating to the point i would rather spend more time with nix than deal with them. maybe a very weird view.

I have experienced a positive return on investment from using Nix Darwin and devenv.sh since getting a new Mac two years ago. Did not spend too much time learning neither.

Also with migration assistant on Mac you basically do not need this in anyway shape or form.

Try dra[1] and a simple shell script in your dotfiles that installs / updates everything in

  $HOME/bin

1: https://github.com/devmatteini/dra

I found the Brewfile and a little `setup.sh` to be more than sufficient for getting a new Mac setup.

With the caveat of it not being a portable single file, I find custom image-based Linuxes fill this gap perfectly.

There's of course Fedora Silverblue / Fedora Bootc with https://universal-blue.org/ and https://blue-build.org/ being good examples.

Recent developments have seen the creation of bootc images for non-Fedora distros too, and at this point I've seen quite a few cool arch-bootc custom images, completely customized to the author's desires. See: https://github.com/bootcrew/, https://github.com/tartaria-dev/tartaria

For me, this is the holy grail. Every time I switch laptops, I lift all my config files and such over, but there's always so many system level configs and other things that you have to go and manually fiddle. On top of that, some apps don't really behave well when you just move config files to e.g. under a different username etc. Would be nice if there was a comprehensive solution to this problem, need to try nix-darwin out.

Speaking from the viewpoint of a whole operating system images, the main challenge is that while Nix allows you to create ephemeral environments, many people (myself included) have various hard-coded paths for mounting hard drives. If you want something to be shareable, you have to create a workflow in which the user environment is activated interactively after a tty session is acquired. Same goes for any system services that need persistence -- these have to be configured to be activated at runtime. It's a lot of work for a party-trick. It's probably possible to configure the system such that the log-in needs a FIDO2 key which is also used for LUKS drives, which would be similar to how macOS handles log-ins. But abstracting this such the login works on every machine possible suddenly requires filesystems to be networked, and so on.

That being said, we used NixOS images to boot several Windows PCs of my friends into RAM to play Halo 3 multiplayer split-screen. Most of my friends were mainly confused why they could play with any gamepad they had in their shelf. They also left the event with no permanent changes to their PCs.

I haven't used Nix yet, but I have done exactly this a number of times with Guix now. I assume Nix has the same capabilities. In Guix you can specify a home configuration that includes packages, configuration files, and running services all in one manifest.scm file. If you want to make sure that it's isolated from whatever else is set up on the system you can launch that manifest in a container with a single extra flag

this is basically the purpose of nix flakes, which take in inputs (usually git repositories) and provide outputs (compiled files, docker images, etc). it's a pain to get going, but not tremendously difficult with some googling. It's a lot easier with AI as well.

Installed nix-darwin on 26.0, on a fresh M4 air. I have updated since updated macos to 26.2 through the normal method, no wacky nix stuff there. no issues. no clue on major version changes, but nix-darwin is essentially the nix config language parsed to then run the necessary set of scripts.

I installed on macos14? Maybe 13? And have had minimal trouble since.

Comparable to the amount of breakage I regularly had with homebrew.

I am critical as with any technology (see my comment about Nix in another thread here), but Nix is profoundly not using computers the mid-80's way. It is more future technology, where a system is immutable, fully declaratively defined, has atomic updates/rollback, etc. It's the direction things are going, see e.g. macOS sealed system volumes, Fedora Silverblue, etc. It's just that it still has a very large number of sharp edges, not so great documentation, lack of static typing, etc.

Nix may not be the tech that replaces everything, but at the very least it is and has been an important exploration vehicle for declarative configuration, immutable systems, etc.