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

21–30 of 80 posts

Re: Going immutable on macOS, using Nix-Darwin

#21

Post by qn9n »

zero0529 wrote: post #15

I did this for a while but MacOS updates broke Nix often enough that I usually would spent some time every week reinstalling it. I still use Nix for dev environments because it is great but Nix still breaks sometimes. I also really wanted to like the declarative homebrew configuration but it also often didn’t work as expected for some configurations and had a lot of leaky abstractions that straight up just broke some…

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

Re: Going immutable on macOS, using Nix-Darwin

#22

Post by yladiz »

trinix912 wrote: post #19
loveparade wrote: post #11

Earlier quoted context omitted.

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…

That's mostly solved with env managers for python/ruby/node/..., takes at most a few minutes to fully set up and learn, and doesn't get constantly broken by macOS updates. Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back and it still takes less time than converting everything to Nix.

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 of the “purist” mindset a lot of people in the community have, it’s hard to justify it.

Re: Going immutable on macOS, using Nix-Darwin

#23

Post by KingMob »

I tried nix-darwin for half a year, and ran into endless problems: poor docs, huge default disk usage, non-trivial to customize, etc. After 6 months, I eventually went back to a mix of Homebrew and mise, which does most of what I need for I still believe something like nix is the future of building software, I'm just not sure it'll be nix itself.

Re: Going immutable on macOS, using Nix-Darwin

#25

Post by microtonal »

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

Re: Going immutable on macOS, using Nix-Darwin

#26

Post by vages »

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…

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.

Re: Going immutable on macOS, using Nix-Darwin

#27

Post by microtonal »

pjmlp wrote: post #24

I see these kind of posts like using Gentoo, cool that some people are having fun, not for me, using computers the mid-80's I have better yaks to shave.

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.

Re: Going immutable on macOS, using Nix-Darwin

#28

Post by sandreas »

zero0529 wrote: post #15

I did this for a while but MacOS updates broke Nix often enough that I usually would spent some time every week reinstalling it. I still use Nix for dev environments because it is great but Nix still breaks sometimes. I also really wanted to like the declarative homebrew configuration but it also often didn’t work as expected for some configurations and had a lot of leaky abstractions that straight up just broke some…

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

  $HOME/bin
along with extending the $PATH. Works great for most of my tools (exa, zoxide, bat, jq, etc).

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

Re: Going immutable on macOS, using Nix-Darwin

#29

Post by rgoulter »

nothrabannosir wrote: post #16
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…

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

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: until you've felt what a comfortable design is, you cannot imagine it.

Post reply on HN