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
|