mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Dmitry Samersoff <dms@samersoff.net>
To: musl@lists.openwall.com, Rich Felker <dalias@libc.org>
Subject: Re: [musl] Advocating musl to in windows subsystem and OS X
Date: Fri, 12 Jun 2020 22:08:26 +0300	[thread overview]
Message-ID: <8d5c1e37-b650-fe70-4dba-05ece843cba1@samersoff.net> (raw)
In-Reply-To: <20200612173747.GD6430@brightrain.aerifal.cx>

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
> 


  parent reply	other threads:[~2020-06-12 19:08 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
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 [this message]
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=8d5c1e37-b650-fe70-4dba-05ece843cba1@samersoff.net \
    --to=dms@samersoff.net \
    --cc=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).