Re: [musl] Advocating musl to in windows subsystem and OS X

[Szabolcs Nagy <nsz@port70.net>]

* Ariadne Conill <ariadne@dereferenced.org> [2020-06-12 13:25:34 -0600]:
> On Friday, June 12, 2020 1:05:02 PM MDT Luca Barbato wrote:
> > On 12/06/2020 19:37, Rich Felker wrote:
> > > 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.
> > 
> > https://www.microsoft.com/en-us/p/alpine-wsl/9p804crf0395#activetab=pivot:ov
> > erviewtab
> > 
> > This seems available.
> 
> It is also not supported at all by Alpine team itself, and apk-tools 3 will 
> break with WSL1 due to the way the new database code uses mmap access.
> 
> In other words, if it breaks, you get to keep both pieces.

glibc tests don't pass cleanly either on wsl.

wsl does not emulate linux syscalls perfectly
so nobody should expect reliable behaviour
using whatever linux userspace on top of it.