MUSL DEPRECIATED?

Ok this has been bugging me for a while.
People seem to think Musl is a really good thing.
But how can that be?
According to Void wiki:
>Some programs (mostly graphical applications) will work incorrectly, or segfault when run under musl. This may be due to programs expecting some glibc-specific behavior.
This must mean that musl is incomplete. This behavior that is in glibc and not musl is apparently pretty vital, because not having it can cause stuff to not run properly or segfault.
Clearly Musl needs to implement these important features.
Am I wrong, and if so, how do you justify these glaring deficiencies?

Other urls found in this thread:

en.wikipedia.org/wiki/C_POSIX_library
gnu.org/software/libc/):
twitter.com/NSFWRedditGif

You again. Please stop posting.

one difference is way smaller per-thread stack size, glibc creates up-to 80MB while musl only allows 80kb
there are many formatting extensions in glibc and many behaviors that go against POSIX specs while musl tries to strictly honors POSIX over copying glibc behavior
GNU's EEE in practice baby
>musl uses readv and writev for implementing stdio ... However, it does also impact how Linux interprets some writes to files in /proc
wonder how big difference this makes and when it's an issue
I've heard systemd notoriously doesn't care for honoring POSIX, many GUI applications rely in some way on systemd, maybe this could be hiding some issues?

(You) again.
Please explain this then.

>glibc creates up-to 80MB while musl only allows 80kb
why would they make it like that? Does it provide any benefit?
>I've heard systemd notoriously doesn't care for honoring POSIX, many GUI applications rely in some way on systemd, maybe this could be hiding some issues?
I don't think that has much to do with it. The quote in the OP was from the wiki for Void Linux, which uses the runit init system.

fucking read their wiki and talk I've linked in previous thread instead of making new thread with already answered questions like an idiot

Compatibility issues can come from both sides, brainlet. Just because some retards write applications that rely on non-standard glibc behavior doesn't mean musl is at fault.

>non-standard glibc behavior
glibc is the standard, you fuck.

No, POSIX is the standard you absolute swine. I really hope you're baiting right now because people like you really make me lose faith in the future survival of the human species.

It's not, it's an implementation of an standard. And it also implements things that don't exist in the actual standard.

What is the defining document on how glibc's interfaces should behave? What can I refer to? What can I compare glibc's source code with to see if it's acting according to specification?

You cannot use musl as a drop-in replacement for glibc. You have to recompile your programs against musl and then all issues should be gone. Otherwise it probably doesn't compile with musl in the first place.

en.wikipedia.org/wiki/C_POSIX_library

Well it's mostly binary-compatible, actually everything i tried worked fine

Glibc is logically the "standard".
If it wasn't, then why is Musl considered to be an "alternative" to it?

No it's not. Glibc is an implementation. It tries to FOLLOW standards.
From the glibc homepage (gnu.org/software/libc/):
>The GNU C Library [...] aims to follow all relevant standards including ISO C11, POSIX.1-2008, and IEEE 754-2008.
Now please stop embarrasing yourself.

>relying on glibc-specific behaviour

there's the problem, you shouldn't rely on bugs in a trash tier software made by communist hippies in the 90s.

musl is made with strong readability in mind, glibc on the other hand looks like a designated shitting street

>you shouldn't rely on bugs
How are they bugs?
>Glibc's an implementation of a standard.
Yeah.
Admittedly i'm half-trolling with this shit. I knew glibc is based on POSIX and ISO.
But why are its additions to the language a bad thing?
>GNU tries to innovate by extending the standard and providing programmers with more features
>"OY VEY! SHUT IT DOWN!"

bump

Would flatpak allow you to run steam on a musl system?

anyone?

How are you in a position to care, without simultaneously knowing? Unless you're a troll.

Because implementing functionality outside the standard leads to things depending on that extra functionality as if it were standard. It's the same thing that Microsoft did with RDP.

So nobody is allowed to innovate with this component? Nobody is allowed to do anything different or improve upon it?
At that point why are there even different implementations? Just have the standards faggots make one and have everything use that.

In MS's case the additional functionality was proprietary, thus locking out other vendors. A soft--lockout occurs when the standard isn't followed by the vastly more dominant implementation. Everyone uses the more dominant implementation without regard to portability.

To clarify, the functionality was not proprietary at first, but permission to use the functionality in third party implementations was revoked by my understanding.

So someone makes a standard with certain specifications
Someone else like, say, the GNU project implements that, but also adds additional features for use by programmers
Programmers find these tools useful, and start using that implementation over the ones that just implement the standard
And you think that's a bad thing? That there should be no innovation?

I ask again. If this is such a big concern somehow, why don't the standards fags make one implementation, and everybody just uses that? Why even give people freedom if they're not allowed to do anything with it?

>DEPRECIATED

No, I think that the lack of a proper standard is the core problem. The unfortunate result of it is the formation of non-standard implementations. I don't like it, and find it far from ideal, but it is what it is. The solution is the formation of a new standard that encapsulates the desired functionality. Personally I'm not a fan of glibc (libc for lyfe), I think the code is a mess, but again, that's what we have to deal with right now.

>No, I think that the lack of a proper standard is the core problem
What do you mean by proper standard? You've been bringing the standards and standards-compliance up this whole time.
>The solution is the formation of a new standard that encapsulates the desired functionality
Ah, so perhaps the standard itself is a bit behind the times, and needs to add the functionality? Interesting.

Oh boy!

Another programming thread...

A standard that contains the features needed and wanted by it's users.

Yes, that is exactly what I mean. Yes, developers break standards which leads to fragmentation, but it's often necessary. If I seem dodgy it's because I avoid placing blame on any one group, because it's the interaction (disagreements) between the groups that arises the issue in the first place.

>having a libc

Patricians develop directly on top of the Linux kernel by issuing system calls. Enjoy your errno, you fucking retards.

Some GCC GNU C extensions are actually useful. The ability to take the address of a label, for example.

The real problem here is that C is fucking garbage. It's not expressive enough so GCC literally had to extend the language.

I agree, check out my other post. The C standard itself needs to be extended.

I heard from a muslfag that one issue was that glibc would come up with a feature, it would get implemented into the standards, and then glibc would keep their original extension, as well as the standards-version, and programs would just keep using the glibc version of the feature.

this is /g
arguably better than the consumer electronics threads

>lack of portability

This thread at least. Most are a waste of bandwidth.

THIS HAS EXCELLENT PORTABILITY.

WANT LINUX SYSCALL ON MACOS? RUN LEENUCKS ON MACOS AS MACH USER PROCESDSD.

YOU WANT ON WINDOWS? RUN UBUNTU ON BASH ON WINDOWS ON CHROOT ON WIN32 PROCESS.

>that fucking REEEEEEEEEEEEE
I kek'd

I briefly considered going full retard and throwing 20 layers of virtualization in there too.

>gets completely blown the fuck out
>i was only pretending to be retarded!
Like pottery.