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.
← Back to Stories (view on slashdot.org)
Who is Ulrich Drepper, and why should I care about what he says on his LiveJournal?
-mkb
I've been using Linux for many years, and the problem of obtaining software packages drives me to the end of my nerves. Every single time I try to get a package that isn't something extremely common like Apache, I run into major, major problems. Honestly, I don't care how the problem gets fixed. Distribute a binary with everything compiled in for all I care. Distributions distribute every package known to man anyway. :)
./configure nonsense. It sucks.
Something needs to be done. Even with the source, half the time I have to make all sorts of include changes. What is so hard about providing a common build and install process? If you get Apache, OpenOffice, and Mozilla to adopt a convention, everything else will follow. Why not have something like Apache Ant that simply installs either to a user directory or to a common directory and links to every user directory? Then provide a nice GUI on top of it, where it will either compile if the source is there and then install, or just install otherwise? How hard could that be? Forget this
Regardless, this is a perfect example where sometimes it really does make sense to have "management" provide leadership by imposing structure. Ideally, they would be serving and representing the interests of users and helping to overcome the disinterest of joe programmer who doesn't do the psychologically difficult work of catering to someone other than themselves. The "scratch an itch" metaphor breaks down when other people don't know how to "scratch" themselves and need the help of a division of labor to serve their needs. Before you say that they should learn how to "scratch", think that as a community, society, and economy we all scratch eachother's itches in an incredibly diverse number of ways. This comes about because of intentionally trying to fulfill a demand. In the case of the Linux stack of Free/Open Source software, the developers have not taken responsibility for how their product is consumed.
It's interesting because it's true.
The poster points out some of the same frustrations many non-linux people have when they try to use the OS. Keep in mind, that anyone switching to Linux still has to do work. This means any switching to Linux research is going to occupy spare time. That time better be spent getting Linux to do my work better, not me making Linux work at all.
You've been incrementally learning Windows for 10 years now. Every time you change versions you have to go through another learning-curve bump. "Where did they put "ODBC Drivers" now?". If you were suddenly presented with learning Windows on a tabula rasa, your learning curve and frustration level would be just as high as they are for a Windows user moving to Linux for the first time.
If you're a programmer, let me ask you this: How many text editors have you had to learn? Isn't it a pain in the ass learning a new one? "Hell, I already know 43 editors, I have no desire to learn another one". This does not make any of the editors you already know superior to the one you don't, nor does it make the new one inferior just because you don't. Different isn't a priori bad, it's just different.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Were there one available, I would still be unlikely to use it. The fact remains that after you've seen through all the marketing hype, XML remains inappropriate for many tasks, and configuration files are right at the top of the list. You only have to look at Jabber or Tomcat to see some perfect examples of that.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
All other points raised are shown to be consequences of this.
The specific example he cited is a rather enormous bug (a thread which is detached can by definition not be joined. "Detaching" a thread means telling the system that you are not interested in its exit status... and join()ing is reading the exit status).
(This doesn't mean that other examples are as clear cut. It could still be that most tests do actually show genuine glibc bugs, and that he just picked up the right example to bolster his point.)
that the audit raises many bugs
that other distros "somehow" achieve their compliance but he's not sure how
I'd say, if Ulrich is right about the test cases, the situation should be fixed by removing/rewriting the dodgy test cases althogher. Deliberately running distros with non-standard shared libraries or on dog-slow hardware to make them succeed the tests is pointless. If that is indeed how "somehow" some distros achieve to pass the tests, Ulrich is indeed right on the mark that it would make the test suite completely meaningless. You are not certifying a distribution, but you are certifying a distribution tweaked to run the tests...
Better fix the suite, and run the distro under "normal" conditions (i.e. the same as normal users would do).
He's not whining that it's hard. He's whining that it's impossible, because the tests don't match the either the standards or common practice. He's whining that distros must be somehow faking compliance, because they ship *his software* which doesn't "pass" the buggy tests.
.001 seconds). And the same cases are particularly hard to test programs' assumptions about.
His argument is: no set of Linux software could pass the LSB suite by actually consistantly giving the desired results, because there's no libc that consistantly gives those results (when run on sufficiently fast hardware to expose the bugs in the tests, for example); yet distros do claim to pass the suite; therefore, the LSB is not ensuring compatibility, because it certifies things that don't work by their rules.
Furthermore, he argues that programs that don't work tend not to work because they rely on undefined behavior. Certifying that the environment behaves in accordance with the standard doesn't help, because the software developer's environment and the user's environment may do different things in some cases, while both comply with the standard. Unless the programs are tested for doing non-standard things, they won't necessarily work. And the undefined behavior is undefined for a reason: you can't improve the system without changing it (especially when the thing not defined is which takes longer: executing a certain function or waiting
The sections that you dismiss as whining are actually providing examples, which is important in engineering (or science). There are theoretical flaws in any process; it is always important to know whether those situations ever actually occur. If he didn't have an example of a program relying on undefined behavior which should vary between systems, one could say that nobody would actually write code like that and think that it worked; but it turns out that people actually do write such code, and these people happen to include the people writing LSB tests, which is why they're flawed tests.