> Um, you seem to be talking as if one must run a 64-bit OS on 64-bit > hardware. That is, of course, utterly ridiculous. IMHO 32-bit OS'es > running on 64-bit hardware are still the norm. See this recent post from > an Intel employee for example:
I'm not implying that, in fact i completely agree with you. I am merely speaking to some of the reason the I personally felt compelled to switch. LFS is primarily educational for me, until the point when I am using it in a production environment (which is not now). :) With this education comes a desire to stay up-to-date, rather than just build the most stable OS possible (I would use LFS 5 if that were the goal). > Not only that, you also seem to be implying the days of the LFS *build > method* are limited. I might be biased but I can assure you that the basic > idea of the LFS/DIY build method works fine on x86, ppc and x86_64 for > *NATIVE* building of Glibc based systems and that it has stood the test of > time. Of course, it doesn't cope with multilib nor x86 -> x86_64 > bootstraps but that is where cross compilation comes in handy. I will not > go into the many drawbacks of cross versus native because it's all been > said before. No I don't have issue with the LFS build method. All the (x)lfs projects use this method to some extent, and it is one that I like more and more after each successful build. It is very easy to understand and cannot be much simpler when building toolchain packages etc. This is a great idea and the fact that CLFS is so remarkably similar is a testament to LFS's proven concept. I am not writing this to whine and complain, it truly saddens me to think that two groups of like minded people completely split because of a detail such as this. I just hope that when users and testers start migrating to CLFS more and more, which is inevitable, that the LFS work performed since the fork will not be in vain, and that the hundreds of thousands of hours of learning and development by the LFS devs will not be in vain. > > I agree with Dan. It's probably time to implement a native non-multilib > x86_64 build as an option for LFS. But to keep everything compatible with > x86, you'll probably need the lib -> lib64 symlinks which mirrors the > practice of some distros and also what I've done in the DIY Refbuild. I have no "loyalties" to either group. I work on whatever project suits my purposes at any moment. If the LFS project started to make native 64 or multilib builds, I would bet that the shear maturity of the LFS project would win most of the users of CLFS right back. Stylisticly, and for stability's and compatibility's sake, I actually prefer LFS to CLFS. Functionally, CLFS is more progressive, and I am a progressive user, as most people who try any LFS are naturally progressive users as well. Thanks! Craig Jackson (TheEpitome) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
