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-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
