Distributions for the Nexus 7 (TGDaily and HotHardware) [LWN.net]

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 18:54 UTC (Fri) by nix (subscriber, #2304)
In reply to: Distributions for the Nexus 7 (TGDaily and HotHardware) by Cyberax
Parent article: 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? And, in particular, relates to glibc not providing various admittedly useful localization functions?

These functions are not provided for a single simple reason -- they are not required to implement the POSIX API: random extensions really shouldn't be thrown into glibc, because they have to be maintained forever (yes, yes, strfry() shouldn't be there, but it dates from a time when glibc was much younger and development was much wilder -- and now it cannot be removed). The localization databases and the like are required to implement that API (including things like the localization support in printf()). This is doubly true for the timezone stuff which is really there only so that conversions to the local timezone for filesystem stuff works.

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. Surely this leaves you even worse off than glibc does? At least (in the new glibc governance world) these problems are potentially resolvable? 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.

(Log in to post comments)

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 19:53 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>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.