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