Ulrich Drepper slams on the LSB, suggesting that binary compatibility is a red herring and that the LSB is incompetent.
I think it best to respond to the substance of the allegations here. To do that, you’ve got to filter out the ad hominem slurs (“…they buy into the advertisement of the people who have monetary benefits from the existence of the specification, they don’t do any research, and they generally don’t understand ABI issues.”), ego (“After they added the 100+ reports I sent and those others sent the test suite is a somewhat good reflection of who a Linux implementation should behave…”), and contradictions (even though the LSB people are incompetent, their experience shows that their goal is unattainable; one would think you need to try with competent people before deciding that something is impossible).
So what are you left with?
- Test suites have bugs, even embarassing ones. Are we supposed to be surprised by this? Yes, part of the thread test bug Drepper highlights is pretty stupid. But who can claim to have never written stupid code? Certainly not I, and certainly not Drepper.
- The tests are incomplete. This is both because of incomplete specifications and bugs, which cause discrepancies from the specs. By this logic, software testing is also useless for the same reasons. In the cases where the tests are right, can we not depend on them? “Useful” need not imply “perfection”, as all users of glibc today can testify.
- Waivers are signs of incompatibility. Drepper’s complaint: “The result of all this is that you can have a program which is certified for LSBv3 which doesn’t run on all LSBv3 certified systems, depending on whether the LSB environment worked around the broken test or not.” But software vendors can easily retrieve a complete list of waivers, which allows vendors to anticipate what discrepancies they’re likely to encounter. Vendors may be ignorant of the issues, but that is hardly the LSB’s fault.
- Having separate runtime environments for LSB issues is bad. First of all, Drepper seems to think that people doing separate LSB runtimes (like me) are doing it to work around LSB test problems. In Debian, however, 100% of the bugs I work around with the dynamic linker are bugs in Debian, not bugs in the tests, and only one of those bugs is not a glibc bug. Second, if the separate LSB runtime environment is complete, why should it matter that it’s different from the default, as long as it follows LSB behavior?
As a final point, I would look at Drepper’s recommendations for a replacement of the LSB: source specifications, and identical binaries whenever ABI compatibility is an issue. He doesn’t answer the question of whose binaries those should be, probably because he’s happy with the current de facto answer: the binaries provided by his employer, Red Hat. No doubt he would prefer a world without competition, but should the rest of us?
(Seen via Slashdot.)
I think that much of Drepper’s criticism is on target, and it has nothing to do with who his employer is (Uli Drepper is a very independent-minded guy who is often fighting the rest of Red Hat, so your implication that he is somehow acting out of corporate interest is foolish).
Drepper’s main interest, it seems, is as the maintainer of glibc, and everyone uses his glibc. If its behavior does not match what the LSB says, that could be a bug in glibc (especially if it also violates Posix or introduces a security problem). But if glibc and LSB don’t match and no third consideration says what the right answer is, then it’s more appropriate to call it an LSB bug, since it wasn’t in the charter of the LSB to declare all existing implementations non-compliant and introduce a new standard.
Your point is certainly relevant. However, in my experience of getting Debian LSB-compliant, issues caused by LSB mistakes have not been nearly as troublesome as issues caused by glibc mistakes.
This is not because glibc is buggier (it’s not), but that LSB’s mechanisms for handling these bugs is better than glibc’s has been.
For example, the sole reason I did the LSB dynamic linker hack was because of NPTL POSIX violations in glibc 2.3.2 that could not be solved by just upgrading NPTL. By contrast, the timing problem he complains about was waived in a very timely manner, so that certification efforts could continue.
Indeed, I’d be very interested to learn of a single case where the LSB ordered the glibc developers around (or anyone else, for that matter) that was not based on some other recognized standard, such as POSIX or SUS.
Uli Drepper is a very independent-minded guy who is often fighting the rest of Red Hat, so your implication that he is somehow acting out of corporate interest is foolish
That may be. On the other hand, is it foolish to recognize how his post serves his employer’s best interests, whatever his motivation for writing it? How about how his post serves his employer’s best interests at all of our expense?
Or does he have a different plan for getting the Oracles of the world to support the Debians of the world? If so, I’m all ears.
An issue is implied which I do think is valid is the question, who are the LSB people and why should we support them? How do we know that they have the skills and the well meaning to maintain a standards document? In the event that they make mistakes, who’s correct: The upstream author who wrote it, or the ABI writer that isn’t involved with upstream at all?
For the LSB to be effective, it should be working with upstream to use the same testsuites that they do, and to contribute to those and improve them. Make it possible to run them on the running system to check against known faults. Add testsuites to the pieces that don’t have them. Work with distributions to run these tests every time a package is built so that regressions are caught and dealt with right away. When other bugs are found, help make them testable and get those tests in upstream.
I think a standardisation plan is only effective when it involves the people who are involved with writing and responsible for the code on a large scale. Then we could get the various distros together who want to play and decide every two years or so to make a snapshot of the ABIs that are commonly supported by the group. Call that the LSB of the moment, with all its associated bugs.
Tks,
Jeff Bailey
I personally think Ulrich Drepper really missed the most important reason why the LSB has little value over API specifications: it only matters for proprietary software. Given the availability of source code, the LSB’s myriad specifications of ABIs are completely irrelevant. The only useful things I’ve seen coming out of the LSB are the API specifications, such as the standardized init script mechanism; even then, they seem to feel that they should be gratuitously different from every other mechanism and come up with their own.
Furthermore, I agree entirely with Joe Buck’s comment as well: “if glibc and LSB don’t match and no third consideration says what the right answer is, then it’s more appropriate to call it an LSB bug”. Standards should work the way Debian Policy works: wait until everyone is mostly doing the same thing anyway and will likely continue to do so in the future, and specify that accepted technical solution as the right way to do things; this avoids declaring someone buggy by fiat.
it only matters for proprietary software
Well, first of all, that’s a pretty serious matter. Maybe in twenty years or so proprietary software will go away; until then, it’s a problem for a good number of us who use free software.
Second, though, it’s not just important for proprietary software. See the comments to this post for a whole list of people who are not content with either source or distribution-provided binaries.
Furthermore, I agree entirely with Joe Buck’s comment as well: “if glibc and LSB don’t match and no third consideration says what the right answer is, then it’s more appropriate to call it an LSB bugâ€.
I am not sure who disagrees with you (and Joe) on that point. Certainly not the LSB.
WRT testing in general, I think that the term insufficient but necessary applies. I applaud the idea of LSB, and I know the level of effort people putting into standardization. These are all very good things, IMHO. I worry now with the others over whether it is the right standard, even while being very happy that there is a standard. I think that’s a higher concern than whether LSB should exist.
Maybe it’s because I don’t know the players very well, but nothing I saw at http://www.linuxbase.org/policy/charter.html caused me alarm. Maybe your readers see something different in it.
I have to wonder if incompatibility with glibc isn’t an error in specification, though I had the same problem with most standards body. Remember that the C++ standardization committee specified something that didn’t really exists (hardly worthy of the term “standardization”), but what they came up with was generally very good. I think they needed to divide standardization and improvement. Is this similar? Are they breaking compatibility to standardize and improvement for some good reason?
One problem is that the messenger (Drepper) himself is notorious for disregarding user’s complaint about his own work in general in regards to glibc, verbally insulting these “Joe Sixpack” users.
If you dont run Red Hat,
your system is broken by Drepper’s standards anyway.
Jeff Licquia: “Or does he have a different plan for getting the Oracles of the world to support the Debians of the world? If so, I’m all ears.”
As a system engineer, if I’m running Oracle on a server, I’m going to be using RHEL or OEL because that is what Oracle tests and certifies it on. I’m never going to run it on Debian unless it has been natively Q/A tested by Oracle to run on Debian and will not accept any LSB compliance testing as assurances that Oracle will run correctly on Debian. Oracle is unlikely to ever support Debian through that kind of standards-compliance process as well, there’s no way they want to open the door to their support org to any and every distribution that can claim LSB standards compliance.
The solution to having Oracle support Debian is simply to have Oracle support Debian natively. Compile the binaries from source, test it on Debian and support it. If Oracle doesn’t see any utility in going after this marketshare and doesn’t put forth the effort the only way to fix it is for Debian to gain marketshare. And, again as a system engineering, the “problem” that Oracle doesn’t support Debian is only a problem if you assume that Debian is the correct answer. I can make RedHat work just fine in production systems, so I don’t understand why this problem needs to be solved.
(And I’m more of a FreeBSD bigot, so let me know what your solution is to getting Oracle running on that O/S because I’ve worked on linux for over a decade now and I’m sick and tired of it — I want to see you solve *that* problem — and my FreeBSD problem is at least as important to the world as your Debian problem).