
Musl-libc version 1.0.0 released - deoxxa
http://www.musl-libc.org/download.html
======
justincormack
I have been using Musl for various purposes for quite some time. I think my
favourite things are:

* The team are very helpful, and fix things fast and correctly. You can see some of the detail in this post on race conditions in glibc [http://ewontfix.com/16/](http://ewontfix.com/16/)

* It is very standards compliant, so it is a good portability test for your code. It is a bit like using a BSD libc, except it does have Linux specific syscalls etc.

* Static linking works, which it doesnt properly in glibc. If you want to be like those trendy Go people and provide simple statically linked single file binaries, for running in containers etc then you can. And they will be small: the glibc shared library is 1.8MB (not including rt, pthread etc), while a Musl statically linked copy of Lua for example is only 160k. Static linking is very useful for all sorts of things, my most recent use was cross compiling bianries to run under qemu-user for testing.

* It is BSD licensed so you can use it in completely different projects however you want, eg OSv uses it [http://osv.io/](http://osv.io/)

* The code is small and readable. If you want to know how things work you can just take a look, quickly find the code and understand it. Just finding the code in glibc takes ages. I keep a reference copy just for this purpose.

You can use the "cross compiler" musl-gcc that ships with it to build if your
code is happy being cross compiled (should be, most things just work). If you
have a lot of dependencies it might be easier to use a distro, I use Sabotage
in a chroot usually [https://github.com/sabotage-
linux/sabotage](https://github.com/sabotage-linux/sabotage)

~~~
pascal_cuoq
Not to offend any secondary Musl contributor, but I think that your first
favorite thing is all the more impressive that “The team” is essentially one
person.

~~~
dalias
It started out that way, but these days we have several other developers who
are pretty active. You can see from our stats on ohloh:
[https://www.ohloh.net/p/musl/contributors?query=&sort=commit...](https://www.ohloh.net/p/musl/contributors?query=&sort=commits)

Also, without the work of the entire community testing and reporting issues
getting various packages to work with musl, it would have taken forever to get
this far. Testers and bug reporters are seriously under-appreciated!

------
dalias
Hi all. I'm the original author and maintainer of musl, and I'm happy to
answer any questions anyone might have about the project. Glad to see so much
interest!

~~~
hkphooey
Did you raise issues with the glibc team and submit patches etc... before
deciding to create your own project?

~~~
dalias
At the time the project was started, Ulrich Drepper was the maintainer of
glibc and the official response to any bug report was "STFU". So, no.

Aside from that, while a more permissive license was not part of my original
goal or vision for musl, it's something that could never have happened by
working on improving glibc. Right now we're facing a situation where Linux has
been fragmented into a "GNU/Linux" minority made up of hackers' desktop PCs
and enterprise servers, and an overwhelming Android majority. The latter is
using a grotesquely incompatible, poorly designed, non-standards-conforming
libc called Bionic, and if you want to run existing C programs on Android, you
have to add heaps of #ifdef hackery to them to make them compatible with
Bionic (much like the #ifdef hackery needed to make C programs work on
Windows).

musl can provide a real, standards-conforming libc for use on Android that's
still light and MIT-licensed (important because Open Handset Alliance members
have a contractual obligation to Google not to add copyleft code to the system
they distribute). This means, in theory, we can do away with the whole #ifdef
mess and just run existing, portable software on Android. In short, it has the
potential to free FOSS projects from getting bogged down in the maintenance
burden of supporting yet another gratuitously-incompatible system (Android) in
order to remain relevant.

~~~
shaurz
I would really like Android to switch over to Musl and drop Bionic, and
eventually also drop SurfaceFlinger for Wayland and use an upstream kernel. I
can dream...

------
dalias
A special treat to go with the release, that's not linked on the website yet:
in-browser demo setup using jslinux: [http://www.musl-
libc.org/jslinux/](http://www.musl-libc.org/jslinux/)

~~~
justincormack
Cool, I have never run a C compiler in JavaScript before...

------
nathell
Any Linux distro built against musl out there?

~~~
dalias
Yet, there are quite a few. See the wiki: [http://wiki.musl-
libc.org/wiki/Projects_using_musl](http://wiki.musl-
libc.org/wiki/Projects_using_musl)

A few big names are in the process of adding musl-based variants or switching
entirely to musl, but most of these are still experimental. Alpine hopes to
finish switching over sometime this year. Aboriginal Linux too. Bedrock Linux
is already using musl in their latest release, but due to the way their distro
works, they're in the unique situation where they don't have to build a lot of
packages against the system libc, so they have it much easier.

------
justincormack
There is a very minimal Docker build with Musl showing how it can be usd to
build a minimal container
[https://github.com/mwcampbell/vontainrr](https://github.com/mwcampbell/vontainrr)

~~~
agumonkey
I get a 404. Maybe this [https://github.com/mwcampbell/docker-
muslbase](https://github.com/mwcampbell/docker-muslbase) ?

~~~
justincormack
Yes that's the one.. Android paste...

~~~
NicoJuicy
So you are saying that there is a bug in the Android copy-paste? :-)

(even though the 2 links are completely different)

~~~
justincormack
I think the bug is in my fingers

------
Zen101
Interesting, great update

------
jokoon
wait, but I thought premature optimization was evil !

~~~
dalias
musl actually has very little in the way of optimization, premature or
otherwise. Most functions are written to be as simple and direct as possible.
Often but not always this gives near-optimal size and speed too. The places
where more complex approaches are used are _mostly_ situations where the naive
solution would have corner cases that fail or corner cases that have
pathologically bad performance and could be used as a DoS attack vector. The
main exception is things like memcpy, memset, etc.; if they're slow, people
are generally very unhappy.

BTW, one difficulty in libc is that it's hard to know what optimizations are
"premature" because you can't envision everybody's usage cases without an
enormous volume of experience with third-party code.

~~~
jokoon
Isn't this implementation targeting embedded platforms ? I read it's reducing
its memory footprint by using static linking...

