So, you'll punish everyone in the US, but then you discover the world is round and actually quite big. And that it doesn't really matter if you control the US computers when everywhere else no one passed legislation on that and the unsecure versions would keep existing.
The only way to stop something like this is to heavily educate people. But who's going to pay for that? Who's going to profit? No one
You can simply send the public key in order to verify a signature by a private key. And there are ways to negotiate a secure exchange using only that. If they did things right, this thing is unstoppable unless ISP's get in on the action by disconnecting the infected nodes.
But knowing the infected machines was never the problem. Spamm e-mail brings with it the address... But you can't really go knocking down doors forcing people to scan their computers. That's why the black holes were designed, you wouldn't invade anyone's privacy but at the same time take them down.
Now, either the ISP's start disconnecting people that are infected, or you seem to stand no chance against it. But I believe new legislation will have to be drafted if we are to start disconnecting people off the internet for virus infections...
I think it's worse than that. If it works with the scheme fasttrack (for example) uses, you'd need to get the people behind the computer to actually kill it. Even if they get the original machine, they can just switch places and keep going (since there is no single point of failure, from what I read).
Most likely depends on the key scheme they used and how they "protect" it. But standard public key encryption schemes should give anyone a run for their money for a few years...
Oh, and before you answer, not that it mentions a C&C server, there is no need for a server in this - just someone with a computer and the right access.
Fasttrack (Kazaa) or skype are not tied down to one server. The only centralized source in those, I believe, it's the log in... But I don't think these require that.
On the other hand, spreading information through the network could be slow, making it less efficient.
The only way the RIAA stopped kazaa was by exploiting their checksum algorithm to difuse bogus info. But I don't think that is an option. On the other hand, it should be possible for anyone to give orders to this botnet if they know the "key" to order them around... But if done right, that should be impossible.(or highly improbable)
Actually, the core of his compression scheme seems to be constructing an LZW dictionary but using line patterns instead of bits or letters. The reason it works is because he jumps ahead of all those arrangements that would have probably been made letter by letter a, an, and, and , and h, (etc) which is what makes lzw and it's variants slow.
It was clever, but any Theory of Information course should tell you that choosing your "default" symbols correctly is very important. He did just that (:
I never claimed you should. I also said it wasn't a best practice. But if you didn't know how JOIN worked it would be orders of magnitude faster than using the IN. That's all I've said. PHP hasn't been that slow for over five years now (slower than C obviously, but going through an array should still be completed in linear time - you only have to pass your table once), and even though (as I mentioned) this kind of practice could lead to concurrency issues, it WORKS in this case.. That's all I've said.
On the other hand, you tried to humiliate someone with an incorrect statement. Again, there are no roudtrips. There is no client involved. Just someone processing some data using PHP. You've been spouting lingo trying to define yourself as someone "in the know". But if you want people to respect your point of you... Not having idiotic kneejerk reactions would be a nice start.
Don't flatter yourself. Either you're someone that suffers from verbal diarrhea and has too much time on his hands to cultivate a user farm, or you're payed to do this.
I want to believe that someone would only do this kind of thing if they were getting payed... but I guess that some people are just that lifeless. Good for you! (:
No, just the 10000 ones the OP mentioned. And the bigger the more there are, the more you have to wait.
And you're trying to cover your failure by nitpicking. There are no extra roundtrips, a webserver should not be the client. You messed up, just admit it already and move on.
In my CS degree there is a DB benchmarking course where you can see that there are queries taking minutes in Oracle or Postgresql that had to be canceled after 18 hours straight running in mysql (with no end in sight). So yes, in enterprise systems it isn't that hard to conjure a badly formed query that takes minutes to run, like I mentioned.
And, as stated, it still runs faster than the IN statement (not the JOIN, as everyone already said). The server is the client... Never heard that one before, I guess the OP is not the only one that needs to express itself better. From where I come from never heard the server called client before.
Second, for small businesses and the like, yes, the webserver and the DB server share resources. It's not only common, it's actually the default configuration option when you configure apache and php (so I'm guessing, not uncommon).
And there is no extra roundtrip for anything anyways. You do a query and then you filter them serverside and that's it. The time you described about passing everything through the process is negligible when you consider the time (sometimes minutes) that the server takes to process the IN, so you're still wrong.
The only thing you got right is that the join method will be faster. But that's what everyone has been telling everywhere from the start.
I can't, for the life of me, see how this could have been marked as informative. Tests ( http://www.anandtech.com/show/3794/the-iphone-4-review/2 ) show that the iPhone 4's antennae behaves very much like the Nexus One antennae, but when gripped drops the signal much more than the iPhone 3GS and the Nexus One.
There is a serious flaw that manifests in low reception areas and with left handed people. If it wasn't a big problem, it would not have been noticed.
Apple touted improved reception and revolutionary design in it's adds, but that was not true, and it took them long enough to "admit" it (actually, they never did, but still accepted returns and gave free bumpers to those affected with by the problem they claim did not exist).
In one thing you're right though, the hype was ridiculous. But what caused that hype was people proving, either by simple tests or real research, Few days after steve job's mea culpa (or actually "no culpa"), the media frenzy stopped. It's a textbook example on how not to handle a problem.
Most recent prints have wireless connectivity. From there to a coarse location is not a stretch (and since some actually contact an outside server, they can even trace the IP back to you).
Also, documents sometimes have that information themselves, and the printer can use that information to identify the creator.
Not saying they do, just that if they want to know where you are, they can. Printers with modified firmware have even been used as points of entry by the government before, so it's not that far fetched that the seemingly innocuous device can gather lots of information about you.
Yes, he could have phrased it better, but php is processed server side, the client only gets the final result. So no more round trips except the ones between server and database (and in most cases, they are on the same machine or cluster, so it's negligible).
His method does speed up things if the query is executed with an IN and not with a JOIN... Even if it's not a best practice (lots of concurrency issues if you make things like that frequently).
Where do you see the client and the roundtrips? There would be only one (DB access once) and the the this method would be 100% transparent to the client.
Don't get excited, I'm sure they'll conclude that there is too much to tell in one book and separate it into two volumes, making sure the cash co... the books keep going.
"Apple Inc. has exclusive rights to the hardware and software that would make it possible for Amazon.com to provide Amazon Instant Videos for these devices"
It makes as much sense as Adobe having the hardware. It could have something to do with patents on DRM'ed video delivery that Apple owns or something like that.
Slashdot Mirror
So, you'll punish everyone in the US, but then you discover the world is round and actually quite big. And that it doesn't really matter if you control the US computers when everywhere else no one passed legislation on that and the unsecure versions would keep existing.
The only way to stop something like this is to heavily educate people. But who's going to pay for that? Who's going to profit? No one
Yep, I was about to hit you on that :P
You can simply send the public key in order to verify a signature by a private key. And there are ways to negotiate a secure exchange using only that. If they did things right, this thing is unstoppable unless ISP's get in on the action by disconnecting the infected nodes.
But knowing the infected machines was never the problem. Spamm e-mail brings with it the address... But you can't really go knocking down doors forcing people to scan their computers. That's why the black holes were designed, you wouldn't invade anyone's privacy but at the same time take them down.
Now, either the ISP's start disconnecting people that are infected, or you seem to stand no chance against it. But I believe new legislation will have to be drafted if we are to start disconnecting people off the internet for virus infections...
I think it's worse than that. If it works with the scheme fasttrack (for example) uses, you'd need to get the people behind the computer to actually kill it. Even if they get the original machine, they can just switch places and keep going (since there is no single point of failure, from what I read).
The article is not wrong. There is no need for a C&C server, which doesn't mean there aren't people with computers controlling it...
Most likely depends on the key scheme they used and how they "protect" it. But standard public key encryption schemes should give anyone a run for their money for a few years...
Oh, and before you answer, not that it mentions a C&C server, there is no need for a server in this - just someone with a computer and the right access.
Fasttrack (Kazaa) or skype are not tied down to one server. The only centralized source in those, I believe, it's the log in... But I don't think these require that.
On the other hand, spreading information through the network could be slow, making it less efficient.
The only way the RIAA stopped kazaa was by exploiting their checksum algorithm to difuse bogus info. But I don't think that is an option. On the other hand, it should be possible for anyone to give orders to this botnet if they know the "key" to order them around... But if done right, that should be impossible.(or highly improbable)
Actually, the core of his compression scheme seems to be constructing an LZW dictionary but using line patterns instead of bits or letters. The reason it works is because he jumps ahead of all those arrangements that would have probably been made letter by letter a, an, and, and , and h, (etc) which is what makes lzw and it's variants slow.
It was clever, but any Theory of Information course should tell you that choosing your "default" symbols correctly is very important. He did just that (:
Sigh.
I never claimed you should. I also said it wasn't a best practice. But if you didn't know how JOIN worked it would be orders of magnitude faster than using the IN. That's all I've said. PHP hasn't been that slow for over five years now (slower than C obviously, but going through an array should still be completed in linear time - you only have to pass your table once), and even though (as I mentioned) this kind of practice could lead to concurrency issues, it WORKS in this case.. That's all I've said.
On the other hand, you tried to humiliate someone with an incorrect statement. Again, there are no roudtrips. There is no client involved. Just someone processing some data using PHP. You've been spouting lingo trying to define yourself as someone "in the know". But if you want people to respect your point of you... Not having idiotic kneejerk reactions would be a nice start.
Don't flatter yourself. Either you're someone that suffers from verbal diarrhea and has too much time on his hands to cultivate a user farm, or you're payed to do this.
I want to believe that someone would only do this kind of thing if they were getting payed... but I guess that some people are just that lifeless. Good for you! (:
PS: That anonymous was obviously not me.
Maybe they just employ the same marketing firm and they rotate accounts.
No, just the 10000 ones the OP mentioned. And the bigger the more there are, the more you have to wait.
And you're trying to cover your failure by nitpicking. There are no extra roundtrips, a webserver should not be the client. You messed up, just admit it already and move on.
In my CS degree there is a DB benchmarking course where you can see that there are queries taking minutes in Oracle or Postgresql that had to be canceled after 18 hours straight running in mysql (with no end in sight). So yes, in enterprise systems it isn't that hard to conjure a badly formed query that takes minutes to run, like I mentioned.
And, as stated, it still runs faster than the IN statement (not the JOIN, as everyone already said). The server is the client... Never heard that one before, I guess the OP is not the only one that needs to express itself better. From where I come from never heard the server called client before.
Second, for small businesses and the like, yes, the webserver and the DB server share resources. It's not only common, it's actually the default configuration option when you configure apache and php (so I'm guessing, not uncommon).
And there is no extra roundtrip for anything anyways. You do a query and then you filter them serverside and that's it. The time you described about passing everything through the process is negligible when you consider the time (sometimes minutes) that the server takes to process the IN, so you're still wrong.
The only thing you got right is that the join method will be faster. But that's what everyone has been telling everywhere from the start.
I can't, for the life of me, see how this could have been marked as informative. Tests ( http://www.anandtech.com/show/3794/the-iphone-4-review/2 ) show that the iPhone 4's antennae behaves very much like the Nexus One antennae, but when gripped drops the signal much more than the iPhone 3GS and the Nexus One.
There is a serious flaw that manifests in low reception areas and with left handed people. If it wasn't a big problem, it would not have been noticed.
Apple touted improved reception and revolutionary design in it's adds, but that was not true, and it took them long enough to "admit" it (actually, they never did, but still accepted returns and gave free bumpers to those affected with by the problem they claim did not exist).
In one thing you're right though, the hype was ridiculous. But what caused that hype was people proving, either by simple tests or real research, Few days after steve job's mea culpa (or actually "no culpa"), the media frenzy stopped. It's a textbook example on how not to handle a problem.
You completely missed the point of his rant. He was arguing for your point.
Most recent prints have wireless connectivity. From there to a coarse location is not a stretch (and since some actually contact an outside server, they can even trace the IP back to you).
Also, documents sometimes have that information themselves, and the printer can use that information to identify the creator.
Not saying they do, just that if they want to know where you are, they can. Printers with modified firmware have even been used as points of entry by the government before, so it's not that far fetched that the seemingly innocuous device can gather lots of information about you.
Yes, he could have phrased it better, but php is processed server side, the client only gets the final result. So no more round trips except the ones between server and database (and in most cases, they are on the same machine or cluster, so it's negligible).
His method does speed up things if the query is executed with an IN and not with a JOIN... Even if it's not a best practice (lots of concurrency issues if you make things like that frequently).
Homeopathy? The fact that he takes a whole box of sleeping "medicine" before each presentation and never, ever, did they work?
It might not be scientific method, but it's enough for me.
Where do you see the client and the roundtrips? There would be only one (DB access once) and the the this method would be 100% transparent to the client.
Don't get excited, I'm sure they'll conclude that there is too much to tell in one book and separate it into two volumes, making sure the cash co... the books keep going.
Yes, since you don't like it then it is a bad book. Everyone knows that (:
http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale
"Apple Inc. has exclusive rights to the hardware and software that would make it possible for Amazon.com to provide Amazon Instant Videos for these devices"
It makes as much sense as Adobe having the hardware. It could have something to do with patents on DRM'ed video delivery that Apple owns or something like that.