***ChanServ sets mode: +o rekado
<stikonas>pder: so I think we'll be stuck with autoconf 2.52 or lower for a while... <stikonas>hopefully you can get binutils working with it <stikonas>regarding perl, we might be able to build a sligtly better perl with modules manually... <stikonas>and Configure script will probably not work with tcc anyway <OriansJ>it might not be a small command but it certainly is nice to depend on a single libc: M2-Planet -f M2libc/sys/types.h -f M2libc/stddef.h -f M2libc/string.c -f M2libc/knight/Linux/fcntl.h -f M2libc/knight/Linux/unistd.h -f M2libc/stdlib.c -f M2libc/stdio.c -f M2libc/bootstrappable.c -f M1-macro.c --architecture knight-posix <Hagfish>so there's no nice way for it to find those files itself? <OriansJ>Hagfish: not without a kernel+file-system <OriansJ>And M2-Planet isn't allowed to assume a kernel nor file system <Hagfish>i'm struggling to imagine what sort of world exists without a kernel or file system <OriansJ>As it is supposed to be able to function to enable the bootstrapping of the first trusted kernel <Hagfish>what is the first step that requires a kernel (and how simple a kernel would be sufficient)? <OriansJ>Hagfish: well the first step that absolutely *MUST* have a kernel is MesCC <OriansJ>The requirement for Environment variables and a File system can't be done without a kernel (unless you want to convert mes.c into a unikernel) <Hagfish>there are people out there who write minimal kernels for fun <Hagfish>i would hope that at least one of them would see the value of this project <Hagfish>i guess it's a question of what other interesting things they've got to work on <Hagfish>but it does feel inevitable that someone (either in this channel or new) will have a go at this sort of challenge eventually <OriansJ>Well getting a Minimal kernel that TCC could compile is a rather straight-forward task. Getting M2-Planet buildable kernel would require a deeper level of work <Hagfish>hmm, yeah, tcc-compileable seems a modest goal <OriansJ>but I am hoping that someone beats me to it first <OriansJ>So I can skip the 3-6months of work required. <Hagfish>yeah, i'm hoping there are enough breadcrumbs lying around that someone will start following them and pick off some of the remaining tasks <OriansJ>One only needs to support a small handful of syscalls and single tasking <OriansJ>Hagfish: also there is a huge set of work to do with CPM/DOS porting, Hardware porting and Libre-Hardware work as well <Hagfish>we might be like the GNU project, waiting for our Linus to come along :) <Hagfish>yeah, hopefully some of the lower level stuff, and the porting work, parallelises well <OriansJ>Porting is getting M1/Hex2 working and then just adding the primitives required to M2-Planet. Full bootstrap port involves the writing of multiple independent pieces <Hagfish>the gravitational attraction to this work should increase with the amount of work that's already done <OriansJ>Hagfish: certainly much more people now than when we started in 2016 <Hagfish>people shouldn't be too motivated by fame, but the more we have to show people, the more it will grab people's attention <OriansJ>Then it was just me and janneke (with rekado_ and rain1 sometimes) <Hagfish>each individual step is a marvel in itself, but seeing it fit together is more than the sum of its parts <OriansJ>Hagfish: with a plan which exceeds down to individual transistors and up to full Distros <Hagfish>there are sort of "canonical" pieces of software that you port to a new type of machine <Hagfish>i wonder if some of the bootstrapping stages will come to be seen as "canonical" <Hagfish>like the first thing you do when hand-wiring your own CPU is see if it can generate the same hashes as other machines running the bootstrap process <Hagfish>people might start to share pictures of their 7-segment display outputs showing some "famous" hash that people end up memorising <OriansJ>Hagfish: well I would want hash mismatches to be a flag of something interesting on new bootstraps. <OriansJ>but sub-200 byte bootstrap binaries certainly would fit on business cards <Hagfish>bootstrap binary on the front, hash of the outputs on the back <Hagfish>at sub-200 bytes, people could memorise them <Hagfish>the logo would depict a bootstrap, right? <OriansJ>I'd probably have to find an artist to help get a good idea. <Hagfish>yeah, i think often projects try to crowd-source good ideas, then maybe give a shortlist of ideas to designers (who can then produce a few different visual interpretations) <OriansJ>Personally I think of the lower levels like making a piece of art out of colored pieces of sand. <Hagfish>you make me think of the xkcd comic about the rocks in the desert <OriansJ>except the pieces get bigger and more impressive and easier to use <OriansJ>individual nybbles to create bytes; which become instructions and data blocks to become the first hex programs <Hagfish>maybe a logo could be an hour glass, with sand at the top, and binary at the bottom, representing "we'll get there eventually" :) <Hagfish>but yeah, the incremental stepping up would be nice to capture <Hagfish>that might be a bit too illuminati :) <OriansJ>but yes, one could do big clunky relays, then shrinking vacuum tubes and transistors, until sand and then a hex block and then assembly and then C code <Hagfish>i feel like a logo should be recognisable at, say, 8x8 pixels <OriansJ>not a detail I am even thinking about this minute but certainly a problem for someone wanting to make some money off bootstrapping <OriansJ>But one can get creative with bootstripping with an attractive person pretty easily <Hagfish>merch could be a way to support the project, if funding was a bottleneck (and an intermittent source of funding were a solution) <OriansJ>well right now janneke is funded by NLnet and I'm a Full time employee for the State of Michigan. <OriansJ>So any funding would be to encourage the addition of more developers or close the problems that are biggest for members of the community <Hagfish>if a pot of money were to be generated, it would probably be best applied as bounties for specific issues or tasks <Hagfish>that can be a dual edged sword, though, of discouraging non-paid work, and encouraging people to technically fully the requirement but produce something that isn't really suitable <OriansJ>Hagfish: hence why we haven't done it yet. It doesn't seem like it would be worth the effort nor its cost. <Hagfish>are there examples of financial grants given for important past work that was done for free? <Hagfish>i believe Linus and RMS shared one for GNU/Linux <OriansJ>and here I am just thinking about wtf strstr is in string.h <OriansJ>and now kaem: M2-Planet -f M2libc/sys/types.h -f M2libc/stddef.h -f M2libc/string.c -f M2libc/knight/Linux/fcntl.h -f M2libc/knight/Linux/unistd.h -f M2libc/stdlib.c -f M2libc/stdio.c -f M2libc/bootstrappable.c -f Kaem/kaem.h -f Kaem/kaem_globals.c -f Kaem/kaem.c -f Kaem/variable.c --architecture knight-posix <OriansJ>mescc-tools is now M2libc C standard without any need for custom functions <OriansJ>up next is M2-Planet but I need to get some sleep. <OriansJ>pabs3: that would be rain1 and they do sometimes show up here. <siraben>Well build systems are simple in comparison to compilers right? Like a glorified shell script with topological sorting. <stikonas>for GNU Make I also wrote kaem script... Make is so simple to build, that it's good to have it before shell <stikonas>but yeah, I also think that build systems are much simpler in comparison to compilers... <stikonas>even if it depends on itself. it is usually quite simple to rewrite it in another build system <pder>stikonas: nice job on getting perl 5.6 working. Does that mean a newer autoconf is possible? BTW, I did have a /tmp directory when I got that awk error, so I am not sure whats going on with it. <stikonas>pder: newer autoconf needs perl with extentions <stikonas>although, I might be able to build that for perl 5.6 withouth Configure <stikonas>pder: one option is to try to rebuild gawk with autotools/configure <stikonas>autoconf 2.52 works on gawk if I recall correctly <stikonas>pder: do we actually need those -J -j -z specifiers for tar? <stikonas>pder: and gawk doesn't even need automake <stikonas>so if you want to rebuild it, feel free to grab my autoconf commit <pder>we have an ancient version of tar that doesnt support -j or -J. That pull request fixes an issue with bzip2 failing on reading from stdin by rebuilding it with tcc-musl without any patches <stikonas>pder: but I think I also sometimes saw that error... <stikonas>we should probably rebuild other mes libc stuff too <pder>I agree, maybe also xz if its not too hard? <stikonas>ancient tar also slightly struggles with some metadata with newer tarballs although that's not critical <stikonas>don't remember what was the problem though <stikonas>pder: by the way, how are binutils going on? Or have you not tried any more? <pder>I have a method to getting it fully built using the configure script and patching about 3 things. I'd like to know how to get it working without hacking generated files <stikonas>well, maybe I can take a look at some point later... <pder>Yeah. Not much success running autoconf in many of the directories <pder>Not sure if you saw that link I posted to an old version of Linux From Scratch that had a list of compatible versions of binutils autoconf and perl <stikonas> I saw but I don't think they are rebuilding binutil's configure files <pder>I can try to put something together for binutils that uses the configure script and we can fill in the autoconf steps when it is ready <stikonas>but it will be easier to iterate on top of something <pder>Thats a good point. I am not sure if they rebuild configure scripts- probably not <siraben>stikonas: re: build systems, that's good to hear. <pder>stikonas: I pushed a branch named binutils-wip if you want to play around with it. <stikonas>pder: thanks, I'll take a look a bit later <stikonas>you should clean some old merged branches :D <stikonas>pder: instead of true in bzip2 build script you can just use : <pder>ok, I didn't know what people preferred. I will change it <stikonas>pder: by the way, are you sure you were not using busybox tar? <pder>I think busybox tar supports -j and -J. GNU tar 1.12 does not <pder>But we were manually doing it in two steps. <stikonas>oh, coreutils were already pre-unpacked by kaem <pder>Speaking of which, I kind of prefer passing -k to bunzip2 or gzip to keep the original file <pder>Do we ever actually need to call bunzip? Cant we just use tar xzf? <stikonas>well, early in bootstrap we might not have pipes <stikonas>that's why it was kept as two separate processes <stikonas>pder: although, back then I hoped that we wouldn't need to rebuild so much. I.e. will be able to build newer versions <pder>With tcc and musl we should be able to handle newer packages. bzip2 is actually quite new from 2019 <pder>One thing that would be really handy is a way to start the build using a snapshot of the rootfs after the first tcc is built. The first part takes a good amount of time and isnt really changing much <stikonas>that's why I'm suggesting to disable blynn-compiler, at least for now <pder>I wonder if there is some low hanging performance improvements for mes <pder>stikonas: it might have been. I haven't been around that long <fossy>stikonas[m]: pder I also think we should disable blynn until it provides value <stikonas>in principle we can keep readme entry to avoid renumbering everything *fossy is also considering removing part numbers <stikonas>yeah, I think I suggested that too at some point <stikonas>it's getting annoying to change something in the middle <stikonas>Unless we can get Markdown to number them automatically <stikonas>but that's probably not possible with headings <OriansJ>fossy: I recommend using an area numbering scheme. eg 1.0.0 and 2.0.0 for major pieces; 1.1.0 for middle pieces and 1.2.3 for small pieces; That way gaps are normal(ish) <OriansJ>stikonas: the hardness of a program is entirely dependent on the programmer. For example writing a C compiler in Assembly I can do as a speed run and get multiple done in a few hours but it takes me forever to do graphical user interfaces. <OriansJ>For some people writing a 512byte hex program takes forever but they might churn out a boatload of GUI programs in a short while. <OriansJ>For example rain1 and janneke are both better at writing Scheme interpreters than I am. <OriansJ>I takes all kinds here to get the goals we seek. <Hagfish>i don't know if it justifies the downsides, but i do really like seeing the list of steps with numbers next to them <Hagfish>it's like going up an elevator in a really tall building and seeing the number increasing ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado