On 28 May 2005, you wrote in lfs.dev: > Jeremy Huntwork wrote: > >> Increased complexity? For x86 -> x86, I'm not sure I see it that way. > > You have to be kidding, right? Everyone around here has obviously > forgotten what it's like to be a newbie. I'll repeat what I've stated > in the past: > > - the greatest thing about LFS is that newbies can come here and > find a > simple build recipe that actually works and is easy to understand! > > If you guys cannot see this then you've seriously lost the plot. >
And the current stable release of LFS is just that - simple and easy to understand. The *development* release of LFS is attempting to do the same, while providing additional functionality for modern hardware. >> And, again, the reason for going this route even for just x86 -> x86 >> would be to provide absolute independance from the host. Isn't that >> what LFS has been aiming for since the beginning of PLFS? This is in >> a sense the realization of that goal. Total abstraction. > > As a co-author of PLFS, I have a fair idea of what I'm taking about > and the answer is NO!. This complete independence from the host line > that everyone around here keeps peddling is seriously overrated. Sure, Well, the initiative to change the build process was instigated due to Alan Cox rather pointedly explaining that our build method was flawed, as we relied on host elements that could impact the final release. PLFS was developed initially in answer the that concern. (Yes, I was around then too ;) > it is a factor but what matters most is the finished product ie: in > LFS speak, the current Chapter 6. The purity of the finished product > can be measured using ICA style techniques. And _THAT_ was the aim of > PLFS. Folks used to believe you had to build LFS twice to attain a > perfect system. A proper build method avoids the need for building > twice. Like I said, this stuff can be measured! Don't forget CMM, CMMI and ITIL as well ;P <snip> > Sure, I don't agree with everything in it, but the biarch stuff really > is on the cutting edge. My point is that I just don't believe > cross-lfs methods are suitable for the masses as the default build. > > You already have BLFS, ALFS and HLFS. Why not CLFS? Cross stuff is > needed for newer arches. But for everyone? If the developers can make it work, why not? Your welcome to your belief that it isn't suitable - once the developers have a reasonably stable and complete build branch, we'll ask our users what they actually think (although comments prior to that are always welcome). > I can't help but think this whole drive to inflict cross build on > everyone is partly my fault. I know for a fact that some LFS folks are > still bitter about my departure from LFS and see my DIY project as > competition. This, I suspect, is what's driving this whole thing. Sad > really. Although there are some who (over-)react regarding mention of your project in these forums, the cross-lfs work is being developed to maintain LFS as relevant for new technologies, as well as maintaining a build path that copes with existing technologies. It's progress is being tracked through a development branch, as it should be, and it may well be dropped in favour of a hint or seperate book - that decision has yet to be made, and won't be made anytime soon. Please don't think we hold our breath and look over our shoulders in fear of any "competition" - the "build a system from scratch and learn on the way" market place has plenty of room for others, and we're comfortable in where we are, and the progress we are making. As always, yours (and anyone elses) input is welcome, thanks for taking the time to comment. - -- Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
