What next?

Jeremy Huntwork jhuntwork at linuxfromscratch.org
Wed Feb 27 13:44:11 PST 2008

Alan Lord wrote:
> Firstly, Gerard is definitely on the right track in his recent posts, 
> and DJ also hit the nail on the head too with some of his concerns.

Based on the sorts of replies I've been seeing most of us are agreed 
that LFS needs a change of direction. Something that will make it more 
useful as an end product and not _just_ a one-time learning experience.

Allowing greater end usability in this way is also sure to stir up more 
interest from both those long associated with the community, and those 
just joining.

And judging by the recent lull in community discussion/interest followed 
by this flurry of activity, it's clear to me that something can and 
should happen, if LFS is going to continue.

> * combine the resources/knowledge of the various projects into something 
> more coherent,


> * Implement PM (Oh yes, oh yes)

Agreed. But as has been noted we need to be careful and deliberate about 
how we approach this one.

> * Move away from the manual cmmi to an automated build system (Sounds a 
> bit like Gentoo)

Not sure. As has been brought up, education is key and we don't want to 
lose that. In fact, we want to improve on it and steer clear of a 
'Gentoo path'. However we approach automation and package management 
needs to take that into heavy consideration. We're going to need to 
really discuss how this is all actually set up.

> * Make the LFS book more informative and less "techy/geek" speak.

+57 (I can have 57 votes, right?)

This, IMHO, should be the main thrust and focus of the change. Yes, the 
above three items are vital to keeping LFS usable and growing, but not 
without this core component. The goal should still be to _teach_ and not 
just dispense information. Trust me, there is a difference.

> I keep coming back to education... That was the goal of LFS and should 
> continue to be it's overriding objective.

Yep yep yep yep yep, uh-huh uh-huh.

> So perhaps the LFS project becomes some sort of "course" (And I use the 
> term loosely). The "modules" of which, could be something like:
> * Learning the basics (Command Line, cmmi, security, toolchain, blah blah)
> * Scripting/Automating (A subject about how LFS get built, the tools, 
> the process etc)
> * Basic Useful Applications (A sort of mini BLFS where we get 
> networking, X and maybe Firefox/TB type apps installed)
> * Building your Distro (Completing the core build-out adding your chosen 
> apps and utilities and configuring)
> * Making it your Distro distributable (How to make a liveCD or "your 
> distro", how to make an installer script...)

This is a good start, I think. What I would like to see happen is for 
Gerard to layout a proposal of core changes (perhaps based in part on 
the above suggestions) with a little more detail than he has given so far.

For example, if we are merging efforts between the sub-projects, what 
form does LFS now take and how is it arranged organizationally? Also, on 
the topic of form, what changes to the structure of LFS will make it 
both _more_ educational (again, think _teach_, not just list facts) and 
easier to provide PM and automation? (Even those aspects should be 
looked at from an educational standpoint.)

With a bit more of a solid proposal, we might be able to move away from 
just discussions and begin on a LFS-NG or, at least, a POC for LFS-NG.


More information about the lfs-dev mailing list