From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30241 invoked from network); 12 Jun 2020 17:38:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Jun 2020 17:38:03 -0000 Received: (qmail 13614 invoked by uid 550); 12 Jun 2020 17:38:00 -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 13596 invoked from network); 12 Jun 2020 17:37:59 -0000 Date: Fri, 12 Jun 2020 13:37:47 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200612173747.GD6430@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Advocating musl to in windows subsystem and OS X On Fri, Jun 12, 2020 at 06:56:28PM +0200, Brian Peregrine wrote: > Hey all, > > after thinking about my previous post (Advocating musl to the chromium > OS developers ), it struck me that both Microsoft and Apple use some > sort of libc too (Microsoft has the "subsystem for linux" on windows > 10 now, and Apple's OS X is based on linux too -I think it was based > on the "Darwin" linux distro. No, OSX is in some sense a BSD fork, but with major architectural changes, and has nothing to do with Linux. Their libc is a BSD one (FreeBSD I think) with tons of gratuitous changes made that did little but intentionally break things, basically for NIH purposes/justifying the existence of the project. (This is much like Google's Fuchsia fork of musl.) musl does not run on OSX and while all of the pure-library code and stdio code could in principle be used, actually making "musl for OSX" would be a large project that doesn't make sense. What would make much more sense is either reusing code or making corresponding improvements based on things that are better in musl. > Microsoft probably uses glibc (as the subsystem seems to be > canonical-made and they use glibc in ubuntu), for os x, I'm not sure > what is being used. > See https://itsfoss.com/install-bash-on-windows/ > https://www.makeuseof.com/tag/microsoft-linux-distros-windows-10/ > https://news.ycombinator.com/item?id=3601092 > > In either case, Rich, perhaps you can propose to both that they use > musl, In some sense WSL doesn't "use" any libc; it's a thin syscall emulation layer (WSL1) or near-full-linux-vm (WSL2) that's supposed to be able to run any Linux userspace. My understanding is that they ship some glibc-based distro, and I don't see that being viable for them to change because they're supporting whatever users have built on it, but anyone's free to use whatever they prefer. On a higher level, I don't really want anyone shipping musl in places where the end user who receives it doesn't intend to use musl, for much the same reason that I don't like it when distros ship systemd to folks who don't intend to use systemd. It leads to gratuitous complaints from people who are unhappy that it's different from what they expect, and keep asking for changes to make it more glibc-like. I'd much rather seek out a user base that *wants* what's different about musl rather than "puts up with" what's different about musl. > and point them to your comparison > (http://www.etalabs.net/compare_libcs.html ) ? > Also, perhaps that comparison can have Bionic added too and compared > to that as well ? The comparison is really out-of-date, and needs some serious methodological overhaul. Some of the points are quantitative and need to be pegged to particular versions to be relevant, and need a way of testing all the libcs with the same hardware/kernel to be able to update them at all. All of that is beyond the scope of anything I want to do right now, but I'd be interested in helping someone else who wants to continue it setup a procedure and revamped test cases. The qualitative parts are fairly easy to keep up-to-date though, and Bionic and others could probably be added there. I don't think it makes sense to include non-Linux libc's, though, since they can't be used interchangibly -- they're not options you have. > Perhaps it's most appropriate to do this through posting an issue at > their relevant repo's (for MS, it's > https://github.com/microsoft/WSL2-Linux-Kernel/issues , for apple > (https://github.com/apple ), I'm not sure which repo holds the libc. Unfortunately WSL1 has been broken and can't safely run musl binaries since forever, and it's apparently not getting fixed despite the fix being a one-liner if you had the source: https://github.com/microsoft/WSL/issues/830 I'm not sure if WSL1 is still an option, but in some sense it "should be" because it's lighter and cleaner than WSL2 which was basically just "let's give up and use a VM with a real Linux kernel". If WSL1 ceases to be a thing, using musl on WSL becomes more attractive. I re-pinged the issue to find out what's up. Rich