musl >comparatively pretty young, 6 years old. >speedy >designed for static linking >has a whole page dedicated to talking about how awesome it is >Supports x86, x86_64, ARM 32/64, MIPS 32/64, PowerPC 32/64, S390X, SuperH, Microblaze, and OpenRISC. >MIT license
uclibc-ng >technically way older, since it's forked from the now dead uclibc, which was started 17 years ago >apparently slightly slower according to musl >no specific mention of static/dynamic linking >no comparison page >Supports way more shit. Like 29 different architectures OwO >LGPL license
>The argument of alternative Loonix libcs And then you try compiling something useful and it shits itself because of shitty proprietary GANOO extensions. Vendor lock in with open sores software. This is the world we're living in.
Jacob Carter
yep gotta love it. It's not even like glibc has the license advantage, as uclibc is also copyleft same goes for coreutils. we have busybox
Josiah Howard
bump with anime gril
Colton James
very quiet in here, uwu
Hudson Davis
submit a pull/patch then faggot
Carter Sanders
Yay someone replied! Hello, friend! Have you used any Loonix distribution that has one of these libcs?
Nicholas Rivera
also, here's an akarin!
Samuel Moore
final bump. shame nobody wants to talk...
Joseph Ortiz
dont feel bad for trying user. it was a good attempt
Jacob Reed
thanks for that. just wanted to discuss these things, as I think they're kinda interesting do you have anything to say on them?
Noah Torres
...
Noah Young
I linked this thread to a friend on Jabber and discussed GNUisms with him there, in response to However, I myself don't know much about Linux since I use BSDs instead. The idea that GNU participates in vendor lock-in is an intriguing idea that should be investigated.
Connor Turner
Alpine uses musl and it's fine.
Logan Carter
>Have you used any Loonix distribution that has one of these libcs? Are there even any? I haven't heard of any distro worth using that doesn't use glibc.
Carson Gomez
I mostly use Linux, but this is a new idea for me too. If GNU did have some kind of vendor lock-in, or unnecessary bloat, then I generally wouldn't mind too much on the basis of them being copyleft, but as I said in , glibc is not the only copyleft libc for Linux, so it does not have that advantage.
Kevin Gonzalez
Gentoo allows for a uclibc install, and I think musl. Void has a musl option Alpine is entirely musl-based
John Robinson
>"The argument of alternative Loonix libcs" >doesn't actually present an argument Other than for running on a toaster/potato, why wouldn't you use glibc/eglibc?
Nicholas Cooper
>why wouldn't you use glibc/eglibc? primarily Sup Forums autism. same reason why a lot of anons like minimal tiling wms, vim, etc
Ian Gomez
also, eglibc is dead
Elijah Myers
It is? I thought Debian still used it.
Lincoln Stewart
according to wikipedia, whatever that thing did was merged into glibc, and debian just uses regular glibc now since Jessie
Nolan Rivera
>same reason why a lot of anons like minimal tiling wms, vim But both of those have real, practical reasons.
Anthony Jackson
>making shit faster is not practical >reducing bloat is not practical I mean it's not quite as practical as those two, but still, it's not entirely retarded
The colors for versioned symbols should be inverted. Versioned symbols are a cancer and should not be included.
Noah Myers
I am not the creator of musl. That said, why are versioned symbols bad? if they're bad, then I guess that's one more argument for these two alternative libcs, and possibly an argument for uclibc over musl, since musl may want to add this, assuming it's as bad as you claim
Jack Cook
Okay faggot what extension requires additional shit in the libc? I know the clang's lambda support for C is one but mainline gcc doesn't even support them.
Liam Garcia
I'd just like to say, thank you guys so much for posting in here and sharing your thoughts I feel happier now uwu
Alexander Martin
How it works: GNU makes an feature extension feature appears in new C standard GNU implements standard but also keeps the compatibility with extension developers don't even try to transit to portable standard over gcc/glibc only extension GNU never discontinues the extension, several years later another libc appears and second compiler becomes popular, but they are incompatible with the extension
>because of shitty proprietary GANOO extensions. here is your (You) kid, don't donate it to sucksmore all once.
Blake Kelly
>but they are incompatible with the extension Clang sadly tries to be compatible with GCC. I wish there was a good C compiler in the world.
Hudson Brown
obviously musl newer = better
literally faster static linking is objectively superior yeah its fucking cool less architectures -> less complexity better license
Jason Reed
does musl have strlcpy and strlcat?
Brandon Gutierrez
yes
Juan Howard
>making shit faster is not practical I've never heard any performance complaints about glibc. If anything, I'm pretty sure it has one of the fastest malloc implementations there is. >reducing bloat is not practical It is strange to mention this in the same sentence as a library meant for static linking.
Aiden Young
You have a very fine collection of whitespace, OP.
Jonathan Williams
>I wish there was a good C compiler in the world. Shit like statement expressions should be in the standard, though.
James Sanders
When do you ever need those, though? I've never done copies and concatenations of strings whose lengths I'm not statically aware of without tracking their lengths explicitly instead of using NUL termination, and in that case using memcpy/memmove is both easier and faster anyway.
Tyler Ortiz
Thanks for the explanation. So from this, it sounds like it's not even an issue of glibc letting you do more shit, as a lot of their extensions end up becoming standards anyway. So it is literally vendor lock-in. Whether that's just due to a side effect ofGNU doing this for the sake of devs who have built their entire software system on top of the extensions and don't want to redo it in the standards-compliant way, a side effect of GNU being too lazy to get rid of the extensions, or an intentional act of vendor lock-in, it appears to be the case.
I definitely see your points here, but to play uclibc's advocate, >newer = better newer = not as mature >literally faster only slightly. uclibc is still running circles around glibc >yeah its fucking cool humility is a virtue >less architectures -> less complexity not really much I can say here. I would say that because of Intel's and AMD's botnet features, having more available architectures is good because it gives us better support for our escape options, but musl does seem to have all of the ones that are being considered. That said, it's missing POWER (as in, the POWER that would be used on something like the TALOS II.) >better license I personally disagree, but I know that you will be incapable of convincing me otherwise, and I know that I will be incapable of convincing you, so whatever.
Hudson Butler
Thanks, uwu
You say A library, not BOTH. uclibc does not mention static linking specifically.
In response to myself here, I would like to clarify a bit on the license issue. a possible, non-biased argument for the license is that uclibc is under the same one as glibc. So with musl even if it is super fast, I and other freetards can be like >cuck license , but since uclibc is also copyleft, it gives an opportunity to say, "this thing is faster than glibc, less bloated in general than glibc, and has a cute puppy. It's also equally as supportive of your freedoms as glibc, so you have NO excuse."
Ian Collins
>uclibc is still running circles around glibc [citation needed]
Oliver Martin
Friendly reminder to wash your hands after touching libc
Logan Jones
So i'm planning a Sup Forumsentoo install with uclibc I've heard some anons say everything works just fine I've heard others say a ton of shit breaks What am I in for?
Brody Cox
>Hello OP I'm assuming you're the creator of musl. after reading rich's twitter I doubt he will ever go to Sup Forums