Note that sometimes (/often) this purely due to the allocator, and as far as I remember Chimera uses a different allocator than the stock musl one.

Yet I can't find many benchmarks.

Frustratingly, it's listed here, but not actually included in the results: https://github.com/daanx/mimalloc-bench Might be fun trying to run the benchmarks myself.

that said, scudo is highly configurable, and the performance reflects the configuration (you can even swap out the primary allocator, secondary cache, you can tune all the parameters, the TSD registry implementation has a big impact on multithreaded code, etc.), so it's not 100% representative - chimera's current configuration is further tweaked for both better performance and lower memory usage

scudo being this configurable is excellent because it is what enables such integration in the first place (other allocators e.g. frequently rely on ELF TLS, i.e. __thread and the likes, which would make libc integration very difficult and would require major changes to the dynamic linker, with scudo we instead implement a custom TSD registry and simply shove an extra pointer in the pthread structure)

What’s actually amazing about chimera is the musl + clang/llvm/compiler-rt combination. It allows you to do all kinds of amazing things easily from a programming perspective.

The apk 3 package manager, build system (cbuild) is also excellent. Everything feels modern and clean. Package availability is still limited and you would probably need to compile many of your favourite packages from source but I would still highly recommend this distribution.

Any examples?

As such, I have stuck with GCC which requires much less space.

Is this any different on Chimera.

I have 2TB of internal SSD storage on my laptop, and I can buy extra TB's for $50 each.

Why on earth would I balk at 100MB?

Some webpages serve half of that in optimized images for crying out loud, lol.

Similarly we should persist with musl. It’s infinitely cleaner, simpler and understandable.

I am in favor of standardizing the behavior of libc and having multiple implementations that are commonly used.

There are also many other POSIX ( UNIX-like ) operating systems such as FreeBSD and OpenBSD which have their own.

Redox has a Rust-based C library called Relibc that even works on Linux.

There are also other C libraries that work on Linux such as dietLibc and of course Bionic, which is the standard C library on Android.

The problem is not the lack of a standard, it is that Glibc does not follow the standard and is itself the de facto choice for desktop Linux. Applications that assume Glibc may not work on other implementations ( like MUSL ).

That's incorrect Glibc does follow the relevant standards, you can simply restrict yourself to only use POSIX and C11, it's just that program authors find the glibc-extensions convenient enough to use them over just the bare standard.

That said, some of the other libraries don't even claim to support the relevant standards, e.g. Bionic is not even fully POSIX compliant. So an application that assumes MUSL (which btw, also implements glibc, BSD and Linux extensions), can't use Bionic as a drop in replacement (not sure about Relibc).

To note that this is only became a thing when the Universal C Runtime was introduced in Windows 10, until then is was pretty much "Every C compiler provides their own", which was the common approach on non-UNIX systems.

There is already a standard you need to adhere to. It lives one level lower and is the Linux userland-kernel interface i.e the syscall interface.

i think you overstate how much trouble it is to port software to it; most software does not involve any porting in the first place, upstreams are not that reluctant, and as for firefox having a specific crash, have you reported it?

slowness is typically a default allocator issue and that does not apply to us (in fact, it may sometimes be faster)

> musl is just a mandatory choice [due to the toolchain]

interesting; i didn't realise that.

> most software does not involve any porting in the first place, upstreams are not that reluctant

perhaps; it seems to me that the majority of patches in alpine's aports (otherwise a rather vanilla distribution) are fixing glibc assumptions.

> as for firefox having a specific crash, have you reported it?

as i understand it, mozilla wouldn't accept a musl-specific bug report; and neither the old nor new alpine firefox maintainers were able to reproduce these two crashes, weirdly enough, so i gave up and started using the upstream build, hence using this as an example of a musl (or non-bog-standard-gnu-tooclhain at any rate; at least one of these crashes seem to be on a c++/rust boundary) annoyance.

> slowness is typically a default allocator issue and that does not apply to us

i didn't know about your using a different allocator either. i'll investigate.

to end on a more positive note, from the end-user point of view there are also some joys to having an incompatible userland: in principle, not being able to natively run upstream builds prepares me for when i decide to jump ship to e.g. arm or riscv.

i had a few nice 'aha' moments: i switched to a different music streaming service because the old one wanted widevine which wouldn't work in a musl build of firefox; a random electron app i downloaded, unpacked and ran with distribution-provided electron (assuming it's just a bunch of html and javascript) didn't work because it shipped, amid other resources, shared libraries (with filenames helpfully ending in '.node').

you said chimera's builds are affected by this, which means you've presumably tested it there; i see no bug report about it in cports either though