Could you stop the AC bashing, please

Steve Crosby sneeble at hotmail.com
Mon Feb 24 07:03:48 PST 2003


matthias at winterdrache.de (Matthias Benkmann) wrote in
l

> 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

Just to add some signal to the noise...

*My* reading of the LKML posts in question indicated three concerns with 
kernel bug reports that were being reported by people with LFS systems.

1) The kernel toolchain (gcc/binutils/glibc) was being compiled from 
"unknown" sources, i.e. random "source" distribution versions and 
vendors.

  This results in the toolchain being of an unknown quality, and more 
importantly an unreproducible source.  This makes proving a kernel bug as 
opposed to a toolchain bug very difficult for the LKML people.

  This is an understandable attitude.  The LKML don't provide free 
support services, that's what vendor support contracts are for.  They 
will make an effort if they can reproduce the fault, but that's precisely 
the problem Alan was mentioning, that the people reporting the bug 
couldn't/wouldn't cause the same error under a "known" system.

2) The LFS versions of software are often "leading edge" if not bleeding 
edge (stable, not alpha).  The main install base of the various tools run 
under different versions, which produces the same replication/testing 
issues mentioned above.

3) The "other" vendors provide patches for known bugs, which are 
(usually) posted to upstream maintainers.  For whatever reasons, the 
upstream maintainers are slow/bad at implementing these patches, which 
means we (LFS) run tools with bugs that are already fixed in other vendor  
systems.  This means "most" of the bugs reporting by LFS people have 
already been resolved by a toolchain fix, rather than being a kernel 
problem.

The "Pure" LFS build system is designed to address point 1. We can't (and 
*shouldn't*) fix point 2.

Point 3 is under discussion already, with the possibility of a "patches" 
mailing list/site, which will help LFS keep more up-to-date with other 
vendor developed fixes to packages we use.

> 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 would have occurred even with the pure LFS build method.

Yep.  These problems have been the result of bugs in the toolchains (as 
you indicate later in your post).  I don't consider this a bad thing, all 
software benefits from being used fully.  The optimisations that the 
tweaks introduce aren't *illegal* and if they cause problems, what better 
for the community as a whole than we find, report and help fix them.

<snip>

> 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! 

And it isn't intended to.  It's intended to address the current 
difficulties of the toolchain being dependant on an unknown host system.  
Once the build process is perfected, we will have a toolchain that is the 
same, regardless of the underlying host system.

> 
> 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.
> 

Absolutely.  This is called "RedHat", "Debian", "SUSE", etc.  If you want 
to report a suspected kernel bug to LKML, I would *strongly* recommend 
you attempt to reporoduce the problem using another vendors product 
suite, so at least the LKML people have a common framework to reportduce 
the problem.  If we can't reporduce the problem in another vendor's 
suite, then it may be an LFS specific problem, a tool problem, or worse 
an *already fixed* problem.

<snip>

> 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

That depends entirely on what you mean by "working".  If I can have the 
same toolchain as another user, despite them building from LFS 1.0 
(patched and upgraded) and me building from FooBar 9.4, then we have what 
*I* deem a working toolchain.  This may not be what the LKML people refer 
to as a working toolchain, which is discussed in the paragraph above.

> 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

And so he shouldn't.  He's not paid to provide any support to us, and 
only does support because he chooses to.  Help the LKML people out by 
giving them a common framework to reproduce the problem and they will do 
wonders in identifying and resolving the problem.

> bugs. Pure LFS will not change this a bit. So it's wrong to flame AC,

No it won't.  Unless LFS gathers considerably more market share than it 
has (we can hope!), it *never* will.  And it's *always* wrong to flame 
*anyone*.  Whatever the cause.  If you can't say it politely and quietly, 
then seriously consider if it should be said at all.  (That's a 
generalisation BTW, not aimed at anyone, in particular, or at all *grin*)

> because he is right. And it's wrong to use AC's words as justification
> for pure LFS, because that's missing the point.

Well, the reason for beginning the PureLFS hint was the conversatoin on 
LKML, as an attempt to address *some* of the criticism levelled at LFS 
with regard to the nature of our toolchain.  As such, the mention of AC 
and the LKML are quite rightly presented in the opening history.  The 
wording is perhaps stronger than was intended, but that can be fixed (if 
necessary).

> 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.
> 

As with all flamewars, fingers often type faster than the brain thinks.  
And I suspect that (as with myself) a good many people started reading 
this thread and never bothered to read the comments Alan even posted, or 
the entire thread that the message generated.  I did before I posted 
this, so I feel I have an understanding of the concerns expressed.

- --
Steve Crosby
sneeble at hotmail.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