| thank you for your work on chimera! > 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