I can't say anything about GLIBC1, I simply wasn't 'seasoned' enough at the time. GLIBC2, however, has been bad from the start. I can see no likely reason other than a fundamental retardation on the part of the FSF. We do not use HURD, do you know why? Because it sucks. We should not use GLIBC2, because it is: HURD's GLIBC. Don't get me started on GCC.

My very first exposure to GLIBC2 was when I posted a hack on LKML that was essentially the asme as /dev/pts, but in 1997, before UNIX98. It was a simple kernel patch that solved both the ptty allocation problem and the ptty permissions problem in one simple step. I immediately got flamed by some GLIBC2 developers who called my solution inadequate because it didn't solve the /dev/hda /dev/hdb .. /dev/hdk .. /dev/hdz?? allocation problem as well. They thought their stupid little suid helper was a better solution to the ptty permission problem and considered the ptty allocation problem to be irrelevant.

My second exposure to GLIBC2 was when I found a pair of bugs in mktemp(), one of which was security-important. I found these bugs in GLIBC1 (Linux libc5), and I specifically did not find them in BSD libc. A quick check revealed GLIBC2 (a grand step up, but the same shitty "I can't even read a manpage" mentality towards implementation?) had the same bugs, but they were apparently fixed quickly. At least they didn't flame me for believing in standards.

Now I'm a professional compiler developer and am exposed to the fact that GLIBC2 is gratuitously gcc-dependent. Compare:

#define mymacro(x,y) (x ? y : 0)
to the GLIBC2 style:
#define mymacro(x,y) __extension__({ int res; if (x) { res = y; } else { res = 0; } res; })

The difference is that the former is valid ANSI C. The second requires a gcc extension called 'statement expressions'. It's a wholely unnecessary requirement, but one that glibc2 manages to sneak in quite frequently.

Now I've gained just a little exposure to BSD libc. Do you know what it's underlying principle appears to be? Straightforwardness. We're talking about a C library, a very simple set of string, math, locale, multithreading (now), memory allocation, and system wrapper functions. This is the very first thing you want to get on a new platform when doing a port, it is probably the most ported code ever. You will often port the C library to platforms you haven't even gotten your compiler to run on natively yet. Every piece of overhead added to your C library is added to every single program on your system. Every incompatibility in your C library will affect every developer to ever use it, tying him to specific versions of specific compilers on specific platforms. Every change you make to your core C library will have to work on all of the platforms your C library works on, and will have to be merged into all of the ports and forks of your C library.

So it goes to reason that you need your C library to be simple. You need it to obey the ANSI standard as absolutely as possible. You need it to be fast. You need it to be small. BSD has all of these things, plus one more that's a bit more important to much of the world: it's BSD licensed, which is much more forgiving than even the LGPL. The end result? The BSD library has been ported absolutely everywhere.

At work we have one guy responsible for the BSD libc port, and it's plenty. If we were using the GLIBC2, we'd need one full-time lawyer, one full-time RMS-ass-kisser, and then a handful of developers to keep up with patches. Do you see the light?

Let's perform some more GLIBC2 vs. BSD libc comparisons:

[greg@linux] ~$ gcc -static -o hello hello.c; strip hello
[greg@linux] ~$ du -sk hello
416     hello
compared to:
[greg@freebsd] ~$ gcc -static -o hello hello.c; strip hello
[greg@freebsd] ~$ du -sk hello
44      hello
Yeah, that's right, when statically linked GLIBC2's printf() and support routines are about 10x as big as BSD's. We're on computers, a 15% improvement is considered worth looking at so you can copy their techniques. An "order of magnitude" is 2x. You simply aren't expecting 10x differences between extremely simple code that hasn't advanced, technologically, in more than two decades.

Let's get to the core issue here. BSD developers are sane, down to earth, sort of developers. So are most Linux developers. But the FSF is entirely a bunch of assclowns with a grand vision and heads so big that it's a wonder they've managed to get them so far up their asses. Think about it, BSD people are obviously all insane because BSD has splintered so many times, right? I mean, look at Theo, right? Now let me introduce RMS into the picture. Suddenly, Theo looks like an easy going kind of guy. You can do this in any field really. Look at politics, Dubya is just a little bit insane and frothing at the mouth right? I mean, he's in a position where being insane could start WWIII, and he's certainly not putting on the brakes. Now put him in a room with RMS. Wow, Dubya just turned moderate! Cooperation with RMS is impossible, it's either his way or the right way, and this developer has had it.

Time for one less shitpile in the Linux world: I christen thee BSD/Linux.

[update 2017/02/09: The world has spoken, being forever mired in suckitude has won.]