> 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