Distributions for the Nexus 7 (TGDaily and HotHardware)

>So... your entire body of complaints regarding glibc being 'by far the shittiest library in a standard Linux stack' relates to localization?
Also:
1) Inability to use statically linked glibc or bundled glibc.
2) Inability to use latter versions of glibc to create binaries for earlier versions. So I'm forced to install a parallel chrooted system so that my binaries compiled on a recent Ubuntu can be started on RHEL.
3) Fairly slow malloc implementation.
4) Huge size for embedded systems and inability to create a cutdown version.
5) Dependency on runtime-loadable modules (NSS).
...

But yeah, the design of localization and time handling is just an iconic example.

>These functions are not provided for a single simple reason -- they are not required to implement the POSIX API.
And so freaking what? Create a separate 'lib-shitfulled-POSIX-compatible abomination-c' and be done with that. Then continue developing a sane successor.

Most developers don't care about POSIX at all (which is good).

> What mystifies me is that you suggest that this problem is resolved by, uh, using bionic et al, which don't implement *any* of the POSIX-mandated localization stuff *at all* and thus may break real applications that depend on the existence of this support.
Good. Any application that depends on glibc for localization is broken.

>Surely this leaves you even worse off than glibc does?
No, it's actually much better solution. I can bundle bionic (or uClibc) and my favorite localization library along with my application.

> You can't add proper localization to bionic at *all* without adding all the features that glibc already has, then adding more on top of that.
Yes, I realize that glibc can't be modularized at this point. But it can at least be made _useful_ by including obvious extension functions. They even (gasp!) can later be standardized.

But noooo, POSIX is a sacred cow and everybody should bow down before it.