IRC channel logs
2023-10-30.log
back to list of logs
<stikonas>but obviously, in baremetal style bootstrpa you don't have and you have to set you real clock to some other date... <muurkha>yeah, that's what I meant about "otherwise the system clock is an input into the build process that's different every time you run it" <stikonas>but then that also causes issues if you want to download stuff from the internet using https <stikonas>you can only use that if you pre-download all tarballs <muurkha>well, downloading stuff from the internet using https is also an input into the build process that's different every time you run it <stikonas>well, you can probably use normal time for downloads <muurkha>and is a lot more likely to be changed to be malicious <stikonas>which is why live-bootstrap all most other distros check download hashes <muurkha>so pre-downloading all the tarballs seems like table stakes <stikonas>well, but making bootstrap process more portable should also be good <muurkha>yeah, we can hope that the reason Xiaoyun Wang stopped publishing new attacks on secure hash functions, and China switched to different hash functions, was *not* that she found much stronger attacks that have been kept secret <pabs3>stikonas, muurkha: btw, I think Intel are planning on some sort of removal of 32-bit support from the "PC" platform, so at some point the bootstrap might need to start with amd64 and branch off 32-bit PC later on <stikonas>I think it can still run 32-bit problems but won't boot in those early modes <stikonas>so probably wouldn't affect userspace bootstrapping <stikonas>but would break things like builder-hex0 <stikonas>well, it would be possible to adjust it I guess... <muurkha>probably amd64 implementors have less incentive to remove 32-bit support than ARM implementors <pabs3>Intel added it to their roadmap though <muurkha>I mean you still have a big verification effort to make sure your 32-bit support doesn't introduce ways to crash the whole system or subvert privilege checking, but it doesn't require a whole separate instruction decoder <pabs3>IIRC their plan is that 32-bit will still be available post-boot, but the boot process will only have 64-bit mode <oriansj>pabs3: well, we have until 2037 to solve all of the problems (as we will want it done at least a year early) or get to a place where losing 32 bit x86 would not be a loss <muurkha>also you could just write a 64-bit operating system that runs Fiwix as its only process, in 32-bit mode <muurkha>I should look at Fiwix at more than just a cursory level, it's such a great achievement <oriansj>stikonas: also you should have permissions to do stage0-posix releases when ever you want to do them <muurkha>including Linux for i386, which I didn't realize <muurkha>but presumably only if you compile with a version of libc newer than 02020 <pabs3>Debian's approach means not fixing i386 for 2038, since i386 will be declared as only for proprietary binaries <matrix_bridge><Andrius Štikonas> Well musl 1.2 has fixes for 2038 but we also use 1.1 in live-bootstrap as tcc can compile it easier <matrix_bridge><Andrius Štikonas> oriansj: oh thanks, I'll take a look I the evening, though I probably don't have permissions to tag some other repos, i.e, M2-Planet <stikonas>oriansj: or perhaps I could just do stage0-posix release, it's not like we really have any consumers who take just M2-Planet <stikonas>oh, but we do have at least some consumers for mescc-tools <ekaitz>if you want to see what stikonas and I have been fighting against since summer <ekaitz>we already shared with y'all we made the bootstrappable tcc to be self-hosted <ekaitz>but that's more or less the explanation of the process <ekaitz>now we are going to bother you more with the fixes to the scripts :) <ekaitz>janneke: i'll send you some patches for that, but they are pretty nasty <matrix_bridge><Andrius Štikonas> janneke: also all those stub steps I tcc seem to be unnecessary <matrix_bridge><Andrius Štikonas> So tcc-mes with reduced defines and then 3 more builds to reach stable point <stikonas>janneke: which tarballs do you need for a new stage0-posix release? <stikonas>I think I have the rights to do stage0-posix, M2-Mesoplanet and mescc-tools-extra releases but not other modules (such as bootstrap-seeds, mescc-tools, M2-Planet <stikonas>perhaps I should start with Mesoplanet and mescc-tools-extra then... <stikonas>argh, there is a question of versioning... that needs sorting out.. <janneke>stikonas: stage0-posix, mescc-tools, M2-Planet <stikonas>anyway, I've noticed discrepancy between what M2-Planet was tagged with <stikonas>so perhaps its worth syncing M2-Mesoplanet versioning with M2-Planet <janneke>the biggest problem that prevented me from updating in guix was that mescc-tools and M2-Planet could not use each-ochens M2Libc <stikonas>but like I said, I only have write access to some repositories <stikonas>and ideally we also release subprojects at the same time as the whole stage0-posix... <stikonas>oh you are fetching tarballs from lilipond <janneke>i tried to find (and build) tarballs that work together like this and match <stikonas>those are not the same as git snapshots I guess <janneke>i contributed "make dist" targets for some stage0 projects <stikonas>ok, I'll try to include submodules inside tarballs <janneke>(but submodules weren't used back then, i guess) <janneke>ACTION believes submodules are a very bad idea, fwiw <stikonas>anyway, thanks for letting me know about make dist <stikonas>I think I saw it before but forgot about it