Jeremy Huntwork wrote: > The two main attractions of LFS are its educational value and the > flexibility it offers to fully customize every aspect of the system. > Whatever we do must focus on meeting those two goals.
I agree. > Merging the projects is a good idea, but I think, for the sake of > customization and flexibility, it will still be good to break down LFS > into 'modules' as Alan Lord suggested. I'm having a problem understanding this concept. If one wants a web server, then you only need LFS and a few packages from BLFS. If you want a workstation, then you need LFS and quite a few more packages from BLFS. What's a "module" besides a list of packages for a particular application? BLFS is set up to be able to jump around as necessary. I must be missing something because I see a "module" as fundamentally LFS and a list of links in BLFS. > For example, (I've mentioned this before, but I want to bring it up > again in light of recent suggestions) consider the whole toolchain > purity issue. LFS says it teaches users about what makes a Linux system > tick and what is going on inside it, but far more effort in the book is > focused on the idea of bootstrapping a pure toolchain, rather than what > is going on in the final system. I'm not sure what you mean by "going on in the final system". If you mean that we should explain the bootscripts, then I'm all for it. I've always thought the bootscripts should be listed in an appendix to both LFS and BLFS. If you mean to describe the inner workings of such things as the kernel, init, hal, dbus, or udev then I think that is beyond the scope of LFS. If someone want to write a separate book on those types of topics, then that would be useful. > I'm not suggesting that we abandon the bootstrapping method. What I'm > suggesting is that we make the temporary toolchain into its own module. It already is. Its called Chapter 5. > We give the end users a choice to completely bootstrap their own system > as in current LFS implementations, or, we let them download a packaged > temporary toolchain that we have generated based on those same > instructions and start with what now corresponds to chapter 6 in LFS. That is trivial. We could also give them an entire pre-built LFS with the exception of the kernel. Fundamentally, there is no difference between any LFS system except the configuration used in building the kernel. We can also give pre-built BLFS packages, but then we've reinvented Slackware. The point is that new users need to go through the process of building so they can learn how to customize and, primarily through mistakes, learn what *not* to do. > The main LFS module can be about the final system. Teaching users > _concepts_ of the system, locations of key config files, useful shell > tricks and tips, information about packages, examples of how to use the > packages in a practical way, etc, etc. This should make LFS somewhat > more accessible and easier for end users to pick and choose what it is > they need out of it. In many ways this sounds like the Linux Documentation Project. I'm sorry if this comes out sounding negative. Your ideas are worthy of discussion, but do I think there does need to be a contrary view. I understand the issues. I've thought about it quite a bit, but I really can't see adding much of the complexity being contemplated without actually detracting from the goals you stated at the top of your post. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
