I know it’s a strange place for this conversation but the facts remain: docker images don’t do this and nix flakes actually do. As the video I linked demonstrates and you allude to, Docker files aren’t 100% hermetic (which means they’re not reproducible) while Nix flakes actually do achieve this. Watch the video I linked for more explanation which directly talks about how nix works with the goals of Docker that you mentioned in the head of your last comment. I hope my non-confrontational tone comes across somehow. This is all said with respect and in the spirit of science.
First of all. Thank you for civil discussion. As you say this is weird place to have such discussion, but it’s also true that these jokes often have some kernel of truth to them that makes these discussions happen organically.
So with that out of the way and with no bad intentions on my side:
I’ve noticed you use Dockerfiles and Docker Images interchangeably. And this might be the core of misunderstanding here. What I was describing is that:
Developer builds an image (using Dockerfile or otherwise) on their laptop and then pushes that image to a Docker repository.
This exact same image is then used in CI to do integration tests, scanning, whatever…
If all is good, this image is then deployed to production.
So if you compare sha of the image in production and on developers laptop, they are the same checksums. Files are identical. Nix arrives to this destination kind of from the other side. Arguably in more elegant way, but in both cases files are the same.
This was the promise (or one possibility) in the early days of Docker. Obviously there are some problems with this approach. Like what if CPU architecture of the laptop differs from production server? Well that wasn’t a problem back in 2014, because ARM servers just didn’t exist. (Not in any meaningful way) There’s also this disconnection between the code that generates the image and the image itself, that goes to production. How do you trust environment (laptop) where image is built. Etc… So it just didn’t stick as a deployment pattern.
Many of these things Nix solves. But in terms of “it works on my laptop” what I wrote in previous comment applies. The environment differences themselves rather than slightly different build artefacts is what’s frequently the problem. Nix is not going to solve the problem of slightly different databases because developer is runing MariaDB locally to test, but in production we use DB managed by AWS. Developer is not going to catch this quirky behavior of how his app responds to proxy, because they do not run AWS ELB on their laptop, but production is behind it. You get the idea.
When developer says it works okay on their laptop, what it usually means is the they do not have 100% copy of production locally (because obviously they don’t) and that as a result they didn’t encounter this specific failure mode.
Which is not to say, that Nix is bad idea. Nix is great. I’m just saying that there’s more to the “laptop problem” than just reproducible builds - we had those even before Docker Images.
Hope that makes sense. And again, thanks for civil discussion.
I know it’s a strange place for this conversation but the facts remain: docker images don’t do this and nix flakes actually do. As the video I linked demonstrates and you allude to, Docker files aren’t 100% hermetic (which means they’re not reproducible) while Nix flakes actually do achieve this. Watch the video I linked for more explanation which directly talks about how nix works with the goals of Docker that you mentioned in the head of your last comment. I hope my non-confrontational tone comes across somehow. This is all said with respect and in the spirit of science.
First of all. Thank you for civil discussion. As you say this is weird place to have such discussion, but it’s also true that these jokes often have some kernel of truth to them that makes these discussions happen organically.
So with that out of the way and with no bad intentions on my side:
I’ve noticed you use Dockerfiles and Docker Images interchangeably. And this might be the core of misunderstanding here. What I was describing is that:
So if you compare sha of the image in production and on developers laptop, they are the same checksums. Files are identical. Nix arrives to this destination kind of from the other side. Arguably in more elegant way, but in both cases files are the same.
This was the promise (or one possibility) in the early days of Docker. Obviously there are some problems with this approach. Like what if CPU architecture of the laptop differs from production server? Well that wasn’t a problem back in 2014, because ARM servers just didn’t exist. (Not in any meaningful way) There’s also this disconnection between the code that generates the image and the image itself, that goes to production. How do you trust environment (laptop) where image is built. Etc… So it just didn’t stick as a deployment pattern.
Many of these things Nix solves. But in terms of “it works on my laptop” what I wrote in previous comment applies. The environment differences themselves rather than slightly different build artefacts is what’s frequently the problem. Nix is not going to solve the problem of slightly different databases because developer is runing MariaDB locally to test, but in production we use DB managed by AWS. Developer is not going to catch this quirky behavior of how his app responds to proxy, because they do not run AWS ELB on their laptop, but production is behind it. You get the idea.
When developer says it works okay on their laptop, what it usually means is the they do not have 100% copy of production locally (because obviously they don’t) and that as a result they didn’t encounter this specific failure mode.
Which is not to say, that Nix is bad idea. Nix is great. I’m just saying that there’s more to the “laptop problem” than just reproducible builds - we had those even before Docker Images.
Hope that makes sense. And again, thanks for civil discussion.
Thanks for the thoughtful reply. Thanks for getting into the weeds with me. I learned a bit from you here. 🙏🏼