IRC channel logs

2021-05-04.log

back to list of logs

<stikonas>gef: how will that work in libc?
<stikonas>I just don't see an easy way to patch libc like that
<stikonas>libc's in different programs are completely independent
<stikonas>and we use multiple libc
<stikonas>I think bauen1 said you can only do that in kernel
<stikonas>but then we can only do that once we have our own kernel...
<stikonas>i think removing timestamps in from final files is easier
<stikonas>especially once we have upkgs
<stikonas>(once installation happens with DESTDIR, it's quite easy to purge timestamps)
<stikonas>at least if we fix touch
<gef>stikonas: the monotonic increase should theoretically always work, otherwise software makes invalid assumptions about execution order. Timestamps could be a form of validation between different runs, in that the sequence of steps is stable (it is not a guarantee per se, but it will catch many a perpetrator). IMHO, this matters primarily for the earlier steps of bootstrapping.
<stikonas>gef: how would libc know the previous timestamp?
<stikonas>I mean in the code as a variable
<gef>ah, it has to be thrown away at that point, libc arrives much later, is that what you ask?
<stikonas>it sounds like some "global" inter process variable
<stikonas>well, I'm just confused how one would implement this monotonically increasing timestamp
<stikonas>on each write
<gef>idea: perhaps some higher bits of the timestamp represent a phase of the bootstrapping - does that sound interesting?
<stikonas>we would have to manually number that
<stikonas>and after all the renumberings in parts.md I'm a bit sceptical to introduce manual numbering (and this time in code)
<stikonas>well, it's just that it seems to me that two executales never share any memory state
<stikonas>and I think POSIX basically guaranteeds that unless some process forks, in which case two processes will share state
<stikonas>maybe one can try to use that
<stikonas>but I think implementation will be a bit tricky
<stikonas>i.e. we need to patch libc to have some reservered memory are between all processes
<stikonas>and that will only work without threads for sequential buidls (athough at the moment that's what we have)
<OriansJ>stikonas: fopen("/example.timer", "rw");
<stikonas>well, ok, we can keep it in VFS>..
<stikonas>that will simplify things...
<siraben>yay, I see https://news.ycombinator.com/item?id=27023088 on the front page
<gef>here is a bootstrapping problem for future geek generations:
<gef>* use *polyglot assembly* to implement an OISC emulator of boot sector size, which can result into a compiler usable for bootstrapping: https://vojtechkral.github.io/blag/polyglot-assembly/
<gef>"The basic idea is pretty simple: The code starts with a magical snippet that gets interpreted by both architectures and basically performs a conditional jump based on which architecture is runing the code."
<fossy>watdaf
<fossy>holy shit the stars just blew up
<fossy>it went from like 5 stars to 49 stars on live bootstrap
<pabs3>fossy: it got on the HN front page https://news.ycombinator.com/item?id=27023088
<bauen1>^ and now live-bootstrap has a lot more "to show" like gcc-4.0.4 running
<gforce_de1977>nice graph during my experiments: http://intercity-vpn.de/bootstrap/bootstrap-usedmem700M-usedmem2x.png
***alendvai__ is now known as attila_lendvai
<melg8>Hi, i've managed to fix touch by rebuilding it on coreutils 5 second pass. But now encountered another problem. It can't handle symlinks. First available version with that setup isĀ  8.1 (2009-11-18) [stable] in contrast with our 6.10 (2008-01-22) [stable]. So, can somebody explain why 6.10 were choosed? and what problems might be, with trying 8.1
<melg8>to build? and should i add it as separate step, or try to replace 6.10?
<gforce_de1977>trying to lower the max RAM-requirement, now close to 512mb 8-))) http://intercity-vpn.de/1.png
<melg8>how you achieve that?
<gforce_de1977>melg8: measures needed RAM from /proc/meminfo every second and plot it
<melg8>I mean, how you try to lower max ram? by doing what?
<gforce_de1977>melg8: deleting sources and unneeded old stuff while compiling new stuff
<gforce_de1977>only keep resulting binaries
<melg8>so at the end there is nothing from, like M2?
<gforce_de1977>yes
<gforce_de1977>dont get me wrong, this is totally unneeded work, but i was interested
<melg8>nice idea, but i think that we need both options - minimal and full, so it could be build in constraint env, but also - so we could control intermediate results
<gforce_de1977>you are right, i will add an --autocleanup option for this stuff later
<gforce_de1977>finding somebody who has an i386 PC mit 512mb RAM will be hard, but 256mb should be possible 8-)
<melg8>it would be useful if somebody will try to start 20 builds at same time) just for fun and reproducibility purposes)
<gforce_de1977>melg8: i did already several 1000 builds for fun, see the 'issues' on github. there indeed some problems with reproducibility, but solveable
<melg8>yea, im working on reproducibility side of things as well, but i want to clear out my diffs from all dates changes, and then try to fix the rest, hope is to achieve bit by bit reproducibility
<xentrac>yaay