i still kind of wonder what exactly people have in mind when they complain about chimera/musl compatibility issues, because i rarely see anything really concrete being brought up
one concrete thing people frequently mention is nvidia drivers, but well... consider blaming the proprietary vendor (it's not musl's compatibility that's bad, it's nvidia's) and not the project that can really do little about it
the other thing is proprietary applications, which really is the same story but hurts far less because you can usually just containerize them so in practice you can have almost everything working anyway
the other stuff i've only seen vague claims about, usually coupled with "but the repos are so tiny" (which uh, yeah they are not debian sized but there's like, every major desktop, most major foss programs, and lots of smaller things in there, what else do you want? are you gonna wait until your more niche packages magically appear in there? because that's not gonna happen without someone actually doing it)
in general if it's foss it can be made to work natively nearly always, but we're not building a product here, people are expected to do their part
@q66 i have like one amd gpu here and it would appear there's a mosfet shot on it :/ (i can probably unfuck it, but lack parts...)
but i also have nvidia 960 and 1050... nouveau does vulkan on those, at least.
@ozzelot i have no amd gpus in use right now
(but no nvidia because i mostly use intel ones)
@q66 i'm currently running arch with proprietary drivers (on a gaymink laptop no less) but am chimera-curious
@q66 i wanted to use corectrl or something similar for my amd gpu on chimera but i keep hitting roadblocks :(
cant compile from source (no clue if the problem is on me there because i dont usually compile stuff), cant install the nix package manager to get the nix package of that (i think the error was related to it not finding sudo? i couldnt manage to make a systemwide alias of doas as sudo to fix that, which is probably also my bad, to be fair-), and a flatpak of a similar program to corectrl can read stats of the gpu, but cant apply anything because it fails to install a service, and messing around with flatseal permissions didnt help
for some reason, the gpu speed seems to already come locked at the lowest speed anyway? that does solve the issue on my old backup laptops where i dont need gpu performance, as they are just meant to run syncthing anyway, and i wanted to do that to lower temperatures. But sadly, i cant move my main laptop and pc to chimera like this
i hope i eventually find a workaround that works or someone with more technical knowledge adds corectrl to the repos, because i really wanna use this distro on my main pc 
@q66 wait, i tried the flatpak of that, but for some reason i didnt think of looking if it's in the repo
im gonna try that, thanks for telling me!!!
@Sorro https://github.com/chimera-linux/cports/commit/d739ce782db2cc556a3bb37b8cbba363cdc433c3 this wasn't very difficult regardless, so you can try that too
@q66 lact from the repos seems to complain saying "permission denied" when i try to apply a change, but corectrl works perfectly, so thats good enough for me
thanks for adding it!!
@q66 i tried enabling lact, lact.service, lact-service, LACT, lact-dinit
it couldnt find any service with any of those names, and dinitctl list only lists running services, so im not sure how to look for the correct name
@q66 well, either i looked at the wrong part of the source code (im not a developer), or the code doesnt work 
@q66 this is speculative but musl still doesn't really support locales, right? that could be a serious problem for anyone who isn't a native speaker of english
or then again it might not, it's not clear to me how much that stuff actually gets _used_ anymore
@zwol locales are not localization, translations work out of the box (for any language) and as far as actual locale bits go, rudimentary support for various locale facets (eg date formatting) is present in chimera out of the box for a bunch of languages
(minor stuff like decimal point vs comma and monetary format is not supported rn though)
@Haijo7 if it's precompiled, why do the dependencies matter? (such binary would come built for glibc right)
if it's open source you can probably rebuild them
i do wonder which dependencies those are
@q66 That sounds promising. How about input methods, though? Crucial for East Asian languages, desirable for many others, and also an important piece of the accessibility story.
I'm told there are a lot of them that only work with one specific desktop environment and naturally there's not a lot you can do about that.
@zwol that's going off on a tangent, isn't it? this has nothing to do with locales at all, and isn't any different from any other distribution
there's ibus and there's fcitx5 and chimera isn't any worse than anything else at having them...
@q66 no, I honestly don't know if those work on top of musl
@zwol why wouldn't they? you could ask this about any software
https://pkgs.chimera-linux.org/packages?name=ibus*&arch=x86_64&origin=
https://pkgs.chimera-linux.org/packages?name=fcitx*&arch=x86_64
@q66 what it comes right down to for me, tbh, is I don't trust rich felker not to decide to refuse to implement some API that an entire tranche of stuff depends on
this would be entirely a me problem, except that I have a feeling I'm not the only one who reacted this way to reading through musl's docs
@zwol such apis that a large bunch of stuff relies on don't just magically appear and presumably we have certain standards that libraries follow
i'm far from a fan of rich felker, i think he sometimes makes stuff intentionally obtuse to stick it to people whose code doesn't conform to his ideas of perfection, i dislike the way musl (doesn't) handle patches, i dislike that chimera has to patch in a different memory allocator into the libc because musl doesn't recognize the poor performance of the default as a problem, and that's not all of it, but also it's the only actually viable choice regardless
@q66 does Chimera get many reports of (desktop) stuff breaking due to musl's default stack size, which is much smaller than glibc's?
@federicomena no, musl uses the PT_GNU_STACK header of the executable and any startup-time DSO and uses the largest value as the default stack size, and the typical offenders are compiled with something like `-Wl,-z,stack-size=0x200000` (eg pixman, so pretty much almost any graphical app implicitly defaults to 2M) so you rarely run into such things
and this only applies to extra threads anyway, the main thread gets its stack from the kernel so musl doesn't have much to do with it
@q66 queue.h got me a few times building stuff with musl, but you can just find a suitable queue.h on the net and use it
@q66 yeah, my point was kind of that those offenders need to be found and linked like that, one by one. Librsvg and a bunch of GNOME modules went through that process, and it's annoying to debug :)
@federicomena it hasn't happened in a while (some months) and particularly gnome stuff pretty much implicitly gets elevated stack size no matter what
i still think this tiny stack default is pretty pointless and doesn't in practice help anything but it hasn't been annoying enough to patch downstream
debugging it is fairly easy once it happens, dump core, open in lldb, usually it's fairly clear
@q66 I'm wanna packaging electron, but I can't write recipe
@soggy i don't get it, the pipewire from cports is the same pipewire as the one in packages
i use bt audio with it all the time and it just works