Could you stop the AC bashing, please

Bill's LFS Login lfsbill at wlmcs.com
Mon Feb 24 07:03:34 PST 2003


On Mon, 24 Feb 2003, Matthias Benkmann wrote:

> On Mon, 24 Feb 2003 13:39:26 +1100 Ryan.Oliver at pha.com.au wrote:
>
> > I wouldn't consider it a flame but a fact, Alan Cox did level criticism
> > at us, and personally when I hear AC speak, I listen, then do something
> > about it, coz something is wrong.
>
> "pure LFS" will not invalidate AC's point. I'm very sorry that I have to
> mention Greg by name again, but he is the perfect example. 2 times already
> have we stumbled across problems caused by his tweaking, problems that
                                   ^^^^^^
In the interest of accuracy and fairness, I suggest a more accurate verb
here would be "exposed". In the sample you cite below, the bug was "ex-
posed by", not "caused by", if it was GCC bug.

> would have occurred even with the pure LFS build method. pure LFS will
> give conservative users like me a better toolchain, but those users were
> never the problem. AC has a problem with people reporting alleged bugs in
> the kernel that in fact result from code generation errors due to an
> unstable toolchain.
>
> I understand AC's frustration with this. I remember well how I chased
> after alleged problems in my instructions for compiling the keymap into
> the kernel, and how annoyed I was when people were actively discouraging
> others from using my instructions, even though the problems were caused by
> Greg's tweaks. Yes, it was a GCC bug, but that is not the point. It was a
> bug that only got exposed when you fiddled with optimizations. How is
> "pure LFS" going to solve this problem? It isn't!

Question: are you suggesting that investigation of, and possible use of,
optimizations should be avoided in LFS? Would it have been better if
your keymap activities had sailed right on, unhindered, and the bugs
(and their educational impact) had never occurred? Would you prefer that
these things are not investigated so that disruptions to your activities
would not occur? I would *guess* that your answer is "no, I do not sug-
gest that".

> Removing all optimization hints, banning all hints that include
> non-default optimizations and censoring all mails that reference
> optimizations of any kind would be orders of magnitude more effective than
> "pure LFS" in convincing AC that LFSers are using good tools and that
> their bug reports can be trusted.

Although it would be nice if AC held the LFS community in high esteem, I
find it difficult to believe that a goal such as that should have much
to do with LFS. As a part of the drive to create a better toolchain,
sure. Further, I *personally* believe that LFS would be much less
interesting (good/bad or otherwise) if the project did nothing but
"follow the leaders" of the established major distros and the Linux
community at large. Let us not forget that the roots of Linux, open
source et al began with mavericks, progresses mostly with mavericks and
will continue to prosper (non-commercially) only so long as mavericks
exist and play an active and affecting role in the *IX community.

What this means to *me* is that the efforts of those who may stray from
the beaten path are (potentially) valuable and I would not want to see
their enthusiasm or efforts dampened in any way by a more "conservative"
attitude in the LFS activities.

To all of them, for their efforts, their mistakes, their
open-mindedness and their persistence in the pursuit of a "better way",
I say thanks - and keep up the good work.

If LFS is not conservative enough for some users, they have options. I
belive LFS only ought to help educate them about some of those options.

> Now before someone wants to let off steam again, flaming me, suggesting I
> said things I didn't, I want to get this straight: I do not suggest that
> we implement the previous paragraph. What I want to say is that LFS users
> as a collective can never ever be trusted to have a working build
> toolchain. It's simply a consequence of what LFS is: a guideline, meant to
> be deviated from. It lies in the very nature of LFS.
> AC is right when he does not trust LFS users to report kernel bugs. Pure
> LFS will not change this a bit. So it's wrong to flame AC, because he is
> right. And it's wrong to use AC's words as justification for pure LFS,
> because that's missing the point.

It is not wrong to use that as justification, IMO. Although I
*personally* do not have more concern for AC's opinion that any other
person that I may respect, I do not disparage the desire to have respect
for LFS grow in the Linux community. If that is a valid desire for a
substantial portion of this list, then it seems that having a better
toolchain, which was AC's complaint, is a useful way to try to achieve
that goal. Granted, the "your way" credo may not allow AC to have full
confidence in all the folks who may want to report bugs, but it can
allow him to see the LFS project as having a reliable toolchain and
know that certain LFS-reporters of bugs can be taken quite seriously and
(maybe) others should not be taken so seriously.

That may benefit all LFSers and AC (or whomever) as well.

> All of this, of course, has nothing to do with the qualities of pure LFS,
> just with the way it has been introduced and is presented.

IMO, the time for those concerns were during the initial presentation. A
healthy discussion could have taken place (and did anyway, IIRC) about
whether or not pure-lfs should be pursued.

One last thought about the term "pure". Although "political correctness"
may have some merit, in certain contexts, it would be unreasonable to
attack the term based on a very parochial view of the connotations of
the term. In its "purest" (he-he!) meaning, the word carries no such
connotations and should not be banned to the trashbin because of abuse
of the term by certain groups.

> MSB

-- 
Bill Maltby
lfsbill at wlmcs.com

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list