IBM - They're using Qt + C++ for their new palmtop reference platform.
I think you are reading a bit too much into their announcement. Qtopia is merely one of several GUI options for their reference platform, and it's probably there more by default than by choice. The main GUI programming environment for their reference platform is likely to be Java.
Microsoft - They're using C++ to write C# and.NET I'd imagine. They've also written their components with it.
Yes, C++ is a good systems programming language. It's also a good scientific programming language. It's not a good language for developing GUIs or end user applications.
Apple - They're using C++ and KHTML for their webbrowser.
They are reusing a component written in C++. Their entire GUI is written in Objective-C, and that's what they are using for Safari as well.
In short, you are grasping at straws, citing a bunch of largely irrelevant facts about niches where C++ is still hanging on. IBM is pushing Java for GUI development, on all their platforms, Microsoft is pushing C#, and Apple is pushing Objective-C and (to a lesser degree, Java).
It seems to this day that Qt licensing is still a problem for GNOME. One of the greatest ironies in all of Free Software, IMHO.
I fail to see the irony. Open source software licenses are designed to achieve specific goals, and it seems like the Gnome/Gtk+ license is achieving its goal.
KDE is built from the ground up upon Qt/C++ and this is one of the major reasons for it's considerable success.
IBM, Microsoft, Apple, and Sun all are moving away from C/C++ for their GUI efforts. What is KDE's response going to be? Claiming that everybody else is wrong?
language is rarely precise
on
Defining "Planet"
·
· Score: 2, Insightful
Even simple concepts like "red" or "tall" don't have universally accepted definitions; why should "planet"?
How do we solve that? We say what we mean in a particular context and then use the word as a shorthand. "In this paper, we will use the term 'planet' to refer to extrasolar bodies with diameters over 700km and masses less than 13 times the mass of Jupiter." "In this paper, we will be talking about the traditional nine planets of the solar system, Mercury, Venus,..." Etc.
Terms like "planet" would actually be less useful if they did have a precise definition, because than each of those papers would have to use a much more awkward circumlocution when referring to bodies that don't meet the definition precisely.
You don't need 10 controllers; the bandwidth limit is merely an electrical limit on the wire and connector, not on the controller.
A single high performance USB2 or FireWire controllers should be able to do full USB2 or FW bandwidth per connector. Think of it like an Ethernet switch. In the past, a 100Mbps limit was aggregate, but now, the switch can do 100Mbps per port.
You can already get USB2 and FireWire cards that can do high speed transfers simultaneously on several connectors, and if this really takes off, there is no reason why you couldn't have a card with 8 or 16 independent channels (ultimately, of course, it gets silly because PCI can't keep up anymore).
Yes, I'm aware of that; that was, in fact, the point of my posting: if you attach each of those drives individually to a controller using a slower connection, you don't need an expensive, high-speed bus standard and still get the same aggregate bandwidth. You also reduce the risk of breaking something when you add or remove drives. Sorry if I didn't spell it out clearly enough.
Not to say that ATA disks aren't reliable, but the components that are used in ATA disks are typically those that were outside the absurdly strict tolerances that are required for "enterprise-class" drives.
The future of reliable, enterprise-class hardware is not delicately engineered systems that cost a premium, but a large number of inexpensive, simple servers and drives. For disks, we already have that in the form of RAIDs. If a drive, or two, or three, fail, you just replace them.
And yes, when it comes to speed, SCSI tends to rule the roost. Not only because you can throw 320MB/s down each individual channel, but you can toss enough devices on that channel to keep that overall speed sustained over longer periods of time.
That is circular reasoning. If you pick separate channels for each device, then each channel can be slower. Besides, "tossing enough devices on that channel" makes the overall system less reliable because if there is a problem with any one of them, it may kill the whole channel. And, besides, the more devices you toss onto a serial bus, the less efficiently it will be utilized relative to having a single device with the same total bandwidth requirements. Overall, you are probably better off using five separate USB2 or IEEE1394 connections than one of these serial SCSI connections.
Why would adopting a serial standard lead to "the elimination of the distinction"? When both were parallel, they were different.
The distinction is largely one of software and controller standards. SerialATA looks like an IDE controller, and SerialSCSI looks like a SCSI controller. The fact that both use a handful of wires in a thin cable to attach them doesn't change that.
Yeah, but what drive actually delivers 320 Mbytes/second? As long as the connection between the controller and each drive can keep up with the drive, the connection is fast enough.
Of course, a really fast connection may allow you to daisy chain and still get almost full transfer rates from each drive, but that's not really such a big deal, in particular when the cables are as small as they are for serial connections.
Don't try to do everything at once. Find some server function you can move to Linux and move it. Then, see how it goes. Then, after a couple of months, do another. If your software is compatible between Sun and Linux, move over those users that want to move, again, slowly, one-by-one. This will give you and your users time to adapt.
And if it isn't broken, don't fix it. That little Sun sitting in a corner running some server all by itself, just leave it alone until it starts causing problems (bad hardware, can't access NFS, whatever). Then, deal with it.
The other thing that goes into an "enterprise network" is lots of diversity. Enterprise networks pretty much always have a diverse mix of machines in them.
In the past, beingexcentricwas very expensive. Today, you can be excentric and save money, too, by not having E-mail or a cell phone. Isn't progress great?
Of course his patents are bogus and lack novelty (here), but they don't seem any more bogus than a lot of other stuff that gets patented. In particular, his more recent patents look like the obvious application of an old idea to specific areas, but as defenders of the patent system are often so fond of saying "well, the underlying algorithm/gadget/... may be known, but patents are for useful ways of solving real problems, and this particular solution hasn't been patented before, so it must be novel, right?"
The sad thing is that if these patents had been held by a laywer or a big company with a good legal team, they probably would have held up at least long enough for them to generate some revenue. And chances are they would have picked their legal battles more carefully and settled out of court at just the right points to avoid even the risk of invalidation.
Sorry, but "faster, bigger, better, stronger" is not what evolution aims for. Mice, deer, worms, and rabbits somehow all managed to survive. And the saber tooth tiger, mammoth, and lots of other big, strong, and ferocious species have died out. Even for crocodiles, most of them get eaten before reaching adulthood. Evolution creates more of what survives, and small wimpy creatures that have a lot of sex are at least as successful as ferocious hunters. Furthermore, bigger muscles and other traits that we may think of desirable usually come along with quite a few problems, otherwise we'd already have them.
Bullshit. Implementing a fix that is not QA'd and fully tested should never be done. Clearly you have no idea how to develop robust, reliable software.
Translation: "If it works for me and if it works for the QA department, it's correct. Who cares whether it conforms to the specification or whether it will break when the library gets updated."
When a library you depend on doesn't comply with specifications, you have several options: you write code that doesn't break when the library gets fixed, you find an alternative API, or you leave the feature out of your software.
Your objection is valid in that if you naively implement the first option, you effectively have untested code. Untested code can be managed properly (even if you may not know how). But if it bothers you and you are concerned about robustness, just pick the second or third option: find another API (Windows is full of duplications, so that isn't hard) or leave out the feature. Even checking for the presence of the bug and terminating the program with an assertion failure is better than what you suggest.
But the approach you follow, writing code that quietly violates the specification of the library is a prescription for disaster, no matter how good your QA department is.
In short, we don't have to look any further than the idiocy you advocate to see why so many Windows programs keep crashing and why DLLs are such a problem on Windows. Yes, you evidently are a professional Windows programmer (or might as well be), and I don't mean that as a compliment.
installing a Windows rootkit
on
Windows Rootkits
·
· Score: 2, Funny
Is that like pouring a bucket of water into the ocean? Or bringing a boxed lunch to an all-you-can-eat buffet?
Just grab a laptop and work anywhere. You can either connect via wireless, or you can synchronize your laptop and computers. I often sit down outside with my laptop to work.
This has been a continuing problem with Sun's Java source code, where Sun for years has made noises that if you look at their source code, they have rights to any Java implementation you work on in the future. Microsoft wasn't even original in the area of obnoxious shared source licenses.
The first rule of thumb should be: if it doesn't come with a well-known open source license, don't look at the source code; if you do, you may find yourself in a world of legal trouble and cause pain not only for yourself but also for your employer or the open source projects you are working on. Occasionally, one can make an exception to this rule, but it needs to be carefully thought through.
There is no such thing as "UNIX" patents; any patents that there might have been would have expired by now, and the only one that I know of that there ever was was the set-uid bit.
If SCO has patents related to SCO UNIX, they are either invalid, or they have nothing to do with what makes UNIX UNIX.
In particle physics, a result is not trusted unless it is 3 standard deviations above background (i.e. there's a 1/1000 chance of it being a fluke). That's hardly at the lmit of detectablilty.
Your "i.e." already shows that you don't know much about statistics, which is sadly true for a lot of scientists.
He was quite familiar with the existing body of scientific literature (e.g. Lorentz's paper on unifying Newtonean mechanics and Maxwell mechanics where he proposed what is now called the Lorentz transform).
So? Park doesn't propose evaluating someone's fluency with the scientific literature, he is talking about someone "working in isolation", which, without further qualification, would mean something like "without collaborators and without a research team".
Further, the scientific community was quite familiar with Einstein through his publications in the scientific literature.
Sure, that is ultimately why people listened to Einstein's ideas about relativity; if he hadn't established credibility with other publications, relativity might never have become accepted. But what does that have to do with Park's criterion of "working in isolation"? Whether someone publishes a lot or not, they are still working "in isolation".
Believe me, I dislike strongly a lot of the crackpot theories that people come up with. I think Duesberg's theories about AIDS are crackpot and may end up being responsible for the deaths of thousands. However, Duesberg's theories are wrong because they contradict experimental data, not because Duesberg is working in isolation or puts his results on a web site (which is pretty much the only place where he can put them).
Park's criteria are inappropriate and harmful; they have no place in science or the evaluation of scientific truth.
You want to give an example? Just because the detectors used in these enterprises operate on very small, fleeting signals, doesn't mean that the results are somehow less solid.
Oh, I fully agree: small signals don't mean the same as unsound. But that's not what I'm talking about. For a recent example, look at CERN and the Higgs (press release and all). Does that make CERN an institution of junk science?
One of the problems in a lot of scientific results, too, is the misapplication of statistics. Figures like "99% sure" often result from the application of statistical tests to the end result of a chain of reasoning and assumptions and don't tell you how much you can trust the result itself. The speed of gravity measurements are an example of this: statistically, the experimental results may be highly significant, but that doesn't mean that the conclusinos are true with that probability.
Pages of dull tables are not an anecdote. They are a record of events. Yes, you still have to trust the researcher, but that's _not_ what this one is warning against. It's warning against delivery over content.
Getting scientific papers published is all about delivery. In fact, you yourself say so: if it contains "pages of dull tables" you think of it as scientific. Of course, the "anecdotes" people tell scientifically are not in exactly the same format they tell over dinner, but their content and their delivery is chosen to please the reviewers and readers. You just try publishing a scientific paper in a format that differs from what is expected and see it get rejected.
And those cases where it was valid, scientifically, the literature bore this out fairly soon after. Remember the target of these rules are judges. If your deciding a court case on yesterdays lab results, then there's a problem.
Court cases are decided on "yesterday's lab results" all the time: DNA tests, ballistic reports, etc. Do those get reviewed in the literature for 10 years before they get admitted into court? Usually, they actually get neither peer reviewed nor are they carried out in a double-blind manner.
And how long did it take from his publication [of relativity] till relativity was accepted generally?
Exactly my point: people like Park thought "oh, it's that screwball theory that doesn't make a lot of sense and comes from that nut from the Swiss patent office". If Einstein hadn't made a name for himself with the photoelectric effect, people probably would never have given relativity another look.
But you missed the important part of the rule: If they make other laws of nautre wrong, then it's probably not the other laws of nature that are the ones that are incorrect.
Calling them "laws of nature" is in itself misleading. These aren't rules written down in some natural book of laws, they are simply hypotheses and constructs. In many cases, the support for them is simply the absence of observations to the contrary or the lack of any plausible hypothesis that does not incorporate them.
This is not for the average man to tell truth from fiction. This is intended to assist judges in telling a well proven fact from junk science.
You are assuming that this is possible in many cases. I don't think it is. We can easily identify something like creationism as being outside of science. But whether cold fusion or global warming are true or false should be determined only on the basis of logical consistency and experimental evidence, not whether their proponents are nice people or whether it is science that the mainstream has believed in for decades or was released last month. And in the case of cold fusion, that simply meant a few months of experimentation that failed to reproduce it.
Basically, what I'm saying is not that courts should trust results like cold fusion just because a scientist testifies to it, courts should intrinsically distrust all scientific "facts", whether they come from scientists with lots of grants and titles or scientists with press releases. If a court decision hinges on a scientific result, the court needs to apply the scientific method itself. And, often, the answer will simply be: science can't give us a reliable answer.
And you are kidding yourself if you think people like Park reserve their rules of thumbs only for court cases (where they, if anything, do more damage). Someone with that kind of attitude can't help but apply the same considerations, consciously or unconsciously, to papers and grant applications he is reviewing.
then the fix gets released and breaks the original application.
Workarounds in applications that break when the library gets fixed are in themselves broken. The correct thing for an application developer to do is to test for the presence of the bug and then pick either the workaround or the version corresponding to the published API and behavior. Then, the application doesn't break when the fix gets released.
What Microsoft is doing is the right way to do it.
No, it's wrong. You merely have the blind leading the blind.
Ideally, upon upgrade of a DLL, there should be a way for the application to contact the mother ship (i.e. the home page of the developer) and ask for approval to upgrade to the new DLL.
And the fact that you consider this "ideal" is typical of why Windows is such an awful platform.
The "ideal" is that if applications have workarounds for library bugs, that they apply those workaround quietly and correctly only when needed. And it's an ideal that's easy to achieve for anybody who has the slightest idea of what they are doing.
I got the impression from the article that these "warning signs" were not a methodology for scientists to establish scientific truth, but rather a handy guide for the media, to help them determine, "this press release could be junk science. Ask the scientific community for more information before printing it as fact."
Park is giving criteria for evaluating the truth of claims made by other scientists. That is part of the scientific process, whether it is done in a scientific or in a legal context. And Park's criteria are unacceptable for determining scientific truth. It may be bad manners to make a press release about a discovery prior to peer review, or it may be oddball to "work in isolation", but neither behavior has any bearing on whether the theory itself has merit or not.
Park's rules are actually worse than merely publishing bad experimental results because they likely hurt people far outside his field.
Binding applications to DLLs tightly doesn't solve the problem either because, as people have pointed out, often you do want applications to use a new version.
The real solution is to indicate whether a DLL is a bug-fix release or whether it represents a significant and incompatible change to the APIs. You know, like Linux major/minor dynamic library versioning, for example.
Park's rules are as bogus as the junk science he tries to expose. Let's just look at them:
[The discoverer pitches the claim directly to the media.]
The discoverer may not have much choice in the matter. For example, a reviewer may have leaked the story, or he may worry that someone else is going to scoop him, or he may work (horrors of horrors) for an institution with a PR department (meaning just about any university, research lab, or company).
[The discoverer says that a powerful establishment is trying to suppress his or her work.]
Just because you are paranoid doesn't mean they aren't out to get you anyway. Sure, scientists rarely reason like "well, if this guy is right, I'm going to lose my research funding/market/whatever". Thinking usually is more along the lines of "well, this guy obviously can't be right, because we get so much money for our way that a lot of people with a lot of money think we are right; so this guy must be wrong, end of story".
[The scientific effect involved is always at the very limit of detection.]
Like a lot of particle physics or astrophysics these days.
[Evidence for a discovery is anecdotal.]
All scientific evidence is anecdotal in some sense. Just because someone has impressive sounding credentials doesn't mean his scientific anecdotes (=research results) are necessarily true. Just look at Schoen. Ultimately, the only way to know for certain is to reproduce the results. All one can ask of a scientific paper is that it contains all the information necessary to reproduce the results. If the results can't be practically reproduced or verified some other way (occasionally, experiments work like a public key cryptosystem), then they just don't matter.
[The discoverer says a belief is credible because it has endured for centuries.]
This statement is followed by a pretty nasty put-down of things like traditional medicinal knowledge. Of course, such knowledge isn't "scientific knowledge". But that doesn't mean that it's not true, and it certainly doesn't mean that a court should disregard it. In fact, most evidence a court hears is not scientific evidence.
[The discoverer has worked in isolation.]
Einstein worked in isolation--does that make relativity "junk science"?
[The discoverer must propose new laws of nature to explain an observation.]
Again, like a lot of astrophysics.
With his rules, Park demonstrates simultaneously that he is too gullible when it comes to "reputable" sources and that he is too prejudiced when it comes to sources that he doesn't know. I don't know whether that makes Park a quack, but I do know that it makes him the kind of person that seriously hurts the scientific community and scientific discourse.
Scientific truth depends not on "warning signs", it depends on logical consistency and experimental reproducibility, and it depends only on that. Sadly, that often means that science can't give definitive answers because logical consistency or experimental reproducibility can be very hard to achieve or verify. But that is no excuse to substitute Park's own unscientific approach for them.
Slashdot Mirror
I think you are reading a bit too much into their announcement. Qtopia is merely one of several GUI options for their reference platform, and it's probably there more by default than by choice. The main GUI programming environment for their reference platform is likely to be Java.
Microsoft - They're using C++ to write C# and .NET I'd imagine. They've also written their components with it.
Yes, C++ is a good systems programming language. It's also a good scientific programming language. It's not a good language for developing GUIs or end user applications.
Apple - They're using C++ and KHTML for their webbrowser.
They are reusing a component written in C++. Their entire GUI is written in Objective-C, and that's what they are using for Safari as well.
In short, you are grasping at straws, citing a bunch of largely irrelevant facts about niches where C++ is still hanging on. IBM is pushing Java for GUI development, on all their platforms, Microsoft is pushing C#, and Apple is pushing Objective-C and (to a lesser degree, Java).
I fail to see the irony. Open source software licenses are designed to achieve specific goals, and it seems like the Gnome/Gtk+ license is achieving its goal.
KDE is built from the ground up upon Qt/C++ and this is one of the major reasons for it's considerable success.
IBM, Microsoft, Apple, and Sun all are moving away from C/C++ for their GUI efforts. What is KDE's response going to be? Claiming that everybody else is wrong?
How do we solve that? We say what we mean in a particular context and then use the word as a shorthand. "In this paper, we will use the term 'planet' to refer to extrasolar bodies with diameters over 700km and masses less than 13 times the mass of Jupiter." "In this paper, we will be talking about the traditional nine planets of the solar system, Mercury, Venus, ..." Etc.
Terms like "planet" would actually be less useful if they did have a precise definition, because than each of those papers would have to use a much more awkward circumlocution when referring to bodies that don't meet the definition precisely.
You can already get USB2 and FireWire cards that can do high speed transfers simultaneously on several connectors, and if this really takes off, there is no reason why you couldn't have a card with 8 or 16 independent channels (ultimately, of course, it gets silly because PCI can't keep up anymore).
USB1 is compatible with USB2; they are still "distinct" and behave very much differently.
Yes, I'm aware of that; that was, in fact, the point of my posting: if you attach each of those drives individually to a controller using a slower connection, you don't need an expensive, high-speed bus standard and still get the same aggregate bandwidth. You also reduce the risk of breaking something when you add or remove drives. Sorry if I didn't spell it out clearly enough.
The future of reliable, enterprise-class hardware is not delicately engineered systems that cost a premium, but a large number of inexpensive, simple servers and drives. For disks, we already have that in the form of RAIDs. If a drive, or two, or three, fail, you just replace them.
And yes, when it comes to speed, SCSI tends to rule the roost. Not only because you can throw 320MB/s down each individual channel, but you can toss enough devices on that channel to keep that overall speed sustained over longer periods of time.
That is circular reasoning. If you pick separate channels for each device, then each channel can be slower. Besides, "tossing enough devices on that channel" makes the overall system less reliable because if there is a problem with any one of them, it may kill the whole channel. And, besides, the more devices you toss onto a serial bus, the less efficiently it will be utilized relative to having a single device with the same total bandwidth requirements. Overall, you are probably better off using five separate USB2 or IEEE1394 connections than one of these serial SCSI connections.
The distinction is largely one of software and controller standards. SerialATA looks like an IDE controller, and SerialSCSI looks like a SCSI controller. The fact that both use a handful of wires in a thin cable to attach them doesn't change that.
Of course, a really fast connection may allow you to daisy chain and still get almost full transfer rates from each drive, but that's not really such a big deal, in particular when the cables are as small as they are for serial connections.
And if it isn't broken, don't fix it. That little Sun sitting in a corner running some server all by itself, just leave it alone until it starts causing problems (bad hardware, can't access NFS, whatever). Then, deal with it.
The other thing that goes into an "enterprise network" is lots of diversity. Enterprise networks pretty much always have a diverse mix of machines in them.
In the past, being excentric was very expensive. Today, you can be excentric and save money, too, by not having E-mail or a cell phone. Isn't progress great?
The sad thing is that if these patents had been held by a laywer or a big company with a good legal team, they probably would have held up at least long enough for them to generate some revenue. And chances are they would have picked their legal battles more carefully and settled out of court at just the right points to avoid even the risk of invalidation.
Sorry, but "faster, bigger, better, stronger" is not what evolution aims for. Mice, deer, worms, and rabbits somehow all managed to survive. And the saber tooth tiger, mammoth, and lots of other big, strong, and ferocious species have died out. Even for crocodiles, most of them get eaten before reaching adulthood. Evolution creates more of what survives, and small wimpy creatures that have a lot of sex are at least as successful as ferocious hunters. Furthermore, bigger muscles and other traits that we may think of desirable usually come along with quite a few problems, otherwise we'd already have them.
Translation: "If it works for me and if it works for the QA department, it's correct. Who cares whether it conforms to the specification or whether it will break when the library gets updated."
When a library you depend on doesn't comply with specifications, you have several options: you write code that doesn't break when the library gets fixed, you find an alternative API, or you leave the feature out of your software.
Your objection is valid in that if you naively implement the first option, you effectively have untested code. Untested code can be managed properly (even if you may not know how). But if it bothers you and you are concerned about robustness, just pick the second or third option: find another API (Windows is full of duplications, so that isn't hard) or leave out the feature. Even checking for the presence of the bug and terminating the program with an assertion failure is better than what you suggest.
But the approach you follow, writing code that quietly violates the specification of the library is a prescription for disaster, no matter how good your QA department is.
In short, we don't have to look any further than the idiocy you advocate to see why so many Windows programs keep crashing and why DLLs are such a problem on Windows. Yes, you evidently are a professional Windows programmer (or might as well be), and I don't mean that as a compliment.
Is that like pouring a bucket of water into the ocean? Or bringing a boxed lunch to an all-you-can-eat buffet?
Just grab a laptop and work anywhere. You can either connect via wireless, or you can synchronize your laptop and computers. I often sit down outside with my laptop to work.
The first rule of thumb should be: if it doesn't come with a well-known open source license, don't look at the source code; if you do, you may find yourself in a world of legal trouble and cause pain not only for yourself but also for your employer or the open source projects you are working on. Occasionally, one can make an exception to this rule, but it needs to be carefully thought through.
If SCO has patents related to SCO UNIX, they are either invalid, or they have nothing to do with what makes UNIX UNIX.
Your "i.e." already shows that you don't know much about statistics, which is sadly true for a lot of scientists.
He was quite familiar with the existing body of scientific literature (e.g. Lorentz's paper on unifying Newtonean mechanics and Maxwell mechanics where he proposed what is now called the Lorentz transform).
So? Park doesn't propose evaluating someone's fluency with the scientific literature, he is talking about someone "working in isolation", which, without further qualification, would mean something like "without collaborators and without a research team".
Further, the scientific community was quite familiar with Einstein through his publications in the scientific literature.
Sure, that is ultimately why people listened to Einstein's ideas about relativity; if he hadn't established credibility with other publications, relativity might never have become accepted. But what does that have to do with Park's criterion of "working in isolation"? Whether someone publishes a lot or not, they are still working "in isolation".
Believe me, I dislike strongly a lot of the crackpot theories that people come up with. I think Duesberg's theories about AIDS are crackpot and may end up being responsible for the deaths of thousands. However, Duesberg's theories are wrong because they contradict experimental data, not because Duesberg is working in isolation or puts his results on a web site (which is pretty much the only place where he can put them).
Park's criteria are inappropriate and harmful; they have no place in science or the evaluation of scientific truth.
Oh, I fully agree: small signals don't mean the same as unsound. But that's not what I'm talking about. For a recent example, look at CERN and the Higgs (press release and all). Does that make CERN an institution of junk science?
One of the problems in a lot of scientific results, too, is the misapplication of statistics. Figures like "99% sure" often result from the application of statistical tests to the end result of a chain of reasoning and assumptions and don't tell you how much you can trust the result itself. The speed of gravity measurements are an example of this: statistically, the experimental results may be highly significant, but that doesn't mean that the conclusinos are true with that probability.
Getting scientific papers published is all about delivery. In fact, you yourself say so: if it contains "pages of dull tables" you think of it as scientific. Of course, the "anecdotes" people tell scientifically are not in exactly the same format they tell over dinner, but their content and their delivery is chosen to please the reviewers and readers. You just try publishing a scientific paper in a format that differs from what is expected and see it get rejected.
And those cases where it was valid, scientifically, the literature bore this out fairly soon after. Remember the target of these rules are judges. If your deciding a court case on yesterdays lab results, then there's a problem.
Court cases are decided on "yesterday's lab results" all the time: DNA tests, ballistic reports, etc. Do those get reviewed in the literature for 10 years before they get admitted into court? Usually, they actually get neither peer reviewed nor are they carried out in a double-blind manner.
And how long did it take from his publication [of relativity] till relativity was accepted generally?
Exactly my point: people like Park thought "oh, it's that screwball theory that doesn't make a lot of sense and comes from that nut from the Swiss patent office". If Einstein hadn't made a name for himself with the photoelectric effect, people probably would never have given relativity another look.
But you missed the important part of the rule: If they make other laws of nautre wrong, then it's probably not the other laws of nature that are the ones that are incorrect.
Calling them "laws of nature" is in itself misleading. These aren't rules written down in some natural book of laws, they are simply hypotheses and constructs. In many cases, the support for them is simply the absence of observations to the contrary or the lack of any plausible hypothesis that does not incorporate them.
This is not for the average man to tell truth from fiction. This is intended to assist judges in telling a well proven fact from junk science.
You are assuming that this is possible in many cases. I don't think it is. We can easily identify something like creationism as being outside of science. But whether cold fusion or global warming are true or false should be determined only on the basis of logical consistency and experimental evidence, not whether their proponents are nice people or whether it is science that the mainstream has believed in for decades or was released last month. And in the case of cold fusion, that simply meant a few months of experimentation that failed to reproduce it.
Basically, what I'm saying is not that courts should trust results like cold fusion just because a scientist testifies to it, courts should intrinsically distrust all scientific "facts", whether they come from scientists with lots of grants and titles or scientists with press releases. If a court decision hinges on a scientific result, the court needs to apply the scientific method itself. And, often, the answer will simply be: science can't give us a reliable answer.
And you are kidding yourself if you think people like Park reserve their rules of thumbs only for court cases (where they, if anything, do more damage). Someone with that kind of attitude can't help but apply the same considerations, consciously or unconsciously, to papers and grant applications he is reviewing.
Workarounds in applications that break when the library gets fixed are in themselves broken. The correct thing for an application developer to do is to test for the presence of the bug and then pick either the workaround or the version corresponding to the published API and behavior. Then, the application doesn't break when the fix gets released.
What Microsoft is doing is the right way to do it.
No, it's wrong. You merely have the blind leading the blind.
Ideally, upon upgrade of a DLL, there should be a way for the application to contact the mother ship (i.e. the home page of the developer) and ask for approval to upgrade to the new DLL.
And the fact that you consider this "ideal" is typical of why Windows is such an awful platform.
The "ideal" is that if applications have workarounds for library bugs, that they apply those workaround quietly and correctly only when needed. And it's an ideal that's easy to achieve for anybody who has the slightest idea of what they are doing.
Park is giving criteria for evaluating the truth of claims made by other scientists. That is part of the scientific process, whether it is done in a scientific or in a legal context. And Park's criteria are unacceptable for determining scientific truth. It may be bad manners to make a press release about a discovery prior to peer review, or it may be oddball to "work in isolation", but neither behavior has any bearing on whether the theory itself has merit or not.
Park's rules are actually worse than merely publishing bad experimental results because they likely hurt people far outside his field.
The real solution is to indicate whether a DLL is a bug-fix release or whether it represents a significant and incompatible change to the APIs. You know, like Linux major/minor dynamic library versioning, for example.
The discoverer may not have much choice in the matter. For example, a reviewer may have leaked the story, or he may worry that someone else is going to scoop him, or he may work (horrors of horrors) for an institution with a PR department (meaning just about any university, research lab, or company).
Just because you are paranoid doesn't mean they aren't out to get you anyway. Sure, scientists rarely reason like "well, if this guy is right, I'm going to lose my research funding/market/whatever". Thinking usually is more along the lines of "well, this guy obviously can't be right, because we get so much money for our way that a lot of people with a lot of money think we are right; so this guy must be wrong, end of story".
Like a lot of particle physics or astrophysics these days.
All scientific evidence is anecdotal in some sense. Just because someone has impressive sounding credentials doesn't mean his scientific anecdotes (=research results) are necessarily true. Just look at Schoen. Ultimately, the only way to know for certain is to reproduce the results. All one can ask of a scientific paper is that it contains all the information necessary to reproduce the results. If the results can't be practically reproduced or verified some other way (occasionally, experiments work like a public key cryptosystem), then they just don't matter.
This statement is followed by a pretty nasty put-down of things like traditional medicinal knowledge. Of course, such knowledge isn't "scientific knowledge". But that doesn't mean that it's not true, and it certainly doesn't mean that a court should disregard it. In fact, most evidence a court hears is not scientific evidence.
Einstein worked in isolation--does that make relativity "junk science"?
Again, like a lot of astrophysics.
With his rules, Park demonstrates simultaneously that he is too gullible when it comes to "reputable" sources and that he is too prejudiced when it comes to sources that he doesn't know. I don't know whether that makes Park a quack, but I do know that it makes him the kind of person that seriously hurts the scientific community and scientific discourse.
Scientific truth depends not on "warning signs", it depends on logical consistency and experimental reproducibility, and it depends only on that. Sadly, that often means that science can't give definitive answers because logical consistency or experimental reproducibility can be very hard to achieve or verify. But that is no excuse to substitute Park's own unscientific approach for them.