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.

Comments

Re:who?

[Tet]

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.

currently leads Glibc

[oliverthered]

Then I wish he'd put a XML parser into glic so that no-one has an excuse for not using XML for configuration files and for data export / import.

Re:I agree, but something needs to happen

[aussersterne]

I think the (possibly regrettable, I don't know) answer to this is that Linux users need to choose: they can have an easy-to-use distribution that is a near monopoly in the Linux world (which is WHY it will then solve problems like the one you describe), or they can have a hundred different distributions.

Right now, so long as you pick one of the "big three" (Debian, Red Hat/Fedora, SuSE), you will have very little package/software install trouble.

Most companies that release Linux software offer the following downloads (as do most OSS software websites for individual products):

1. .tar.gz to compile from source (gets you right into th dependency hell you want to avoid)
2. RPM for Red Hat/Fedora
3. RPM for SuSE
3. DEB for Debian

I have been in the Red Hat family since Red Hat 5 or so and I can tell you that beginning with Red Hat 8 things started to get really easy, and by the time the Fedoras had come around, I spend nearly zero time compiling my own software or chasing package dependencies. Tools like yum/apt even make it so that you don't have to FIND a download site and double-click on and icon, you just type in a command that says "I WANT IT!"

But even for commercial software like Flash or Java, it's cake, I just install the package. The reason is because the package is DESIGNED FOR MY OPERATING SYSTEM.

Sorry, but most of the other Linux operating systems (Slackware, Mandrake, Yoper, Xandros, whatever) are too small for packagers to target them, and that's generally what results in package hell--you are trying to use a package that assumes the components installed by default in another operating system. So even if they are both RPMs, installing a Red Hat/Fedora RPM on Mandrake will cause you trouble. Even once you get the packages all installed, the configuration and support files are likely to be located in all the wrong places.

And yes, generally the packages ARE clearly labeled. So I guess my answer is the one people hate to hear, but if you're going to ask the question about "package hell" then you're going to get this answer: switch to a bigger distro (best case is probably Red Hat/Fedora) and the problem will generally go away.

Let's forget binary compatibility

[ajs318]

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

Re:The MAIN GCC developer...

[the morgawr]

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?

Re:who?

[tolkienfan]

The problem is actually quite simple.

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