3 ms·
"Bullshit. You clearly don't know what you're talking about." Tells it like he sees it. I'm not going to argue with the man. He makes some good points. The use
by chuhnk 16y ago
"Bullshit. You clearly don't know what you're talking about."
Tells it like he sees it. I'm not going to argue with the man. He makes some good points. The user really doesn't care what the underlying changes are as long as everything continues to work, in this case it does not. Reading back through the comments its clear Linus makes great suggestions which are left unheard.
I like comment #222 https://bugzilla.redhat.com/show_bug.cgi?id=638477#c222 https://bugzilla.redhat.com/show_bug.cgi?id=638477#c222
"Breaking existing binaries with a shared library update IS A BAD THING. How hard can that be to understand? If you break binary compatibility, you need to update the library major version number."
- e40 16y agoThis hit the product I work on and I agree 100%. We had to scramble for days to fix this. (Find a test case, diagnose it, make the fix, release a patch.) It was a pain in the ass. At least the solution was a 1 liner.
- xilun0 16y agoexplain how you fix any bug or change any implementation by still respecting your side of a contractual interface without breaking said "binary compatibility" when using this broken definition of "binary compatibility" exposure of a random proprietary software bug written by morons does not imply breakage of "binary compatibility". some free software developers have no time to test their standard compliant library against all crappy proprietary software ever written under the sun. if that makes you sad, at least you are free to modify the fucking library for your own little use case, or even to fork the library and maintain your fork with an explicit policy of never ever changing externally observable behaviour (probably meaning you won't make any change to said library (other than in comments) if you REALLY apply this rule...), which happily glibc never had and hopefully never will have.