Slashdot Mirror
Debian Switching From Glibc To Eglibc
ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"
Not really in any way that you'd notice. It comes down basically to the fact that, despite glibc being rather portable, Drepper is a bit of an asshat towards the ARM community, and Debian needs to work on more than a dozen architectures without asshattery.
It's also not so much of a fork as it is a "branch", sort of like the cherry-picking that happens to generate the -mm tree of the kernel; it's not 100% of the same sauce, but it's close enough that mostly nobody cares.
uClibc is not binary compatible with glibc, so you can't compile on one and run on the other. Heck, uClibc is generally not even binary compatible across versions -- you have to recompile the whole system every time you update uClibc.
That's not to say uClibc isn't useful, but it doesn't have the same goals (or features) as glibc or eglibc.
Agreed. It's what Gumstix seems to be using for their tiny ARM-based boards, it's a good lightweight alternative to the increasingly bloated glibc.
ARM is getting big these days, it's not a market to sideline.
"I bless every day that I continue to live, for every day is pure profit."
Because uClibc has(had) inferior threading and performance. And it is(was) missing the GNU extensions that many popular FOSS projects depend on.
There is also newlib and dietlibc. In many ways I find newlib to be better than uClibc, although I still tend to use uClibc for projects because it's good enough and we already use it.
“Common sense is not so common.” — Voltaire
Devices like MP3 players, set top boxes, and mobile phones account for far more GLIBC deployments than desktops and servers.
Sure he's a bit abrupt on the glibc dev list, but does any of that really interfere with his role as package maintainer?
I mean other than the fact that he rejects small, well-designed patches to the build system because the problem doesn't affect him -- he insists that no mere mortal should build glibc anyway.
And maybe he packages the system to fail with no useful errors when building with the default options on i386 -- but he also capriciously and unilaterally decides which platforms are supported both as targets and build systems, and again, mere mortals shouldn't attempt to build glibc in the first place.
And he doesn't package releases into tarballs, and only tags new releases on his schedule, even if the last release has major bugs with committed, tested patches in wide use downstream -- but he does apply tags on an arbitrary schedule to code that may or may not have been widely tested, so at least releases are predictable.
Not only that, but Drepper was taking with where the change was being made. He was suggesting that the alternative implementation be in an architecture-specific file rather than changing the generic implementation.
In other words, in this particular case, the idea was that the original patch would incur a performance hit to x86 and other mainstream architectures in compensating for ARM's differing alignment. Consequently Drepper wanted the change to be done in a platform-specific file outside of his purview.
The problem isn't GLIBC. The only problem is this idiot Ulrich Drepper. He demonstrates time and again that he is incompetent and has no business being in a position that is forced to interact with other people. This Ulrich Drepper character has the nerve to say stuff in bug report discussions like this such as:
anything handy and certainly have no interest in writing it up.
cannot order me around.
issue at hand. Otherwise you would have noticed that this code has been
entirely rewritten in the current code. It uses a very different implementation
which allows to handle this situation differently.
And this is from a single bug report alone. Why exactly does GNU tolerate such a thoughtless idiot in such a fundamental position in such an important project? Moreover, this idiot Ulrich Drepper even shuns support important architectures such as ARM apparently due to nothing more than whims. How can this be?
GNU is supposed to be a project for it's users by it's users. You don't go far if you rely on antisocial morons to handle PR stuff.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
Actually Debian is quite prevalent in the embedded space. It's a very consistent develop environment across 11 supported architectures and an additional 5-10 unsupported ones.
Paying taxes to buy civilization is like paying a hooker to buy love.
" Any change will negatively impact well
designed architectures for the sole benefit of this embedded crap."
^ Actual Quote.
Not even an old program written from Loki Software Entertainment would run on a modern Linux Mint (2.6 kernel) for example unless in a chroot'd sandbox. Truly sadistic, that I even remember this happening even on the same kernel branch. Bruce Perens would address this better than I, but my time is worth more elseware.
You can do it by installing the old libraries and using LD_LIBRARY_PATH and LD_PRELOAD. See the Gentoo Wiki archives for information and a tarball of the necessary libraries.
Not the most elegant solution, but it's easier than dealing with a chroot.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
Um, if you're describing that right, isn't he right to reject your patch? What if I'm a user of another EBDDIC system, and that system uses the choice that's in the library? Does that mean that if your patch is accepted, my patch to undo yours should be equally accepted?
I suppose that is sort of correct. But the major EBCDIC system out there that people use these days is z/OS. I sort of doubt you could've actually found another system the change affected because it didn't change all EBCDIC encodings, just a specific version of the EBCDIC encoding.
What I did is I created my own encoding that was named very similarly and carefully rebuilt glibc with every update. But that was a poor solution in several respects because that encoding is mentioned by name in several IBM manuals.
I guess I would've appreciated a tiny bit of discussion, or perhaps the mention of a different system my change would've affected negatively. Neither were forthcoming, and I really doubt there is such a system.
Need a Python, C++, Unix, Linux develop
The IBM implementation has to represent about 99.9% of all EBCDIC systems in existence. Ignoring it is just asinine.
Comment of the year
He refused nscd patches to fix issues in glibc that had numerous gross errors like:
1) assumed all replies arrived in one packet
2) database storage mishandling
3) zero-length returns from syscalls due to unrelated signals
And then last year he "found" many of these bugs and finally fixed them the same way, after rejecting the same patches 3 years earlier. Ulrich Drepper is the reason nscd sucked so badly for so many years in Linux, as he's the reason for so much other suckage, and the reason most distributions end up with a heavily forked glibc anyway. This is just sharing those forks - the forks happened many years ago in every distribution that works. Even Redhat has a glibc that's heavily forked from the mainline, and they pay him.
Which, unfortunately, is the problem with glibc. Remember the fact that he refused to incorporate the safe string handling functions because they were 'inefficient BSD crap,' forcing portable OpenSSH and a number of other projects to include their own copies of things like strlcat()/strlcpy() to work on GNU systems?
I am TheRaven on Soylent News
Drepper does come across as an asshole totally antagonistic to ARM and embedded development. But after a little googling, I'm convinced his thinking is a little more complicated than that. Basically, he seems to think that glibc is poorly suited to embedded applications, and wishes that ARM developers would develop their own specialized libcs.. He's also concerned that in GCC development, the needs of some platforms that happen to have powerful backers (such as AIX) get more priority than their mindshare deserves.
He's got some good points. He does express them in a way that's unnecessarily offensive and combative. But that doesn't make him an asshole. That makes him a typical geek!
I know you mean Windows in the XP/Vista/2007 sense, but historically Windows CE/Mobile has run on ARM chips. While current netbook users demand slightly more out of their machine than they'd have had in a PDA five years ago, an up-to-date mobile edition of Windows would run on embedded chips splendidly (or as splendidly as Windows runs).
I'll be your candy shop of infinite deliciousity if you'll be my discotheque of endless rump-shaking.
For even more context, look at the patch. The "negative impact" is a couple extra microseconds of cpu time to memset 20 bytes instead of 3. I guess 32-bit x86 ought to be enough for anyone.
Do you even lift?
These aren't the 'roids you're looking for.
It's horribly inefficient BSD crap. Get your Drepper quotes right!
The Yasashii Syndicate ||
The guy knows what he is doing, too. If you haven't, I suggest reading his paper:
http://people.redhat.com/drepper/cpumemory.pdf
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Did you actually read #3? strfry() is a joke function, an silly Easter egg that had been included in Glibc since time immemorial and unfortunately cannot be removed for fear of breaking compatibility.
Anyone with half a brain can see that fixing "bugs" in ancient Easter eggs is a waste of developers' time. If I were in Ulrich Drepper's position, my response would be similar to his, but with more insults.
It was just somebody lost and reporting a bug in the wrong place - pissing off the maintainer a little bit and resulting in a three line reply with an insulting middle line. Now we only get to see the insult without the suggestion of putting the code where it belongs.
If you look at the thread the bug had already been fixed two months before in the port where some thought it belonged (sysdeps/unix/sysv/linux/arm/check_pf.c) instead of in the main branch where the submitter thought it belonged.
Not only is this out of context it also is from two years back. It's as petty on Debian's part as it would be going off at RMS for his "linux? Never heard of it. Haha" comments for most of the 1990s. It's almost as petty as the Iceweasel squabble over the logo. I suspect that the person at Debian responsible for this petty press release should be a little more honest in their tantrums instead of cherry picking two year old quotes out of context.
That particular comment was in response to something posted by a fake Drepper. Check the email address for comment #40.
yes, nanoseconds. If that.
Just for kicks, I compared memsetting 20 bytes (aligned) vs 3 bytes (unaligned) with llvm-gcc (which can output code in a dozen assembly languages).
For mips, sparc, and ppc32, a 3-byte unaligned memset must be done 1 byte at a time, so the 20 byte memset is only 2 instructions more (5 32-bit stores).
For 64-bit alpha and ppc64, the 20-byte memset only uses 3 instructions (2 64-bit stores + a 32-bit store).
x86 (and arm, for that matter) can do a 3-byte memset as a 8-byte set and a 16-byte set.
Do you even lift?
These aren't the 'roids you're looking for.
Please read the summary.
The maintainer is hostile to ensuring compatibility on ARM.
I use eglibc, and I like it better. For instance, when I was a bit distressed to discover that glibc shipped with scripts which require bash or ksh (not a good fit for a TINY embedded system), I went and looked. The dependencies there could be EASILY removed with no significant harm done -- and the scripts would work. One of them took me all of twenty minutes to clean up to make it functional with any POSIX shell.
This isn't rocket science. It also isn't software engineering. I was first disappointed with glibc's performance somewhere around 1996, and it's never really won me over since. eglibc seems to me to be a much nicer approach.
(Full disclosure: I think $dayjob funds some eglibc development, and we certainly use it.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
The ABI is compatible with glibc, this doesn't preclude them from including new functions like strlcpy and strlcat - which again looks like something that Ulrich Drepper doesn't think is a good idea. In fact, the man went so far as to reject the patch, stating that:
Fork couldn't have come soon enough!
XML is like violence. If it doesn't solve the problem, use more.
Indeed - and not just ordinary, non-involved people. In one bug alone, he managed to upset Gentoo's Mike Frysinger, he told Petr Baudis of SuSE that "I never saw your name on my paycheck. Since if that's not the case you cannot order me around., and gave the MirOS developer Thorsten Glaser cause to comment on Drepper's standards.
Nice going!
XML is like violence. If it doesn't solve the problem, use more.
Not only that, but Drepper was taking with where the change was being made. He was suggesting that the alternative implementation be in an architecture-specific file rather than changing the generic implementation.
The problem is that the code before the fix wasn't generic at all. It could break on any architecture, and, in fact, it isn't even guaranteed to work on x86.
This bug I haven't seen linked to in the comments in this story yet, but it's another gem.