On 18/02/2020 13:38, Jacob Welsh wrote:
> Hello,
> 
> In TMSR we've made extensive use of musl, due to the very welcome dose
> of clear and concise code it provides as compared to the competition
> [1]. For example we have a static Ada compiler [2], the Bitcoin
> reference implementation [3], a reproducible and self-contained Gentoo
> system [4], and not least of all my own distribution [5] used in my
> consulting business [6].
> 
> However, the apparent goal of aggressive expansion of Unicode and
> localization "features" in musl sets off alarms; for instance, on the
> roadmap [7] I see:


Why do you not believe that musl could provide any of these features
using clear and concise code?


>> Unicode 12.1 update and related character handling work


This is necessary for actual real-world users that need to use the
symbols added since the last Unicode update.

For example, Unicode 12.1 added the symbol for the new Japanese era,
Reiwa Era.  You will be unable to represent current dates in the
Japanese calendar without this update.


>> Locale support overhaul.


Also very important for real-world users that wish to use languages
besides English to communicate with their computer.


>> Hostname resolver support for non-ASCII domains (IDN)


IDN domains are gaining significant traction, especially in Asia and the
Middle East.


>> LC_COLLATE support for collation orders other than simple codepoint order


I have been personally impacted by the lack of LC_COLLATE support.


>> Support for LC_MONETARY and LC_NUMERIC properties.


This is necessary for a better desktop experience; especially LC_NUMERIC
is egregious since many cultures/countries utilise , as the decimal
separator.


>> Message translation support for dynamic linker


This will allow non-English speakers the ability to understand the
errors that are happening on the computers they own.


>> Locale data and libc message translations


This is somewhat already possible with
https://github.com/rilian-la-te/musl-locales - it would basically just
be upstreaming the translation files into musl proper (to ensure they
are kept up-to-date) and adding messages that are not already translated.


> We think this is such a bad idea that it threatens to undermine musl's
> otherwise substantial virtues. This kind of bloat imposes real costs on
> the users that matter - namely the literate ones, who value predictable,
> stable and bug-free code - in exchange for entirely unclear benefits.


No one user matters more than another.  musl's own self-description is:

"musl is lightweight, fast, simple, free, and strives to be correct in
the sense of standards-conformance and safety."

Locale support can be lightweight, fast, simple, free, and correct.  In
fact, musl is *not* conformant to the POSIX standard *because* it does
not implement the requisite locale support.

The benefits are the ability for people in non-English speaking cultures
and countries to be able to use systems based on musl instead of being
stuck with inferior alternatives.

Anglocentrism has no place in Libre software.


> Especially considering the rate at which bugs are still turning up,
> there is no justification for this added complexity. In any event we
> will not be using "upgrades" that import additional nonsense into this
> critical system component.

There is absolutely justification for these features: Wolfram Alpha[1]
quotes the number of English speakers to be approximately 11% of the
world population.

That means 89% of living people on Earth cannot currently fully utilise
musl-based systems the way they could if it was possible to support
non-English languages.  Adding better locale support will fix this.


--arw


[1]: https://www.wolframalpha.com/input/?i=number+of+english+speakers

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org