On Sat, Mar 01, at 02:59 taipan wrote: > Speaking for myself, i have an almost compulsive need to know _WHY_ i'm > supposed to do things a certain way, so additional 'pre-reading' would > be no issue for me, in fact it would be welcomed. But i can envisage > such an approach driving away the sort of people who have the mindset of > "yeah, yeah, just tell me where the 'GO' button is so i can build the > thing!". I don't think that is anyone here that doesn't like the verbosity. We are (all probably) suffering from that illness :), I know I do. And (If it's not the main reason, it's one of the most important) that's why we settled down in those (Do It Yourself) projects (I suppose).
> Does LFS want to cater to as wide an audience as possible, or would it > be worthwhile defining a 'target-demographic' at an early stage in the > planning process? You are absolutely right about that. The answer to your question quite possible can lead us to the right path. Personally I never gave real value to the ./configure && make && make install commands in the book; (However) it was the correct/stable build method that helped me to build a system at the first place which then gave me the time to explore the possibilities. Well we can speak about the possibilities, how you can extend the functionality of a system in its greatest extend, how you can secure a system [In that regard we can merge some of HLFS], how to create a nice functional environment to work, by choosing to work more closely with the one of the two/three D.E monsters or else how you can be a happy user using a minimal environment (I can help on that!), how you can take the best of the software with the right config's or the the right switches, how you can extend the functionality of a program by linking in it a library (we can talk a little bit more about the interaction between binaries and libraries [1]). And speaking about possibilities: We can extend our role in some places. To build an embedded system for example. We can also cooperate with upstream in a more systematic way; we can keep a changelog/history of the program (serious bugs that fixed, switches that changed, e.g., like new additions or removals from coreutils that happens often). We can speak more thoroughly for kernel changes in drivers, schedulers [Speaking about the latter, the scheduler in linux had changed, do we all know that? Possible yes, but it would be good if we had a tiny newspaper with all these little news (included changes in LFS organization, major toolchain issues, important updates, security problems, announcements: Voice of the community? Why not?] Is this all material "too much" for a novice? Quite possible yes, but I am totally sure *not* for the most of us. We want to make book(s) for *us*, and if there is audience, even better. Our only limit is our imagination and the man power. Speaking about the latter, it proved in the last days, that there are a lot of people willing to contribute. They just want the right environment. Speaking about the former, well again in the last days it proved our wi(l)d(e) imagination. So, Let's make it! Jeez I wish I had more time to contribute; my wife is pregnant again, and I don't know how I can handle four kids not to mention the dogs, etc... 1.http://linuxfromscratch.org/pipermail/lfs-chat/2007-July/027791.html -- http://wiki.linuxfromscratch.org/blfs/wiki/Hacking -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
