TL;DR : [3] Hello Aleksandar,
On Sun, Jul 12, 2026 at 09:21:09PM +0200, Aleksandar Kuktin wrote: > >On Sun, 12 Jul 2026 18:29:44 +0200 > >[email protected] wrote: > > > Is there any other reason than to avoid the "trusting trust" compiler > > backdoors, to pursue the bootstrapping which you envision? > > From time to time, people invent new computers. Including new ISAs, > but also brand new system architectures (well, nothing is really new, > fifties and sixties offer a goldmine of interesting computing ideas). > These new computers require bootstrapping software onto them. This is not true. They can get software cross-built on existing platforms. Since many years ago it is state-of-the-art. Given the availability of sufficiently powerful computing platforms and compilers there was no longer a need to do bootstrapping from the binary CPU codes. (Did you possibly by "bootstrapping" mean "creating"? These are not synonyms, especially not in this discussion.) > Sometimes, the systems are specifically designed, for their own reasons, > in a way that breaks the assumptions of current POSIX environments. In > these cases, bootstrapping is the only option. This statement is not true either. I interpret the first part as "it is possible to build a system which is not suitable/capable to run a Posix environment". The other part "then bootstrapping is the only option" does not follow from the first. It is straightforward to cross-build between platforms of different hardware and/or software architectures. Cross-building is also a lot more efficient than bootstrapping a native compiler for a new platform _on_ that new platform from scratch. > Alternatively, from time to time people invent new operating systems > that they desire to bootstrap. Perhaps because the systems are so alien > to the current crop bootstrapping from scratch really is the cleanest > way to get going. Yes, there is always a possible reason to do something: one's personal desire. If you mean that in some scenario bootstrapping would lead to a result better (for others) than by cross-compilation, then please present such a scenario. > Next, bootstrapping can be and is a way to instantiate a new system > without relying on an interconnected mess of "bloat", as is common in > modern GNU/Linux distributions. Bootstrapping implicitly limits the > dependency list to a very small number of requirements. This is not true. The amount of sources and intermediate binaries which bootstrapping implies is by design larger than at cross-compilation, because it includes the (otherwise historically accomplished by others) intermediate steps. Also: 1. Remarkably, all the "old-style-system-bootstrap" projects which I know of are using modern OS environments for the development. 2. At the same time, to even give the necessary data to a "bootstrap" to start it on a new computer, you can not avoid using some pre-existing tools, quite probably your modern Linux distribution. 3. On top of that, if you mean to bootstrap a modern OS environment, this automatically and regrettably implies all the bloat of it. > This promotes permacomputing. If at all, then probably to the contrary, given that your preceding argument does not hold. > Furthermore, bootstrapping teaches people how to create software > without relying on a ready-made computing environment. This is > invaluable for embedded system design, or even for building using old Actually, to the contrary, embedded systems design is heavily rooted in cross-building and _not_ in bootstrapping a build environment from CPU codes. Thus I have to dismiss your statement "to create software without relying on a ready-made computing environment ... is invaluable for embedded system design". At the same time, learning the intimate internal details of the systems is of course valuable. > technologies. An interesting example of this many people here will > probably like is https://www.bdsoft.com/resources/bdsc.html , a C > compiler (predating K&R C) for CP/M, that requires you to understand > the entire software environment to really unlock it's full power. This is hardly relevant for the discussion, but yes, there are many software systems which require one to understand all the aspects and details, to be most useful. > (There's another, confusingly called Tiny C. And I remember seeing a > third C compiler that was also a variation on the name "Tiny C > Compiler".) You have probably seen TenDRA. It uses the "tcc" name. > Bootstrapping teaches skills relevant for all these fields. And, to So we are back to learning/teaching as the only rational (in contrast to emotional) reason to do development of bootstrapping. > > What is wrong with Posix binaries? They are easily available and it > > does _not_ matter for the sanity of generated artifacts whether those > > binaries were auditable. > > It matters, but for this you need to go beyond your assumptions. The following part indicates that you were not able to read about VSOBFS? > This following section tries to show the limits of VSOBFS, and to make > sure I'm not misunderstanding anything, I went to Codeberg to check, > but the website tells me "Access denied". Thus, what follows may > misunderstand VSOBFS' mechanism of verification but I think it doesn't > because hard logic limits possible options to, I think, only the one I > discuss below. That's unexpected. If your ISP is somehow blocked at Codeberg, you can work around this by e.g. using the Tor Browser Bundle. The site is up and answers to unauthenticated web browsers. > As far as I understand, VSOBFS builds the same binaries on a > heterogenous set of host systems and compares the outputs. If the > outputs are bit-for-bit identical, the conclusion is that there were no > implants added to them. To avoid your uncertainty, I strongly suggest you to try to reach the website[1] once more. Given your interest in understanding the exact assumptions and the reasoning, please read "Limits to verifiability"[2]. > The conclusion is correct, but only in the confines of it's unspoken > assumptions. The VSOBFS assumptions are carefully written down. What you analyze was your guesses and not what VSOBFS does. I hope that reading [2] will clear the picture. > But the same outcome can happen in one other situation: if all the [... skipped ...] > not of equally-dishonest builders. I appreciate your willingness to analyze the possible problems in depth. I am though pretty unsure whether such a discussion is on-topic here.[3] ------------------------------------------------------------------------ To conclude: Thanks for your arguments Aleksandar. Unfortunately, the only real one of them was about usefulness of development (or analysis) of compiler bootstrapping as a means of learning. In this sense bootstrapping per se is probably outside the technical direction of this list, unless a student or her teacher need some help with understanding the internals of tinycc. Is there any other reason for development of bootstrapping which you would substantiate? The "hack value", i.e. one's pleasure of solving a technical puzzle can of course always be one's reason to do a development project, but I am specifically looking for practical usefulness to others. Kind regards /tccm [1] https://codeberg.org/keciav/vsobfs [2] https://codeberg.org/keciav/vsobfs/src/branch/main/ltv20231123.md [3] Dear list, please tell when something is not appropriate. _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
