Not only was I going to buy Starcraft II, but I was thinking about purchasing a nice laptop to run it (as my current machine is a desktop and WAY too outdated to play it) and a second "LAN license" so my roommate could play. Now, it's not worth it to me; our internet connection can't handle the traffic of two online games to Battle.net at once, and even if it could, what if we have our laptops somewhere we cannot access Battle.net? Maybe we're on a bus, or train, maybe we're in a park. Maybe we don't like latency.
Blizzard, the only thing you won't be selling out with this move is copies of Startcraft II.
It sounds to me like these operations are "safe" because the folks doing the 3rd-party analysis never see the results, or the original data. Basically, you can add two encrypted values together and get a third encrypted value which contains the answer, and that answer can only be seen via decryption with the key.
What the hell good is that to Mr. 3rd Party processor? Why don't the original data holders just do it themselves, which will probably increase security and accuracy? If your data is so sensitive it needs to be heavily encrypted, should you really run the risk of outsourcing data analysis to a 3rd party that can't even check their work for accuracy? What if some subtle rounding error goes unnoticed during testing? This could cost you millions.
People think Google is a program you install on your computer. People think their headset is called a "blue tooth". People think that TCP/IP is a chain of yogurt shops.
You can go ahead and do that if you want, but any system I ever sell, administer, maintain, or own, password entry will be as obscure as possible. If you can't handle typing a password, you have no business performing operations which require one.
Don't tell me we need a military bigger than the rest of the world combined to protect us from Mexico and Canada.
Since wars aren't started by marching armies of archers and horse cavalry anymore, I'd say we need a large military to protect us from just about anyone. Now, what we decide to use that military for when no one is attacking us is another story...
I thought when the grid went down that synced panel set ups just cut them selves off from the grid, not that they cut them selves off from powering your home.
Yeah, that makes way more sense, and can't be that hard to implement (IBGTs, anyone?)
Yes, the 1s are skinny and the 0s are fat. You see, there is more space to compress between a line of evenly spaced 1s than between a line of evenly spaced 0s. If you compress wth too much force, the 0s get "squished", they'll turn into 1s, and this can screw up the formatting and cause segfaults and kernel panics, even in the newer Linux builds. There isn't much that can be done about this, even with today's protected memory designs, so we're limited to removing the space in between. It might help you to think of this technique as the giant laser thingie in "Honey, I Shrunk The Kids!" which recuded the space between atoms of objects in order to shrink them.
ROR compression (a variation of the.rar format) uses this particular method, replacing the 0s with a counter of how many 0s in a row where replaced, and then compressing the 1s together. This is called "Packed Binary Coding".
Similar methods where developed by American researchers (Dynamic Unicode Hypertensioning), but instead of simply compressing the 1s, they are instead converted into a pipe character ("|") so as to prevent the tick mark adorning the shaft of the 1 to prevent further compression (or errors resulting from "tilt" when the ones are pressed together too forcefully).
These are second-year Comp Sci concepts. What is/. coming too when we're not even keeping up with the basics? It's a sad day for geeks everywhere.
Facebook needs to step back and optimize, optimize, optimize. They're well ahead of MySpace, and with the reputation MySpace is getting, Facebook would do well to keep things clean and fast; there isn't really a danger of competitor innovation destroying them (in the short term).
If you save 320 bytes per file, serving 200 different files 750,000 times per day each (imagine some HTML docs that load a bunch of images, JavaScript, and CSS), that's 1.3TB over the course of 30 days. It adds up fast.
320 was chosen out of the air, as the total length of removed JavaScript comments (320 bytes is the content of 2 full SMS messages), trimmed image pixels, or extraneous tabs in an HTML document. Of course some files will see more page hits than others, some days will see less traffic on the site, and some files/file types are likely to be reduced by different amounts. The question still remains - how you would like to reduce your bandwidth bill and have your users be happier with your site all at the same time? Less traffic, maybe you don't need to bother with it. 500 hits/day sure paints a different picture (915MB/month), but upper-mid-sized sites which rely on leased hosting should really be keeping an eye on this, and it certainly would be good netiquette for everyone to ensure optimized traffic.
Sounds like you're talking about server-side HTMLTidy. Jesus, how are you supposed to troubleshoot if your page doesn't publish/render the same way as you develop it? I guess "LAZY" is the answer. If that was a good idea I think the W3C would've mandated it with HTML 3.0.
Turn it off in your dev environment until you're ready to debug issues that come up with it (i.e. after you feel everything is ready otherwise). Sure it's an extra cycle of development, but if HTMLTidy (or whatever you use) isn't doing something really weird, everything should work exactly the same as it does without it being turned on.
A 15k savings per page load on a site that gets 15 million hits per day = 429.15GB less traffic per month. How much do you pay per GB of traffic? Would this be worth it? What if you could reduce the load size further? There are definitely major, high-traffic sites out there that could reduce their page load footprint by more than 15k/load, especially if they started using the browser cache properly...
While you're absolutely right (there is no excuse to not support gzip compression on your web server these days), a file loaded with comments and unnecessary whitespace is still going to compress down to a larger size than one with all the comments, out-of-tag whitespace removed. There is simply less data to compress in the first place. (Note: things such as long CSS ids are of no matter, because they'll be pattern-matched and take up the same space as a shorter name, anyway)
An important distinction here is that JavaScript code is known to be properly sandboxed by Apple and AT&T. This is also OK for the Sega games running as emulation of the original ROM; That is no different from a game app that has a data file in it. The problem comes when you allow users to load any code they want into a potentially unprotected environment. Then, this becomes a liability issue.
Apple wrote the JavaScript engine that runs on the iPhone. If there are flaws, they can push updates to fix it, or if it's severe enough disable some or all JavaScript until a fix can be made. The implications here are staggering - suppose a bug gets out into the wild which involves a JavaScript 'sploit followed by a 3G DDoS attack. AT&T's whole network becomes saturated, iPhone or not. This can disrupt E911 services. Because of a JavaScript bug, someone might die. It's unlikely, but if it happens it's a HUGE liability. Everyone from the family of the deceased to the state would have a stake in that lawsuit.
Apple has a failsafe here - they can shut it down before it spins out of control because they have access to the code. They can push updates out before their phones become an army of virus-spewing BlueTooth devices nailing ever PC (or even Mac) they come with in 30 feet of.
Now imagine it happens through a bug in this Commadore 64 App, or any other App that would allow executable code. Apple has little control over that, much less so than if a flaw was their own problem. Don't get me wrong, Apple has a good reputation for security, they build solid products, and what I describe here is very unlikely to happen.
Not only that, but forcing a person to break a legal contract as a condition of employment is illegal (most website's TOS forbids password sharing), and by knowingly logging in with false credentials, you've committed computer fraud.
We're not just talking monetary penalties here. This is a felony.
Are those plates causing more oil to be consumed than would happen otherwise?
Of course. Energy has to come from somewhere. In order for the plates to be pushed down, the car has to climb up. Granted, this might be as little energy as climbing a kerbstone, it shows how little energy can be gained. It's not free and it's not green but it's publicity.
If you drove a car towards these plates, put the car in neutral while moving, and turned the engine off before rolling over the plates, would they generate any less energy than driving over them at the same speed with the engine running?
I think the "burned oil" (it would actually be gasoline or diesel fuel, unless you need new rings or a head gasket) is pretty much the FAULT OF THE PERSON WHO DROVE THE CAR THAT IS BURNING IT.
And the work for pressing the plates down is done by what? Maybe, that could be, uhmm... the cars driving over them, yes? So basically they are using their customers fuel to power their store and call that "green". Way to go, guys.
What a troll. These cars are going to be driving over the pavement and exerting the SAME FORCE which makes the plates work anyway, wearing away on standard surfacing instead of being harnessed by this system and put to good use. That surface, ASPHALT, also comes from a petroleum base, and although highly recyclable, is just another cost to contend with; at least by the time the kinetic plates need repair/replacement (if built right), the business will have saved some money on electricity costs. Also, that's up to 30 kWh of power they don't have to buy from the grid, which doesn't need to be generated. Sure, one store doesn't make a difference (generators will run just as hard), but once you start seeing these everywhere, suddenly we need to burn less coal because the high energy demands are partially met by simply letting gravity do the work.
Slashdot Mirror
Not only was I going to buy Starcraft II, but I was thinking about purchasing a nice laptop to run it (as my current machine is a desktop and WAY too outdated to play it) and a second "LAN license" so my roommate could play. Now, it's not worth it to me; our internet connection can't handle the traffic of two online games to Battle.net at once, and even if it could, what if we have our laptops somewhere we cannot access Battle.net? Maybe we're on a bus, or train, maybe we're in a park. Maybe we don't like latency.
Blizzard, the only thing you won't be selling out with this move is copies of Startcraft II.
Good Morning to you;
Good Morning to you;
Good Morning, dear children;
Good Morning to all!
Bring it on, Warner...
It sounds to me like these operations are "safe" because the folks doing the 3rd-party analysis never see the results, or the original data. Basically, you can add two encrypted values together and get a third encrypted value which contains the answer, and that answer can only be seen via decryption with the key.
What the hell good is that to Mr. 3rd Party processor? Why don't the original data holders just do it themselves, which will probably increase security and accuracy? If your data is so sensitive it needs to be heavily encrypted, should you really run the risk of outsourcing data analysis to a 3rd party that can't even check their work for accuracy? What if some subtle rounding error goes unnoticed during testing? This could cost you millions.
People think Google is a program you install on your computer. People think their headset is called a "blue tooth". People think that TCP/IP is a chain of yogurt shops.
You can go ahead and do that if you want, but any system I ever sell, administer, maintain, or own, password entry will be as obscure as possible. If you can't handle typing a password, you have no business performing operations which require one.
I had no problem opening up a Norelco to solder in new NiC. Coincidentally, I also did the same to a couple of Panasonic shavers.
How many megawhiskers where they?
Don't tell me we need a military bigger than the rest of the world combined to protect us from Mexico and Canada.
Since wars aren't started by marching armies of archers and horse cavalry anymore, I'd say we need a large military to protect us from just about anyone. Now, what we decide to use that military for when no one is attacking us is another story...
I thought when the grid went down that synced panel set ups just cut them selves off from the grid, not that they cut them selves off from powering your home.
Yeah, that makes way more sense, and can't be that hard to implement (IBGTs, anyone?)
Yes, the 1s are skinny and the 0s are fat. You see, there is more space to compress between a line of evenly spaced 1s than between a line of evenly spaced 0s. If you compress wth too much force, the 0s get "squished", they'll turn into 1s, and this can screw up the formatting and cause segfaults and kernel panics, even in the newer Linux builds. There isn't much that can be done about this, even with today's protected memory designs, so we're limited to removing the space in between. It might help you to think of this technique as the giant laser thingie in "Honey, I Shrunk The Kids!" which recuded the space between atoms of objects in order to shrink them.
ROR compression (a variation of the .rar format) uses this particular method, replacing the 0s with a counter of how many 0s in a row where replaced, and then compressing the 1s together. This is called "Packed Binary Coding".
Similar methods where developed by American researchers (Dynamic Unicode Hypertensioning), but instead of simply compressing the 1s, they are instead converted into a pipe character ("|") so as to prevent the tick mark adorning the shaft of the 1 to prevent further compression (or errors resulting from "tilt" when the ones are pressed together too forcefully).
These are second-year Comp Sci concepts. What is /. coming too when we're not even keeping up with the basics? It's a sad day for geeks everywhere.
Facebook needs to step back and optimize, optimize, optimize. They're well ahead of MySpace, and with the reputation MySpace is getting, Facebook would do well to keep things clean and fast; there isn't really a danger of competitor innovation destroying them (in the short term).
If you save 320 bytes per file, serving 200 different files 750,000 times per day each (imagine some HTML docs that load a bunch of images, JavaScript, and CSS), that's 1.3TB over the course of 30 days. It adds up fast.
320 was chosen out of the air, as the total length of removed JavaScript comments (320 bytes is the content of 2 full SMS messages), trimmed image pixels, or extraneous tabs in an HTML document. Of course some files will see more page hits than others, some days will see less traffic on the site, and some files/file types are likely to be reduced by different amounts. The question still remains - how you would like to reduce your bandwidth bill and have your users be happier with your site all at the same time? Less traffic, maybe you don't need to bother with it. 500 hits/day sure paints a different picture (915MB/month), but upper-mid-sized sites which rely on leased hosting should really be keeping an eye on this, and it certainly would be good netiquette for everyone to ensure optimized traffic.
Sounds like you're talking about server-side HTMLTidy. Jesus, how are you supposed to troubleshoot if your page doesn't publish/render the same way as you develop it? I guess "LAZY" is the answer. If that was a good idea I think the W3C would've mandated it with HTML 3.0.
Turn it off in your dev environment until you're ready to debug issues that come up with it (i.e. after you feel everything is ready otherwise). Sure it's an extra cycle of development, but if HTMLTidy (or whatever you use) isn't doing something really weird, everything should work exactly the same as it does without it being turned on.
A 15k savings per page load on a site that gets 15 million hits per day = 429.15GB less traffic per month. How much do you pay per GB of traffic? Would this be worth it? What if you could reduce the load size further? There are definitely major, high-traffic sites out there that could reduce their page load footprint by more than 15k/load, especially if they started using the browser cache properly...
Don't forget, those "unneeded" closing tags are needed in HTML 5. The days of newline tag closings are numbered.
While you're absolutely right (there is no excuse to not support gzip compression on your web server these days), a file loaded with comments and unnecessary whitespace is still going to compress down to a larger size than one with all the comments, out-of-tag whitespace removed. There is simply less data to compress in the first place. (Note: things such as long CSS ids are of no matter, because they'll be pattern-matched and take up the same space as a shorter name, anyway)
According to Wikipedia: "Mung is described as 'the stuff that comes out when you push down on a pregnant woman's stomach.'"
An important distinction here is that JavaScript code is known to be properly sandboxed by Apple and AT&T. This is also OK for the Sega games running as emulation of the original ROM; That is no different from a game app that has a data file in it. The problem comes when you allow users to load any code they want into a potentially unprotected environment. Then, this becomes a liability issue.
Apple wrote the JavaScript engine that runs on the iPhone. If there are flaws, they can push updates to fix it, or if it's severe enough disable some or all JavaScript until a fix can be made. The implications here are staggering - suppose a bug gets out into the wild which involves a JavaScript 'sploit followed by a 3G DDoS attack. AT&T's whole network becomes saturated, iPhone or not. This can disrupt E911 services. Because of a JavaScript bug, someone might die. It's unlikely, but if it happens it's a HUGE liability. Everyone from the family of the deceased to the state would have a stake in that lawsuit.
Apple has a failsafe here - they can shut it down before it spins out of control because they have access to the code. They can push updates out before their phones become an army of virus-spewing BlueTooth devices nailing ever PC (or even Mac) they come with in 30 feet of.
Now imagine it happens through a bug in this Commadore 64 App, or any other App that would allow executable code. Apple has little control over that, much less so than if a flaw was their own problem. Don't get me wrong, Apple has a good reputation for security, they build solid products, and what I describe here is very unlikely to happen.
...but it's not impossible.
You keep using that word. I do not think it means what you think it means.
.....aaaannnnddd -1 Redundant, beaten by an AC. FML.
Real datacenters use Emacs.
I love it when you talk dirty like that! Gimme some more, and say it in a hoarse whisper!
*neigh*
Not only that, but forcing a person to break a legal contract as a condition of employment is illegal (most website's TOS forbids password sharing), and by knowingly logging in with false credentials, you've committed computer fraud.
We're not just talking monetary penalties here. This is a felony.
Are those plates causing more oil to be consumed than would happen otherwise?
Of course. Energy has to come from somewhere. In order for the plates to be pushed down, the car has to climb up. Granted, this might be as little energy as climbing a kerbstone, it shows how little energy can be gained. It's not free and it's not green but it's publicity.
If you drove a car towards these plates, put the car in neutral while moving, and turned the engine off before rolling over the plates, would they generate any less energy than driving over them at the same speed with the engine running?
I think the "burned oil" (it would actually be gasoline or diesel fuel, unless you need new rings or a head gasket) is pretty much the FAULT OF THE PERSON WHO DROVE THE CAR THAT IS BURNING IT.
But hey, don't let me stop you from trolling.
And the work for pressing the plates down is done by what? Maybe, that could be, uhmm... the cars driving over them, yes? So basically they are using their customers fuel to power their store and call that "green". Way to go, guys.
What a troll. These cars are going to be driving over the pavement and exerting the SAME FORCE which makes the plates work anyway, wearing away on standard surfacing instead of being harnessed by this system and put to good use. That surface, ASPHALT, also comes from a petroleum base, and although highly recyclable, is just another cost to contend with; at least by the time the kinetic plates need repair/replacement (if built right), the business will have saved some money on electricity costs. Also, that's up to 30 kWh of power they don't have to buy from the grid, which doesn't need to be generated. Sure, one store doesn't make a difference (generators will run just as hard), but once you start seeing these everywhere, suddenly we need to burn less coal because the high energy demands are partially met by simply letting gravity do the work.
Tea & Crumpets: The Game!
Coming soon: Dodging Dentists 2
WHOOOOOOOSH!