Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going immutable on macOS, using Nix-Darwin

carette.xyz

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Going immutable on macOS, using Nix-Darwin

#61

Post by jorvi »

copirate wrote: post #58
jorvi wrote: post #56

Earlier quoted context omitted.

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…

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.

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

Re: Going immutable on macOS, using Nix-Darwin

#62

Post by cmckn »

Are folks not using migration assistant when they get a new Mac? I’ve had the “same” macOS install for almost 20 years, across 6 or 7 machines, and it’s fine. I see the value of nix-darwin if you use multiple Macs and change them frequently, but that’s never been me.

Re: Going immutable on macOS, using Nix-Darwin

#63

Post by copirate »

jorvi wrote: post #61
copirate wrote: post #58

Earlier quoted context omitted.

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.

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…

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?

Re: Going immutable on macOS, using Nix-Darwin

#64

Post by ronef »

[Disclaimer: biased Flox/Nix person]

There's a lot of reasons to use Nix instead of or WITH Homebrew depending on your exact needs.

Where it’s paid off for me (and where I think it actually wins) is when the problem is recreating environments: multiple machines, teammates, CI, nasty native deps, CUDA stacks, etc. At that point you’re choosing where entropy lives: in invisible drift (brew/manual installs) or in a repo you can diff/rollback.

Also, you don’t always need to go full “immutable everything.” Really depends on your needs here. Hybrid tends to be another sane path. In certain situations this can get you 80% of the upside without having to rip it all out. So kinda the "good enough" which I've seen a lot of folks do.

We (Flox) actually worked on this with Kelsey Hightower a while back - https://bsky.app/profile/kelseyhightower.com/post/3ld2rsccls...

Re: Going immutable on macOS, using Nix-Darwin

#65

Post by conradev »

jorvi wrote: post #38
pedrozieg wrote: post #31

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…

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…

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.

Re: Going immutable on macOS, using Nix-Darwin

#66

Post by yjftsjthsd-h »

microtonal wrote: post #25
otikik wrote: post #8

I see this: > The consequence is me, spending a few hours debugging my environment instead of writing code. But then I also see this: > I’ve spent a lot of time recently moving my entire workflow into a declarative system using nix. I can see how this can be beneficial for someone who switches systems very often, reinstalls their OS from scratch very often, or just derives a lot of pleasure/peace of mind knowing that…

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 m…

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

Er, YMMV I guess? IMO if you're spending more than an hour fussing with it per 6 months, you're doing something weird

Re: Going immutable on macOS, using Nix-Darwin

#67

Post by bsimpson »

pedrozieg wrote: post #31

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…

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

Re: Going immutable on macOS, using Nix-Darwin

#69

Post by nothrabannosir »

fnordlord wrote: post #47
rgoulter wrote: post #29

Earlier quoted context omitted.

Right. Nix is a wonderful technology. But I would not argue it is practical if you can afford "just fix it when it breaks". A nix setup more/less requires you to pay all the cost up front. I appreciate putting in the effort now so that I don't have to later for stuff like declarative dev environments. It's really nice to not have to copy-and-paste installation instructions from a README. -- I did like the point: unti…

Yeah, I'm a Nix user and fan but I'm still going to be stuck fixing it when it breaks. The biggest thing that I have to remind myself is that reproducible != "just works." Once you get to what you want, you're set but until then and every change after, there's a chance you'll be in the weeds. At least from my usage, the fact that your configuration is all tied to whether the entirety of nixpkgs-unstable is working ca…

I have sworn off nixpkgs-unstable for basically anything but testing. I’m now on the 6 months stable release cadence and never going back. Much much better experience. Unstable really is unstable. And that’s great! But it’s not for me.

Re: Going immutable on macOS, using Nix-Darwin

#70

Post by Svoka »

sennalen wrote: post #68

Looking in from outside, people going immutable with Nix sure seem to struggle a lot more than people going immutable with disposable containers and Terraform/OpenTofu

How do you manage macOS desktop apps with those, I am confused. The article is about set up of a personal workspace.
Post reply on HN