<oriansj>Melg8: the only strategy I have seen work for bootstrapping is take the most advanced language you have and use it to make something much more advanced as quickly as possible and then start using that new more advanced language to bootstrap the next language that will replace it. <oriansj>hex0 -> hex1 (huge improvement in dealing with loops and function calls) -> hex2 (huge improvement in dealing with global variables) -> M0 (huge improvement in readablity) -> cc_* ( major leap in ease of programming) -> M2-Planet ( major improvement in debugging) <Melg8[m]>oriansj: can you once again explain to me what is idea behind emulator? so you want to use it to be compiled by non-trusted compiler + use non-trusted make + all that on top of some kernel program - and use it across different runners with different compiler/make/kernels? so it will trigger inconsistencies if something try to insert some malicious code? or am i hallucinating? if yes (or kinda yes) than how it would build more difficult to <Melg8[m]>build stuff - like non single source non single outup files (like gcc + libs)? <oriansj>vagrantc: libera.chat got the most approve votes and no reject votes, so it won <vagrantc>ok, so no need to change any of my configurations :) <oriansj>Melg8: if you mean the knight emulation in stage0, that is just to enable a bare metal development for a hardware architecture I plan on building in individual gates. <Melg8[m]>than how and will it be glued together? because in stage0-posix kaem glue all steps together - so no manual work required to scale this process to 20 different targets in ci if we like to. <oriansj>or if you mean the cross-platform capabilities of M2-Planet+mescc-tools then it means that any single trusted architecture can be used to detect a compromise in any hardware platform. As all architectures can reproduce identical binaries for all targets. <oriansj>So x86 can be used to detect compromises for AArch64, armv7l, AMD64, knight (powerpc too when I finish doing that work) and all of those systems can also be used to detect compromises on the x86 hosts as well. <oriansj>And once I do knight in individual gates, then any compromise for any other target know will show up instantly when we do a simple diff between the binary produced on the trusted system (knight) and the one produced on the target system. (Straight DDC but with even fewer assumptions [only depends on a single trust hardware platform and a single hex0-monitor seed]) <Melg8>but with that up until what binary program would be verified? ***copper.libera.chat sets mode: +o janneke
***ChanServ sets mode: +o oriansj
<oriansj>Melg8: well that would be everything that M2-Planet can build. As I am not certain about what MesCC can do in regards to cross-platform builds. And various other pieces in regards to their portability. <oriansj>But that is certainly that could be addressed to a level which extends much further if the work required was performed. <Melg8[m]>not rule, but lack of support of >256 arguments/ <Melg8[m]>cool! so, will you lead this migration to new mes? when it will arrive? <stikonas>Melg8[m]: well, first of all we need to switch to new m2libc based workflow <stikonas>and it might already have newer mes, I haven't checked <stikonas>I started moving live-bootstrap to m2libc <stikonas>and first blocker that I encountered was mescc-extra-tools ***pritambaral is now known as prite
<fossy>stikonas: yeah, I need to rewrite mescc-tools-extra to use m2libc <mitzman>hmm, I was reading a bit about the bootstrapping process, and came up across this: "The Guix bootstrap for x86_64 uses x86 mes and that is not expected to change.". i also saw that x86_64 mes is on its way. would that mean guix will have the possibility to be bootstrapped with the x86_64 mes?