From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 59ab65ca for ; Tue, 18 Feb 2020 19:38:43 +0000 (UTC) Received: (qmail 3674 invoked by uid 550); 18 Feb 2020 19:38:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3642 invoked from network); 18 Feb 2020 19:38:41 -0000 Date: Tue, 18 Feb 2020 19:38:29 +0000 (UTC) From: Jacob Welsh To: musl@lists.openwall.com Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [musl] Locale support considered harmful noise 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: > Unicode 12.1 update and related character handling work > Locale support overhaul. > Hostname resolver support for non-ASCII domains (IDN) > LC_COLLATE support for collation orders other than simple codepoint order > Support for LC_MONETARY and LC_NUMERIC properties. > Message translation support for dynamic linker > Locale data and libc message translations 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. 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. I'll be happy to discuss further here, in my blog comments or on irc [8]. Yours, J. Welsh [1] http://trinque.org/2019/12/29/a-republican-os-part-2/ [2] http://ave1.org/2018/building-gnat-on-musl/ [3] http://therealbitcoin.org/ml/btc-dev/2015-July/000133.html [4] http://trinque.org/2018/11/27/cuntoo-bootstrapper/ [5] http://fixpoint.welshcomputing.com/2019/introducing-gales-linux [6] http://dorion-mode.com/2019/11/jwrd-computing [7] https://wiki.musl-libc.org/roadmap.html [8] #ossasepia or #trilema on freenode; PM me (jfw) or someone talking to ask for voice.