Forgot your password?
typodupeerror
Debian Software Linux

Debian Switching From Glibc To Eglibc 565

Posted by timothy
from the dismissed-with-cause dept.
ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"
This discussion has been archived. No new comments can be posted.

Debian Switching From Glibc To Eglibc

Comments Filter:
  • by AvitarX (172628) <<gro.derdnuheniwydnarb> <ta> <em>> on Wednesday May 06, 2009 @05:19PM (#27851615) Journal

    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)

    by je ne sais quoi (987177) on Wednesday May 06, 2009 @05:21PM (#27851647)
    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've had my system totally screwed by glibc problems before, so badly that the only thing I could think of to do was to reinstall (it was while installing on a new machine, so it was okay). Whenever I see that glibc in the upgrade list for apt-get upgrade, I get a little queasy to this day though, along with upgrading the locales package.
  • FINALLY (Score:5, Interesting)

    by Anonymous Coward on Wednesday May 06, 2009 @05:21PM (#27851663)

    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)

      by David Gerard (12369) <slashdot@@@davidgerard...co...uk> on Wednesday May 06, 2009 @05:23PM (#27851699) Homepage
      Ulrich, TuomoV and Joerg Schilling.
    • Re: (Score:3, Insightful)

      by DaGoodBoy (8080)

      I'm sure the EGlibc and EGcs naming was not entirely coincidental.

    • Re:FINALLY (Score:4, Informative)

      by Anonymous Coward on Wednesday May 06, 2009 @05:39PM (#27851923)
      Sure he's a bit abrupt on the glibc dev list, but does any of that really interfere with his role as package maintainer?

      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)

        by Anonymous Coward on Wednesday May 06, 2009 @06:55PM (#27852789)

        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)

        by TheRaven64 (641858) on Wednesday May 06, 2009 @07:23PM (#27853077) Journal

        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)

        by xant (99438) on Wednesday May 06, 2009 @07:32PM (#27853185) Homepage

        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)

      by ThePhilips (752041) on Wednesday May 06, 2009 @06:25PM (#27852433) Homepage Journal

      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)

        by X0563511 (793323) on Wednesday May 06, 2009 @08:15PM (#27853663) Homepage Journal

        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)

          by Austerity Empowers (669817) on Thursday May 07, 2009 @12:43AM (#27855697)

          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.

    • by bconway (63464) on Wednesday May 06, 2009 @06:51PM (#27852719) Homepage

      From TFA: 1 [sourceware.org] 2 [sourceware.org] 3 [sourceware.org] 4 [sourceware.org]

    • Re:FINALLY (Score:4, Funny)

      by EveLibertine (847955) on Wednesday May 06, 2009 @08:26PM (#27853767)

      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.

  • by C0vardeAn0nim0 (232451) on Wednesday May 06, 2009 @05:29PM (#27851781) Journal

    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 ?

    • by TopSpin (753) * on Wednesday May 06, 2009 @07:07PM (#27852911) Journal

      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)

    by Rob Riggs (6418) on Wednesday May 06, 2009 @05:30PM (#27851795) Homepage Journal
    That quote in the story is way out of context. Ulrich's words were:

    Any change will negatively impact well designed architectures for the sole benefit of this embedded crap.

    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.

    • by Burkin (1534829) on Wednesday May 06, 2009 @05:43PM (#27851969)
      He claims random crap like that all the time when he refuses to fix bugs.
    • by Anonymous Coward on Wednesday May 06, 2009 @05:46PM (#27852003)

      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.

      • by shutdown -p now (807394) on Thursday May 07, 2009 @01:44AM (#27856017) Journal

        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.

    • by BSAtHome (455370) on Wednesday May 06, 2009 @05:53PM (#27852105)

      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)

      by jmorris42 (1458) * <jmorris@beauTOKYO.org minus city> on Wednesday May 06, 2009 @05:57PM (#27852155)

      > 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?

    • by Areyoukiddingme (1289470) on Wednesday May 06, 2009 @06:03PM (#27852213)

      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.

  • Yay! (Score:5, Interesting)

    by Omnifarious (11933) * <eric-slashNO@SPAMomnifarious.org> on Wednesday May 06, 2009 @05:36PM (#27851877) Homepage Journal

    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)

      by Estanislao Martínez (203477) on Wednesday May 06, 2009 @05:49PM (#27852053) Homepage

      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.

      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)

        by Omnifarious (11933) * <eric-slashNO@SPAMomnifarious.org> on Wednesday May 06, 2009 @06:16PM (#27852355) Homepage Journal

        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)

        by Blakey Rat (99501) on Wednesday May 06, 2009 @06:32PM (#27852521)

        The IBM implementation has to represent about 99.9% of all EBCDIC systems in existence. Ignoring it is just asinine.

  • by bzzfzz (1542813) on Wednesday May 06, 2009 @05:36PM (#27851881)
    Devices like MP3 players, set top boxes, and mobile phones account for far more GLIBC deployments than desktops and servers.
  • by pla (258480) on Wednesday May 06, 2009 @05:40PM (#27851939) Journal
    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.
    • by ArsonSmith (13997) on Wednesday May 06, 2009 @06:04PM (#27852223) Journal

      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.

    • by Chris Burke (6130) on Wednesday May 06, 2009 @06:10PM (#27852283) Homepage

      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?

      • by dbIII (701233) on Wednesday May 06, 2009 @09:15PM (#27854213)
        It was just somebody lost and reporting a bug in the wrong place - pissing off the maintainer a little bit and resulting in a three line reply with an insulting middle line. Now we only get to see the insult without the suggestion of putting the code where it belongs.
        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.
  • by John Goerzen (2781) on Wednesday May 06, 2009 @05:51PM (#27852081) Homepage

    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.

  • by pathological liar (659969) on Wednesday May 06, 2009 @05:52PM (#27852087)

    From eglibc's mission statement [eglibc.org]:

    "Retain API and ABI compatability with GLIBC wherever feasible."

    Yeah, that's going to end well...

  • by erroneus (253617) on Wednesday May 06, 2009 @05:54PM (#27852123) Homepage

    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.

  • by GreatBunzinni (642500) on Wednesday May 06, 2009 @06:01PM (#27852177)

    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:

    • Stop reopening bugs. Search the web if you want an explanation, I don't have
      anything handy and certainly have no interest in writing it up.
    • Strange, I never saw your name on my paycheck. Since if that's not the case you
      cannot order me around.
    • Stop reopening the bug. If you want explanations pay somebody.
    • Dammit, stop opening the bug. It is obvious that you know *NOTHING* about the
      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.
    • Stop reopening the bug. And this is also no discussion forum. Go somewhere else.
    • Stop commenting.
    • Idiot. There is no bug. Don't reopen.
    • Fine. Whatever. I'll revert it, assholes.

    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.

    • by elevator (117768) on Wednesday May 06, 2009 @06:30PM (#27852489) Homepage

      • Fine. Whatever. I'll revert it, assholes.

      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)? :)

    • by Anonymous Coward on Wednesday May 06, 2009 @06:39PM (#27852577)

      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!

      • by lgw (121541) on Wednesday May 06, 2009 @08:01PM (#27853531) Journal

        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!

      • by GreatBunzinni (642500) on Thursday May 07, 2009 @05:58AM (#27857307)

        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.

    • by abigor (540274) on Wednesday May 06, 2009 @06:59PM (#27852833)

      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.

  • Doesn't matter (Score:5, Insightful)

    by 0xABADC0DA (867955) on Wednesday May 06, 2009 @06:02PM (#27852197)

    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.

  • [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)

    by that_itch_kid (1155313) on Wednesday May 06, 2009 @08:52PM (#27854025)

    Can we PLEASE get the moderation confirm button back!?!?!?!

  • Yay! (Score:4, Informative)

    by seebs (15766) on Thursday May 07, 2009 @12:04AM (#27855473) Homepage

    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.)

TRANSACTION CANCELLED - FARECARD RETURNED

Working...