Hacker News Reader

Comment by davexunit | Hacker News Reader

There's quite a lot of separation, IMO. Docker uses an imperative, stateful system for image creation that doesn't actually help with reproducibility and specifically only creates container environments. Guix and Nix use a functional, declarative system for building anything (software builds, VM image creation, etc.) and can create any type of environment, including containers. Guix and Nix are much more general-purpose and are built upon a stronger foundation.

So, rather than using Docker running Debian/Ubuntu/whatever images and another OS entirely managing the host, you can use Guix or Nix to manage every layer and take advantage of their very advanced features everywhere.

View on HN

I'm a big fan of Guix/Nix and would love to see them in greater use.

Whilst I agree that they provide many of the reproducibly benefits of containers, isn't the other big advantage of containers the (theoretical) security benefits they bring? i.e. a process can't break out of its container and access other data.

Perhaps I'm missing something but can such isolation be provided by Guix/Nix?

Yes it can. The build daemon already uses containers to create the isolated environments to perform builds in so that we can view builds as pure functions. Nix uses systemd-nspawn for making NixOS containers. Guix uses a Scheme interface that I wrote called call-with-container to build GuixSD containers or simple containers without an init system via 'guix environment'. call-with-container is a work in progress, but some of the code has already made it to master, and the rest of it should land in master in time for the next release.

That's great to hear, thanks for the work, I look forward to trying it out. Using Guix with systemd-nspawn sounds like it could be a formidable combination.

Guix doesn't use systemd, but maybe you could still use systemd-nspawn somehow? call-with-container will be the preferred mechanism on Guix, since it will integrate tightly with the rest of the system.

Apologies for the confusion - I assume call-with-container talks to the required kernel functionality directly instead.

Actually I would argue that Docker is more flexible than Nix/Guix. The usecase for package managers are installing packages, whereas Docker combines package management along with configuration management.

Think about Nix+Ansible - that's what you really need if you are going to have a true stateless system. Take your base packages to create an immutable snapshot and then layer your configuration changes on top of them.

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.

See: http://www.gnu.org/software/guix/manual/html_node/Using-the-...

True, but Docker adds true separation. It enhances security and decreases random damage area.

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.

What if an application removes all your files in the filesystem via "rm -rf /", because it has remote execution bug?

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.

Nix(OS) does configuration management too, Guix(SD) does it too but only for the base system as far as I know. There's no need for ansible on a NixOS system.

A NixOps-like tool for Guix is in the works.

Reply on news.ycombinator.com