Apologies in advance, this mail will break the threading...
Possibly our mailservers white/grey listing is playing havoc with my
lfs-dev subscription (haven't received a mail since the 22nd) ....
Currently following this from the mail archives
Some history for folks that weren't around.
CLFS basically formed out from the old lfs-hackers list, which used to
be our old R&D playground before it was shut down in 2005.
(Can't even find the archives for it anymore... which is a shame...)
CLFS wasn't, in my mind at least, meant to be a separate project. At the
time (2004/2005) we were trying to adapt LFS to deal with multilib
builds so we could put it on x86_64 hardware (there weren't any decent
x86_64 distroes at the time to work from)...
At the time there wasnt much interest in anything outside of ix86 for
LFS proper (recent conversations on the list pretty much mirror exactly
what happened circa March, April and May 2005), Jeremy Utley (JMan) and
myself also hacked together an LFS style build (cross-lfs-lite, Cross
compiled initial stage, native compile for the rest of ch5) in the lfs
wiki that was hoped to be more palatable, but again at the time it was
considered too much for the book...
Jim at this time had also picked up cross-lfs and ran with it, it grew
legs and then started running...
Now speaking frankly.
Internal bickering, politics, NIH syndrome and inflated egocentric
claptrap eventually pushed development off of the lfs-dev list entirely.
I tried not to get involved.
For me this was a somewhat sad occasion (all the work was originally
done for the lfs project itself). But I go where the work goes... and it
went elsewhere.
Cross-lfs became a defacto lfs-hackers.
In hindsight, the removal of the lfs-hackers list is probably what split
the community.
The signal to noise ration on lfs-dev was far too high and to do any
significant work you would be constantly attempting to justify yourself
to barrow-pushers, FUD merchants or vested interests (a very small
minority) instead of getting the job done.
Technical matters became a secondary concern.
It is probably for the same reasons technical folk nowadays shy away (or
go "MIA").
When it stops being fun and degenerates into Megaphone Diplomacy (Those
that shout hardest win, regardless of merit) folks have better things to do.
Who wants to deal with over-inflated egos, cause pushers and ill
tempered narcissists (only 1% of the community, but they ruin it for the
rest) when you could be getting on with work... life is too short... You
get paid to deal with crap at work, but on your own time who could
really be bothered.
Civility left the lfs-dev list ages ago (note recent posts), the dream
of "one united" LFS went with it...
Folks will expend their efforts in a co-operative environment conducive
to the open interchange of ideas judged solely based on their technical
merit, with freedom and encouragement from peers to try out their own
thing, and receive appropriate attribution and thanks for the fruits of
their labour...
Once long ago it used to be this way... long long ago...
Can the situation be rescued? I don't know and frankly it is not up to
me. I go where the work goes.
I am listed as a CLFS maintainer and co-leader, but I never exercise any
power or try to drive the project in any given direction, it goes where
the people take it. Everyone involved has an equal say and equal vote on
determining what happens.
Somewhere there is a middle ground where we (LFS and CLFS) can work
together on common goals and share knowledge (especially in regard to
dealing with multilib builds), but I fear personality issues and general
antipathy from folks holding onto past issues and mistreatments or with
a barrow to push will tend to override pragmatism (if history is any guide).
Myself, I have no vested interest either way... I quite frankly do not care.
One main sticking point if folks so choose to merge projects again is
somehow dealing with the conflicting goals between the projects
.
From my point of view (speaking for myself) CLFS goals are about
documenting and educating folks on the build of sane cross and native
toolchains, incidentally we happen to be building a linux system from
scratch.
( I have to define sane here now due to a previous ill-tempered arrogant
outburst on this very list, a perfect example of why people just say
stuff it and go elsewhere)
In my opinion a sane toolchain should behave exactly as an unaltered
native compiler would.
ie: out of the box and without any user interference, when uttering
"gcc {,-m32,-m64} foo.c" it will
1) use headers from the prescribed system location,
2) link using libraries and startfiles from the prescribed system
location and
3) can generate an executable (this is a pretty big
requirement)... all without requiring any user interference... and finally
4) do all of the above without caring where it is installed or
relocated to.
If you install a native toolchain into /opt (or relocate it somewhere
else) you expect that it will always locate headers from /usr/include,
link against libraries from /lib{,64} and /usr/lib{,64} and produce an
executable.
If it didn't it would be broken.
Same should be the case for CLFS cross or native toolchains (except
where needed referencing /tools instead). Choice of install prefix is
incidental.
)
LFS goals appear to be the other way around... and thats fair enough. If
the goal is to solely produce a linux system from scratch where host =
target the technical exactitude
of the toolchain used doesn't need to live up to any of the points
above, as long as it barely gets the job done and the manual
intervention required for it to actually work is fully documented.
Over at CLFS we do not compromise on the toolchain, we cannot afford to.
Will continue to watch this thread with some vague interest, but
probably wont post again on this subject... you guys can try to work it
out amongst yourselves.
[R]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
