So they're basically saying "our system will be better because more things will just work" but then they decided to use nonstandard libc and coreutils so actually getting existing Linux scripts and software to work in this distro will be harder.
It absolutely does not mean "no manual programming or customization from the user required". It means no dirty hacks, like the ones mainstream distros employ to make some of the customization and programming unnecessary that is actually kind of inherent to the way Unix has traditionally worked.
That may very well be much less easy to work with from a consumer perspective, but from a systems programmer perspective it's the opposite way. Those hacks that allow for the ease of use in a GNU userland make programming a massive pain in the ass where nothing "just works" the way it should, because GNU programs and libraries are in flagrant violation of every specification and rule of thumb that has ever really mattered for Unices.
Also, it's GNU libc that has gone out of its way to fail to adhere to standards, not musl. GNU does not give a single crap about open standards, because they believe that whatever GNU is IS the standard, which apparently is your view as well. That's simply unacceptable for a lot of people.
> Those hacks that allow for the ease of use in a GNU userland make programming a massive pain in the ass where nothing "just works" the way it should, because GNU programs and libraries are in flagrant violation of every specification and rule of thumb that has ever really mattered for Unices.
Just because the tools offer additional functionality does not mean they "violate every specification and rule of thumb that has ever really mattered for Unices" (what does that even mean?!). I mean you're welcome to edit files in ed, because that's pure Unix, but I'd rather use a more capable editor.
But vi/nvi it's useful because you can use commands to replace text inline, or pipe text parts to commands.
the system aims to have high quality packaging that results in a system that is consistently deterministic and auditable, while indeed making things just work (no extra effort beyond just installation required to get any software the system ships to work - on any CPU architecture it supports) - you can bootstrap a fully working system pretty much just by installing a single metapackage + a kernel in a root (and then refreshing the bootloader)
To me, that is a bad thing and we agree that diversity should be possible.
We do not agree that “most Linux installs are going to be using Bionic”. Android uses the Linux kernel but it is not what people mean when they say “Linux”. The applications running on Android and the ones running on your Linux desktop are separate universes.
Speak for yourself.
In my mind, Linux is home routers, smart TVs, digital signage, tablets, smartphone, fridges, and yes, servers and workstations.
I too would like the standard C library to be an actual standard with multiple compliant and compatible implementations, and I'd like apps to work correctly across multiple implementations.
It requires some effort to migrate applications to musl, and there are functional differences from glibc. https://wiki.musl-libc.org/functional-differences-from-glibc...
"Standard" is one of those words that can mean different things. Insisting on one absolute definition and calling anyone who uses another definition "disingenuous" is not hugely constructive.
Nobody said anything about an absolute definition.
When describing the C standard library, the only reasonable interpretation of "nonstandard" is that it does not adhere to standard C. There are no counter-examples anyone has been able to provide from any corpus.
No, that is your interpretation, and one that, so far as I can tell from all of the responses in this thread, you are alone in believing.
> There are no counter-examples anyone has been able to provide from any corpus.
* https://elinux.org/images/1/15/Anatomy_of_Cross-Compilation_... 2016, see page 14 "de facto standard of Linux C libraries"
* https://www.linuxjournal.com/article/3417 (June 1999) -- "Linux has now standardized on the GNU C library (glibc) as the common implementation for future Linux systems."
* https://www.reddit.com/r/C_Programming/comments/9g6531/where... "For the standard library, uCLibC and muSL are the two lightweight (and thus likely easier to understand) libraries. GLibC ("libc") is more or less the de-facto standard C library for all non-windows (and even some windows) development."
* https://man.archlinux.org/man/glibc.7 -- "For a while, Linux libc was the standard C library in many Linux distributions."
It's also ironic coming from someone who's opening salvo was to describe a post about musl being "non-standard" as constituting a "serious allegation".
No, it isn't. It's the GP's opinion.
Standard has a few different meanings, including something typically or commonly used. As in "GNU Libc has been the standard C library used by Linux distributions since 1991." That would be, you know, a statement of fact. Musl is, at best, a niche option used by a few distros.
Using musl is fine for limited uses, but it's magical thinking to believe that it's at exact feature and functional parity replacement for glibc.