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.'"
At Least It's Egier to Use and Less Glib (Score:4, Funny)
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.
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:Don't be so Glib (Score:5, Insightful)
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:Don't be so Glib (Score:4, Insightful)
But, umm, he's right. He may have been abrupt in the way he phrased his initial response, but his reasoning is not at fault.
No, he's not. The entire point of not using assembler is to have the language do convenient stuff for you. What's more efficient, reasonable, and secure: implementing those nice functions well in one standardized library, or forcing each programmer to re-implement them - probably poorly?
memcpy for string manipulation, my ass. I thought we'd moved past that.
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!
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:At Least It's Egier to Use and Less Glib (Score:4, Interesting)
Mod parent up, as the above are Drepper's words with a bit more context. Nothing like stirring up the pot a bit with sensational headlines.
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.
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.
Re:At Least It's Egier to Use and Less Glib (Score:5, Insightful)
"Wow, you are a bastard. I hope you die alone.
How do people with an attitude like Drepper's become maintainers of crucial projects? He seems obviously unsuitable (whether he has superb technical skills or not).
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: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!
That bug report was well worth a read (Score:4, Funny)
Re:At Least It's Egier to Use and Less Glib (Score:5, Informative)
Re:At Least It's Egier to Use and Less Glib (Score:5, Insightful)
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.
Really? Since that's a single cache line in either case, the difference is actually going to be more like maybe a dozen nanoseconds on a modern x86 (when it was going to take around 100ns in the base case assuming a cold cache miss).
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.
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".
Re:Might be a good idea (Score:5, Informative)
Re:Might be a good idea (Score:5, Informative)
It's horribly inefficient BSD crap. Get your Drepper quotes right! [redhat.com]
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:Might be a good idea (Score:5, Insightful)
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!
Then we need fewer typical geeks, and more atypical geeks.
Re:Might be a good idea (Score:5, Insightful)
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!
Then we need fewer typical geeks, and more atypical geeks.
Indeed. For the record, I don't think he is a typical geek. But if that's your definition of typical geek, then the typical geek is an asshole.
Re:Might be a good idea (Score:5, Insightful)
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.
Sorry, being unnecessarily offensive and combative is the very definition of an asshole. The term fits.
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)
Re:FINALLY (Score:5, Funny)
Hans Reiser death match... Ahhh shit, probably still too soon for that one.
Re: (Score:3, Insightful)
I'm sure the EGlibc and EGcs naming was not entirely coincidental.
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: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: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.
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.
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.
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]
Re:FINALLY (Score:4, Insightful)
This proves he understands computer architecture, particularly for the x86 and knows how to write code that works very well on his targeted hardware. A lot of people do, particularly in hardware development, firmware and (get ready) embedded development. Not everyone, I'm sure he gets lots of crappy patches.
That doesn't qualify him to lead anything, nor does it excuse the attitude. If he wants to pull off the Asperger's thing and obsess over every lost access cycle, he should do it as a code contributor while a more dynamic personality handles the project leadership.
Put another way, any program can be optimized down to nothing if you throw out all the requirements. He doesn't seem to balance the two very well, nor does he want to share his insight with others as to why he makes arbitrary decisions.
Some of Ulrich Drepper's finer points (Score:5, Interesting)
From TFA: 1 [sourceware.org] 2 [sourceware.org] 3 [sourceware.org] 4 [sourceware.org]
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.
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:No, Ulrich Drepper's response was appropriate (Score:4, Insightful)
Re:No, Ulrich Drepper's response was appropriate (Score:4, Insightful)
Performing the necessary configuration management, code review, and regression testing -- for a patch is non-trivial in any responsbily-maintained project.
Re:Some of Ulrich Drepper's finer points (Score:5, Insightful)
I just wrote this post [slashdot.org] defending Drepper, but now I take it all back. It's perfectly reasonable to expect a maintainer to explain his actions. Responding with "you don't write my paycheck" makes him an asshole, pure and simple.
It occurs to me that Redhat does pay Drepper's salary. I assume that he gets to maintain glibc because they're donating his time? I'm sure they know, even if he doesn't, that donating resources to an open source project does not give them ownership of said project. If I were one of these frustrated developers who's tired of Drepper's BS, I'd find out how his boss is and have a word.
Re:Some of Ulrich Drepper's finer points (Score:5, Funny)
Responding with "you don't write my paycheck" makes him an asshole, pure and simple.
Yep, and the comment "Paid $1 via Paypal. Please fix" was my favorite response!
Re:FINALLY (Score:4, Funny)
He has pissed off practically everybody in the FOSS world at least once.
Good riddance.
Because the FOSS world is full of well balanced individuals who would never get unreasonably pissed off at the drop of a hat.
Re:FINALLY (Score:5, Interesting)
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 ?
Re:downstream from debian (Score:4, Interesting)
a repeat of the whole xfree86/x.org thing ?
A repeat of that, and also a repeat of the GCC/EGCS fork. This isn't the first major fork in FOSS history and it won't be the last. Both the Xfree86/Xorg and GCC/EGCS forks resulted in improvements to the progress and maintenance of these systems/tools.
Perhaps another glibc fork is overdue. Remember that the GNU C library that Ulrich is paid by Redhat to maintain was, for a long time, forked by Linux kernel developers. Consider also that there are already at least 5 alternative C library implementations (Bionic, dietlibc, uClibc, Newlib, Klibc) for Linux, all revolving around the embedded use case. Is it any wonder this fork pre-appends E for embedded as a name? Embedded Linux is absolutely crucial to the future of Linux generally; Linux has its foot in the door of many institutions because it's easy to embed.
There is no actual technical reason (including performance regressions) a C library implementation need be exlusively 'embedded' or not. It certainly makes development more difficult as more conditions appear in the source and the build system gets more complex. C library developers/maintainers should be capable of dealing with that degree of complexity. Lightweights need not apply.
By its nature a C library must contend with so many architectures and use cases that no one developer can possibly encompass all the required knowledge. Perhaps having a prima donna like Ulrich play gate keeper is not optimal.
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)
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: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: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.
Re:For the greater good (Score:4, Insightful)
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?
Re:A rant (Score:4, Interesting)
> Drepper never suggested not to fix a bug for the ARM architecture....
Couldn't be bothered to read the linked bug discussion could you. Beyond rejecting a fix for an actual problem he even went so far as to say "No, Arm is not supported." Which was of course news to a lot of folks, since Debian has been shipping an official ARM port for years. If glibc isn't accepting patches for platforms Debian is officially supporting it is totally understandable they would adopt a fork that does.
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.
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.
Re:For the greater good (Score:4, Interesting)
>> He's not fit to write C.
> Which is probably why glibc source code looks like preprocessor soup.
Glib looks like preprocessor soup because it has to be portable and fast. The only sane way to avoid using the preprocessor is to move the logic into the C code. This usually results in better readability, but destroys performance. The insane way would be to duplicate code, which has a disastrous impact on maintainability.
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:4, Insightful)
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?
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:Yay! (Score:5, Informative)
The IBM implementation has to represent about 99.9% of all EBCDIC systems in existence. Ignoring it is just asinine.
I make a living on this embedded crap (Score:5, Informative)
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.
"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.
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?
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:"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.
Not Just for embedded devices (Score:4, Insightful)
I think there is some shallow reading going on here.
eglibc has a number of features that are useful in general. It happens that embedded systems have a strong need for these features, but they are generally useful as well. I've discussed it with one of the Debian glibc maintainers, and he said that eglibc is basically a patchset atop glibc implementing new features and fixing bugs. I think of it similar to the relationship between go-oo.org and OpenOffice. Distributions have to fix these bugs anyway, because upstream won't. So why not adopt a standard patchset to do so collectively?
This has no implications for a change of focus away from the desktop or anything like that.
API/ABI compatibility? (Score:4, Insightful)
From eglibc's mission statement [eglibc.org]:
"Retain API and ABI compatability with GLIBC wherever feasible."
Yeah, that's going to end well...
What an ugly situation (Score:4, Interesting)
I recall the brief and mild concern over the push to change from XFree86 to X.org. The reasons for doing so were pretty clear and obvious and most people (except for the XFree86 people themselves) that it was simply necessary as the needs of the community outgrew XFree86's visual range. In short, the people wanted more than XFree86 could collectively deliver. (XFree86 people? You were such dumbasses... what better way to show how useless you could be?)
But this story is different. Now we have a maintainer who doesn't believe in what the people and the market are interested in doing -- moving Linux into smaller and smaller devices. "Embedded crap?" Indeed! The future of computing is not more powerful single boxes, but smaller networked devices that work together and the operating system will eventually become less relevant if not entirely irrelevant. This "embedded crap" is where all devices are headed. Many popular consumer gadgets and some really high-end consumer gadgets are already utilizing embedded Linux as the means of making some really cool things happen. The community will not stand for one or a few pig-headed people to impede that.
Either GLibc needs to pull his head out of his ass or he will make himself and his project irrelevant. Worse, if your name and reputation were to be muddied because your project was killed off by the community because "you don't want to work and play well with others" then the odds of people wanting to work with you socially or professionally in the future are greatly reduced and your technical skills, wisdom and experience will have been wasted.
Would it surprise anyone to know that many ice cream sellers only like one or two flavors? Why, then, do they sell so many other kinds?! The reason is obvious.
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: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:The problem isn't GLIBC. It's Ulrich Drepper. (Score:4, Insightful)
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.
Have you ever delt with glibc development, or do you base this on reading a single bug?
One thing Ulrich Drepper is NOT is incompetent. He is extremely competent, and if you boot Linux you're running a ton of his code. In fact, he is so competent he has keep maintainership for years despite his finely tuned confrontational style where he seems to know *exactly* the response to write that will create the worst reaction in whoever he is responding to. I know, it has happened to me, but luckily I'm out of that game for now. If I was still dealing with it day-to-day, like Debian glibc maintainers, it would drive me nuts too.
The other thing to consider is that glibc, being the base of pretty much everything else, can be like a candle to a moth attracting people who really, truely have no idea. This can become tiresome, and may explain why some of the elitism comes about. You don't want the real development lists turning into a Ubuntu newbie user forum.
I wish eglibc well!
Re:The problem isn't GLIBC. It's Ulrich Drepper. (Score:5, Insightful)
One thing Ulrich Drepper is NOT is incompetent.
If you're job is to lead a development effort, people skills are more important than technical skill. Being an asshole makes you incompetant. If you just want to be some asshole writing good code in the corner, you can do that, but that isn't waht makes a good project leader!
Re:The problem isn't GLIBC. It's Ulrich Drepper. (Score:5, Insightful)
Have you ever delt with glibc development, or do you base this on reading a single bug?
I believe it is easy to understand that if this problem was limited to a single uncivilized reaction towards a single clueless user on a single bug report no one would ever seriously ponder the possibility of forking such a complex project.
One thing Ulrich Drepper is NOT is incompetent. He is extremely competent, and if you boot Linux you're running a ton of his code. In fact, he is so competent he has keep maintainership for years despite his finely tuned confrontational style where he seems to know *exactly* the response to write that will create the worst reaction in whoever he is responding to.
He is incompetent due to the very nature of his job. He is paid not only to write code but also to interact with all glibc users who may wish to contact the project due to any issue related to that particular software project. If his job involved being locked in a basement somewhere away from all traces of humanity where he would code to his heart's content without having any contact without the outside world then there wouldn't be any problem. But that isn't his job. He also needs to interact with users, communicate with them, listen to what they have to say and handle cases where a party in that interaction is wrong in order to get a positive outcome. Moreover, due to the very nature of his job he is also assumes the responsibility of being a sort of public figure of that project responsible for public relations and the project's image.
Due to that, if someone in that position happens to be an antisocial moron who can't help being a dick... That person will end up making the project look bad and suffer the consequences that his own moronic actions cause. That's what makes him incompetent. Due to the nature of this project, being an antisocial moron makes you unfit to be in that position, as much as being a great PR person without any noticeable programming skills would also make that project suffer, although in different ways.
I know, it has happened to me, but luckily I'm out of that game for now. If I was still dealing with it day-to-day, like Debian glibc maintainers, it would drive me nuts too.
If a company pays someone to work in a project and his antisocial behaviour leads the company's clients to not only run away but also start off a competing project, would that employee still be considered competent? He would be fired on the spot. That's what is happening with 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:No - it's people who don't read. (Score:4, Insightful)
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)
Re:Doesn't matter (Score:4, Interesting)
Ha! That's a great idea in principle, though I don't know how I would feel about there being a /compat dir containing glibc on Linux, you know it would be needed. It also would be a lot of work to get apps and libs that have workarounds or have come to expect (even without knowing it) glibc-isms to be fixed. The other thing is that there are lots of programs that rely on glibc internals to link. They would need a recompile. Then there are those programs that actually use glibc internals, and there are more of those than you think. For a while there that was the only way to really get internationalization to work right with glibc.
In any case I think the Debian folks use a BSD libc in some ports and there was a some work on BSD libc in Gentoo. That all sort of came to the problems I outlined above when trying to use BSD libc on i386.
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."
FUCK (Score:4, Insightful)
Can we PLEASE get the moderation confirm button back!?!?!?!
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: (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, 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.
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.
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.
Re:uClibc (Score:5, Funny)
Re:uClibc (Score:5, Funny)
That is not dead which can ACPI, and with strange ions charge is stored on Li.
Re:Anonymous Coward (Score:4, Funny)
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"?
Re:More context (Score:5, Funny)
Seems pretty fishy to me.
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:GLIBC is the cause for all binary incompatibili (Score:5, Funny)
Sadly, nobody really gives a shit about Linux binary compatibility.
BSD does.