Anton Livaja
d@nny disc@ mc²this is the only project that i think even remotely gives a shit about doing container-based bootstrapping right https://mastodon.social/@lrvick/115971880005974213 what everyone else is pretending to be
guix and mes make it possible ofc
too bad about LLVM. i'm gonna help make gccrs happen to push my own bootstrappable cinematic universe
Lance R. Vick@hipsterelectron Too bad about LLVM? Gcc is absolutely still in tree and you can use it, but it is hard to beat the cross compiling capabilities of LLVM.
@hipsterelectron In the spirit of never taking choices away, we made sure to still expose several different toolchain combinations in our "pallets" making it easy to swap toolchains depending on what you are doing:
https://codeberg.org/stagex/stagex/src/branch/main/packages/pallet
@hipsterelectron Also of note we don't use guix at all, but we do use mes today. That said I don't expect we will need mes much longer as M2Planet and M2Libc will likely be able to directly build tinycc soon the way things are progressing.
@lrvick will be super interested to see that followup to the mes achievement. so many things want to achieve that root of trust and being able to swap it out is a very powerful demonstration
@lrvick i'm pretty sure your work here allows me to consider the full-source bootstrap problem solved to a sufficient degree which means i can focus on easier problems
@lrvick kind of a strong statement but that's kind of what i'm hoping. seeing swappable toolchains done all the way up and down is crazy future stuff
@hipsterelectron That is really encouraging for us to hear as that was our intent.
Talos Linux just uses stagex/bootstap-stage3 to bootstrap their own distro directly, and that is exactly why we made bootstrap its own thing.
I don't want people to have to re-invent these wheels again because there are like 20 people on the planet that really care about this stuff and they should focus on the layers not solved yet.
@hipsterelectron Also speaking of crazy, there has already been work towards doing the bootstrap in RISC0 so we could have a zero knowledge proof of bootstrap that would be easy to verify on a wide range of hardware.... stay tuned :D
@lrvick i just think the project is annoying on a personal level (llvm)
@lrvick great great great to hear gcc swappability is achieved here. i am literally just an llvm hater and won't use it unless someone pays me lol
@lrvick i am currently deliberating on a project with a different set of goals atm which may end up encoding more of a gcc dependence but that's absolutely not a decision i'd propagate to my users
Ted Mielczarek@hipsterelectron ooh, interesting!
@tedmielczarek i have so badly wanted to see anyone back up the supply chain security discussion with tech that meets the need. one thing that i believe @lrvick and i agree on is that the user needs to have maximum flexibility prioritized and engineered at all levels so no one toolchain or protocol can be wielded as a tool of political control
@tedmielczarek @lrvick i see analogies to the conception of "swappability" i've recently been trying to codify https://circumstances.run/@hipsterelectron/115910457108221095
d@nny disc@ mc² (@[email protected])
@[email protected] byte-level provenance is related to swappability which is a stronger form of reproducibility than the existential proof that checksum reproducibility provides and requires semantic knowledge of the input so you can deconstruct and modify it programmatically as spack achieves with the spec language