What next?
Jeremy Huntwork
jhuntwork at linuxfromscratch.org
Wed Feb 27 14:44:11 MST 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,
Agreed.
> * 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.
--
JH
More information about the lfs-dev
mailing list