Changes in glibc development
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).
Posted Mar 27, 2012 13:39 UTC (Tue)
by grobian (guest, #83608)
[Link] (5 responses)
Posted Mar 27, 2012 13:48 UTC (Tue)
by corbet (editor, #1)
[Link] (3 responses)
Posted Mar 27, 2012 13:57 UTC (Tue)
by grobian (guest, #83608)
[Link] (1 responses)
http://article.gmane.org/gmane.comp.lib.glibc.alpha/17118
Posted Mar 27, 2012 18:01 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Mar 27, 2012 15:18 UTC (Tue)
by daney (guest, #24551)
[Link]
Posted Mar 27, 2012 16:14 UTC (Tue)
by bojan (subscriber, #14302)
[Link]
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.
;-)
Posted Mar 27, 2012 13:51 UTC (Tue)
by slashdot (guest, #22014)
[Link] (2 responses)
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?
Posted Mar 27, 2012 15:18 UTC (Tue)
by vapier (guest, #15768)
[Link]
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.
Posted Mar 27, 2012 21:05 UTC (Tue)
by stevenj (guest, #421)
[Link]
Posted Mar 27, 2012 14:02 UTC (Tue)
by msbrown (guest, #38262)
[Link] (2 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.
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.
Posted Mar 27, 2012 18:03 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Mar 27, 2012 19:09 UTC (Tue)
by slashdot (guest, #22014)
[Link]
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.
Posted Mar 27, 2012 23:00 UTC (Tue)
by juliank (guest, #45896)
[Link] (1 responses)
Posted Mar 28, 2012 1:12 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link]
The more interesting possible outcome is a merger of eglibc and glibc.
Posted Mar 28, 2012 5:40 UTC (Wed)
by cmccabe (guest, #60281)
[Link] (10 responses)
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...
Posted Mar 28, 2012 7:03 UTC (Wed)
by quotemstr (subscriber, #45331)
[Link] (1 responses)
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.
Posted Mar 28, 2012 16:58 UTC (Wed)
by cmccabe (guest, #60281)
[Link]
Posted Mar 28, 2012 7:21 UTC (Wed)
by suckfish (guest, #69919)
[Link] (3 responses)
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.
Posted Mar 28, 2012 8:46 UTC (Wed)
by jengelh (subscriber, #33263)
[Link]
The x86 architecture is just the same (and so are others like IA64).
Posted Mar 28, 2012 10:45 UTC (Wed)
by dps (guest, #5725)
[Link] (1 responses)
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.
Posted Mar 28, 2012 11:42 UTC (Wed)
by mpr22 (subscriber, #60784)
[Link]
Posted Mar 28, 2012 12:59 UTC (Wed)
by man_ls (guest, #15091)
[Link] (2 responses)
Posted Aug 22, 2012 9:15 UTC (Wed)
by arekm (subscriber, #4846)
[Link] (1 responses)
Posted Aug 22, 2012 13:44 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Mar 28, 2012 18:16 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Mar 28, 2012 12:54 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
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.
Posted Mar 28, 2012 18:20 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Mar 28, 2012 15:21 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (4 responses)
Posted Mar 29, 2012 16:15 UTC (Thu)
by jwakely (subscriber, #60262)
[Link] (3 responses)
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.
Posted Mar 29, 2012 16:40 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
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.
Posted Mar 29, 2012 17:14 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
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.
Posted Mar 29, 2012 18:24 UTC (Thu)
by foom (subscriber, #14868)
[Link]
In fact, there's so many things you can do that it's hard to even know where to start enumerating them. :)
Changes in glibc development
Looks like Drepper finally managed to annoy even his
most hardcore supporters.
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
Changes in glibc development
http://article.gmane.org/gmane.comp.lib.glibc.alpha/17116
Changes in glibc development
Changes in glibc development
Changes in glibc development
Changes in glibc development
Was he still the glibc maintainer before this announcement?
Changes in glibc development
From the mailing list:
new maintainers
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
Changes in glibc development
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
Changes in glibc development
No, the FSF (who owned the copyright before and still do) are not going to change the license terms.
Changes in glibc development
Changes in glibc development
Changes in glibc development
Changes in glibc development
https://bugzilla.redhat.com/show_bug.cgi?id=638477
Changes in glibc development
Changes in glibc development
Changes in glibc development
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
Changes in glibc development
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
Changes in glibc development
Changes in glibc development
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
Changes in glibc development
Changes in glibc development
Changes in glibc development
Changes in glibc development
Changes in glibc development
I can't make a simple executable on my Ubuntu 12.04 that can be run on RHEL6 because of incompatible glibc.
Changes in glibc development