5 ms·

This smaller bootstrap seed thing is a different problem from reproducible builds. nixpkgs does still have a pretty big initial TCB (aka. stage0) compared to Gu

This smaller bootstrap seed thing is a different problem from reproducible builds. nixpkgs does still have a pretty big initial TCB (aka. stage0) compared to Guix. But as far as I can tell NixOS has the upper hand in terms of how much can be built reproducibly (aka. the output hash matches across separate builds).

jnxx 5y ago
Bootstrapping from a very small binary core (I think 512 bytes) with an initial C compiler written in Scheme also has the advantage that the system can easily be ported to different hardware. Which is one major strength of the GNU projects and tools.
- delroth 5y ago
  Not necessarily. Usually these very small cores end up being more architecture specific binaries than a stage0 consisting of gcc + some other core packages. A good illustration of this is that Guix's work on bootstrap seed reduction has been so far mostly applied to i686/amd64 and not even other architectures they support (at least, not fully).
  - pxc 5y ago
    Does this still matter if you can work your way up to a cross compiler, though? Do you actually need to go all the way down to ‘native’ hex monitors for a bunch of architectures or whatever?
siraben 5y ago
There's an issue for this[0]. Currently Nixpkgs relies on a 130 MB (!) uncompressed tarball, which is pretty big compared to Guix. It would be amazing to get it down to something like less than 1 KB with live-bootstrap. Also, due to the way Nixpkgs is architectured, it also lets us experiment with more unusual ideas like a uutils-based stdenv[1] instead of GNU coreutils. [0] https://github.com/NixOS/nixpkgs/issues/123095 https://github.com/NixOS/nixpkgs/issues/123095 [1] https://github.com/NixOS/nixpkgs/pull/116274 https://github.com/NixOS/nixpkgs/pull/116274
pxc 5y ago
We can relate the two efforts as each project addressing an aspect of ‘trusting trust’ problems, albeit in different ways. Stage0 is awesome, and it'd be cool to see Nix's bootstrap seed shrink

jnxx 5y ago

Bootstrapping from a very small binary core (I think 512 bytes) with an initial C compiler written in Scheme also has the advantage that the system can easily be ported to different hardware. Which is one major strength of the GNU projects and tools.

delroth 5y ago
Not necessarily. Usually these very small cores end up being more architecture specific binaries than a stage0 consisting of gcc + some other core packages. A good illustration of this is that Guix's work on bootstrap seed reduction has been so far mostly applied to i686/amd64 and not even other architectures they support (at least, not fully).
- pxc 5y ago
  Does this still matter if you can work your way up to a cross compiler, though? Do you actually need to go all the way down to ‘native’ hex monitors for a bunch of architectures or whatever?

siraben 5y ago

There's an issue for this[0]. Currently Nixpkgs relies on a 130 MB (!) uncompressed tarball, which is pretty big compared to Guix. It would be amazing to get it down to something like less than 1 KB with live-bootstrap. Also, due to the way Nixpkgs is architectured, it also lets us experiment with more unusual ideas like a uutils-based stdenv[1] instead of GNU coreutils. [0] https://github.com/NixOS/nixpkgs/issues/123095 https://github.com/NixOS/nixpkgs/issues/123095 [1] https://github.com/NixOS/nixpkgs/pull/116274 https://github.com/NixOS/nixpkgs/pull/116274

pxc 5y ago

We can relate the two efforts as each project addressing an aspect of ‘trusting trust’ problems, albeit in different ways. Stage0 is awesome, and it'd be cool to see Nix's bootstrap seed shrink