My resignation

Matthias B. msbREMOVE-THIS at
Thu Jul 15 09:41:14 PDT 2004

On Thu, 15 Jul 2004 16:33:30 +0200 Jeroen Coumans
<jeroen at> wrote:

> Matthias B. said the following on 15-07-2004 13:29:
> > 
> > Don't tempt me :-)  Or maybe DO tempt me. I might even start something
> > like this. I could at least write up a mission statement. Hmmm.
> I'd love to see one and I'd even offer to help write one. LFS really 
> needs a clear mission statement to resolve the current conflicts. 

I've started writing some guidelines for the educational book as I would
envision it (called "LFS-C" for "LFS-Course" as opposed to "LFS-D" for
"LFS-Distro") and I fear that it would not help resolve the current
conflicts, because it's too different from what we have now and so can not
be readily applied to the current book.

> *) Internal meaning that both books would still be produced under the 
> LFS flag and no forking would occur. This is based on the assumption 
> that there is considerable overlap between both ideologies and that 
> neither party has an interest in forking.

I don't subscribe to the "forks are evil"-philosophy. I have yet to see
something evil come from a fork.

But LFS-C as I envision it would certainly not be a fork like egcs or, in the sense that some people try to create a "better LFS". Most
importantly there'd be no need for splitting the community. LFS-C would be
something very different with little resemblance to the current LFS book
at least with respect to presentation. 

The current LFS book is many things, but it is not a course. The current
LFS book is more like a walkthrough that walks an experienced Linux user
through the steps needed to create his own distro. So the current LFS book
is much closer to LFS-D than it is to LFS-C. 

The difference is hard to describe without having actual text for
demonstration. I think "walkthrough vs textbook" describes it best. A
walkthrough is more concise and presents steps in chronological order. A
textbook is more detailed and rather than in chronological steps it is
organized in topics ordered by educational criteria.

LFS-C for instance would first present a simple shell script as init,
together with text explaining the Linux boot concept and init's role. A
later (optional) chapter could present SysVinit in depth and teach people
how to design their own SysVinit setups.

LFS-D on the other hand would contain instructions for setting up SysVinit
right away, with much less explanatory text and instead of general
instructions on how to set up a SysVinit system it would present concrete
instructions complete with sophisticated boot scripts to set up a useful

LFS-C would naturally lag behind LFS-D. The way it would work is that a
major change such as udev is implemented in LFS-D and used for a while and
at some point someone writes a chapter for LFS-C that presents the
experiences with udev in a form appropriate for a course. 
An important thing to note is that while LFS-D would remove old
instructions (make_devices in this case) obsoleted by a change, LFS-C
would not usually do that. While LFS-D *changes* continually, LFS-C
*grows*, i.e. additional chapters are added that deal with new topics.

One could compare it to an actual implementation of a cryptographic system
(LFS-D) vs a textbook on cryptography (LFS-C). The actual implementation
does not contain primitive ciphers such as character-substitution and when
a new cipher obsoletes an old one, the code for the old one is removed and
replaced with code for the new one.

The textbook on the other hand starts by presenting primitive ciphers and
when new ciphers are invented, chapters are added but the chapters about
the old ciphers are not removed.

Yet another way to describe the relationship of LFS-D and LFS-C is
learning-by-doing vs learning-by-textbook. These are 2 fundamentally
different concepts and people differ in their preferences. Some people
prefer to learn hands-on while working on a real-life project. Other
people prefer a traditional course with small textbook examples.
In order to learn how a compiler is implemented you could for instance
join the GCC project and port GCC to a new architecture. That would be the
hands-on way. The more traditional way would be to learn from a textbook
about grammars, parsers etc. and then following the book's exercises build
a small pet compiler for a primitive language with little real-world

I hope that I've been able to make clear how I would envision splitting
the LFS project. I think the problems we're having and all the discussions
about what to include and what not to include in the book and how the
educational goals can best be achieved can mostly be traced down to the
impossibility of combining the above 2 approaches.


Murphy was an optimist!

More information about the lfs-dev mailing list