Slashdot Mirror
Debian Switching From Glibc To Eglibc
ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"
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.
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.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
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.
I'm sure the EGlibc and EGcs naming was not entirely coincidental.
My God! It's full of Voids!
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.'
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.
The thing about a vocal constituency in OSS is they can do what you wont and then replace you......
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".
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?
Are you adequate?
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.
From eglibc's mission statement:
"Retain API and ABI compatability with GLIBC wherever feasible."
Yeah, that's going to end well...
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.
> 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?
Democrat delenda est
But that would actually involve Ulrich actually admitting that he's ever been wrong.
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.
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.
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"?
Not a typewriter
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.
All hope abandon ye who enter here.
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!
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.
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.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
There's a big difference between Drepper and TdR: Theo is usually actually right when he's being an asshole. Drepper has no such excuse.
I am TheRaven on Soylent News
I just wrote this post 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.
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.
Gentlemen! You can't fight in here, this is the war room!
Since he never explained the rational for the "fix," and instead preferred to spam "Do not reopen this, this is not a bug," instead, I would say he is not. A bug comment discussion like that would get me reprimanded or fired.
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!
Socialism: a lie told by totalitarians and believed by fools.
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.
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.
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).
The enemies of Democracy are
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.
Can we PLEASE get the moderation confirm button back!?!?!?!
That's quite a read, you have to go out of your way to get multiple people writing comments like this one:
:D"
"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).
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.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Performing the necessary configuration management, code review, and regression testing -- for a patch is non-trivial in any responsbily-maintained project.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
An explanation like yours would go miles ahead of ulrich's. The guy is an asshole
-- dnl
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.
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.
... 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.
I am the lawn!
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.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
While funny, when was Theo wrong exactly?
- Michael T. Babcock (Yes, I blog)
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.
*sigh* back to work...