The award is not for "contributions to the recording industry", it's for "significant contributions, other than performance, to the field of recording."
Steve Jobs' contributions to the "recording industry" may well have been negative or damaging, but they have nothing to do with the field of recording. They were entirely to do with content distribution, which is totally different.
But I didn't want to add too much more to the body of the post, or saddle it with footnotes which would have detracted from the ending.
On the other hand, I couldn't think of a better example to use. Except maybe the curvature of the Earth, but that'd feel like ripping off Asimov's "The Relativity of Wrong" essay. Any suggestions on a better example I could use next time? (Because it's not like posts like the GGPs aren't going to come up again)
Since the modern scientific method was invented approximately 400 years ago, not one single repeatable experiment has ever been devised, by anyone, anywhere, anywhen, which has been able to show an "irregularity" (truly random processes such as radioactive decay, quantum weirdness, and Heisenberg's uncertainty principle notwithstanding)
Occam's razor. Entities should not be multiplied unnecessarily.
When Newton discovered his laws of motion, he was right to accept them. When the scientists who followed him for the next 300-odd years accepted them, they were right to do so. Even though he was eventually shown to be wrong by Einstein, until that point, no-one had any good reason not to accept those laws. However, as soon as Einsten came up with new data, came up with new theories, came up with new experiments, came up with new evidence and proved Newton wrong, then scientists changed how they saw motion.
Yes, scientists should always be aware that their theories might not be correct, that there may be an edge case they've not seen yet. But until someone's actually found it, the best you can do is go with what you've got. If an experiment ever comes along to show that the universe isn't regular, science will use that to show how the universe is not regular. Anyone who refuses to accept the new evidence will not be, to all intents and purposes, a scientist. And science might have to do a lot of work to probe the boundaries (if any) of that irregularity and work out how much it affects the millions of experiments and observations that have been done over the last few centuries.
But until that time comes along, it's perfectly reasonable to assume that the universe is regular. Because that's what every experiement ever done has ever shown.
Your black swan argument could just as well be a 10-headed sheep argument. So what if no-one's seen them? No-one's proven that there aren't 10-headed sheep. So it's an absurdity to say they don't exist!
Bollocks.
If you show me a 10-headed sheep, I'll believe you. Until then, it is so mind-bogglingly unlikely that such thing exists that they are not worth considering in any reasonable model of the universe, and you're just engaging in philosophical wankery, not science.
If the 2nd law of thermodynamics proves that evolution is impossible, because of a local decrease of entropy, then it also proves that life and growth is impossible, because those processes are equivalent local decreases of entropy within a closed system of globally increasing entropy, only on smaller timescales. Therefore, given that life is actually possible, this shows that either the 2nd law of thermodynamics is wrong, or that his understanding of a "closed system" is wrong.
Yup, I guess that's why many European societies which have much tighter gun controls and lower levels of firearm ownership than the US are so much less polite.
Yes, my ATI drivers had a hand in this, but that's part of the problem itself: why do all new GUIs demand glossy, sugar-coated rendering at the cost of my processing power? [...] For the record, even KDE4's non-accelerated mode rendered incorrectly.
I used to be the biggest proponent of Linux around, but it is really difficult to advocate something when its quality is dropping so quickly, and you yourself are barely able to operate it.
If KDE4's non-accelerated mode is rendering incorrectly, then I suspect that that is a serious problem with your graphics card drivers, or maybe even your graphics card. Really. And if you're using an out-of-tree driver with serious problems, I don't see how you can claim that it's the quality of Linux that's the problem. The Linux devs have no influencing there at all.
Lots of people (e.g. all the KDE developers) have been using KDE4 all day, every day, for 4 years or so now. Don't you think they'd have the means, motive and opportunity to clean up such problems if they were experiencing them? The fact that they're not experiencing them (and, as an almost-worthless anecdote which I'll throw in anyway, neither am I) is a pretty good indication that the problems you're experiencing aren't in the KDE part of the stack which you share with them. Or in Qt. Rather, they're much more likely to be in the part of the stack which is unique to you - your drivers and graphics card.
While I agree with you that GNU touch with its extended date parsing is fantastic and worth the space it requires, that link does not make your point that
"touch" supports the --date=STRING feature, which contains a very elaborate parser for all kinds of weird ways to write the date, including locale support for different languages.
Rather, it specifically says that
The option-argument shall be a string of the form: YYYY-MM-DDThh:mm:SS[.frac][tz] or: YYYY-MM-DDThh:mm:SS[,frac][tz]
That reminds me of the Yes, Prime Minister foreign office 4 stage strategy. You've just outlined stages 1 and 2. I guess that once they can no longer deny it's anthropogenic, they'll move to saying that there's nothing we can do (stage 3), again absolving them of the need to do anything. Then they won't need stage 4 until after some coastal cities are already underwater and millions of climate refugees/victims are making their lives a misery.
you can't just turn up the thermostat and assume the room will stay the same temperature, nor can people simply burn more energy while living the same life style in the same body.
I don't see why not. You could just convert the energy to heat. The body's homoeostasis system will then expand the surface blood vessels, or start sweating, to dump the heat to the environment, just like it does whenever you get warm. It'd just be like having an artificially increased rest metabolism.
IANANP, but I did take some nuclear physics courses as part of my degree.
It's somewhat unlikely that there's an exothermic nuclear reaction in there. Iron/Nickel is the tipping point where you go from fusion being exothermic to fission being exothermic. (This is why elements up to and including Iron and Nickel are much more common than elements from Cobalt onwards; they can be made in a stable way in the core of a star for a while. Once you start to (try to) fuse these elements though, you suck energy out of the star and things go bad.) Copper is the wrong side of that limit.
Even putting that aside, while you're correct that fusion is not "new physics", "cold fusion" is, because of the need to get the nuclei together in spite of the electrostatic repulsion. Yes, catalysts/quantum tunnelling/whatever aren't "brand new physics" in that they are concepts we are aware of, but finding a way in which they can be applied to allow cold fusion would be a new application, and is what I was intending to encompass in my meaning.
However, this is kind of beside the point, as all I was really doing was obligatorily referencing xkcd.
You should really read through this thread (especially Linus Torvalds' comments)
I did, when the problem first hit. Linus is right for the code that he writes, in that the public APIs he is in charge of (the Linux kernel<->userspace boundary) does not have a normative public specification, is not designed to be re-implemented by multiple vendors (despite the BSDs impressive efforts), and, while the documentation (at least for syscalls) is generally pretty good, the only real definition in Linux of "what does this part of the API do?" is "whatever that part of the API currently does".
Linus' comments are dead right for the project he works on. However, he does not work on an implementation of The Standard C Library.
It is extremely unlikely that memcpy() outperforms memmove()
But... that particular change to memcpy() wasn't made on a whim, for no reason. Rather, it was specifically made so that memcpy() could seriously outperform memmove(), because you can do extra optimisations if you know that the source and destination must not overlap!
the sane cleanup is just to add a new guarantee for a previously undefined usage of memcpy.
So convince ISO to change the standard, and the C libraries will follow. Including glibc.
Plus, I'm not convinced that strncpy() is a good example of a function that has "fix[ed] the brain damage". IMHO strncpy() is pretty brain damaged itself, and best avoided. strlcpy() is better, although not standardised, and not in glibc because of perfectly well-reasonsed arguments by Drepper. So I much prefer snprintf(dest, sizeof(dest), "%s", src);
As an ex-smuggler who feels like going straight by, e.g. doing a little gas mining in an out-of-the-way place that won't attract much attention from the emp^H^H^Hauthorities, that sounds like just what I was looking for!
Very few who criticize Flash have ever [...] explored it's benefits for [...] cross-platform usability.
What the...?
Ha ha ha ha hahahahahahahaha!
*wipes tears from eyes* That's probably the funniest thing I've heard all day, thanks!
Flash? Cross-platform? You have got to be kidding! Or on crack. Or maybe you can point me to where I can get Flash 10.3 for *BSD/Solaris/Plan9. Or where I can get Flash for any OS running on IA64/generic ARM (not just Cortex-A8)/MIPS/PowerPC/Sparc/Alpha? Heck, they only started supporting x86-64 properly this year, despite that arch being over 10 years old.
Flash was using memcpy(3) incorrectly. It happened to work on older versions of glibc/x86 by chance. There was never any guarantee that it would work on later version of glibc/x86, or on non-x86 versions of glibc, or non-glibc libcs (e.g. BSD libc), or basically any other Unix/POSIX/C-based system.
The whole bloody reason for API documentation, standards and the like is so that bad or non-optimal implementation details need not be fixed in stone forever! You should be able to re-implement an API any way you like "under the hood", and providing the implementation meets the API spec, you're good to go. Anyone relying on undocumented side effects of a particular implementation is doomed to pain. That's how APIs work. That's how the POSIX and the C standard work, and that's how memcpy(3) works, and that's the reason for memmove(3)'s existence.
Yes, all developers make mistakes. Sometimes we do make the wrong API call, or pass a NULL where we shouldn't, but the code accidentally works on one implementation of the API for a while. When we become aware of it, the correct response is to FIX THE BUG IN OUR USE OF THE API on all current branches and release a "point" update ASAFP. "Months" should not be an acceptable timescale for that sort of thing. Especially for something as simple as replacing calls to memcpy(3) with calls to memmove(3).
Um, OK, that would cause a problem, but why on earth would you read into a character buffer? You're using C++. Why not read into a std::string?
Yes, you have to read into character buffers in C, because that's all you have. Character buffers, or arrays, are just as insecure in C++ as in C. Which is why you shouldn't use them. Use vectors, lists, or - for characters, strings. C++ has safe abstractions. Use them FFS!
Hmm....I'm aware of the problems of gets(), but haven't heard of possible issues with >> before. Can you give an example or link to an article that explains the issues, so I know what patterns to avoid in the future?
The word discriminatory has a different, more specific, meaning in legal documents - like standards licenses - than the meaning you are ascribing to it.
FRAND is in respect to the licensing of the standard, not the software.
If a standard is licensed in a fair, reasonable and non-discriminatory way, then the licensor can impose a term such as "you owe the standard author $0.10 for every unit you ship." If that licensing term applies to anyone who wishes to distribute any software that implements the standard, it is fair, reasonable and non-discriminatory.
However, such a licensing term on the standard, which is still FRAND, makes the standard unimplementable as Free Software, because the developers suddenly need to pay the standard owner for each copy of the software distributed. Further, anyone else who wishes to redistribute the software to help their neighbour, while permitted to do so by the software license, is suddenly in breach of the standard licensing terms and legally liable to the standard owner.
Slashdot Mirror
The award is not for "contributions to the recording industry", it's for "significant contributions, other than performance, to the field of recording."
Steve Jobs' contributions to the "recording industry" may well have been negative or damaging, but they have nothing to do with the field of recording. They were entirely to do with content distribution, which is totally different.
(IANA sound engineer, but I know a few...)
Are you sure? Wanna try some Snow Crash?
Actually, it's 93% of Americans.
Yeah, I know.
But I didn't want to add too much more to the body of the post, or saddle it with footnotes which would have detracted from the ending.
On the other hand, I couldn't think of a better example to use. Except maybe the curvature of the Earth, but that'd feel like ripping off Asimov's "The Relativity of Wrong" essay. Any suggestions on a better example I could use next time? (Because it's not like posts like the GGPs aren't going to come up again)
Since the modern scientific method was invented approximately 400 years ago, not one single repeatable experiment has ever been devised, by anyone, anywhere, anywhen, which has been able to show an "irregularity" (truly random processes such as radioactive decay, quantum weirdness, and Heisenberg's uncertainty principle notwithstanding)
Occam's razor. Entities should not be multiplied unnecessarily.
When Newton discovered his laws of motion, he was right to accept them. When the scientists who followed him for the next 300-odd years accepted them, they were right to do so. Even though he was eventually shown to be wrong by Einstein, until that point, no-one had any good reason not to accept those laws. However, as soon as Einsten came up with new data, came up with new theories, came up with new experiments, came up with new evidence and proved Newton wrong, then scientists changed how they saw motion.
Yes, scientists should always be aware that their theories might not be correct, that there may be an edge case they've not seen yet. But until someone's actually found it, the best you can do is go with what you've got. If an experiment ever comes along to show that the universe isn't regular, science will use that to show how the universe is not regular. Anyone who refuses to accept the new evidence will not be, to all intents and purposes, a scientist. And science might have to do a lot of work to probe the boundaries (if any) of that irregularity and work out how much it affects the millions of experiments and observations that have been done over the last few centuries.
But until that time comes along, it's perfectly reasonable to assume that the universe is regular. Because that's what every experiement ever done has ever shown.
Your black swan argument could just as well be a 10-headed sheep argument. So what if no-one's seen them? No-one's proven that there aren't 10-headed sheep. So it's an absurdity to say they don't exist!
Bollocks.
If you show me a 10-headed sheep, I'll believe you. Until then, it is so mind-bogglingly unlikely that such thing exists that they are not worth considering in any reasonable model of the universe, and you're just engaging in philosophical wankery, not science.
If the 2nd law of thermodynamics proves that evolution is impossible, because of a local decrease of entropy, then it also proves that life and growth is impossible, because those processes are equivalent local decreases of entropy within a closed system of globally increasing entropy, only on smaller timescales. Therefore, given that life is actually possible, this shows that either the 2nd law of thermodynamics is wrong, or that his understanding of a "closed system" is wrong.
Yup, I guess that's why many European societies which have much tighter gun controls and lower levels of firearm ownership than the US are so much less polite.
Oh, wait...
If KDE4's non-accelerated mode is rendering incorrectly, then I suspect that that is a serious problem with your graphics card drivers, or maybe even your graphics card. Really. And if you're using an out-of-tree driver with serious problems, I don't see how you can claim that it's the quality of Linux that's the problem. The Linux devs have no influencing there at all.
Lots of people (e.g. all the KDE developers) have been using KDE4 all day, every day, for 4 years or so now. Don't you think they'd have the means, motive and opportunity to clean up such problems if they were experiencing them? The fact that they're not experiencing them (and, as an almost-worthless anecdote which I'll throw in anyway, neither am I) is a pretty good indication that the problems you're experiencing aren't in the KDE part of the stack which you share with them. Or in Qt. Rather, they're much more likely to be in the part of the stack which is unique to you - your drivers and graphics card.
While I agree with you that GNU touch with its extended date parsing is fantastic and worth the space it requires, that link does not make your point that
Rather, it specifically says that
That reminds me of the Yes, Prime Minister foreign office 4 stage strategy. You've just outlined stages 1 and 2. I guess that once they can no longer deny it's anthropogenic, they'll move to saying that there's nothing we can do (stage 3), again absolving them of the need to do anything. Then they won't need stage 4 until after some coastal cities are already underwater and millions of climate refugees/victims are making their lives a misery.
It'd be funny if it weren't so tragic.
I don't see why not. You could just convert the energy to heat. The body's homoeostasis system will then expand the surface blood vessels, or start sweating, to dump the heat to the environment, just like it does whenever you get warm. It'd just be like having an artificially increased rest metabolism.
Ha!
IANANP, but I did take some nuclear physics courses as part of my degree.
It's somewhat unlikely that there's an exothermic nuclear reaction in there. Iron/Nickel is the tipping point where you go from fusion being exothermic to fission being exothermic. (This is why elements up to and including Iron and Nickel are much more common than elements from Cobalt onwards; they can be made in a stable way in the core of a star for a while. Once you start to (try to) fuse these elements though, you suck energy out of the star and things go bad.) Copper is the wrong side of that limit.
Even putting that aside, while you're correct that fusion is not "new physics", "cold fusion" is, because of the need to get the nuclei together in spite of the electrostatic repulsion. Yes, catalysts/quantum tunnelling/whatever aren't "brand new physics" in that they are concepts we are aware of, but finding a way in which they can be applied to allow cold fusion would be a new application, and is what I was intending to encompass in my meaning.
However, this is kind of beside the point, as all I was really doing was obligatorily referencing xkcd.
I bet you $200 it's not cold fusion, or any other kind of new physics.
Can't you do both? Make them unsearchable by default, and also untag them as they are added?
I did, when the problem first hit. Linus is right for the code that he writes, in that the public APIs he is in charge of (the Linux kernel<->userspace boundary) does not have a normative public specification, is not designed to be re-implemented by multiple vendors (despite the BSDs impressive efforts), and, while the documentation (at least for syscalls) is generally pretty good, the only real definition in Linux of "what does this part of the API do?" is "whatever that part of the API currently does".
Linus' comments are dead right for the project he works on. However, he does not work on an implementation of The Standard C Library.
But ... that particular change to memcpy() wasn't made on a whim, for no reason. Rather, it was specifically made so that memcpy() could seriously outperform memmove(), because you can do extra optimisations if you know that the source and destination must not overlap!
So convince ISO to change the standard, and the C libraries will follow. Including glibc.
Plus, I'm not convinced that strncpy() is a good example of a function that has "fix[ed] the brain damage". IMHO strncpy() is pretty brain damaged itself, and best avoided. strlcpy() is better, although not standardised, and not in glibc because of perfectly well-reasonsed arguments by Drepper. So I much prefer snprintf(dest, sizeof(dest), "%s", src);
Quite right. The OS is in charge of mechanism, the applications - via the services (mechanisms) the OS provides - is in charge of policy.
Keeping "buildings, traffic and services running smoothly" sounds like policy to me, and hence in the domain of applications running on an OS.
As an ex-smuggler who feels like going straight by, e.g. doing a little gas mining in an out-of-the-way place that won't attract much attention from the emp^H^H^Hauthorities, that sounds like just what I was looking for!
What the...?
Ha ha ha ha hahahahahahahaha!
*wipes tears from eyes* That's probably the funniest thing I've heard all day, thanks!
Flash? Cross-platform? You have got to be kidding! Or on crack. Or maybe you can point me to where I can get Flash 10.3 for *BSD/Solaris/Plan9. Or where I can get Flash for any OS running on IA64/generic ARM (not just Cortex-A8)/MIPS/PowerPC/Sparc/Alpha? Heck, they only started supporting x86-64 properly this year, despite that arch being over 10 years old.
Flash cross-platform. Heh. Good one!
It's not a glibc bug, it's a bug in Flash.
Flash was using memcpy(3) incorrectly. It happened to work on older versions of glibc/x86 by chance. There was never any guarantee that it would work on later version of glibc/x86, or on non-x86 versions of glibc, or non-glibc libcs (e.g. BSD libc), or basically any other Unix/POSIX/C-based system.
The whole bloody reason for API documentation, standards and the like is so that bad or non-optimal implementation details need not be fixed in stone forever! You should be able to re-implement an API any way you like "under the hood", and providing the implementation meets the API spec, you're good to go. Anyone relying on undocumented side effects of a particular implementation is doomed to pain. That's how APIs work. That's how the POSIX and the C standard work, and that's how memcpy(3) works, and that's the reason for memmove(3)'s existence.
Yes, all developers make mistakes. Sometimes we do make the wrong API call, or pass a NULL where we shouldn't, but the code accidentally works on one implementation of the API for a while. When we become aware of it, the correct response is to FIX THE BUG IN OUR USE OF THE API on all current branches and release a "point" update ASAFP. "Months" should not be an acceptable timescale for that sort of thing. Especially for something as simple as replacing calls to memcpy(3) with calls to memmove(3).
Surely you mean Good. I need the cash.
(Not much point making the bet if you're broke now, if no-one tries to reproduce the result for years...)
Um, OK, that would cause a problem, but why on earth would you read into a character buffer? You're using C++. Why not read into a std::string?
Yes, you have to read into character buffers in C, because that's all you have. Character buffers, or arrays, are just as insecure in C++ as in C. Which is why you shouldn't use them. Use vectors, lists, or - for characters, strings. C++ has safe abstractions. Use them FFS!
Hmm....I'm aware of the problems of gets(), but haven't heard of possible issues with >> before. Can you give an example or link to an article that explains the issues, so I know what patterns to avoid in the future?
The word discriminatory has a different, more specific, meaning in legal documents - like standards licenses - than the meaning you are ascribing to it.
FRAND is in respect to the licensing of the standard, not the software.
If a standard is licensed in a fair, reasonable and non-discriminatory way, then the licensor can impose a term such as "you owe the standard author $0.10 for every unit you ship." If that licensing term applies to anyone who wishes to distribute any software that implements the standard, it is fair, reasonable and non-discriminatory.
However, such a licensing term on the standard, which is still FRAND, makes the standard unimplementable as Free Software, because the developers suddenly need to pay the standard owner for each copy of the software distributed. Further, anyone else who wishes to redistribute the software to help their neighbour, while permitted to do so by the software license, is suddenly in breach of the standard licensing terms and legally liable to the standard owner.