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

51–60 of 80 posts

Re: Going immutable on macOS, using Nix-Darwin

#51

Post by karlshea »

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…

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.

Re: Going immutable on macOS, using Nix-Darwin

#52

Post by 16 »

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…

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

Re: Going immutable on macOS, using Nix-Darwin

#53

Post by 16 »

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…

It sounds like you're on unstable? Things are significantly more stable if you stick to the release branches (25.05, 25.11 etc)

Re: Going immutable on macOS, using Nix-Darwin

#54

Post by yladiz »

rgoulter wrote: post #41
yladiz wrote: post #22

Earlier quoted context omitted.

This is my feeling too. Nix is a relatively high time investment for a tool that tries to do everything, when you might not need or want everything and using the specific language’s tooling is more than sufficient and quicker. It takes a few minutes to install and do `uv sync`, or `nvm install`, or whatever, on a repository on a new computer, and it just works. Until Nix gets there, and I’m skeptical it will because…

I think the comparison is "X-as-code", like with Terraform and other tools. If you just want a throwaway VM, it's straightforward to create one through the UI cloud console. Whereas, terraform is nevertheless still a useful tool to use to manage VMs. For stuff like installing development dependencies.. it's maybe not difficult to copy-and-paste instructions from a readme, but solutions like devcontainers or Nix's dev…

Of course. I wouldn’t say that Nix is a tool without much use or merit, because setting up development environments can be a huge pain and I understand why some people would use it and prefer it.

My biggest complaint is what I mentioned above: it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to - I might have to debug Nix instead of Node, which is not always straightforward. In my limited experience Nix got in my way more than I’d like, and in ways I didn’t expect or want to deal with, and until it’s as seamless as something like Homebrew or apt, it’ll be a hard sell.

Re: Going immutable on macOS, using Nix-Darwin

#55

Post by JulianWasTaken »

chuckadams wrote: post #49
JulianWasTaken wrote: post #34

I've tried nix-darwin a time or two in the past. Every few years when homebrew makes a "hostile" change and I get upset I consider trying it again (now most recently with changes to gatekeeper). I think I'll get to doing so in the next year or so. But I think just in fairness, the comparison here for flakes should be to Homebrew bundles. My packages are managed in a bundle: https://github.com/Julian/dotfiles/blob/mai…

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

Fun, thanks for letting me know, will remove it :)

(I'll still stick with "I never really have run into a version issue for things I use Homebrew for, for places where it matters, I have whatever-programming-language-lockfile-for-the-project-I-am-developing" for cases where I need to be sure the setup is reproducible, which is why I've clearly never noticed this file was useless).

Re: Going immutable on macOS, using Nix-Darwin

#56

Post by jorvi »

16 wrote: post #52
jorvi wrote: post #38

Earlier quoted context omitted.

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…

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

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.

Re: Going immutable on macOS, using Nix-Darwin

#57

Post by jorvi »

karlshea wrote: post #51
jorvi wrote: post #38

Earlier quoted context omitted.

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…

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.

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.

Re: Going immutable on macOS, using Nix-Darwin

#58

Post by copirate »

jorvi wrote: post #56
16 wrote: post #52

Earlier quoted context omitted.

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

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.

Re: Going immutable on macOS, using Nix-Darwin

#60

Post by n8henrie »

After a decade of homebrew, a few years ago I got tired of their very grumpy maintainers and switched to nix-darwin + home-manager. I've been overall fairly happy, and for tinkerers would recommend giving it a shot. Admittedly I bounced off my first try a year before that.

A few of my favorite parts, which I see less represented in this thread so far:

- I simultaneously jumped into nixos on several Linux machines (starting with a few Pis for experimentation), and maintaining all of my systems with a single flake and mostly shared code is a dream come true. - no more convoluted dotfile syncing, most of my scripts and aliases and bash config and binaries all sync together - cross-building linux from Darwin -- including integration tests in a vm -- works surprisingly well, this is mostly just nix but nix-darwin has helpers that make this easier - writing system services (launchd) on my Mac then converting them to a headless Linux machine (systemd) is generally very straightforward - prefixing my path with GNU coreutils works well and saves me from many e.g. `sed` quirks, I get expected behavior across OSes - this was always a sore spot in homebrew, either dealing with the `g` prefix on everything (eg `gsed`) or dealing with intermittent breakages when stuff depends on the BSD behavior - I was also able to put nix-darwin on my wife's MacBook and greatly simplify admin / maintenance tasks I do for her - finally, the nix crew is just thirsty for help and contributions, particularly the darwin crowd; I feel like my (minor, occasional) contributions are celebrated, differences of opinion are met with an open mind, it is in general a far departure from the relative hostility of homebrew - on the down side, I have spent far more of my limited time helping contribute to nixpkgs / nix-darwin / home-manager

Post reply on HN