Slashdot Mirror


Ulrich Drepper On The LSB

Sam Lowry writes "In a recent post at his livejournal, Ulrich Drepper criticizes the LSB standard and urges the distributions to drop it." It's an interesting piece; Ulrich raises some good points.

4 of 401 comments (clear)

  1. Re:who? by Tet · · Score: 4, Interesting
    How he is considered qualified to talk about the LSB when it doesn't have much of anything to do with Glibc

    The LSB has nothing to do with glibc? Really? Strange. I always thought the LSB was designed to ensure binary compatibility between distributions, and hence has quite a lot to do with glibc.

    Personally, I still think the LSB has some value, but Uli's concerns are valid. IMHO, they seem to point to problems with the current LSB test suite that should be fixed, rather than leading to the conclusion that the whole concept is broken, though. In its current form, there is little value to be had in LSB compliance, true. But it needn't always be that way. A decision needs to be made to either fix the LSB or abandon it altogether. Uli prefers the latter approach. I favour the former.

    --
    "The invisible and the non-existent look very much alike." -- Delos B. McKown
  2. Let's forget binary compatibility by ajs318 · · Score: 5, Interesting

    Let's forget once and for all about binary compatibility. Bury it. Because it does not really benefit most people. There is one very well-known operating system which implements as near full binary compatibility as you can get -- and it's generally regarded as a disaster.

    What matters is source compatibility. And right now GNU/Linux has that in spades. Not just GNU/Linux, but the BSDs, Mac OSX, Solaris and even Windows have it. If the source code is properly written, and properly packaged, then it will compile on any machine that is up to the job of running it. If you make any really drastic changes -- the standard C library for instance -- you might well have to recompile some applications. Is that a major hardship? I don't think so. Back when we changed from round-pin 5 and 15 amp plugs to rectangular-pin 13 amp plugs, people had to have their houses rewired. When we went from artificial gas to natural gas, people had to have their cookers and heaters modified. When Channel Five launched, many VCRs needed their RF output shifted. These were all necessary changes for the better {ironically enough, we probably will be going back to artificial gas in future ..... but the new stuff probably will be more like the natural stuff so nothing will need to be changed}.

    Binary compatibility was never more than a nasty hack, fudged in for the benefit of those who want to lock up the source code of their software. These people are pure evil. By not sharing their code with you, they are just one very tiny step removed from stealing from you. It had the beneficial {at least, it was beneficial when processors were slow and disk space small} side effect that you did not have to spend CPU time and disk space compiling applications locally; but now that disk space and processor power are cheap, the benefits of pre-compiled applications are diminished substantially.

    There's even a good argument to be made in favour of deliberately introducing binary incompatibility. If programs compiled on my computer would only ever be able to run on my computer, and any program compiled on anyone else's computer would never be able to run on mine, then there would be no such thing as viruses or buffer overrun vulnerabilities. {Unfortunately, this raises the question of how to ever get any computer up and running}.

    --
    Je fume. Tu fumes. Nous fûmes!
  3. Re:The MAIN GCC developer... by the+morgawr · · Score: 4, Interesting
    glibc developer actually

    And while he happens to be right in this case, I don't think very highly of him. He's clearly very bright, but the poster above who said that Ulrich had a bigger ego than Theo was spot on. Too often, he lets his ego and NIH syndrome get in the way.

    For example glibc is the only major C library that doesn't support the new buffer proctected string functions originally written by OpenBSD (at least last time I checked). These fuctions are faster, safer, and easier to use then the POSIX ones and are supported not just on BSDs but almost every commercial UNIX. Source compatability alone would dictate including them.

    Drepper however has repeatedly refused to include them because they work and they make it too easy to not code buffer overflows (no this is not a joke). According to Drepper programmers should be good/smart enough not to mess up something so simple as a string buffer so including a defacto standard that makes it easy to get it right is inappropriate. WTF?

    --
    The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
  4. Re:who? by tolkienfan · · Score: 4, Interesting
    The problem is actually quite simple.

    If the test-suite is broken, then the LSB guaranties are worthless.