Brennan Vincent wrote: > I mean no offense, but what's the value of installing LFS from an installer? > I thought the real point of LFS was to do everything by hand, to learn in > detail how a Linux system works...
We are far from the first people to have the idea of automating LFS: http://www.linuxfromscratch.org/alfs/ One could even argue that build systems of "Gentoo" and the BSD systems are automating a *nix from scratch .... However, we've seen that with some build systems (seemingly to deal with growing build complexity) the goal of automation over-takes any goal of education. Even if the goal of education was there to begin with, after a while the build looks like deep sorcery to the new comer. That's clearly against the point of LFS. Before I had completed the build of an LFS system, being able to do it all by hand was the most important goal. Now that I've gone through the process a number of times, and I actually use LFS machines for normal tasks, being able to repeat the process reliably and efficiently becomes a goal. And yes, it is in sharp focus for me that any LFS installer that obfuscated the steps would, indeed, be taking away one of the main things I really like about LFS. Any automated LFS-like system should make it clear how to perform the steps by hand, and easy to reproduce those steps by hand. For pure practicality, this is important because it seems that every time I build a system, something has changed. Somewhere in the course of things I end up needing to walk the steps by hand very slowly and very carefully and take notes about what is different between the book and reality ... especially when using newer versions than found in the book. But more important, I completely agree that a great way to learn, involves walking it all by hand as a novice. And to that end, it is even more important that the steps and process be transparent. What I especially like about the litbuild work that Brett Neumeier has been doing is that it is, in effect, another approach to constructing an an LFS-like book. Instead of being XML which is translated into HTML, the format of litbuild input is text files which can be read as plain text, transformed into nice HTML, or executed as a script. Here is an example: http://tiedyedfreaks.org/eric/src/freesa/automation/packages/gcc.txt or: http://tiedyedfreaks.org/eric/src/freesa/automation/packages/glibc.txt By keeping the instructions in a format which remains comfortable to read (and more importantly: update) as plain text, the goal of understanding the "what" and "why" is easier to serve: the barrier to any change is low, especially adding some additional explanatory text as something new is learned. A good way to go from novice to intermediate experience is to use LFS systems for "real work". Of course this means going past the bash prompt and heading into building a complete system. I lean on http://cblfs.cross-lfs.org/ rather a lot for this. For me, doing "real work" with an LFS system also translates to a desire to automate the parts I'm comfortable with so as to let me focus on the "new" stuff: things like "what is this new GMP dependency?", other changes in the process of building various programs, and dealing with rolling through upgrades over time. (I find "package users" very handy in that respect.) So, in the end, I think "the real point" of LFS is to learn, and automation can encourage this, especially for the intermediate user. Cheers, -Eric litbuild, FreeSA, and Brett's mod of "package users" can be found at: http://www.freesa.org/ -- http://www.freesa.org/ -- mobile: +31 620719662 aim: ericigps -- skype: eric_herman -- jabber: [email protected] -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
