Changes in glibc development [LWN.net]

Roland McGrath has sent out an announcement that the glibc steering committee, which oversaw development of the GNU C library, is dissolving. "With the recent reinvigoration of volunteer efforts, the community of developers is now able to govern itself. Therefore, the Steering Committee has decided unanimously to dissolve. The direction and policies of the project will now be governed directly by the consensus of the people active in glibc development." Joseph Myers, one of the volunteers who has helped to pick things up again, has added: "Everyone is welcome to join in the development, working in accordance with community-agreed practices and GNU policy, and commit access is routinely available for people making good contributions." He has also suggested that, over time, the eglibc fork may be merged back in to glibc. (Thanks to Michael Kerrisk).

to post comments

Changes in glibc development

Posted Mar 27, 2012 13:39 UTC (Tue) by grobian (guest, #83608) [Link] (5 responses)

Was about time. They should have done this years ago.
Looks like Drepper finally managed to annoy even his
most hardcore supporters.

Changes in glibc development

Posted Mar 27, 2012 13:48 UTC (Tue) by corbet (editor, #1) [Link] (3 responses)

I think a number of changes have been made in the glibc project; it would be a mistake, I think, to see this as a story about one person.

Changes in glibc development

Posted Mar 27, 2012 13:57 UTC (Tue) by grobian (guest, #83608) [Link] (1 responses)

I think these two recent mails by him drove them over the edge:

http://article.gmane.org/gmane.comp.lib.glibc.alpha/17118
http://article.gmane.org/gmane.comp.lib.glibc.alpha/17116

Changes in glibc development

Posted Mar 27, 2012 18:01 UTC (Tue) by nix (subscriber, #2304) [Link]

Hardly. glibc development took off some time before. I'd not be at all surprised to learn that what triggered the change was Ulrich's departure from RH, and the subsequent appointment of Jeff Law as the glibc maintainer there.

Changes in glibc development

Posted Mar 27, 2012 15:18 UTC (Tue) by daney (guest, #24551) [Link]

In this particular case, I think it may really be a story about one person. The current maintainers are sensibly concentrating on the good parts of the new reality, but there is this thing that isn't discussed. And that is probably for the best for all concerned.

Changes in glibc development

Posted Mar 27, 2012 16:14 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Looks like Drepper finally managed to annoy even his most hardcore supporters.

Not sure what qualifies as "hardcore supporter" here, but I have to say I am so terribly annoyed by Ulrich. I mean, all that terrible stuff that he put into glibc over the years... Seriously, it doesn't get any worse.

;-)

Changes in glibc development

Posted Mar 27, 2012 13:51 UTC (Tue) by slashdot (guest, #22014) [Link] (2 responses)

What happened to Ulrich Drepper?
Was he still the glibc maintainer before this announcement?

Did he voluntarily give up his role, or was he kicked out?

Why hasn't Roland McGrath (who is the original author, and seems a competent and reasonable person) taken up the maintainer role himself?

Won't giving commit access to all "good contributors" tend to result in patches getting committed without review, thus leading to lowered code quality?

Changes in glibc development

Posted Mar 27, 2012 15:18 UTC (Tue) by vapier (guest, #15768) [Link]

Ulrich changed jobs and no longer works for RedHat. presumably the amount of time he has to spend directly on glibc development has gone down significantly.

i don't want to speak for Roland, so i'll just make generalities. not everyone has a full time job just for glibc, or even wants that. there is a lot of interesting computer development going on nowadays in other areas.

new maintainers

Posted Mar 27, 2012 21:05 UTC (Tue) by stevenj (guest, #421) [Link]

From the mailing list:

The following people have agreed to be responsible for glibc to the GNU Project: Ryan Arnold, Maxim Kuvyrkov, Joseph Myers, Carlos O'Donell, Alexandre Oliva. (This does not confer any extra ability to make decisions for the project; community consensus is what matters there.)

Changes in glibc development

Posted Mar 27, 2012 14:02 UTC (Tue) by msbrown (guest, #38262) [Link] (2 responses)

No-one has been "kicked out" of anything.

Rather, the number of key contributors with the ability to commit changes (in essence, ability to maintain glibc) has been increased based on those contributors' clearly visible quality and dedication to the work.

Evidence that this is working? Compare the quantity (and quality) of traffic on the glibc mailing lists in the past couple of months since this change started to be folded into practice.

Changes in glibc development

Posted Mar 27, 2012 18:03 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Rather, the number of key contributors with the ability to commit changes (in essence, ability to maintain glibc) has been increased based on those contributors' clearly visible quality and dedication to the work.

Of course, this could have happened years and years ago, but for some reason someone who shall remain nameless was dead set against it. (it worked so badly for GCC, after all.)

Changes in glibc development

Posted Mar 27, 2012 19:09 UTC (Tue) by slashdot (guest, #22014) [Link]

The kernel has a single person who can commit changes, and it works very well (although Linus probably tends to pretty much just rubber stamp changes from subsystem maintainers that don't impact code outside the subsystem).

But of course, if no one suitable and willing can be found, multiple committers are better than a bad single maintainer (which Ulrich Drepper was alleged to be).

Perhaps an interesting alternative could be to use a more structured review system (Gerrit?), which makes sure that at a least a few other committers see no issues with a patch even if commit rights are decentralized.

Changes in glibc development

Posted Mar 27, 2012 23:00 UTC (Tue) by juliank (guest, #45896) [Link] (1 responses)

So, given that glibc has been taken over by a group of people closer to the core of the GNU project than Drepper, will the next step be a switch from the LGPL-2.1 to LGPL-3?

Changes in glibc development

Posted Mar 28, 2012 1:12 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

No, the FSF (who owned the copyright before and still do) are not going to change the license terms.

The more interesting possible outcome is a merger of eglibc and glibc.

Changes in glibc development

Posted Mar 28, 2012 5:40 UTC (Wed) by cmccabe (guest, #60281) [Link] (10 responses)

With Ulrich gone, where will we get our drama from?

Who will break Flash for everyone by changing memcpy to not work with overlapping regions? Who will force everyone to write their own wrapper for gettid() on Linux (despite the fact that glibc has several interfaces that require the result of gettid to be passed to them).

Who will declare that "tarballs are obsolete" and force everyone to fetch his releases from (the completely non-obsolete) CVS system? Who else will try to rip out sunRPC from glibc before there's an alternate working implementation? Who else will refuse to make setenv thread-safe, because programmers who don't read the fine print of POSIX need to get burned (and obviously setenv is such a performance bottleneck.)

With Ulrich gone, I can only imagine that glibc is going to be positively boring...

Changes in glibc development

Posted Mar 28, 2012 7:03 UTC (Wed) by quotemstr (subscriber, #45331) [Link] (1 responses)

> Who will break Flash for everyone by changing memcpy to not work with overlapping regions?

Yet again: memcpy isn't guaranteed to work on overlapping regions. Use memmove if you think regions might overlap. Whatever else Drepper did, changing memcpy was perfectly legitimate.

Changes in glibc development

Posted Mar 28, 2012 16:58 UTC (Wed) by cmccabe (guest, #60281) [Link]

Linus Torvalds believed that the new memcpy was actually slower, as well as a bad decision from the release management point of view. There's no point in rehashing the discussion, you can find it all here:
https://bugzilla.redhat.com/show_bug.cgi?id=638477

Changes in glibc development

Posted Mar 28, 2012 7:21 UTC (Wed) by suckfish (guest, #69919) [Link] (3 responses)

Sounds like you're looking for Solaris, not Linux. In Solaris land, anything goes (most of the time). Bogus memcpy doesn't crash (most of the time). Bogus free doesn't crash (most of the time).

Good for design wins for marketing droids selling to corporates --- "look, your crappy code compiles and runs (most of the time)".

Crap for anyone who actually wants bugs to get fixed.

Changes in glibc development

Posted Mar 28, 2012 8:46 UTC (Wed) by jengelh (subscriber, #33263) [Link]

>Good for design wins for marketing droids selling to corporates --- "look, your crappy code compiles and runs (most of the time)". Crap for anyone who actually wants bugs to get fixed.

The x86 architecture is just the same (and so are others like IA64).

Changes in glibc development

Posted Mar 28, 2012 10:45 UTC (Wed) by dps (guest, #5725) [Link] (1 responses)

Having used Solaris (SPARC) I know in that land newly allocated memory frequently contains values very different from 0 which can break *buggy* code that allocates an array of pointers on the heap and assumes they are all initially null. This usually just works on Linux.

Solaris has not monopoly on "your bugware just works most of the time". Some bugware dies badly on Solaris but works on Linux and other systems where freshly allocated memory is all 0 most of the time.

What I really don't like in glibc is implementing a pipe2 function returning ENOSYS, if is not implemented, instead of implementing it using pipe(2) and fcntl(2), No doubt someone would call this is a feature but I can't work up enough enthusiasm for it to do so.

Changes in glibc development

Posted Mar 28, 2012 11:42 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

It's not that returning ENOSYS is a feature, but that pretending to work would be a hidden-race-condition bug.

Changes in glibc development

Posted Mar 28, 2012 12:59 UTC (Wed) by man_ls (guest, #15091) [Link] (2 responses)

With Ulrich gone, where will we get our drama from?

You can always install OpenBSD and follow de Raadt. Or you can <shiver>buy a TV set<shiver>.

Changes in glibc development

Posted Aug 22, 2012 9:15 UTC (Wed) by arekm (guest, #4846) [Link] (1 responses)

.. or Miller on netdev. Similar attitude recently.

Changes in glibc development

Posted Aug 22, 2012 13:44 UTC (Wed) by nix (subscriber, #2304) [Link]

Your comment is unintentionally ironic, since Uli and davem really *really* didn't get on. (I also note that davem will at least listen to reasoned argument.)

Changes in glibc development

Posted Mar 28, 2012 18:16 UTC (Wed) by nix (subscriber, #2304) [Link]

Who will break Flash for everyone by changing memcpy to not work with overlapping regions?

That optimization was due to H. J. Lu, who is still involved. :)

Changes in glibc development

Posted Mar 28, 2012 12:54 UTC (Wed) by lkundrak (subscriber, #43452) [Link] (1 responses)

I don't quite get all the hate comments toward Ulrich Drepper. Maybe proponents of good engineering decisions that Ulrich favoured over pragmatism did not have to speak as loud in discussions as the primary glibc maintainer was "on their side."

Ulrich did an awesome job at maintaining libc sanity over the years which I'm thankful for.

Incompetent engineers that are willing to avoid crashing by introducing strange bugs by chopping off parts of string with strlcpy() should really use a higher level interface than C library. Java, Perl, Go, Python are there for them. Same goes for performance.

Changes in glibc development

Posted Mar 28, 2012 18:20 UTC (Wed) by nix (subscriber, #2304) [Link]

I think Uli is an excellent *developer*. I think he was not an excellent *maintainer*, because the job of a maintainer is not just to say no to everyone but also to nurture a development community so you don't have to do all the work yourself. This he manifestly failed to do. (The rate of bugfixing suggests that he didn't even keep up with the rate of bug reports, which is unsurprising as there is only one of him.)

Changes in glibc development

Posted Mar 28, 2012 15:21 UTC (Wed) by mjthayer (guest, #39183) [Link] (4 responses)

Does anyone who is following glibc development (Joe? Nix?) have a feeling for whether it is likely to become more friendly to static linking any time as a result of these changes?

Changes in glibc development

Posted Mar 29, 2012 16:15 UTC (Thu) by jwakely (guest, #60262) [Link] (3 responses)

I would guess it's unlikely. For distros or software vendors the arguments in the "static linking considered harmful" doc make sense, and most of the glibc team work for distros or software vendors.

I think for it to change there would need to be more people working on glibc who only care about more-specialised environments where most (or all) of the arguments are irrelevant.

Changes in glibc development

Posted Mar 29, 2012 16:40 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Glibc is THE worst library for application developers. I can't make a simple executable on my Ubuntu 12.04 that can be run on RHEL6 because of incompatible glibc.

And _you_ _can't_ _do_ _anything_ about it. Nothing at all. You can at least package other libraries along with your application but you can't do it with glibc (yeah, 'considered harmful').

So I'm forced to rebuild all my apps on ancient RHEL5. Bleah.

Changes in glibc development

Posted Mar 29, 2012 17:14 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

I can't make a simple executable on my Ubuntu 12.04 that can be run on RHEL6 because of incompatible glibc.

Yes, you can. Install SDK, target LSB 4.0, problem solved. You can even target LSB 3.1 and support RHEL5 this way.

And yes, if you'll compile program this way your binary will use system-installed version of glibc, it'll not require any LSB packages.

LSB is surprisingly robust tool and it solves things like GLibC lack of forward compatibility nicely. The problem with it lies in the fact that it does not give you usable environment: libraries are added slowly and some essential ones are still missing. But this is not a GLibC problem.

Changes in glibc development

Posted Mar 29, 2012 18:24 UTC (Thu) by foom (subscriber, #14868) [Link]

Another the thing you can do is install an Ubuntu 10.04 chroot on your Ubuntu 12.04 system.

In fact, there's so many things you can do that it's hard to even know where to start enumerating them. :)