On 7/13/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > Ken Moffat wrote: > > > But, given that most LFS (and BLFS) developers think using anything > > other than x86 is unsupportable, CLFS is the only way to go for other > > architectures. > > Ken, That is a little unfair. I don't know of any LFS or BLFS > developers that think non-x86 is unsupportable. We have chosen to keep > those books x86 only due to the personal preferences, the hardware > available to them, and a preference of wanting to use the simplest > instructions possible without IF $arch == 'x' constructs. We have no > problems with pointing people to CLFS when it is appropriate.
I have been using CLFS to make x86-only builds lately as well. I am not pretending to be all that involved in the test/dev of lfs or clfs, but hopefully can give a user's perspective: Like most, I started learning LFS with LFS, not CLFS. It is STILL a very useful and (mostly) complete project, rolled up in a package deal in the form of the stable versions. I have immense respect for all the devs for LFS that still put countless hours into making it very successful. I know that the time spent now, even if it's only on x86, could never be wasted, as there is plenty to learn just from that one platform. I spend a fair amount of time in #lfs-support, and I never suggest that people switch to CLFS unless they can't build with LFS due to their architecture. That being said, my focus has completely shifted ever since working with CLFS. I needed it to work with my new 64-bit proc. At that point I still had no preference. I don't know how to say this delicately, so I will just say it. It seems futile for me to attempt to test for LFS for the simple fact that the x86 architecture's days are limited. You can barely buy a new system off the retail shelf that isn't at least a single-core athlon64. I am very curious where the efforts will change with regard to the very dedicated LFS developers. Do you have any plans to eventually begin work on CLFS when the time is right? It seems like a natural progession to combine forces at some point, and I hope egos do not get in the way of this, as I know we would value the wealth of knowledge that LFS devs and testers could bring to CLFS, as well as the reduction in overhead in maintaining 2 separate projects. I hope I didn't spark a flame war here. That is definately not my intent. It just seemed like a relevant time in the thread to bring it up. I don't want to see both projects suffer over issues of pride. Thank you all for your efforts! Craig Jackson (TheEpitome) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
