* [musl] Advocating musl to in windows subsystem and OS X @ 2020-06-12 16:56 Brian Peregrine 2020-06-12 17:37 ` Rich Felker ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Brian Peregrine @ 2020-06-12 16:56 UTC (permalink / raw) To: musl 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. 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, 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 ? 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. Brian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-12 16:56 [musl] Advocating musl to in windows subsystem and OS X Brian Peregrine @ 2020-06-12 17:37 ` Rich Felker 2020-06-12 19:05 ` Luca Barbato 2020-06-12 19:08 ` Dmitry Samersoff 2020-06-14 19:17 ` Markus Wichmann 2020-06-15 23:59 ` Jeffrey Walton 2 siblings, 2 replies; 12+ messages in thread From: Rich Felker @ 2020-06-12 17:37 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-12 17:37 ` Rich Felker @ 2020-06-12 19:05 ` Luca Barbato 2020-06-12 19:25 ` Ariadne Conill 2020-06-12 19:08 ` Dmitry Samersoff 1 sibling, 1 reply; 12+ messages in thread From: Luca Barbato @ 2020-06-12 19:05 UTC (permalink / raw) To: musl On 12/06/2020 19:37, Rich Felker wrote: > 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. https://www.microsoft.com/en-us/p/alpine-wsl/9p804crf0395#activetab=pivot:overviewtab This seems available. lu ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-12 19:05 ` Luca Barbato @ 2020-06-12 19:25 ` Ariadne Conill 2020-06-12 19:38 ` Szabolcs Nagy 0 siblings, 1 reply; 12+ messages in thread From: Ariadne Conill @ 2020-06-12 19:25 UTC (permalink / raw) To: musl On Friday, June 12, 2020 1:05:02 PM MDT Luca Barbato wrote: > On 12/06/2020 19:37, Rich Felker wrote: > > 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. > > 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. Ariadne ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-12 19:25 ` Ariadne Conill @ 2020-06-12 19:38 ` Szabolcs Nagy 0 siblings, 0 replies; 12+ messages in thread From: Szabolcs Nagy @ 2020-06-12 19:38 UTC (permalink / raw) To: Ariadne Conill; +Cc: musl * 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-12 17:37 ` Rich Felker 2020-06-12 19:05 ` Luca Barbato @ 2020-06-12 19:08 ` Dmitry Samersoff 2020-06-12 19:24 ` Ariadne Conill 1 sibling, 1 reply; 12+ messages in thread From: Dmitry Samersoff @ 2020-06-12 19:08 UTC (permalink / raw) To: musl, Rich Felker Hello Rich, One thing that might make sense - is to compare performance and resource consumption of OpenBSD and Musl based Linux distro (e.g. Alpine) because both targets the same audience. -Dmitry On 12.06.2020 20:37, Rich Felker wrote: > 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-12 19:08 ` Dmitry Samersoff @ 2020-06-12 19:24 ` Ariadne Conill 0 siblings, 0 replies; 12+ messages in thread From: Ariadne Conill @ 2020-06-12 19:24 UTC (permalink / raw) To: musl Hello, On Friday, June 12, 2020 1:08:26 PM MDT Dmitry Samersoff wrote: > Hello Rich, > > One thing that might make sense - is to compare performance and resource > consumption of OpenBSD and Musl based Linux distro (e.g. Alpine) because > both targets the same audience. I don't think Alpine or other apk-based distributions like Adelie are appropriate for such a comparison. While it is true that we consume musl, we layer other things (for example, libucontext, GNU libiconv, GNU libintl) on top of it to fill in the gaps. Accordingly, on Alpine you don't get a "pure" musl experience as you would with, say, sabotage. Ariadne ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-12 16:56 [musl] Advocating musl to in windows subsystem and OS X Brian Peregrine 2020-06-12 17:37 ` Rich Felker @ 2020-06-14 19:17 ` Markus Wichmann 2020-06-14 20:43 ` [musl] RE: [EXTERNAL] " John Starks 2020-06-15 23:59 ` Jeffrey Walton 2 siblings, 1 reply; 12+ messages in thread From: Markus Wichmann @ 2020-06-14 19:17 UTC (permalink / raw) To: musl On Fri, Jun 12, 2020 at 06:56:28PM +0200, Brian Peregrine wrote: > Microsoft probably uses glibc (as the subsystem seems to be > canonical-made and they use glibc in ubuntu), The distribution you install is just a collection of the exact binaries you would get in a normal install. Therefore it is the distribution itself which has a libc, and whether that is glibc, musl, or dietlibc (just to name an utterly outlandish option) is up to the distribution. However, there is one additional file installed, called /init, which is also the root of the emulated process tree. And that file is statically linked against musl (as you can tell by running "strings" on it). It apparently generates a couple of files from Windows' current system settings (like /etc/resolv.conf). Ciao, Markus ^ permalink raw reply [flat|nested] 12+ messages in thread
* [musl] RE: [EXTERNAL] Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-14 19:17 ` Markus Wichmann @ 2020-06-14 20:43 ` John Starks 2020-06-15 23:30 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: John Starks @ 2020-06-14 20:43 UTC (permalink / raw) To: musl > From: Markus Wichmann <nullplan@gmx.net> > On Fri, Jun 12, 2020 at 06:56:28PM +0200, Brian Peregrine wrote: > > Microsoft probably uses glibc (as the subsystem seems to be > > canonical-made and they use glibc in ubuntu), > > The distribution you install is just a collection of the exact binaries you would > get in a normal install. Therefore it is the distribution itself which has a libc, > and whether that is glibc, musl, or dietlibc (just to name an utterly outlandish > option) is up to the distribution. > However, there is one additional file installed, called /init, which is also the > root of the emulated process tree. And that file is statically linked against > musl (as you can tell by running "strings" on it). It apparently generates a > couple of files from Windows' current system settings (like /etc/resolv.conf). Yes, originally we dynamically linked our infrastructure binaries to glibc and relied on the distro to ship it. These days we are happy users of (statically-linked) musl. We additionally try to make sure that musl-based distros such as Alpine work well within WSL. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] RE: [EXTERNAL] Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-14 20:43 ` [musl] RE: [EXTERNAL] " John Starks @ 2020-06-15 23:30 ` Rich Felker 0 siblings, 0 replies; 12+ messages in thread From: Rich Felker @ 2020-06-15 23:30 UTC (permalink / raw) To: John Starks; +Cc: musl On Sun, Jun 14, 2020 at 08:43:35PM +0000, John Starks wrote: > > From: Markus Wichmann <nullplan@gmx.net> > > On Fri, Jun 12, 2020 at 06:56:28PM +0200, Brian Peregrine wrote: > > > Microsoft probably uses glibc (as the subsystem seems to be > > > canonical-made and they use glibc in ubuntu), > > > > The distribution you install is just a collection of the exact binaries you would > > get in a normal install. Therefore it is the distribution itself which has a libc, > > and whether that is glibc, musl, or dietlibc (just to name an utterly outlandish > > option) is up to the distribution. > > However, there is one additional file installed, called /init, which is also the > > root of the emulated process tree. And that file is statically linked against > > musl (as you can tell by running "strings" on it). It apparently generates a > > couple of files from Windows' current system settings (like /etc/resolv.conf). > > Yes, originally we dynamically linked our infrastructure binaries to > glibc and relied on the distro to ship it. These days we are happy > users of (statically-linked) musl. We additionally try to make sure > that musl-based distros such as Alpine work well within WSL. Thanks. Can you fill us in on if WSL1 is still a thing that's supported/in-use? If so is there any chance we could get some action on https://github.com/microsoft/WSL/issues/830 ? Rich ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X 2020-06-12 16:56 [musl] Advocating musl to in windows subsystem and OS X Brian Peregrine 2020-06-12 17:37 ` Rich Felker 2020-06-14 19:17 ` Markus Wichmann @ 2020-06-15 23:59 ` Jeffrey Walton 2 siblings, 0 replies; 12+ messages in thread From: Jeffrey Walton @ 2020-06-15 23:59 UTC (permalink / raw) To: musl On Fri, Jun 12, 2020 at 1:11 PM Brian Peregrine <peregrinebrian@gmail.com> 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. > > 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, 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 ? > > 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. Small nit... I believe OS X is closer to NetBSD than Linux. Or at least the useland tools like sed, awk, grep are anemic like the BSDs. Jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Advocating musl to in windows subsystem and OS X
@ 2020-06-16 0:11 John Starks
0 siblings, 0 replies; 12+ messages in thread
From: John Starks @ 2020-06-16 0:11 UTC (permalink / raw)
To: Rich Felker; +Cc: musl
> From: Rich Felker <dalias@libc.org>
>
> Thanks. Can you fill us in on if WSL1 is still a thing that's supported/in-use? If
> so is there any chance we could get some action on
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fmicrosoft%2FWSL%2Fissues%2F830&data=02%7C01%7CJohn.
> Starks%40microsoft.com%7C127a8ed7d301497f35ac08d811842654%7C72f98
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637278606562798960&s
> data=LjbyFJNdCzh%2BX7Z5HK8dFyc5whcSYU4YS1AW3NsLy4Y%3D&rese
> rved=0 ?
WSL1 is still supported, and we'll continue to ensure commonly used software works. There may be some compatibility issues whose fixes are too expensive/difficult, but I don't immediately see why this is such an issue. Let me see what's holding up a fix.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-06-16 0:12 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-12 16:56 [musl] Advocating musl to in windows subsystem and OS X Brian Peregrine 2020-06-12 17:37 ` Rich Felker 2020-06-12 19:05 ` Luca Barbato 2020-06-12 19:25 ` Ariadne Conill 2020-06-12 19:38 ` Szabolcs Nagy 2020-06-12 19:08 ` Dmitry Samersoff 2020-06-12 19:24 ` Ariadne Conill 2020-06-14 19:17 ` Markus Wichmann 2020-06-14 20:43 ` [musl] RE: [EXTERNAL] " John Starks 2020-06-15 23:30 ` Rich Felker 2020-06-15 23:59 ` Jeffrey Walton 2020-06-16 0:11 John Starks
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).