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:At Least It's Egier to Use and Less Glib (Score:0, Insightful)
Linux just isn't ready for the desktop yet. It may be ready for the web servers that you nerds use to distribute your TRON fanzines and personal Dungeons and Dragons web-sights across the world wide web, but the average computer user isn't going to spend months learning how to use a CLI and then hours compiling packages so that they can get a workable graphic interface to check their mail with, especially not when they already have a Windows machine that does its job perfectly well and is backed by a major corporation, as opposed to Linux which is only supported by a few unemployed nerds living in their mother's basement somewhere. The last thing I want is a level 5 dwarf (haha) providing me my OS.
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: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:FINALLY (Score:3, Insightful)
I'm sure the EGlibc and EGcs naming was not entirely coincidental.
"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:For the greater good (Score:2, Insightful)
The thing about a vocal constituency in OSS is they can do what you wont and then replace you......
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: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?
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...
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.
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:For the greater good (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: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: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:"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: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: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:Doesn't matter (Score:5, Insightful)
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.
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:The problem isn't GLIBC. It's Ulrich Drepper. (Score:3, Insightful)
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:Might be a good idea (Score:3, Insightful)
It was actually during a dist-upgrade, but from sarge to etch (kde was hugely out of date for an end user). In my defense though, why should my system get so hosed while trying to do that? I thought the entire point of having a package manager was to make those kinds of things seamless. glibc is the only package that hosed my whole system doing that. Even having problems with locales required me to revert and just reinstall some things. I think that having a package maintainer who is more open to fixing bugs in existing releases (such as is shown in some of those bug reports that people have listed here) would make life much easier for transitioning and make it more flexible about which packages depend on it. This is especially important for such a low level package like glibc. But hey, what do I know.
Re:No - it's people who don't read. (Score:4, Insightful)
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!
As far as possible! (Score:3, Insightful)
Hopefully it'll stray as far as possible, given that the original project seems to have serious attitude issues with accepting their bugs and simply applying supplied patches! I know little about GLIBC internals, but even I can see how crack-happy the maintainers seem to be, and could probably do a better job myself. All I can say is thank god this is being forked away from those nut-jobs, and hopefully everyone else WILL jump ship too.
Re:At Least It's Egier to Use and Less Glib (Score:3, Insightful)
I was actually surprised anyone even objected, and to object in such a poor way. Agreeing or disagreeing with someone else's ABI is irrelevant. If we all want to go back to the days of assuming only a single OS and single CPU exists, and that portability just gets in the way of true genius, we can always use Windows.
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:A rant (Score:3, Insightful)
I just updated to the new Ubuntu, and now my SATA controller doesn't work. It corrupted a partition before I figured it out and put in an PCI card to handle my drives.
Unfortunately, now my drives are juggling around. /dev/sda one boot, /dev/sdb another boot!
Bless the new code. Who cares about backwards compatibility?
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.
FUCK (Score:4, Insightful)
Can we PLEASE get the moderation confirm button back!?!?!?!
Re:"So what" vs "Wow, unbelievable" (Score:3, Insightful)
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.
Honest question, why should the glibc maintainer be concerned with which market Linux is strong in, or what direction it takes, or if there even is a Linux tomorrow? This seems to happen a often now, long time free software developers are basically ostracized for not putting Linux at the center of the universe or supporting its cause - whatever that is, and it most certainly is separate from GNU's goals. I'm not suggesting this particular problem is specific to Linux, you did that. In general though, this seems to be the case.
It also kind of makes you wonder if the OSS crowd realized that openness does not excuse you from the politics of dealing with throngs of people and instead exposes you to more of it.
Go ahead.. what if everyone, and I mean EVERYONE used OSS (more to the point, YOUR) software? Would testing requirements change? How would developers start responding to millions of user complaints vs. thousands? Could individuals realistically contribute in that environment with the higher testing costs (in time & resources)? The "don't like it, fork/write it yourself" model doesn't scale. The only way I can imagine it is if OSS development eventually evolves into a corporate-like hierarchy where responsibility and ownership trickle downward through multiple layers. We've already figured that out though.... *ahem* commercial software *cough* and people say that model isn't really open, even when it is.. OpenOffice, OpenSolaris, any OSS project with commercial backing pretty much. Maybe non-profit OSS organizations are the answer to this. They'd face the obvious problem of reminding everyone that free != free or find some other method of funding. Ugh, OSS really digs itself a hole leading people to think free == free. Good luck with that.
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: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.
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:No, Ulrich Drepper's response was appropriate (Score:4, Insightful)
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: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.
Re:At Least It's Egier to Use and Less Glib (Score:3, Insightful)
... in Drepper's words it was 'for the sole benefit of this embedded crap.'"
Aurelien Jarno has just uploaded a fork of glibc called eglibc...
I love FOSS.
Re:Don't be so Glib (Score:5, Insightful)
Re:Don't be so Glib (Score:3, Insightful)
By contrast virtually all of a standard Linux desktop will compile to ARM. You might be missing some important pieces like Flash player, Sun Java and some other stuff, but the core experience would all be there. You'd get Firefox, OpenOffice, media players and everything else, subject to the system's other limitations such as memory & disk footprint.
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:Don't be so Glib (Score:3, 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.
Re:A rant (Score:3, Insightful)
Documen-what? Use the source Luke. This is big part why I love open source. Source is the ultimate documentation. I can read how anything I fancy works! Documentation is always going to have problems keeping up with the source.
Opinions like this kill good projects. Document your damn code.
Re:At Least It's Egier to Use and Less Glib (Score:3, Insightful)
While funny, when was Theo wrong exactly?
Re:"So what" vs "Wow, unbelievable" (Score:3, Insightful)
You must not know much, if anything, about Debian.
God, I love this. Anyone (and I mean anyone) who is in any way remotely critical of Debian, gets this response immediately fired at them from the cheerleading squad.
Kudos on the compelling argument there, Slick. Totally airtight, and utterly unassailable rhetoric. ;)
Can someone explain his good points? (Score:3, Insightful)
I'm seeing lots of comments about how horrible a maintainer he is...but somehow he's still the maintainer. I have to assume that he's actually good at something or else he would have already been replaced.
Can anyone give some insight on what qualities he has that explain how he has managed to keep the position as glibc maintainer?
I'm just trying to see the other side of the picture here.
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:A rant (Score:3, Insightful)
End users need docs too.