The argument of alternative Loonix libcs

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

Other urls found in this thread:

etalabs.net/compare_libcs.html
archive.fosdem.org/2017/schedule/event/building_a_distro_with_musl_libc/
twitter.com/NSFWRedditGif

>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.

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

bump with anime gril

very quiet in here, uwu

submit a pull/patch then faggot

Yay someone replied!
Hello, friend!
Have you used any Loonix distribution that has one of these libcs?

also, here's an akarin!

final bump. shame nobody wants to talk...

dont feel bad for trying user. it was a good attempt

thanks for that.
just wanted to discuss these things, as I think they're kinda interesting
do you have anything to say on them?

...

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.

Alpine uses musl and it's fine.

>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.

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.

Gentoo allows for a uclibc install, and I think musl.
Void has a musl option
Alpine is entirely musl-based

>"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?

>why wouldn't you use glibc/eglibc?
primarily Sup Forums autism. same reason why a lot of anons like minimal tiling wms, vim, etc

also, eglibc is dead

It is? I thought Debian still used it.

according to wikipedia, whatever that thing did was merged into glibc, and debian just uses regular glibc now since Jessie

>same reason why a lot of anons like minimal tiling wms, vim
But both of those have real, practical reasons.

>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

Hello OP I'm assuming you're the creator of musl. I have an issue with your page here: etalabs.net/compare_libcs.html

The colors for versioned symbols should be inverted. Versioned symbols are a cancer and should not be included.

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

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.

I'd just like to say, thank you guys so much for posting in here and sharing your thoughts
I feel happier now uwu

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

there was an interesting talk on Alpine distro and porting on FOSDEM 2017, even n-gate said it's one of the worth talks but audience had ho idea
archive.fosdem.org/2017/schedule/event/building_a_distro_with_musl_libc/

>because of shitty proprietary GANOO extensions.
here is your (You) kid, don't donate it to sucksmore all once.

>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.

obviously musl
newer = better

literally faster
static linking is objectively superior
yeah its fucking cool
less architectures -> less complexity
better license

does musl have strlcpy and strlcat?

yes

>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.

You have a very fine collection of whitespace, OP.

>I wish there was a good C compiler in the world.
Shit like statement expressions should be in the standard, though.

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.

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.

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."

>uclibc is still running circles around glibc
[citation needed]

Friendly reminder to wash your hands after touching libc

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?

>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

...