[Gnu-arch-users] Bootstrapping theory and practice (re Alfred)

[Thomas Lord]

 Tom> The first phase of autoconf relies on GNU m4 and perl.
 Tom> Increasingly, in practice, it relies on automake and libtool.
 Tom> While jocularly dismissed in the autoconf documentation, the
 Tom> circular dependency between m4 and autoconf is a clear
 Tom> bootstrapping bug.

 Alfred> I fail to understand why this is a bootstrap bug, yes, there
 Alfred> is a circular dependency there, but not one that causes any
 Alfred> grief.  As compared to some weirder ones--GNU ada anyone?
 Alfred> You'd also have a circular dependency in package-framework if
 Alfred> it gets used, consider the shell starting to use it, then you
 Alfred> need a shell to configure the shell, and viola, circularity.
 Alfred> Basiclly, you can't come around circular dependencies for
 Alfred> this type of thing, and I don't consider it a serious
 Alfred> bogisity.  For things that produce architecture dependant
 Alfred> output (compilers) this is far more important though.

Ok, so, I have to say why the circularity is a bug and why it isn't
necessary and in the course of that I'll add some "things we should be
doing".

I spend some of my time thinking about forseeable disasters and what
they imply and how to be prepared for them.  "Continuity of
operations", "emergency responses" --- I eat that stuff up.  A
frequent source of agitation for me, these past couple of years, is
the pitiful state of my first aid kit as supplies expire or get used
up and I can't afford to restock.  Don't call me a Boy Scout (those
homophobes) but there are some values and priorities in common there.

One shouldn't count on having much of a working, trustworthy computing
environment when one needs to do an emergency bootstrap with little or
no help from the (likely largely devastated) net.  We really want lots
of edge nodes to be able to come back on their own, presuming such
things as heavily compromised binaries on what they've got that's
still running.  No, really.  Stop laughing.  I'm deadly serious.

The good news is that maintaining that level of operational paranoia,
done right, can have so many pleasant side effects on a day-to-day
basis that it can more than pay for itself.  One example dear to my
heart is pedagogy -- a clear bootstrapping path, maintained and
renewed across time, requires/enables students learning/rebuilding the
stack from bottom to top.  Another example: it helps us guard against
emergent effects of a stack that slips out from under control. (While
the Y2K bug, well, wasn't, the difficulties people had in making that
so and preparing in case it was so are instructive -- we saw a
generational crisis there).

The circularity is a bug on principle and in forseeable, time
critical, life critical practice.  What happens when the cycle breaks?
When someone needs to get stuff working but is faced with a busted
shell /and/ a busted M4?

An only slightly exaggerated analogy from a long-ago mentor concerns
the state of metallurgy.  If we lost access to steel refineries (he
claimed and I believe him), we'd have to reconstruct a lot of historic
metallurgy just to be able to build equipment heat-tolerant enough to
use in making steel.

And it's not like it's that damn hard or expensive.  You pick a
bootstrapping environment above which applications reside and below
that you build a tower whose foundation is the raw-iron-du-jour.

It's a question of building Stuff That Works and can be maintained, 
human-scale, generation after generation /as opposed to/ stuff that
that just takes the earlier work for granted and hopes for the best.
New Orleans vs. Amsterdam.

You mention compilers -- well, don't get me started on that.  It's a
glaring flaw of the GCC project that it neglects the bootstrap path.
Gimme an environment I can print in a small book and "toggle in" --
forth-ish say (something I respect about some Sun hardware).  Then a
tiny K&R-ish, non-optimizing C on that.  Then a tiny, simple compiler
that's enough to bootstrap GCC in that C subset.  Then we're in
business.  Other towers are possible and worth considering, of course.

  Alfred> I still have problem to see how the two phase thing 
  Alfred> [with autoconf] is a problem.

The GNU project's success would hardly have been impeded by treating
a GNU shell (not necessarily bash) and GNU Make as prereqs for
everything else.

Autoconf is almost entirely justified in its origins by not doing
that.  Most of the remaining justification could be eliminated by
floating a nice portability library rather than trying to juggle
libc variants.

If Autoconf were never anything more than the tool used to build a GNU
shell, GNU make, and maybe a portability library, I would have far
less reason to complain.

-t