IRC channel logs
2026-01-29.log
back to list of logs
<jackdk>That's exciting work. And in further excitement, someone submitted a Bachelor's thesis that bootstraps an i686 Nix from live-bootstrap, by bootstrapping Nix and building nixpkgs' bootstrap-tools from Aux Foundation. Future work in this space will be much easier because nixpkgs recently merged a hex0-based stdenv bootstrap to `staging`. <aggi>i guess none of those bootstrapping final targets would consider a _complete_ tinycc/linux2 driven system integration as trusted bootstrapping/development-host <aggi>because, tinycc/linux2 can both: significantly shrink the dependency-graph for a _complete_ development host if gcc/binutils remain fully optional <aggi>and, furthermore, provide far more hardware-support, nptl, and offer many more optional software-components far earlier _before_ gcc/binutils were bootstrapped <aggi>besides another side-effect, extended portability is confirmed for a real C-toolchain with it <aggi>well, ok, those various ideas do not conflict with each other, it's just a matter of priorities set <aggi>and of cause GNU rather head towards a full GNU-toolchain system immediately, while i considered full vendor-neutral portability mandatory <aggi>interestingly, fiwix and bootstrappable thankfully did cope with important portability issues for a tinycc/linyx2 sysv abi, but do not capitalize upon it finally <aggi>i mean, with regards to portability, the linux-tcc/2.4 fork got slightly modernized, and it is latest software versions backported for it <aggi>in this regard, there's no need to bother with any latest kernel version almost <aggi>and it was/is latest kernel-versions for example which do vendor-lock gnu-toolchain and with it a significantly increased dependency graph <aggi>and finally, for any other than ARCH=x86_32 the pragmatic approach is cross-compiling anyway i guess <aggi>a tinycc/linux trusted development host can do this just fine, given bootstrappable did confirm the tinycc->gcc transitiion anyway <aggi>it's been a nightmare to keep perl.static and python.static portable, for GNU/autotools and gentoo/portage here <aggi>which is the tooling full cross-compile/static-linking was confirmed with here <aggi>myself is thinking real hard, to avoid gentoo/portage, and re-writing packaging for some other system <aggi>because, i could not merge with upstream due to various blockers, and i guess the same would happen at the Guid/Nix front for the mentioned tinycc/linux2 system profile <aggi>if there had been some cooperation, the C-toolchain portability for and with tinycc/linux had been coped with already, for everyone to benefit from <aggi>but i'm maintaining a kernel fork, libc fork, tinycc patches, and 500ebuilds already, hundreds of patches and hacks <aggi>and any merge with anyone would be desirable only if there was some mutual benefit <aggi>because, the tinycc/linux fork is fully operational here, all else to re-integrate with upstream is additional efforts <aggi>i would consider this fork the candidate for a common bootstrappable development host <aggi>of cause, Nix, or void, or sabotage-linux packaging, that's all options to be considered, if full cross-compilation/static-linking support can remain covered <aggi>with regards to licensing, both linux2 and tinycc are GPL, if that was a concern or motivation to prefer any variant <aggi>regardless of licensing, i think, my opionion, such a _complete_ bootstrappable development host should keep gcc/binutils/g++ _optional_ <aggi>for technical reasons, such as the gigantic dependency graph that is with latest kernel versions and gnu-toolchain otherwise <aggi>furthermore, a tinycc/linux development host establishes a baseline for any other approach, such as fiwix/minux/hurd and the various toolchains that are/were developed (scc, pcc, kefer, cproc, qbe) <aggi>since it's such an interesting cornercase: could any Guix/Nix/whatever be fully driven with TinyCC as it's main system-toolchain? <aggi>if not, and this affects all other hundreds of variants/distributions/versions i could recall; why is that none of those systems could confirm C-toolchain portability? <jackdk>I don't think nixos could, since Nix is built out of fairly modern C++. That forces you into either a GNU or clang toolchain I guess <aggi>to avoid a misunderstanding: i do appreciate bootstrappable.org covers the transition from tinycc to gcc/g++ llvm/clang/c++ etc. <aggi>but, i am opposed to the idea GNU-toolchain/c++ etc. became a _mandatory_/non-optional dependency far too early within the bootstrapping chain <aggi>i too prefer a _complete_ development host can be driven with c-toolchain portability remaining intact <aggi>furthermore, this problem is solved already, but merely blocked for political reasons if you will <jackdk>I think it would be great in the medium term to have a stable baseline that is "known-bootstrappable" from which people can build up to higher-level things. I don't know enough to discuss the relative merits of Fiwix vs Linux2 as the kernel for that baseline <jackdk>My current heuristic, reinforced from yesterday's discussion, is C99+autotools+libraries I can get via pkg-config (and are also bootstrappable) <aggi>maybe that's the irony, linux2/fiwix are "higher-level" things, in case of fiwix kernel that is achieved with 50000 lines of code <aggi>both linux2 and fiwix offer a sysv abi, with a few less features (i've re-iterated over the linux-2.4 one only) <aggi>interestingly, such a linux2/fiwix kernel abi is sufficient for almost all higher-level things <aggi>a key difference between linux2 and fiwix concering kernel ABI, is optional NPTL support which RedHat never mainlined, but it is available/feasible and tested succesfully with the linux-tcc fork <aggi>so, linux2.4 can drive a notable amount of software with multi-threading (which i've tested recently with a tinycc compiled tor.static proxy recently, just one example, it's working) <aggi>fiwix, for good reason, rather may avoid NPTL alltogether <janneke>politics can be terrible, if they're not aligned your goals <janneke>ACTION is a strong supporter of freedom, alas, that comes with politics <aggi>another difference, linux-tcc/2.4 in essence got full hardware support, which is very practical <aggi>and again something, which fiwix rather may avoid (USB stack is terrible), so i took the pain to rebase/patch/modernize linux-tcc <aggi>then i've backported almost everything i could back onto linux-tcc, some of which could be a candidate for fiwix too (since it's both linux2 sysv abi kernels) <aggi>another difference, fiwix uses gnu/gcc as it's main system-toolchain still, although it was feasible to run fiwinx with tinycc (shown by bootstrappeble) <aggi>for linux-tcc instead a system integration with tcc was confirmed for a complete development host already - not in theory, it's up and running <aggi>anyway, thanks for listening <fossy>ah, we missed another pre-generated code in nyacc? :( <fossy>jackdk: thanks for that link, that is exciting :D <fossy>Ooh, if i understand correctly, we can get rid of those file regeneration scripts for nyacc that take forever? <stikonas>fossy: was it really another regeneration code that we missed? <stikonas>I've got an impression that it was just another place in the code that used the same files