nix-darwin VS nixpkgs

Just a shout out to nix-darwin[1]. It is nix, so initial setup is a bit involved. But then it truly makes it easy to configure everything in one place including mac defaults, homebrew apps declaratively and mas apps etc.

There is a sample config in nix-darwin repo[2].

[1] https://github.com/LnL7/nix-darwin

[2] https://github.com/LnL7/nix-darwin/blob/master/modules/examp...

https://github.com/LnL7/nix-darwin/tree/master/modules

nix-darwin does similar thing for MacOS

You can use https://github.com/LnL7/nix-darwin

There are many threads around where you can learn more about this (and why it's complicated...), but https://github.com/nix-community/home-manager/issues/1341 and https://github.com/LnL7/nix-darwin/issues/139 seem like two of the most comprehensive.

Nix is pretty usable for both desktops and headless servers. Personally, I even use it on macOS without much trouble.

My system looks like any other install of Ventura, but all of my configuration, ranging from the terminal and VS Code to macOS-specific system preferences and Safari, is done declaratively in Nix [1]. The overwhelming majority of my installed software also comes from Nix packages, with some exceptions for stuff that is not packaged yet (e.g., I have Podman Desktop, the macOS ZFS port, Lulu, yubikey-manager-qt installed through Homebrew -- fortunately nix-darwin [2] also just lets me have an set of brews/casks in my config).

It was been a bit of a nightmare at first since the error messages are kind of horrific, and there can be a lack of good examples/docs on flakes. But I think the weekend worth of time I invested was worth it since I no longer need to rely on hacky shellscripts or remember to manually configure anything.

[1]: <https://github.com/nix-community/home-manager>

[2]: <https://github.com/LnL7/nix-darwin>

Take a look at nix-darwin, this is what I use. It allows you to configure your system similar to NixOS including globally installed programs.

This — I still use mas and brew —-cask through the nix-darwin module, though. It’s not exactly reproducible, but it’s at least closer to reproducible and declarative.

https://github.com/NixOS/nixpkgs/commits?author=neon-sunset

I see two signers in the top 6 displayed on https://github.com/NixOS/nixpkgs/graphs/contributors

For a single file script, nix can make the package management quite easy: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-f...

For example,

```

Yes, Nix doesn't actually ensure that the builds are deterministic. In fact it works just fine if they aren't. There are packages in nixpkgs that aren't reproducible: https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aiss...

I'm not familiar with Bazel, but Nix in it's current form wouldn't have solved this attack. First of all, the standard mkDerivation function calls the same configure; make; make install process that made this attack possible. Nixpkgs regularly pulls in external resources (fetchUrl and friends) that are equally vulnerable to a poisoned release tarball. Checkout the comment on the current xz entry in nixpkgs https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/comp...

NixOS uses a monorepo and I think everyone's love it.

I love being able to easily grep through all the packages source code and there's regularly PRs that harmonizes conventions across many packages.

Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing.

https://github.com/NixOS/nixpkgs

In this specific case, nix uses fetchFromGitHub to download the source archive, which are generated by GitHub for the specified revision[1]. Arch seems to just download the tarball from the releases page[2].

[1]: https://github.com/NixOS/nixpkgs/blob/3c2fdd0a4e6396fc310a6e...

[2]: https://gitlab.archlinux.org/archlinux/packaging/packages/ib...

True, but irrelevant -- _some packages_, _somewhere_, do depend on xz, which, if built, requires pulling the source from GitHub (see the default.nix: https://github.com/NixOS/nixpkgs/blob/nixos-23.11/pkgs/tools...)

It's not the vulnerability that's a problem right now (NixOS was protected by a couple of factors) but rather GitHub's hamfisted response.

That is the problem.