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)
...seems to be maintainer of the GNU C library, and works for Red Hat. At least, that's what Google says. Should I know who he is??? :/
Game dev and music blog
Ulrich Drepper is the guy who currently leads Glibc development, which makes him an important hacker type person who should hopefully know his stuff.
He also has an ego that could drag Theo deRaadts ego into a dark alley and beat it senseless. He is an asshole.
How he is considered qualified to talk about the LSB when it doesn't have much of anything to do with Glibc, I don't know.
> How he is considered qualified to talk about the LSB when it doesn't have much of anything to do with Glibc, I don't know.
Probably because the LSB was created so that commercial binaries can run on any LSB-compatible distro. A key part of this is also related to symbol versioning in Glibc. As Ulrich is maintainer of Glibc, and as he works for Redhat which has to guarantee LSB certification, I guess he's entitle to talk about the LSB.
--
The world is divided in two categories:
those with a loaded gun and those who dig. You dig.
You really like to post this comment, don't you? At least the 2nd time I read it, word for word, maybe the third.
You are kinda right, though, even though I guess some of those probs come from Suse, never had those with other distros (Fedora and Debian lately), but I always had trouble and instabilities with Suse...
As I understood that somewhat incoherent rant, his complaints are actually about the LSB test suite, not the spec itself, and specifically about linker- and threading-related bugs in the suite.
What I'm listening to now on Pandora...
How he is considered qualified to talk about the LSB when it doesn't have much of anything to do with Glibc, I don't know.
AFAIK, GLIBC is one of the components required for LSB compliance.
And he's right, the LSB was a poorly thought out attempt to make all distributions compatible with RedHat rather than an attempt to come up with a common groud for all distros. For example, why oh why is RPM support required for LSB compliance? It doesn't affect the execution of software on the system, and only serves to create a mess for distros that use another packaging system.
Far more frustrating than that, however, is the fact that LSB only covers the very core of the system. The APIs that 90% of programs rely on are not even mentioned in the LSB spec. Rather, the spec simply states that a few very basic libraries must exist, then goes on to detail the signatures of the function libraries. Not particularly useful unless you're Sun Microsystems looking for a way to convince people that you're compatible with Linux.
Javascript + Nintendo DSi = DSiCade
Not knowing who someone isn't doesn't indicate IQ, nor a drop in IQ. Not knowing someone indicates ignorance on a subject. IQ is a measure of intellectual functioning. A pgymy living in the amazon might not know who the President of the US is, or what a computer is, but he/she could have the highest IQ ever recorded.
./ IQ is dropping.
*Sigh* your post on the other hand, does indicate that the average
But we don't need standards that handle things by way of THIS sort of answer. The link in question is a bug in the standards test. Their answer was not to fix the standards test, like it should have been- it was to, as Ulrich put it, don't use fast SMP machines. In it's current form, the standard is less than useful because you're needing "waivers" for things like this.
Combine this with silly requirements such as needing Sendmail (Uhm, shouldn't it be more along the lines of, we need an MTA of some sort- so long as it's handled properly, who cares which one, right? Sendmail's the least desireable of all of them, and it tends to get turned off for Postfix or Qmail most of the time anyway!) and it's about as useful an appendix is to a human these days.
Yes we need standards. API standards, possibly ABI standards- but not what we're getting here.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I'm a fairly technical user
You certainly have mastered the cut & paste operations.... see here.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
Um, I bought Quake3 for Linux when it was on sale at EBGames and ran it in Red Hat and it was as easy as:
1. Insert CD
2. Double-click on installer icon when file manager window pops up
3. Enter root password when prompted
4. When all is said and done, choose Quake3 from the start menu
From what I can tell, there's only one difference between this and the Windows version that you described, and that's the entering of the root password. And we don't want to do away with that, because it's what makes Linux 90% less susceptible to malware.
Anyway, what distribution and version of Quake3 are you using?
STOP . AMERICA . NOW
LSB == Linux standards base :
http://www.linuxbase.org/
When I read this, I had a curious sense of deja-vu, as if I had responded to this retarded argument once before. And looky here:
http://www.google.com/search?ie=UTF8&q=User%3A+%2Come on. It wasn't even insightful the first time.
What's wrong with you??? You're posting that again and again!!! See:
Comment 1
Comment 2
Comment 3
Comment 4
Comment 5
And some more! Stop it!
For example, why oh why is RPM support required for LSB compliance?
So there is some standard way of packaging a program for all LSB distros. Joey Hess's Alien can turn an LSB-RPM into about any package format you can need.
LSB only covers the very core of the system.
Right; that very core has taken years to standardize.
The APIs that 90% of programs rely on are not even mentioned in the LSB spec.
What programs? It's designed to be sufficient for commerical binaries, which historically statically link everything. There's no way to standardize GNOME or KDE libraries.
The parent post is either a very persistent and unimaginative troll or a script of some kind - it's been posting the same article nearly character-perfect to any thread remotely connected with Linux.
;-)
Please Do Not Feed The Trolls.
Mod down or ignore... for Christ's sake don't reply - it only encourages them
Everything in moderation, including moderation itself
When I installed Bugzilla I issued this command: apt-get install bugzilla. Debconf asked me a few questions, and it worked fine.
Ulrich Drepper isn't some random guy. :-)
Need a Python, C++, Unix, Linux develop
Hmmm... How long ago was you SuSE experience?
:)
I ran SuSE from 7.3 to 9.2.
Or maybe SuSE isn't quite as good as Red Hat or Debian
That may be the case. The dependency problems I had with SuSE were not casued by RPM; they were caused by trying to use RPMs not packaged by SuSE. I've read most of the documentaion for RPM. I can see why Red Hat wouldn't have problems. RPM is a powerful program, it's just not used well by SuSE.
The Gentoo Portage system works well, though I expect a few replies from BSD people who disagree...
Request a Linux Shockwave player here: http://www.macromedia.com/support/email/wishform/
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.
In fact, it's the opposite: XML makes a lot of sense for configuration files. For instance, suppose that you need to write a script that automatically adds a line to /etc/X11/xorg.conf or a similar configuration file. If a file like that is in XML, this is trivial: you can write a XSL transformation or use any of a billion tools to apply the change in a correct way. But if it's in some ad-hoc file format (as it is right now), you either have to write a parser and unparser (which would have been unnecessary if it had been in XML; and how do you know for sure that your code is entirely correct?) or use some hacky combination of sed/grep/etc. to perform the change (which is, alas, the "Unix way"). The latter will of course fail unpredictably in lots of cases. E.g., are you handling those sections correctly? Comments? What if the line was already present? And so on.
Of course, XML is a horribly bulky format. But who cares? It's not like configuration files will take up a lot of disk space either way. The important thing is to have a universal standard format that can be easily manipulated using standard tools so that you don't have to implement parsers and printers all the time or approximate them using broken sed/grep hacks.
While Ulrich has his faults, the above is completely false. The reason they weren't accepted into glibc was IIRC:
1) They are non-std. and did not have a usable standard like definition apart from the implementation and had no tests (Solaris implemented them slightly differently, for example, and Input Validation in C and C++ from oreilly also screwed it up -- and that was written by people selling a Secure codeing in C book).
2) It doesn't solve the problem better than asprintf() which had been around for years (although also non-standard), as you still have problems with truncation (and both APIs have the problem of requiring the programer to correctly pass around the meta data about the string -- Ie. it's size/length).
3) Given the above, and the fact the implementation is "free" then anyone wanting to use them can just include the source in their apps. and rely on autoconf (and they'll also be guaranteed to have the "correct" implementation).
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
The testing process was to run a test, and when it failed, try to figure out if the problem was in the test suite or the tested code. Simple enough.
The tests certainly at some point worked.
No. That wasn't the case. I found myself fixing obvious bugs in the test suite, then attempting to use the fixed version against the target. It was often clear that the test suite could never have worked.
Some distributions still somehow manage to pass the test suits of a new version of the spec. And all this without the people reporting any problems and requesting waiving the test.
We'd report the bugs, with suggested fixes, but we could not wait for fixes to come back and retest. We had to plow forward. We claimed compliance when we had a test we thought tested the assertions and passed it. We never asked for a waiver. Another nice things we came across during the LSBv3 testing are numerous timing problems.
Been there. Done that, though I didn't have to find some slow machine. What is the value of such a certification? What assurance does this give you? Is don't use fast SMP machines an acceptable answer in any universe, especially when it comes to thread tests?
If you have need of slow machines, I can provide approximately 25 working 486/33's. I'd put this on his blog, but he doesn't allow comments. I thought this was strange, because I use livejournal primarily as a place where people can comment. However, he talks about his choice there, too. To each their own.
It is not possible to achieve the goal of 100% binary compatibility...
All good points. And its worse than that. Yet, the exercise was valuable. For us, it uncovered many bugs in SVr3. Many. This was ultimately a good thing for our customers.
We were also a Unix porting house. We fixed lots of bugs in our prior ports of Unix. We offered our fixes to AT&T for free. They declined. We had to apply our fixes to each port - without the benefit of CVS. And, we had thousands of patches. And all this for a basically stable system. It was around then that I was convinced of the incredible inefficiency of propietary software. This would never happen to gcc.
My advise: but the losses.
I read this as "My advice, cut the losses." Oddly, many versions of this mispelling pass my spell checker. Ulrich needs an editor. Perhaps I'll volunteer. Perhaps he can check my work. Will you be a swap editor for me? I'll check your work, you check mine.
So, i agree that the test suite was a horrible idea from the idea that one might assure customers that their old software will still run, or will run on compatible platforms. I agree that the last bug will not be found. However, that is not an excuse to give up the search.
-- Stephen.