gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] bootstrapping


From: Thomas Lord
Subject: [Gnu-arch-users] bootstrapping
Date: Wed, 19 Oct 2005 22:10:19 -0700

 Matthew> In fact the very word 'bootstrap' implies a circular
 Matthew> dependency, so it's an odd sort of complaint!

The goal state of bootstrapping has a cyclic process -- e.g., a 
self-compiling compiler.  Such a computing system is a feedback
based amplifier for coherent energy: you put hacks in and the
whole system defies entropy and becomes more organized.

The art of bootstrapping is starting with a system that doesn't
have the feedback cycle you want and building the acyclic tower
that gets you there.

The social responsibility concern for bootstrapping the kinds of
things that comprise the Internet and various intranets is that 
one ought to be prepared to retrace the bootstrapping paths in 
the event of various kinds of disaster.

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

  Alfred> I agree, but then you'd kinda need to ditch the whole GNU 
  Alfred> project into a trashcan, and start over (maybe reusing 
  Alfred> existing code).  Simply not a option, so it is better to do 
  Alfred> this in a evolutionary manner.

Isn't it contradictory to talk about starting over and reusing existing
code in the same breath?

Anyway, this can be perfectly "evolutionary" and consistent with GNU's
state.  We're talking about filling in gaps in the bootstrapping tower,
cleaning up the configure/build infrastructure for core apps, and 
promoting a second configure/build infrastructure for other apps.

There's even, arguably, an underdeveloped market need in the embedded 
systems area.   Lots of companies make various kinds of locked-box
network filters (e.g., protocol accelerators in a box).  Lots of these
use a GNU/Linux kernel.  Lots of these, afaict, get their OS in very 
tenuous, ad hoc ways and would be way better off if they had in-house
source and a low-key way to maintain that.   Many of these systems 
wind up deployed in surprisingly life-critical places and so the 
customers would benefit from a bit more robustness here too.

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]