Live data from Hacker News

Will Nix Overtake Docker?

blog.replit.com

11–20 of 259 posts

Re: Will Nix Overtake Docker?

#11
IMO initial value of docker for local development is enabling me to run two copies of postgres without them shitting on each other. I get that nix is supposed to be hermetic, but does it enable two of something?

nix being really good at package management is something docker needs to imitate -- out of order apt-get without requiring a re-downloading all the packages, for example, seems like it would shrink most cloud build costs. I guess this is what the article means by trouble 'sharing layers'

docker buildkit (or moby buildx or wherever the branding has settled) is supposed to to improve caching, but creating a simple API for caching that plays nicely with system + language package managers would really move the needle here; reorderable package installs would be the v2

Re: Will Nix Overtake Docker?

#12

I tried using Nix and NixOS early in the year, but documentation is an issue. Also, while I appreciate NixOS’s focus on reproducible configuration, I also have 25 years worth of mediocre Unix sysadmin experience, and it would be nice if the system found a way to accommodate Unix. My last straw was trying to get nix to schedule some task through systemd, when what I wanted was a simple crontab.

Kind of a tangent, but from what I have seen, crontab doesn't actually exist on modern distros, I believe they have a tool that converts the crontab config in to systemd timers. As well as fstab.

Re: Will Nix Overtake Docker?

#13

IMO initial value of docker for local development is enabling me to run two copies of postgres without them shitting on each other. I get that nix is supposed to be hermetic, but does it enable two of something? nix being really good at package management is something docker needs to imitate -- out of order apt-get without requiring a re-downloading all the packages, for example, seems like it would shrink most cloud…

You can use Nix to create a tarball that can then be launched as a Docker container. However, I haven’t figured out a way to make Nix play nicely with container image layering—you get a small container image for deployment, but you’ll have lots of such largely-duplicative tarballs in the CI pipeline and the latency for generating them is annoying.

Re: Will Nix Overtake Docker?

#15
> If you run docker build twice with the same Dockerfile you might get 2 images that behave in different ways. For example, a third-party package could silently be updated and cause breakage. Aggressively pinning dependency versions helps, but doesn't completely prevent this issue.

If "aggressive" means fully, then why doesn't that fix the issue?

Re: Will Nix Overtake Docker?

#16

> If you run docker build twice with the same Dockerfile you might get 2 images that behave in different ways. For example, a third-party package could silently be updated and cause breakage. Aggressively pinning dependency versions helps, but doesn't completely prevent this issue. If "aggressive" means fully, then why doesn't that fix the issue?

A lot of package repositories prevent this now, but theoretically your package repository could allow a new version of the package to be uploaded with the same version number. Docker tags have this issue in fact, so even your base image could change underneath you.

Re: Will Nix Overtake Docker?

#17

I tried using Nix and NixOS early in the year, but documentation is an issue. Also, while I appreciate NixOS’s focus on reproducible configuration, I also have 25 years worth of mediocre Unix sysadmin experience, and it would be nice if the system found a way to accommodate Unix. My last straw was trying to get nix to schedule some task through systemd, when what I wanted was a simple crontab.

Kind of a tangent, but from what I have seen, crontab doesn't actually exist on modern distros, I believe they have a tool that converts the crontab config in to systemd timers. As well as fstab.

Yes, so I was doubly frustrated in this instance. I know the BSD-style init script system that I learned with Slackware is not geared well towards modern hardware (i.e., laptops), but it was so much simpler to read and comprehend.

Re: Will Nix Overtake Docker?

#18
post #14

One thing in the blog that is not true is that you can only inherit from a single layer. You can use multi-stage builds to grab & blend layers: https://docs.docker.com/develop/develop-images/multistage-bu... . It is not as powerful as nix, granted, but it is possible.

While you can copy files from different stages, I wouldn't consider this to be the same thing as composing two base images together. Like the example in the post, you can't take the Rust and NodeJS images and tell Docker to magically merge them. You can copy binaries & libraries from one to the other but that seems extremely tedious and error prone.

Whereas Nix makes it rather trivial to compose together the packages you need (eg Rust, NodeJS) in your environment.

Re: Will Nix Overtake Docker?

#19

> If you run docker build twice with the same Dockerfile you might get 2 images that behave in different ways. For example, a third-party package could silently be updated and cause breakage. Aggressively pinning dependency versions helps, but doesn't completely prevent this issue. If "aggressive" means fully, then why doesn't that fix the issue?

Probably because of non-deterministic builds. Especially if the dependency pulls info from the network at build time.

Re: Will Nix Overtake Docker?

#20

IMO initial value of docker for local development is enabling me to run two copies of postgres without them shitting on each other. I get that nix is supposed to be hermetic, but does it enable two of something? nix being really good at package management is something docker needs to imitate -- out of order apt-get without requiring a re-downloading all the packages, for example, seems like it would shrink most cloud…

Nix supports this quite well.

https://nixos.org/manual/nix/stable/#multiple-versions

The Nix and container mindset are very similar in that they refer to all of their dependencies, including down to glibc.

Post reply on HN