IRC channel logs
2024-01-27.log
back to list of logs
<fossy>stikonas: i did a bit of investigating but i haven't got anywhere yet, did other things yesterday <fossy>I'm fairly positive that my UEFI treats strings in the format A-B specially <fossy>where A and B are any arbitary text <fossy>so i tried setting a couple of kaem values to different things <fossy>out of those, only -a and a- work, the other ones just become empty strings <fossy>i added a print() to the variable setting function in M2libc for uefi and --a had propagated through to that... <fossy>but when i added a print() to the variable getting function it showed it as empty <fossy>however oddly i couldn't reproduce the issue when using "set" builtin in UEFI shell <stikonas>so as far as I understand, those variables that kaem sets shouldn't be touched by UEFI... <fossy>yeah, shouldn't but are, oddly <stikonas>on my system I don't know how to use UEFI set to e.g. set them to \posix\paths but it works fine in kaem <fossy>apart from that, the super slow machine did fail at the same point, took a while; not sure how long, cause i just left it, but probably a bit over an hour? <fossy>compared to my laptop, which took 45 seconds <stikonas>yeah, something is very unoptimized on your one machine... <fossy>yes, i suspect there's no FS caching or something along those lines <fossy>it would be easy enough to do some kind of encoding to make the UEFI variables not include dashes, but that's a huge hack that I don't really love, gonna try and find out what the actual issue is <oriansj>so you think a M2libc bug for setting environment variables? <stikonas_>perhaps fossy's implementation does something a bit different... <oriansj>perhaps; or we might be assuming something about UEFI which might not always be true. <stikonas>last month I already spent a lot of time fixing stack alignment issues... <muurkha>oriansj: Forth could get by with two block buffers for multiple processes talking to multiple files because context switches are fairly rare events, maybe once every million instructions, so it's not a big deal if they cause two page faults <muurkha>I don't know if any Forth systems actually had only two block buffers but that's all the BLOCK interface definition guarantees you <muurkha>lrvick: congratulations! that's huge! <matrix_bridge><Lance R. Vick> muurkha: Now working on generating hashfiles and an easy workflow for people to build and then PR in signatures. Will release tars and container images once I get at least 3 build confirmation signatures. <matrix_bridge><Lance R. Vick> Takes about 1.5 days to build on 20 cores so it is not a small ask <matrix_bridge><Lance R. Vick> Hoping to make a case that these are drop in replacements for all the official docker containers from alpine and debian that build most of the universe right now, but with much higher supply chain integrity. <matrix_bridge><Andrius Štikonas> yeah, getting people to use stuff will be the hard part <Foxboron>How do they have "much higher supply chain integrity"? <oriansj>Foxboron: well right now most supply chains are here have this binary blob and trust me. And in the slightly better case, they also have: here is the source code we claim corresponds to that binary. <Foxboron>oriansj: I'm thinking of what Lance is currently working on <oriansj>well a reproducible build chain that is bootstrapped from stage0 is a huge improvement compared to that. <Foxboron>So he is reproducing debian and alpine from stage0 from scratch? <oriansj>Foxboron: Lance is doing reproducible system images bootstrapped from stage0 in docker; which others can then build upon <stikonas>he is just creating a different docker image that could be used as a base <Foxboron>So a limited bootstrap of Debian and Alpine, then. <Foxboron>I'm curious how the toolchain is bootstrapped though. Labeling it as a "drop in" replacement isn't necessarily trivial if the toolchains differ. <oriansj>Foxboron: well; that is a question Lance should be able to answer (but I am guessing a variation on live-bootstrap) <oriansj>the end result usually is the standard GNU build tools, compilers and interpreters; from which most software can be built from. <Foxboron>Which is where most of the work is, if the aim is Reproducible Builds. bootstrapping from stage0 is interesting, but ensuring things is reproducible beyond that is not trivial. <Foxboron>ah, wait. I see the repo is linked previously :p <Foxboron>lrvick: your numbers for Debian and Nix is wrong. Nix is only building ~600 packages and the actual reproduction of debian is closer to 80% <Foxboron>except they built an entire apk compatible package manager on top of the OCI stack, instead of using dockerfiles directly <Foxboron>Largely the container community has been calling this "distroless" containers <Foxboron>I dont think they are using the bootstrappable stage0 to bootstrap anything, and I don't recall what they did. But might be interesting information there regardless <stikonas>Foxboron: live-bootstrap is generally quite reproducible <stikonas>majority of packages were just building reproducibly without any work needed <stikonas>only a few needed some tweaks and patches <stikonas>and large part of that is stuff like dates in manpages... <matrix_bridge><Lance R. Vick> Foxboron: Wolfi and chainguard are rooted in alpine which currently makes no particular attempt at supply chain integrity. This was not acceptable for the threat model of my use cases. Still it might be worth me adding to the comparison chart just to show the difference in goals. <matrix_bridge><Lance R. Vick> This question has come up a few times so I should address it in the readme <matrix_bridge><Lance R. Vick> Foxboron: I am not bootstrapping debian or alpine or any other distro. My only use of those is to have 3 different distros build stage0 to show they all get the same result, then I switch to a scratch container with stage0 and everything builds up from there. <matrix_bridge><Lance R. Vick> This is as far as I know the only set of containers that builds from 0 without trusting any existing linux distribution <matrix_bridge><Lance R. Vick> Foxboron: I will link those numbers to my sources (and then we can see if my sources are in fact wrong, which they may be!) <matrix_bridge><Lance R. Vick> That chart will be difficult to keep updated. I should probably just be like x for 100% reproducible or p for in progress, and link to the current stats