| 9 Jun 2025 |
 raboof | IIRC it was also not super easy to trigger | 10:50:07 |
 Grimmauld (any/all) | i mean, ibus triggers it | 10:51:28 |
| Grimmauld (any/all) | the goal is to find something minimal that triggers it | 10:51:40 |
| Grimmauld (any/all) | and this was just a naive blind guess to see if it was easy, and turns out that no it isn't | 10:52:00 |
| raboof | right, but iirc ibus needs a fair number of rebuilds to actually hit the problem | 11:15:47 |
 fricklerhandwerk | The main chunk of work happened in 2023 here: https://github.com/NixOS/nixpkgs/pull/227914
All of this stuff works now except cross-compiling GCC to 64 bit, which should merely involve setting the right flags | 11:39:05 |
| raboof | I'll admit it's not clear to me how all that works in practice ;) - would that allow us to create, say, a qemu disk image with only sources (and those 256b) on it that'd when 'booted' bootstrap itself to a functional shell? or is that not the idea? | 13:42:14 |
 Julien | I think the assumptions are: Nix + a running kernel + those 256b allows you to build all nixpkgs | 13:53:23 |
| Julien | Obviously the assumptions are broken at multiple places in nixpkgs when other binary blobs are downloaded | 13:53:50 |
 emily | in particular I believe the goal is to produce a bootstrap tools tarball from those | 13:59:01 |
| emily | that can replace the current "mystery meat" one | 13:59:11 |
| emily | so that the bootstrap tools could be audited more easily | 13:59:22 |
| raboof | wrt 'other binary blobs', ideally allowNonSource = false should help with that (assuming all such cases are properly marked, which is probably not fully the case ;) ) | 14:00:09 |
| emily | btw, there is non-Nix work on solving the "running kernel" part that goes through tiny bare metal kernels and something called "Fiwix" :) https://lwn.net/Articles/983340/ | 14:00:15 |
| Julien | interesting thanks ! | 14:00:32 |
| emily | (which makes me happy, since I always felt like the "running kernel" part made the whole exercise a little absurd) | 14:00:35 |
| emily | ("an existing Nix binary" has the same problem for our minimal bootstrap. it's still an improvement over the bootstrap status quo though, don't get me wrong) | 14:01:05 |
| emily | (but a true bootstrap starts before you have any fancy build coordinator to hand) | 14:01:20 |
| emily | (ofc ideally you get Nix going as soon as possible in that process :) ) | 14:01:29 |
| emily | anyway, yeah, the fundamental idea is that you have a tiny and auditable trusted binary seed, and then you can reproduce anything by "only" auditing that binary seed and a few millions of lines of code | 14:02:06 |
| emily | including, like, several patched old versions of GCC and stuff like that | 14:02:14 |
| emily | and really the distinction between 256 bytes of hand-written machine code and the next stage where they get to write it in hex with comments instead is not very "source vs. binary" IMO | 14:02:42 |
| emily | but the general principle is good, even if the bootstrap chain needs heavily trimming down to be practically auditable | 14:02:56 |
| raboof | I see guix similarly requires an existing kernel and guile for their bootstrap, so no opportunity to build nix from their bootstrap đŸ˜† | 14:05:17 |
| emily | yeah, though the Guix community has a lot of overlap with the work on things like ^ I think | 14:05:55 |
| emily | IMO, the ideal is that you get a nice purely-functional package manager running on something "simple" – say that Fiwix kernel | 14:06:18 |
| emily | that way you can optimize the more manual chain to get to Nix/Guix/whatever as short as possible and then the rest of the way you get to use the nice tool | 14:06:39 |
| Julien | Then we can go and bootstrap the hardware đŸ˜‡ | 14:24:31 |
| emily | first start with 256 transistors… | 14:25:58 |
| emily | eventually you'll get an automated chip factory that processes purely functional specifications | 14:26:27 |
