Arnold, I agree with your response. I don’t think it benefits from characterizing someone else’s work as “FUD,” “naïveté,” or “dishonesty.” Those kinds of remarks by [email protected] shift the discussion away from the technical issues and toward questioning the motives or competence of the person making the argument.
If there are technical inaccuracies, the strongest way to address them is simply to explain them and provide sufficient evidence. That allows everyone to evaluate the arguments on their technical merits without unnecessary personal commentary. We’re all trying to better understand an interesting issue. A respectful, intelligent exchange of facts and reasoning is far more productive than the rude, dismissive rhetoric in [email protected]’s post, which shifted the discussion away from the technical claims and toward personal judgments. Our TinyCC discussion group deserves better. —John M. > On Jul 12, 2026, at 7:18 AM, [email protected] wrote: > > Folks, > > Can y'all take further discussion off line? This back and forth sniping > at each other has been going on for a long time and seems to be only > marginally > related to tcc. > > Although I'm interested tcc's progress, all this stuff about boostrapping > isn't of interest to me. I can't speak for the rest of the list, but > I'd appreciate it if y'all would take this private. > > Thanks, > > Arnold > > [email protected] wrote: > >> Dear Michael, >> >>> On Sat, Jul 11, 2026 at 05:07:17PM +0000, Michael Ackermann via >>> Tinycc-devel wrote: >>> VSOBFS [...] i've placed this on a different page together with >>> Minix to clarify upon what the differences are and why this seems >>> insufficient >>> to solve some important bootstrapping issues >> >> I appreciate if you refrain from spreading FUD. >> >> Can in happen that you are still not aware that VSOBFS indeed _provides_ >> complete proven source-only-based >> >> 1. toolchains (at you choice, tinycc or gcc which has been tested) and >> 2. the OS environment needed for building, i.e. the kernel and the >> relevant utilities, at your choice, Minix or Linux >> >> Also you can have missed that you can repeat this process on virtually >> any Posix-like platform and verify that the result will be the same, >> reflecting only the sources used? >> >> Readily available are runnable tinycc-20a1ebf binaries and the matching >> C-libraries for both Minix and Linux, again, with proven provenance >> exclusively from the corresponding sources. >> >> To use them to build e.g. the latest tinycc in the same clean environment >> is straightforward and fully scriptable, in Bourne sh. >> >> As an alternative, extracting the binaries to a compatible environment >> of your choice (e.g. from the Linux disk image, to instead run under a >> modern Linux x86_64 kernel) is of course trivial. >> >> ---------------------------------------------------------------------- >> For extra clarity: >> >> Unaudited OSs och toolchains are sufficient to produce verifiably clean >> toolchains solely from the corresponding sources. >> >> The "trusting trust" compiler backdoor problem does not stand any longer. >> >> Trying to imitate the 1970-s manual compiler bootstrapping on modern >> hardware can be a nice exercise to study compilers and operating systems, >> but pretending to solve a security problem this way is either a sign >> of naïveté or of dishonesty. >> >> Cheers >> /tccm >> >> _______________________________________________ >> Tinycc-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
