Also, in addition to being a containerization strategy, (Get ready to cringe hard line bloat hating ascetics!) Docker has also become a super convenient container for server side software distribution, and for that use case I think it would take a long time for nix to overtake the convenience of DockerHub and private docker registries.
Definitely agree. I just installed NixOS in a vm to start attempting to learn it and seems like a pretty steep hill to climb, Docker was challenging when I first encountered it years ago, and while I’m far from being comfortable with it, I don’t think it had near the learning curve that Nix/NixOS does.
I want to continue to look into it, but it’s not going to replace any of my Docker containers any time soon.
Wait actually on second thought, maybe? It’s entirely plausible that Docker will implode horribly due to terrible decisions induced by share price chasing. Leaving something else to take the field from it with no competition.
Then Nix would have some users and Docker would have roughly zero users (even though the former Docker users moved to something else really similar under a different banner) and Nix would have overtaken Docker.
The article conflates two questions. Will Nix be more popular than Docker? Probably not. Will Nix be able to do everything Docker does? It has been able to do that for a couple years now!
Atlassian Marketplace is a big Scala application, the jar is built via a Nix shell and then we use Nix to build an OCI container image. The image is pushed to a registry where the internal Atlassian PaaS is able to deploy to production. Every release is completely reproducible, bit for bit!
Looking at Nix DSL code makes my eyes bleed. I realize that this isn’t a fundamental problem, but it sure doesn’t make me want to learn how to use Nix.
They rightly point out the limited sharing of layers in Docker. Nix has better composability via the separate /nix/store paths, though the problem is then that the package definitions become very unwieldy and non-standard.
You pay a tax on every package. And since Nix has better reproducibility, you have more packages to build.
You also have more problems with the model shear between N different language package managers who want to own their slice of world.
I was thinking that what we need is simply an HTTP proxy for reproducibility without rewriting all your package builds and building them from source. Has anyone done anything like that?
That is, tools like apt should all be able to use an HTTP proxy to fetch data. So if you do an apt install in something like a Dockerfile, it the proxy should be able to record what it retrieved, and you can archive it somewhere. (where to archive it is another issue; I don’t like depending on free services from Docker.)
Then again I remember this other project which adds a “lockfile” concept to Debian (an expanded transitive dependency list). So maybe it would suffice if Debian and pip had that?
This is a false equivalency. A better question would be: Is nix going to overtake docker, puppet, Linux distros, chef, ansible, terraform, and cloudfoundry?
Probably not, because there are a lot more people spending effort making all of those things better. Nix can do all of those things, however, which makes it a very powerful tool. These debates about which is better, for such vastly different tools, are unproductive.
Whereas Nix is primarily designed for building packages & environments in a reproducible way.
The author is I guess only referring to nix the tool, to the exclusion of nixpkgs the package repo and nixos the Linux distro and nixops the operations tool. Maybe the author shouldn’t do that.
The other barrier is that it is still quite niche and full of nuanced bugs.
For example, the declarative execution of container services using podman is fully documented but multiple times for me generated in broken services that failed to run.. And this happened within a single nixOS release (not during a transition of major releases).
It is a major effort to re-codify development environments for a completely new development “closure” DSL.
At work I’m using Nix to build container images, which I’m trying to get fully reproducible, and that would have been a herculean task without Nix. I don’t think we’ll need Docker at all.
The article discusses some valuable differences between Docker and Nix but while looking for click-bait the author into a bit of a logical tangle. In the first paragraph, I quote:
This question could be dismissed by saying that Nix and Docker are different tools that solve different problems.
The author implies here that it’d be a mistake to dismiss the question in this way, and that he’s about to explain why. Then the author ends the article with:
Will Nix overtake Docker? No, these tools accomplish different goals
I’ve been using nix recently for building static versions of Dawn for Linux.
I really enjoy the simplicity of the .nix expression language and definition files. Being into the idea of statically-compiled code I use musl and oh wow does it take a very long time to build/start a nix-shell. We’re talking ~1h on a 16 CPU Ryzen 3950x. But once it’s built, starting a nix-shell is reasonably quick (~1s.)
The one big issue I’ve had with nix is that it uses the host machine as its base layer (I assume they use overlayfs) and it leaks through! I.e. the same exact .nix recipe run on two different machines may yield different outcomes, which “defies” a key selling point of nix. Someone pointed out to me that I could use buildFHSUserEnv but it does not seem to be compatible with musl or some of the packages I need (llvm 13, musl, cmake, ninja, python, x11).
Anyhow, I find it a great alternative to Docker for build environments (especially since docker runs as root on Linux and does not do uid/gid mapping) and I’ll keep using nix I think.
In what way do you mean it leaks through? I thought that as long as you use pinning/hashes/flakes your whole environment+versions is a part of the package definition. Or do you mean something like different CPUs result in different optimisation which results in different ordering / other details?
“inside” the nix shell things like the host system’s /usr/lib directory is available. This caused issues for me with some build scripts that would go look in those “standard” locations and as a result link against libs from the host system. I believe the idea is that every nix tool e.g. gcc or cmake is built to only consider /nix/ stores but as soon as you run something that wasn’t patched for nix (in my case dawn and depot_tools) you start getting into trouble. Just gotta be conscious about it though and explicitly specify locations of things.
Can’t help but think that this follows Betteridge’s Law of Headlines…
For the uninitiated:
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines
If you ignore the clickbait title, it has a nice quick comparison between a minimal Docker and minimal Nix config
No; Docker doesn’t require as much new learning. Solutions which let you lift-and-shift from previous infra really often win.
This.
Also, in addition to being a containerization strategy, (Get ready to cringe hard line bloat hating ascetics!) Docker has also become a super convenient container for server side software distribution, and for that use case I think it would take a long time for nix to overtake the convenience of DockerHub and private docker registries.
Definitely agree. I just installed NixOS in a vm to start attempting to learn it and seems like a pretty steep hill to climb, Docker was challenging when I first encountered it years ago, and while I’m far from being comfortable with it, I don’t think it had near the learning curve that Nix/NixOS does.
I want to continue to look into it, but it’s not going to replace any of my Docker containers any time soon.
Wait actually on second thought, maybe? It’s entirely plausible that Docker will implode horribly due to terrible decisions induced by share price chasing. Leaving something else to take the field from it with no competition.
Then Nix would have some users and Docker would have roughly zero users (even though the former Docker users moved to something else really similar under a different banner) and Nix would have overtaken Docker.
Perhaps a silly question - can’t we fall back to Podman? Red Hat has several Docker alternatives.
Sure. Anything that can run containers.
The article conflates two questions. Will Nix be more popular than Docker? Probably not. Will Nix be able to do everything Docker does? It has been able to do that for a couple years now!
Does Nix let you build a single file package that AWS (for example) can spin up in response to a network event?
You can build OCI container using Nix, so my answer would be - probably yes.
So I guess another question to put is, will nix replace the docker file?
Nix replaced Dockerfiles for my team at work.
Atlassian Marketplace is a big Scala application, the jar is built via a Nix shell and then we use Nix to build an OCI container image. The image is pushed to a registry where the internal Atlassian PaaS is able to deploy to production. Every release is completely reproducible, bit for bit!
neat, and i didn’t know that. thanks.
Guix (which I think of as a better Nix) lets you do this. You can even produce a pack in the Docker image format directly from Guix.
I had not seen that; thank you.
Looking at Nix DSL code makes my eyes bleed. I realize that this isn’t a fundamental problem, but it sure doesn’t make me want to learn how to use Nix.
Work is going on to allow people to specify most packages using simple YAML, etc. instead of using full Nix all the time.
That’s a bit like answering people who complain that this 747 is a bit difficult to fly by giving them a toy plane.
The Nix language is great. People are always gonna whinge.
They rightly point out the limited sharing of layers in Docker. Nix has better composability via the separate
/nix/storepaths, though the problem is then that the package definitions become very unwieldy and non-standard.You pay a tax on every package. And since Nix has better reproducibility, you have more packages to build.
You also have more problems with the model shear between N different language package managers who want to own their slice of world.
I was thinking that what we need is simply an HTTP proxy for reproducibility without rewriting all your package builds and building them from source. Has anyone done anything like that?
That is, tools like apt should all be able to use an HTTP proxy to fetch data. So if you do an
apt installin something like a Dockerfile, it the proxy should be able to record what it retrieved, and you can archive it somewhere. (where to archive it is another issue; I don’t like depending on free services from Docker.)Then again I remember this other project which adds a “lockfile” concept to Debian (an expanded transitive dependency list). So maybe it would suffice if Debian and pip had that?
https://news.ycombinator.com/item?id=28840128
And I still wonder if a nicer system could take advantage of the fact that OverlayFS is in the kernel, and just bypass Docker …
Things you do in apt, including install, get logged to /var/log/apt/history.log, with entries that look like this:
Start-Date: 2021-11-10 15:49:09 Commandline: apt install html-xml-utils Requested-By: dsr (1000) Install: html-xml-utils:amd64 (7.7-1.1) End-Date: 2021-11-10 15:49:13
So you could just log that via syslog somewhere useful to you, or copy off the log .
This is a false equivalency. A better question would be: Is nix going to overtake docker, puppet, Linux distros, chef, ansible, terraform, and cloudfoundry?
Probably not, because there are a lot more people spending effort making all of those things better. Nix can do all of those things, however, which makes it a very powerful tool. These debates about which is better, for such vastly different tools, are unproductive.
The author is I guess only referring to nix the tool, to the exclusion of nixpkgs the package repo and nixos the Linux distro and nixops the operations tool. Maybe the author shouldn’t do that.
The DLS is still a learning barrier.
The other barrier is that it is still quite niche and full of nuanced bugs. For example, the declarative execution of container services using podman is fully documented but multiple times for me generated in broken services that failed to run.. And this happened within a single nixOS release (not during a transition of major releases).
It is a major effort to re-codify development environments for a completely new development “closure” DSL.
I won’t make any claims about docker, but Nix is a solid replacement for docker-compose.
At work I’m using Nix to build container images, which I’m trying to get fully reproducible, and that would have been a herculean task without Nix. I don’t think we’ll need Docker at all.
That’s a great application for Nix! Making Dockerfiles reproducible is a nightmare and most folks don’t even try.
I hope you can write this up sometime!
The article discusses some valuable differences between Docker and Nix but while looking for click-bait the author into a bit of a logical tangle. In the first paragraph, I quote:
The author implies here that it’d be a mistake to dismiss the question in this way, and that he’s about to explain why. Then the author ends the article with:
Aka the question could indeed be dismissed.
I’ve been using nix recently for building static versions of Dawn for Linux.
I really enjoy the simplicity of the .nix expression language and definition files. Being into the idea of statically-compiled code I use musl and oh wow does it take a very long time to build/start a nix-shell. We’re talking ~1h on a 16 CPU Ryzen 3950x. But once it’s built, starting a nix-shell is reasonably quick (~1s.)
The one big issue I’ve had with nix is that it uses the host machine as its base layer (I assume they use overlayfs) and it leaks through! I.e. the same exact .nix recipe run on two different machines may yield different outcomes, which “defies” a key selling point of nix. Someone pointed out to me that I could use buildFHSUserEnv but it does not seem to be compatible with musl or some of the packages I need (llvm 13, musl, cmake, ninja, python, x11).
Anyhow, I find it a great alternative to Docker for build environments (especially since docker runs as root on Linux and does not do uid/gid mapping) and I’ll keep using nix I think.
In what way do you mean it leaks through? I thought that as long as you use pinning/hashes/flakes your whole environment+versions is a part of the package definition. Or do you mean something like different CPUs result in different optimisation which results in different ordering / other details?
“inside” the nix shell things like the host system’s /usr/lib directory is available. This caused issues for me with some build scripts that would go look in those “standard” locations and as a result link against libs from the host system. I believe the idea is that every nix tool e.g. gcc or cmake is built to only consider /nix/ stores but as soon as you run something that wasn’t patched for nix (in my case dawn and depot_tools) you start getting into trouble. Just gotta be conscious about it though and explicitly specify locations of things.
Is Nix also like a universal executable format for Linux servers?