IRC channel logs
2022-07-28.log
back to list of logs
<oriansj>rkeene: only if we were without each other. It is way too big for any single individual but together: kicking ass and taking names and then giving those names to other bootstrapping problems after we kick their ass too. <stikonas>I'm now working on similar thing for amd64 <oriansj>thank you very much stikonas for helping make our bootstrap seeds smaller ^_^ <stikonas>that one might reduce a bit more since I have enough registers to store stuff like malloc, command_done and script <stikonas>and after that I think I can start working on kaem-optional-seed.efi <stikonas>kaem-optional-seed.efi will probably be over 1 KiB... <oriansj>stikonas: silly question but is the UEFI shell scriptable? <stikonas>e.g. on my laptop there is no UEFI shell, although UEFI has an option to start UEFI shell from bootable media <stikonas>oriansj: but it's far more limited in terms of scripting <stikonas>e.g. set command can show exit status of last command <stikonas>but I don't think there is anything like $? <stikonas>(based on my M1 file, I can reduce kaem-optional-seed by 200 bytes on amd64) <stikonas>anyway, I think we'll replace it with kaem-optional-seed.efi <stikonas>although the problem with kaem is that it is not interactive <stikonas>so stage0-uefi would be able to run, even build M2-Mesoplanet but then it will just exit <stikonas>(although compiled binaries can be inspected on some other system) <stikonas>anyway I mostly view UEFI shell as debugging aid <oriansj>well in the case they have the shell, just having a script there would remove one of our binaries and if not, our kaem-optional will fill that role nicely <oriansj>and thank you for making that option possible ^_^ <oriansj>not entirely but in comparison to our hex0 fun, yeah <stikonas>well, one just needs to somehow run hex0.efi kaem-minimal.hex0 BOOTX64.efi <stikonas>unfortunately you need either kaem or Shell to pass command line arguments <stikonas>well, there are some options to combine things into one binary... <oriansj>indeed, one could do a much more impresive hex0 monitor <stikonas>but having kaem and hex0 separate makes scripting nice and logical <pabs3>hmm, would be nice to merge bison-bootstrap into bison upstream, it seems small enough they might accept it. interesting its written by a Debian person :) <stikonas[m]>pabs3: bison bootstrap only works with a very specific version of bison <stikonas[m]>(You can of course use it tonbuilf other versions later) <muurkha>yeah, it wouldn't make sense to upstream changes to an ancient version of bison <pabs3>ah, I see. I was thinking it was for the current version of bison. I guess if it caught up to the current version then it could end up maintained upstream <muurkha>maybe, but the bison maintainers might not appreciate having to worry about whether they were introducing an incompatibility with a 25-year-old version of bison every time they made a change to bison's grammar <muurkha>they'd have to agree that deriving bison from pure source code was a worthwhile goal <pabs3>I feel like that would be aligned with the values of FSF/GNU so probably the bison folks would agree :) <pabs3>(although, there have been at least three occasions where GNU caused downstream GPL violations by not including source in their tarballs at all, so...) <muurkha>maybe at some point we can make that argument about value alignment to them, but it will be an easier sell once we have a whole reproducible bootstrap chain from bare metal <oriansj>pabs3: well even more cases of when one couldn't actually build the sources they distributed and everyone basically took the pregenerated crap <oriansj>muurkha: well we are 3 big pieces away from that goal; just need to build hurd with M2-Planet and then we can just call it one <oriansj>muurkha: well we have the bootstrap kernel already with boot2now; it is the linking kernel written in C that is missing (along with the ability to build a filesystem capable of building Linux) <Hagfish>maybe that's what's been holding back GNU/Hurd all this time... it was too easy of a challenge that no one bothered. but tell them to build it with M2-Planet and suddenly there'll be PRs coming in by the hour :) <oriansj>muurkha: after building Mes-m2 (as MesCC needs more kernel support than all of the previous parts put together) <oriansj>Hagfish: or a handful of pull requests on M2-Planet/M2-Mesoplanet (which is probably how far off of C-89 support we are in terms of C features) <Hagfish>i guess i was imagining a reinvigoration of the work on GNU/Hurd too, but i guess it doesn't matter from a bootstrapping perspective whether Hurd bootstraps Linux or vice versa <oriansj>muurkha: well we can easily build the scheme interpreter as M2-Planet/M2-Mesoplanet only use a handful of syscalls. The interpreter however has the ability to call a good deal more <mid-kid>I'm glad it's not too complicated but I wonder if it'd be a good idea to modify live-bootstrap so it can be used to build LFS without any modifications. <mid-kid>I also have some old notes on building gentoo from a chapter 7 LFS but it's been a while so I'll have to check them. <stikonas[m]>mid-kid: we'll get there eventually, first I think fossy wants to build python <stikonas[m]>python3 has some python generated headers or maybe parser <oriansj>I must say, the more I learn about kernels, the more I think capability kernels were the right idea at the wrong time. <muurkha>yeah, I think they're the right idea <muurkha>oriansj: I don't know that it was even the wrong time; maybe the dominance of the identity-based access control model was just random <muurkha>like qwerty keyboards: even if the alternative designs don't really offer the dramatic *improvements* Dvorak originally claimed for his design, surely nobody believes Qwerty is in any sense *optimal* <muurkha>there are other examples where one alternative or the other is clearly superior technically, but I don't want to offer them as examples because people disagree fervently about which alternative it is ;) <oriansj>muurkha: well thinking in terms of bad people is far easier than thinking in terms of badly behaving programs <muurkha>maybe it's safe to point out that Java has largely replaced COBOL in mainframe business data processing starting around 02008, and that almost certainly means either that people would have been better off writing a decent Smalltalk in the 01980s to replace COBOL, or that they are worse off now that they've switched to Java <muurkha>so clearly there is some kind of path dependency going on <muurkha>oriansj: maybe, yeah. but programmers have thought in terms of program behavior as long as there have been programmers <oriansj>well Java shared something special with COBOL that Smalltalk doesn't: there is no focus on distribution, distribablity, package management or administration but rather here download this Jar (binary blob) file and run it. <mid-kid><stikonas[m]> But without pregenerated files <- Ah yeah that's a major issue I guess <mid-kid>Though very few distros do debian's whole source-purity shtick so it's kind of out of the window once you build most distros unfortunately. <mid-kid>But for a pure-source bootstrap like this it's important. <stikonas>argh, messed up one thing in POSIX/x86/kaem-optional-seed.... <oriansj>stikonas: no worries I noticed you didn't update the comment with the name to kaem.x86 <stikonas>shouldn't have moved Exit_Failure function <stikonas>now on subprocess error it would exit with 0