Please, before posting links to Wikipedia entries, give it some context!
235 karma · joined July 7, 2013
Please, before posting links to Wikipedia entries, give it some context!
https://bugzilla.redhat.com/show_bug.cgi?id=638477
comment 129 https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129
---
Quite frankly, I find your attitude to be annoying and downright stupid.
How hard can it be to understand the following simple sentence:
THE USER DOESN'T CARE.
Pushing the blame around doesn't help anybody. The only thing that helps is Fedora being helpful, not being obstinate.Also, the fact is, that from a Q&A standpoint, a memcpy() that "just does the right thing" is simply _better_. Quoting standards is just stupid, when there's two simple choices: "it works" or "it doesn't work because bugs happen".
Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth.
Reality is what matters. When glibc changed memcpy, it created problems. Saying "not my problem" is irresponsible when it hurts users.
And pointing fingers at Adobe and blaming them for creating bad software is _doubly_ irresponsible if you are then not willing to set a higher standard for your own project. And "not my problem" is not a higher standard.
So please just fix it.
The easy and technically nice solution is to just say "we'll alias memcpy to memmove - good software should never notice, and it helps bad software and a known problem".
---
This is why Linus is widely considered a good steward, and Ulrich had to be removed from glibc.
Yes, they both had abrasive mannerisms, yes they sometimes said things that wouldn't pass fortune 500 HR policy.
The difference is: Ulrich seemed to care more about some kind of technical "correct-ness", and anything that didn't fit in his mental model was considered wrong, and nothing else mattered.
Linus deeply cares about the user experience. the kernel has a strict no-regressions policy for this reason. If it used to work before and now it doesn't, this needs to be fixed in the kernel
Like this case, most of the cases where Linus uses salty language comes down to various kernel developers not following this policy, then complaining when their patch doesn't get accepted.
Edited for formatting
You may look at it and rewrite huge chunks because you're a far better programmer now, but trust me, re-writing code is way easier than writing it from scratch
If I were Chinese, the license of the software I was using would be far, far down my list of "Freedoms" that I was concerned about.
Hindus denying rights to women and allowing atrocities like rape and honor killings? Basically the BJP platform in India. Oh, and mass killings of Moslems in the 80s thrown in for good measure.
There is no Zoroastrian or Taoist state, but I'm sure if there was, there would be atrocities there.
Oh, and before anyone says that this is just an anti-religious rant: Pol Pot killed millions, and he was a nominal atheist.
People can and will kill and subjugate people for pretty much any reason. Usually they call it "The Greater Good"
LibreSSL and openSSLRampage is the OpenBSD response, and, it's absolutely in keeping with their character. I admire the "Fuck it, let's just fix this shit" attitude that goes along with it.
The Core Infrastructure Initiative is the Linux Foundation's response.
They're two valid ways of dealing with the problem. the LibreSSL way is more direct, targetted, and, in a way, satisfying, especially if you run OpenBSD, and can gain from these efforts relatively quickly.
The "Core Infrastructure Initiative" is looking at it from a more holistic perspective and saying: OK, OpenSSL was in trouble and nobody noticed, what other projects are in the same situation, and how can we prevent what happened to OpenSSL from happening to other projects.
Neither way is necessarily "The only right way", or even better than the other way. In fact, both approaches complement each other. OpenBSD fixes the actual current problem child, Linux Foundation is on the hunt for the next problem child
Just open up the editor and start coding. Pick something off that list, and hammer away at it. It may suck, but just keep going, re-write it, pick something else on your todo list, but keep going. The secret is: There is no "zone", there's hard work, and perseverance. The "zone" is just a figment of your imagination.
But this very constraint is what drives projects like M-PESA, and Ushahidi, and BRCK.
Also, Software Developers in the US and Europe don't necessarily make 100,000 Dollars. In some spots you'd be luck y to make half that.