IRC channel logs
2026-06-22.log
back to list of logs
<aggi>AwesomeAdam54321: i remain sceptical over re-entangling scheme/lisp into the C-bootstrapping chain <aggi>that's no dis-paraging of anyone's effort, and a misleading statment of yours made in this case <aggi>fossy: if x86_32 was removed from bootstrapping efforts this severly regresses against live-bootstrap <aggi>implying a kernel bootstrap was any special purpose and individual taste of mine is another bold claim <AwesomeAdam54321>janneke, ekaitz: Would patches to expand the extent of supported modules be accepted? <ekaitz>AwesomeAdam54321: I'm not the rigth person to make that question to, but we'll have some news in the syntax front soon <matrix_bridge><Andrius Štikonas> So sooner or later it will be hard to maintain <matrix_bridge><Andrius Štikonas> You'll have to lie about system date at the very least <lanodan>Well at least for bootstrapping the system date matters a lot less, that said at musl level it shouldn't be an issue so what remains are filesystems and AFAIK that got mitigated in Linux <aggi>with POSIX 32bit and JFS filesystem it's possible to prolong until year 2106, since this filesystem treats 32bit timestemps unsgined <aggi>the convention then is, to treat 32bit timestamps on Unix as unsigned <aggi>since bootstrappable re-compiles everything from source, i hope patching a few pieces suffices <aggi>and this is what linux struggled with iirc, since they tried to hack some binary abi compatibility for year2038 <aggi>while OpenBSD didn't, hence implemented year2038 much earlier than linux, because OpenBSD too argued for re-compiling entire 32bit posix with a few patches <aggi>and drop 32bit abi compat <aggi>i'm not too happy myself either, a linux-tcc 2.4 kernel was the online option remaining to retain a bootstrappable kernel with sufficient hardware support <aggi>32bit posix limitations aren't specific to x86, any 32bit ARCH is affected <aggi>and there is arguments to be made to retain the 32bit envelop for bootstrapping and other purposes <lanodan>Not sure why you're adding posix there when POSIX.1-2024 changed time_t to be at least 64-bit <aggi>ext2fs isn't POSIX-2024, i fear you can't alter it's internal implementation without breaking changes <aggi>i am not at least sure if ext2fs would behave on 64bit posix <aggi>AwesomeAdam54321: yep, with linux-tcc kernel fork <aggi>there's a few other filesystems and pieces to verify (squashfs, unionfs which got backported and rebased) <aggi>and i've not begun to test the 32bit POSIX C-toolchain system profile for year2038 <aggi>next plan was, to move the most releveant base system profile components from gentoo/portage into live-bootstrap configurator/steps build system <aggi>this is what the tiny-bootstrap fork was created for - which remains x86_32 exclusive indefinitely <aggi>recently i got stuck at re-writing the portage/ebuild of app-cdr/cdrtools - which already is fully supported with tinycc atop linux-2.4 syscall abi <aggi>it's just one exemplary piece of an important base system component i would prefer to see maintained in live-bootstrap steps/configurator too <aggi>but i must alter the live-bootstrap dependency chain significantly, since i'm planning for an early make_bootable of linux-tcc (2.4) <aggi>i too intend to keep the C system profile agnostic towards gcc/binutils or any other toolchain chosen in the future <aggi>since all the salvaged software already is supported with tinycc/static-linking 100%, that's too relevant for any other approach with cproc/qbe, kefir, simple-cc, etc. <aggi>because there was plans "to remove tinycc", at least the existing userspace components already got detangled and confirmed those remained portable with different C-toolchains <xentrac>aggi: at this point you've accused both AwesomeAdam54321 and stabbles of trying to mislead people. to me, this seems like extremely aggressive behavior that goes far beyond basic norms of civility, and I would like you to stop it immediately <xentrac>people shouldn't have to worry that they're going to be called liars if they contribute to #bootstrappable efforts <xentrac>eliminating the vulnerability to the kernel is extremely important, but that doesn't mean that everyone has to be working on it, or that they're being "misleading" if they don't <xentrac>disagreeing with people, whether on priorities or on facts, doesn't require impugning their integrity <aggi>xentrac: i haven't the slightest clue how anything you're saying was related to bootstrapping or 32bit POSIX concerns <aggi>but thinking ARCH x86_32, posix 32bit and tinycc could easily be dropped and problems are solve then, it's difficult to argue with this <aggi>so, no worries, i won't comment upon this type of mindset again