IRC channel logs

<stikonas>ekaitz: oh yes, so many cores...

<ekaitz>mixed channel

<ekaitz> https://milkv.io/pioneer i shared this

<stikonas>yeah...

<stikonas>oh yes, it was on #guix-risc-v

<stikonas>anyway, I'm not sure if it's much faster for single core workload

<stikonas>e.g. building tcc with mes :)

<stikonas>ok, pushed M2-Planet 1.11.0 release too https://github.com/oriansj/M2-Planet/releases/tag/Release_1.11.0

<stikonas>so now only stage0-posix is remaining

<oriansj>ekaitz: hmm, 64 cores with support for ECC but board doesn't support ECC???? either incorrect information on page or they don't realize the average bit corruption rate of DDR4 per GB

<ekaitz>i have no idea about hardware mate

<oriansj>fair enough; most people don't know it happens and even fewer actually read the google study on the subject.

<ekaitz>i don't know what ecc is either

<ekaitz>but i'm sure i'm able to understand it if you summarize it ;)

<oriansj>imagine solar or csmic background radiation flips a bit in your memory; ECC would be able to detect and correct it

<ekaitz>aaaah

<ekaitz>i even studies that kind of error correction stuff

<ekaitz>i didn't know that memories needed that but it makes perfect sense

<oriansj>and as the lithography process uses smaller and smaller features it becomes more sensitive to lower and lower energy radiation. higher odds of a hit as the lithography gets denser too and the more RAM you have the greater the odds of getting hit (it scales approximately linearly with memory capacity)

<oriansj>a good rule of thumb is 1 bit corruption per GB per day (probably good bit higher now)

<oriansj>so 128GB => about a corruption every 10 minutes

<nektro>if you're using all of it

<stikonas>also most memory is never written back to disk

<stikonas>which is why most people don't bother

<stikonas>oriansj: we have a mess with mescc-tools

<theruran>Torvalds had a rant about ECC RAM a few years ago: https://arstechnica.com/gadgets/2021/01/linus-torvalds-blames-intel-for-lack-of-ecc-ram-in-consumer-pcs/

<stikonas>oriansj: I didn't know that you tagged it on savannah

<stikonas>so I tagged it yesterday on github

<stikonas>and made a release tarball

<stikonas>oriansj: but it's not the same commit!

<stikonas>but we probably want to include that extra kaem fix...

<stikonas>so I think the options are either silently move tag on savannah or bump version, prepeare new 1.5.1 tag...

<oriansj>stikonas: I pulled your tag and pushed it to savannah

<stikonas>ok, thanks

<stikonas>oriansj: this still seems to show the old tag...

<stikonas>though maybe there is some mirroring delay

<muurkha>radiation from the chip packaging is also a contributor

<muurkha>chips are packaged in epoxy, epoxy is largely carbon, separating carbon-12 and carbon-13 from carbon-14 is not literally impossible but far too expensive, and carbon-14 is radioactive

<vagrantc>will be speaking at seagl in a few days, and bootstrappable builds is a solid cornerstone of it: https://osem.seagl.org/conferences/seagl2023/program/proposals/939

<muurkha>yaay

<vagrantc>although i only talk about reproducible builds in the abstract ... looking at my slides bootstrappable builds might take up more of the talk :)

<ekaitz>vagrantc: is it going to be recorded?

<vagrantc>probably, as well as live-streamed

<vagrantc>they are doing a hybrid conference this year ... with both local and remote talks

<vagrantc>will be a pretty introductory talk ... kind of like a trimmed down version of my fossy talk

<vagrantc>although ... i am finding it hard to trim it down as much as i had hoped ... hopefully i will fit it all in the timeslot :)

<stikonas>yeah, but it might still be able to reach some people that we can't in other ways

<vagrantc>that's the plan :)_

<stikonas>vagrantc: also, if I recall early boot chain was a bit misordered in fossy talk, if you still have that, I can help you fix that

<vagrantc>stikonas: oh, please!

<stikonas>ok, so simplified chain without kaem shell and rebuild of original seeds is:

<vagrantc> https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/blob/master/2023-11-04-SeaGL-Beyond-Trusting-FOSS/Beyond-Trusting-FOSS.org

<vagrantc>that's my current draft so far

<vagrantc>i think i extracted the chain i had from what guix actually uses

<stikonas>ok, let's fix 25

<vagrantc>but i may have missed something, certainly :)

<stikonas>yeah, but even in guix it's the same order

<stikonas>hex0->hex1->hex2->M0

<stikonas>rather than hex0->hex1->M0->hex2->M1

<stikonas>in fact longer chain is

<vagrantc>there were some limits to what i could include in a single slide reasonably too ... but best not to be *wrong* :)

<stikonas>hex0->hex1->hex2->M0->cc_x86->M2-Planet->mescc-tools ->Mes ->Tinycc

<stikonas>it's mostly just ordering

<stikonas>M1 is subset of mescc-tools

<vagrantc>thanks, will see if i get it right :)

<stikonas>kind of cross-platform version of M0

<ekaitz>i'm not the only one that doesn't have a clear understanding of the whole chain... good good

<stikonas>with nicer interface and a few more features

<vagrantc>ekaitz: :)

<ekaitz>vagrantc: :)

<ekaitz>it's a little bit crazy

<ekaitz>for example cc_x86?

<stikonas>cc_x86 is C compiler written in M0 language

<stikonas>so C compiler in assembly

<stikonas>well, or cc_riscv64 :)

<stikonas>or cc_amd64, cc_riscv32 or a few others

<ekaitz>that was going to be my next question

<ekaitz>haha

<ekaitz>and M2 planet is a platform neutral thingie

<stikonas>yeah, cc_x86 can't build anything else

<ekaitz>written in that C subset, but what does it provide?

<vagrantc>i dropped the non-x86 architectures slide for this talk

<stikonas>ekaitz: m2-planet?

<ekaitz>stikonas: yes

<stikonas>well, it supports bigger C subset

<ekaitz>in practical terms i mean

<ekaitz>so it's just another C compiler

<stikonas>sufficient C subset to build mes

<stikonas>oh ok

<stikonas>so compared to cc_*

<ekaitz>yes

<stikonas>hmm, let me remember

<ekaitz>it's not platform specific in this case i guess, but it has to have several backends... or is it like an interpreter or something?

<stikonas>but new features in M2 are structs on stack

<stikonas>ekaitz: no, it's still like tcc

<stikonas>just has a few different codegens

<ekaitz>okay

<ekaitz>understood!

<stikonas>it supports quite a few more things than cc_*

<stikonas>though I'm struggling to name them :D

<vagrantc>stikonas: i think this fixes it? https://paste.debian.net/1296913/

<stikonas>been awhile since I looked at source of cc_*

<stikonas>vagrantc: yeah I think so

<stikonas>you can also lower hex0 to 256 bytes

<vagrantc>stikonas: not in guix yet

<stikonas>no, not in guix

<ekaitz>stikonas: what you explained is enough for me :) i just wanted to understand the high level

<vagrantc>but i do mention that in the talk :)

<stikonas>I'll try to make stage0-posix release today or tomorrow

<stikonas>anyway, M2-Planet is written in maybe 60% smaller subset than it supports

<stikonas>some other examples are a += 1;

IRC channel logs

2023-11-01.log