You know, Burning Man used to have a drive-by shooting gallery. With guns, and cars, and is just as libertarian as this festival. The difference is, Burning Man encompasses much more than just libertarianism.
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.
Never delete code. This is why you have git or svn, or whatever your tool of choice is. Never, ever delete code. You may think it's dumb, you may think it's crap, or useless or whatever, but in 2 years, you'll think. "Damn, I remember doing this already, don't I have some code in somewhere?" And you will.
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
Nah, SCM tools were not made to be your personal snippet collector, you're better off just getting a real one if you're the hoarder kind of programmer.
Sometimes you just need to burn the pictures of you with your ex and move on. In some way, you should "KEEP" everything, after all digital space is cheap right? But you can keep a lot of code around that you will never revisit in the future.
> but trust me, re-writing code is way easier than writing it from scratch
> > but trust me, re-writing code is way easier than writing it from scratch
> Not always true, and not even often true.
In my experience, virtually always true. Just rereading the code you wrote before will bring back the understanding you had when you wrote it (unless you intentionally wrote obfuscated code, I suppose?), and it'll be immediately obvious to several-years-on you what the shortcomings were of that idea. If you have the time, a full rewrite almost always turns out to be better code than the old version, as long as you can hold off on trying new experiments in the process.
You can always take the experience, but often the old code exists in such a misguided architecture that it is better to scrap it vs. unwind multitudes of bad uninformed decisions (b.c. you know better now!).
Re-writing code is actually almost always harder than writing it from scratch, but we do it for other benefits: interoperability with legacy components, legacy of expected behavior (warts and all), risk (the old code is debugged), and culture (programs in the team know that code). But if you don't have those requirements, you will often come out behind in rewriting all code rather than going with a green field.
It also depends on whether the work one is doing is cutting edge (lots of experimentation and learning required) or basic dev work over relatively well known concepts.
It'd be a first if it works properly. NM has been a pain point for me for years. There is always something that doesn't work properly.
Also it's impossible to debug easily. VPN not connecting? NO DOCUMENTATION.
Typically when something doesn't want to work as well you end up with a "download the latest VPN RPM" situation which doesn't actually compile against that version of NM because the API is unstable as hell.
Fascinating insight into a bit of Jobs life that is mostly overlooked, except as a "He used to be a hippy" anecdote. Steve Silberman does a good job of teasing out the bits and assembling a better vision of Jobs's belief system, and how it informed his work at Apple and NeXT
Please, before posting links to Wikipedia entries, give it some context!