4 ms·
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 speci
by davexunit 11y ago
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.
- mands 11y agoI'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?
- davexunit 11y agoYes 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.
- mands 11y agoThat'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.
- davexunit 11y agoGuix 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.
- mands 11y agoApologies for the confusion - I assume call-with-container talks to the required kernel functionality directly instead.
- sandGorgon 11y agoActually 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.
- davexunit 11y agoActually, 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-Configuration-System.html#Using-the-Configuration-System http://www.gnu.org/software/guix/manual/html_node/Using-the-...
- mateuszf 11y agoTrue, but Docker adds true separation. It enhances security and decreases random damage area.
- davexunit 11y agoDocker 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.
- mateuszf 11y agoWhat if an application removes all your files in the filesystem via "rm -rf /", because it has remote execution bug?
- deleted 11y ago