IRC channel logs

<notgull>Never been a fan of autotools tbh

<roconnor>One thing #bootstrappable is good at is showing how the sausage is made.

<aggi>stikonas> and in the end, modern systems are quite big...

<aggi>far too big, and most important unneessarily

<aggi>as a random pick, lurking at slackware11 from 20years ago

<aggi>such systems already got almost everything: web-browser, audio and video multimedia, openoffice, tex typesetting, pdf/ps, gnuplot etc. etc.

<aggi>and at that time, software did compile and run on computers with 90% less RAM than today

<aggi>furthermore, nowadays software isn't "scalable" anymore, neither in size nor complexity

<aggi>there's been only one direction, scaling up, and no more option to down-scale when desired

<aggi>bootstrapping is one important use-case, when down-scaling in size and complexity is important

<aggi>FransFaase: i'm missing one piece of information from your presentation

<aggi>last time i had a glimpse at stack_c it seemed this one could not yet be fully integrated into a complete system-bootstrap chain

<aggi>which means stack_c had to be compilable by cc_x86 (or cc_amd64 if that exists), and too run atop some builder-hex0 type kernel

<aggi>this is a major difference to pnut-cc (too x86_32) compiler from laurenth, which too improves upon bootstrapping compile-time performance significantly by avoiding scheme/lisp interpreter

<aggi>nonetheless the progress made and comfirmation for tcc with ARCH=x86_64 is excellent work

<aggi>in a later stage i did not yet test linux-tcc and the userspace backport for amd64 - although that's a feasible long-term perspective to do so

<aggi>i see, in the presentation the remaining gcc dependency is highlighted with the approach for tcc-amd64 in the T-diagram

<aggi>and there is a few other blockers remaining with x86_64 (and any other ARCH than x86_32)

<aggi>there remains a major difference between live-bootstrap (x86_32) and amd MES-replacement (amd64)

<aggi>the former implements a complete system-bootstrap, the latter doesn't, not yet

<janneke>ACTION has a somewhat corny question/remark: if we're going to dump ai slop into a "full source" bootstrap, why not simply inject a binary?

<janneke>binaries bootstrap much faster

<aggi>pnut-cc can be compiled by cc_x86 to arrive at i386-tcc, and this route is significantly faster than mes-cc

<aggi>but i would not at all consider this "AI slop"

<aggi>the whole dependency graph of a linux-tcc/2.4 system too got a much smaller dependency graph to yield a complete/bootstrapped *nix development host

<aggi>the obvious advantage of GNU mes-cc is initial support for various ARCH other than x86_32

<aggi>but those are blocked by (too many i think) other open issues remaining anyway

<aggi>so the corny question/remark is: if any ARCH=amd64|riscv|aarch64 should be dumped into live-bootstrap because this can't avoid a gigantic dependency graph pulled into

<aggi>because once you got a fully bootstrapped x86_32 *nix development host, this can cross/compile towards any other ARCH, with gcc later then, anyway

<aggi>and i wouldn't consider linux-tcc/2.4 for x86_32 a major bootstrapping or development target; i consider this the FALLBACK option to retain a fully bootstrapped *nix development host including sufficient hardware support

<aggi>backporting onto linux-tcc disclosed a notable amount of rather concerning C-toolchain and POSIX portability issues (which too have an impact onto bootstrapping)

<aggi>to summarize this reasoning: which should be a common BASELINE (arch, kernel/version, compiler/version) for a common bootstrapping target and *nix development host?

<aggi>to answer that, i would prefer bh0->cc_x86->pnut-cc->i386-tcc->minimal(!) fiwix/linux-tcc+busybox+tcc

<aggi>in between this MES-replacement can offer detailed insight into dependencies (it's strength hasn't been a full system-bootstrap yet, but extended dependency tracing)

<aggi>which is remarkable because i've hit limits myself when hacking tiny-bootstrap fork, to track each individual source-file pulled into (up until M2-Mesoplanet already)

<aggi>another advantage with the pnut-cc->i386-tcc route: it can be re-based for tcc mob/HEAD _without_ various intermediate tcc-versions involved

<aggi>and i feel, there's no consent yet a fully bootstrapped *nix development host fallback option was necessary, regardless of how that was implemented finally

<notgull>Yeah I think AI generated code counts as "generated source" here

<aggi>notgull: no doubt, and i did notice on tinycc-devel already some have begun to run ai-generated/automated Unit-Testing against it's code base, then sending some mail-template to tinycc-devel mailing list with the results

<aggi>yet, which pieces of MES-replacement were ai-generated code? (for that matter "genetic code" isn't any news, code generators are known for more than 20years, together with bloat generated from UML diagrams etc.)

<aggi>i wouldn't know either which pieces from pnut-cc were ai-gernated code, if any, i doubt there was.

<aggi>for that matter, Torvalds just recently objected to ai-generated/automated unit testing (static code analysis) run against latest linux5/6/7 series

<aggi>and that's the current live-bootstrap linux/gcc target affected then (not some minimal fiwix or linux-tcc *nix development host)

<mihi>janneke, notgull: In my opinion it doesn't matter that much whether some piece of code has been written by a human called Jia Tan or an AI called Claude Code. The important point for code to be potentially trustworthy is that its format and style are in a form that can be (1) reviewed by humans and (2) edited and improved (e.g. made more clear) by humans.

<mihi>a typical binary blob output by a compiler (or psyntax.scm) is not, while an old cp850 color "ascii art" where the attribute layer has often been hand-coded in a hex editor is very well.

IRC channel logs

2026-10-13.log