<OriansJ>melg8: I'd much rather have 200MB of sources than 1MB of binary to audit. <Hagfish>when people write research papers about this project, perhaps that quote will become known (incorrectly) as Orian's Law <Hagfish>i'm sure other people have made similar observations, but this might be the first project that takes that idea to its furthest extremes <stikonas>although, I don't think any other project is as advanced <stikonas>we can avoid them in coreutils-6 because we only build (sha256sum, mktemp and date) <stikonas>getting rid of it in autotools build (coreutils 8.32) seems quite hard, probably worth to delay it until gperf (which is after g++) <OriansJ>Hagfish: I like to think of it as "extreme" libre software development. No binaries or pregen files, only human written source code as far as the eye can see. <OriansJ>stikonas: we are only further advanced then the rest because instead of one lone developer trying to do everything (and failing because it is too hard to do alone); we have a rather large collection of capable people working together and having fun while doing it. <stikonas>with more people progress might be much faster <melg8>OriansJ if i add mkdir to kaem - can it be merged to main repo? that would be really nice for nix by removing custom patched version from it <stikonas>we won't need to pre-mkdir so a few empty directories in initial initrd image <melg8>yea, because of that abuse of empty directories i was forced to replicate them by hand + add to kaem mkdir - thing is - until newer version of nix i can't checkout repos submodules, and if cant do that - i can't just build from "inside" of loaded sources - they are in /nix/store/blabla and build is in /build ) <melg8>and all this because i don't want to trust to bash and use kaem instead) <OriansJ>melg8: generally patches are quite welcome (I tend to only reject them when they are breaking things or touch way more than is required to implement the desired functionality) <OriansJ>althought mkdir tends to be a seperate program outside of the shell <OriansJ>but it can quite easily be a builtin for kaem <OriansJ>one could also make chmod a builtin in kaem too without too much effort <stikonas>but I guess kaem.c only, not kaem-optional-seed <stikonas>well, the alternative is like OriansJ says, write a small mkdir binary <OriansJ>stikonas: correct. kaem-optional-seed is shrink only, never add. <melg8>can instead of kaem seed be hex seed, which builds kaem seed and than runs it? will it be smaller? <melg8>which builds kaem from source* <stikonas>yes, I discussed it a couple of times here <OriansJ>melg8: kaem-optional-seed is a 1:1 to the kaem-optional-seed.hex0 <melg8>i think that would be cool even though initial source become larger i guess <OriansJ>stikonas: yep and eliminate the need for tokenization and other features. <stikonas>although total amount of hex0 code will go up <stikonas>and hex0 is not that much easier to read/write than machine code <stikonas>tokenization takes quite a few bytes in kaem <OriansJ>it'll just be move a string into eax, call execve; waitpid loop and then next string, call execve; waitpid loop and then move last string into eax, execve; waitpid loop. Exit <OriansJ>(also pushing stack for argv but you get the idea) <melg8>it would be nice... for marketing )) <OriansJ>melg8: and a good exercise for anyone who would want to learn hex0 programming. <melg8>not me, at least not for now) already 3 different directions of self improvement )) <OriansJ>melg8: ^_^ no worries, we all have more things to do then time to do it in. <melg8>btw, any news about live-bootstraps ci max run time? <melg8>i've managed to build it, tomorrow will cleanup patches, and rebase, so it will be reviewable <Hagfish>"we are only further advanced ... because ... we have a rather large collection of capable people working together and having fun while doing it." <Hagfish>it sounds like there's a meta-bootstrapping problem here <Hagfish>"the best way to find a talented person to do amazing work, is to first have some talented people doing amazing work" <Hagfish>perhaps i could say that OriansJ solved that problem first ***mephista is now known as spicy_icecream
<fossy>melg8: live-bootstrap CI time is next on my list <ekaitz>hi, I'd like to contribute to the project towards a RISC-V port, could you point me to some basic work that have to be done so I can dig a little bit on it? <bauen1>ekaitz: hi and welcome, i'm not sure how familiar you are with live-bootstrap, but iirc the major hurdles with risc-v are that hex0 and friends don't yet support risc-v, the patched tcc version we're currently using is too old so it's missing the risc-v support from tccs mob branch, and we later build gcc 4.0.4 that is also missing risc-v support <bauen1>gcc 4.0.4 is quite a bit of an issue in that regard, as you'd have to add risc-v support to it basically from scratch (gcc 4.0.4 is very old) <ekaitz>i'd take a look to the hex0 and friends in the first place, since it is the most accessible for me <ekaitz>but the gcc thingie looks terrifying atm <bauen1>OriansJ: also iirc you had some choice words about how risc-v could / should be handled with hex0/m1/m2/mescc ? <bauen1>ekaitz: yes, maybe there are ways around using gcc, but eventually you'll need a c++ compiler for newer versions of gcc <ekaitz>well, i'm not sure there are ways around, we'll probably need to port it too <ekaitz>we'll see, maybe it doesn't look that terrifying in the near future <gforce_d11977>ekaitz: getting the first step with hex0 done would be coooooool <ekaitz>gforce_d11977: I'm playing around with qemu these days and it works pretty well with riscv and gdb <ekaitz>I'm migrating *lightening* (wingo's fork of GNU Lightning) to riscv and I'm debuggin the process with that <ekaitz>smartineng: is there any conversation thread to catch up with those changes and see what is needed next? <gforce_d11977>ekaitz: try to work on the very first: hex0-seed.x86.hex0 and try to implement it for risc-v to get a feeling <ekaitz>good thanks gforce_d11977 and janneke ! <ekaitz>gforce_d11977: this may sound stupid but I'm a little bit confused by the amount of sub-projects we have here <ekaitz>ho wis bootstrap-seeds related to mes? when is it loaded ***dongcarl7 is now known as dongcarl
<bauen1>ekaitz: bootstrap-seeds should be the only binary seed necessary for running live-bootstrap, it consist of a hand-assembled hex0 and kaem <bauen1>ekaitz: kaem is shell, the early build scripts are written in it <melg8>kaem is like minimal bash which can run .kaem scripts <bauen1>^ it exists in a few versions afaik, each being a bit more complex with a few more features until we reach bash in live-bootstrap <ekaitz>so the hex0 is the assembler and kaem a shell <ekaitz>i'll try to implement both, let's see :) <bauen1>well hex0 (the language) is basically a glorified binary <bauen1>iirc hex1 is hex0 but with comments <bauen1>it's been a while since i touched those parts <bauen1>but they should be fairly straight forward to implement <ekaitz>how do you create the hex0? directly by hand or you use a simple assembler to do most of the hard job? <bauen1>ekaitz: the idea being that you never use the output of a compiler in the bootstrap, so hex0 is hand assembled, as is kaem (the seed version), which are then used to compile the next etc... <ekaitz>great, yeah, that makes perfect sense <gforce_d11977>ekaitz: 'kaem' is a puzzled 'make' (spelled in another order) <stikonas>bauen1: ekaitz hex1 is hex0 + 1 character labels