Hacker News Reader

Comment by gravypod | Hacker News Reader

For software designed to be hosted in a datacenter (rather than distributed to an end user) is there a reason why Guix is better than some containerization framework? With things like Nix there's reproduciblity guarantees. With containers it (appears) simpler to package and reproduciblity ship your software.

What is Guix's main selling point?

View on HN

Nix and Guix are extremely similar. Guix is a fork of nix that is rewriting it to be guile all the way down.

I personally like Nix's syntax better than a lisp, but that is just a preference.

The core of how they operate is the same. Just look at their build/ci system.

https://hydra.nixos.org/ https://ci.guix.gnu.org/

Yeah but if I had the option of Docker or something nix based, why would I not choose Docker? Particularly as deploying to most Clouds is pretty easy if an app in already in a Docker Container.

One advantage is that guix/nix only isolate dependencies. So, if I want two or more utilities to interact, I don’t need to bring in something like docker-compose or used network protocols, I just depend on both and write a script or something. This way, I can start with each service on its own container and then, as necessary, move two services into one container or whatever.

Also, nix/guix are somewhat lower-overhead ways to build a system for local development than containers.

You can easily build Docker images using Nix. Benefits: (1) reproducability, if you pin to a certain nixpkgs, you always get the same set of packages; (2) layers don't have to be full filesystem diffs; (3) the image only contains the computed closure. E.g. I produce Docker images an NLP program with Nix. The image only contains: glibc, tensorflow, my program, word embeddings, the model. No other system files or dependencies. Since the image build expression uses Nix expressions, I can also directly use the same models on my Linux workstation, Linux servers, macOS, etc. without Docker.

This is a good starting point:

https://grahamc.com/blog/nix-and-layered-docker-images

Combine it and use nix for building docker containers. :)

Guix provides interoperability with Docker: the 'guix pack' command builds Docker images of applications, and 'guix system docker-image' builds images containing a complete system with services, etc.

So Guix gives you reproducibility, provenance tracking, and hackability, but you can still "speak Docker".

Nix & Guix both implement the functional deployment model pioneered by Nix, but I do not see Guix as a "fork" of Nix.

It's also much more than a matter of syntax: see the great explanation at https://news.ycombinator.com/item?id=18910683 .

I have read that comment and such before. However it is still a fork. It started off with the same code base, and is being rewritten in guile from the top down.

That rewrite is bring new features, differences, and makes them not compatible with each other. However, as they started off with the same code to me they will always be a fork. While something can evolve to something that is fully independent, it doesn't change it's origin. Also a fork is not bad word. Many successful "forks" become more popular than the original.

To this day guix still uses the nix-daemon code, which is written in C. And they build system they used was hydra, written in perl. In fact http://hydra.gnu.org used to say "download nix package". for everything. Cuirass is very recent, but you can still see that it still looks extremely similar to Nix's hydra.

I think guix still has better porcelain (cli).

Nix has much better discoverability and readability. I was going to show different files, however gnu.org NS servers seem to be down.

Most importantly it isn't a competition. These two products existing only benefit each other as new ideas between them flow both ways.

An already built container is reproducible in the same way that a binary artifact is reproducible. Nix is reproducible to its core, including hash integrity of every tool used to execute the build. Anybody should be able to build a bit-for-bit identical copy from scratch.

It's quite an ambitious goal, and I'm still surprised it succeeded. Unlike docker, nix can't be naive about what's being built. For example, it has to understand the specifics of python and python packages, and build its own infrastructure instead of using the existing tools like docker.

> An already built container is reproducible in the same way that a binary artifact is reproducible. Nix is reproducible to its core, including hash integrity of every tool used to execute the build. Anybody should be able to build a bit-for-bit identical copy from scratch.

This is the goal, but not actually the case. Nix/guix does many things to make reproducible outputs more likely, however people are very good at putting things in a package that are not deterministic, such as the build time down to the milisecond.

Reply on news.ycombinator.com