What next? [Was: Re: LiveCD or No LiveCD?]
gerard at linuxfromscratch.org
Tue Feb 26 14:00:01 PST 2008
> 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
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
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
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.
More information about the lfs-dev