Torvalds: Standards are paper. I use paper to wipe my butt every day.
bugzilla.redhat.com
bugzilla.redhat.com
Reality is what matters. When glibc changed memcpy, it created problems. Saying "not my problem" is irresponsible when it hurts users.
Oh, but I guess since this point requires actual thinking to understand, it's not in the realm of reality...
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...
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.
That has never been the ethic here: http://news.ycombinator.net/item?id=117171 http://news.ycombinator.com/item?id=392347
EDIT: Well, on second thought, notice that in both cases, although pg stated the he thought downvotes should be used to express disagreement, more upvotes were given to other commentors that though downvotes should only be used to boo rudeness (which is my personal opinion, as well). So I think maybe there is a division in the community on how this is supposed to be done.
Actually, the experience I was just whining about is case in point for why some people think downvotes should only be used to boo rudeness. I think a lot of people downvoted me just because there was a response to me that was strongly worded, even though it was (in my opinion) not really even relevant.
The first sentence of your post that is being downvoted is okay; it contributes something to the conversation:
> 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.
I believe your second sentence is the reason you're being downvoted:
> Oh, but I guess since this point requires actual thinking to understand, it's not in the realm of reality...
That sentence is sarcastic, insulting to people's intelligence, and contributes nothing to the conversation. If you lose that attitude, I think your contributions would be better received.
I was parodying Linus.
I was making the point that that's exactly what you should not do.
Your comment was a passive-aggressive declation of stupidity in the other party.
The two are not the same.
Well, that is exactly how I perceived Linus' comment, which is why my comment came across that way.
Clearly I was wrong, but I thought everyone would find it obvious that Linus' reply was pretty much unacceptable (and thus understand the point I was trying to make... which was not a passive-agressive declaration of stupidity in the other party, despite how it came across).
As least in the comment that was linked to, all he does is "yell" (all caps) at the person he's attacking, and although he presents an argument, it doesn't address the things his attackee actually said; I (personally) found it to be thoroughly unsatisfying in an intellectual/technical sense.
No, I in fact have not; I just looked at Andre's last comment and Linus' flaming response which did not address his points and was very rude.
You may be right that Andre was being a pedantic, obnoxious, rigid idiot. I have no idea, I didn't read the thread. My only point is that "THE USER IS ALL THAT MATTERS" is not a valid software principle and that rather than communicate anything useful, Linus just yelled at people (in the particular commen that was linked to from HN).
Even worse, you aren't interested in getting a clue by reading the damn material.
However, I was pissed off by one of Linus' comments (which, taken by itself was pretty ridiculous), and made a comment on HN about it.
My comment was sarcastic in a way that I think was misunderstood and made many people angry. Many insults were hurled my way, and I tried to defend myself, resulting in an ever-worsening spiral. It's pretty much just become a massive shitfest.
I wish people hadn't been so quick to attack myself and my character (yourself included). This kind of thing is definitely contributing to the decline of HN, which is something being discussed lately (as always, I guess). And, yes, I'm contributing to it too by even trying to defend myself, or maybe by defending myself too aggressively.
I can understand if you read the whole 100+ thread and then point out that what I'm talking about is completely unrelated. That's true, but I wasn't talking about the whole discussion; just picking at a bit of unreasonable rudeness on Linus's part that failed to make any intellectually worthwile point. And I stand by that: the individual comment I was picking at (i.e., the one linked from this HN post) was pretty ridiculous.
If you intend this as defense, you'd best go back and look at your posts. You've been plenty rude, and arguably at least a little malicious.
That's because it's not.
The spec ( 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.
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 */;)
Seems to me kind of an important thing to recognize in this kind of discussion.
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.
So in a way, it is about supporting legacy software.
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) :-)
"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?
"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.
What's the goal of Fedora? To satisfy intellectual purity or to make sure software runs for it's end users?
I know in some ways Fedora is a testing ground for Red Hat, and if that's the "purpose" of Fedora, then the reason for doing anything shouldn't be "user experience" but "being a testing ground for Red Hat." Which may lead to the same thing, but is not the same thing.
I mean, there really is no 11th Commandment that says "Software is all about the user." No, it's about whatever the programmer(s) making the software want it to be about.
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.
How should Linus have addressed the other guy?
This causes massive compassion fatigue. Take that into account, and it becomes clear that Linus is not as big an asshole as you think.
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"!
They being so damn smart does not give them the right to be condescending and insult people who can't keep up. So I'm not as smart as he is, does that make invaluable? Does that give him the right to call me stupid? What if I am doing my best? If my best try isn't really helping, then they should simply ignore me, not attack me. Nothing gives anybody the right to insult people.
It's the guiding principle here on HN: be civil. Just like others need to polish their technical abilities, being nice is something they should work on.
In general, sites like Hackernews or Stackoverflow wouldn't work at all if smart people couldn't handle answering basic questions without being jerks.
For every Steve Wozniak there is a Steve Jobs.
It might also be a european thing. We are more direct. Less talking around the issue at hand.
They eventually learned to do the initial sell in a much more sideways manner as when confronted with 'do you want this or not?', British clients tended to just say yes to get them out of the office - even if they had zero intention of taking the product. Caused a lot of confusion until that was identified.
>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.
you sound like you're an ass with overgrown ego.
In general, one chooses whether to get things done or waste the time on gentle handling of ego of the people who can't control their own ego. It is a great boon for humanity that Linus has been choosing the former.
See, in your post, the "You're an ass with overgrown ego" doesn't help your point at all; it's just provocative and seen as aggressive.
Try to remove that phrase from your post and you'll see that there's no difference at all. In fact, you would have wasted a little bit less of everyone's time. (See how easy it can be to be aggressive and provocative; even thought it wins nothing at the end.)
Anyway, if I understand your post, you are saying that either you gets things done or you're ass kissing the ego of people. First, that is plainly totally wrong. You can be productive without being an ass. Secondly, not being aggressive, is not the same thing as ass kissing.
It's like fighting to win a battle or a war. By being aggressive, you fight to win that small battle.. but if the contributor is pissed enough and decide to not work with some asses, everybody loses.
That exactly what Linus did.
>you are saying that either you gets things done or you're ass kissing the ego of people. First, that is plainly totally wrong. You can be productive without being an ass.
if you analyze the logic of your statement you'd find what it puts "not ass kissing the ego of people " as equivalent to "being an ass". We're back to square one.
Quite frankly, I find your attitude to be annoying and downright stupid.
He was being insulting and unnecessarily aggressive.
Post #128 was stating logic and facts. Linus responded with logic and facts also, but before he did so, he stated the insult. Unnecessary and didn't add anything to the debate except emotional provocation.
If someone else doesn't get it, he can say, "This is my point, I hope it makes sense, if it doesn't, I don't know what else I can do to make you understand me." Something like that. And then just stop replying. Instead, he turns it into a pissing match.
> you sound like you're an ass with overgrown ego.
stands in direct contradiction to this expressed desire:
> get things done [and not] waste ... time
because what you think the other person sounds like is not relevant.
This:
> Absence of ass kissing isn't an insult.
is useless for a different reason. If you are a manager, which Torvalds is, you need to be able to keep the people you're managing in a usable state. This is only very rarely done with brusqueness.
If you're trying to make a world-class product, you can't afford the time to wrap all comms with your developers in niceties - you need to define where you stand and what's expected in solid terms.
Also: given his thorough explanations that go along with the chiding, I'd much rather be on a forum that has that kind of poster.
For the record, Linus's behaviour is not typical of Asperger's Syndrome.
"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".
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"."
Not being an ass isn't difficult with practice, and it can even save time when communicating.
Go back and look at the thread. Linus isn't wading in with abuse. He's a solid part of the discussion from the start (I stopped counting his responses when I got to 7 in the first 50) and at least for those first 50 he's polite as everyone seems to demand him being. Explaining both his point about the function and about the user-doesn't-care view, repeatedly, politely - just as all the naysayers in this thread are demanding of him.
Heaven forfend Linus actually show frustration at having to repeat himself again and again, like an ordinary human would!
Molehill, meet mountain.
But I don't think I'm really in a good position to advise Linus on how to manage an open-source development community. Linux seems to be running at a high level of average competency despite the occasional hostility. Who am I to say that the hostility is dispensable? I'd like to believe it is, but I want to see an existence proof.
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.
Applications are complex, fragile things. If you care about keeping them going over time, you wind up kowtowing to a lot of workarounds. Welcome to the software industry.
The attitude of "I can change library Z, be spec compliant and still sleep at night even though the change took half an industry down" might be /correct/ but it is not going to retain customers. Do it enough, and you'll see users flee.
Unless there's no where else for them to go. :)
"Nice business you have here. It 'ud be a shame if something were to . . . /happen/ to it? Right?"
"Right, boss."
"Shaddap, I ain't talkin' to youse."
It's a successful, ancient business model.
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."
exposure of a random proprietary software bug written by morons does not imply breakage of "binary compatibility". some free software developers have no time to test their standard compliant library against all crappy proprietary software ever written under the sun. if that makes you sad, at least you are free to modify the fucking library for your own little use case, or even to fork the library and maintain your fork with an explicit policy of never ever changing externally observable behaviour (probably meaning you won't make any change to said library (other than in comments) if you REALLY apply this rule...), which happily glibc never had and hopefully never will have.
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."
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.
Bear in mind that I'm an experienced developer, and consequently am reluctant to call someone a "moron" who should "not be allowed to touch a keyboard" on the basis of the occasional bug in their code.
Yes, confusing memcpy() and memmove() is a novice mistake, but I've done dumber things, and it'd be nice if my users didn't have to pay the price. If the OS or CRTL can save them from my error by rendering the error harmless without any real downside, then it should do so.
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.
http://tech.slashdot.org/story/05/12/13/1340215/Torvalds-Say...
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.
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".)
http://www.tuxradar.com/content/debian-ditches-glibc-eglibc
I consider all this a real attitude problem.
The function below addresses the perennial programming quandary: “How do I take good data in string form and painlessly turn it into garbage?”.
To make the argument that strfry isn't a joke, you might find a real program that uses it productively. I'd be interested in seeing if one exists.
NAME
strfry - randomize a string
[snip]
DESCRIPTION
The strfry() function randomizes the contents of string by using rand(3) to randomly swap characters in the string. The result is an anagram of string.
[snip]
COLOPHON
This page is part of release 3.32 of the Linux man-pages project. [snip]
What version of the man-pages package do you have installed?
In any case, I'm not wrong about strfry being a gag function, and it looks (if you read upthread) that my hunch was right that nobody uses it in real code.
(Oh, pardon. I didn't catch that you might have thought that I thought that strfry was anything but a joke. My take on the situation is that the documentation needs patched, rather than the strfry code. :) )
But this one is "It's broken, this is how, this is data confirming it, this is a patch and that's how it's fixing the issue." The work is done - review, apply, release. Or if it's considered such a joke that it's not worth fixing, just remove it completely.
Seems to say it isn't used. I also contest that it _is_ broken. I cannot find a man page that promises that it uses a uniform distribution; one could even argue that such a function should not use an uniform distribution. For example, randomizing the non-uniformity of the distribution depending on the phase of the moon would, IMO, be a good idea for this function.
When presented with a model bug report (includes good description, test cases, and even a patch) he felt the need to change the function, but instead of using the supplied patch he rewrites it himself and commits it without testing it. It is still broken. When this is pointed out he gets angry and complains about people wasting his time, when it was he that decided to waste his own time rewriting it his own way and he was the one that still got it wrong.
Everyone would have been better off if he had taken the sensible path of "read bug report", "confirm bug", "test patch", "commit patch" instead of arguing and rewriting things out of spite.
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.
Also, static linking.
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.
By the way, if flash was open source it would probably be a one line patch to fix the issue, but it's not, and I wouldn't blame the fedora/glibc devs for that. Breaking things because "you can" is no good policy, but it doesn't mean you have to be backward compatible for ever, that's what being realistic is about.
There has to be great benefit from changing the implementation of memcpy for it to be worth it. And broken flash is an obvious negative. And across the said thread, there is argument that the new implementation might not be the best as well. So, with two negatives and no obvious positives why do it at all?
In this particular situation, the standards were not helping get things up and running, right?
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)
How hard can it be to understand the following simple sentence:
THE USER DOESN'T CARE.The user doesn't care, but professional software developers, which I assumes Adobe's developers are, should make it a priority to follow the relevant standards.
It also indicates that Adobe don't run their code through valgrind, which would have picked this problem up.
Considering that flash is (a) security critical and (b) often full of security bugs, you'd think they might run valgrind over it once in a while.
Entirely Adobe's fault this one.
BTW with Firefox 4 the need for flash has virtually gone. All the popular video sites can play most of their videos using the native video support in the browser.
Oh, and its perfectly fine for me to change the behavior from one to the other, or even have a lookup table of random responses to undefined behavior. Because, like, you're not following the standard. And its so easy.
Only for signed integers. Unsigned integers are defined to wrap around.
If memcpy() had been fixed 30 years ago to do overlapping moves correctly, as it could and should have been, that would have been the end of it; we would not be having this conversation.
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 ;).
win95 had a similar one with the game Civilisation, they actually put code into win95 to detect the game and change the way the OS worked - doesn't sound like a good solution
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it [...] the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
Also, to quote Linus:
"And what was the point of making [an OS] again? Was it to teach everybody a lesson, or was it to give the user a nice experience?"
Adobe should not rely on non-spec-defined behavior, but there's no reason why glibc <i>should</i> be making this change without making a major version number change.
Hmm. Well, I was assuming that glibc was following the spec all along but just changed some implementation detail that mattered because Adobe wasn't following the spec all along.
I think there's an argument to be made that the way an API is implemented is an implicit contract that ought to be upheld. But that's not the arugment I see being made.
Anyway, this level of detail is below the scope of the "specs vs pragmatism" debate that's going on.
That sounds wrong to me. If your consumers have to rely on assumptions beyond what's provided in the contract of the API, your API is leaky and/or broken.
[edit] I understand the pragmatism necessary in the case of the glibc issue, but to clarify my point I disagree with the general assertion I'm quoting.
Wasn't it implementation details it was relying on? Isn't NOT relying on implementation details pretty much the basis of good software engineering?
This reminds me of Joel Spolsky's article, "How Microsoft Won the API War:"
"There are two opposing forces inside Microsoft, which I will refer to, somewhat tongue-in-cheek, as The Raymond Chen Camp and The MSDN Magazine Camp.
Raymond Chen is a developer on the Windows team at Microsoft. He's been there since 1992, and his weblog The Old New Thing is chock-full of detailed technical stories about why certain things are the way they are in Windows, even silly things, which turn out to have very good reasons. . .
The other camp is what I'm going to call the MSDN Magazine camp, which I will name after the developer's magazine full of exciting articles about all the different ways you can shoot yourself in the foot by using esoteric combinations of Microsoft products in your own software."
He thinks the MSDN camp won, and that's bad, and he contrasts with, say, Apple in historical times:
"A lot of developers and engineers don't agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It's why so few applications from the early days of the Macintosh still work. For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to. Even though somewhere in Inside Macintosh, Apple's official Bible of Macintosh programming, there was a tech note saying "you can't do this," they did it, and it worked, and their programs ran faster... until the next version of the OS came out and they didn't run at all. If the company that made the application went out of business (and most of them did), well, tough luck, bubby.
To contrast, I've got DOS applications that I wrote in 1983 for the very original IBM PC that still run flawlessly, thanks to the Raymond Chen Camp at Microsoft."
The thing is, Apple is still mostly like that. Want the new hotness? Upgrade. I've been using OS X since 2004 and have trouble remembering all the stuff that broke because of OS updates (NetNewsWire and printing were particularly common). I don't know if it's because of the MSDN camp in Apple, but I do find it ironic that you cite things breaking as a reason to move to Apple. There are plenty of them, but I'm not sure that's one.
Apple did in fact do a lot of bending over backwards for compatibility, at least when it was a major developer breaking the rules. System 7 had special code in the memory manager for Microsoft applications to make them work with the 32-bit memory manager and virtual memory.
That said, Microsoft does do an outstanding job in this area. I remember when Win98 was coming out, we were not in the beta program at work. We got a call from Microsoft telling us that a VxD of ours was not working on Win98, telling us what assumption it was making that was no longer valid, and inviting us into the beta program. We were not a large, well-known company. That was pretty cool.
Yea, MultiFinder had special code to load old MS applications like Excel 1.5 below the 1MB line because they were only 20-bit clean.
Incidentally, I think this figured into Apple's thinking regarding limited back-compat. They had already unintentionally forced a number of application upgrades, why not do something positive like move everyone to a new OS/CPU/API in the process?
To be clear, things breaking wasn't what I was referring to. Generally, things worked very well on Linux (except [at the time] suspending and wifi on my laptop) and I know they've gotten better.
On the other hand, there was far too much focus on software for the developer's sake and not software for the user's sake for my tastes (even as a developer). I'm fine with the people who are developing the (almost exclusively) open source software developing it for themselves, but it was too much headache for me, so I did the proverbial "voted with my wallet".
I still use Linux a lot, it is the platform my startup is deploying on, and it amazes me every time I ponder the changes to the entire community since kernel version 0.9'ish and slackware when I first started using Linux. I actually trust the Linux community far more than Apple to keep things working over a longer-term timeline (which is great for servers, but I don't care much about on my desktop).
The memcpy() function is marked specially in the ELF file. On the first invocation, the dynamic linker actually calls the function and then takes the return value and treats it as a function pointer. This function pointer is then used for linking, so that subsequent invocations will call that pointer instead.
The memcpy() function in glibc then simply checks which SIMD extensions are available and returns a pointer to the appropriate real memcpy to use.
I'm not a Linux guy, so I am out of the loop. What makes these writings so lovable?
I think he's right, I think it's important to defend what he thinks is right, and I understand how it can be frustrating, but we all just have to have the fortitude keep the flames in check.
The ones with content. In the sample quotes in the article, Linux is attacking ideas and attitudes, not people.
???
In the comment I read, he goes into detail about why it's wrong.
His next comment that starts "Bullshit." goes into 500 words of coaching.
He is backing up his arguments with developer-level people here, not newbie coders who are still figuring out how an array works.
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.
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.
But! what's interesting is how much I dislike the first sentence of comment 133.
He said Youtube worked fine. It was compared to as a control. The problem was with some other site using Flash.
He misunderstands how the world works. Standard is not just paper; standard is the thing. From this site: http://science1.wordpress.com/2007/04/26/matter-does-not-exi...
For physicists Newton’s atomic materialism is blinding.
It will take many generations of humans to perceive that
standard is the thing. There is no “physical” world
other than standards and density differentials.I prefer more people standing against intransient word & law. (Much is called Standards, or Rights.)
Codes hold you.
Our support systems could allow critical viewpoints better.