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

If you dont run Red Hat,
your system is broken by Drepper’s standards anyway.

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?

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.

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.

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

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.

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.