IRC channel logs

<oriansj>well we are going to lean *HEAVILY* on guix to keep bootstrap chains alive after we create them for some languages. (especially those that seem not to give a flying fuck about having a proper bootstrap path)

<oriansj>but yeah, languages require adults in the room keeping the bootstrap path possible and calling out the bad behavior.

<oriansj>Which is really weird because even writing advanced compilers, you never need to use a boatload of language features. Like basic structures and a handful of control flow is all one really needs.

<unmush`>it has occurred to me on reading this that we are essentially software etymologists

<homo>somehow ghc manages to use all the features, as only previous version of ghc can compile new version of ghc

<homo>I found a fix from aur for building hugs with modern gcc, now it finally works on guix https://paste.debian.net/1339304/

<homo>surprised to see Control.Arrow in hugs, didn't know they are that old

<homo>rekado: if you still have part 2 of your blog, I'm curious about bootstrapping nhc98 from hugs to have first bootstrappable compiler for personal programming

<homo>also I found bug in definition of hugs package, it pulls 98-plus, but skips building those extra packages like X11, HGL, OpenAL, OpenGL, etc.

<efraim>that might not be a bug, if it was intended to be used for bootstrapping

<efraim>especially if those extra bits needed more inputs

<homo>right, most of the libraries of 98-plus (parsec, stm, time, ...) are installed, it's only audio and graphics ones that are excluded

<homo>I can change definition to include those too, but I bet there is 0 need and 0 interest in using those

<homo>it's so surprising to see that in the old days cabal had build instructions for nhc98 and hugs, and base was shared between ghc, hugs and nhc98

<homo>source code of hugs even includes cabal-install...

<homo>pattern guards, ffi and hierarchical module names (like Data.Char) are haskell2010 additions and fortunately hugs supports them, so hugs2010 name?

<homo>actually nhc98 is broken on amd64, it strictly assumes i386

<aggi>finally the tinycc i486-tcc-linux-musl.iso got some working squashfs.initrd with a busybox and some init scripts to mount the full root.squashfs

<homo>linux can be compiled with tcc? o_O

<aggi>yep, a complete distribution can be (if it's sanitized from c++)

<aggi>although, it is not fully compliant with "we do not break userspace", when spawning recent software versions atop linux-2.4 ABI

<aggi>for bootstrapping i'll publish a minimal initrd.squashfs version only which does not ship the full root.squashfs containing ~500 packages

<aggi>btw. my ISP increased upload bandwidth from 2Mbps to 10Mbps (without notification), so i can host some tiny anon ftp myself

<homo>well, at least "stable" ABI is useful for something other than flirting with proprietary software

<matrix_bridge><cosinusoidally> Just wondering, could builder-hex0 be made to run under 64-bit UEFI by replacing the bits that transition down to 16-bit to do bios calls with bits that transition up to 64-bit to do UEFI calls?

<matrix_bridge><Andrius Štikonas> cosinusoidally: no

<matrix_bridge><Andrius Štikonas> It's a bit more complex than that

<matrix_bridge><Andrius Štikonas> I have posix-runner that implements some of that bu t it is far from complete

<matrix_bridge><Andrius Štikonas> You can't reserve arbitrary memory in UEFI, you need to ask for allocation in malloc style...

<matrix_bridge><Andrius Štikonas> And also dosome other tricks

<matrix_bridge><Andrius Štikonas> Next task in posix-runner would be to implement paging

<matrix_bridge><Andrius Štikonas> Otherwise we can only run relocatable binaries

<matrix_bridge><Andrius Štikonas> (Again since we don't control arbitrary region of memory)

<matrix_bridge><Andrius Štikonas> Also, I haven't even properly sorted out transition to user space

<matrix_bridge><Andrius Štikonas> All programs in posix-runner.efi run in kernelspace

<aggi>it's a little concerning UEFI/CSM is phased out with some recent intel x86_64 hardware

<matrix_bridge><Andrius Štikonas> yes, I don't have UEFI/CSM on my laptop...

<matrix_bridge><Andrius Štikonas> hence I did a bit of work on posix-runner...

<matrix_bridge><Andrius Štikonas> but it takes quite a bit of time to debug these low level OS issues

<aggi>i see three options to cope with uefi/csm: (1) using legacy hardware, (2) qemu, (3) switching to another ISA other than x86_64

<aggi>BIOS is designed for direct low-level hardware-acces, emulating 16bit real-mode for this atop uefi probably yields just that, an emulator

<aggi>anyway, the tiny old thinkpad i got for 30EUros seems decent for support with linux-2.4

<aggi>although it was cheap, it is rather difficult to acquire such a device in decent condition

<aggi>it's 20years old, i clocked down CPU to lowest 600MHz, 1 GiB RAM, with the tinycc distribution it's fun

<aggi>it seems however, proprietary vendor malice creeped into the system 20 years ago already, standards compliant vesafb is jittering video-output

<aggi>i tried efifb on some more modern hardware, and it sucks too, nothing changed ever since

<aggi>because i try keeping generic standards compliant drivers instead of vendor-specific ones

<aggi>it's a hit and miss, if you got decent svga video-out then

<aggi>anyway, usb is working, just booted the tinycc kernel bare metal today, first time; other than jittery vesafb it's ok

<stikonas>well, UEFI itself is not proprietary byt itself, I have UEFI as part of coreboot

<stikonas>but it's just different boot flow

<stikonas>so we need to write different code

<aggi>the issue isn't uefi secure boot (although it's bad), nor a free/open implementation of uefi with coreboot, the issue is uefi itself

<aggi>allthough #fsf invested significant efforts into free/open uefi implementation, uefi itself is the problem

<stikonas>well, it is a complex system

<stikonas>it does provide you with far more than BIOS though

<stikonas>but of course there is some cost of those services

<aggi>BIOS, bootloader and kernel duplicate too much code already

<stikonas>that happens everywhere

<aggi>uefi just made it worse

<stikonas>on aarch64/riscv64 u-boot and kernel also duplicate a lot of stuff

<stikonas>all those device tree files get coppied from kernel to u-boot too

<stikonas>some drivers have to be implemented in both places too

<aggi>yes, and the dependency graph of u-boot got rigged, with python and c++ attached

<aggi>this was one main reason i will abandone arm, among others

<aggi>and i fear risc-v is following along the flaws of arm

<aggi>[off-topic] https://arstechnica.com/gadgets/2024/04/after-48-years-zilog-is-killing-the-classic-standalone-z80-microprocessor-chip/

<stikonas>well, u-boot is fairly standard bootloaded on all embedded systems

IRC channel logs

2024-12-11.log