mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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 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 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 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&amp;data=02%7C01%7CJohn.
> Starks%40microsoft.com%7C127a8ed7d301497f35ac08d811842654%7C72f98
> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637278606562798960&amp;s
> data=LjbyFJNdCzh%2BX7Z5HK8dFyc5whcSYU4YS1AW3NsLy4Y%3D&amp;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).