Forgot your password?
typodupeerror
Debian GNU is Not Unix Open Source Linux

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

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Summary (Score:5, Interesting)

    by TheRaven64 (641858) on Saturday March 31, 2012 @08:33AM (#39533635) Journal
    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).
    • by Anonymous Coward

      now Drepper has gone to work at Goldman Sachs

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

  • by buchner.johannes (1139593) on Saturday March 31, 2012 @08:46AM (#39533711) Homepage Journal

    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 [wikipedia.org]

    • Re:fork valley (Score:5, Interesting)

      by TheRaven64 (641858) on Saturday March 31, 2012 @08:54AM (#39533747) Journal
      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.
    • by Anonymous Coward on Saturday March 31, 2012 @08:55AM (#39533757)

      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.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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.

        • by 3dr (169908)

          +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

          • by skids (119237)

            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.

      • by slashbart (316113) on Saturday March 31, 2012 @11:36AM (#39534799) Homepage
        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 [wikipedia.org]
    • 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.

    • by skids (119237)

      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 with

  • It's not a fork (Score:4, Informative)

    by aglider (2435074) on Saturday March 31, 2012 @09:00AM (#39533771) Homepage

    It's clearly written in the fery first FAQ [eglibc.org]:

    EGLIBC is not meant to be a fork of GLIBC.

  • The icon is wrong (Score:5, Informative)

    by phoxix (161744) on Saturday March 31, 2012 @09:07AM (#39533807)

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

    • by Anonymous Coward

      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.

    • by bheading (467684) on Saturday March 31, 2012 @10:48AM (#39534417)

      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.

      • by mamas (468872)

        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.

  • by BlackPignouf (1017012) on Saturday March 31, 2012 @02:26PM (#39535903)

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

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

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Working...