this post was submitted on 01 Jul 2023
181 points (96.9% liked)
Programmer Humor
32710 readers
224 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
How long until nix flakes go mainstream and fix this problem?
Replace "nix flakes" with "Docker" and you have your answer from almost decade ago.
No offense but it sounds like you don’t actually understand nix flakes if you think they’re 1:1 equivalent to Docker.
They simply are not containers. They allow the declarative BUILD of any derivation at any time in the future. They hermetically lock all dependencies and build instructions which allows you to archive and reproduce the EXACT content-addressed dependency graph of the software. You can rebuild using a flake while Docker doesn’t actually allow that same hermetic reproducible guarantee whatsoever.
See here for a much better explanation of the glaring differences between the two: https://youtu.be/0uixRE8xlbY
You could even build a container with a flake though I’d recommend OCI instead because they’re an open standard...
This is programmerhumor so perhaps allow for a bit of hyperbole on my part. I wasn't completely factual.
However the initial days of Docker were effectively promising to solve the exact same "it works on my laptop" problem. The idea was that developer builds docker image and pushes it to repository where it can pass through CI and eventually the same image gets to production.
As you can see, this effectively reproduces the EXACT content as well, because you transfer the files in a set of tar files.
It didn't work for many reasons. One of which is the fact that it's often not so much about the exact files, but the rest of the environment like DBs, proxies, networking, etc that is the problem. I've seen image misbehaving in production due to different kernel version/configuration.
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. 🙏🏼
probably until it is easier to pinpoint specific versions of any package in question
Nix flakes do that. The flake.lock file automatically pinpoints not just specific versions but specific builds of each package and locks them to their hash. It will also soon be content-addressed by default which would mean that each derivation takes into account the contents of the entire dependency tree and how they relate to one another.
They technically do, but let's say I want to have
kubectl v1.10andgo v1.0among others. Some packages do get packaged multiple times for each version. Most don't. Then you end up hunting down build hashes for each version using tools like https://lazamar.co.uk/nix-versions/ which work I guess but the UX is not great. Talking about this with my colleagues, most won't bother until you can declaratively list tools and versions directlyCorrect me if I’m wrong: in my understanding, you could also package your own custom derivation from scratch that would do that. I agree that the UX is clunky at best but (in my perhaps incomplete understanding) you can do that today.