Comment 267 for bug 727064

(In reply to comment #221)
>
> There are others which place a higher value on accommodating proprietary
> software and carrying downstream patches.

Why the hell do people like you continue to think this is about "proprietary software"?

This is about "helping users". It has absolutely _nothing_ to do with proprietary or not, and is about the fact that binary compatibility matters.

It's also about doing a good job.

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.

And there really isn't any valid technical reason for doing a bad job at memcpy.

What is annoying is how people have turned this "glibc broke existing binaries" into some kind of "free software vs proprietary" crap. That's not the point. I know from personal involvement in git that the whole "oops, we used memcpy where we _should_ have used memmove" is a common bug. Bugs happen. The binary may even have been really well tested, but it was tested with a library that consistently did things some way.

Now glibc does random things. The direction of the copy will seemingly depend on things like random alignment issue, rather than any repeatable thing, so just access patterns etc make it do different things for no good reason.

I repeat: "for no good reason". There's no REASON for glibc to break things.

So stop the whole "proprietaty software" crap. It's about USERS. And it's about Quality-of-implementation.

In the kernel, we have very strict rules of "we don't break binary compatibility unless we _have_ to". It doesn't matter if it's a result of a bug in user space or not ("you shouldn't have been doing that") we revert patches that break things. Sure, occasionally we have major reasons why we can't see it as that kind of absolute rule (security bugs that simply require visible changes, or major re-architecting of some area that makes it impossible to support some old API), but they really need to be major reasons.

Why? Because _users_ are the only thing that makes software useful. Software isn't useful on its own. You cannot say "this is the right thing to do" unless you take users into account.

And no, "there is a workaround" is not good enough, unless that workaround is then automatic from the distribution. Most users that hit this issue will never ever see this bugzilla. They will just say "Fedora is buggy".

And they'd be right.

I'm disappointed. Stop the idiotic parroting of "proprietary app". Think about what users do, and think about all the random binaries people run.