GNU Mes 0.25 released

[ahojlm at 0w.se]

Thanks for taking the discussion seriously Andrius.

On Tue, Nov 14, 2023 at 02:56:57PM +0000, Andrius Štikonas wrote:
> 2023 m. lapkričio 14 d., antradienis 14:27:11 GMT ahojlm at 0w.se rašė:
> > The term by itself does not even mention the programming language(s)
> > involved.
> 
> That's because the process involves multiple languages. Do you want it to be called
> Bootstrap of C/C++Bash/Perl/Bison/Scheme/... (and many more)

Indeed, Vagrant's point was possibly the use of a toolchain,
irrespectively of the exact programming language - I don't know.
Regardless, the cited remark of mine does not affect the reasoning
in any way and hence was totally redundant. Sorry (seriously).

> > * Why is the use of a random C toolchain in a solution "less of a
> > solution" than a use of a random binary loader? How do you verify the
> > latter without doing the bootstrap on various loaders and comparing
> > the result?
> 
> You read the loader. E.g. hex0 on x86 is 256 bytes (and not insignificant part is elf header).

By a "binary loader" I mean the tool which is between one's brain and the
RAM/ROM to be executed at the power-on or a corresponding hardware event.

The tool has to be present, doesn't it?

> At these sizes well commented machine code is readable:
> https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0
> (or https://github.com/ironmeld/builder-hex0/blob/main/builder-hex0-mini.hex0 for baremetal version)
> and if you look at binary file it's in 1-to-1 correspondence to source file (except for comments that are not in binary file).

Even while given the specific knowledge one can *relatively* reliably
audit what a certain small binary code would do on a certain CPU model,
how can we really be sure that it is those bytes which will be in RAM
and will be run, and nothing else?

Besides putting the codes into program memory, even examining a file is
hardly possible without a (binary) implementation of the corresponding
file system and a (binary) viewing tool. By what means shall these
have-to-trust components be eliminated or provided?

The "direct" data operations were feasible when CPUs consisted mostly
of discrete components and there were physical switches to set separate
bits in registers or RAM. Then a bootstrap from binary was relevant and
has of course been carried out.

Now very few persons/organisations have access to such hardware, so
even if those would repeat the process, they are probably too few for
us to easily take their word about provenance - they can be corrupt
or make mistakes.

The rest of us have to live with modern hardware which assumes to be
handled using pre-provided (binary) programs in one or another form.

Besides starting the first binary, there is of course a similar issue
with basically all i/o. There is no longer a hardware register which
pushes bits to a line (or does DMA in a more complex scenario), but
systems-on-chip with a lot of software inside.

Now let me repeat the original question: Why would the use of a random C
toolchain in a from-source-bootstrap solution be "less of a solution"?
VSOBFS explicitly addresses breaking free from the trust to the needed
binaries (among others a C-toolchain, but also a kernel and general-purpose
tools) - by postulating multiple, diverse, unrelated bootstraps.

> > * How is the result (if reproducible and verifiable all the way)
> > of one of those routes better than the corresponding result of the other?
> 
> Of course it is reproducible.

I did not question *this*. It is the condition in the question.

> In fact reproducibility is far easier to achieve, because
> you don't have any unknowns (and paths in particular) coming from initial toolchain.

We may have misunderstood each other, then don't hesitate to elaborate.

Source-based bootstrapping in VSOBFS uses arbitrary binary ANSI-C-toolchains,
in Guix it uses a binary seed and binary loaders.

The question was not about the efficiency or completeness of the
corresponding methods, but _if_ both leverage their promises, what is
the difference in the result?

My answer is "both yield an OS in its binary/runnable form, with full
certainty of the provenance, which was the stated goal of bootstrapping,
thus: no difference" - but I am ready to listen to your perspective.

> > I do not chase any funding but I care about being recognized as the first
> > at full-source Unix/Posix bootstrap.
> 
> When was it released?

The 8th of March 2023, see the list archive.

Kind regards,
 an