Hi tccm, i remember we've been talking about this before and didn't consent with a common understanding of some basic facts. That's why i welcome your intervention too and it's certainly not "off-topic", it touches most principle engineering concerns of tinycc itself.
A major criteria seems to be, bootstrappable.org fully discloses all sources, commented binary hex seeds, their early macro assemblers and compilers in particular. > what is new? A reliance on a 375-byte binary program? Yes, for example. And there's a few more of those "trivial" hex-seeds. > Most of all, why is it actually called "full source"? All of it is disclosed and documented, that's new, including the pico-kernel and loader from rickmasters which is a crucial piece of live-bootstrap too. > "the set of binaries from which packages are built includes a 25 MiB > statically-linked Guile" This information seems outdated; bootstrappable.org merely was honest with documenting known issues at the time those were unresolved. Nowadays you do NOT need a pre-compiled 25MiB scheme interpreter anymore, for live-bootstrap to arrive at tinycc and linux-tcc (or fiwix) kernel together with a musl-libc that is. This gigantic scheme interpreter had been an important temporary development stage nonetheless, and we would rather be grateful GNU handled all those efforts. Myself is focussing less on the remaining GNU toolchain pieces however, which are entangled into some autotools/scheme related complexity surrounding gcc/binutils GNU build-system still, but it's coped with by live-bootstrap to my knowledge to remain compliant with acceptance criteria. Another difference of my approach, was forking a complete(!) system integration _before_ and _without_ GNU toolchain being available and tinycc-toolchain chosen instead which at bare minimum was suitable to demonstrate the feasibility of doing this while live-bootstrap focused on keeping GNU toolchain up and running instead. Furthermore GNU mes pieces are optional nowadays, in particular mes-cc, since there was other options introduced and welcomed at bootstrappable recently: - pnut-cc from laurenth - mes-replacement from Frans Faase who focused on some dependency tracing worth a discussion of its own documented at his web-site - and a few more i cannot all mention here with their pros and cons tccm, if you disagree with GNU mes project for example, you might easily stop at M2-planet compiler and spawn any other libc/c-compiler from there however you wish. In fact bootstrappable.org isn't focused on C-language exclusively, there's non-C fully scheme/lisp type bootstraps being discussed. So, if you dislike C language and GNU mes for some reason, you're free to hack some LISP-machine or Forth spawn from M2. Or improve upon M2-planet itself to skip the necessity of yet another intermediate compiler/libc necessary at this stage. In fact this had been discussed briefly, if at all it would be feasible to spawn tinycc directly from M2 instead of intermediate mes-cc|pnut-cc. A recent proposal at bootstrappable had been to extend the abilities of mes-cc instead and improving upon it's compile-time performance to completely drop tinycc from their dependency graph - which i guess is a little misguided and no priority, but that's the nice aspect with free software, different opinions are welcome and showcasing the feasibility of any approach. For practical reasons i've chosen to keep mes-libc without mes-cc in combination with pnut-cc to spawn tcc-0.9.26, which is extremely fast compile-time in comparison to the scheme-written mes-cc. You might have a look at the tiny-bootstrap system-integration approach, since myself too disagrees with some choices made by live-bootstrap. I would prefer to keep the whole dependency graph of live-bootstrap much smaller and simpler overall to arrive at a linux-tcc/tinycc bootable system, and moving all else into an optional package set (GCC/binutils, linux5, GRUB, python). I don't intend to abandon those GNU components, i merely would prefer to keep those optional during the earlier/critical stages of bootstrapping. Because GNU has a natural tendency to grow rather tall in places where it's problematic. There's too some fundemental issues with various X86 assemblers and different syntax necessary to cope with syslinux,isolinux, and linux-2 bootcode pieces. Sadly GNU gas probably isn't the most favorable choice due to the size and complexity of typical GNU projects. Maybe you recall the mailing-list noise of mine when asking about the presence of x86 16bit real-mode ASM support with tinycc. In the meantime i managed to compile YASM with tinycc at least to avoid the gigantic GNU binutils dependency, and this tinycc+yasm combination fully replaced gcc/binutils here already, 100% (you'll find the yasm and tinycc bootstrapping steps are already integrated into steps-tiny; i've just been in extremely bad mood again in recent weeks due to some outrageous denials at german universities, german government offices who supposedly support startup funding, hr offices etc.) Anyway, M2-planet in particular, live-bootstrap, GNU mes, that's all very important pieces which deserved any funding there was for this. I would uphold the same opinion for tinycc-devel, linux-tcc kernel and tiny-bootstrap alike. Another major issue remaining is bootstrapping concerns down to firmware/hardware level, which cannot be discussed in detail here. As a sneak preview, to keep it brief, few days ago i've ported and tested another mainboard for coreboot/seabios and tried to compile those with tinycc at least, something which would violate strict bootstrapping acceptance criteria already since tinycc would not be available for firmware development at the bootstrapping phase it's needed. Even worse, in practice you need GCC/binutils to cope with coreboot/seabios. And again, a major hindrance, absense of 16bit real-mode ASM support with tinycc since coreboot contains a little of it (coreboot/seabios may not be a suitable bootstrapping choice for other reasons besides but there is no other options to my knowledge, except some exotic ones not yet covered by live-bootstrap and tcc). Hardware development by itself raises even more concerns (verilog/hdl bitstream compilers and gigantic unacceptable "circular dependencies" those introduce). Anyway, thanks to https://15h.org there's a few affordable x86_32|64 boards remaining with free/open firmware at least; such development workstation with a bootstrapped fully tinycc-toolchain driven kernel and userspace is something i'm heading towards. linux-tcc kernel fork is fully supported and tested on fm2/coreboot already, including modern SATA/AHCI and Gigabit Ethernet (and USB2) That's something which wasn't available for 20 years, a capable tinycc-driven kernel such as this. > 2. tinycc as-is is good enough for complete and reproducible bootstrapping, > thanks to the presence of its historical versions. This is proven by VSOBFS. That's a statement I tend to agree with, and raising questions over the rising complexity of tinycc itself, some instabilities and bugs noticed in recent times. Gladly tinycc-devel coped with all problems which were spotted. However, it is live-bootstrap which offers several bootstrapping paths for tinycc, beginning with the mentioned tiniest hex boot seeds. > tinycc as-is is good enough for complete and reproducible bootstrapping, > thanks to the presence of its historical versions. Concerning your VSOBFS, tccm, it mentions a few requirements for example: "1. a POSIX-like OS on a 32+ bit CPU as a host for the building procedure 2. an ANSI (C89) compatible C compiler for the host OS" This seems to indicate your project hasn't taken all the way down the rabbit hole, which of cause it doesn't need to and is a matter or priorities. In comparison live-bootstrap does NOT need a posix-like OS to begin with, it can be spawn from the pico-kernel/loader from rickmasters, and then FULLY rebuilds ALL dependencencies gradually from there. And that's too the place where BIOS/firmware bootstrapping belongs into, which actually is an unresolved issue. Maybe there will be some progress with other ARCH (riscv or aarch32/64, but currently that's all WIP and i386-tcc is the only known complete(!) system-integration available which meets some "trivial" acceptance criteria) tccm, i would NOT rule out minix myself either as a bootstrapping target or development host, since this seems what it is about, you're spawning from minix, not the worst choice by far, and myself too objects to latest linux5 and similar kernel versions fundamentally (see documentation at http://tinyfront.mooo.com/docs.html#Kernel) For practical reasons, mentioned above, i advertized a little for the linux-tcc fork maintained by myself, since all other precious kernel options such as fiwix or minix by design avoid the insane complexity of ACPI, SMP, USB on X86 etc. (simplified speaking) Bottom line, bootstrappable and tinycc are a revelation to the software industry. You couldn't over-exaggerate the importance of those projects almost. This isn't some biased "marketing", it's a fact, even when such projects contradict the interests of some shareholders invested elsewhere nowadays, uhum. On 2026-06-02 21:03, [email protected] wrote: > Dear Michael, > > I unfortunately feel unsettled by your promotion of bootstrappable.org and > of the Mes project on this list. > > TL;DR > tinycc as-is is good enough for complete and reproducible bootstrapping, > thanks to the presence of its historical versions. > This is proven by VSOBFS[1] which has fully solved the "trusting trust > problem", in contrast to the projects mentioned above. > > On Tue, Jun 02, 2026 at 09:15:15AM +0000, Michael Ackermann via Tinycc-devel > wrote: > > Currently, you may have a look at live-bootstrap project from > > bootstrappable.org > > I dare to say that the marketing of the projects you refer to is extremely > misleading. > > Please read on a bit, take a note of the wording [0] > ==================================================================== > "The Full-Source Bootstrap: Building from source all the way down" > ------------------------------------------------------------------ > "22,000 nodes rooted in a 357-byte program—something that had never > been achieved, to our knowledge, since the birth of Unix." > > This sounds impressive, new and groundbreaking? But wait, to build 22000 > interrelated packages from source has been done by other projects earlier, > what is new? A reliance on a 375-byte binary program? > Most of all, why is it actually called "full source"? > > Moreover, later down in the same text you read > > "the set of binaries from which packages are built includes a 25 MiB > statically-linked Guile" > > This is _not_ "357 byte". > > What does "full" mean in the above so called "full source" "all the way"? > > I asked and insisted, got no answer. > ==================================================================== > > That kind of bootstrapping does not[2] provide any real guarantees of > avoiding trust in binaries (to avoid the trust is the stated goal of > bootstrapping). To be useful, the above actually needs an addition of > multiple-diverse-compilation. > > Ironically, the latter suffices all-by-itself, as shown by VSOBFS[1]. > > What Mes and bootstrappable.org are doing is neither sufficient[2] > to avoid trust-in-binaries, nor necessary for this purpose[1]. > > ==== That's why pointing to their needs as a reference for tinycc > ==== bothers your humble servant. > > NLnet has spent money (not least EU money) on Mes, seems to spend money > on "live-bootstrap", for pseudo-solving a fully solved problem. > > Remarkably, an NLnet representative, when I asked, believed that the > binary seed in Mes was optional :) this is what happens when people do > not read the fine print? > > Full disclosure: I am the author of the actual solution, VSOBFS, published > in March 2023. It provides a guarantee that the binary output is fully > defined by the sources and _nothing_else_. > > This work did not cost anything for the society and the result is > in the public domain. > > 1. The VSOBFS work would be much harder without tinycc, thanks a lot! > > 2. tinycc as-is is good enough for complete and reproducible bootstrapping, > thanks to the presence of its historical versions. This is proven by VSOBFS. > > Best regards > tccm > [0] > https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ > April 26, 2023, compare to the date of VSOBFS announcement March 8, 2023 > [1] https://codeberg.org/keciav/vsobfs > [2] besides the "seed" itself you need binaries to examine it, even to > be able to put it in memory for execution > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel --
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
