>> I am also sure PopCap would not have bothered making their excellent Pants vs Zombies app if they were unable to sell it because people were playing the free Flash version instead
And why is that? I played the Flash version on their site, then downloaded the free demo version, and then paid for the full version. After finishing the Adventure mode three times over (working on the fourth), all the mini-games, and most of the puzzles (damn that nighttime fog!), I went ahead and paid the three bucks to play it on my iPod Touch (I'll never be bored at a meeting again!).
I'm sure I am not the only one who finds the game so good as to warrant paying for the full version over the short Flash version, especially when it's just three bucks.
Sure, the iPhone and iPad should then come with a manual to teach and train the user in the interface intricacies of each web site or application, along with the standard set of built-in gestures.
Dude, do you realize that the AppStore was an afterthought? The iPhone was supposed to run exclusively Apple-only native apps, and FREE third-party web-apps, not to mention the entire (non-Flash) Internet on Safari. And indeed it worked like this for about a year.
If developers wanted to charge for subscription to their site or for access to their kewl game (which some did), Apple never had any control over this, nor did it care. This is the bit that you don't consider in your argument, that people did make money on web applications and iPhone widgets before and Apple had no worries over that.
The only change now is that they allow third-party native apps through their AppStore. All other third-party development remains accessible as before. You are right, Apple demands 30% of the cut if you intend to make money from your native app, but this is because they give you access to their massive distribution channel and payment processing system. If you go at it on your own (albeit not with a native app), you can keep the money yourself and Apple has no restrictions over that.
I take your position to be that Flash is not the problem, but the actual use of it on some web applications is; that it is a matter of bad design.
I guess you then would suggest that rather than ban Flash altogether, Steve Jobs should tell all those developers and designers with crappy, broken sites that abuse Flash, to re-design them for the iPhone/iPad/iPod Touch, right?
Right, because that would be more practical than telling them to re-design their site with HTML5.
Not true. Nobody is stopping you (or anybody) from publishing your own articles or editing any existing one in Wikipedia. That your changes may get reverted later is another matter.
After all, it's "the free encyclopedia that anyone can edit", which indeed they can, not "the free encyclopedia which publishes anything that anyone who is not a member of the editor cabal edits."
Google doesn't belong in that list. You miss the point that Google's customers are actually the individual and organizations that advertise in their system. The search engine and GMail users are just the mechanism in which to exercise that system in order to increase the value of the advertising service they provide.
Making money hand over fist from their advertising network, and extracting cash directly from their real paying customers, makes Google a huge success.
>> Cubestorm for looks and sheer speed, sudoko robot for neatness and purity.
DEATHMATCH!!!!!!!!
Sure, the Sudoku robot can move around, but if it happens to wander too close, CubeStorm will twist its delicate figure into a wreck and solve it into a heap of yellow Duplo studs; and do it fast!
Very true, but my point is that software is not inherently flawed because humans write it, just as mathematics is not inherently flawed because humans discovered or created it. Software is flawed for many other reasons, mostly business pressures and time constraints, which are inherent in the development process itself, and not in the software.
>> It's not possible to do the sort of work he was doing while validating against a list of known-good inputs.
I say it is possible. It may not be possible in every application, but on his particular example it certainly is. His problem was due to a misunderstanding of the problem domain: instead of treating each image as a unique entity in itself, irrespective of message, and attempt to compare it to the already retrieved images through some special mechanism, he made the assumption that images would be unique within a message. As it turned out this assumption was wrong, but it was unnecessary to begin with.
I take your point and agree that knowing the entire input domain of a complex system may be impossible, but disagree that this will result in an inherent bug in the system. That which is not known should be treated as such and either ignored, dealt in some way, or flagged for later consideration, as the situation requires. You know the things you know, and therefore you can detect the things that you do not.
>> The domain of possibilities is simply too large to meaningfully cover it, and the same is true of newsgroup parsing.
This is true for the case of antivirus software, because over the years the problem domain (and in fact, the marketing claim) has been expanded to include not only known threats but future, unknown threats as well. For this, an attempt is made to make sense of the entire input domain, using heuristics and other statistical analyses, with the assumption that a certain percentage of false positives (or false negatives) is acceptable. This makes their effectiveness and usefulness rather questionable, depending on your threshold of acceptance.
The same may be true for newsgroup parsing, if indeed the author intends to detect stuff he doesn't even know exists, nor in what form; but this is typically not the case. It is much more likely that the application scope will be narrowed to solve specific known problems. This is certainly the case in the example provided by the poster, where a specific and discreet problem exists: to retrieve all unique images from all messages. He made the assumption that the entire input domain was known and then proceeded to implemented the application accordingly, without any acknowledgement to the limitations of this design.
That last part is bad design and bad practice, not an inherent flaw of software in general.
I'd understand your confusion if English is not your first language. However, that sentence is explicit and unambiguous:
"resulting in slow-downs as the systems were forced to increasingly turn to disk-based virtual memory to handle tasks[...]" (emphasis mine).
The highlighted words assert that the slow-downs were a direct result of the memory consumption and that consequently virtual memory was consumed.
It is true that the article does not expressly state how they determined that virtual memory was consumed, but seeming that they make this assertion it stands to reason that it was at least observed in some manner. This is attested by a blog entry from the actual researches conducting the tests:
New data from the exo.repository shows that better than 8 in 10 Windows 7 systems monitored by the exo.performance.network are running alarmingly low on physical memory. And nearly the same number are demonstrating significant delays in I/O processing - ostensibly due to heavy virtual memory activity as Windows compensates for insufficient RAM. (emphasis mine)
Actually, software is applied mathematics, which can be perfect to solve a discreet problem, indeed. However, there are many factors involved in the development of software, most unrelated to mathematics and algorithms, that hasten the design and implementation, and require compromising such perfect solutions.
It would then be more accurate to say Software is subject to business pressures, and as such it won't be perfect.
Ah, the ol' Reject-Known-Bad or Sanitise-All-Input paradigm. It is indeed impossible to anticipate all the bone-headed ways in which input can be botched, maliciously or not. Thus, it is then more secure to prepare a discreet list of valid input and only accept that, rejecting anything that does not conform to what you expect. This rejection is not based on a black-list of bad input to compare against, but on a sort of white-list what you assert your program can handle.
If you would have considered this approach, your application would have rejected the message with duplicate images (perhaps logging this reaction somewhere for you to review later), and continued churning along without crashing. (Alternatively, you could have modeled your application on the Real World and realized that messages may contain, and often do, the same image more than once and expected that; but I understand that problem analysis is not very common these days.)
Check out the OWASP Top Ten. Trying to maintain a black-list of all known bad input and all its variants is akin to an arms race in which you will always find yourself at the losing, reactionary end.
Is it "Company" as in "Company Name", or "Corporate Tax ID"? If the latter, then you require a business entity; the former is just an informal label, if you don't actually own a company. It could be something like "Tepple's Kewl SoftCo". This is typically termed a D.B.A, or "Doing Business As".
"Opinions"? maybe. But I doubt there's much of that in there. However, the Constitution is actually based on well established and contemporary political theories of the time. Particularly notable as influences were Baron de Montesquieu, John Locke, and, yes, even British Common Law.
The US Constitution's Bill of Rights was heavily influenced by the actual English Bill of Rights, and contained a synthesis of many of the rights already present in each of the original States' constitutions. None of them was particularly aimed at protecting "wealthy land owners" specifically, unless you believe that, say, only wealthy people should have the right to peaceful assembly. But if that is the case, that says more about you than our forefathers' goals.
The concepts of the balance and separation of powers also was not really focused on a the well-being of "wealthy land owners," but on ideas that go back to the Roman Republic to prevent tyranny.
But I know that the factual historical roots of the US Constitution are not as shocking and sensationalist--and therefore not as interesting--as apocryphal boogey-men stories of corrupted and wealthy old geese plotting to enslave the masses.
Slashdot Mirror
>> I am also sure PopCap would not have bothered making their excellent Pants vs Zombies app if they were unable to sell it because people were playing the free Flash version instead
And why is that? I played the Flash version on their site, then downloaded the free demo version, and then paid for the full version. After finishing the Adventure mode three times over (working on the fourth), all the mini-games, and most of the puzzles (damn that nighttime fog!), I went ahead and paid the three bucks to play it on my iPod Touch (I'll never be bored at a meeting again!).
I'm sure I am not the only one who finds the game so good as to warrant paying for the full version over the short Flash version, especially when it's just three bucks.
-dZ.
Wait, since your argument for income was shown to be dubious, you now change it to say that the real problem is control?
Let's skip a few rounds and tell me what is the really really really real problem.
-dZ.
Sure, the iPhone and iPad should then come with a manual to teach and train the user in the interface intricacies of each web site or application, along with the standard set of built-in gestures.
-dZ.
Dude, do you realize that the AppStore was an afterthought? The iPhone was supposed to run exclusively Apple-only native apps, and FREE third-party web-apps, not to mention the entire (non-Flash) Internet on Safari. And indeed it worked like this for about a year.
If developers wanted to charge for subscription to their site or for access to their kewl game (which some did), Apple never had any control over this, nor did it care. This is the bit that you don't consider in your argument, that people did make money on web applications and iPhone widgets before and Apple had no worries over that.
The only change now is that they allow third-party native apps through their AppStore. All other third-party development remains accessible as before. You are right, Apple demands 30% of the cut if you intend to make money from your native app, but this is because they give you access to their massive distribution channel and payment processing system. If you go at it on your own (albeit not with a native app), you can keep the money yourself and Apple has no restrictions over that.
-dZ.
I'm a witch*, you insensitive clod!
-dZ.
* I'm not really a witch, don't burn me bro'.
I take your position to be that Flash is not the problem, but the actual use of it on some web applications is; that it is a matter of bad design.
I guess you then would suggest that rather than ban Flash altogether, Steve Jobs should tell all those developers and designers with crappy, broken sites that abuse Flash, to re-design them for the iPhone/iPad/iPod Touch, right?
Right, because that would be more practical than telling them to re-design their site with HTML5.
-dZ.
The threshold for inclusion in Wikipedia is not truth, but truthiness.
Not true. Nobody is stopping you (or anybody) from publishing your own articles or editing any existing one in Wikipedia. That your changes may get reverted later is another matter.
After all, it's "the free encyclopedia that anyone can edit", which indeed they can, not "the free encyclopedia which publishes anything that anyone who is not a member of the editor cabal edits."
-dZ.
Google doesn't belong in that list. You miss the point that Google's customers are actually the individual and organizations that advertise in their system. The search engine and GMail users are just the mechanism in which to exercise that system in order to increase the value of the advertising service they provide.
Making money hand over fist from their advertising network, and extracting cash directly from their real paying customers, makes Google a huge success.
-dZ.
>> Cubestorm for looks and sheer speed, sudoko robot for neatness and purity.
DEATHMATCH!!!!!!!!
Sure, the Sudoku robot can move around, but if it happens to wander too close, CubeStorm will twist its delicate figure into a wreck and solve it into a heap of yellow Duplo studs; and do it fast!
-dZ.
Or Legicks.
-dZ.
Employing a computer to solve a puzzle......-10 awesome points
Using an already existing algorithm.........-10 awesome points
Building it with Legos and making it
look like a menacing sci-fi movie prop......10^eleventy-billion points
Actually, they say "such and such is made of legos" with the implication that it increases its cool factor by about eleventy orders of awesomnitude.
-dZ.
When I got stuck on the Rubik's Cube, I just tossed it in the drawer with the rest of the forgotten toys. Cheating at it never even occurred to me.
-dZ.
What? Sex training?
Be aware that it may be frowned upon by certain authorities.
-dZ.
Very true, but my point is that software is not inherently flawed because humans write it, just as mathematics is not inherently flawed because humans discovered or created it. Software is flawed for many other reasons, mostly business pressures and time constraints, which are inherent in the development process itself, and not in the software.
-dZ.
>> It's not possible to do the sort of work he was doing while validating against a list of known-good inputs.
I say it is possible. It may not be possible in every application, but on his particular example it certainly is. His problem was due to a misunderstanding of the problem domain: instead of treating each image as a unique entity in itself, irrespective of message, and attempt to compare it to the already retrieved images through some special mechanism, he made the assumption that images would be unique within a message. As it turned out this assumption was wrong, but it was unnecessary to begin with.
I take your point and agree that knowing the entire input domain of a complex system may be impossible, but disagree that this will result in an inherent bug in the system. That which is not known should be treated as such and either ignored, dealt in some way, or flagged for later consideration, as the situation requires. You know the things you know, and therefore you can detect the things that you do not.
>> The domain of possibilities is simply too large to meaningfully cover it, and the same is true of newsgroup parsing.
This is true for the case of antivirus software, because over the years the problem domain (and in fact, the marketing claim) has been expanded to include not only known threats but future, unknown threats as well. For this, an attempt is made to make sense of the entire input domain, using heuristics and other statistical analyses, with the assumption that a certain percentage of false positives (or false negatives) is acceptable. This makes their effectiveness and usefulness rather questionable, depending on your threshold of acceptance.
The same may be true for newsgroup parsing, if indeed the author intends to detect stuff he doesn't even know exists, nor in what form; but this is typically not the case. It is much more likely that the application scope will be narrowed to solve specific known problems. This is certainly the case in the example provided by the poster, where a specific and discreet problem exists: to retrieve all unique images from all messages. He made the assumption that the entire input domain was known and then proceeded to implemented the application accordingly, without any acknowledgement to the limitations of this design.
That last part is bad design and bad practice, not an inherent flaw of software in general.
-dZ.
I'd understand your confusion if English is not your first language. However, that sentence is explicit and unambiguous:
The highlighted words assert that the slow-downs were a direct result of the memory consumption and that consequently virtual memory was consumed.
It is true that the article does not expressly state how they determined that virtual memory was consumed, but seeming that they make this assertion it stands to reason that it was at least observed in some manner. This is attested by a blog entry from the actual researches conducting the tests:
http://exo-blog.blogspot.com/
-dZ.
Actually, software is applied mathematics, which can be perfect to solve a discreet problem, indeed. However, there are many factors involved in the development of software, most unrelated to mathematics and algorithms, that hasten the design and implementation, and require compromising such perfect solutions.
It would then be more accurate to say Software is subject to business pressures, and as such it won't be perfect.
-dZ.
Ah, the ol' Reject-Known-Bad or Sanitise-All-Input paradigm. It is indeed impossible to anticipate all the bone-headed ways in which input can be botched, maliciously or not. Thus, it is then more secure to prepare a discreet list of valid input and only accept that, rejecting anything that does not conform to what you expect. This rejection is not based on a black-list of bad input to compare against, but on a sort of white-list what you assert your program can handle.
If you would have considered this approach, your application would have rejected the message with duplicate images (perhaps logging this reaction somewhere for you to review later), and continued churning along without crashing. (Alternatively, you could have modeled your application on the Real World and realized that messages may contain, and often do, the same image more than once and expected that; but I understand that problem analysis is not very common these days.)
Check out the OWASP Top Ten. Trying to maintain a black-list of all known bad input and all its variants is akin to an arms race in which you will always find yourself at the losing, reactionary end.
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
-dZ.
Is it "Company" as in "Company Name", or "Corporate Tax ID"? If the latter, then you require a business entity; the former is just an informal label, if you don't actually own a company. It could be something like "Tepple's Kewl SoftCo". This is typically termed a D.B.A, or "Doing Business As".
-dZ.
I think he's talking about the evolution of technology buzzwords.
No, seriously, get a life outside the Web.
-dZ.
"Opinions"? maybe. But I doubt there's much of that in there. However, the Constitution is actually based on well established and contemporary political theories of the time. Particularly notable as influences were Baron de Montesquieu, John Locke, and, yes, even British Common Law.
The US Constitution's Bill of Rights was heavily influenced by the actual English Bill of Rights, and contained a synthesis of many of the rights already present in each of the original States' constitutions. None of them was particularly aimed at protecting "wealthy land owners" specifically, unless you believe that, say, only wealthy people should have the right to peaceful assembly. But if that is the case, that says more about you than our forefathers' goals.
The concepts of the balance and separation of powers also was not really focused on a the well-being of "wealthy land owners," but on ideas that go back to the Roman Republic to prevent tyranny.
But I know that the factual historical roots of the US Constitution are not as shocking and sensationalist--and therefore not as interesting--as apocryphal boogey-men stories of corrupted and wealthy old geese plotting to enslave the masses.
-dZ.
It is possible, and I'd say rather probable, to peaceably assemble to discuss the violent overthrowing of the government.
As such, this law violates the First Ammendment.
-dZ.