51–60 of 80 posts
Earlier quoted context omitted.
It's not reproducible then, it's simply cached. It's a valid approach but there's tradeoffs of course.
it's not an either or, it can be reproducible and cached similarly, nix cannot guarantee reproducibility if the user does things to break that possibility
Earlier quoted context omitted.
it's not an either or, it can be reproducible and cached similarly, nix cannot guarantee reproducibility if the user does things to break that possibility
The difference is that you can blow the Nix cache away and reproduce it entirely. The same cannot be said for Docker.
Docker has a `--no-cache` flag, even easier than blowing it away, which you can also do with several built in commands or a rm -rf /var/lib/docker
Perhaps worth revisiting: https://docs.docker.com/build/cache/
Earlier quoted context omitted.
Along similar lines, when I was reading the article I was thinking "this just sounds like a slightly worse version of nix". Nix has the whole content addressed build DAG with caching, the intermediate language, and the ability to produce arbitrary outputs, but it is functional (100% of the inputs must be accounted for in the hashes/lockfile, as opposed to Docker where you can run commands like `apk add firefox` which…
> whereas nix will always produce the same output for a given input. If they didn't take shortcuts. I don't know if it's been fixed, but at one point Vuze in nix pulled in an arbitrary jar file from a URL. I had to dig through it because the jar had been updated at some point but not the nix config and it was failing at an odd place.
The --mount=type=cache for package managers is genuinely transformative once you figure it out. Before that, every pip install or apt-get in a Dockerfile was either slow (no caching) or fragile (COPY requirements.txt early and pray the layer cache holds). What nobody tells you is that the cache mount is local to the builder daemon. If you're running builds on ephemeral CI instances, those caches are gone every build…
Docker is profoundly bad software.
Earlier quoted context omitted.
> whereas nix will always produce the same output for a given input. If they didn't take shortcuts. I don't know if it's been fixed, but at one point Vuze in nix pulled in an arbitrary jar file from a URL. I had to dig through it because the jar had been updated at some point but not the nix config and it was failing at an odd place.
Flakes fixes this for Nix, it ensures builds are truly reproducible by capturing all the inputs (or blocking them).
Earlier quoted context omitted.
> It's a big glob of homegrown thoughts and ideas. Some of them are really slick, like build deduplication. Others are clever and hard to reason about, or in the worst case, terrifying to touch. This is true of packaging and build systems in general. They are often the passion projects of one or a handful of people in an organization - by the time they have active outside development, those idiosyncratic concepts are…
As someone who has worked in the space for a while and been heavily exposed to nix, bazel, cmake, bake, and other systems, and also been in that "passion project" role, I think what I've found is that these kinds of systems are just plain hard to talk about. Even the common elements like DAGs cause most people's eyes to immediately glaze over. Managers and executives are happy to hear that you made the builds faster…
Buildkit... It sounds great in theory, but it JustDoesn'tWork(tm). Its caching is plain broken, and the overhead of transmitting the entire build state to the remote computer every time is just busywork for most cases. I switched to Podman+buildah as a result, because it uses the previous dead simple Docker layered build system. If you don't believe me, try to make caching work on Github with multi-stage images. Just…
Earlier quoted context omitted.
> so two docker builds can end up with the same hash but different output The cache key includes the state of the filesystem so I don’t think that would ever be true. Regardless, the purpose of the tool is to generate [layer] images to be reused, exactly to avoid the pitfalls of reproducible builds, isn’t it? In the context of the article, what makes builds reproducible is the shared cache.
Ah you're right, the hash wouldn't be the same but a Dockerfile could produce different outputs on different machines whereas nix will produce identical output on different machines.
Nix isn't some magical thing that makes things reproducible either. nix is simply pinning build inputs and relying on caches. nixpkgs is entirely git based so you end up pinning the entire package tree.
Earlier quoted context omitted.
> whereas nix will always produce the same output for a given input. If they didn't take shortcuts. I don't know if it's been fixed, but at one point Vuze in nix pulled in an arbitrary jar file from a URL. I had to dig through it because the jar had been updated at some point but not the nix config and it was failing at an odd place.
Flakes fixes this for Nix, it ensures builds are truly reproducible by capturing all the inputs (or blocking them).