Could you stop the AC bashing, please
sneeble at hotmail.com
Mon Feb 24 07:03:48 PST 2003
matthias at winterdrache.de (Matthias Benkmann) wrote in
> 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
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
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.
> 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
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.
> 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
> 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.
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