Debian Switching From Glibc To Eglibc 565
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.'"
Re:Efficiency? (Score:3, Informative)
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.
Re:uClibc (Score:5, Informative)
That's not to say uClibc isn't useful, but it doesn't have the same goals (or features) as glibc or eglibc.
Re:uClibc (Score:5, Informative)
Agreed. It's what Gumstix [gumstix.com] 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.
Re:uClibc (Score:5, Informative)
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 [sourceware.org] and dietlibc [www.fefe.de]. 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.
I make a living on this embedded crap (Score:5, Informative)
Re:FINALLY (Score:4, Informative)
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.
Re:For the greater good (Score:5, Informative)
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.
Re:uClibc (Score:3, Informative)
IIRC, uClibc can't run Apache. There's a place for uClibc, but that place isn't a generalized distribution like Debian.
Re:Hope it works (Score:2, Informative)
The problem isn't GLIBC. It's Ulrich Drepper. (Score:4, Informative)
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 [sourceware.org] 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.
Re:Imagine (Score:3, Informative)
Won't someone explain this in terms of a car analogy!?
Car analogy ho!
"Toyota recently announced that it will be switching manufacturers of its most commonly used drive trains because the original manufacturer said that the changes Toyota requested were 'for the sole benefit of this hybrid/electric crap.'"
In other words, in three years time, glibc might be used only by RHEL6, and Ulrich Drepper will just be forking eglibc and calling it glibc.
Re:"So what" vs "Wow, unbelievable" (Score:5, Informative)
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.
Re:At Least It's Egier to Use and Less Glib (Score:5, Informative)
" Any change will negatively impact well
designed architectures for the sole benefit of this embedded crap."
^ Actual Quote.
Re:GLIBC is the cause for all binary incompatibili (Score:5, Informative)
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 [gentoo-wiki.info] for information and a tarball of the necessary libraries.
Not the most elegant solution, but it's easier than dealing with a chroot.
Re:Yay! (Score:5, Informative)
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.
Re:"So what" vs "Wow, unbelievable" (Score:1, Informative)
And that's just the actual detrimental-to-the-code stuff, let alone the nastiness he spews on a personal level.
Re:The problem isn't GLIBC. It's Ulrich Drepper. (Score:5, Informative)
And this is from a single bug report alone.
You are aware I hope that the last comment (and one earlier) is from a fake Drepper? (check the mail addy)? :)
Re:Yay! (Score:5, Informative)
The IBM implementation has to represent about 99.9% of all EBCDIC systems in existence. Ignoring it is just asinine.
Re:For the greater good (Score:3, Informative)
Embedded architectures are never well designed. Their purpose is not to win "best design" award - but to be cheap and efficient.
Embedded systems are extremely high volume market. Sparing few transistors here there often saves $$$$$ when you get into shipment volumes with 4-6 zeros at the end. Software development is often one time effort, that's why such oddities (as Ulrich have complained about) with easy workarounds are quite common. Main savings are coming from actual H/W costs.
Re:FINALLY (Score:5, Informative)
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.
Re:More context (Score:1, Informative)
I hadn't read the whole thread when I replied.
Looking at it more it seems like he's calling the ARM ABI crap because it breaks his brittle code which makes unwarranted assumptions about structure alignment and padding.
How is it that this idiot is working on something as important as glibc?
Re:The problem isn't GLIBC. It's Ulrich Drepper. (Score:5, Informative)
I personally enjoy this old classic:
http://sources.redhat.com/ml/libc-announce/2001/msg00000.html [redhat.com]
Scroll down to the thanks list, and read below. Not saying who is right or wrong here, but it makes for some funny reading.
Re:Some of Ulrich Drepper's finer points (Score:3, Informative)
Wow. #2 actually had me laughing out loud. That's pretty unusual for a bugzilla report :)
Re:Might be a good idea (Score:5, Informative)
Re:Might be a good idea (Score:5, Informative)
Drepper does come across as an asshole totally antagonistic to ARM and embedded development. But after a little googling [google.com], 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!
Re:Don't be so Glib (Score:4, Informative)
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).
Re:At Least It's Egier to Use and Less Glib (Score:5, Informative)
Re:FINALLY (Score:2, Informative)
Re:Might be a good idea (Score:5, Informative)
It's horribly inefficient BSD crap. Get your Drepper quotes right! [redhat.com]
Re:I make a living on this embedded crap (Score:2, Informative)
Re:FINALLY (Score:5, Informative)
The guy knows what he is doing, too. If you haven't, I suggest reading his paper:
http://people.redhat.com/drepper/cpumemory.pdf [redhat.com]
No, Ulrich Drepper's response was appropriate (Score:4, Informative)
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.
Re:"So what" vs "Wow, unbelievable" (Score:3, Informative)
Getting in a pissing match over support for an irrelevant feature doesn't inspire me with confidence in Debian's leaders.
Check the eglibc home page. This isn't the only case where he's viciously attacked people who have pointed out bugs and sent him patches.
Re:FINALLY (Score:3, Informative)
Please go back and re-read the post to which you replied. I think you missed something, like some small amount of sarcasm.
Re:No, Ulrich Drepper's response was appropriate (Score:1, Informative)
Anyone is free to waste his/her own time. Applying a patch takes a trivial amount of time in any sane project. If someone wants to fix an easter egg, I say let them.
Re:"So what" vs "Wow, unbelievable" (Score:5, Informative)
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.
Re:For the greater good (Score:3, Informative)
bconway posted 4 citations [slashdot.org] earlier.
Re:At Least It's Egier to Use and Less Glib (Score:5, Informative)
That particular comment was in response to something posted by a fake Drepper. Check the email address for comment #40 [sourceware.org].
Re:contentious project manager with a god complex? (Score:1, Informative)
The funny thing is that he’s not friends with Theo. Theo tried to make strlcpy and strlcat the de facto standard, in order to reduce the number of buffer overflows, but Drepper famously rejects them as “horribly inefficient BSD crap.”
When I saw this interview [kerneltrap.org], where Theo complains that “one person decided to be difficult,” my immediate thought was Drepper.
Re:At Least It's Egier to Use and Less Glib (Score:5, Informative)
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.
Re:Don't be so Glib (Score:3, Informative)
Well, if you had read the summary, you would notice that it is binary and source compatible. I would assume that they would stay relatively close except in cases where glib is being uncooperative.
Re:Don't be so Glib (Score:3, Informative)
Please read the summary.
The maintainer is hostile to ensuring compatibility on ARM.
Yay! (Score:4, Informative)
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.)
Re:Don't be so Glib (Score:5, Informative)
The ABI is compatible with glibc, this doesn't preclude them from including new functions like strlcpy and strlcat [redhat.com] - which again looks like something that Ulrich Drepper doesn't think is a good idea [redhat.com]. In fact, the man went so far as to reject the patch [redhat.com], stating that:
Fork couldn't have come soon enough!
Re:I make a living on this embedded crap (Score:4, Informative)
I develop "embeddded" systems for the broadcast industry. Most every piece of broadcast equipment in a satellite truck and cable head end system runs some flavor of glibc in Linux.
I quote embedded since it can mean different things to different people. We use a 233 MHz PPC processer with 128 Meg Ram which easily handles 60Mbit high-def streams. Relative to a modern desktop, our base system it is a bit light, but it's plenty enough to run the full glibc.
Re:FINALLY (Score:1, Informative)
strl* functions are made to be as fast as possible and as useful as possible so that retards like you don't use strn* and str* crap to win a few bytes or cycles.
-1 on truncation is completely useless. Look at Microsoft safe string functions for reference on real crap.
Oh, truncation happened! Alarm!, alarm! call a handler. Okay, let's try again with a bigger buffer and hope to be luckier this time or waste yet another call with strlen(at this point you should have done strlen and memcpy).
BTW, growing buffers are slow and problematic for many reasons you wouldn't understand anyways. Go back to your Java.
I post as AC because I happen to have modpoints.
Re:At Least It's Egier to Use and Less Glib (Score:5, Informative)
Indeed - and not just ordinary, non-involved people. In one bug alone, he managed to upset Gentoo's Mike Frysinger [sourceware.org], 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. [sourceware.org], and gave the MirOS developer Thorsten Glaser [sourceware.org] cause to comment on Drepper's standards.
Nice going!
Re:For the greater good (Score:4, Informative)
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.
Re:"So what" vs "Wow, unbelievable" (Score:4, Informative)
This [redhat.com] bug I haven't seen linked to in the comments in this story yet, but it's another gem.
Re:"So what" vs "Wow, unbelievable" (Score:2, Informative)
The following survey disagrees with your perception of Debian not having a significant presence in the embedded market: http://www.linuxdevices.com/articles/AT7065740528.html [linuxdevices.com] . I suggest you back up your statement with relevant information if you wish to use it as an argument.
Also, Ulrich Drepper does not have "every right" to disregard the ARM platform as long as it is listed as a supported architecture. My request to the steering committee can be seen here: http://lists.debian.org/debian-glibc/2007/10/msg00038.html [debian.org]
Re:Don't be so Glib (Score:3, Informative)
Yes but did you read the thread?
strlcat was the salvation for those who have already been punished by legacy applications abominable use of strcat.
Sam
Re:Don't be so Glib (Score:3, Informative)
Good questions, but unfortunately for MS its a different situation.
1. Apple's Rosetta works because it the Intel hardware its running on is more powerful than the PPC hardware its emulating. A better example would be VirtualPC on Apple PPC hardware running Windows. It worked, but it was dog slow compared to VMWare or Parallels on Apple Intel hardware.
Another option some people have mentioned, that goes along with Rosetta is the idea of "Fat Binaries" where one "binary" actually includes multiple binaries for different architectures. Apple did this with their Universal Binaries that contain both PPC and Intel code inside them. This allows the same binary to work on multiple architectures. Its a great idea and contains the flexibility to let you support multiple architectures, but I think MS would need to modify the OS to support it, and even then, it balloons the size of the binary because of all the "redundant" pieces that most users won't even use. This isn't something that you want for a netbook. On OSX this extra space can often run in to the GB depending on how many applications you have installed. Once of the big things in Snow Leopard is that removing PPC support allows Apple to start stripping out that cruft themselves (at the expense of no longer supporting PPC hardware from 3-4 years ago).
2. .Net is SUPPOSED to be architecture independent, and most of the stuff that is developed for Mono is, but a lot of the stuff MS develops make calls to WINtel specific libraries. They (MS) would have to port these libraries to ARM. They could certainly do it, but I doubt it would just be "recompile the source" since a lot of those libraries were probably not coded with portability in mind, let alone making sure that the architecture supports the features the libraries are expecting, in the format they are expecting.
Re:Might be a good idea (Score:3, Informative)
You have to love his replacement example [redhat.com]:
*((char *) mempcpy (dst, src, n)) = '\0';
Re:Some of Ulrich Drepper's finer points (Score:3, Informative)
Particularly #3. Someone finds a bug, submits a patch, and in return gets mocked for their effort. How great.
Side note for anyone who actually wants strfry to be statistically valid: the fix doesn't completely fix it.
Suppose that __random_r returns a value between 0 and 9, inclusive. Suppose than len is 8. In that case, j %= len maps to:
In this example, 0 and 1 occur twice as often as any other value. The fix for this problem is to pick a threshold close to 2^31 that is a multiple of len, and keep requesting values for j until you get one less than the threshold. Then you'll get an even distribution on j %= len.
Re:Don't be so Glib (Score:3, Informative)
You and the vast majority of C programmers, it seems.
Security aside, think of it from an efficiency perspective: it always starts from the beginning of the target string (since it has no other information available to it), iterates to the end, and then begins catenating the second string. This gives you O(n^2) behavior when catenating multiple times to the same string. The str* functions are some of the worst ever designed...
There are two obvious fixes:
1) always record explicit lengths of your strings, so that you can catenate by just memcpying to the end of a given target string
2) use my strcopy() function, which returns the pointer to the terminating NUL at the end of the target string.
E.g., this is legal and useful:
strcat(strcat(strcpy(a,b),c),d);
but it's slow because each strcat starts over from the beginning. If strcpy/strcat always returned the pointer to the end of the target string, instead of the pointer to the beginning of the target string (which is what strcopy() does) then you get no efficiency loss, and you only need one function instead of two:
strcopy(strcopy(strcopy(a,b),c),d);
After you fix this basic inefficiency you can of course define strn/strl variants as you see fit...