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
Just curious as to who this guy is...
...and realizing that in today's net-driven society, all it can take is for people to quote you, and others automatically assume you're important. I have no idea who this guy is, and I'm already assuming he's someone since ./ quoted him in an article.
Do not confuse "Freedom of Choice" with "Free Will".
...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
Some other random dude says this isn't true over on his MySpace!
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.
RTFA
It could have been written by Bill Gates or my mom.
Why does the author have to be so important if the facts are laid out and verifiable. You don't have to agree with his analysis nor his conclusions, but the facts should stand or fall regardless of the author
Johns: Well, how does it look now? Riddick: Looks clear.
Dude thanks! I finally know how to install this game on Linux. The last time I tried, I ended up causing my mother's computer to wardial her friends from her recipe club.
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
Current mood: Sad :(
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'll grant I'm not familiar with all the politics and the specific methodology by which a Linux distro tests or achieves LSB compliance, but this blog entry sounds a lot like whining. Ulrich whines that it's hard, that the audit raises many bugs, that it's tedious, that other distros "somehow" achieve their compliance but he's not sure how, that the audit process itself has bugs, and that the LSB group must be pushing this agenda down people's throats.
If it were truly well-thought-out, I'd see either one of two lines of discussion. One would list philosophical proofs that the concept of LSB was unsound for specific philosophical reasons X, Y and Z. The other would list technical proofs that the implementation of LSB standards was unsound for specific technical reasons A, B and C. No whining that it's hard. No whining that other distros do it differently. No whining that bugs are found. No whining that there's politics involved. Just solve the problems found, improve the process of finding problems, or show why the problems or the process is untenable.
[
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
Guys, you're posting to the wrong web site. This is /. , not ./
Dude thanks! I finally know how to install this game on Linux. The last time I tried, I ended up causing my mother's computer to wardial her friends from her recipe club.
That was you?!!?? My mum's gonna kick your mum's ass! ;)
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.
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
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.
thank God the internet isn't a human right.
I'm surprised how well you Mac-trolls can type with only one hand at the keyboard.
Go back to fellating your iPod.
for these two trolls which are posted on every article about Linux. And yet some clueless moderator mods them up despite the fact that they are both wrong and offtopic.
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
The other segment is for desktop OSs that run on generic multi-source hardware. That is over 90% of the market, and that is where the BSDs, Windows and Linux compete.
The hardware part of this market segment is not dominated by anyone, there are low entry barriers and lots of players. The OS part is dominated by MS, but with increasing competition from the BSDs and Linux. Whether this will turn into a real threat, its too early to say. Apple is not a player here, and, right or wrong, evidently doesn't intend to be. In this market segment, OS X, whatever its merits to users, is irrelevant because absent.
Conclusion: it may be too late for desktop Linux or BSD, but not because of OS X.
LSB == Linux standards base :
http://www.linuxbase.org/
The idea of a common set of standards for lots of stuff obviously has many potential benifits for Linux.
The problem with the LSB is it does not do much. What is needed is not a standard for "thou shalt have this version of libc in this directory", but instead a standards body needs to come up with "this is the way you will perform your system initilzation", "this is how you will set and store your ip networking configuration" etc...this would make YOUR skills transferable from distro to distro, would allow the community to come up with BEST OF BREED solutions for things like system configuration tools etc.
Having 1000 different distros do this stuff in 1000 different ways is WORSE THAN not being able to run Oracle on a particular distro without a little tweaking.
-- Given enough time and money, Microsoft will eventualy invent UNIX.
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.
..... but the new stuff probably will be more like the natural stuff so nothing will need to be changed}.
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
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!
Better yet, use Synaptic.
Even better, try not being a plagarizing troll. Go outside and get some fresh air, perhaps also try dating. You'll be happier.
You want the truthiness? You can't handle the truthiness!
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!
How many text editors have you had to learn?
Should I have to learn a text editor? Sure, I had to learn emacs and vim. What about nano? Nano was obvious. It listed the commands at the bottom. Sure it's not the most powerful editor around, but still. It's a freaking text editor. I should be able to open a file, type stuff in, save, and quit, without ever having seen the editor before, and without having to read the man page. None of the GUI editors really suffer from this problem, since they have menus and toolbars to fall back on. But for some reason, the DOS style alt menus in console never caught on in the Linux world, not even as an option.
Sorry, just had to get that one out.
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
#1. Define the format of the package that LSB apps will be shipped in.
#2. Define the functionality needed by the package management system to install, update/upgrade, remove those packages.
#3. Let the various distributions add that functionality to their own systems IN ADDITION to the functionality they already have.
Never define a app as the "standard".
Always define the functionality so anyone can write an app to that standard.
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)
The LFSS (Linux File System Standard) is the main standard I am really concerned about; if developers and OS distributions would stick to that it would solve a great deal of the problems I see when installing applications.
The LSB is overrated imho.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Sorry, are you talking about slashdot or livejournal?
C17H21NO4
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
First what I said above is true, at the time Ulrich said specifically that strlcat and strlcpy wern't nessessary because programers could just check their code for the common mistakes the strl* functions are intended to solve.
1) It is true that they are not in the POSIX, ANSI, ISO, or Single UNIX standards, but neither is a ton of the other stuff in glibc. However, they are supported on almost every non-GNU libc -- making it a defacto standard. Many open source apps use them and there is a BSD-licensed reference implementation.
Not implementing something because sun can't copy and paste correctly on the first try is about as silly as arguements come. If anything the arguement that roll-your-own tends to get messed up is an arguement FOR inclusion not against.
2) asprintf, a gnuism which is also non-standard and less widely implemented, is less used then the strl* functions in actual code. The strl* functions are admittedly not as general as a fixed printf but they are much faster and are near drop in replacements for old code. asprintf is simply not a workable replacement for strlcpy or strlcat. Why should you do a full printf just to cpy or cat a string? Truncation is not the problem you've made it out to be. The strl* API will tell you when it has occured allowing you to make whatever adjustments you need to make. Expanding the heap space to suck up whatever gets thrown at a program is just asking for DoS in many cases. Furthermore truncation is not something strl* was designed to fix. These are drop in replacements for the broken, slow strn* functions. They couldn't fix truncation in the way you and Ulrich want and be compleate replacements.
3) You already said above that roll-your-own was likely to get messed up. It's also stupid to have a few dozen open source apps carting around the code instead of putting it in a library. The GNU C library is one of the only C libraries without this functionality, because of that many programers continue to make the same mistakes that the strl* functions were intended to fix. Not including good, frequently used, defacto standardized code is a really dumb idea, especially when the excuse is that people didn't use the overkill GNU solution.
These functions demonstrably prevent common coding mistakes, prevent buffer overflow attacks, and improve code security. There is every reason to include them in glibc. Not including them was pure ego and NIH syndrome.
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
Yes, and it's very dogmatic. It presents good reasons for the internal API to change, but IMHO the reasons against not offering a stable ABI for external driver support amount more to calling the developers of these "leeches".
...and as a result I'm stuck sitting here porting Highpoint's stupid wrapper to 2.6.13. They're NOT going to give me open-source drivers, and there was no other card in its price range that did what we needed it to do here.
...and for device drivers you're just screwed. =/
Guess what? Tons of products now offer "linux support" by ugly wrappers or, worse yet, per-distro builds, or even WORSE no drivers at all.
Hell yeah I want open source drivers in the kernel. It's nice when the drivers come built-in! Lots of companies agree with this concept in the Win32 environment as well and various builds of the NT kernel ship with drivers for all sorts of hardware built-in.
The problem is not everyone is going to do this...
To whoever modded me flamebait -- it wasn't flamebait! I'm not trying to piss anyone off. I'm just saying that while it's Highpoint's fault somewhat for not updating their driver, it's also the fault of Linux for not having a better-structured way for deprecating and removing old code. (i.e. don't remove deprecated code in minor revisions!)
Fortunately the needed changes aren't that big (I had to familiarize myself with the APIs, both old and new, which is why I'm taking so long), but I shouldn't have to be doing this at all. That's why I'm grumpy.
So right now, with a server that needs to be deployed, would I benefit from a stable ABI (or at least a stable API!) for device drivers? Hell yeah! I would be doing other, more productive things with my time.
THANKFULLY drivers for the chipset family that the 1820A uses are finally starting to trickle into patches to the kernel, but they're in a very very very alpha state at the moment. Maybe in half a year this won't be an issue anymore. =/
Trying to strongarm companies into releasing open source drivers by making closed-source ones a bitch to make work will NOT convince them to open their code (witness ATI and nVidia). We have to show them other merits to opening their code (being installed by default being a good one to start with -- assistance from the community in bugfixes being another).
In order to accomodate stuff that is still closed, we need solid ABIs for things like drivers, for things like standard libraries. Right now the only one we can count on is the basic executable environment ABI. The only way you can count on THAT working is to have everything statically linked into the executeable...
If we had these my job would have a lot fewer headaches and I could focus on more important tasks.
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.