On 2026-07-07 17:14, [email protected] wrote: > On Tue, Jul 07, 2026 at 11:52:15AM +0000, Michael Ackermann via Tinycc-devel > wrote: > > > I have to assume that you mean some very specific definition of > > > "complete". > > > > Yes. For example, i assume your VSOBFS relies upon a fully capable Minix > > operating system, without an answer how that got bootstrapped itself > > VSOBFS _creates_ a fully functional Minix operating system instance (a disk > image), including C compilers, among others tinycc for C99.
Allright. But what are the requirements to yield such a Minix system from source? That's related to the "circular dependency" i was referring to, which means you'll probably need a kernel and utilities to do so _before_ those dependencies got bootstrapped themselves. live-bootstrap instead resolved those issues. VSOBFS probably did not. And such a circular dependency is a critical engineering concern by itself, regardless of various security considerations. > See e.g. https://codeberg.org/keciav/vsobfs > > > > "Currently, there is no way to perform the bootstrap without > > > external preparations! This is a currently unsolved problem." > > > > > > Remarkably, this is a problem which does not seem to have a solution? > > > > A solution to this problem implies a regression back until 8/16bit 70s era > > computing with punched paper strips, which is neither practical nor relevant > > to the scope of bootstrapping a modern POSIX including C-toolchain. > > Nonetheless some approaches are discussed, including free/open hardware > > development (Gigatron TTL and similar), but current situation seems it's > > just > > not possible/feasible to bridge the gap towards 32bit POSIX from there. > > Exactly, in the sense that human-verifiable OS/toolchain bootstrap from binary > codes is no longer feasible nowadays. You're mistaken in this regard, live-bootstrap does implement a "complete(!) system bootstrap" and it is documented in great detail how that was accomplished. It just does not cover the 8/16bit realm by loading the builder0 nano-kernel/assembler from a punched paper tape. It's just not necessary to do so and a seperate concern, discussed among various other projects. > The good news (now already old news) is that it is possible to prevent > the "trusting trust" vulnerability, without such bootstrap. I am not implying at all VSOBFS should follow the same reasoning as live-bootstrap did, but you should not mistake VSOBFS as a "complete system bootstrap" when it isn't, regardless of whichever problem you might want to solve. > Tinycc was extremely useful in the implementation of the solution. > The small size of its code made it feasible to correct the incompatibilities > when building it by an older compiler. The live-bootstrap dependency chain does _not_ rely upon an "older compiler", but tinycc is spawn with a direct dependency chain from macro-assembly instead. And again this is a _very_ important difference to what you're claiming to having accomplished with VSOBFS. And this is my major grievance with various approaches and developers, claiming to having accomplished something anywhere close to what live-bootstrap did, but completely missed the most important minor little details. > Regards > /tccm --
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
