What next? [Was: Re: LiveCD or No LiveCD?]

[Gerard Beekmans]

> 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