> Well this certainly is taking the discussion to the next level. I'm > interested in hearing more about possibilities and like you am anxious > to hear what Gerard has in mind.
I'm still at the office so I'll elaborate on this later, but to keep the momentum going I can at least summarize my thoughts. They are not finished concrete thoughts yet, just possibilities. They aren't even viable yet with our current resources. Call them pipe dreams for now, but that's how LFS once started - a pipe dream. With determination and a clear plan they *can* become reality if everybody rallies behind it and help out. The premise is simple actually. It's not a paradigm shift. We've all talked about it over and over again, rehashed it to death why it can't be done: combine our various projects. LFS in itself is a great exercise. Without parts of BLFS that end result isn't very usable for a system that you actually plan to use on a daily basis; server or workstation wise. Without a better ALFS integration, people are going to find themselves unable to use LFS in production on more than one computer. I could not see myself running vanilla LFS on the servers I maintain at work. One is doable but not even full time when you have other duties. When you end up with a dozen or more systems, you either get ALFS working, or you give up and go back to a distribution. Package management has been brought up by various people. It's a simple requirement if you plan to use the system for a while, besides just learning. ALFS would be able to tackle that problem as well. What if ALFS became the main way to do an LFS system? You might argue the fact that it takes away from the LFS methodologies. There is great benefit to be had from doing it all manually. But let's be honest - the majority of the book is running configure, make, make install. Does that really provide much educational value? It's not like you can actually read the output fly by on modern machines. In years past you could sometimes read along and get an idea of what it was doing. Not so much anymore. And not really important unless you're a programmer too and have an interest in knowing those details. The book can still provide all the educational value it does today. But concentrate less on how to run a configure script. It's far more valuable to know how Glibc works internally, and how it interacts with every part of the system and what it provides beyond just a C library, than how a configure script figures out where "gawk" lives. The actual installation process is the boring part of setting up LFS. After so many packages you lose focus and just wait for it to do its thing. We're better off talking about what exactly this package is going to be used for during the installation (automated installation or otherwise). You have to wait anyways. Use the time constructive and spend less time typing commands you already know. Take Glibc as an example. Throughout the book we learn a bit about it, but it's very limited. I am not suggesting providing the manual or info pages from each package in the book, but we can definitely expand on what's there. Sometimes a mini-tutorial style explanation could be beneficial for some packages. Take Perl as another example. Unless you already know what Perl is, you wouldn't be much wiser by reading the Perl installation page in Chapter 6. The most you get out of it is that it's some kind of programming language (though seeing it's called the Report Language you may not even clue in to the fact). We could provide a lot more useful information for just about every package we currently install. It would be more useful than the list of short descriptions. For those, if ALFS came into play, you can just look up the man pages when you obtain a list of installed files. The space used in the book can be better spent. The book will essentially become less of an installation script interspersed with some text and more of an actual book teaching concepts, decisions, justifications, etc that make for a working Linux system. As a closing remark - we offer this while LFS teaching endeavor with a set of tools to get the job done that target a variety of people. A bootable CD that can be used on a system without Linux pre-installed would be one of those tools (aka what started this thread). Whether it's a LiveCD complete with an Xorg system or not is immaterial. The basic idea is that we have a boot CD that can double as a Rescue CD as well when we mess up Grub. Why not use an LFS CD to repair/install an LFS system rather than use somebody else's distribution CD to repair/install our own LFS. LFS started out as more of an LFS+BLFS combined (read the 1.x series). Then it was decided to split the core of LFS from the optional parts as the optional parts are too user specific. Not everybody likes a chosen email program, web browser, etc. I don't know that we want to merge LFS and BLFS in its entirety but maybe ALFS can become the "official" glue between the two. If nothing else, to take away the manual burden of trying to install all the needed packages. I groan when it comes time to install something like KDE and Gnome. That's a week project to get it all just right unless you can spend hours upon hours for a few days on it. Shouldn't have to be. I'll leave it at that. Some food for thought where I believe we must improve in order to move forward. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
