mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Advocating musl to in windows subsystem and OS X
Date: Fri, 12 Jun 2020 13:37:47 -0400	[thread overview]
Message-ID: <20200612173747.GD6430@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAHCeaGPFbm7c-mrcTScwTEk-=zbBw_K==n3t00q36jn7+a+qow@mail.gmail.com>

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

  reply	other threads:[~2020-06-12 17:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12 16:56 Brian Peregrine
2020-06-12 17:37 ` Rich Felker [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200612173747.GD6430@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).