IRC channel logs
2020-03-20.log
back to list of logs
<OriansJ>grubles: most people don't release source code that doesn't work; so it probably works to what degree and with what properties, one can not guess without study. <OriansJ>So, communicate and learn more if you are curious. <OriansJ>bootstrapping is a very small community and we need to be kind and considerate of each other and each other's time. Which like life is a precious resource. <grubles>what i meant was i know a guy who tried it and ran into issues <grubles>the guix ppc64be bootstrap looks promising too, since you can run it on a talos ii <OriansJ>well all of it is supposed to be promising. we are aiming at sub 512byte bootstraps for all platforms <fossy>whats mesboot mean in commencement.scm <fossy>I see lots of mesboot but dont get it, especially in stages far past mes <fossy>and whats the purpose of building gcc and binutils twice? <janneke>"mesboot" is not much more than a helper to make names/identifiers unique <janneke>before mes, it started with gnu-make-boot0, and diffutils-boot0 via gcc-cross-boot0 to gcc-final (skipping some steps) <janneke>so when i needed a name for the various gcc-2.95 and gcc-4.6, i added "mesboot" instead of boot-1 or boot-2 or something <janneke>there could be several reasons for building packages more than once <janneke>i think we build gcc at least 4 times, and binutils also more than twice? <fossy>I mean the same version multiple times <janneke>so, a full gcc cannot be built without a matching, up to date glibc <janneke>a minimal gcc (--enable-languages=c) => gcc-core has less dependencies and can be used to build glibc <janneke>this gcc-core+glibc can then build the full gcc <janneke>also, glibc cannot be built by a non-gcc compiler <OriansJ>janneke: why not? surely given the effort any C compiler could support the required C features. <janneke>OriansJ: sure, patches thoughtfully considered ;-) <OriansJ>janneke: as the goal is to make MesCC able to build GCC directly, wouldn't being able to also build glibc be in scope? <clemens3>aehm, stupid question, but I just might as well ask it here.. any thought to the strategy of going back in time to old initial versions? I am just asking, fiddling with Linux From Scratch, and it is mega complex.. but I am thinking about using the latest version, to compile an early version, and then back and back.. but just a thought, I am just scratching the surface.. <clemens3>but we are just rebuilding, what has been lost, not <clemens3>like when the first java compiler compiled its bootstrap version 1 in gcc, and then used javac, now you need to have javac already installed.. <clemens3>of course, is difficult to impossible as well to compile or even find version 1.0 <clemens3>but I did nt see this strategy mentioned on the bootstrap wiki of list of stupid ideas:) <janneke>OriansJ: in a way that's in scope, but i'm not sure priority-wise <janneke>clemens3: if you look at gnu guix, it has a uses a scripted version of "linux from scratch" <janneke>going back in time, step by step, may just be feasible and it's an interesing idea <janneke>my approach has been more pragmatic: try to take the biggest leaps you can <janneke>i did look at gcc-1.40 (earlier versions weren't ported to gnu/linux yet) <janneke>but i found i could build gcc-2.95 right away <janneke>building all versions of gcc-1.40 ... 2.95 could be interesting, but currently not very practical (read: terrbly time-consuming) <janneke>and then there's all user tools, awk, bash, coreutils, grep, sed, ... <clemens3>basically the work has been done, just so much layers (garbage) on top.. know how (how to get started) got lost again <janneke>yes...if you could just "extract" those shell scripts from history, we would be "done" <clemens3>projects like crystal, rustc, golang, they are so proud to cut off their bootstrap/gcc roots <clemens3>even java did it (thought must have been very late in the game, not when I used it) <clemens3>so the gcc-1.40 is interesting.. needs an old slackware floppy somewhere <janneke>i think gcc-0.9 was the first release <OriansJ>clemens3: not all software is worth the effort to resurrect <OriansJ>janneke: completely fair; probably far down on the list. <OriansJ>clemens3: at the same time, why rebuild garbage when you can have something worth keeping. <janneke>clemens3: yes, what OriansJ says: about garbage <janneke>the difference between software archeology (walking the old path) and bootstrapping, as i see it, is that we want a sweet, maintainable software stack, "now" <janneke>so, we want to rebuild "world" using maintainable and actually maintained software <janneke>if using historical versions (gcc-2.95) can get us there today...we'll use it <janneke>however, as gcc-2.95 is not really maintained (maintainable is open for discussion) <janneke>we either want to replace it (or find a true maintainer: much less desirable) <OriansJ>as all software rots; not in the well walked parts of a programing language but in the edges were few go. In those points programs break and die. Unspecified behavior being depended upon changing with time and optimizations. Thus we must a much more careful path. One that will survive through the ages. <fossy>interesting idea for kernel: minix 1.0's kernel ported to M2-Planet <OriansJ>fossy: honestly any posix kernel ported to M2-Planet solves the kernel bootstrap problem entirely <OriansJ>well line counts are a really bad metric for the complexity of a program <fossy>fwiw I agree with OriansJ and janneke, using old versions in the meantime is... undesirable but nessrcary, but I really think maintaining or removing them is important in the long run <OriansJ>and xv6 might also be an easier job as it is designed to be understood by students <fossy>OriansJ: are there any guides on M1, is it a prexisting langauge, or did you make it? Cant find much on it... I will most likely need to be using M1 for the assembly in this <OriansJ>fossy: M1 is assembly language you can define for yourself <fossy>I guess thats what the libc-*.M1's are, defines <OriansJ>literally it supports the bare minimal subset of functionality required for an assembler (line macros, strings and hex literals) <OriansJ>those are actually in the files like x86_defs.M1 and amd64_defs.M1 <OriansJ>the libc-core.M1 are just the _start functions required to setup the stack and call FUNCTION_main <OriansJ>So you can define any instruction you want, any way that you want in M1 <OriansJ>to figure out what you need for M1 defines rasm2 (rasm2 -a x86 -b 32 -d '8901') is very helpful <xentrac>minix is also designed to be understood by students. minix3 is supposedly pretty decent <OriansJ>as you probably want to have as little assembly as possible if you wish for the kernel to be portable. <OriansJ>xentrac: well microkernels come with other sorts of problems <OriansJ>and monolithic kernels do have development advantages in the short term. <xentrac>the decisive disadvantage for microkernels historically has been the worse performance due to the larger number of context switches <xentrac>L4 got that down to an extremely small difference, but in the wake of Spectre the gap has grown again <civodul>if you look at the big picture, D-Bus RPC is not exactly efficient :-) <xentrac>but L4 is worlds better than, say, Mach <OriansJ>xentrac: I was referring to the bugs found while hurd was being written but you are correct in regards to performance properties. <OriansJ>as RMS himself has previously spoken about the greater difficulty writing a microkernel relative to a monolithic kernel. <xentrac>right, but he hasn't written either one himself <xentrac>he's relating his understanding of mib's experience <OriansJ>he attempted to build a proper OS upon mach, which might have been a bad plan <xentrac>and mib probably wasn't the right man for the job <xentrac>in general debugging a distributed system is harder than debugging a single-threaded program, and sometimes harder than debugging a multithreaded program, but we know a *lot* more about debugging distributed systems in 2020 than we did in 1997 <OriansJ>xentrac: we have no "right men" here, only people who find certain problems fun. <civodul>the Mes-related work integrated in Guix is a huge step forward <OriansJ>civodul: yes, janneke has done alot of amazing work in regards to improving the guix bootstrap. <civodul>i mean there certainly is fun, but there's also a technical/social motivation :-) <OriansJ>the gash work and the gash-utils really took a byte out of the bootstrap binary size. <OriansJ>with some more effort janneke will get guix down to just guile (thanks to dddddd finishing slow-utils soonish [I hope]) <OriansJ>and then all that remains is getting mes-m2 into fighting form to bootstrap guile, run MesCC and solve this bootstrap problem. <OriansJ>building a working, garbage collecting, compacting lisp in M2-Planet was easy but getting it to full form to solve the final bit is going to be rough. <OriansJ>Plus I have ports to armv7l and AArch64 to do for mescc-tools-seed (not to mention port work to powerpc and risc-v if we want this all universal) <fossy>OriansJ: that is something I plan to work on in the near future <fossy>gash-core-utils is marvellous <OriansJ>fossy: Timothy Sample really did alot of heavy lifting in that and Rutger van Beusekom really sparked the merger that formed gash <OriansJ>wished they would visit here and get more praise for thier hard work as they share their successes but it is ultimately their choices. <dddddd>I can rush and throw something to the wall if that matters. <dddddd>It's mostly working for some time now. <dddddd>Are we removing the knight padding yet? <dddddd>Also, note that I'm completing M1.scm, as I understood the rest of slow-utils is working. Correct me if I'm wrong.