Merge BLFS and LFS? [Was Re: What is LFS anyway?]

Jeroen Coumans jeroen at
Mon May 10 10:43:15 PDT 2004

Tushar Teredesai said the following on 10-05-2004 19:11:
> Though I said the above with a tinge of humor, I would like to throw 
> this idea out in the open. How about merging the two projects into a 
> single one? The advantages that I see are:

For me, the distinction between LFS and BLFS always was the different 
goals and philosophy each project has.
LFS was all about teaching the inner workings of a Linux system by 
building a base Linux system from source. The focus on education led to 
a fairly minimal system with little room for alternatives in the book 
itself. The book's form is written accordingly: a strong focus on 
methodology and linearity, to build up the users knowledge.

BLFS was all about creating a usable system from LFS by extending it 
with packages for which instructions were provided. This meant 
instructions for a wide diversity of packages where everybody could shop 
around for their specific needs. As a result, it's form is quite 
different from LFS, namely thematically organized, with dependencies 
cross-linked and non-lineair in narration.

There is a reason why the original LFS howto was shrinked to it's 
current form, and even this is more then enough to fill a book, and that 
was to seperate the goal of education from the goal of building a usable 
system. BLFS was formed to fill the void of building a usable system 
which LFS left when it decided to focus on education.

I'm definitely against any such proposal, btw., because I believe in the 
above distinction of goals, audiences and form, and their mutual 
exclusiveness, at least in one book. This is the way it has been for the 
last few years, and it was good - LFS has come a long way in technical 
excellence, and BLFS has provided instructions for many different use 
cases, ranging from server to desktop.

The above reasons are also why I am principally against proposals to 
include packages such as hotplug or udev. Despite Jeremy's claims that 
we're holding back progress of LFS by not including them, I believe the 
distinction as outlined above is crucial for both projects to keep their 
focus narrow and allows them to achieve technical excellence.

Jeroen Coumans

More information about the lfs-dev mailing list