Hacker News new | past | comments | ask | show | jobs | submit login

I love Nix concepts and all it's subprojects (NixOS, NixOps, Hydra, Disnix).

However, i've found NixPkgs to be a bit messy. It's too big, targets too many platforms and it's too disorganised. But to be completely fair, I think it's getting a lot of good refactorings lately.




Yeah it's basically just growing pains.

For large enterprise use, Nix is going to need to mature to a point where it's possible for enterprises to host a Nixpkgs cache locally, using a binary repository manager like Artifactory or Nexus, both for sheer cost (to save on bandwidth of thousands of servers downloading updates from the Internet) as well as risk reduction (in case the public binary caches are unavailable at critical moments). If this is doable today, it's not really documented.

I'm sure the project will get there... eventually.


You can install nix-serve on any machine to share its binary cache (including patched applications). Then add all of the enabled machines to every machine's nix.binaryCaches in order of preference. If they don't have what you need, it will fall back to the upstream server. You'll want to make sure they are upgraded in an appropriate order to minimize the need to leave your network for updates. It's true this isn't well documented, but I figured it out in about a day and was surprised at how simple it turned out to be.

You can even go further and set up your own build server to service all the architectures you need to support.


I found Guix a lot more organised. Most package code is very simple, and the toolchain is also quite elegant. Hopefully the latter will be addressed by the new nix interface.


Is GuixSD really usable in production? Its focus on using a Linux-libre kernel instead of mainline is worrisome regarding real-world hardware support.


Switching to mainline is almost trivial, just override plain linux-libre kernel and redefine the source.

GuixSD is getting production-ready IMHO. See for example Guix getting adopted by some HPCs:

https://guix-hpc.bordeaux.inria.fr/


That is already very easy:

https://github.com/nh2/nix-binary-cache-proxy

Allows you to set up (using NixOps!) a caching proxy for the nixos binary cache in your local network.

It can also serve your own custom packages if you sign it with your own package signing key and tell your machines to trust it.


Setting up your own binary cache is straightforward: https://nixos.org/nix/manual/#sec-sharing-packages

Is using Artifactory or Nexus a requirement? Why?


Mainly concerns like access control, and auditing for internal projects. If we're going to package for Nix, we need to host those packages internally somewhere, and access to that host needs to be audited/monitored. Access should be limited to developers and forbidden to non-engineering staff, etc.


Nix package definitions sit in a Git (or other VCS) repo, which you can access-control through your usual means.

The binary artifacts are behind an HTTP server, which you can access control through whatever normal access control mechanisms, or leave uncontrolled and rely on the fact that it's not possible to retrieve artifacts from the server without having access to all the build inputs so you can hash them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: