<OriansJ>janneke: well we could skip compression for the initial bootstrap binaries and then add it only after we could build it <civodul>janneke: i think weinholt has an R6 implementation of gzip, if that's an option <OriansJ>xentrac: The Loko scheme compiler certainly looks interesting however I haven't had the chance or time to figure out it's bootstrapping requirements nor if it is able to compile/interpret MesCC as those would be the big 2 to know about. <OriansJ>Hagfish: I look forward to see it running on real hardware, especially when RISC-V with ECC is available in the sub-$300 range (dropping $3K just isn't in most people's budgets) <xentrac>OriansJ: yeah, I think those are interesting questions but I don't know either <OriansJ>xentrac: plus it wouldn't hurt for us to find ways of making MesCC even faster <xentrac>one of the interesting things about Loko from my point of view is the possibility of running on "bare" hardware rather than on an OS <xentrac>as long as we're bootstrapping on an OS, the OS can backdoor us and otherwise interfere with reproducibility <OriansJ>xentrac: well stage0 up to M2-Planet doesn't depend upon an OS and has atleast 1 implementation that runs on bare hardware (no bios or firmware) <OriansJ>So adding a OS that is buildable via M2-Planet or below is part of the current plans <OriansJ>xentrac: gio already has a bootstrap to M2-Planet for x86 (on the bios level if I remember correctly) <OriansJ>with that we can straight build a valid posix in a reduced C subset; test and debug until we are happy and then do a switch to a M2-Planet build and thus eliminate that potential problem. <xentrac>boot2c is for bios, loko is for multiboot ***ng0_ is now known as ng0
<OriansJ>xentrac: unfortunately both suffer from the file-system bootstrap problem and that is one of those things we need to work out a solution for. <warren>I'm curious does anyone know how Guix's rust was bootstrapped if mrustc works on only x86_64? <warren>they list i686 x86_64 and armhfp as being available for rust 1.37 <warren>wondering how they bootstrapped armhfp as AFAIK mrustc doesn't work there <civodul>Guix targets armhf, and i *think* that chain works there too <xentrac>OriansJ: what is the file-system bootstrap problem? <warren>civodul: this lines up with my understanding that mrustc only works on x86_64 *vagrantc waves to warren <warren>LOL, I was just told to stop worrying about upstream's rustc bootstrap because somebody already proved mrustc bootstrap can lead to a binary identical rustc as that build from upstream's bootstrap. <vagrantc>mrustc installs on guix on armhf, but not substitute available for rust itself, building <warren>vagrantc: are you a Guix developer? I haven't tried it myself yet but I do need to learn Guix. Bitcoin soon moves to all official builds in Guix. <vagrantc>warren: they're foolish enough to let me push commits without review :) <warren>vagrantc: most projects do the best they can with whatever volunteers willing to work on it <vagrantc>warren: i gave a talk at debconf last year "My Crush on GNU Guix" so i've been experimenting :) <warren>For the last several years Bitcoin builds had been with a tool called Gitian which installed the same Ubuntu LTS chroot to make reproducible output. It uses a glibc and libstdc++ compat wrapper so binaries can work on earlier Linux ditsros https://github.com/bitcoin/bitcoin/tree/master/src/compat. It also cross-compiles deterministic binaries to Win64 and OSX. But of course this isn't safe because it's blindly trusting whatever is in Ubuntu. <warren>xentrac: hi, where do we know each other from? <xentrac>I was just thinking about you and #acetarium yesterday <warren>xentrac: I left #acetarium a few years ago because it seemed the original people abandoned it <xentrac>you and I were the people mad liked to attack <xentrac>blindly trusting what was in Ubuntu at some past point seems safer than blindly trusting Ubuntu forever <xentrac>but Guix does seem like a big improvement! <warren> https://github.com/bitcoin/bitcoin/tree/master/contrib/guix <--- Bitcoin wants to move to Guix-based builds. With the same glibc/libstdc++ wrappers the binaries work on many distros. Linux builds already work. They are close to mingw Win64 builds working. Somebody else has to redo the OSX cross compile. After that Bitcoin can abandon the Ubuntu-based build system. <warren>OSX is kind of screwed because it can only work by importing a gigantic binary blob from the Apple SDK. Apple users are screwed no matter what. At least the rest of the build system isn't introducing *more* attack vectors. <xentrac>really? you can't build a Mach-O binary that MacOS will load without a gigantic binary blob? <vagrantc>warren: is there some simple test case for mrustc on armhf? <warren>vagrantc: "build a working rustc that passes its own tests ... and that successfully builds the next rustc that passes its own tests". There had been weird bugs where the next bootstrap is broken! <warren>xentrac: I dont know the OSX details <vagrantc>warren: ok, running a test build now ... <warren>vagrantc: building rust 1.19 right? <vagrantc>warren: for starters ... and then 1.20, etc. <vagrantc>for self-hosting languages, that's kind of the only way to do it... <warren>I read all the links in /topic. How close is stage0 from being able to bootstrap stuff that leads into gcc-2.95?