That is something I don't like about Linus. He's so aggressive when he speaks; it's insulting. Explaining to the guy the good attitude to have toward backward compatibility and "not my problem" thing, is totally great. However, doing it in a so harsh tone is just plainly aggressive and useless. In fact, I'd argue that it is even less than useless as if someone talked to be like that, I'd be even less reticent to try to help. Add to this the fact that Linus, being well known and respected, simply demolished him. It's like if I kicked my little 12 years old cousin' ass in front of everyone to make him understand that we he did wasn't right. Good job Linus. I feel like posting on this forum now.
A spec is a contract between programmers and in the long run, it's better (for users and programmers) to follow specs and expect others to follow them, rather than to let others break them willy-nilly and just bend over backwards to accomodate.
Oh, but I guess since this point requires actual thinking to understand, it's not in the realm of reality...
These fights between "specs lawyers" and "pragmatic" programmers are painfully frequent. Reminds me of the ext4 controversy on the out-of-order metadata synchronization.
> Torvalds has his own take on this, which is that "For some reason, compiler developers seem to be far enough removed from 'real life' that they have a tendency to talk in terms of 'this is what the spec says' rather than 'this is a problem'."
Agreed. We have to produce a lot of paper doc in my domain, and in our bug base, there's a section dedicated to spec bugs. Just cos it's in the spec doesn't make it right.
"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.
"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."
This 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.
Assigned to the inimitable Ulrich Drepper, who comments:
"The existence of code written by people who should never have been allowed to touch a keyboard cannot be allowed to prevent a correct implementation."
I wanted to note that Ulrich Drepper has proposed a way around the issue, and clearly said at the end "I'm happy to entertain a patch to this effect."
When I first read the parent comment it sounded as though Ulrich immediately shot it down, which he did not. (Note I'm not blaming the OP of the parent comment for this, I am just trying to help future readers from making the same mistake I did)
While he is not immediately agreeing with what Linus proposed, at least it is progress.
"The existence of code written by people who should never have been allowed to touch a keyboard cannot be allowed to prevent a correct implementation."
Sounds like Drepper needs to read the standard C library spec (or else there's a human-language barrier at work here). It is not incorrect to map memcpy() to memmove(). ("Be conservative in what you send, and liberal in what you accept." -- Postel)
Can anyone imagine this debate happening inside Microsoft? This is why they win.
Going down the thread I found this little gem in one of Linus' replies:
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.
I find it interesting that Linus seems to have originally come across this particular bug report as a user; he, too, was having a problem with Flash player:
The ANSI C standard defines two functions: memcpy, which
is fast but might overwrite memory if source and destination
overlap; and memmove, which might be slower but will always
be correct. The burden of choosing correctness over speed
should not be placed upon the programmer; there should be
only one function. Pretend there is, and always use memmove.
I may be overdoing it a bit here, but personally I don't agree with Torvald's p.o.v. at all. While user experience is obviously important, allowing mistakes like this to go unchallenged by simply providing a work-around just encourages people to write broken software. Specs exist for a reason. Ignoring them is not it.
I do this in my own software as well. If a user files a bug because input X fails to process as expected -- and it turns out his/her input does not meet the spec -- I do not supply a fix. Even if his/her supplied input is widely used in 'the wild'. While this alienates a considerable user base, I refuse to be part of the problem.
Scoped properly, he's entirely correct. The user doesn't care about standards. The user cares that STUFF WORKS.
Standards serve a purpose - but standards are guidelines.
Adobe & Redhat had no contractual obligation I assume, so really it's up to either of them to fix the problem - and in fighthing about who did what wrong is pointless if a couple lines of code ora few hours of work are all it will take to make things work.
In this particular situation, the standards were not helping get things up and running, right?
Are you referring to POSIX? Because if so, you should know that it is a shining example of a worthless standard and that most unix programs rely on unspecified behavior far more than this easy-to-make flash bug.
A spec is a contract between programmers, and in the long run, following specs is good for users. Letting Adobe ignore specs and then bending over backwards to accomodate them doesn't seem like a good policy.
And even if following the spec weren't better for users in the long term, it is technologically superior, and Fedora is free to choose the technologically superior alternative over pleasing the masses if they want. Despite what Linus suggests, there is no Ten Commandments of software that dictate the rules here.
I guess Linus could have used this opportunity to convince a naysayer like me why I'm wrong, but instead he was just insulting and didn't address the real points at all.
So, glibc changes, breaks adobe, and it is adobe's fault? Even if adobe was relying on bad behavior, it was glibc's bad behavior it was depending on.
These are the kinds of problems that finally convinced me to move from Linux to OS X. I get the Unix without the egos (just the fanbois, but I can usually ignore them ;).
It's always a trade-off, but in this case the cost is minimal. If your program is limited by the speed of memmove/memcpy(), and you absolutely must copy (rather than alias, or whatever), you probably want to use a 128-bit aligned, widely unrolled SSE copy or something like that. That is, take advantage of the constraints of your precise situation. You can't do that with an API as generic as memcpy().
While I agree with his focus on users, he has passed up a valuable coaching opportunity and probably antagonized a whole bunch of developers. He turned a potential coaching opportunity into a pissing match. Ridiculing volunteers on a open source project is inappropriate, irrespective of whether the opinion of that person was right or wrong.
Although I like the attitude on some level and in this case he is obviously right, the problem with it is that our (and others I know) programmers feel like cowboys after reading HN posts like this. 'Ruby master bla says I don't need comments and documentation man!' 'Testing is sooo 00s; we use our brains!' 'Specs and standards are paper, read Torvalds; he uses that in his watercloset! Yeah he isn't talking about specs, but those are paper too!'.
Specs are great: Java and Scala both have specs. Not having a spec can be OK if the language designer doesn't change things too often, and announces it well in advance when they do, e.g. Python.
What's worst is, say, when the language "Product Manager" leads a standardization committee that hasn't done anything for 7 years, yet often changes the language implementation overnight so code samples in other people's books and blogs no longer work.
Is this submission a deliberate attempt to make Linus look bad? The title is not at all what his comment amounts to; it could be removed from comment post without changing the meaning. I don't doubt you can find a multitude of quotes of Linus in support of various, official or pragmatic, standards. He was just polemizing.
It wasn't an attempt to make him look bad. I think many/most people here would agree with the sentiment about standards vs actual usage. And that line was delivered with classic Linus style - blunt and with the subtlety of a chainsaw. That's why I chose it for the title.
Keep in mind the specs were written to standardize the behaviour that existed at the time: there were implementations of memcpy that worked a bit faster because they didn't have to test for overlapping regions. That's why there's a separate memmove function in the first place.
So people saying that memcpy should work like memmove are really the ones advocating for changing a spec that is currently quite explicit.
Enabling this type invalid behavior from app code is a classic example of introducing dependencies on undocumented behavior. Over time these dependencies accumulate in complex systems with the resulting effect of increasing software incompatibilities, not reducing them.
[+] [-] fleaflicker|15 years ago|reply
Reality is what matters. When glibc changed memcpy, it created problems. Saying "not my problem" is irresponsible when it hurts users.
[+] [-] d0m|15 years ago|reply
[+] [-] javert|15 years ago|reply
Oh, but I guess since this point requires actual thinking to understand, it's not in the realm of reality...
[+] [-] ot|15 years ago|reply
Linus himself has already expressed his point of view many times, for example here (http://www.h-online.com/open/features/GCC-We-make-free-softw...):
> Torvalds has his own take on this, which is that "For some reason, compiler developers seem to be far enough removed from 'real life' that they have a tendency to talk in terms of 'this is what the spec says' rather than 'this is a problem'."
I couldn't agree more.
[+] [-] bmj|15 years ago|reply
[+] [-] lallysingh|15 years ago|reply
[+] [-] chuhnk|15 years ago|reply
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
"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|15 years ago|reply
[+] [-] ximeng|15 years ago|reply
http://sources.redhat.com/bugzilla/show_bug.cgi?id=12518
Assigned to the inimitable Ulrich Drepper, who comments:
"The existence of code written by people who should never have been allowed to touch a keyboard cannot be allowed to prevent a correct implementation."
[+] [-] mitchellh|15 years ago|reply
When I first read the parent comment it sounded as though Ulrich immediately shot it down, which he did not. (Note I'm not blaming the OP of the parent comment for this, I am just trying to help future readers from making the same mistake I did)
While he is not immediately agreeing with what Linus proposed, at least it is progress.
[+] [-] CamperBob|15 years ago|reply
Sounds like Drepper needs to read the standard C library spec (or else there's a human-language barrier at work here). It is not incorrect to map memcpy() to memmove(). ("Be conservative in what you send, and liberal in what you accept." -- Postel)
Can anyone imagine this debate happening inside Microsoft? This is why they win.
[+] [-] famousactress|15 years ago|reply
[+] [-] hyperbovine|15 years ago|reply
[+] [-] j2d2j2d2|15 years ago|reply
http://tech.slashdot.org/story/05/12/13/1340215/Torvalds-Say...
[+] [-] bonch|15 years ago|reply
[+] [-] DeusExMachina|15 years ago|reply
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.
[+] [-] mjs|15 years ago|reply
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c8
"I see this as well. Sounds like clipping or some really bad sample rate frequency conversion."
(It's only later that it becomes clear that this is due to a glibc "regression".)
[+] [-] acqq|15 years ago|reply
http://www.tuxradar.com/content/debian-ditches-glibc-eglibc
I consider all this a real attitude problem.
[+] [-] s3graham|15 years ago|reply
Also, static linking.
[+] [-] genera|15 years ago|reply
[+] [-] exch|15 years ago|reply
I may be overdoing it a bit here, but personally I don't agree with Torvald's p.o.v. at all. While user experience is obviously important, allowing mistakes like this to go unchallenged by simply providing a work-around just encourages people to write broken software. Specs exist for a reason. Ignoring them is not it.
I do this in my own software as well. If a user files a bug because input X fails to process as expected -- and it turns out his/her input does not meet the spec -- I do not supply a fix. Even if his/her supplied input is widely used in 'the wild'. While this alienates a considerable user base, I refuse to be part of the problem.
[+] [-] dedward|15 years ago|reply
In this particular situation, the standards were not helping get things up and running, right?
[+] [-] aidenn0|15 years ago|reply
[+] [-] javert|15 years ago|reply
And even if following the spec weren't better for users in the long term, it is technologically superior, and Fedora is free to choose the technologically superior alternative over pleasing the masses if they want. Despite what Linus suggests, there is no Ten Commandments of software that dictate the rules here.
I guess Linus could have used this opportunity to convince a naysayer like me why I'm wrong, but instead he was just insulting and didn't address the real points at all.
(And FYI, I'm a diehard Linux user)
[+] [-] SoftwareMaven|15 years ago|reply
These are the kinds of problems that finally convinced me to move from Linux to OS X. I get the Unix without the egos (just the fanbois, but I can usually ignore them ;).
[+] [-] linuxguy|15 years ago|reply
How hard can it be to understand the following simple sentence:
[+] [-] pmjordan|15 years ago|reply
[+] [-] yuvadam|15 years ago|reply
[+] [-] irfn|15 years ago|reply
[+] [-] srram|15 years ago|reply
[+] [-] dtby|15 years ago|reply
I'm not a Linux guy, so I am out of the loop. What makes these writings so lovable?
[+] [-] guan|15 years ago|reply
[+] [-] bcl|15 years ago|reply
[+] [-] rwmj|15 years ago|reply
[+] [-] tluyben2|15 years ago|reply
[+] [-] vorg|15 years ago|reply
What's worst is, say, when the language "Product Manager" leads a standardization committee that hasn't done anything for 7 years, yet often changes the language implementation overnight so code samples in other people's books and blogs no longer work.
[+] [-] pnathan|15 years ago|reply
[+] [-] Confusion|15 years ago|reply
[+] [-] statictype|15 years ago|reply
[+] [-] marshray|15 years ago|reply
So people saying that memcpy should work like memmove are really the ones advocating for changing a spec that is currently quite explicit.
Enabling this type invalid behavior from app code is a classic example of introducing dependencies on undocumented behavior. Over time these dependencies accumulate in complex systems with the resulting effect of increasing software incompatibilities, not reducing them.
[+] [-] sriramk|15 years ago|reply
[+] [-] rcthompson|15 years ago|reply
[+] [-] rch|15 years ago|reply
But! what's interesting is how much I dislike the first sentence of comment 133.