Hi, I am one of the quorum of maintainers. Any questions welcome. Feel free to drop by our matrix channel #stagex:matrix.org for feedback or questions any time as well!
or #stagex IRC channel on OFTC
Stagex – Container-native, full-source bootstrapped, and reproducible toolchain
11–17 of 17 posts
Re: Stagex – Container-native, full-source bootstrapped, and reproducible toolchain
#12Why shoehorn Docker into this as a build sandbox instead of writing an alternative package set for Nix?
Re: Stagex – Container-native, full-source bootstrapped, and reproducible toolchain
#13Why 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".
Re: Stagex – Container-native, full-source bootstrapped, and reproducible toolchain
#14Why 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-sn…
Check the more recent comparison here https://codeberg.org/stagex/stagex/#comparison
Re: Stagex – Container-native, full-source bootstrapped, and reproducible toolchain
#15Why shoehorn Docker into this as a build sandbox instead of writing an alternative package set for Nix?
Because nix is not fully reproducible, full source bootstrapped, or multisigned. See my other comment on comparison to Nix.
Entirely different threat model.
The OCI spec supports multisig, multiple build engines, multiple registry engines, which are a major benefit of using standards.
You can even both build and export to OCI images with shell scripts.
Re: Stagex – Container-native, full-source bootstrapped, and reproducible toolchain
#16Why shoehorn Docker into this as a build sandbox instead of writing an alternative package set for Nix?
Because nix is not fully reproducible, full source bootstrapped, or multisigned. See my other comment on comparison to Nix. Entirely different threat model. The OCI spec supports multisig, multiple build engines, multiple registry engines, which are a major benefit of using standards. You can even both build and export to OCI images with shell scripts.
> Because nix is not fully reproducible, full source bootstrapped, or multisigned.
You've conflated Nix and Nixpkgs. My suggestion was to use Nix as your build engine, not to base your system on the existing packages in Nixpkgs. You'd still build your own complete package set, like you're doing already. Using Nix would give you a build sandbox that is purpose-built for deterministic builds, and you won't have to work around the troubles of Docker, which is not designed for that. I'm sure you must be aware that it's effectively impossible to reproduce a Docker image bit-for-bit when building from a regular Dockerfile, and I'm sure you've had to come up with some nasty hacks to work around all that. You could also use Nix's built-in store path signing feature, which does support multiple signatures.
Re: Stagex – Container-native, full-source bootstrapped, and reproducible toolchain
#17Earlier quoted context omitted.
Because nix is not fully reproducible, full source bootstrapped, or multisigned. See my other comment on comparison to Nix. Entirely different threat model. The OCI spec supports multisig, multiple build engines, multiple registry engines, which are a major benefit of using standards. You can even both build and export to OCI images with shell scripts.
> Because nix is not fully reproducible, full source bootstrapped, or multisigned. You've conflated Nix and Nixpkgs. My suggestion was to use Nix as your build engine, not to base your system on the existing packages in Nixpkgs. You'd still build your own complete package set, like you're doing already. Using Nix would give you a build sandbox that is purpose-built for deterministic builds, and you won't have to work…
Docker, Kaniko, Buildah, and Podman can all produce bit for bit reproducible OCI images without any hacks for more than a year now. (Docker itself was last to the party here)
I do not think we gain anything using the nix format, but we would lose a lot of compatibility with the huge ecosystem of container-native build systems and infrastructure.