My resignation

Matthias B. msbREMOVE-THIS at winterdrache.de
Thu Jul 15 04:20:11 PDT 2004


On Wed, 14 Jul 2004 12:00:04 -0700 (PDT) jeremy at jutley.org wrote:

> The entire reason the LFS-Bootscripts were put into a package was that
> having them in the book was VERY typo-prone - by placing the scripts
> into a package, we eliminate that problem. 
> why
> have you guys not given your input to him?  

The problem with small step-by-step changes is that you don't see the
problems until it's too late. A lot of steps of which each looks like a
good idea can be a bad move when taken together.

But the underlying problem is that LFS has no clear mission statement.
There is the education camp whose members believe that first and foremost
the LFS book should be educational and that functionality is secondary.
Then there is the functionality camp whose members believe that a
by-the-book LFS system should be a serious and useful Linux system. And
then there's the largest camp of the in-betweens who have no clear idea of
what they want from LFS. 

Maybe the unstable/testing/stable split was the wrong one. Maybe there
should instead be a distro/education split. I have the feeling that the
education/functionality conflict is the real conflict here and it has only
disguised itself.

AFAIK Minix was facing similar issues before Linux came along. A lot of
people demanded more and more from Minix, wanted it to become a serious
contender in the world of operating systems, whereas Tanenbaum meant to it
be strictly an educational tool. The difference in our case is that Gerard
never had such a clear focus for LFS and now that he's faded into the
background, the community is breaking up over this conflict.

If we had 2 branches, one with a clear focus towards maximum functionality
and progress and one with a clear focus towards education, then we would
not be having this conflict. The functionality branch would comprise
unstable and testing, oriented towards progress and new development,
accepting complexities such as udev, hotplug and other useful stuff. The
goal would be to give people instructions for building their own Linux
distro that can compete with other distros. Educational content would be
secondary and targeted at advanced users who want to understand what
they're doing, what's the rationale behind the instructions but don't need
textbook style education.

The educational branch on the other hand would be what is stable now, but
stripped down even further (e.g. no networking, possibly not even
SysVinit), with no need to produce a useful, complete system with
up-to-date packages. The educational branch would deal with udev, hotplug,
networking, sophisticated SysVinit setups,... in Appendixes that are
something like educationally enhanced super-hints. It would be like a
course with several modules. The basic module would tell you how a Linux
system works at a simple example that leaves out all the complex stuff.
Additional modules build on this.

The functionality branch and the educational branch would probably share
very little text. What they would share is the experience with building
the packages, problems, support,...

MSB (who needs to stop daydreaming)

-- 
Shallowness is the art of painting grey using colours.




More information about the lfs-dev mailing list