Robert Daniels wrote: > I've been thinking about this 'modules' idea, and also the idea about > the automatically generated personalized book, and I came up with the > following: > > 1) Bootstrapping a toolchain - Pretty much equivalent to Chapter 5. > 2) Package Management - Choose your package manager, learn how it works, > why they exist. Maybe a basic scripting tutorial as well. > 3) Basic CLI - Chapter 6. Add gpm, choice of text editor. > 4) Security - How to secure a linux system, cover options like PAM, > SELinux, sudo, and whatever else is appropriate. > 5) CLI Apps - Applications to make a system useful from a command line. > Wget, text web browsers, etc. > 6) Desktops: Probably one of the larger sections. Cover KDE, Gnome, > Xfce, and more basic window managers. Also include desktop frameworks > like Xorg, HAL, and DBus. > 7) Desktop Apps - Things like office suites, multimedia applications, > graphical web browsers, etc. > 8) Server Software - LAMP stack and whatever else is appropriate for a > server, cuz I don't really know. > > A lot of the structure here looks similar to what we already have. 1-3 > pretty much have to go in order, and I think 4 should also follow > immediately after, but the rest is fairly nonlinear and/or optional. >
Looks about right to my unskilled eye, but i'd say the 'linearity' of modules 1 & 2 would be a bit trickier to implement than it initially appears... If you were to take the 'diy-linux reference-build' as an example, Greg caters for the option of package-management during the 'temp-tools phase' (or Chapter 5, or module 1, whichever you prefer), which is a *must* for any users wishing to take the PM option during Chapter 6. Furthermore, he provides his own build-scripts, either for illustrative purposes or to be used outright, which include 'temp-tools' (Chap-5/module-1) in their automation-process. So sections on scripting/automating & PM ought to at least be linked to at an earlier stage in the process than _after_ the bootstrap has been completed. 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!". 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? Feel free to correct any misconceptions i might have voiced - i'm fairly thick-skinned. ;) taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
