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 _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
