You've got that backwards - LEDs turn on and off very fast. Much much faster than incandescents, since those has to physically cool down and heat up with each cycle.
I'm involved fairly closely with the creators of the original exploit, so I know a bit about Wii security.
The way it's currently implemented, as soon as we start hacking the firmwares they put out, we've effectively won the battle for current consoles. Wiis contain a separate security ARM processor unofficially dubbed the "starlet". It is here that all of the interesting security takes place, and it is also responsible for most of the wii-specific hardware that the gamecube lacked. Ultimately, the consoles carry an unmodifiable boot ROM which loads an also unmodifiable boot1 bootstrap loader (unmodifiable because, although it sits in flash, it is checked against a hash stored in OTP memory). Boot1 is buggy. Boot1 loads Boot2, and we'll probably start hacking boot2 and the next step (the actual operating system and drivers that run on the starlet). This is going to be similar to the PSP scene, most likely: Nintendo will put out updates, but we'll work around them. We can also modify the existing firmware to prevent updates from happening.
However, new consoles can come with an updated boot1 (the OPT hash is programmed at the factory). Those might be impossible to hack the same way. However, the OS is buggy and other hacks can be found.
Their next system update may block this, but people just have to hold off until hacked firmwares come out. Worst case, you can always apply the hack to current consoles by directly modifying the Flash memory in the Wii.
All this only applies to the security system though, and the bug that was used for the demo at 24c3. It is rather unlikely that Nintendo will patch the Zelda bug (which is what we're using to boot current homebrew, not the meaner more powerful 24c3 bug) from firmware somehow, so there is a very good chance that we'll always have options for booting homebrew. Besides, we can find exploits in other games, easily. The 24c3 bug lets us get total system access, but even if they lock that out in newer consoles, we can still get homebrew running via game exploits.
Power increases with the square of the voltage. (-x) is a positive number. You can already make CPUs that run on negative voltages: just swap all of the transistors (roughly). Or you could just take a normal CPU and rewrite the specs to put the 0 at the positive rail, call it ground, and mention that the chip uses inverted logic I/O. Voila, a negative voltage CPU.
Your typical SRAM memory cell uses a simple double inverter loop, plus transistors to switch the rows. To change the bit, you effectively short out the inverters using higher power transistors. This saves chip area but wastes power. I guess they moved to a design that doesn't depend on this "brute force" method and instead gracefully changes the state of the cell using logic.
No, they attack Spain because Spain had troops in Iraq.
A perfectly good political candidate lost because of the attack. Now we're stuck with an idiot who can't handle our own "little" local terrorist problem, ETA. Little is in quotes because it used to be a little problem, but he's managed to do things backwards and now ETA has money and weapons again. All because of the decision by the People's Party to support the US war in Iraq.
Furthermore, converting the MP3 back to WAV and burning it does no extra conversions either. It just makes the decoding take place in the computer instead of in the player.
The torrent itself - as in the peer to peer data transmission - is done at a piece level and the stream is logically equivalent to concatenating all files and transmitting them as a whole. Obviously, this never happens at a filesystem level. However, even though the actual filesystem data is split into files, the logical stream that is what gets shared is effectively the result of the concatenation of all files (this happens in real time: when someone requests a piece, it is done by position in the "whole of the torrent" and then the client determines which file(s) it has to read to find the data). The point is that there is no internal fragmentation on the transmitted data: (essentially) the exact same number of actual data bytes will be transmitted whether you split the torrent into files or tar it up into one big file (assuming no compression for the tar and ignoring overhead for it). It's not like downloading files over HTTP where there is an overhead per file. The bittorrent wire protocol doesn't even know about the existence of multiple files.
This is why if you download a single file out of a torrent, you will often get a certain percentage of the previous and following files completed even though you never checked them for download: the edges of the pieces weren't aligned with the file boundaries. If you uncheck, say, a "downloaded from foo" txt file, more often than not you'll get it anyway (the client stores the file anyway because it needs to store that portion of the block to be able to upload it to peers, since blocks are sent as full units).
The.torrent file is a separate issue, and it can get large with large amounts of files. However, it's not like you're saving bandwidth: the file names and info will just happen to be inside the rar files (as part of the rar format), instead of the torrent file, but you'll still have to download them. Having them in the rar files is arguably a better solution in this case, since it keeps the.torrent file small and transmits the relatively bulky file list over BT, but that's a different issue.
I'm pretty sure BT does the equivalent of concatenating all files, splitting the result, and then transmitting blocks of that. The file divisions are at a higher level - the torrent itself is just a stream of blocks of bytes. No internal fragmentation.
That's not how it works. Let's say you have a pair of entangled particles. By definition, you know that one will be seen as being in state A and one in state B (even though you don't know which is which). You can ship one of them off, then later on look at your copy, and instantly know what state the one you sent off will be measured as.
The confusion arises when you realize that, by definition, the state of the particles is random. Since they are entangled, they have opposite states, but the states are unpredictable. However, once you measure your local particle to be in state "A", you force the other particle to be measured in state "B". Technically, you would "force" the other particle to the opposite state once you observe your particle, no matter how far away they are. However, since you don't get to pick what state the particle ends up being in, you can't actually send information this way. It does have some interesting applications in cryptography though.
For S2S to work, they would have to add a SRV record to aol.com so other servers can find the XMPP server responsible for @aol.com addresses (this works just like MX for e-mail, but more general). I doubt they will do that until their server is a little more mature.
In Electrical Engineering, the multiplier is commonly used to replace the decimal point in component. For example, you could call a 4.7k resistor a "4k7" resistor, and a 2.2nF capacitor might be called a "2n2" capacitor.
They're commenting on the changes to OOXML that are to be implemented. No change to OOXML would fix that problem: that it doesn't make sense when we already have ODF. Their text was introductory only, not a real "thing to fix" in OOXML, since there is nothing they could do to OOXML to fix that.
Here's to hoping that they'll still consider it an issue when voting again.
PLEASE don't recommend Sabayon for HDD installs. Sabayon is to Gentoo what Knoppix is to Debian. Sure, it works nicely as a live CD, but I hope you don't mind never upgrading if you do decide to install it. emerge -uav world on Sabayon tends to break the entire system.
That is correct; I missed that detail when I read his post and assumed that he was talking about NTSC. Indeed, NTSC is 480 out of 525, PAL is 576 out of 625.
That's not how it works. The efficiency goes up as you increase the speed for a while, and then it goes down again. Your eyes aren't magic, after you pass a certain speed it all just looks like an average to them and your efficiency goes back down.
PWM is more efficient than constant power (which is why pulsed lasers are popular), since our eyes tend to perceive a higher brightness with PWM for the same amount of light, and scanning is similar to this, but this only works to a certain point. In a CRT, the phosphor on the screen does the hard work of keeping scanned pixels emitting light after they're hit. CRTs are also smaller than a projected screen, and involve totally different technology with totally different power limits. High-powered laser diodes are expensive and very dangerous in case of a malfunction.
I'm not sure where you got the associatuon that laser means bright, but that's definitely not the case. Lasers LOOK bright because all of the energy is concentrated on a point: if you point the dot at a wall, it will be about as bright as any LED placed at that spot on the wall. If you point it at your eye, it's like shoving an LED up your cornea, with the added fact that it tends to focus to one point in your retina. Lasers concentrate their light in a very different way from a regular bulb, so they may look "bright", but in terms of light output they really aren't. When you scan an image on a wall and spread that tiny dot into an area of several square feet, it ceases to be "bright".
We can already address 16 Exabytes of memory with 64-bit pointers. With 8388608-bit pointers, we would be able to access [insert over two million digits here] Yottabytes of memory. At that stage I don't think 1 meg pointers are as much of an issue. The theoretical maximum information capacity of the Universe might be, though. You know, like how you'd need [insert over two million digits here, about 80 less than before] universes to hold that much information.
Slashdot Mirror
You've got that backwards - LEDs turn on and off very fast. Much much faster than incandescents, since those has to physically cool down and heat up with each cycle.
I'm involved fairly closely with the creators of the original exploit, so I know a bit about Wii security.
The way it's currently implemented, as soon as we start hacking the firmwares they put out, we've effectively won the battle for current consoles. Wiis contain a separate security ARM processor unofficially dubbed the "starlet". It is here that all of the interesting security takes place, and it is also responsible for most of the wii-specific hardware that the gamecube lacked. Ultimately, the consoles carry an unmodifiable boot ROM which loads an also unmodifiable boot1 bootstrap loader (unmodifiable because, although it sits in flash, it is checked against a hash stored in OTP memory). Boot1 is buggy. Boot1 loads Boot2, and we'll probably start hacking boot2 and the next step (the actual operating system and drivers that run on the starlet). This is going to be similar to the PSP scene, most likely: Nintendo will put out updates, but we'll work around them. We can also modify the existing firmware to prevent updates from happening.
However, new consoles can come with an updated boot1 (the OPT hash is programmed at the factory). Those might be impossible to hack the same way. However, the OS is buggy and other hacks can be found.
Their next system update may block this, but people just have to hold off until hacked firmwares come out. Worst case, you can always apply the hack to current consoles by directly modifying the Flash memory in the Wii.
All this only applies to the security system though, and the bug that was used for the demo at 24c3. It is rather unlikely that Nintendo will patch the Zelda bug (which is what we're using to boot current homebrew, not the meaner more powerful 24c3 bug) from firmware somehow, so there is a very good chance that we'll always have options for booting homebrew. Besides, we can find exploits in other games, easily. The 24c3 bug lets us get total system access, but even if they lock that out in newer consoles, we can still get homebrew running via game exploits.
Power increases with the square of the voltage. (-x) is a positive number. You can already make CPUs that run on negative voltages: just swap all of the transistors (roughly). Or you could just take a normal CPU and rewrite the specs to put the 0 at the positive rail, call it ground, and mention that the chip uses inverted logic I/O. Voila, a negative voltage CPU.
Your typical SRAM memory cell uses a simple double inverter loop, plus transistors to switch the rows. To change the bit, you effectively short out the inverters using higher power transistors. This saves chip area but wastes power. I guess they moved to a design that doesn't depend on this "brute force" method and instead gracefully changes the state of the cell using logic.
No, they attack Spain because Spain had troops in Iraq.
A perfectly good political candidate lost because of the attack. Now we're stuck with an idiot who can't handle our own "little" local terrorist problem, ETA. Little is in quotes because it used to be a little problem, but he's managed to do things backwards and now ETA has money and weapons again. All because of the decision by the People's Party to support the US war in Iraq.
Furthermore, converting the MP3 back to WAV and burning it does no extra conversions either. It just makes the decoding take place in the computer instead of in the player.
Also, Heaven Seven works just fine under Wine. Fully raytraced graphics with no GPU use!
Bzzt. That statement makes no sense. Go read up on kWh vs kW and try again.
The torrent itself - as in the peer to peer data transmission - is done at a piece level and the stream is logically equivalent to concatenating all files and transmitting them as a whole. Obviously, this never happens at a filesystem level. However, even though the actual filesystem data is split into files, the logical stream that is what gets shared is effectively the result of the concatenation of all files (this happens in real time: when someone requests a piece, it is done by position in the "whole of the torrent" and then the client determines which file(s) it has to read to find the data). The point is that there is no internal fragmentation on the transmitted data: (essentially) the exact same number of actual data bytes will be transmitted whether you split the torrent into files or tar it up into one big file (assuming no compression for the tar and ignoring overhead for it). It's not like downloading files over HTTP where there is an overhead per file. The bittorrent wire protocol doesn't even know about the existence of multiple files.
.torrent file is a separate issue, and it can get large with large amounts of files. However, it's not like you're saving bandwidth: the file names and info will just happen to be inside the rar files (as part of the rar format), instead of the torrent file, but you'll still have to download them. Having them in the rar files is arguably a better solution in this case, since it keeps the .torrent file small and transmits the relatively bulky file list over BT, but that's a different issue.
This is why if you download a single file out of a torrent, you will often get a certain percentage of the previous and following files completed even though you never checked them for download: the edges of the pieces weren't aligned with the file boundaries. If you uncheck, say, a "downloaded from foo" txt file, more often than not you'll get it anyway (the client stores the file anyway because it needs to store that portion of the block to be able to upload it to peers, since blocks are sent as full units).
The
I'm pretty sure BT does the equivalent of concatenating all files, splitting the result, and then transmitting blocks of that. The file divisions are at a higher level - the torrent itself is just a stream of blocks of bytes. No internal fragmentation.
That's not how it works. Let's say you have a pair of entangled particles. By definition, you know that one will be seen as being in state A and one in state B (even though you don't know which is which). You can ship one of them off, then later on look at your copy, and instantly know what state the one you sent off will be measured as.
The confusion arises when you realize that, by definition, the state of the particles is random. Since they are entangled, they have opposite states, but the states are unpredictable. However, once you measure your local particle to be in state "A", you force the other particle to be measured in state "B". Technically, you would "force" the other particle to the opposite state once you observe your particle, no matter how far away they are. However, since you don't get to pick what state the particle ends up being in, you can't actually send information this way. It does have some interesting applications in cryptography though.
For S2S to work, they would have to add a SRV record to aol.com so other servers can find the XMPP server responsible for @aol.com addresses (this works just like MX for e-mail, but more general). I doubt they will do that until their server is a little more mature.
Try it:
$ dig SRV _xmpp-server._tcp.aol.com
No, the black is the 10^n. Though you could add another black for tolerance, although I don't think there is a standard color for "zero tolerance".
Don't you mean Red, Black, Orange, Gray, Black? :)
In Electrical Engineering, the multiplier is commonly used to replace the decimal point in component. For example, you could call a 4.7k resistor a "4k7" resistor, and a 2.2nF capacitor might be called a "2n2" capacitor.
That would make it Y2k038.
They're commenting on the changes to OOXML that are to be implemented. No change to OOXML would fix that problem: that it doesn't make sense when we already have ODF. Their text was introductory only, not a real "thing to fix" in OOXML, since there is nothing they could do to OOXML to fix that.
Here's to hoping that they'll still consider it an issue when voting again.
So it's a hybrid mini TOSLINK + audio jack. Those things exist.
PLEASE don't recommend Sabayon for HDD installs. Sabayon is to Gentoo what Knoppix is to Debian. Sure, it works nicely as a live CD, but I hope you don't mind never upgrading if you do decide to install it. emerge -uav world on Sabayon tends to break the entire system.
That is correct; I missed that detail when I read his post and assumed that he was talking about NTSC. Indeed, NTSC is 480 out of 525, PAL is 576 out of 625.
Of which about 480 are actually visible, and the rest are blanking and retracing.
That's not how it works. The efficiency goes up as you increase the speed for a while, and then it goes down again. Your eyes aren't magic, after you pass a certain speed it all just looks like an average to them and your efficiency goes back down.
PWM is more efficient than constant power (which is why pulsed lasers are popular), since our eyes tend to perceive a higher brightness with PWM for the same amount of light, and scanning is similar to this, but this only works to a certain point. In a CRT, the phosphor on the screen does the hard work of keeping scanned pixels emitting light after they're hit. CRTs are also smaller than a projected screen, and involve totally different technology with totally different power limits. High-powered laser diodes are expensive and very dangerous in case of a malfunction.
I'm not sure where you got the associatuon that laser means bright, but that's definitely not the case. Lasers LOOK bright because all of the energy is concentrated on a point: if you point the dot at a wall, it will be about as bright as any LED placed at that spot on the wall. If you point it at your eye, it's like shoving an LED up your cornea, with the added fact that it tends to focus to one point in your retina. Lasers concentrate their light in a very different way from a regular bulb, so they may look "bright", but in terms of light output they really aren't. When you scan an image on a wall and spread that tiny dot into an area of several square feet, it ceases to be "bright".
You still get full specs from many companies. Free samples are still around. Though it sadly doesn't seem to be popular with PC components.
We can already address 16 Exabytes of memory with 64-bit pointers. With 8388608-bit pointers, we would be able to access [insert over two million digits here] Yottabytes of memory. At that stage I don't think 1 meg pointers are as much of an issue. The theoretical maximum information capacity of the Universe might be, though. You know, like how you'd need [insert over two million digits here, about 80 less than before] universes to hold that much information.
Exponents grow fast