Slashdot Log In
Debian Switching From Glibc To Eglibc
Posted by
timothy
on Wed May 06, 2009 04:13 PM
from the dismissed-with-cause dept.
from the dismissed-with-cause dept.
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.'"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Hope it works (Score:5, Funny)
I would hate the embedded version's maintainer to not want to fix a bug that was simply for 'for the sole benefit of this desktop crap.'
Might be a good idea (Score:5, Interesting)
Re:Might be a good idea (Score:5, Insightful)
Speaking as a Debian user who has had some major upgrade problems directly caused by glibc, anything that's "more upstream friendly" is okay by me.
I don't think this means "easy to upgrade", but rather "the maintainer isn't an asshole".
Parent
Re:Might be a good idea (Score:5, Informative)
Parent
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!
Parent
FINALLY (Score:5, Interesting)
Drepper has had this coming for many, MANY years.
He has pissed off practically everybody in the FOSS world at least once.
Good riddance.
I hope this ends up like the gcc/egcs thing a while back. In the end the old gcc was shut down and egcs was renamed back to gcc.
It would be for the best of glibc if this Drepper dude got removed from the project.
I still think we should organize a mud wrestling match between Ulrich and Theo.
Re:FINALLY (Score:5, Funny)
Parent
Re:FINALLY (Score:5, Insightful)
Drepper has had this coming for many, MANY years.
Frankly, I'd say Ulrich is fitting person for a project like glibc.
I do not think his a bad guy, it's just a job of glibc maintainer (which is a central piece of "Linux OS", second most important after kernel) would make out of anybody an a**hole.
I'd say his job is 99.9% of times saying "NO" to all the silly proposals flying all the time on glibc mail lists.
But it's just in this case he was wrong. Shit happens.
Parent
Some of Ulrich Drepper's finer points (Score:5, Interesting)
From TFA: 1 [sourceware.org] 2 [sourceware.org] 3 [sourceware.org] 4 [sourceware.org]
Parent
Re:Some of Ulrich Drepper's finer points (Score:5, Insightful)
From reading those posts, it is pretty clear that this guy seems like a total douchebag and in my view has no business maintaining any serious open source project, let alone something as important as glibc.
Particularly #3. Someone finds a bug, submits a patch, and in return gets mocked for their effort. How great.
Parent
Re:FINALLY (Score:5, Interesting)
Parent
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.
Parent
Re:FINALLY (Score:5, Interesting)
Sure he's a bit abrupt on the glibc dev list, but does any of that really interfere with his role as package maintainer?
Yes. When he refuses to incorporate the string manipulation functions that don't perform silent truncation, that's a security problem. Every BSD libc (including Darwin/OS X) has strlcat() and friends, but Drepper decided they were 'inefficient BSD crap'. A few projects, like OpenSSH, just include a copy of the ones from OpenBSD libc in their own code, but other projects over the years have just fallen back to strncat() and friends if the safe versions aren't available, and had security problems on GNU platforms that didn't apply elsewhere.
If you're going to refuse patches for no reason other than the fact that you're an idiot, then it is affecting the project you maintain and a fork is an excellent idea.
Parent
Re:FINALLY (Score:5, Insightful)
Honestly, even if none of that were true, you're not allowed to be an asshole any more if you are in charge of a major project. Open source is a *community*, and people flee the community when it's populated by assholes. Darwinian selection tends to filter out assholes in this environment, because it doesn't take all that much to advance a better project, even if the asshole is extremely gifted.
Parent
downstream from debian (Score:5, Interesting)
downstream we have many, many distros now adays.
so, if this eglibc becomes the default, it'll end up being the default in pretty much all debian based distros like ubuntu, mepis, xandros, etc.
a repeat of the whole xfree86/x.org thing ?
For the greater good (Score:5, Interesting)
As the maintainer of GLIBC, he has to be the steward for the greater good of all users. And sometimes that means pissing off a vocal constituency.
Re:For the greater good (Score:5, Interesting)
Parent
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.
Parent
Re:For the greater good (Score:5, Insightful)
The code hit an assert() in glibc. That is per definition a bug. You should never implement an assertion and then complain if someone hits it and confronts you with the design choices of that time. When you are informed of a triggered assert(), then you should act like a man and fix the code.
Parent
A rant (Score:5, Insightful)
> As the maintainer of GLIBC, he has to be the steward for the greater good of all users.
No, it needs to be correct code. If ARM happens to be the only platform that currenty exercises the bug it is still a bug. Goddamn people, I swear we are getting as blase about fixing bugs as a Microsoft shop. There is no such thing as a good bug, a less important bug, etc. If it is a bug and someone has a patch for it you APPLY THE DAMNED PATCH. If you have a problem with the patch you write a better patch. Not patching at all is never be the answer.
I really hate updating my systems these days, because for every bug fixed it seems you get a fresh new one. Make it shiny, we will fix the bugs later! Of course later never comes, eventually the crap piles up too high and somebody decides to just start over. Which explains the piles of discarded stuff and the new one that also doesn't quite work in most areas, especially in system administration.
Seriously, the Free Software world needs to call a timeout. Establish a core and devote every available resource into making that core bug free and secure. Then allow no change to be committed to that core without extensive peer review to prevent new bugs from getting in. The Linux kernel is hopeless, no chance of getting it to stop and clean up and x.org is currently in a period of upheaval, but the layer above each could be stabilized. Not just coreutils, but everything including the core widget sets, admin tools. Get things to a point where an ordinary userland package will (not might) work even it it wasn't built against the exact same release.
And finish hashing out the whole new /dev/, dbus, etc. and settle the API down enough to document the damned thing. I know UNIX, but this new stuff totally confuses me. WHere does one go to even find out how it is supposed to work? Which of course isn't how it currently DOES sorta work. How does one even know if a particular piece of documentation, sketchy and incomplete as it will certainly be, documents what was, what currently is or what is intended to be?
Parent
Re:For the greater good (Score:5, Insightful)
Reading the context didn't help his case any. I read the bug report, and the attached patch, and was appalled that Ulrich thought he was defending good code. If the code is expected to run on even ONE other platform, what he was doing was incredibly stupid. It doesn't matter if the vocal constituency is on a platform that doesn't please Ulric. There is more than one officially supported platform, so therefore his opinion was idiocy of the highest order.
Anybody who thinks it's a good idea to depend on the size of structure padding, on one specific platform, with one specific compiler, and code a memory violation on that expectation, deserves all the vitriol the community can muster. Take his compiler away from him. He's not fit to write C.
Parent
Re:For the greater good (Score:5, Interesting)
He's not fit to write C.
Which is probably why glibc source code looks like preprocessor soup.
Parent
Yay! (Score:5, Interesting)
I've been wishing for ages for maintainership to be taken away from Ulrich Drepper. Every single bug report I've seen submitted to him has been shot down for some stupid, insane reason, even when it's been accompanied by a patch. He's a bad maintainer.
One example, I submitted and update to an EBCDIC encoding used on IBM mainframes. The encoding had several choices for what should be encoded as the newline character. It wasn't clear which one should be used, but the z/OS system I was using had definitely chosen a particular one. Glibc had chosen a different one. I submitted a patch that changed it and Ulrich rejected it saying that there wasn't a standard and so my version was no more valid than the version that was in the library.
And, on another case, it was clear that the /etc/localtime was being read for each and every field that was being printed in strftime. This both caused things to be slow, and it also created a race condition if that file was changed. I recommended to the person who found the bug that he submit it. He did, and Ulrich rejected it for some bizarre reason I can't recall.
He is an awful maintainer, and I really hope the project is taken away from him by this fork.
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.
Parent
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.
Parent
I make a living on this embedded crap (Score:5, Informative)
"So what" vs "Wow, unbelievable" (Score:5, Insightful)
And the developer has every right to make that call, just as eglibc has every right to make a fork that cares more about the embedded world, and Debian's maintainers have a right to switch.
That said, I have two main thoughts on this issue.
First, only a complete idiot would ignore the fact that one of Linux's primary strengths lies in the embedded market. Refusing to fix a relatively easy bug because it "only" affects that market sounds like something Microsoft would force on us "for your own good", such as DRM or the UAC.
Second, Debian (as a stock install, I don't include remastered lightweight Knoppix variants in that category) does not have a significant presence in the embedded device market. Such uses either involve a platform-specific lightweight distro where available, or the devs take a roll-your-own approach. Getting in a pissing match over support for an irrelevant feature doesn't inspire me with confidence in Debian's leaders.
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.
Parent
Re:"So what" vs "Wow, unbelievable" (Score:5, Insightful)
And the developer has every right to make that call
Who said or implied otherwise in any way shape or form? Seriously.
Getting in a pissing match over support for an irrelevant feature doesn't inspire me with confidence in Debian's leaders.
But ARM is a supported architecture, used enough at least that they found the bug, and the bug was in glibc and thus affects all distributions that use glibc. What would make me lose confidence in Debian's leaders is if they agreed that because it's an "irrelevant" architecture that it shouldn't be fixed.
And just because the bug in question may be "irrelevant" for Debian, the real issue they're getting in a pissing match over is an obstinant maintainer of one of the most important pieces of software in any linux distro. Switching to a libc with a friendlier upstream maintainer over an irrelevant bug makes a hell of a lot more sense than waiting until it's a critically important bug that the current guy decides he won't fix for some stupid reason, now doesn't it?
Parent
Doesn't matter (Score:5, Insightful)
The problem is that programming a libc is the worst kind of programming... you have to be compatible with N different standards that are incompatible with each other. A lot of the functions you have to implement are impossible to simultaneously be correct and not make you puke (see printf). And on top of that, nobody even cares since they're all using some high-level library to call your libc functions anyway.
I really wish somebody would come out with a decent libc for linux though. With glibc, you either compile statically and have a 1+mb binary that's still dynamically linked anyway because you used a socket or your program just doesn't run on some systems and you have dll hell far worse than on any Windows. If you've ever had to deliver a non-OSS binary for linux you know what I'm talking about.
Dietlibc is the most convenient alternative by far, but it has several bugs, is slow, and errno is not threadsafe. For instance printf("%2d\n", 222) prints nothing. But if you test your software you can use it really easily, just CC="diet gcc". The uClibc is better, but it's a pita to use, requiring its own entire toolchain.
Since nobody actually pays for developers to work on libc, you end you with whoever crazy people will actually work on it. So while the fork is a good thing, it's probably just going to be more of the same.
Re:Doesn't matter (Score:5, Insightful)
Parent
Debian forks glibc, Drepper forks Debian (Score:5, Funny)
[To be posted [today.com] tomorrow, probably]
The Debian project has dropped the use of the GNU project's glibc C library, substituting the eglibc fork, as glibc maintainer Ulrich Drepper refused patches or bug reports for several architectures Debian relied on.
"Any change will negatively impact well designed architectures for the sole benefit of this embedded crap," said Drepper. "Famously good architectures like x86. Can you believe, these people wanted their C library to work in systems with shells other than bash! These people must think they're signing my pay check."
Drepper has, in retaliation, announced his own fork of Debian. It will be created in cooperation with Joerg Schilling and Tuomo Valkonen and be based on OpenSolaris with Ion running on XFree86 as the standard window manager. "Keith Packard ruined X," said Valkonen. The standard file system will be ext4, given its proven ability to cause data loss in user software the maintainers consider ill-written.
The project will be licensed under both the intersection and union of the GPL, LGPL, CDDL, MIT and the thing TuomoV wrote for Ion. This is not anticipated to be a problem in practice with real-life users, at least not until one exists.
"YOU!" said David Dawes of XFree86. "YOU'VE BEEN TALKING TO THEM, HAVEN'T YOU! YOU'RE CONSPIRING WITH THEM! THOSE GUYS! THEY STOLE IT ALL! THEY PUT A RADIO IN MY HEAD! LINUX/BSD WEENIES! I'LL SHOW 'EM! HELL YES!" "That means he's onside with us," said Valkonen. "Dave's been a bit terse since he finally lost it trying to fix his own broken modeline."
Don't be so Glib (Score:5, Insightful)
It might be "Egier" to use, but how far will it stray from the original project (that everyone else is currently using), or is it the first leak in the Dam before everyone jumps ship.
Its especially ironic given the push that netbooks have had over the past year, and the emphasis on Power savings that is pushing developers to consider using ARM chips, and by extension Linux (since Windows just plain won't run on them :) ).
If the OSS community doesn't support an opportunity to get our foot in the door (in a BIG way), by putting "our" OS on the "longest running and lightest" Netbooks/Notebooks that come out (or put our software out with known bugs), then we deserve to reap what we sow.
Parent
Re:At Least It's Egier to Use and Less Glib (Score:5, Funny)
Talk about "embedded crap". This ancient troll seems to be lodged between your ears!
Parent
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.
Parent
Re:At Least It's Egier to Use and Less Glib (Score:5, Funny)
I know! For the record, he was talking about the problems of the patch in aquatic environments. "It's working fine everywhere but this carp architectures."
I'm not surprised that the project's been forked after reading this bug [sourceware.org]. Not only was he wrong, but he was adamantly wrong. It was only when his employer (RedHat) stepped in that it looks like they solved the issue.
Parent
Re:At Least It's Egier to Use and Less Glib (Score:5, Funny)
I'm not surprised that the project's been forked after reading this bug. Not only was he wrong, but he was adamantly wrong.
Wow. Looks like he went to the Theo DeRaadt School of Social Graces.
Parent
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.
Parent
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.
Parent
Re:uClibc (Score:5, Insightful)
uClibc is created for embedded systems, meaning that it might lack some of the features that glibc has. Debian doesn't work only on embedded systems, and therefore it needs a full libc with all bells and whistles. eglibc is a glibc fork, which might be targetting embedded systems, but retains full source and binary compatibility with glibc, and I would assume that any useful feature would still be there, possibly optional.
And they switch not because they want lightweight libc, but because they want more friendly upstream. uClibc doesn't seem to be a good choice if that is the reason.
Parent
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.
Parent
Re:uClibc (Score:5, Funny)
Because uClibc brings us one step closer to Cthulhulibc.
That which lies dead but dreaming must not be awoken, especially on embedded devices.
Parent
Re:uClibc (Score:5, Funny)
Parent
Re:uClibc (Score:5, Funny)
That is not dead which can ACPI, and with strange ions charge is stored on Li.
Parent
Re:More context (Score:5, Insightful)
Looking elsewhere through the bug comments, it seems that there are assumptions in the glibc code that could break whenever the gcc people feel like it, even on x86. This was something that needed to be fixed, and isn't specific to x86 or any other non-embedded arch.
Also, when has x86 ever been a "well designed architecture"?
Parent
Re:More context (Score:5, Funny)
Seems pretty fishy to me.
Parent
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.
Parent
Re:GLIBC is the cause for all binary incompatibili (Score:5, Funny)
Sadly, nobody really gives a shit about Linux binary compatibility.
BSD does.
Parent
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)? :)
Parent
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.
Parent