4 ms·

I'll take this bait in good faith: What about glibc is so bad that you'd rather use the slower, buggier, less compatible, less throughly reviewed musl in produc

by fl0ki 3y ago

I'll take this bait in good faith: What about glibc is so bad that you'd rather use the slower, buggier, less compatible, less throughly reviewed musl in production? If I had to pick something, it'd be that glibc is behind musl on supporting 64-bit timestamps on 32-bit targets; and at least for my targets, that's a stretch. In return, musl's (past?) problems with domain resolution alone seem like more than enough of a downside to avoid it on all targets. https://twitter.com/RichFelker/status/994629795551031296 https://twitter.com/RichFelker/status/994629795551031296 vs https://datatracker.ietf.org/doc/html/rfc7766#section-5 https://datatracker.ietf.org/doc/html/rfc7766#section-5 Disclaimer: I'm targeting these from Rust, not C or C++ directly.

1vuio0pswjnm7 3y ago
"I'll take this bait in good faith: What about glibc is so bad that you'd rather use the slower, buggier, less compatible, less throughly reviewed musl in production?" One might conclude from reading this question that someone has already made up their mind. Why would someone framing a question in this way have any interest in what I prefer and why. I am not a "developer". I am an "end user" that compiles programs for own use. Is this a "good faith" question. "Bait" indeed. The difficulty with compiling static binaries using glibc is the deal-killer for me. Coming to Linux from NetBSD, I never experienced any difficulty compiling static binaries using NetSBD's libc. Rarely do I encounter software I want to use that does not compile easily with musl. Instead I encounter software authors that have made the effort, if any is required, to be musl-compatible or that use musl exclusively (see spitbol), including Linux distributions that have adopted musl as their libc (see Alpine Linux) or offer a musl option (see VoidLinux). If others prefer glibc, then I have no problem with that. What I do not understand is why HN commenters want to jump on every comment where I mention using musl myself and try to disparage it. Why would they care what libc I use. If anything, these snarky comments only make me more skeptical of glibc.

by fl0ki 3y ago

1vuio0pswjnm7 3y ago

"I'll take this bait in good faith: What about glibc is so bad that you'd rather use the slower, buggier, less compatible, less throughly reviewed musl in production?" One might conclude from reading this question that someone has already made up their mind. Why would someone framing a question in this way have any interest in what I prefer and why. I am not a "developer". I am an "end user" that compiles programs for own use. Is this a "good faith" question. "Bait" indeed. The difficulty with compiling static binaries using glibc is the deal-killer for me. Coming to Linux from NetBSD, I never experienced any difficulty compiling static binaries using NetSBD's libc. Rarely do I encounter software I want to use that does not compile easily with musl. Instead I encounter software authors that have made the effort, if any is required, to be musl-compatible or that use musl exclusively (see spitbol), including Linux distributions that have adopted musl as their libc (see Alpine Linux) or offer a musl option (see VoidLinux). If others prefer glibc, then I have no problem with that. What I do not understand is why HN commenters want to jump on every comment where I mention using musl myself and try to disparage it. Why would they care what libc I use. If anything, these snarky comments only make me more skeptical of glibc.