Actually, Guix and Nix aren't just package managers, they also provide a fully system configuration management tool complete with the ability to roll-back to earlier versions of the system. You don't need Ansible or Docker when you use Guix or Nix. The same framework for providing reproducible software builds is also used to provide reproducible system configuration.
very interesting - thanks for pointing that out.
Ergo my statement that Docker and Nix/Guix will converge at some point. There is already an overlap: I believe Docker has mindshare, but it is unusable on desktops.. whereas Nix/Guix was designed for desktops, but is losing out because most people use Macs!!
It would really be something to build a ESXi for Docker/Nix/Guix and be able to provision fully functional VMs on top of it.
I am currently using the Nix packager on a Mac and it works fairly well. It's not as smooth as Homebrew but it's getting there. See http://nixos.org/nix/ -> Get Nix
We already have a cloud-orchestration solution, built on NixOS, and in a lot of ways it's already considerably nicer than some alternatives: http://nixos.org/nixops/
Docker doesn't really offer us much beyond a stable engine for actually using containers, which could probably be accomplished with its `libcontainer` anyway.
Docker's imperative scripting language to build systems isn't appropriate for NixOS, because we declare our entire system with a single configuration file, which can be transactionally updated/rolled back. That means you never want to really run 'apt-get install ...', you want to add a package to your system by modifying your configuration file, and 'rebuilding' your system. So the imperative 'run commands to update OS' model that something like Ansible uses is obsoleted.
Because of this, if I have my laptop with a configuration file, and a backup of my data, I can basically reproduce my laptop on a brand new machine on the spot by A) copying config, B) 'realizing' the configuration and rebuilding my OS based on it, C) restore data. Naturally, you normally just version control all these files, because your configuration is your specification of how to 'create a system from scratch'. All I do is 'git clone' onto a new device, run 'nixos-rebuild' and my system is ready to go. I can deploy a live server after making sure the configuration is reboot/clean-start safe by testing it in a VM, and scp'ing it to a new server, etc.
Note that the same language, Nix, is used to A) describe how to build packages in a reproducible way, B) used to describe your OS configuration (NixOS), and C) is used to describe whole configuration networks, including things like EC2 configs (NixOps). Nix is also a programming language, not like YAML or a simple configuration language - so you also get a significant amount of reuse in code, and a drop in tool diversity/complexity from this. My NixOS configurations are very abstracted and reusable for multiple situations, they share configs where it makes sense, etc.
NixOS, at least, also has a concept of Linux containers that are specified declaratively in the same configuration file. This is why I mentioned libcontainer earlier - currently, NixOS spawns NixOS-based containers using systemd-nspawn. In theory we could probably replace this with Docker, but it's not really a detail that the user is aware of - the actual underlying mechanics of the container engine are abstracted. Docker is useful as a development tool even on NixOS, but it's not really what we need. We could maybe write something more sane by reusing some code from elsewhere.
Of course not everything is perfect. Docker has of course progressed very quickly for users since I last used it (very early releases that were promising but ultimately lacking in a lot of ways), but since using NixOS I have never looked back, because while it's a tool that requires me to do a lot of work (which is not an exaggeration), it is one that actually allows me to move mountains, so to speak, and get my work done.
Docker has major security issues. Guix and Nix allow for much more security via build reproducibility, extensive checksumming, and of course, containers. I don't know what "random damage area" means, but you can't shoot yourself in the foot with Guix or Nix. If you screw up, you just roll back and try again.
See: http://www.gnu.org/software/guix/manual/html_node/Using-the-...