I suspect that the primary use cases for that would be applying half-baked workarounds and refusing to work with an "unsupported" libc, much like HTTP User-Agent.
I’m only half joking. Features detection in Musl is a generally pain. I don’t blame developers for sometimes taking the path of least resistance and not trying to support it.
It must be nice living in your. theoretical world. Here in the real world, I like libraries to actually help me do what I want to do rather than be needlessly annoying to take a stand no one actually cares about. But that’s me. Clearly it serves Musl right given the massive amount of use it’s seeing. Hmm, wait a minute…
See RFC 1925, The twelve networking truths:
(1) It has to work
However as I noted in my other reply, musl also implements the res_* functions, like res_send() etc., and those can be used to address both.
However musl also includes res_send() etc., which can be used for MX records, and e.g. Qmail did use it back then. Here's the commit adding TCP support to those functions in Musl.
http://git.musl-libc.org/cgit/musl/commit/src/network/res_ms...
Qmail's issue was a hardcoded buffer size so this patch to musl wouldn't have helped.
I've never really understood the underlying mentality that causes maintainers to bend over backwards to _not_ provide popular functionality like this.
Reminds me a bit of the strlcpy/strlcat debacle with glibc.
What would they be doing with it that they couldn’t do better (faster/less bugs/risk) another way?
I think this one might be dumb too which is why I’m asking.
Once upon a time, the DNS spec required requests come from port 53. This was terribly insecure, so many sysadmins patched their DNS server to not do this-- most servers at the time didn't care (including the incumbent), and the few that did were easy to convince of the error of their ways with a simple demonstration.
Then one day, a DNS server became quite popular that didn't do this by default, and perhaps because the DNS spec was written by a company that sold consulting for their (buggy) DNS server, they used this exact argument: that it was wrong because the spec said it was wrong. They patched their server to reject these messages and encouraged users to block this traffic.
That was wrong of them, and eventually, due to enough pressure they eventually caved. That's because the reality of good engineering doesn't give two fucks what the spec says.
So what's your use-case?
Is this HTTP/S? SNMP? Something bespoke? Why doesn't the client already know where all the servers are? How far away are the servers from the client? Can you put code that lives in the client, or is this existing client software you're trying to trick into supporting client-side load balancing?
Also, and only slightly related: Do you have a different definition of "use-case" than me that involves being as vague as you possibly can?
Probably trying to prevent feature creep; musl's home page describes it as
> musl is lightweight, fast, simple, free, and strives to be correct in the sense of standards-conformance and safety
And every single feature they add makes those things harder.
While I wouldn't call myself a fan of Postel's Law (I think "being liberal with what you accept" can allow others to get away with sloppy implementations over long time periods, diluting the usefulness of standards and specifications), I think at some point you have to recognize the reality of how things are implemented in the real world, and that refusing to conform to the de-facto standard hurts your users.
The fact that the maintainer only caved because the TCP fallback behavior is finally being made mandatory, and not because he's (very belatedly) recognizing he's harming his users with his stubbornness, also speaks volumes... and not in a good way.
> the maintainer only caved
> he's harming his users with his stubbornness
A gentle reminder that you're not entitled to other people's free labor. It's one thing to disagree with technical decisions made by the project, but the shaming and name calling is a bit too much.
And while I’d agree in principle that nobody is entitled to anyone else’s labor for free, I’d also add that nobody is entitled to be shielded from criticism of work they have chosen to publish, or to have that criticism be watered down to a sanitized, milquetoast version of the writer’s intended message.
You certainly demonstrated the fallacy. You took the most absurd interpretation of my words that is possible in a literal sense because that's easier for you to mock.
Describing someone's behavior as entitled doesn't amount to making a false claim. That's the most obvious interpretation of what I actually said. But you took it to mean that any claim of entitlement can't be false.
> Your imagining someone to be entitled does not make them so, and your accusation belittles their actual, valid reasoning.
There's no imagination or accusation involved here when the very comment I'm referring to is right here in this very thread. It's a statement of fact.
The parts I quoted are ad hominem attacks that accuses someone of neglecting an obligation that objectively doesn't exist. That's the dictionary definition of entitlement.
> It actually shows you to be the one "entitled" to your projected redeclaration of their identity and rationale
Like misrepresenting my words or calling me "narcissistic?"
> potentially shared value-based opinion about the facts being criticised
The parts I quoted isn't a fact-based criticism. It's an ad hominem attack.
> irrellevant as calling out someone for being "entitled to breathe air" if you catch them criticizing the air's quality
Everyone is entitled access to clean air. People have an obligation to keep the air clean.
No one is entitled access to free labor, including having your pet features implemented and maintained in a software project.
But overall, gosh. How many fallacies, misrepresentations, and personal insults can you pack in such a short comment?
> intentionally-faulty software
> the maintainer only caved
> he's harming his users with his stubbornness
is strong language and not productive. If someone at my company sincerely criticized my work in this way I'd find it unacceptable and managers would get involved. There's criticism and there's polemics, and this is the latter.
I would agree there is a line, but disagree that the original poster stepped over it. Disagreement, even vigorous disagreement is important.
Calling out bad technical decisions is important.
Calling out oversensitive people who want to censor online discourse to their personal tastes is also important.
Furthermore, ad hominem attacks have nothing to do with "calling out bad technical decisions."
BTW go take my words verbatim and use it against me if my actions are genuinely hypocritical. But to do that for my actions you made up is abusive and makes you look bad.
Fair, but I'd hold HN to a higher standard. We're peers and we choose to be here. We should treat each other with kindness and respect, not contempt. I read a fair amount of contempt in OP's characterization, and I hold that separate from respectful criticism.
I looked up a thread about this from 2020 [0] and it actually seems well reasoned, calm, and respectful. No one's slinging around words like "faulty", "broken", or "harm" because those tend to insult people and derail technical discussions.
And FWIW, that's why I would get managers involved if this happened in the workplace. Calling people's work "broken by design" or "harmful" is how to start an argument, not how to solve a problem. If someone's acting this way, there's no way things are going well.
If that maintainer abandoned the project, it would either be picked up or abandoned altogether if the project were worthless.
It's a borderline case because it's almost worthless due to the aforementioned issues.
It was pretty clear that musl was unwilling to support adding any TCP fallback code path regardless of a patch existing.
Anyways, your comment is inflammatory and is full of straw-men. Try being less of a dick.
Do they owe me anything? Of course not. Is anyone here claiming anything to the contrary? No. So what are you on about, exactly?
This is the comment section on a website. Here we are discussing that the project maintainers kinda cocked this one up from a reputation and user trust perspective. If reputation, user trust and thus adoption are not a concern or goal of the project, then cool, good for them. It doesn't mean, however, that there isn't some reputation or user trust that was eroded. And it certainly doesn't mean we can't discuss it.
For you to reply "what are you a child, just fork it and grow a pair, fix it yourself" is not constructive nor does it contribute to the discourse. Or did I put words in your mouth? Hm I wonder how that feels.
Or in other words they've always been standards-compliant, and when the standard changed they updated to match it.
"RFC" is Request For Comments. Some RFCs become standards. But there are no internet police, notwithstanding that the internet is a fascist state (run by corporations for the benefit of corporations). Understanding it as a fascist state is the rational way to view "enforcement" as well as the natterings over whether something is a standard and who is going to enforce it anyway.
That they only just implemented this is a joke, and Alpine/musl users are the punchline.
This has been an issue plaguing Alpine for years where the musl maintainer basically said the standard says may fallback, not must fallback. Let the rest of the internet change, we don't feel this is important. We're standards complainant.
It gained traction for the change with the latest RFC. for dns last year which made TCP fallback mandatory [0]. The cloak of standards compliant could no longer be used.
0: https://datatracker.ietf.org/doc/html/rfc9210