Re: What next?

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
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On Wednesday 27 February 2008 23:44:11 Jeremy Huntwork
wrote:

> 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.

First of all, I will try to be an advocate of what you don't
wish to see 
(perhaps, feel free to correct me if I am wrong). IF you are
to reply, reply 
in a meaningful manner, else don't. Since I would like a
serious reply on 
this particular subject:

In what way(s) could you do this that diy-linux and clfs do
not do already? 
How is it going to compete with the other two? Or three.. Or
four... Or 
Infinity?

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

> Agreed.

Combining from the other projects? How? Why? They already
_have_ it combined. 
Why not work on _merging_ the communities into a single
project? Doesn't that 
make more sense since the goals are apparently the same
since you are 
choosing an evolutionary approach for LFS ?

>
> > * 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.

Implementing a _really_ good package manager is not an easy
task. This is why 
there are so many of them. After you have studied them
collectively and 
figured out the reasons for their incompleteness, you can
discuss about what 
to do. To date and from the archives, no discussion like
this has ever taken 
place in a meaningful manner, and stand - alone projects
took their own path 
and evolved into different self - hosting communities.

Isn't it a weakness in the social structure of LFS that it
could not hold 
these resources together? Educational use is no excuse
imvho.

> > * 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.

Again, how can it be different from Gentoo, Sourcemage, T2,
clfs, diy-linux, 
Archlinux, GoboLinux etc... the list is endless on the meta
- distribution 
front. Package management is not going to help saving, if at
all, anything.

> > * Make the LFS book more informative and less
"techy/geek" speak.
>
> +57 (I can have 57 votes, right?)

I do not think it is geeky, it should be more
"geeky" because there are MORE 
THINGS TO LEARN than how to build a toolchain, but i am a
"bystander" who has 
no reason to doubt your intentions and is probably
unimportant to you as a 
contributing opinion (for the time being, as some other
people, I do not like 
some of your policies when it comes to "combining"
things so there is really 
not much to contribute *here* but an opinion).

> 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.

Aren't there projects doing that, isn't this the reason for
the original 
split? Again, in  *what*  way(s) could LFS be different?

> > 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.

Then why does it need to evolve the "non -
educational" aspects?

> 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.)

Merging efforts (no matter to what you are referring to, you
have a point). 
Now this is the first and only thing that should be really
considered. I read 
that Mr. B You are absolutely correct on this one. Would you
care to explain 
if you are actually referring to attempts like LeafOS (you
and a couple of 
people where doing this long time ago, but it never lifted
up), how things 
should be done so that they do not end up in a standstill?

---------------------------------------------------------
As to automation, package management ... give it a couple of
days... Really. 
You are hardly expecting this. Hardly. You will have much to
discuss about 
this in the following days. MUCH. And you will understand
why some things
developed patiently and unannounced before they ripe, create
"glue points".
---------------------------------------------------------

> 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.

On the other list, the project founder has discussed about
killing LFS the way 
it is first.

To me, the only issue that is holding back LFS and
fragmenting it, is its 
social structure. You are unlikely to have LFS-NG without
taking into 
consideration this factor. Until you do, you will be
bleeding out people 
elsewhere, or trying to "combine" things into
branches etc. Other projects 
are not supposed to be component or conceptual
supermarkets.

Good Luck.

> --
> JH

...
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page