SVN-20070706: Step 5.7 Adjusting the Toolchain

Bruce Dubbs bruce.dubbs at gmail.com
Fri Jul 13 20:27:58 PDT 2007


Ken Moffat wrote:
> On Fri, Jul 13, 2007 at 05:36:23PM -0500, Bruce Dubbs 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.
>>
>>   -- Bruce
> 
>  If I summarised unfairly, I apologise.  Would you prefer "is
> unsupportable by most of the LFS/BLFS editors" ?  This is in the
> sense of "not able to be supported", NOT one of the meanings which
> drift towards 'indefensible'.

I wouldn't use the word "unsupportable" at all.  You can say that the
LFS/BLFS Editors have chosen to only target x86 for a variety of reasons.

The way I look at the whole project, it is a curriculum on how to build
a system from source.  LFS is the intro course where things are
presented in a 'straight line' manner.  BLFS is a follow on to that.
Things like HLFS, ALFS, and CLFS can be considered advanced courses.
Sure, some people can jump right into CLFS, but many can't.

I think that LFS/BLFS will stay relevant for quite some time, even if
the common hardware is x86_64 compatible.  As Greg points out, many, if
not most people run 32-bit OSes on 64-bit capable hardware.  For general
purpose work, I know of no compelling performance reason to use 64-bit
applications or OSes.  Of course, many of the LFS community will want to
experiment with x86_64 or other hardware.

The way the different approaches have divided themselves is not
unreasonable.

  -- Bruce



More information about the lfs-dev mailing list