hackernews-docker-challen VS nix-snapshotter

There's not much else that can be done here. glibc is the next largest dependency at ~30MB. This large size seems to be because Nixpkgs configures glibc to be built with support for many locales and character encodings. I don't know if it would be possible or practical to split these files out into separate derivations or outputs and make them optional that way. If you're using multiple images built by dockerTools.buildLayeredImage, glibc (and everything else) will be shared across all of them anyway (given you're using roughly the same Nixpkgs commit).

https://github.com/max-privatevoid/hackernews-docker-challen...

Why does the "Comparison" table show "Nix" as "No" for "Containerized"? One can [run Nix in containerized environments](https://nix.dev/manual/nix/2.24/installation/installing-dock...), [build containerized environments from Nix](https://nix.dev/tutorials/nixos/building-and-running-docker-...), and [even run Nix-generated environments directly in containerd through a plugin](https://github.com/pdtpartners/nix-snapshotter/blob/main/doc...). I believe the former two apply to Guix as well which is also marked as "No" for "Containerized".

Not super recent, but nix-snapshotter is one that I'd call awesome(but I'm also a k8s fanboi): https://github.com/pdtpartners/nix-snapshotter

https://news.ycombinator.com/item?id=37407758

Excellent info! I started head-deving a project similar to nix-snapshotter[0] and I was thinking "ok, I can probably just build CRI impl that builds a rootfs dir with nix and just shell out to bubblewrap to make a "container".

But once I went through that mental exercise I started reading code in containerd and cri-o. Wow, these are _not_ simple projects; containerd itself having a full GRPC-based service registry for driving dynamic logic via config.

One thing I was pretty disappointed about is how deeply ingrained OSI images are in the whole ecosystem. While you can replace almost all functional parts of runtime, but not really the concept of images. I think images are a poor solution to the problem they solve, and a big downside of this is a bunch of complexity in the runtimes trying to work around how images work (like remote snapshotters).

[0] https://github.com/pdtpartners/nix-snapshotter

Does anyone here have any experience using https://github.com/pdtpartners/nix-snapshotter ?

I build a lot of Docker images using Nix, and while yes it’s generally more pleasant than using Dockerfiles, the 128 layer limit is really annoying and easy to hit when you start building images with Nix. The workaround of grouping store paths makes poor use of storage and bandwidth.