Quantcast
[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

Maintenance is complete! We got more disk space.
Become a Patron!

/g/ - Technology


View post   

[ Toggle deleted replies ]
File: 80 KB, 600x600, uclibcvsmusl.png [View same] [iqdb] [saucenao] [google] [report]
63606651 No.63606651 [Reply] [Original] [archived.moe] [rbt]

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

>> No.63606693

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

>> No.63606847

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

>> No.63607081
File: 61 KB, 555x600, Akaza.Akari.600.1509899.jpg [View same] [iqdb] [saucenao] [google] [report]
63607081

bump with anime gril

>> No.63607588
File: 378 KB, 1024x1399, akari_akaza_by_yukirumo990-d4ifcuc.png [View same] [iqdb] [saucenao] [google] [report]
63607588

>>63607081
very quiet in here, uwu

>> No.63607931

>>63606693
submit a pull/patch then faggot

>> No.63608099

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

>> No.63608317
File: 254 KB, 600x750, Akaza.Akari.full.1327549.jpg [View same] [iqdb] [saucenao] [google] [report]
63608317

>>63607931
also, here's an akarin!

>> No.63609198
File: 139 KB, 917x871, sad_pepe__feels_bad_man__vector_by_hirussai-d8uq43y.png [View same] [iqdb] [saucenao] [google] [report]
63609198

final bump. shame nobody wants to talk...

>> No.63609859

>>63609198
dont feel bad for trying anon. it was a good attempt

>> No.63609878

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

>> No.63609883
File: 369 KB, 580x435, chiyo_penguin.png [View same] [iqdb] [saucenao] [google] [report]
63609883

>> No.63609904

>>63609198
I linked this thread to a friend on Jabber and discussed GNUisms with him there, in response to
>>63606693
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.

>> No.63609920

>>63606693
Alpine uses musl and it's fine.

>> No.63609927

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

>> No.63609939

>>63609904
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 >>63606847 , glibc is not the only copyleft libc for Linux, so it does not have that advantage.

>> No.63609954

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

>> No.63609956

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

>> No.63609978

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

>> No.63609990

>>63609956
also, eglibc is dead

>> No.63610022

>>63609990
It is? I thought Debian still used it.

>> No.63610043

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

>> No.63610054

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

>> No.63610096

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

>> No.63610295

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

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

>> No.63610344

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

>> No.63610390

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

>> No.63610583
File: 38 KB, 600x600, Akaza.Akari.600.817256.jpg [View same] [iqdb] [saucenao] [google] [report]
63610583

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

>> No.63611544

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
https://archive.fosdem.org/2017/schedule/event/building_a_distro_with_musl_libc/

>> No.63611622

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

>> No.63612208

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

>> No.63612234

obviously musl
newer = better

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

>> No.63612298

does musl have strlcpy and strlcat?

>> No.63612321

>>63612298
yes

>> No.63613994

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

>> No.63614029

>>63610583
You have a very fine collection of whitespace, OP.

>> No.63614037

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

>> No.63614070

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

>> No.63614080

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

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

>> No.63614304
File: 44 KB, 511x551, uwu.jpg [View same] [iqdb] [saucenao] [google] [report]
63614304

>>63614029
Thanks, uwu

>>63613994
You say A library, not BOTH.
uclibc does not mention static linking specifically.

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

>> No.63614369

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

>> No.63615450

Friendly reminder to wash your hands after touching libc

>> No.63615527

So i'm planning a /g/entoo 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?

>> No.63616005

>>63610295
>Hello OP I'm assuming you're the creator of musl.
after reading rich's twitter I doubt he will ever go to /g/

>> No.63616052
File: 43 KB, 589x186, lel.png [View same] [iqdb] [saucenao] [google] [report]
63616052

>>63616005

>>
Name (leave empty)
Comment (leave empty)
Name
E-mail
Subject
Comment
Password [?]Password used for file deletion.
Captcha
Action