Date: Tue, 18 Feb 2020 15:42:26 -0600 From: "A. Wilcox" <awilfox@...lielinux.org> To: musl@...ts.openwall.com Subject: Re: Locale support considered harmful noise 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 > . For example we have a static Ada compiler , the Bitcoin > reference implementation , a reproducible and self-contained Gentoo > system , and not least of all my own distribution  used in my > consulting business . > > However, the apparent goal of aggressive expansion of Unicode and > localization "features" in musl sets off alarms; for instance, on the > roadmap  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 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 : https://www.wolframalpha.com/input/?i=number+of+english+speakers -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.