The issue is, nix builds are only guaranteed to be reproducible if the dependencies don’t change. Which they shouldn’t, but you can’t trust the internet to be consistent. Things won’t be there to be fetched forever.
Images do. And you can turn one into a container in seconds. I suppose it’s a matter of preference. I like one a package to be independent
The issue is, nix builds are only guaranteed to be reproducible if the dependencies don’t change.
Dude, this is exactly why Nix is better. Docker builds are only guaranteed to be reproducible if the dependencies don’t change. Which they will. The vast majority of real-world Dockerfiles do pip install, wget, all kinds of basically unlimited nonsense to pull down their dependencies from anywhere on the internet.
Nix builds, on the other hand, are forbidden from the internet, specifically to force them to declare dependencies explicitly and have it within a managed system. You can trust that the Nix repositories aren’t going to change (or store them yourself, along with all the source that generated them and will actually produce the same binaries, if you’re paranoid). You can send the flake.nix and flake.lock files and it will actually work to reproduce a basically byte-identical container on the receiver’s end, which means you don’t have to send multi-gigabyte “images” in order to be able to depend on the recipient actually being able to make use of it. This is what I was saying that the whole thing of needing “images” is a non-issue if your workflow isn’t allowing arbitrary fuckery on an industrial scale whenever you are trying to spin up a new container.
I suspect that making a new container and populating it with something useful is so trivial on Nix, that you’re missing the point of what is actually happening, whereas with Docker you can tell something big is happening because it’s such a fandango when it happens. And so you assume Docker is “real” and Nix is “fake” or something.
I like one a package to be independent
Yes, me too, which is why an affinity for Docker is weird to me.
you can trust the nix repositories aren’t going to change
That, I do not. And storing the source and such for every dependency would be bigger than, and result in essentially the same thing as an image.
I think you’re trying to achieve something different than what docker is for. Docker is like installing onto an empty computer then shipping the entire machine to the end user. You pretty much guarantee thing will work. (yes this is oversimplified)
And storing the source and such for every dependency would be bigger than, and result in the same thing as an image.
Let’s flip that around.
The insanity that would be downloading and storing everything you need, wrapping it all up into a massive tarball and then shipping it to anyone who wants to use the end product, and also by the way assuming that everything you need in order to rebuild it will always be available from every upstream source if you want to make any changes, is precisely what Docker does. And yes, it’s silly to trust that everything it’s referencing will always be available from whoever’s providing it.
(Also, security)
Docker is like installing onto an empty computer then shipping the entire machine to the end user.
Correct. Because it’s not capable enough to make actually-reproducible builds.
My point is, you can do that imaging (in a couple of different ways) with Nix, if you really wanted to. No one does, because it would be insane when you have other more effective tools that can accomplish the exact same goal without needing to ship the entire machine to the end user. There are good use cases for Docker, making it easy to scale services up as was the original intent is a really good one. The way people commonly use it today, as a way to make reproducible environments for ease of one-off deployment, is not one. In my opinion.
I’ve been tempted into a “my favorite technology is better” pissing match, I guess. Anyway, Nix is better.
I might just start bundling my apps inside an environment setup with nix inside docker. A lot of them are similar to identical, So those docker images actually share a lot of layers under the hood.
My apps after compiling and packaging are usually around 50mb. That’s 48mb of debian, which is entirely shared between all the images that I build. So the eventual size of my deployed applications isn’t nearly as big as they seem from the size of the tarball being sent around. So for 10 apps, that’s not 500mb, that’s 68mb.
If anything, the docker hub and registry are a bit of a mess.
The issue is, nix builds are only guaranteed to be reproducible if the dependencies don’t change. Which they shouldn’t, but you can’t trust the internet to be consistent. Things won’t be there to be fetched forever.
Images do. And you can turn one into a container in seconds. I suppose it’s a matter of preference. I like one a package to be independent
Dude, this is exactly why Nix is better. Docker builds are only guaranteed to be reproducible if the dependencies don’t change. Which they will. The vast majority of real-world Dockerfiles do
pip install,wget, all kinds of basically unlimited nonsense to pull down their dependencies from anywhere on the internet.Nix builds, on the other hand, are forbidden from the internet, specifically to force them to declare dependencies explicitly and have it within a managed system. You can trust that the Nix repositories aren’t going to change (or store them yourself, along with all the source that generated them and will actually produce the same binaries, if you’re paranoid). You can send the flake.nix and flake.lock files and it will actually work to reproduce a basically byte-identical container on the receiver’s end, which means you don’t have to send multi-gigabyte “images” in order to be able to depend on the recipient actually being able to make use of it. This is what I was saying that the whole thing of needing “images” is a non-issue if your workflow isn’t allowing arbitrary fuckery on an industrial scale whenever you are trying to spin up a new container.
I suspect that making a new container and populating it with something useful is so trivial on Nix, that you’re missing the point of what is actually happening, whereas with Docker you can tell something big is happening because it’s such a fandango when it happens. And so you assume Docker is “real” and Nix is “fake” or something.
Yes, me too, which is why an affinity for Docker is weird to me.
That, I do not. And storing the source and such for every dependency would be bigger than, and result in essentially the same thing as an image.
I think you’re trying to achieve something different than what docker is for. Docker is like installing onto an empty computer then shipping the entire machine to the end user. You pretty much guarantee thing will work. (yes this is oversimplified)
Let’s flip that around.
The insanity that would be downloading and storing everything you need, wrapping it all up into a massive tarball and then shipping it to anyone who wants to use the end product, and also by the way assuming that everything you need in order to rebuild it will always be available from every upstream source if you want to make any changes, is precisely what Docker does. And yes, it’s silly to trust that everything it’s referencing will always be available from whoever’s providing it.
(Also, security)
Correct. Because it’s not capable enough to make actually-reproducible builds.
My point is, you can do that imaging (in a couple of different ways) with Nix, if you really wanted to. No one does, because it would be insane when you have other more effective tools that can accomplish the exact same goal without needing to ship the entire machine to the end user. There are good use cases for Docker, making it easy to scale services up as was the original intent is a really good one. The way people commonly use it today, as a way to make reproducible environments for ease of one-off deployment, is not one. In my opinion.
I’ve been tempted into a “my favorite technology is better” pissing match, I guess. Anyway, Nix is better.
I might just start bundling my apps inside an environment setup with nix inside docker. A lot of them are similar to identical, So those docker images actually share a lot of layers under the hood.
My apps after compiling and packaging are usually around 50mb. That’s 48mb of debian, which is entirely shared between all the images that I build. So the eventual size of my deployed applications isn’t nearly as big as they seem from the size of the tarball being sent around. So for 10 apps, that’s not 500mb, that’s 68mb.
If anything, the docker hub and registry are a bit of a mess.