Comment by onedognight
2 years ago
Rebuilding the minimal ISO from source is an impressive milestone on the journey to a system that builds from source reproducibly. Guix had an orthogonal but equally impressive milestone on the same journey recently[0], bootstrapping a full compiler toolchain from a single reproducible 357 byte binary without any other binary compiler blobs. These two features may one day soon be combined to reproducibly build a full distribution from source.
[0] https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
That is amazing and it is great to see there are people out there fighting the good fight (while others ask: "but where's the benefit!? if there's a backdoor, everybody is still going to get the backdoor!").
> it gives us a reliable way to verify the binaries we ship are faithful to their sources
That's the thing many don't understand: it's not about proving that the result is 100% trustable. It's about proving it's 100% faithful to the source. Which means that should monkey business be detected (like a sneaky backdoor), it can be recreated deterministically 100% of the time.
In other words for the bad guys: nowhere to run, nowhere to hide.
To me, the largest benefit isn't even related to "bad guys", but rather in being able to understand and debug issues.
Reproducibility makes bugs more shallow. If hydra builds a bit-for-bit identical iso to what you build locally, that means a developer can make a change to the iso inputs, test it, and know that testing will also apply to the final ci-built one.
If a user reports a bug in the iso, and you want to test if a change fixes it locally, you can start from an identical source-code commit as the iso was built from, make some minimal changes, and debug from there, all without worrying that you're accidentally introducing unintended differences.
It minimizes "but it works on my machine" type issues.
Super clarifying, thank you.
It's not yet as far as the Guix stage0, but there was an interesting talk about bootstrapping nix from TinyCC at NixCon: https://media.ccc.de/v/nixcon-2023-34402-bootstrapping-nix-a...
357 bytes for bootstrap compiler binary is VERY impressive!
If I remember correctly, this tiny binary is used to (reproducibly) bootstrap the next binary, which bootstraps the next binary, until eventually GCC can be compiled (and compile other software).
The bootstrap chain is https://github.com/oriansj/stage0-posix-x86/blob/e86bf7d304b...
To be fair, it is 357 bytes ... plus a POSIX operating system.
Still, that POSIX operating system bit is also being worked on.
Isn't that what builder-hex0 does?
https://github.com/ironmeld/builder-hex0
At 357 bytes, do you need a reproducible binary at all?
I'd think one could hand-document all 357 bytes of machine code and have them be intelligible.
This[0] is basically the hand-documentation of those bytes then. Handwritten ELF header and assembly code.
[0] https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX...
Just had a read of this to see what it did... And I must admit, I don't understand what purpose this is supposed to serve.
All it seems to do is convert hex into binary and dump it to a file. Not sure how that's any more useful than just copying the binary for next stage directly, after all this binary had to get on the system somehow.
5 replies →
That’s just the first stage. Simple enough to be audited manually.
Or tattooed on oneself! Or etched on a dog tag!
Nix is a great dog name
1 reply →
> bootstrapping a full compiler toolchain from a single reproducible 357 byte binary without any other binary compiler blobs.
wtf that is mind-boggling. Thanks for the link.
Classic HN, the top comment in a Nix post is about Guix.
Nix has more packages and advocacy (even if the vast majority of people exposed to nix/guix will never actually use it), but Guix is a lot more interesting to me with the expressive power of scheme on offer.
That said, there are some sharp edges[0] that seem a bit harder to figure out (is this just as inscrutable/difficult as nix?).
Does anyone have some good links with people hacking/working with guix? Maybe some blogs to follow?
I care more about the server use-case and I'm a bit worried about the choice of shepherd over something more widely used like systemd and some of the other libre choices which make Guix what it is. Guix is fine doing what it does, but it seems rather hard to run a Guix-managed system with just a few non-libre parts, which is a non-starter.
Also, as mentioned elsewhere in this thread, the lack-of-package-signing-releases is kind of a problem for me. Being source and binary compatible is awesome, but I just don't have time to follow the source of every single dependency... At some point you have to trust people (and honestly organizations) -- the infrastructure for that is signatures.
Would love to hear of people using Guix in a production environment, but until then it seems like stuff like Fedora CoreOS/Flatcar Linux + going for reproducible containers & binaries is what makes the most sense for the average devops practitioner.
CoreOS/Flatcar are already "cutting edge" as far as I'm concerned for most ops teams (and arguably YAGNI), and it seems like Nix/Guix are just even farther afield.
[EDIT] Nevermind, Guix has a fix for the signature problem, called authorizations![1]
[0]: https://unix.stackexchange.com/questions/698811/in-guix-how-...
[1]: https://guix.gnu.org/manual/devel/en/html_node/Specifying-Ch...
> Does anyone have some good links with people hacking/working with guix?
We've just had a conference about Guix in HPC: https://youtu.be/dT5S72x18R8
This is a recording of a stream for the second day with talks about large scale deployments of Guix System in HPC.
Thanks for this! Going to give it a watch :)
How long does a fully bootstrapped build take?
It obviously depends on the hardware, but IIRC for me maybe 3-4 hours building from the 357 byte seed to the latest GCC.
The early binaries are not very optimized :-)
With caching, just the time to download the artefact.
Doesn't caching completely defeat the point of bootstrapping? How do you know the cached artifact is correct? You have to build it manually to verify that, at which point you're still building manually...
3 replies →