[Axiom-developer] RE: Bootstrapping

[C Y]

--- Bill Page <address@hidden> wrote:

> On November 9, 2005 3:15 PM C Y wrote:
> 
> > ... the chicken-egg problem remains.
> 
> Why do you keep on insisting that it is a problem? At most it
> is a paradox to which we must consider a solution. To me it
> seems like you are arguing that chickens should not come from
> eggs but rather from some lower life form - maybe grow on
> trees? ;) Sorry for my poor attempt at humour ...

I seldom get asked that question - somehow explaining that the chicken
was bootstrapped from an earlier evolutionary form, which was also
bootstrapped from an earlier form, etc. etc. back to when some protein
got bored and decided to have a party in the form of early DNA seems to
kill the joke :-P.  (Although, come to think of it, the egg probably
did come first, in that sense ;-)

It might not be a problem - I'm just used to thinking binary dependance
= bad.  It's a holdover from not having the correct Windows computer
you need to run a binary around and being Totally Out of Luck ;-). 
Just think where we would be if the original Axiom had only run on
AmigaOS, or one of the early pre-Unix OSs, and those were the only
binaries we had.  I don't think either Linux or BSD folk are totally
confident their systems will survive 100 years - "current" operating
systems may be totally different by then.
 
> > I would like the capability to exist for someday, a thousand
> > years from now, someone with only the bare electronics and the
> > source code to be able to re-create a running system.
> 
> I think the simplest way to achieve this would be through what
> is known as a byte-code interpreter: in the source code you
> include the machine code for the compiler but not the machine
> code for a real machine, but rather for a simpler abstract
> machine for which you also provide the complete documentation.
> Then the problem becomes first finding a way to simulate that
> abstract machine on whatever hardware you have available. Having
> done that, you load the provided abstract machine code and
> compile your first iteration of the compiler.

Cool.  I wonder if there is a project working on that somewhere.  The
ultimate hacker challenge - given only text files and bare hardware,
make Linux and all the software it runs work :-).

Sure would make a great time capsule entry.  (Sorry, this is kind of an
idea I like - how do we document our current technology in such a way
as to provide all necessary information from going from raw materials
only to where we are today.  Bootstrapping a computer fits in there
;-).

> The biological analogy seems to remain quite valid. The
> abstraction machine code is the chicken's dna. :)

Works for me :-).

> > Symbolics machines were actually very interesting in this
> > respect, since IIRC they actually DID implement Lisp at a
> > machine level, but they unfortunately didn't survive
> > commercially.
> 
> Actually all of these machines used microcode to implement
> a lisp interpreter. Someone had to write the microcode and
> probably used a compiler.

I suppose.  I wonder if bare metal could be made to implement circuits
for Lisp functions...  I suppose going down that route wouldn't make it
an ordinary computer at all.  Mapping Lisp directly to semiconductor
physics... OK, I should stop now.

> > ...  There are a variety of [lisp] compilers that [are
> > bootstrapped] - cmucl and sbcl among them, IIRC, but I think
> > there has been some consideration of developing the possibility
> > of using clisp, which CAN be bootstrapped with gcc, to build
> > cmucl and sbcl.
> 
> As you say, writing a lisp compiler in lisp is a very common
> strategy. I am sure the Axiom developers where aware of this.

Right.

> > Basically, I think there is kind of a mantra that the fewer
> > bootstrapped software dependencies a system has, the better.
> 
> As far as I am concerned that is only because these people
> do not understand the issue. Or perhaps it is because they
> are concerned with issues - such as security and recovery
> that are quite different than building the best language for
> a particular job.

Well, I'm not sure you can separate security and recovery from the job,
since if either fails the job goes with it.

Years ago Ken Thompson proposed a diabolical attack on a computer that
could be made by putting a trap door in a compiler, which would
automatically build it into all software and subsequent versions of
itself, undetectibly.  (I think this is the article: 
http://www.acm.org/classics/sep95/) That kind of thing makes people
(especially open source folk, I think) suspect all binaries, and for
good reason.

> > No one denies gcc is such a dependency, but the introduction
> > of other such dependencies is not a popular idea, because of
> > the reliance of such systems on some available system being
> > able to run the original binary. That's an unpopular assumption,
> > just on principle.
> 
> Stupid principle.

Not in light of things like Ken Thompson's proposed attack.  Security
people may be paranoid, but on the internet paranoia is a virtue.  I
have wondered about that in the past, with both Maxima and Axiom - what
kind of security holes might be present?  Of course a trustable OS
would remove the need to worry about anything more than the integrity
of our own calculations, but no such system exists. (Yet.)

Anyway, we're pretty far off topic (sorry, list!) but I think you have
hit on the key point that supports minimizing bootstrapping - it
reduces the number of unverifable programs you must trust.  Security is
probably the single biggest lack of today's computer infastructure, and
I'm keeping my fingers crossed that Coyotos comes through and changes
this.  Ideally there shouldn't be ANYTHING on the system you can't
trust, but of course it always comes down to something (even if it's
only the circuit tester used to check the output of physical circuits.)
 

Cheers,
CY


                
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com