If you want minimal deterministic containers with low complexity and high supply chain integrity, check out stagex, which is a distro purpose built for this problem: https://codeberg.org/stagex/stagex
Some of the ways it compares to nix/guix is included as a table in the readme.
Nix has been a great boon for my workstation. I can effectively stage changes before going through with them, and rollback is quite simple too. It is great to have an immutable environment with which to test changes upon.
> Iaso explained that layer ordering is "an illusion" that doesn't actually impact the functionality of the image (unless one layer overwrites a file provided by another layer), and that Nix picks an arbitrary order.
Wat?
Occasionally this is the entire purpose of a layer.. is it true it's unreliable? Or only non-deterministic under Nix? I thought deterministic builds are a huge selling point with Nix (admittedly, I haven't tried it yet, because intimidated and my existing tools don't irk me enough to bite the bullet.. yet).
I didn't attend the talk, but Nix's dockerTools doesn't need to worry about layer ordering because there is no chance of a layer overwriting another (most layers just write to their respective /nix/store/hash-pkgname directories, which is guaranteed to be unique by Nix).
You're right! All layers except the topmost layer consist of non-overlapping store paths. It's not one-path-per-layer as there's a hard limit on number of layers, so we smush the packages "deeper" in the dependency tree together within a single layer. There was some work recently where you could specify which paths should correspond to which layers but I can't recall the exact function.
You do have the ability to add a "customisation" layer on top of your image in case you want to create some directories or run arbitrary modifications which does end up as an extra layer which _can_ override the previous layers hence it's always the topmost. But you usually don't need it.
Source: I did a large-ish refactor to the `buildLayeredImage` functions a couple of years ago. My contribution was adding a `streamLayeredImage` function where you can "stream" a derivation to a Docker image on-the-fly without copying any files/layers in the disk.
Nix puts images together in a way that there shouldn't be any overwriting, only additions. If your layers are all additions without any overwriting then the order would be unimportant.
There could be some edge cases I'm not aware of, but from what I know, it should be all additions.
Some of the ways it compares to nix/guix is included as a table in the readme.