Yes, the LSB Has Value – The Licquia Blog

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