"Only days after Nintendo shipped Wii Menu 3.3, which stopped the Twilight Hack from working, the team lead by Bushing brought out a new version of the Homebrew enabling hack for the Nintendo Wii using the Zelda Game and a hacked save game."
This tells us that the wii allows content executables to run at a root/system level of elevated privilege.
No matter what Nintento does, they have no way to remove this security hole in way that would break the massive distribution of popular older software like Zelda.
The least ineffective solution at Nintendo's disposal would be to only run external executables in an isolated virtual machine.
Even that would suffer the same flaw. If the virtual machine is sufficient to run a game like Zelda with middling level demanding 3d graphics, it can offer enough resources to run a user provided, OS alternative.
The only solution I can see would be for Nintendo to implement a hash checking method in addition to VM architecture. The most effective method being copying to local storage before running and then running a hash check independant of the game media.
I don't know much about wii hardware, but I'm guessing it doesn't have enough storage (or at least storage fast enough to be acceptable for consumer expectation) for this to work.
So, it doesn't matter what Nintendo does, the wii will forever be a hackable platform.
I like the way linux bandwidth arbitrator (http://www.bandwidtharbitrator.com/) approaches the problem. -
Set your total bandwidth minus the guaranteed bandwidth you want to allocate to priority traffic masked/identified either by port/protocol/src/dest or by a deep packet (perl based) inspection. -
If any app OR host OR connection OR port starts encroaching on the latency of other others, it gets chucked into memory jail for a fixed number of escalating milliseconds. -
This has a two fold benefit for latency and bandwidth contention issues. One, by chucking the hogs in memory jail, queue space is cleared up to allow priority traffic through on a more consistent basis. -
Imagine you've got a city bus that goes to sports stadium of your chosing. When it's not a game day, there are no problems boarding the bus. You get 3 or 4 people on their way home from or to work. On a game day though, you get those same 3 or 4 people plus an additional 20 drunk people who don't know how to board a bus. What usually happens is the 3 or 4 regulars either don't get a seat or have to wait until the next bus. Not good or fair. -
The way linux bandwidth arbitrator solves the problem is to tell the bus driver to watch for drunk idiots. If she sees more than three cubs fans in a row, she shouts out to them to step back, close their eyes and count to 10. While they're doing this (they're cubs fans, you know they would), she waves the regulars to the front of the line. -
So, it's good for latency and jitter. It's also good for bandwidth. All those bad packets you threw into memory jail? Well, a good portion of them are probably TCP which means there's a remote end of the connection waiting on an ACK before it sends more data. Even in the case of connectionless protocols like UDP, chances are there is some sort of app or session layer check that will defacto hold back sending more data until it receives a response. You've managed to stem the firehose that's half of the problem without resorting to cheap ass tactics like false RSTs. -
The beauty is, done right you don't need to know anything about the problem causing traffic to mitigate its effects. Assume you tag your priority packets with a deep inspection based on port/src/dst/prot (This is what almost never gets done). Whether it's eMule is running on port 443 or through a proxy or if it's a worm or the file sharing program of tomorrow, it gets throttled back. -
The drawback is it's a bitch and a half to get installed and three more bitches worth of pain to get configured and tuned. Once you do though, it rocks. - [I kid about cubs fans. I lived off of Addison Ave and dealt with my fair share of that scenario, but the bulk of the people in line were ok.]
Of course that 99.967% accuracy rate is the result of hundreds of thousands of data points while the above calculations are the result of five and a handful of guessed at numbers. Don't get me wrong, I think this is clever and funny as hell. I just hope no one is taking it seriously.
After reading the article, I decided to give initng a try. I timed my boot from a powered off state to the GDM login prompt so as to have a base-line, installed and configured init-ng 0.6.7, and then retimed from a power off. The result: initng ADDED 12 seconds to my boot time. Tried it again to see if it was a first boot fluke and got the same results to the second. This is on the latest feisty. Someone mentioned that Ubuntu 6.06 used upstart- it doesn't look like feisty is to me, but that might be my ignorance. Cest la vie.
I use Firefox on all of my home machines, and keep IE as the standard on the 300+ work PCs I control. Why? Because all of my home machines have 1GB of memory or better while at work 256-512MB is more the standard. You can bury your head in the sand all you want, but the fact is that IE6 uses less memory than both Firefox 1.5 and 2.0. I find it interesting, by the way, that the Firefox developer above states that they've fixed the most egregious memory leaks in 1.5. In trying to find a fix for the problem, this is the first indication I've seen of the Firefox developer community even admitting that 1.5 HAD memory leak problems. As someone stated earlier, this denial that there's problem only does the browser a diservice. So, I have four machines running Firefox and three hundred running IE. Multiply those numbers times numerous similar corporate environments and ask yourself how big of an impact the memory problem has on adoption?
I wonder how much SBC/ATT and Verizon have spent making sure this BS story keeps getting dredged up. Cowboy Neal is either a sucker or a stooge for posting this.
Too bad Blizzard considers the following general chat yell to be offensive, "OZ [the name of her guild] is recruiting all levels ¦ We are not 'GLBT only,' but we are 'GLBT friendly'! (guilduniverse.com/oz)" The player who said this was threatened with account suspension by the WoW gamemasters. Check out http://www.innewsweekly.com/innews/?class_code=Ga& article_code=1172 for the full story. My wife and I are canceling our accounts as a result.
Is there any evidence at all that it's Google that's responsible for this? We use a combination of Squid in transparent proxy mode and policy routing to do something very similar at the company I work for. It seems more likely to me that the Chinese government is altering google searches in this fasion than that Google itself is.
You're worried about the impact of not doing jumbo frames, but you're ok with the huge latency added by software routing? Ok then./backs slowly away.
If you stop to look at your entire data flow from beginning to end, very rarely is your bottleneck going to be in layer two if it's even in the network at all. Anyone who spends money on 1000BT for a home network is doing it for number fetish reasons, not for any sound technical reasons. It's no different than the idiot who overclocks their box and then spends 90% of their time browsing the web.
The software leaves out the most thought involved aspect of pool, the leave. Figuring out how to angle shots is something that you learn to intuit pretty quickly, especially if you're learning from someone with enough physical skill to put the ball where they visualize it.
The part of the game that involves the most thought is deciding where you want your ball to end up once you've finished your shot. Ideally you want to set yourself up for making another shot. This often means shooting a more difficult, less obvious shot first. At the same time, you have to ask yourself, "If I don't make this shot, how can I make sure that I don't leave my opponent with an easy shot." Again, this often means taking a less obvious shot, or putting a little extra back spin on the ball so that it rolls back a few more inches.
As with chess, the better you get, the more "moves" in advance you try to set yourself up for. You also start to realize that you need to understand your opponent's playing style so that you can accuratly guess at what shots they might play and try to leave them in a difficult position for those shots.
Think of it as a chess board, but instead of the pieces being locked into a nice 8x8 grid, they have continuous positioning throughout the entire board. Now, it's probably possible to write a program that will take all of this into account and try to predict what shots will be good to play. I think it'll be years before any such program is more than halfway decent though, and it will certainly have to be more than just an angle visualizer.
I see alot of people listing color as an attribute they'd like to see. Here's why I think it makes more sense to go with greyscale:
1. Cheaper to make meaning more accessable devices.
2. Because it's a simpler technology than color, it's cheaper and easier to manufacture higher resolution screens. I'd rather have 640x480 greyscale than 320x240 color.
3. Longer battery life.
4. Color is actually one of the least useful information tags. (Tufte)
Slashdot Mirror
"Only days after Nintendo shipped Wii Menu 3.3, which stopped the Twilight Hack from working, the team lead by Bushing brought out a new version of the Homebrew enabling hack for the Nintendo Wii using the Zelda Game and a hacked save game."
This tells us that the wii allows content executables to run at a root/system level of elevated privilege.
No matter what Nintento does, they have no way to remove this security hole in way that would break the massive distribution of popular older software like Zelda.
The least ineffective solution at Nintendo's disposal would be to only run external executables in an isolated virtual machine.
Even that would suffer the same flaw. If the virtual machine is sufficient to run a game like Zelda with middling level demanding 3d graphics, it can offer enough resources to run a user provided, OS alternative.
The only solution I can see would be for Nintendo to implement a hash checking method in addition to VM architecture. The most effective method being copying to local storage before running and then running a hash check independant of the game media.
I don't know much about wii hardware, but I'm guessing it doesn't have enough storage (or at least storage fast enough to be acceptable for consumer expectation) for this to work.
So, it doesn't matter what Nintendo does, the wii will forever be a hackable platform.
Naw, it's,
Hackers: 10, Nintento: 01
I like the way linux bandwidth arbitrator (http://www.bandwidtharbitrator.com/) approaches the problem.
-
Set your total bandwidth minus the guaranteed bandwidth you want to allocate to priority traffic masked/identified either by port/protocol/src/dest or by a deep packet (perl based) inspection.
-
If any app OR host OR connection OR port starts encroaching on the latency of other others, it gets chucked into memory jail for a fixed number of escalating milliseconds.
-
This has a two fold benefit for latency and bandwidth contention issues. One, by chucking the hogs in memory jail, queue space is cleared up to allow priority traffic through on a more consistent basis.
-
Imagine you've got a city bus that goes to sports stadium of your chosing. When it's not a
game day, there are no problems boarding the bus. You get 3 or 4 people on their way home from or to work. On a game day though, you get those same 3 or 4 people plus an additional 20 drunk people who don't know how to board a bus. What usually happens is the 3 or 4 regulars either don't get a seat or have to wait until the next bus. Not good or fair.
-
The way linux bandwidth arbitrator solves the problem is to tell the bus driver to watch for drunk idiots. If she sees more than three cubs fans in a row, she shouts out to them to step back, close their eyes and count to 10. While they're doing this (they're cubs fans, you know they would), she waves the regulars to the front of the line.
-
So, it's good for latency and jitter. It's also good for bandwidth. All those bad packets you threw into memory jail? Well, a good portion of them are probably TCP which means there's a remote end of the connection waiting on an ACK before it sends more data. Even in the case of connectionless protocols like UDP, chances are there is some sort of app or session layer check that will defacto hold back sending more data until it receives a response. You've managed to stem the firehose that's half of the problem without resorting to cheap ass tactics like false RSTs.
-
The beauty is, done right you don't need to know anything about the problem causing traffic to mitigate its effects. Assume you tag your priority packets with a deep inspection based on port/src/dst/prot (This is what almost never gets done). Whether it's eMule is running on port 443 or through a proxy or if it's a worm or the file sharing program of tomorrow, it gets throttled back.
-
The drawback is it's a bitch and a half to get installed and three more bitches worth of pain to get configured and tuned. Once you do though, it rocks.
-
[I kid about cubs fans. I lived off of Addison Ave and dealt with my fair share of that scenario, but the bulk of the people in line were ok.]
"What Could You Do With a Bogus Root Name Server?" Easy, slap it around and call it Suzy. Or possibly, put it in a sack and beat it senseless.
Of course that 99.967% accuracy rate is the result of hundreds of thousands of data points while the above calculations are the result of five and a handful of guessed at numbers. Don't get me wrong, I think this is clever and funny as hell. I just hope no one is taking it seriously.
How much do you want bet that if you took a look at the code under the hood, you'd find sections stolen from here: http://www.bandwidtharbitrator.com/
After reading the article, I decided to give initng a try. I timed my boot from a powered off state to the GDM login prompt so as to have a base-line, installed and configured init-ng 0.6.7, and then retimed from a power off. The result: initng ADDED 12 seconds to my boot time. Tried it again to see if it was a first boot fluke and got the same results to the second. This is on the latest feisty. Someone mentioned that Ubuntu 6.06 used upstart- it doesn't look like feisty is to me, but that might be my ignorance. Cest la vie.
I use Firefox on all of my home machines, and keep IE as the standard on the 300+ work PCs I control. Why? Because all of my home machines have 1GB of memory or better while at work 256-512MB is more the standard. You can bury your head in the sand all you want, but the fact is that IE6 uses less memory than both Firefox 1.5 and 2.0. I find it interesting, by the way, that the Firefox developer above states that they've fixed the most egregious memory leaks in 1.5. In trying to find a fix for the problem, this is the first indication I've seen of the Firefox developer community even admitting that 1.5 HAD memory leak problems. As someone stated earlier, this denial that there's problem only does the browser a diservice. So, I have four machines running Firefox and three hundred running IE. Multiply those numbers times numerous similar corporate environments and ask yourself how big of an impact the memory problem has on adoption?
I wonder how much SBC/ATT and Verizon have spent making sure this BS story keeps getting dredged up. Cowboy Neal is either a sucker or a stooge for posting this.
Too bad Blizzard considers the following general chat yell to be offensive, "OZ [the name of her guild] is recruiting all levels ¦ We are not 'GLBT only,' but we are 'GLBT friendly'! (guilduniverse.com/oz)" The player who said this was threatened with account suspension by the WoW gamemasters. Check out http://www.innewsweekly.com/innews/?class_code=Ga& article_code=1172 for the full story. My wife and I are canceling our accounts as a result.
Is there any evidence at all that it's Google that's responsible for this? We use a combination of Squid in transparent proxy mode and policy routing to do something very similar at the company I work for. It seems more likely to me that the Chinese government is altering google searches in this fasion than that Google itself is.
You're worried about the impact of not doing jumbo frames, but you're ok with the huge latency added by software routing? Ok then. /backs slowly away.
If you stop to look at your entire data flow from beginning to end, very rarely is your bottleneck going to be in layer two if it's even in the network at all. Anyone who spends money on 1000BT for a home network is doing it for number fetish reasons, not for any sound technical reasons. It's no different than the idiot who overclocks their box and then spends 90% of their time browsing the web.
The software leaves out the most thought involved aspect of pool, the leave. Figuring out how to angle shots is something that you learn to intuit pretty quickly, especially if you're learning from someone with enough physical skill to put the ball where they visualize it. The part of the game that involves the most thought is deciding where you want your ball to end up once you've finished your shot. Ideally you want to set yourself up for making another shot. This often means shooting a more difficult, less obvious shot first. At the same time, you have to ask yourself, "If I don't make this shot, how can I make sure that I don't leave my opponent with an easy shot." Again, this often means taking a less obvious shot, or putting a little extra back spin on the ball so that it rolls back a few more inches. As with chess, the better you get, the more "moves" in advance you try to set yourself up for. You also start to realize that you need to understand your opponent's playing style so that you can accuratly guess at what shots they might play and try to leave them in a difficult position for those shots. Think of it as a chess board, but instead of the pieces being locked into a nice 8x8 grid, they have continuous positioning throughout the entire board. Now, it's probably possible to write a program that will take all of this into account and try to predict what shots will be good to play. I think it'll be years before any such program is more than halfway decent though, and it will certainly have to be more than just an angle visualizer.
I see alot of people listing color as an attribute they'd like to see. Here's why I think it makes more sense to go with greyscale: 1. Cheaper to make meaning more accessable devices. 2. Because it's a simpler technology than color, it's cheaper and easier to manufacture higher resolution screens. I'd rather have 640x480 greyscale than 320x240 color. 3. Longer battery life. 4. Color is actually one of the least useful information tags. (Tufte)