7 ms·
That's a deceptive title. The real point is more important (but less sensational): Reality is what matters. When glibc changed memcpy, it created problems. Say
by fleaflicker 16y ago
That's a deceptive title. The real point is more important (but less sensational):
Reality is what matters. When glibc changed memcpy, it created problems. Saying "not my problem" is irresponsible when it hurts users.
- javert 16y agoA 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...
- mrcharles 16y agoI understand your point and the purist programmer in me agrees but maintaining compatibility in the face of horribly broken software is how Microsoft managed to get on top with windows. If you've ever spent time reading The Old New Thing ( http://blogs.msdn.com/b/oldnewthing/ http://blogs.msdn.com/b/oldnewthing/ ) you'd realize the lengths MS went to to make sure that even when they improved things, they didn't break bad software, and how much that meant for people adopting the platform. Seems to me kind of an important thing to recognize in this kind of discussion.
- javert 16y agoThanks for the thoughtful response. I sort of agree with you but I think what you're saying applies to a different context. As the person who was rudely lambasted by Linus pointed out, Fedora is not there to "get on top." It shouldn't be trying to go by the same metrics that Windows goes by. And this isn't an issue of supporting legacy software; if Fedora makes a particular decision, Adobe can just update their software to follow suit.
- mrcharles 16y agoAnd I agree with you, but Linus is still right that the user is more important. When a Fedora user sees that Fedora is broken, all the user knows is that Fedora is inferior to other things. So in a way, it is about supporting legacy software.
- javert 16y agoBut there is no moral commandment that "the user is more important." The goal of software is the goal of its developers; it's up to them. Someone very well could say, "this software is an exercise in intellectual purity." Or, "this software is to scratch the developers' particular itches, which may or may not be the same thing as satisfying most users." Maybe Fedora in particular has a mission statement that says, "The user is most important," but I'm not aware of it. I'm certain that's not the case for the distro I use (Arch Linux) :-)
- mrcharles 16y agoThey have two quotes on their front page: "Since its first version, in 2003, Red Hat's Fedora Linux has been the best place to track what's on the leading edge of Linux and open source software." — Jason Brooks, eweek.com "Fedora has [...] released an amazingly rock-solid operating system." — Jack Wallen, TechRepublic.com Are either of those quotes truly true if the developers are okay with breaking existing functionality?
- javert 16y agoI don't see it as "breaking existing functionality." I see it as "improving functionality." Albeit at the expense of Flash temporarily not working. Is it worthwile to pay that expense? For some software, yes, for some software, no. The point is that there is no solid rule here that is true for every software project ( in this case, every Linux distribution). "Since its first version, in 2003, Red Hat's Fedora Linux has been the best place to track what's on the leading edge of Linux and open source software." — Jason Brooks, eweek.com I personally would consider something like Arch Linux to be much more on the leading edge, and they would definitely not hesitate to improve their software at the expense of something possibly not working on somebody's system until they get the new update. Case in point: Arch Linux was the first to switch to Python 3 from Python 2. A long time after that probably should have happened everywhere. And everybody whined a lot about how it was "too soon" and lots of software would break. Personally, I haven't had any problems with that transition on Arch Linux. Did it break things for some people, temporarily? Yes. Did it move forward the state of the Arch Linux operating system and, honestly, Python 3 adoption in general? Certainly yes. If Linus had been on their forum yelling IT'S ALL ABOUT THE USER and telling people their attitude is stupid, maybe it wouldn't have happened. (Actually, he would have just gotten ostracized from the community.) In fact, they did get a huge amount of flak, but they stood up to it anyway.
- nddrylliog 16y agoSo what, if the spec says "jump off a cliff", you'd do it? Linus explains in-depth why the distinction between memcpy and memmove is arcane and useless nowadays, shows how glibc's over-engineering crap actually hurts performance instead of helping, and that being a tight-ass (ie. doing /more/ than the spec) just makes the situation worse for everyone. Are you all seriously thinking that Linus doesn't know about performance? He's not Miguel, dammit...
- DannoHung 16y agoWhy not change the spec to work right?
- mooism2 16y agoThat takes time. What do you do in the meantime?
- javert 16y agoSo what, if the spec says "jump off a cliff", you'd do it? This isn't relevant to the technical issues at hand; it's just an insult. Exactly what I was trying to criticize Linus for doing. (That was actually the point of my comment.) Are you all seriously thinking that Linus doesn't know about performance? No, that's completely unrelated to anything I said. I'm not familiar with the history of glibc here. I didn't read anything except the single comment from Linus that was linked to. And I'm only addressing the comments he made in that post. You have not addressed what I actually said, at all. I'm thoroughtly disgusted with the way I've been treated here, especially the number of downvotes I've gotten. What happened to the hacker news ethic of voting up things you like, but only voting down when someone is rude or malicious? Unbelievably, I'm now actually at negative votes. I guess I ought to take this as a signal that my comment was a disservice to this community, and consider that maybe I'm not wanted here. By the way, I'm not interested in continuing this thread.
- cma 16y ago>What happened to the hacker news ethic of voting up things you like, but only voting down when someone is rude or malicious? That has never been the ethic here: http://news.ycombinator.net/item?id=117171 http://news.ycombinator.net/item?id=117171 http://news.ycombinator.com/item?id=392347 http://news.ycombinator.com/item?id=392347
- fauigerzigerk 16y agoSeeing this purely as a spec v pragmatism issue isn't going to get us anywhere. There is just no way around looking at each case individually. There are specs that are pie in the sky, outdated, flawed compromises or reflections of vested interests. But there is also a huge amount of lock-in and lost productivity resulting from lack or disregard of specs (e.g IE6). I see no way to be principled on that one.
- javert 16y agoThanks. This is an insightful comment and, yes, I see your point and agree with it.
- jjs 16y ago> Seeing this purely as a spec v pragmatism issue isn't going to get us anywhere. That's because it's not. The spec ( http://pubs.opengroup.org/onlinepubs/009695399/functions/memcpy.html http://pubs.opengroup.org/onlinepubs/009695399/functions/mem... ) explicitly states, "If copying takes place between objects that overlap, the behavior is undefined." Which means the real debate is between two technically valid interpretations of the spec: one that arbitrarily breaks existing software for no discernible benefit✻, and one that does not. (✻ Unless, for ideological reasons, one believes that breaking said software is the benefit, in which case this is still a sneaky and passive-aggressive way to go about it.) It's even fair to cast this particular debate as nonsense vs. pragmatism, because that's what it is.
- andrewf 16y ago"Passive aggressive" hits the nail on the head. If someone truly believes you should break software that made bad assumptions about memcpy, as a matter of engineering principle, then just stick this at the top of memcpy and be done with it: if((src <= dest && src+len >= dest) || (dest <= src && dest+len >= src)) abort(); /* valid - spec says behaviour is undefined */
- s3graham 16y agoDAMN LIBC DEVS BROKE MY ABUTTING memcpyS! ;)
- gersh 16y agoContracts are written and signed. Specs should wikied.
- azernik 16y agoThis ideal is completely irrelevant here - the change Linus and many people are asking for here (aliasing memcpy to memmove) explicitly does <i>not</i> violate the spec; all the spec says is that memcpy is not <i>guaranteed</i> to work when the memory segments overlap. The conflict here is between going above and beyond the call of the standards and in so doing encouraging expectations of that extra functionality in all software, or implementing only the bare minimum specified by the standards and in so doing breaking software as actually written. Given that this change involved literally checking for the relation between the source and destination address, and copying upward in one case and downward in the other (in so doing, implementing a function which is <i>also</i> required in the standard) adding this functionality to the de facto standard does not significantly increase the barrier to entry for new developers. I think the ideal solution would be a note in the standard hinting that memcpy can be implemented with memmove, or even better, a deprecation of memcpy in favor of memmove with memcpy being in the interim aliased to memmove, but standards changes are always a pain.
- d0m 16y agoThat 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.
- sudonim 16y agoI read Linus' response as directed at people in the thread in general in addition to the previous poster. The "not my problem" attitude is pretty common in the world. In OSS, it seems even more important to be flexible in order to achieve something good for an end user. How should Linus have addressed the other guy?
- antipaganda 16y agoYou've got to understand that it is very hard for highly technically proficient people to be nice to everyone. For someone at Linus's level, a LOT of time is spent answering what seems like the worst kind of stupid questions. This causes massive compassion fatigue. Take that into account, and it becomes clear that Linus is not as big an asshole as you think.
- joe_the_user 16y agoYou've got to understand that it is very hard for highly technically proficient people to be nice to everyone. Of all the arguments for being brusque on the web, this is the one I find most unappealing... as well as the least applicable for the matter at hand. As far as I can tell, there's nothing about Linus' reply that depended on his admittedly high level of technical competence. In fact, it seemed he was saying "don't rely on being technically correct, consider the consequences"... in a way that got people's attention. "I'm smart, so it's OK to an asshole" is about as shitty as an attitude as "not my problem, I'm just going by specs" - in fact, it's kind of similar. ... I bet all the up-voters thought they were the "highly technically proficient people"!