GNU Mes 0.25 released

[Andrius Štikonas]

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)

> 
> My quick search of a definition on the web did not uncover anything like
> your suggestion of the "very thing" either.
> 
> > So by citing some other project that allegedly got there first, by
> > depending on an already existing C development toolchain; it seems like
> > comparing apples to oranges or maybe even broccoli.
> 
> The blog pretends to be "there" first, you are trying to redefine "there"
> to fit Guix but not VSOBFS.
> 
> * 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).
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).

> * 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.  In fact reproducibility is far easier to achieve, because
you don't have any unknowns (and paths in particular) coming from initial toolchain.

> * Both of the contending platforms (Guix and VSOBFS, alphabetical order)
> can be used to bootstrap further into anything else and/or each other.
> In this meaning they are equivalent.
> 
> The feat accomplished and presented in the contended blog
> entry is making a certain almost-fully-from-source bootstrap to
> host a Linux distribution. That's nice.
> 
> At the same time the blog in question goes out of its way[2] to create an
> impression that there haven't been any from-source-bootstrap-solutions
> comparable to the one it talks about.
> 
> This is very far from a fair depiction and this is where the potential
> for distrust and flames comes from.
> 
> In other words, the blog strikingly pretends that VSOBFS never
> existed, despite VSOBFS having presented a pedantic solution to
> source-only-bootstrap and illustrated that a binary seed is redundant.
> 
> > and replying to each
> > and every post referencing the alleged "false claims" seems actively
> > disruptive to me.
> 
> A post publicly promoting an untrue priority claim, in this case regarding
> "Full-Source Bootstrap", is an insult against someone having made a
> substantiated corresponding claim earlier.
> 
> Notably, this insult has been repeated despite my protests.
> Yes, I try to be actively disruptive against unfair practices.
> 
> Misrepresentations disorient the actual people who the solutions are
> meant to benefit. They affect also where public resources are invested.
> 
> 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?

> 
> > live well,
> >   vagrant
> 
> Regards,
>  an
> 
> [1] "a form of stipulative definition which purports to describe the true
>     or commonly accepted meaning of a term, while in reality stipulating
>     an uncommon or altered use, usually to support an argument for some view"
>     https://en.wikipedia.org/wiki/Persuasive_definition
> 
> [2] For a casual reader, this is what caused my reaction:
> "[...] something that had never been achieved, to our knowledge, since the
> birth of Unix.
> We refer to this as the Full-Source Bootstrap"
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20231114/89e0d9d3/attachment.sig>