What we should be talking about is how to get rid Apple ecosystem all together.
You can just not use it at all, there are alternatives.
Why do you want to get rid of something which you are not forced to use?
Going immutable on macOS, using Nix-Darwin
71–80 of 80 posts
Re: Going immutable on macOS, using Nix-Darwin
#72I 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…
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…
> 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.
Couldn't pretty much all of that be addressed using containers? Keeping your base system clean does sound wonderful, but eg distrobox containers sound more approachable - you're using all the same commands that you normally would, apps are in an environment much closer to what they probably expect. You can still roll back using snapshots, which you can configure to be automatically created on system updates. If you want an atomic rollback guarantee, and a strong reminder not to mess with the base system, you can use an immutable distro (talking about Linux, not macOS here). The one big advantage that I see from nix is reproducibility. But it's not clear how desirable that is for a desktop use case. You may actually want different software on different machines. Having an overview of all the changes you made to your system sounds cool, but I'm not sure it's worth the effort that comes with nix. I'm worried that after 8 months I'll decide it's too much hassle, like many commenters seem to do, and end up switching to a simpler system with dotfiles and containers, wishing I'd done that from the start.
Re: Going immutable on macOS, using Nix-Darwin
#73It 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).
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 cus…
I thought bootc had an open issue preventing it from working with Arch (or anything other than Fedora). Having working VMs is way further along than I expected anyone to be, this is really cool.
Re: Going immutable on macOS, using Nix-Darwin
#74Don't think of nix-darwin as an alternative to homebrew. Por que no los dos? You can run homebrew (declaratively!) via nix-darwin, and I think they complement each other quite well.
I stick to nixpkgs for most of the foundational system tools, lsps, build tools - basically anything that works in the terminal and is fully open source. For everything else (zoom, slack, vscode, firefox, etc) I use homebrew packages. The combo gives you options and is a strict superset of what you can do with homebrew or nixpkgs alone. Best of both worlds really.
The article I used to help set up, in case this helps anyone: https://davi.sh/blog/2024/01/nix-darwin/
Re: Going immutable on macOS, using Nix-Darwin
#75Are 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.
Right, these commercial operating systems are designed with a different philosophy that arguably has its own merit.
I’m enjoying a Fedora atomic distribution for the eliminating the Linux upgrading issues of the past. But macOS and Windows never really had that problem.
Re: Going immutable on macOS, using Nix-Darwin
#76Earlier quoted context omitted.
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 so…
> 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
Although you're right about nix's DX being quite rough, the problem isn't exactly that it "tries to be everything for package management".
Consider the assumption Nix wants to make about its packages: it should be possible to package software by putting it in some arbitrary directory (i.e. not just /usr/bin), where its dependencies are also put in (or symlinked to) some arbitrary location.
I think with well-written software, this should be a reasonable assumption, but you're going to run into friction with that. (Friction which will require you to have a good breadth/depth of understanding).
In my experience, a lot of the complexity when dealing with Nix is with the large and organic complexity of nixpkgs.
The "trying to be everything" is more incidental to the expressive package management. -- NixOS is 'just' an OS built upon the package manager; dev shells are 'just' shells which expose the build environment of a package; etc.
Re: Going immutable on macOS, using Nix-Darwin
#77Earlier quoted context omitted.
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?
Actually Nix even errors out if the file it tries to write is already in place. I have this sometimes when I move fish functions from being defined adhoc with funcsave to putting them in my nix config because I want them on all my machines.
Re: Going immutable on macOS, using Nix-Darwin
#78Earlier 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…
It's really easy to pull those handful of packages from an older version of nixpkgs. I had to do that when there was some buggy firmware in the latest (at the time) version of linux-firmware. You just:
1. Add a new input to your flake of nixpkgs pinned to a specific commit or branch. For example:
nixpkgs-91fab2d.url = "github:NixOS/nixpkgs/91fab2d3e8ee06464f3c9896e84c97982b771fc3";
(final: prev: {
inherit (pkgs-91fab2d) firefox libreoffice;
})Re: Going immutable on macOS, using Nix-Darwin
#79When I was forced to use a Mac at work I found that Nix was also just a better (mostly faster) package manager than brew. Even if you're not on the immutable bandwagon it's very worthwhile.
As a bonus I was able to achieve some semblance of uniformity across Mac and my Linux desktop with home-manager.
Re: Going immutable on macOS, using Nix-Darwin
#80Earlier quoted context omitted.
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…
It's really easy to pull those handful of packages from an older version of nixpkgs. I had to do that when there was some buggy firmware in the latest (at the time) version of linux-firmware. You just: 1. Add a new input to your flake of nixpkgs pinned to a specific commit or branch. For example: nixpkgs-91fab2d.url = "github:NixOS/nixpkgs/91fab2d3e8ee06464f3c9896e84c97982b771fc3"; 2. Add an overlay where you replace…
Thanks! I will write this down so I can try it out next time.
I really want to get better at these little things but it can be tough sometimes without concrete examples like this.