<unmatched-paren>a simplified graph of the current `tree' of compilers that have been bootstrapped starting from stage0 would be nice (maybe on a `Compiler Tree' page on the wiki?) <unmatched-paren>that way people could see at a glance what we've currently got... `unlocked'? <unmatched-paren>(and probably simplify it to only include compilers and maybe build systems) <unmatched-paren>and potential paths (does graphviz allow different colours for nodes and paths? never used it except with `guix graph') <unmatched-paren>so, we could have, say, tcc -> gcc or mrustc -> rustc in green (done), hugs -> ghc (or whatever the most viable path is looking like right now) in orange (potential path), APC -> FPC -> nim in blue (solution is being worked on but not done yet) and lone SML/NJ and MLton nodes in red (not bootstrappable, and nobody has yet found or created a path) <unmatched-paren>an exhaustive graph should probably have only one node per project instead of per program <oriansj>unmatched-paren: the reason it doesn't exist yet is rather simple. No one was willing to put in the effort to create it yet. <oriansj>but if you make a pull request with an update, it'll get merged. ***janus__ is now known as janus
<unmatched-paren>oriansj: ok, i'll read up on using graphviz and send a PR to add a full graph :) then we can add it to the wiki <unmatche1-paren>C, Make, Perl, Autotools, C++, Python, CMake, Ninja, Meson, Guile, Chez, MIT/GNU Scheme, Racket, CLISP, ECL, SBCL, Raku, D, Pascal, Nim, Go, Rust, Haskell, Idris, OCaml, Zig, C#, F#, SML, Fortran, Ada, Java, Groovy, Scala, Kotlin, Gradle, and Clojure. <unmatche1-paren>the graph should have every notable language or build system that we know of in existence, even if it's trivial to bootstrap <unmatche1-paren>it's intentionally simplified, especially at the live-bootstrap parts <unmatche1-paren>since there's already graphs of that bit, and it's quite large and complex (e.g. it shows four musls) <bauen1>i'm a bit surprised the linux kernel doesn't depend on perl, python or something like that, surely there are some scripts that get executed during build ? <bauen1>or is it all bash + awk + grep, coreutils ? <unmatche1-paren>bauen1: you are apparently correct, according to gnu/packages/linux.scm in guix <unmatche1-paren>the whole graph completely changes its layout when you make a tiny modification like this :) <unmatche1-paren>there's probably many languages i'm missing that i can't think of off the top of my head <bauen1>is there any plan on making a more detailed graph ? e.g. where each node describes a "build recipe" including versioned dependencies and a link to the repo where the build is implemented ? that would probably be massive <unmatche1-paren>and... now i get a not found when trying to click to the large version? <unmatche1-paren>ok, it seems to be working now. you'll probably need to clear your browser's cache to see the new version <bauen1>unmatche1-paren: nope, no problem here no cache cleaning necessary *unmatche1-paren sobs quietly <unmatche1-paren>since its sole purpose is to write apps for Apple(R)(TM)(C)(C) devices ***unmatched-paren is now known as Guest8610
<oriansj>unmatche1-paren: stage0 doens't depend on linux, only stage0-posix does (which is just a port to simplify scripting the bootstap process) <muurkha>bauen1: that sounds like a thing that could be scripted <unmatched-paren>or, actually, change the `linux' node to point at `m2-mesoplanet' instead, which doesn't work without posix, right? <unmatched-paren>so is the idea that we build m2-planet to work on bare metal, then write a tiny kernel in m2 that can run mes etc? <oriansj>unmatched-paren: that is correct M2-Mesoplanet requires an operating system for the Environment and spawn behavior (which could be disabled with a custom cc.c file) and a minor detail Mes-m2 can be built by M2-Planet right now. The M2-Mesoplanet is about building mainline Mes (instead of running MesCC on Mes-M2) <unmatched-paren>how does it interpret .scm files if there's no such thing as a file? <stikonas>no, you would have to feed everything in one go then <unmatched-paren>but then by using the EFI implementation from the CPU vendor you get a whole lot of other trust issues :) <stikonas>well, same as m2-planet vs m2-mesoplanet <stikonas>and actuall without kernel it's not even a file <stikonas>you need so use simplified main() without command line arguments <unmatched-paren>so you modify them to read from a hardcoded constant string if you want them to run on bare metal? <stikonas>anyway, it's probablu not too important because why would you need to run it without kernel <oriansj>unmatched-paren: or from a serial port or paper tap ereader or etc <stikonas>so that people can run nice bootstrap chains without worrying too much about non-portable issues <oriansj>extremely hardware dependent but done in such a way stage0-posix and stage0 on bare metal should produce identical binaries given the same sources <stikonas>but a lot of people were interested in it <unmatched-paren>basically a shortcut until we can get it going from bare metal, if i understand right? <stikonas>e.g. let's say some distro wants to do bootstrapping from stage0 <oriansj>unmatched-paren: Less of a shortcut and more of a second root path to use <stikonas>they probably would just start with stage0-posix and build on top of that <stikonas>rather than each time manually kick off someting on baremetal <muurkha>right, reproducing the same binary means you don't need to worry your kernel intervened in your build process to introduce a backdoor <muurkha>although until you can build the kernel itself with m2-planet you still have to worry that it intervened *after* your build process <stikonas>so either all kernels are backdoored in the same way <oriansj>but a hardcore bootstrapper may wish to do the steps manually to provide a second root check against the stage0-posix binaries produced. <unmatched-paren>oh, yes, it's safe to use prebuilt binaries if the sha256sum is the same as a totally bootstrapped version <muurkha>right, although you need to not run the sha256sum on a potentially backdoored kernel <unmatched-paren>of course... once we get stage0 from bare metal, we'd need to start worrying about the CPU and BIOS itself, which is a whole other can of worms... <stikonas>unmatched-paren: the question is how do you trust your sha256sum then <oriansj>and then we need to do libre-silicon and other fun <stikonas>implementing trusting trust attack on sha256sum is probably harder than in the compiler <stikonas>actually it's not even relevant, since sha256sum does not produce output... <stikonas>so any backdoor would be non-propagating <oriansj>also we can dump binaries to paper tape or CDs or other media for inspection from offline validators and use those same dumped binaries for running <unmatched-paren>even if we built a completely audited CPU, 99% of the world will probably STILL go on using their intel or AMD chips with Microsoft Windows 11... :( <oriansj>unmatched-paren: one can not save a man who wishes to drink poison <muurkha>I think less than 30% of the world uses intel and AMD chips with Microsoft Windows 11 <unmatched-paren>muurkha: oh, i forgot that laptops are apparently considered to be outdated technology now by most people <stikonas>didn't look like that during covid lockdowns... 
