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

31–40 of 80 posts

Re: Going immutable on macOS, using Nix-Darwin

#31

Post by pedrozieg »

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.

Re: Going immutable on macOS, using Nix-Darwin

#32

Post by pjmlp »

microtonal wrote: post #27
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…

Immutable systems have zero to do with Nix, a common source of inspiration maybe, that is all.

Re: Going immutable on macOS, using Nix-Darwin

#33

Post by zero0529 »

sandreas wrote: post #28
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

I’ll check it out thanks :)

Re: Going immutable on macOS, using Nix-Darwin

#34

Post by JulianWasTaken »

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/main/Brewfile and then locked by a lockfile: https://github.com/Julian/dotfiles/blob/main/Brewfile.lock.j... and installing is just `brew bundle install`. All native Homebrew functionality. In practice I have never had an issue with non-reproducible builds across my machines (partly because the tendency on macOS is to run the latest versions of things and stay up to date).

(But again I do find nix-darwin interesting to try for other reasons.)

Re: Going immutable on macOS, using Nix-Darwin

#35

Post by vegabook »

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.

But now you’re stuck with Python. Nix enables trivially simple dev environments that are completely heterogenous. This gives you a powerful form of freedom because it literally opens up the entire software universe to your dev environment in a confidence inspiring way. Not to mention things like parameterising anything you use reliably and setting up environment variables, shell scripts, database service whatever you want. Also integrates with tools such as UV really well. Yes, the language is terse and difficult but once you know it, it’s liberating, and makes you a better software developer in my opinion because you now have a high-end full workshop rather than a small toolbox.

Re: Going immutable on macOS, using Nix-Darwin

#36

Post by bryceneal »

I do this too. It's not for everyone. At this point it's easily been positive ROI for me, but that's after about two years now of maintaining my configs through multiple machines and MacOS upgrades.

I would recommend it only if this type of thing naturally interests you. I can't imagine powering through the initial learning curve if it felt like a frustrating chore.

That said, if having (most of) your machine defined declaratively in a git repository sounds exciting/useful/comfy, then I would encourage you to give it a try. You can start small by just configuring a few programs or options and see how you like it.

I wrote more about my experience here where I also link to my configs: https://bryce.is/writing/code/fully-nix-pilled

Re: Going immutable on macOS, using Nix-Darwin

#37

Post by Jhsto »

turtleyacht wrote: post #2

It would be nice to set up immutable config down to the granularity of a git commit, sharing it as a single file, and be able to reproduce that setup on anyone's machine. Instant onboarding and mirrored production (barring secrets).

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.

Re: Going immutable on macOS, using Nix-Darwin

#38

Post by jorvi »

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

Re: Going immutable on macOS, using Nix-Darwin

#39

Post by Jhsto »

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…

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

Re: Going immutable on macOS, using Nix-Darwin

#40

Post by rgoulter »

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.

> Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back...

I think the closest mainstream UX for "you can try out this program without having to install it" is running a Docker image.

:) I'd say Nix is second best at everything related to packages.

Post reply on HN