IRC channel logs

***ChanServ sets mode: +o janneke

<fossy>can anmyone remember from many years ago if i would need to do anything special to get a serial console working under linux 2.6? console=ttyS0 dosen't help, netiher does earlyprint :( could be a kexec thing too

<oriansj>Hagfish: we already exposed a half-dozen false truths about bootstrapping. The most frequent being that writing a good FORTH or a good scheme is much much harder than it is to write a capable C compiler. (The original cc_86.S was done in less than 24 hours but we spent years to get mes.c into the state needed today. [And it still needs improvements to run things like gash, gash-utils and bootstar])

<siraben>oriansj: do you think that using Forth for bootstrapping would be very difficult?

<oriansj>siraben: well in a skilled FORTH programmer's hands bootstrapping can be productively done in FORTH. The big problem is cooperation with other programmers. Much like it is rare to see more than one developer work on a scheme, it is rare to see more than one FORTH programmer work on a FORTH program.

<siraben>Right.

<oriansj>That isn't to say that it couldn't be done but it requires something harder to find than 2 C programmers who don't break each other's code.

<oriansj>and honestly NieDzejkob has done some wonderful work in FORTH

<oriansj>Mostly squeezing it into 510bytes (the last 2 bytes are needed for the boot tag)

<oriansj>and I hope they make amazing progress in bootstrapping. Such projects tend to just sizzle out and it would be nice to be proven wrong about FORTH. But ask yourself this, could FORTH be used to implement cc_x86 in less than 24 hours? Which I absolutely could do in Assembly (even faster now that I have done it before)

<oriansj>If I spent as much time on TCC as I did trying to compile mes.c with M2-Planet; it probably would have been done sooner.

<oriansj>especially now that we have much better M2-Planet debug and macro support.

<oriansj>and getting back to the M3 work when I finally get freetime is the current plan.

<fossy>Ooops, my review for #127 was pending and not submitted :x

<fossy>hell yea https://ttm.sh/FOi.txt

<fossy>stikonas: what do you think of when we reboot into a new kernel using a "disk" (which would just be a disk image in tmpfs for qemu mode)

<fossy>i.e. root=/dev/sda instead of initramfs?

<fossy>there's quite a few benefits at that point, including: transition to real linux filesystem structure (FHS), future kernel reboots don't need a generation of an initramfs

<stikonas>hmm, I'm not yet sure how it works

<stikonas>where is that disk image stored?

<stikonas>oh, on the host?

<fossy>if you were running on real hardware it would be a real hard drive, the disk image would be on the host yeah

<fossy>and then just -hda sysa/tmp/drive.img or whatever

<stikonas>on real hardware this has to be configurable...

<fossy>yeah

<fossy>i'm looking at how we can do an interactive configuration system

<fossy>i'm thinking if our configuration file dosen't exist then we do interactive config otherwise read from that file

<stikonas>yeah, that's probably the best

<stikonas>do interactive with an option of preseeding answers

<fossy>yeah