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

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 0:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Shmerl is aware of my technical objections.

I think that glibc (and generally all libcs) are designed by a band of idiots that should not be allowed EVER to come close to a computing device.

For example, glibc requires a metric ton of additional stuff like locales and timezones. And all this shit can't even be used! For example:
1) There's no way to get the next time for DST transition. Too complex? I can do this just fine in .NET.
2) There's no way to simply get the time in another timezone without modifying a hidden global variable!
3) Ditto for localization - it only works to make regexes like [A-Z] fail in Estonian locale (because Z is not the last letter in Estonian alphabet). But normalizing a string for a given locale without modifying a global variable? No can do.
4) There's dependency on NSS that makes it impossible to install glibc without raping the whole OS. And what for? Only to make a couple functions like getpwent() work. And of course, this functionality is insufficient for a lot of real-world tasks, like searching a list of by a prefix. Do you see a pattern here?

uclibc and bionic made the right decision - to jettison all that crap and instead build a lean and mean libc.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 0:49 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>like searching a list of by a prefix
Correction: "like searching a list of users in a huge LDAP directory by a prefix".

glibc

Posted Dec 30, 2012 7:57 UTC (Sun) by jrn (subscriber, #64214) [Link]

I'll bite. What does "normalize a string for a given locale" mean? Are you referring to case folding or something?

I think the band of idiots you are referring to is called the POSIX standards committee. Though I like their work and don't consider them to be a band of idiots.

glibc

Posted Dec 30, 2012 8:33 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> I'll bite. What does "normalize a string for a given locale" mean? Are you referring to case folding or something?
For example, convert string to a title case in en_ZA locale while the system locale is es_ES.

> I think the band of idiots you are referring to is called the POSIX standards committee. Though I like their work and don't consider them to be a band of idiots.
Yup. The sheer amount of idiotic decisions in POSIX made it irrelevant long time ago. Almost all real software has to rely on various kinds of extensions.

Oh, by "irrelevant" I mean that POSIX compliance is not even worth the time spent to read POSIX spec.

glibc

Posted Dec 30, 2012 8:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> For example, convert string to a title case in en_ZA locale while the system locale is es_ES.
Or even a better example, convert the string "is this true" to upper case to uppercase in en_US with tr_TR locale. We got hit with this "bug" _several_ time.

The other way around is also hilarious.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 18:54 UTC (Fri) by nix (subscriber, #2304) [Link]

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.

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.