Some points to criticize about LFS
Mark A. Friedman
mafmailbox at earthlink.net
Sun Aug 29 01:14:55 PDT 2004
I believe that Gueven makes some excellent observations about the
focus of Linux From Scratch- not that there is anything wrong or of
poor quality with the excellent LFS approach- just that there are
alternative or additional or missing perspectives to be considered.
(I believe Gueven's biggest language "mistake" was use of the word
"criticise" rather than "suggest" in the title of his post.)
Last summer, I taught an "Introduction to Linux" course at a large
liberal arts university. The course used a book that centered on the
installation and customization of Red Hat Linux. The course would
have been more accurately titled "Introduction to System
Administration with Red Hat Linux." I was not particularly happy with
the content of the course nor the text for that department at that
particular school, but I was brought in too late to change anything.
It was also last summer that I discovered Linux From Scratch and I
have given some thought to how I would use LFS if I was to teach such
a course at a college in the future. I believe Linux From Scratch
would provide an *excellent* lab manual for the type of course I would
teach, however, I would have to do much, much more work on
discovering, researching, outlining and describing the concepts,
principles and rationals involved in putting together a Linux system.
I would want to present: Why was this package included? Is it
necessary? How is it necessary? What were the considerations for
choosing this package over its alternatives? What are the
alternatives? You might imagine that an appropriate text could be
written that was more textual and more conceptual along these lines
and perhaps more graphical as well.
Gueven pointed out that much of the effort of the Linux From Scratch
team appears to be on sorting out the technical details involved in
keeping up with appropriate packages and appropriate releases for the
next version of the book. (I have not examined successive versions of
the book in detail to know how much more *educational* matter was
added from one version to the next version.)
However, for sure, this work is a necessity for the success of Linux
From Scratch. Readers would be less interested in investing the time
to educate themselves through the LFS process if there was a
significant gap between LFS and the software which was preferable or
appropriate to use at any point in time.
At the same time, consider the amount of knowledge that the LFS team
gains in moving from one version of the book to another which is not
passed on to the readers of the book.
Linux From Scratch advertises itself partially as a means of educating
its readers on how to build a custom Linux system, however, through
the LFS process, one learns how to build a custom system not through
reading the book, but by experimenting after one has read the book.
(I value LFS (and related projects) as a educational tool as much as I
value LFS as a book.)
Consider what might be analogous in a book that claims it will teach
one how to use a programming language to solve different types of
problems, (e.g. an introductory or intermediate programming book in an
introductory or data structures course).
Suppose such a book solely included a listing of one large program and
comments on how programming language statements in that listing were
used to build that program, and the reader was left on his or her own
to learn to build other or custom software solutions (to use a
programming language to solve different types of problems) by later
experimenting with those programming language statements on one's own.
Most would claim that such a book was deficient in living up to its
claim to teach "putting together a custom program" as that material
was never discussed in the book. Most would see it only as a book
that discussed one particular software program.
The Linux From Scratch book contains a few "teasers" (e.g. "This book
allows readers to fully customize Linux systems...", "Another benefit
of LFS is the ability to create a very compact Linux system.", "...you
are empowered to audit everything and apply all the security patches
desired.") in that in addition to the material presented in the book,
those aspects of understanding a Linux system were among the aspects I
most wanted to learn about. There was a bit of disappointment that
understanding those aspects of a Linux system were left as "exercises
for the reader."
Here are some ideas on how to augment Linux From Scratch to fill out
it's meeting its objectives.
1) Add a chapter that discusses some of what was learned by the team
during the evolution from one version to the next version of the
book (e.g. "Moving from LFS 6.0 to LFS 6.1"). Why did packages
change? Why did package versions change? Why did package versions
not change? Why were some packages not considered? How and why
were the bootscripts or configuration files or symbolic links
changed? Those chapters would provide an interesting and
educational understanding of the history of the project and Linux
Systems in general later in time.
2) Add (appendix) chapters on the experiences of LFS readers in
customizing their systems after building the concensus LFS system.
Include those as case studies. Include "How I adapted LFS to build
the minimalist system" or "How I adapted LFS to build the secure
system" or "How I adapted LFS to build the bleeding edge system."
This has the additional benefit of offering a way for those who
want to deviate from the concensus LFS system to directly
contribute to the book. (Perhaps this is what hints accomplish but
perhaps these chapters are particularly useful to a wide audience,
or of carefully selected topics, or written particularly with
education in mind.)
3) Add some sidebars to the book. This was the approach taken by the
Red Hat Installation Guide which I used last summer. For example,
a sidebar on the Linux boot process in the section on installing
grub, or a sidebar on scripting languages when installing PERL. I
know of no text that I would want to use for a college course,
however, Linux From Scratch could build up to such a text.
4) Offer some questions or suggest some exercises for the reader.
On a side note, I've also given some thought to what enhancements I
would make to LFS to increase its utility in a classroom laboratory
setting: where there are a group of students who are going through the
LFS process, who are working individually, but also on a
somewhat-common, somewhat-fixed schedule. Mostly, I've thought about
ALFS or package-type capabilities. (Yes, I know that there has been
discussions about LFS and package capabilities, and that LFS is an
educational project rather than a distribution.)
In a laboratory classroom setting, for educational efficiency and
flexibility, I'd want to be able to verify the correctness of a
student's work after installing some package. I'd want to be able to
fix the installation of a package, or bring a student's machine up to
some point in the process, or find deviations from the expected state
of the system at some point. Or, I'd want to be able to have the
students "fast-forward" past some part of the compilation/installation
process because of time constraints or because it was less
educationally interesting. I might want X Windows or KDE installed
from a pre-compiled package rather than have the students waiting for
most larger packages to compile.
(Give a college professor the right tools and you'll sell a bunch more
These are just some ideas I've considered while reading and
appreciating the LFS book and mailing list discussions.
If there's interest, I could be convinced to contribute towards some
of above ideas.
Dr. Mark A. Friedman
Central Connecticut State University
mafmailbox at earthlink.net
More information about the lfs-dev