I think radically building the entire image in Nix and only streaming the result may magically fix the cache cost incurred on update (because nix already knows how to) and also results in single-layer minimal images. Single-layer is just more efficient. Oh, and also it keeps all things declarative (the SBOM output can be declarative, as opposed as accidentally being back to imperative because of … well that’s the nature of the copy command in Dockerfiles
Excellent talk nonetheless. Even if the end-result doesn’t yet look optimal to me, one thing this does in a way that would otherwise not happen, is to highlight the difference in paradigm/mindset between the two ecosystems. It was highly enlightening to me in that way.
The shim is project agnostic. To use it with a python application you simply need to figure out how to build\package it with nix. The shim simply copies what you built with nix into a single layer container image
Maybe I missed something, but this embrace looks more like the MS way of doing things in the 90s.. Is it truly a strategic partnership? I don't clearly see what docker brings to the table, I only see docker pre-emptively adopting Nix's philosophy [storing declaratives, not images] in an effort to improve container management and also, before Nix eats docker's lunch???
@@hera9191Precisely. Which is why I’d say DON’T use the shim. Don’t reimplement nix store in docker’s layer system. Just build the entire image in nix and stream it into a single layer for podman, docker or whatever target container runtime you need
I worked with MS in the 90s and have no idea what you're talking about. They had nothing like this. There is more to running containers than the build process, so I wouldn't recommend throwing out the shim too quickly.
So basically, docker is just taking all the goodness of nix and putting it in docker? so why do i need/want docker again? i don't see what docker is bringing to the table here (aside from a glorified nix wrapper).. Nix with Docker branding/labelling. Okaaaay.. Maybe Docker should consider a re-branding. Here's some suggestions: "Wrapper", "Draper", " "Docker"?"..., "UnDocker", "NoDocker", 'Nix'Docker", "NixLocker"..., "Hocker", "Stocker", "Nocker"... "Doc-Blocker"...
I think radically building the entire image in Nix and only streaming the result may magically fix the cache cost incurred on update (because nix already knows how to) and also results in single-layer minimal images. Single-layer is just more efficient. Oh, and also it keeps all things declarative (the SBOM output can be declarative, as opposed as accidentally being back to imperative because of … well that’s the nature of the copy command in Dockerfiles
Excellent talk nonetheless. Even if the end-result doesn’t yet look optimal to me, one thing this does in a way that would otherwise not happen, is to highlight the difference in paradigm/mindset between the two ecosystems. It was highly enlightening to me in that way.
Much love brother!
this is what I was looking for, amazing.
Neat. Where can I find a working example of the “shim” file for python?
The shim is project agnostic. To use it with a python application you simply need to figure out how to build\package it with nix. The shim simply copies what you built with nix into a single layer container image
that's right! The shim should work for any nix project
32:08 wow, interesting to see that python app comparison > size is more on nix w.r.t debian+layers
Maybe I missed something, but this embrace looks more like the MS way of doing things in the 90s.. Is it truly a strategic partnership? I don't clearly see what docker brings to the table, I only see docker pre-emptively adopting Nix's philosophy [storing declaratives, not images] in an effort to improve container management and also, before Nix eats docker's lunch???
Docker brings here runtime containerisation and also image management. While Nix brings creating environments.
You are 100% right, docker is not needed when nix is done right.
@@hera9191Precisely. Which is why I’d say DON’T use the shim. Don’t reimplement nix store in docker’s layer system. Just build the entire image in nix and stream it into a single layer for podman, docker or whatever target container runtime you need
I worked with MS in the 90s and have no idea what you're talking about. They had nothing like this.
There is more to running containers than the build process, so I wouldn't recommend throwing out the shim too quickly.
@@mabainter i was referring to MS way of dealing with competing technologies born in the 90’. Triple-E, embrace, extend and extinguish.
So basically, docker is just taking all the goodness of nix and putting it in docker? so why do i need/want docker again? i don't see what docker is bringing to the table here (aside from a glorified nix wrapper).. Nix with Docker branding/labelling. Okaaaay.. Maybe Docker should consider a re-branding. Here's some suggestions: "Wrapper", "Draper", " "Docker"?"..., "UnDocker", "NoDocker", 'Nix'Docker", "NixLocker"..., "Hocker", "Stocker", "Nocker"... "Doc-Blocker"...
Nix > AI, you heared it here first
I hate both equally