Glibc spent over a decade under Ulrich Drepper, who many viewed as a dictator. This resulted in forks and major linux distributions no longer using glibc. About 6 years ago, Drepper was removed and glibc moved to "cooperative community development"[0].
The community spoke and said they did not like dictators in development of glibc. Since Drepper's removal, many would agree that the quality of glibc has increased significantly. RMS is well aware of this and the delicate political situation. He should recognize that coming in and declaring himself in charge would not play well with a community that stated about their maintainers following Drepper: "This does not confer any extra ability to make decisions for the project; community consensus is what matters there."
I beg to disagree. The quality post-Drepper certainly did not improve. Bugs are getting worse, needed features are still not implemented, needed performance improvements are sidelined (bsd libc still 20% faster with modern CPUs), crazy but useless ASM optimizations are being added, where e.g. proper loops written in C gain much more. Just not on gcc.
Same as with stdlib++ btw, where strings are now uselessly bloated and most data structures are getting useless also.
Where are utf8 strings? u8"" constants only is for nothing. Everybody needs an u8 api.
Where are the secure _s extensions? Pickering about callbacks and Microsoft is all they can do. But they rather add env hooks.
__bos/alloc_size support is getting better, but gcc still cannot do proper usable const expressions in C. It's a nightmare.
You still cannot compare strings, even not with the crazy wchar_t strings (size 2 or 4), nobody uses anymore. wcscmp only compares buffers, but not strings according to the unicode rules. I believe strings would be pretty important to support, not?
What about a fast malloc? Not even ptmalloc3 went in, there's still stone-age ptmalloc2.
double-close leads to crashes, really? Similar to freopen with NULL.
This is your great community consensus. BSD or even musl are far ahead.
My own benchmarks. The trick is SSE support.
darwin/bsd has that builtin, esp. since darwin can guarantee that their chips do support SSE. Generic linux builds do not, and -march-native or switching to sse optimized shared libs is rarely used.
But recently also bos and align_size support got better in other libc's, which do use clang and not gcc. gcc sucks big time with those optimizations. freebsd and darwin all use clang. This is in the ~60% ball figure.
Every 64-bit OS can guarantee SSE2 support, because it's baked into the x86-64 spec. Every single 64-bit Linux build can and does use SSE2 (unless someone explicitly turned that off for no reason). If there are performance differences, it's not due to chip support and crippled builds for compatibility.
The size of dynamically allocated malloc'ed structures, not just constants. The majority of pointers have an alloc_size, but no object_size (i.e. bos: __builtin_object_size).
The community spoke and said they did not like dictators in development of glibc. Since Drepper's removal, many would agree that the quality of glibc has increased significantly. RMS is well aware of this and the delicate political situation. He should recognize that coming in and declaring himself in charge would not play well with a community that stated about their maintainers following Drepper: "This does not confer any extra ability to make decisions for the project; community consensus is what matters there."
[0] https://sourceware.org/ml/libc-alpha/2012-03/msg01040.html