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.
I think they are saying that in the operating system developer way, where "just works" means coherent and behaving according to some technical specification.
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.
the point with "just working" applies to what the system ships, obviously third party whatever is outside of our control
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)
That's also how I read it. For people who are masochists and want to invite yet more snowflake differences problems. Being too special and causing surprises leads to net negative productivity that swamps all other claimed goals and properties.
I read "nonstandard" in their comment by its dictionary definition ("not average, normal, or usual"). Not that it literally violates a published standard.
Most Linux installs are going to be using Bionic libc, so still dubious to call glibc "standard". This is Linux. There is no standard. OpenWRT used uClibc until 2019.
I am a fan of Chimera Linux and both Alpine and Void also use MUSL. But there is no denying that Glibc is the de facto standard on Linux Desktops and many desktop applications assume it.
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.
Are you saying that just to be contrarian? When somebody tells you they're running Linux on the laptop, you actually think they are owning a chrome book (considering that there are likely more chrome books than laptops with other linuxes), when you read a job add which requires Linux admin knowledge, you think they mean being able to install apps on android?
> To me, that is a bad thing and we agree that diversity should be possible.
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.
That is really how I meant it. Using Linux for almost 20 years I've found the most important part of having a working system is being on the beaten path. Distros that do too much exotic stuff spend all their time fruitlessly trying to keep up with porting and end up confined to a small user base of OS geekery enthusiasts.
You are replying to someone who did, so there's your example. There's a bunch of other people in this thread as well – you really don't need to look very far.
"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.
> 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.
* 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."
> Insisting on one absolute definition and calling anyone who uses another definition "disingenuous" is not hugely constructive.
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".
If a distro is advertising the fact that they are not using glibc, then that's the standard. I don't mean no snark. This is the way parent probably used the term. It doesn't mean musl is not good or it violates some standard. Though you are more likely to have problems with it as an end user where gentoo/arch wikis won't be of any help.
> Saying musk is non-standard is 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.
It's not used by any of the major ones, so in practice lots of apps will be broken. I like musl, and I link it for my own stuff but I only have to make sure my stuff works. if I had to make sure everyone's existing stuff worked glibc is the only practical choice.
Yep. There are lots of edge-cases and macros that glibc provides are difficult to emulate because they require a lot of domain-specific knowledge and special handling. There isn't really a way to use musl in any large distro without lots and lots of patching and giving up correctness and completeness. It's akin to not using ICU4{C,J} and praying that simplistic Unicode handling like normalization will magically work.
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.
