[bootstrappable] Re: GNU Mes 0.18 released

  • From: "Orians, Jeremiah (DTMB)" <OriansJ@xxxxxxxxxxxx>
  • To: "bootstrappable@xxxxxxxxxxxxx" <bootstrappable@xxxxxxxxxxxxx>
  • Date: Fri, 9 Nov 2018 12:05:01 +0000

Yes, if you are after ultimate security / trust, then your conclusion is 
correct.
I honestly hope that I am wrong; it'll be more interesting that way.

If, on the other hand, you trust whatever system people already have (whether 
Windows, or Linux, or a Mac, or whatever)
I really don't but it isn't about what I trust but what others trust.

but you just don't want to introduce any binaries that you do not understand, 
and you want to depend on as little as possible from the system (for 
robustness and trust)
Actually, you would want to depend on the things you already trust as much as 
possible.
For example if I trusted Bash, I could have gone straight to 
https://github.com/kanaka/mal/tree/master/bash
And simply ported MesCC to it; it would have been a lot easier.

then it makes sense to simply assume the linux kernel and bash (or some other 
way to execute code) and bootstrap from there.
Why not assume gcc or clang or tcc or any other binary? Guix certainly did with 
their initial bootstrap binaries (Janneke and I are working on reducing those)
If you want trust reduce your assumptions until all you have left is what you 
can trivially prove.

I think it was you who told me that autogenerated files are unacceptable, 
that everything must be hand written. ;)
That is correct, every single autogenerated file isn't to be trusted. Just like 
you shouldn't trust any binary.
They exist for convenience and as placeholders; nothing more. 

I had this idea before to use some nice source to source translation, say 
from C into some readable Forth, that would produce an autogenerated file 
seed.forth
It is fine if it is a placeholder to be marked as Generated and ultimately 
replaced by a hand written compatible.
But as I have repeatedly seen, people usually stop once they have that 
placeholder and never put in the hard work required.

but perhaps it might be more readable/shorter than seed.M1.
Well, we bootstrapped a FORTH from hex0 already.
It was abandoned when we figured out it was easier to write a C compiler in 
Assembly than it would be to write it in FORTH.

Having hand written a Garbage collecting-compacting Lisp in Assembly, A C 
compiler in Assembly and A FORTH;
I really don't get the FORTH is good for bootstrapping meme, because the 
experience I've had in regards to difficultly in bootstrapping is from Easiest 
to hardest is:
Hex0->Hex1->Hex2->M0->C -> Lisp -> FORTH

Look at Stage0's commit history
From hour 1 of cc_x86's existence until its competition; it was fully testable 
and trivial to debug.
Literally write a function, test it and then move on to the next function.
Once you finish the 220 lines required for the full lexer+tokenizer and a dozen 
or so lines of support code you have a C Compiler that works (it is terrible 
but it works)
Then at that stage you are just making your C compiler more and more useful.
Until eventually, you get to the point where it is good enough to compile the C 
version of itself (and maybe a few extra programs)

For all the hate C gets, its core is the easiest to bootstrap high level 
language.
And honestly, if Janneke didn't do so much lift with MesCC; I would have gone 
with Growing the c compiler provided by M2-Planet instead for pushing towards 
building Mes.c

-Jeremiah

Other related posts: