|
|
|
|
|
|
by colehasson
3456 days ago
|
|
|
NixOS has my vote. On the first ~CON:
If the "end user" is a developer that is new to nix and nix expressions, the transparency of nixpkgs and its nix expressions may turn tweaking from a problem into an opportunity. Seeing the details of builds, configs, and installs clearly laid out in a nix expression taught me more about the package that I was blindly depending on. Having the same tools (nix, nix-repl, nix-shell, *.nix) available across projects and vertically within developments has reduced the "special knowledge" that "end users" need to know for both development and operations. Extra PRO:
Have the expression for your configuration just perfect? Need to build on multiple VMs, machines, EC2? Simply add an expression for networking and deploy with Nixops https://nixos.org/nixops/. Now logical and physical configuration is a declarative data file. If a build fails, I check the source. If my cloud fails, I check the source. For me, the reproducibility and variable independence in NixOS puts the SCIENCE in Computer Science. |
|
|
+1. Dependency management and deployment is the biggest problem Nix solves and it is the only system that actually does so instead of putting the problem somewhere else and presenting that as a "solution." A lot of people are using Docker for this scenario, which gives the illusion of a solution for new projects because you have convenient pre-built images. The images do not come from thin air, and people will run into exactly the same problems as they did with VM images once their Docker projects age and dependencies will need to be updated. Adding virtualization layers cannot solve the problem of updating software dependencies.
The only solution is a package manager that tracks the complete dependency tree, all the linked libraries down to libc, and prevents different versions of packages from interfering with each other. Nix is the only package manager that does this.