6 ms·

i really like a lot of design choices in chimera linux (particularly around its packaging/build system), but as a current alpine linux (main pc, not docker) use

by 5- 3y ago

i really like a lot of design choices in chimera linux (particularly around its packaging/build system), but as a current alpine linux (main pc, not docker) user, i find i still can't justify musl. i like small simple correct software, but musl, despite being all of those things, is, in my experience - slower than glibc, and in occasionally difficult to predict spots; - causes just a bit too much trouble porting software to it -- most upstreams are reluctant to accept patches, resulting in maintenance overhead for the distribution; - occasionally subtly breaks things at runtime -- e.g. both alpine and chimera builds of firefox have the same two crashes which neither the official mozilla nor archlinux builds exhibit. in the end i find i have to rely on my glibc chroot (e.g. for mozilla firefox build) too much for my liking.

freedomben 3y ago
This has been my experience with alpine as well. musl just ends up causing much more trouble than it is worth
- sidkshatriya 3y ago
  For the longest time using anything but gcc was a problem. But people found clang/llvm better in many respects and persisted. Today clang/llvm is a drop in option, even to compile the Linux kernel. Similarly we should persist with musl. It’s infinitely cleaner, simpler and understandable.
  - musicale 3y ago
    As you imply, it's not really a standard unless there are multiple implementations. I am in favor of standardizing the behavior of libc and having multiple implementations that are commonly used.
    - LeFantome 3y ago
      There are many, many implementations of the C standard library. Every OS has one—even Windows. 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 ).
      - cycomanic 3y ago
        > 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).
      - pjmlp 3y ago
        > Every OS has one—even Windows 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.
    - sidkshatriya 3y ago
      I think we should not standardise lunch on Linux. Firstly it will create a lot of acrimony as different people may have opinions. 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.
      - rofrol 3y ago
        lunch and breakfast also
NewJazz 3y ago
[musl is] slower than glibc, and in occasionally difficult to predict spots 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.
- celrod 3y ago
  Chimera uses the scudo allocator, which is Ajay also the default on Android and Fuscia. 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 https://github.com/daanx/mimalloc-bench Might be fun trying to run the benchmarks myself.
  - q66 3y ago
    i ran that when doing the initial porting: https://gist.github.com/q66/84288d3b8e70146a630f65dc1de4b683 https://gist.github.com/q66/84288d3b8e70146a630f65dc1de4b683 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)
- q66 3y ago
  in most applications where it matters, it actually tends to be the allocator; you'll find that especially interactive applications (e.g. browsers) tend to feel significantly more responsive in chimera than in alpine, as well as other things (e.g. LTO link times with lld take a third of the time)
- sidkshatriya 3y ago
  Happy chimera user here. It feels fast in regular usage though I use ssh much more than desktop. 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.
deleted 3y ago
[deleted]
j4ah4n 3y ago
Off topic, but would you have any suggestion or resources to start using alpine on a main pc? I have a System 76 machine I wouldn’t mind trying this out with.
- NewJazz 3y ago
  Their homepage is pretty straightforward. As is the setup-alpine installer.
- prmoustache 3y ago
  https://dataswamp.org/~solene/2023-04-30-alpine-as-desktop-cheatsheet.html https://dataswamp.org/~solene/2023-04-30-alpine-as-desktop-c...
q66 3y ago
musl is just a mandatory choice; the toolchain configuration doesn't really allow running anything else (glibc doesn't go together with clang+compiler-rt, they only very recently made it build with clang and that's still assuming a gcc-centric runtime as glibc actually dlopens libgcc_s, and every other libc is going to be much worse in terms of support) 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)
- 5- 3y ago
  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').
  - q66 3y ago
rahen 3y ago
Besides Chimera, you may be interested in trying Void Linux also.

by 5- 3y ago

freedomben 3y ago

This has been my experience with alpine as well. musl just ends up causing much more trouble than it is worth

sidkshatriya 3y ago
For the longest time using anything but gcc was a problem. But people found clang/llvm better in many respects and persisted. Today clang/llvm is a drop in option, even to compile the Linux kernel. Similarly we should persist with musl. It’s infinitely cleaner, simpler and understandable.
- musicale 3y ago
  As you imply, it's not really a standard unless there are multiple implementations. I am in favor of standardizing the behavior of libc and having multiple implementations that are commonly used.
  - LeFantome 3y ago
    There are many, many implementations of the C standard library. Every OS has one—even Windows. 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 ).
    - cycomanic 3y ago
      > 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).
    - pjmlp 3y ago
      > Every OS has one—even Windows 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.
  - sidkshatriya 3y ago
    I think we should not standardise lunch on Linux. Firstly it will create a lot of acrimony as different people may have opinions. 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.
    - rofrol 3y ago
      lunch and breakfast also

NewJazz 3y ago

[musl is] slower than glibc, and in occasionally difficult to predict spots 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.

celrod 3y ago
Chimera uses the scudo allocator, which is Ajay also the default on Android and Fuscia. 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 https://github.com/daanx/mimalloc-bench Might be fun trying to run the benchmarks myself.
- q66 3y ago
  i ran that when doing the initial porting: https://gist.github.com/q66/84288d3b8e70146a630f65dc1de4b683 https://gist.github.com/q66/84288d3b8e70146a630f65dc1de4b683 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)
q66 3y ago
in most applications where it matters, it actually tends to be the allocator; you'll find that especially interactive applications (e.g. browsers) tend to feel significantly more responsive in chimera than in alpine, as well as other things (e.g. LTO link times with lld take a third of the time)
sidkshatriya 3y ago
Happy chimera user here. It feels fast in regular usage though I use ssh much more than desktop. 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.

deleted 3y ago

[deleted]

j4ah4n 3y ago

Off topic, but would you have any suggestion or resources to start using alpine on a main pc? I have a System 76 machine I wouldn’t mind trying this out with.

NewJazz 3y ago
Their homepage is pretty straightforward. As is the setup-alpine installer.
prmoustache 3y ago
https://dataswamp.org/~solene/2023-04-30-alpine-as-desktop-cheatsheet.html https://dataswamp.org/~solene/2023-04-30-alpine-as-desktop-c...

q66 3y ago

musl is just a mandatory choice; the toolchain configuration doesn't really allow running anything else (glibc doesn't go together with clang+compiler-rt, they only very recently made it build with clang and that's still assuming a gcc-centric runtime as glibc actually dlopens libgcc_s, and every other libc is going to be much worse in terms of support) 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)

5- 3y ago
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').
- q66 3y ago

rahen 3y ago

Besides Chimera, you may be interested in trying Void Linux also.