gmlistbox at obsethryl.eu
Wed Feb 27 15:29:05 PST 2008
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
> > * combine the resources/knowledge of the various projects into something
> > more coherent,
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.
More information about the alfs-discuss