Slashdot Mirror

← Back to Stories (view on slashdot.org)

Glibc Steering Committee Dissolves; Switches To Co-Operative Development Model

Posted by timothy on from the part-of-an-autonomous-collective dept.

First time accepted submitter bheading writes "Following years under controversial leadership which, among other things, led to a fork (which was in turn adopted by some of the major distributions) the glibc development process has been reinvented to follow a slightly more informal, community-based model. Here's hoping glibc benefits from a welcome dose of pragmatism."

68 of 102 comments (clear)

  1. Summary by TheRaven64 · · Score: 4, Interesting

    The pissing match between RMS and Drepper that resulted in the steering committee is no longer longer relevant now Drepper has gone to work at Goldman Sachs (something that makes me smile: I can't think of any other company more deserving of him).

    --
    I am TheRaven on Soylent News
    1. Re:Summary by TrekkieGod · · Score: 5, Insightful

      Ahahaha, really? That's hilarious. Damn, I remember Drepper. I was told "he's quite nice in person", but you'd never know it from how he acted over email.

      Heh...I read through the summary and thought, "actually, we could do with less pragmatism and more with just doing what is right regardless of what the people keep requesting. Design by committee is the path to bloat. Then I clicked the links and saw this comment by Drepper in response to a bug report on arm:

      It's working fine everywhere but this carp architectures. I'm not going to make the code perform worse just because of Arm. Providing your own copy of that file if you care.

      That's not lack of pragmatism, that's lack of professionalism. In fact, this is a good time to point out that "nice in person" is code for "asshole, but too much of a coward to behave like one if the other person is within punching distance."

      --

      Warning: Opinions known to be heavily biased.

    2. Re:Summary by Anonymous Coward · · Score: 1

      now Drepper has gone to work at Goldman Sachs

      I wonder if he refers to gcc users as "muppets".

    3. Re:Summary by bheading · · Score: 4, Interesting

      When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player. It is worth contrasting the attitude of Linus Torvalds in that thread with that of the glibc maintainers. I think most reasonable people would agree there is a trade off between supporting broken applications and ensuring things are done right. In this case, it would have cost glibc nothing to make a minor concession.

    4. Re:Summary by TheLink · · Score: 2

      They can't provide very good reasons to copy stuff backwards, yet they insist on doing it and it breaks stuff.

      For similar stupid problems (and responses) sometimes I get the impression that the Linux Desktop bunch are actually sabotaging Desktop Linux.

      --
    5. Re:Summary by Just+Some+Guy · · Score: 1

      When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player.

      That's OK. It's dead anyway.

      --
      Dewey, what part of this looks like authorities should be involved?
    6. Re:Summary by iluvcapra · · Score: 4, Funny

      Linux Desktop bunch are actually sabotaging Desktop Linux

      Is that like the People's Front of Judea and the Judean People's Front?

      --
      Don't blame me, I voted for Baltar.
    7. Re:Summary by mrmeval · · Score: 1

      I'll wait and see. It appears they've shed themselves of the more poisonous members but that announcement is just a pile of words that past acts do not support.

      I'd prefer to have seen glibc die and eglibc take over. It is a more vibrant effort and has embraced embedded devices.

      --
      I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
    8. Re:Summary by TrekkieGod · · Score: 4, Insightful

      When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player. It is worth contrasting the attitude of Linus Torvalds in that thread with that of the glibc maintainers. I think most reasonable people would agree there is a trade off between supporting broken applications and ensuring things are done right. In this case, it would have cost glibc nothing to make a minor concession.

      I understand your point, that it doesn't break anything else to make the concession. That said, this is exactly what I mean by "we need less pragmatism." The way I see it, overlapping memcpy is a bug, so that's what needed to be fixed. You code according to an API, and the moment that applications start depending on how you implement that API internally, you're asking for trouble. Pragmatically, you'd get flash working, but I'd actually be in favor of leaving the backwards copy in there even if it serves no other purpose than to expose bugs in people's code using your library.

      I think doing things the right way is more important than getting things working for now, because it prevents things from breaking in the future. More long term planning and less short-term concessions is the way to go. That said, "this doesn't work at all on arm" problem was an actual bug on glibc's side. If he thinks the new way of doing things hurts performance in other architectures, then he can provide the different code paths with optimizations if he cares to do so.

      --

      Warning: Opinions known to be heavily biased.

    9. Re:Summary by gnasher719 · · Score: 1

      So there is a serious bug in Adobe's Flash. An incorrect call to memcpy (not malloc). In my experience, at least 80% of all crashes and hangs on my Mac are due to Adobe Flash, so I'm not surprised.

      iOS lives quite happily without Flash. Mac users live either quite happily without Flash, or they live quite happily with Flash crashing sometimes.

      Alternative history of Apple: Apple engineer speeds up memcpy implementation. Does some serious application testing for compatibility. Talks to Steve Jobs. "So what have you been working on?" "I made the C library a few percent faster, which benefits all users. It makes Adobe Flash crash". Steve Jobs: Dies laughing.

    10. Re:Summary by bheading · · Score: 1

      I hope I'm not being too pedantic, but if your OS is crashing or hanging due to Adobe Flash or any other user space application, then your OS is broken. Memory protection is not new.

    11. Re:Summary by bheading · · Score: 1

      I'm sympathetic to the idea of leaving a change in place because it renders subtle bugs in crappy code visible, but to an end user it looks like your change broke his web browser for no reason. If the reverse memcpy (not malloc, thanks gnasher719) was faster it would make sense, but Torvalds' testing showed that it appeared to be slower.

    12. Re:Summary by Anonymous Coward · · Score: 2, Insightful

      I understand your point, that it doesn't break anything else to make the concession. That said, this is exactly what I mean by "we need less pragmatism." The way I see it, overlapping memcpy is a bug, so that's what needed to be fixed. You code according to an API, and the moment that applications start depending on how you implement that API internally, you're asking for trouble. Pragmatically, you'd get flash working, but I'd actually be in favor of leaving the backwards copy in there even if it serves no other purpose than to expose bugs in people's code using your library.

      Sometimes there is a point to that type of thinking. This is not one of those times.

      The original definition of memcpy() defined overlapping copies as "undefined" behavior not for any good API design reason which would stand the test of time (it's usually a bad idea for APIs to permit inputs which cause "undefined" behavior without returning an error code or throwing an exception or whatever), but rather because it made the implementation smaller.

      That's because memcpy() is literally from the dawn of the C Standard Library, when the Bell Labs hackers were trying to squeeze as much functionality as they could into machines which look pathetically small by today's standards. Sometimes they went a little too far down the minimalism path. This was one of those times. Today, there is no legitimate reason to have that gotcha hiding in memcpy. It doesn't save enough space and it doesn't save enough time.

      I think doing things the right way is more important than getting things working for now, because it prevents things from breaking in the future. More long term planning and less short-term concessions is the way to go.

      At this point, the long term planning is in favor of just aliasing memcpy() to memmove(). The definition of memcpy() where it has "undefined" behavior for overlapping regions was one of those short term concessions to reality, ~40 years ago. We can move on. It won't hurt, promise. ;)

    13. Re:Summary by shutdown+-p+now · · Score: 1

      Ironically, it seems that this problem was the last straw for Linus to switch from Fedora to Linux Mint.

    14. Re:Summary by shutdown+-p+now · · Score: 1

      I understand your point, that it doesn't break anything else to make the concession. That said, this is exactly what I mean by "we need less pragmatism." The way I see it, overlapping memcpy is a bug, so that's what needed to be fixed. You code according to an API, and the moment that applications start depending on how you implement that API internally, you're asking for trouble. Pragmatically, you'd get flash working, but I'd actually be in favor of leaving the backwards copy in there even if it serves no other purpose than to expose bugs in people's code using your library.

      If you read all Linus' comments in that bug, he actually covers that angle. He says that either the thing should "just work", or else it should make it really clear that it's broken when inappropriately used. And that's the problem with backwards copy - it doesn't fast-fail the process or anything like that, it just produces garbage output. If you're lucky, this might crash. If you're less lucky, this might output garbage to the user (as in this case), with no easy way to diagnose it. If you're particularly unlucky, it may actually output some private information (say, a password?), or be otherwise exploitable.

    15. Re:Summary by TrekkieGod · · Score: 1

      I'm sympathetic to the idea of leaving a change in place because it renders subtle bugs in crappy code visible, but to an end user it looks like your change broke his web browser for no reason.

      I think we're on the same page here. I think the way to go here, when you have a clash between high profile software such as flash and glibc would have been for the glibc developers to get in touch with adobe and explain, "look, you have a bug in your software, how long will it take you to release a fix? If you give us an estimate, we can revert our changes to get you working again for now, but be aware that we will change it again at the end of the agreed-upon time period, so you really need to have a fix on your side.

      If the reverse memcpy (not malloc, thanks gnasher719) was faster it would make sense, but Torvalds' testing showed that it appeared to be slower.

      And that's a good reason not to not do the reverse memcpy, I agree. All I'm saying is that I'm weary of compromises that allows bad code to survive just to keep things running. I think that it works great in the short term, and gets your users happy that things are working again, but it just makes it more likely to break something else in the future as you make unrelated changes in the code. If the library user depends on implementation details instead of the API contract, you can inadvertently break him with routine maintenance. The end user certainly doesn't appreciate software that breaks with every six-month update. Like I said above, I would not be against a temporary compromise, as long as the actual bug gets fixed instead of grandfathered in.

      --

      Warning: Opinions known to be heavily biased.

    16. Re:Summary by TrekkieGod · · Score: 1

      If you read all Linus' comments in that bug, he actually covers that angle. He says that either the thing should "just work", or else it should make it really clear that it's broken when inappropriately used. And that's the problem with backwards copy - it doesn't fast-fail the process or anything like that, it just produces garbage output. If you're lucky, this might crash. If you're less lucky, this might output garbage to the user (as in this case), with no easy way to diagnose it. If you're particularly unlucky, it may actually output some private information (say, a password?), or be otherwise exploitable.

      That's sound software development advice, I don't disagree with it. I'm not defending reverse memcpy, I'm merely saying that "flash doesn't work when we implement memcpy like this" isn't a good enough reason to change the implementation if the bug is on the flash side. There were other good reasons to do the copy forward pointed out in that thread, and I'm ok with that, but that's the difference between writing good code and being "practical" about it, ie, grandfathering in bad code just to make things work short-term.

      --

      Warning: Opinions known to be heavily biased.

    17. Re:Summary by Guy+Harris · · Score: 1

      When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player.

      Presumably you meant memcpy(), not malloc(). Somebody at Adobe needs a gentle reminder ("gentle" because I can't say for certain that I always remember that memcpy() is explicitly allowed not to properly copy between overlapping memory regions - "properly" meaning "as if the source region were copied to a temporary buffer and then the temporary buffer were copied to the destination region" - but memmove() is explicitly required to do so) that this is a job for memmove() Man.

      So the question is whether the reasons for doing the backwards copy, as mentioned in the cited bug report and items to which it links, are sufficient to justify exposing the bugs in buggy programs such as the Flash player. If the performance benefits aren't large, perhaps they aren't.

    18. Re:Summary by Guy+Harris · · Score: 1

      So the question is whether the reasons for doing the backwards copy, as mentioned in the cited bug report and items to which it links, are sufficient to justify exposing the bugs in buggy programs such as the Flash player. If the performance benefits aren't large, perhaps they aren't.

      ...especially if the bugs in question are security bugs. If it turns out that it's too easy for people to use memcpy() when they should be using memmove(), perhaps there are technically good reasons not to have separated them, as long as "technically" includes "psychologically" as well as "computer hardware and software-wise", given that much of the computer software that would use memcpy() and/or memmove() is, for better or worse, written by human beings.

    19. Re:Summary by Guy+Harris · · Score: 2

      That's sound software development advice, I don't disagree with it. I'm not defending reverse memcpy, I'm merely saying that "flash doesn't work when we implement memcpy like this" isn't a good enough reason to change the implementation if the bug is on the flash side.

      How about "Flash and some other programs in Fedora don't work correctly when we implement memcpy() like this, and some of them might "not work correctly" in ways that are security holes, and we currently have no tools to reliably analyze C code to catch incorrect use of memcpy(), and the failure modes are not always obvious, so it might be quite a long time before all the code out there is fixed?

      No, people shouldn't use memcpy() in calls where the source and destination regions overlap, but if it's going to be a long time before those are all fixed, and if the failure modes can be insufficiently obvious that the bugs might not even be discovered before they do damage, this might be like {warning, car analogy ahead!} going through a traffic intersection with a 2-way stop, on the street without the stop signs, without slowing down and checking for oncoming traffic on the other street, because people shouldn't go through stop signs.

      Here lies the body of Jonathan Day,
      who died defending his right of way.
      He was right, dead right, as he sped along,
      but he's just as dead as if he'd been wrong.

      I think the key here is that the punishment for violating the C standard isn't that your program fails in an obvious fashion, it fails in a somewhat random fashion. If memcpy() would check for an overlap and abort the process if it discovered it, fine, but, at that point, it could, instead, check for an overlap and punt to memmove() with no loss of performance from the version that aborts in the case where there is no overlap and with a gain of "programs don't just barf mysteriously to the end user" in the case where there is.

    20. Re:Summary by Guy+Harris · · Score: 1

      Alternative history of Apple: Apple engineer speeds up memcpy implementation. Does some serious application testing for compatibility. Talks to Steve Jobs. "So what have you been working on?" "I made the C library a few percent faster, which benefits all users. It makes Adobe Flash crash". Steve Jobs: Dies laughing.

      Definitely an alternative history. (And, yes, memcpy() and memmove() use the same code for each of the other versions of that code - "scalar" 32-bit x86, SSE2 32-bit x86, SSE3 32-bit x86, SSE 4.2 32-bit x86, and PowerPC. The source to the ARM versions isn't available, so it's possible that for iOS it matters which one you use.)

      But use memcpy() only where you don't have overlap, even if you're working on OS X (or, I think, most if not all of the *BSDs), anyway.

    21. Re:Summary by Guy+Harris · · Score: 1

      I hope I'm not being too pedantic, but if your OS is crashing or hanging due to Adobe Flash or any other user space application, then your OS is broken. Memory protection is not new.

      You may, indeed, be inappropriately pedantic; he referred to "crashes or hangs", he did not explicitly say that the entire machine hung or crashed. Perhaps they were Safari (or Firefox or $OTHER_BROWSER_THAT_HAS_A_FLASH_PLUGIN) hangs or crashes.

    22. Re:Summary by tlhIngan · · Score: 1

      Drepper has gone to work at Goldman Sachs

      What? So many posts and no one makes the obvious joke about Glibc being so big and bloated that it impacts high-speed-trading platforms? Really?

      And that's a good reason not to not do the reverse memcpy, I agree. All I'm saying is that I'm weary of compromises that allows bad code to survive just to keep things running. I think that it works great in the short term, and gets your users happy that things are working again, but it just makes it more likely to break something else in the future as you make unrelated changes in the code. If the library user depends on implementation details instead of the API contract, you can inadvertently break him with routine maintenance. The end user certainly doesn't appreciate software that breaks with every six-month update. Like I said above, I would not be against a temporary compromise, as long as the actual bug gets fixed instead of grandfathered in.

      And you're basically saying the difference between Apple and Microsoft. Microsoft has to work hard to keep bad code running - because the companies and users that run said bad code will more often blame the shiny new version of Windows that broke it, than the software itself (which worked fine with the last version). See Windows XP and Windows Vista (Vista broke many bad pieces of software).

      Even worse is if you can't get access to the source to fix it (a potentially real problem for open-source as well, as more obscure packages simply die out and mirrors fade away, so the original source is literally unobtainable anymore).

      Apple's mentality is to let said software break - they only support what's documented and if you code against it, you should be fine. But if you stray, don't expect the program to work in the next OS release. (And this has resulted in MANY spectacular breakages - from haxies (input manager hacks) to dock additions leading to unbootable systems). And yes, it happens on iOS a lot too when you see "Fixed issues running on latest version of iOS" in the update notes, or better yet, "We know about issues running on latest iOS".

      As for which way is better - it really depends. The good thing with Linux is it tends to be really stable for long periods of time, so stick on an Ubuntu LTS and you're golden. Problems occur when upgrading (Android FroYo and Ubuntu 10.04 is a popular one when Sun JDK was removed and OpenJDK was not quite working). Though I suppose users would blame whatever Linux they're using if things break and stop working after an upgrade

    23. Re:Summary by bheading · · Score: 1

      Yeah, but he says "at least 80% of all crashes and hangs on my Mac" and then talks about how "iOS lives quite happily without Flash" but yeah, I'm sure he was referring to his browser and not to the whole machine.

    24. Re:Summary by ultranova · · Score: 1

      I think the key here is that the punishment for violating the C standard isn't that your program fails in an obvious fashion, it fails in a somewhat random fashion.

      That's the price you pay for programming in a non-managed language. I certainly agree with you in that memcpy() should check it's arguments and invoke memmove() (and print a nasty message to the console) in necessary, but ultimately, in a language like C, you can always put the runtime into an undefined state easily.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    25. Re:Summary by ultranova · · Score: 1

      >

      You may, indeed, be inappropriately pedantic; he referred to "crashes or hangs", he did not explicitly say that the entire machine hung or crashed. Perhaps they were Safari (or Firefox or $OTHER_BROWSER_THAT_HAS_A_FLASH_PLUGIN) hangs or crashes.

      A browser shouldn't crash either even if a plugin does. Run them in a separate process, and better yet, run every tab in a separate process.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    26. Re:Summary by Guy+Harris · · Score: 1

      Yeah, but he says "at least 80% of all crashes and hangs on my Mac" and then talks about how "iOS lives quite happily without Flash" but yeah, I'm sure he was referring to his browser and not to the whole machine.

      Good, I'm glad you agree with me, and realize that neither of the two statements you cite are in any way indications that he refers to the OS crashing or hanging as a whole (given that both OS X and iOS are UN*Xes that put each process's userland code in a separate address space and protect the kernel's address space from userland code):

      • the first statement says "on my Mac", but that's not "of my Mac" - it's quite believable that most of the cases where applications crash or hang on his Mac are cases where the application is Safari and the crash or hang is due to the Flash player;
      • the second statement mentions an operating system, iOS, but that just means that, as Apple controls the availability of third-party software, and does not allow Flash Player to be available (and does not support third-party plugins for Safari on iOS), Flash isn't available on iOS, and, for many users, that's not an issue.
    27. Re:Summary by Guy+Harris · · Score: 1

      A browser shouldn't crash either even if a plugin does. Run them in a separate process,

      Which Safari now does (I forget whether that was introduced in Safari 5 or earlier), and I suspect at least some other browsers do.

      and better yet, run every tab in a separate process.

      Which Safari doesn't do, although it does run the UI and the rendering/JavaScript stuff in a separate process (that was introduced in Safari 5.1).

    28. Re:Summary by Pseudonym · · Score: 1

      That's because memcpy() is literally from the dawn of the C Standard Library, when the Bell Labs hackers were trying to squeeze as much functionality as they could into machines which look pathetically small by today's standards.

      No, they don't look pathetically small by today's standards. And no, we can't move on. Yesterday's minicomputer is today's microcontroller or smartcard. These 40-year-old "small" platforms aren't dead, they've just been pushed down the food chain.

      That may not mean anything for the platforms that glibc (or Flash, for that matter) targets, but it's very important for the C standard.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  2. fork valley by buchner.johannes · · Score: 2

    There are a couple of forks apparently. Why does this have to be one monolithic library?

    For this reason, several alternative C standard libraries have been created which emphasize a smaller footprint. Among them are Bionic (based mostly on libc from BSD and used in Android[14]), dietlibc, uClibc, Newlib, Klibc, and EGLIBC (used in Debian, Ubuntu and ArkLinux).

    https://en.wikipedia.org/wiki/GNU_C_Library

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    1. Re:fork valley by TheRaven64 · · Score: 4, Interesting

      Those are not forks, they are different implementations. The Android libc is based on FreeBSD libc with some tweaks. It does not share code with glibc.

      --
      I am TheRaven on Soylent News
    2. Re:fork valley by shutdown+-p+now · · Score: 1

      Why does this have to be one monolithic library?

      Because it is the C standard library? Something that doesn't really make much sense to have just in part, you know. If you're writing portable C code, you expect it all.

    3. Re:fork valley by skids · · Score: 1

      Be thankful it is as monolithic as it is... if you've ever had to deal with building lib + toolchain on an architecture where the triplet system (the name like armel-linux-gnu) has to be fudged between binutils, gcc, and libc, there is a lot of hair-pulling involved there. I'd hate to think what it would be like if, say, libm went out in its own independently managed branch and the build system became unsyncronized at that level. WIth modern processors available in a greater variety of configurations within the same family, the multi-lib stuff is pretty much destined for chaos.

      --
      Someone had to do it.
  3. Excessive "modularity" can become hell. by Anonymous Coward · · Score: 5, Informative

    Monolithic libraries are the way to go. They make software development much easier.

    If you don't believe me, just look at the GNOME project. The last time I tried to build it from scratch by hand, there must have been at least 50 libraries I had to build first. That was several years ago, so there are probably many more that are needed now. Those were just libraries from the GNOME project, too! That's not including glibc, the many X libraries, Gtk+, and so forth! Don't forget that you'll need to start making sure you're using the right versions, too. Some of these libraries are released yearly, while others have a new release every week.

    To realistically build something like GNOME, where they went absolutely stupid with unnecessary modularity, you need to use one of the scripts that are out there that'll do it all for you. Those scripts end up being a solution to a problem that shouldn't exist in the first place! They're only needed because what should be one monolithic library was split out into 60 smaller libraries. You'll need all of the libraries to get even a basic GNOME installation up and running, so there's no point in separating them.

    It's not the 1980s any longer. We don't statically link everything using dumb linkers that can't strip out unused executable code. Modern OSes using dynamic linking and delayed loading only ever use the parts of libraries that are actually used.

    1. Re:Excessive "modularity" can become hell. by Anonymous Coward · · Score: 2, Insightful

      Agree on that. Similarly, even though GTK+ purports to be cross platform, I never use it because of the many libraries it requires, GLib, ATK, Pango, WhatEver. It's just too much pain to get them all right and distribute the stuff to somebody not running GNU/Linux. GTK+/GNOME guys suffer badly from overgeneralization. They just don't realize that nobody is going to give a shit about their complex system and want to modify its tiny little details using their wonderful module system.

    2. Re:Excessive "modularity" can become hell. by slashbart · · Score: 4, Interesting

      Amen!
      I like Qt's approach with only a couple of large libraries (QtCore, QtGui, QtXml, ...) where each has a very clear usage, and if you don't want graphics you don't use QtGui, but if you do, everything is in QtGui. Here's the list

    3. Re:Excessive "modularity" can become hell. by 3dr · · Score: 2

      +2 that.

      The building complexity is compounded also by a project's over-specification of dependencies. That is, instead of just requiring FooLib x.y, they are requiring x.y.z. Part of the problem here is that projects use dotted-version notation inconsistently. I would never expect an API change with a .z change, and I would only expect an API change to add functionality with a .y change but never a break in current code. A change in major version means anything goes. Many projects follow this. I wish I had kept notes of those I've run into that do not.

      Several years ago I was building a couple projects on Linux, and after downloading all the packages that weren't already on the system, I got things built. It was extremely time consuming, but it worked. Whatever happiness I had was soon vanquished because another program I wanted to use required one of the same libraries but with a different .z version, which, in some case, could cause a huge rippling of library do-overs. Ridiculous.

      As a related aside, one thing I would like to see is a migration of projects away from autoconf tools. I've been using cmake for over a year now to build cross-platform tools and it does everything autoconf could clumsily do, and better. It is truly a better tool for this job.

    4. Re:Excessive "modularity" can become hell. by skids · · Score: 2

      The building complexity is compounded also by a project's over-specification of dependencies. That is, instead of just requiring FooLib x.y, they are requiring x.y.z.

      Really this is a matter of not having the assets to do proper testing. A good test-driven-development and automated test environment would allow developers who are just trying to be cautious to be more confident about allowing more versions of dependencies.

      --
      Someone had to do it.
  4. It's not a fork by aglider · · Score: 3, Informative

    It's clearly written in the fery first FAQ:

    EGLIBC is not meant to be a fork of GLIBC.

    --
    Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
    1. Re:It's not a fork by bheading · · Score: 1

      Just because they say it's not a fork doesn't mean it isn't a fork :)

  5. The icon is wrong by phoxix · · Score: 4, Informative

    It should be GNU, not Debian. Glibc is very much a GNU project. How do people not know GlibC is a GNU project?

    1. Re:The icon is wrong by Anonymous Coward · · Score: 1

      In fairness, Debian is involved as well, as it supported the eglibc fork by adopting it.
      [which is mentioned in the linked resources, but not in the summary].

      I'd say the GNU icon should be added, and the Debian one could also stay, as long as the Debian side of the story is mentioned in the summary as well.

    2. Re:The icon is wrong by bheading · · Score: 3, Insightful

      The Debian tag is there because they promoted the eglibc fork.

      I am not quite sure that glibc is a GNU project. I thought for that to be true, the copyrights would have to be transferred to the FSF. Drepper posted a long rant a while back about how the FSF would do that over his cold, dead body.

    3. Re:The icon is wrong by mamas · · Score: 1

      That's not true at all.

      #1 - glibc is a GNU project
      #2 - to contribute code you do need a copyright assignment to the FSF.

      You've confused something else.

  6. Re:Drepper and Theo are great men. Respect them. by Anonymous Coward · · Score: 4, Insightful

    They are vilified as being "mean" or "intolerant" by some, merely because they point out the foolishness of others in public.

    They are vilified as being "mean" or "intolerant" because they act like mean intolerant assholes.

    A truly great programmer does not feel the need to belittle others' efforts. A truly great project leader does not feel the need to be rude and dismissive.

    Compare Linus Torvalds, who is just as opinionated and can be just as abrupt, and yet somehow manages not to be widely perceived as a mean intolerant asshole. Consider the possibility that this is because he is also frequently observed being polite and saying nice things in public.

  7. Re:Drepper and Theo are great men. Respect them. by Anonymous Coward · · Score: 1, Interesting

    Ulrich and Theo have both earned my respect based on their software development accomplishments. I could not care any less about what they may or may not have said to somebody on some mailing list or bug report. That is all secondary to the amazing software they're managed to produce.

    I don't have exact numbers here, but Ulrich has had a massive role in producing what may very well be the most widely used C library ever. There's a very good chance that the very computer you're using right now is executing at least some of the code he's written hundreds of times each second! Then there are the millions of servers around the world running Linux and Glibc that are performing extremely important tasks, and they're likely doing this using at least some of Ulrich's code. That's a very significant accomplishment, and I have great respect for him because of this.

    The same goes for Theo. He's managed to produce what may be the most secure pieces of software ever written. It's even more respectable because it's not just a single library or application. It's a whole UNIX-like system, for crying out loud! It's a great accomplishment to be so integral to an effort like OpenBSD, which has astoundingly great code quality and security.

    I judge both Ulrich and Theo on their accomplishments, and they have nothing but the highest level of respect from me because of everything they've managed to build.

  8. Re:Drepper and Theo are great men. Respect them. by TheRaven64 · · Score: 4, Interesting

    Theo and Drepper are very different. Theo is usually technically correct and has no time for people who can't work out why for themselves. Drepper is very often wrong, and is still an asshat in these cases.

    --
    I am TheRaven on Soylent News
  9. Re:Drepper and Theo are great men. Respect them. by TheRaven64 · · Score: 2, Informative

    I don't have exact numbers here, but Ulrich has had a massive role in producing what may very well be the most widely used C library ever

    Is this 'may be' as in the Wikipedia definition, meaning 'isn't'? FreeBSD libc - not GNU libc - is the basis of both the Android and OS X libc implementations, and either one of these uses likely dwarfs glibc installs. And that's before you get to the Microsoft one (which is crap, but is installed on every Windows system).

    --
    I am TheRaven on Soylent News
  10. Re:Drepper and Theo are great men. Respect them. by rgbrenner · · Score: 4, Interesting

    When I first started using Linux (about '97).. I emailed Torvalds to say that I thought Linux needed to advertise because a lot of people didn't know it existed. He actually responded and politely explained how the project is put together/why that wasn't going to happen.

  11. Re:Drepper and Theo are great men. Respect them. by icebraining · · Score: 1

    Not that have some kind of allegiance to the glibc, but what do all those Linux based GPSs, routers, TVs, etc, not to mention all those servers? Franky, I find it hard to believe that Android dwarfs all of those put together.

    --
    Dilbert RSS feed
  12. Re:Drepper and Theo are great men. Respect them. by TheRaven64 · · Score: 3, Informative

    Not that have some kind of allegiance to the glibc, but what do all those Linux based GPSs, routers, TVs, etc, not to mention all those servers?

    Most embedded users don't use glibc either, they use something like newlib or uclibc, depending on the resource constraints.

    --
    I am TheRaven on Soylent News
  13. Re:Drepper and Theo are great men. Respect them. by Anonymous Coward · · Score: 1

    It's very doubtful that all FreeBSD, Android, Mac OS X and iOS installations put together "dwarf" the number of Linux installations, as you claim. Among all of those installations or devices, including any ever manufactured (although many are no longer used, given their surprisingly short lifespan), it's unlikely that over 1 billion devices have been shipped. In reality, we're probably looking at a range of 600 million to 800 million units, if even that.

    Linux is extremely prevalent, much more so than even you would likely think. It's not just used solely in semi-disposable consumer-grade smart phones like Android and iOS, or rare desktop systems or servers like Mac OS X and FreeBSD. Linux, and usually glibc, have been used in billions upon billions of devices. Aside from the many consumer devices using Linux, many of these other installations are highly-specialized industrial devices and tools that you likely wouldn't even know existed unless you worked in the proper fields. There is a huge amount of Linux infrastructure out there that isn't very visible, yet is very important. With Linux's excellent support for virtualization and its very flexible licensing, it's not rare at all these days to encounter infrastructure with hundreds of thousands, if not millions, of virtualized Linux installations. Much of these specialized devices and infrastructure using Linux and glibc will remain in production use far after Android and iOS are mere footnotes in the history of computing.

    Don't forget that EGLIBC was directly based on glibc. So while Ubuntu and Debian may not be using glibc directly these days, they are still essentially using glibc's code. Microsoft's implementation is perhaps the only one that can rival glibc, in terms of usage. But even its numbers may pale when considering all of the "unseen" Linux installations that surround us.

  14. Re:Drepper and Theo are great men. Respect them. by Anonymous Coward · · Score: 1

    As somebody who has worked on many embedded Linux devices in the past, and who continues to do so today, I can tell you that you're completely wrong. Even the cheapest embedded hardware we deal with today is more than powerful enough to handle Linux and glibc, and that's what almost everybody chooses to use. This has been true since about 2003-2004. In fact, it takes more work and effort to not use glibc these days! Nobody will take you seriously if you suggest having a single developer waste even a single day trying to use a non-glibc library in an embedded Linux system. It's much cheaper and more efficient to use the well-tested and very capable glibc, given that the embedded hardware constraints of the 1950s-1990s are no longer of any concern.

  15. Re:Drepper and Theo are great men. Respect them. by Chrisq · · Score: 1

    Respect is earned, not given.

    Except in Bradford West.

  16. Re:Drepper and Theo are great men. Respect them. by donscarletti · · Score: 2

    Well, there are people with a lot of ability who are able to cooperate with others and there are those who cannot. Theo should pick a smaller project than an operating system to do by himself and I'm sure he could do brilliantly and make it famous and widely used (OpenBSD is known by most of slashdot, mostly for its phenomenal strokes of brilliance in the areas Theo cares about and its gaping lack of features in other areas). Drepper on the other hand, well, I'm not sure what's so great about glibc, sure, sprintf never has crashed on me but fucked if I'm handing out any credit to the guy who manages stlib.h just because he manages it.

    --
    When Argumentum ad Hominem falls short, try Argumentum ad Matrem
  17. Re:Drepper and Theo are great men. Respect them. by tyrione · · Score: 1

    You're high if you think Linux hasn't been dwarfed by iOS alone, never mind Android and OS X. Wake me up when hundreds of millions of Linux/glibc consumers arrive.

  18. For a good laugh by BlackPignouf · · Score: 4, Funny

    Read http://sourceware.org/bugzilla/show_bug.cgi?id=4980 or http://sourceware.org/bugzilla/show_bug.cgi?id=4403 for a good laugh. /. trolls pale in comparison. :D

    1. Re:For a good laugh by ArsenneLupin · · Score: 1
      It's funny, reminds me of that old joke with the mighty US navy battleship and the lighthouse...

      Unfortunately, it seems that at least some of the Ulrich Drepper "don't reopen" replies were not actually him, but an impostor...

  19. Re:Drepper and Theo are great men. Respect them. by Shinobi · · Score: 1

    Speaking as someone who develops embedded devices: Raven64 is correct.

    Many projects still require minimal hardware(less than 16KiB RAM, a barebones processor with no cache etc etc), for many different reasons, such as hardening, long battery life(speaking months or even years here, not hours or a couple of days at most), heat/cooling reasons etc, and reduced complexity, increasing reliability.

    Other reasons not to use glibc include real-time requirements, with glibc being barely capable of soft real-time, meaning you use other libraries instead, if you even use any.

    No, building your own little HTPC from a Mini-ITX board etc does not constitute embedded development.

  20. Re:Drepper and Theo are great men. Respect them. by Anonymous Coward · · Score: 1

    He didn't judge anyone. What he said is correct: Drepper is often wrong. Just look at the dick waving contest he engages in every time someone says strlcpy() anywhere near him.

  21. Re:Drepper and Theo are great men. Respect them. by ArsenneLupin · · Score: 1

    Udpcast recently switched from glibc to uclibc in order to stay small enough to stay bootable from floppy.

  22. Re:Drepper and Theo are great men. Respect them. by shutdown+-p+now · · Score: 2

    I dunno; GP has actually signed his post, unlike you, and anyone can go check his Slashdot comment history. In fact, I don't even need to do that, because I see his upmodded posts often enough - and, invariably, they are informative and correct when technical matters are involved (and he doesn't post about stuff he doesn't know, either).

    Drepper, on the other hand... his stubbornness when pointed out that his code is plain wrong and non-portable is enough to judge him on his merits alone, regardless of the attitude problem that he has.

  23. Re:Drepper and Theo are great men. Respect them. by Guy+Harris · · Score: 1

    I don't have exact numbers here, but Ulrich has had a massive role in producing what may very well be the most widely used C library ever. There's a very good chance that the very computer you're using right now is executing at least some of the code he's written hundreds of times each second!

    There's an excellent chance that the computers that a number of people posting to Slashdot are running are executing code either in a C library from Microsoft or in one that's a combination of FreeBSD and Apple code; are you asserting that most Slashdot posters are running Linux on the machine on which they're posting (which might be correct - the Slashdot audience is different from the "owns a desktop or notebook computer" audience) or that Drepper's code is in one or both of those C libraries? The rest of your post may be valid, but be careful with that assumption - it's not a Linux-only party here.

  24. Re:Drepper and Theo are great men. Respect them. by skids · · Score: 1

    A truly great programmer does not feel the need to belittle others' efforts. A truly great project leader does not feel the need to be rude and dismissive.

    I don't think having such a psychological complex necessarily disqualifies one from being a "truly great programmer." There are plenty of utter douchbags who excel in their fields/skills. But you'd be right about project leadership, as that is an area that requires interpersonal skills and much patience and tolerance. Partly because you have to deal adeptly with highly skilled douchebags, but especially because you have to deal with the mediocre ones as well.

    --
    Someone had to do it.
  25. Re:Drepper and Theo are great men. Respect them. by bheading · · Score: 1

    Er, Linux won't run in 16KB RAM. I don't think it ever did. Usually, embedded devices have a cache. Indeed RISC CPUs with their instruction throughput are more dependent on a cache than would otherwise be the case.

    I'm an embedded developer by trade and I've seen projects using both glibc and uclibc. I'd gravitate towards uclibc on the basis that it is small, lightweight and easy for me to poke around in compared with the glibc behemoth; these things are all important. On the other hand, uclibc occasionally has some stupid bugs, like a leap year bug that was fixed recently, and which showed up about a year back.

  26. Re:Drepper and Theo are great men. Respect them. by Shinobi · · Score: 1

    Yeah, but the AC claimed that the hardware restraints don't exist anymore

  27. Re:Drepper and Theo are great men. Respect them. by tlhIngan · · Score: 1

    As somebody who has worked on many embedded Linux devices in the past, and who continues to do so today, I can tell you that you're completely wrong. Even the cheapest embedded hardware we deal with today is more than powerful enough to handle Linux and glibc, and that's what almost everybody chooses to use. This has been true since about 2003-2004. In fact, it takes more work and effort to not use glibc these days! Nobody will take you seriously if you suggest having a single developer waste even a single day trying to use a non-glibc library in an embedded Linux system. It's much cheaper and more efficient to use the well-tested and very capable glibc, given that the embedded hardware constraints of the 1950s-1990s are no longer of any concern.

    Not really. Most use uClibc internally, even though they could use glibc. uClibc and newlib are two of the more common libc's to use for embedded, even when there's plenty of flash and processor power to go around. Hell, there are piles of toolchains prebuilt around uClibc.

    Heck, most embedded systems can get away from using busybox, but most choose to use it because the reference design chosen uses it (very few devices are customized beyond the basics - mostly cost reductions and such).

    Honestly, I run across far few glibc based toolchains for cross compiling than non - uClibc/newlib's by far the more popular, and with the ease at which people can obtain it versus having to build it themselves. Heck, I'm sure the glibc folks weren't helping themselves by concentrating on x86-based systems.

  28. Card game by tepples · · Score: 1

    I don't see how it'd be frightening. There's probably some sort of card game that relies on strfry() to shuffle the deck.