I disagree. An open network is not an invitation to join it and use it (associate), but an unencrypted network is an invitation for anyone to sniff your traffic passively. This would be like satellite TV providers sending their feeds unencrypted and then complaining that non-subscribers are watching their channels. What do you expect if you're broadcasting your data on the air in the clear into public space?
Granted, sniffing everything is not nice of Google (and probably an unintended screwup), but you really shouldn't expect that people won't do it.
AP information is packet data (they're called beacon frames). Looking for beacon frames is a lot more effective at finding APs on the move than using whatever built-in scan feature your card drivers have. They probably had a SNAFU and forgot to filter out data packets in their capturing setup, instead storing everything that hits the antenna (or some engineer didn't realize it would be an issue).
It's not a man-in-the-middle attack. They were probably just capturing all WiFi traffic in order to search for hotspots, but forgot to filter it so only beacon frames were stored. A proper set of cards sniffing are much more effective at detecting faint hotspots than just mashing on the "scan" button on one card, which probably discards stray beacons.
It's your fault if you're broadcasting your data all over the airwaves unencrypted where anyone with a passive receiving antenna can pick it up.
As I understand it, there's a trade-off between uncertainty and speed in quantum computing. You can get results faster, but you'll have a higher probability that your machine returns 2+2=5.
The same goes for conventional computing. No computer is error-free, and bit errors can and do happen. There are unsolved/unsolvable problems in electronics like metastability that always come with a P-value which you can make as large as you want by trading off speed.
Conventional computers are tuned such that the error rates are small enough that people can live with them (e.g. once a few months for crappy consumer hardware, or hopefully once every decade or more for proper servers). The question is whether quantum computing will still be faster after being tuned to similar error rates. There are also tricks you can use, such as ECCs and other types of parity for conventional computers. For example, on quantum computing you can have several computers running the same problem and then require that they agree on the result.
You're definitely confused about this (see my earlier reply to you). The backlight on an LCD panel runs at a rate in the kHz range and has nothing to do with the refresh rate. For all intents and purposes it's a constant source of light.
Nope. The "fluorescent" light in the back is a cold cathode fluorescent lamp driven by an inverter running anywhere from 20kHz to 50kHz. Beat effects with the backlight are not an issue (except on badly designed monitors that PWM too slowly to control brightness).
The dual-layer drive issue was widely publicized and affected lots of Wii owners (Nintendo supposedly fixed those Wiis for free). The pixel snow issue is considerable too.
They are nowhere near the 360 issues, of course. The RROD issue was a massive problem for MS, and early 360s were definitely crap as far as hardware quality. However, I'd say the Wii and the PS3 are on the same league as far as hardware issues. In other words, about average for a game console. Other OS doesn't count as that's not a hardware issue.
Oh, and there may be a new Wii hardware issue in the making. On recent consoles, we've detected certain memory corruption glitches in homebrew under certain circumstances. We've so far been unable to isolate the cause, and so far tests point at the issue existing while Nintendo's code runs too (it just happens not to cause issues for e.g. the system menu). We've all but confirmed that the hardware is definitely glitching, so the only thing that can mitigate it is if there's a memory controller setting that can fix the issue. This may be related to the recent die unification of Hollywood (Vegas and Napa are now one die, and Napa holds the memory in question).
Since this is a sporadic failure and doesn't happen with some workloads, it's quite possible it's been slipping through console manufacturing testing.
In other words, if this problem is anywhere near common in new consoles and it simply isn't showing up with some typical games, Nintendo might have a real problem on their hands when a game comes out that totally bombs on these consoles. I'm not going to say it will definitely happen, as we're still speculating, but it might. Keep an eye out for it.
Unlike the other consoles they don't RROD or have a "Nintendo" timer so the need for existing customers to replace their Wii is minimal.
All consoles have their problems (though the 360 admittedly had more) and the Wii is no exception. You might want to look up WC24 mode overheating issues (the Hollywood's power management is horrid and their software doesn't help by keeping the ARM CPU usage at 100% while the console is "off"), graphical corruption issues which may or may not be caused by said overheating (search for "pixel snow" or something like that), and DVD drive issues, both mechanical and related to disc read performance (for some reason just about all console disc drives suck, ask Nintendo about their issues with dual-layer games). Not to mention their latest update bricked a bunch of consoles because their bootloader update code is broken (they blame it on homebrew, but we know for a fact that's utter FUD).
Actually, mediocre decoders (ffmpeg) on mediocre hardware (some Core 2 Duo laptop, for example) will not play high-bitrate/high-complexity scenes properly at all. 1080p H.264 does push today's CPUs quite a bit. This is why you want GPU acceleration. My one-year-old desktop replacement laptop lags through some 1080p streams using just the CPU, but let the GPU do the work through VDPAU and it just breezes through everything. Heck, I have an underpowered HTPC that can play everything without a hitch using one of Nvidia's cheapest cards (a 8400GS).
The IPv6 one is dead now too. A +trace run ends here:
rs.dns-oarc.net. 3600 IN NS ns00.rs.dns-oarc.net. ns00.rs.dns-oarc.net. 3600 IN A 149.20.58.133 ns00.rs.dns-oarc.net. 3600 IN AAAA 2001:4f8:3:2bc:2::133;; Received 96 bytes from 2001:500:2e::1#53(sns-pb.isc.org) in 128 ms
Both the v4 and v6 IP for ns00.rs.dns-oarc.net. are dead, so the whole thing just dies after that.
Is the ability to run Linux the main reason why the PS3 haven't been broken for so long, as people wanting to play with homebrew could be satisfied with the Linux ability?
If so, won't that mean that with Other OS gone, that enthusiasts will do their very best to crack that machine open any which way they can to enable homebrew, this time with the goal being full access?
Yes, and piracy advocates will come out with a piracy tool shortly after it is completely broken.
I'm not saying that there's inherent value in doing so, just that it's the only sane way of encrypting things like people's names in a database. The problem with record-level encryption is that it totally breaks thing such as indexing. You do not have this issue with filesystem/block-level encryption.
Filesystem encryption involves just a constant overhead for filesystem access (this is pretty obvious when you think about it). In other words, it just increases the CPU usage of IO operations. Sure, it will decrease database performance, but by a constant factor (as opposed to the ridiculous performance problems brought by e.g. being unable to properly index an encrypted field). I don't have hard numbers around, but I would expect the impact of a properly designed implementation using modern server CPUs (i.e. those with hardware AES acceleration) would be fairly small. Plus the encryption would likely operate at a level below the filesystem RAM cache, so cached accesses would not be affected.
There is simply no way with our current resources we could encrypt data in the individual fields in databases and maintain any level of performance with indexes, primary keys, constraints, etc.
You're implying that the only way to do this is encryption of the database contents at the record level. There's an easier way with a constant smaller impact on database performance: just encrypt the filesystem where the database lives.
It doesn't matter if the internet connection is still IPv4. As long as you have IPv6, and you can talk to the IPv6 Internet, nobody cares what kind of tunneling you're doing along the way. It isn't really any different from using PPPoE as a tunnel for IPv4. You'll still be able to talk to IPv6-only servers, which is what matters.
It would be perfectly fine for existing IPv4 users to use tunneling to get to IPv6, as this doesn't consume any extra IPv4 addresses. Once servers and clients are firmly in IPv6-capable land we can start pestering the ISP holdouts to finally offer native IPv6 the entire way.
You clearly haven't bothered to look at any die photos. Check out the Atom. Less than half of the main area is L2. You can see the smaller L1 blocks and other caches, but the vast majority of the rest is logic. That's at least 40-50% logic, more if you count the FSB IO areas. larger CPUs aren't much different.
Then you're also missing the fact that the caches themselves are more complicated (and larger per size) on x86, due to the aforementioned extra snooping required.
I love how everyone jumped so quickly on the instruction decoding bandwagon. Of course instruction decoding is cheap these days, even for x86. The problem isn't decoding, it's the huge amount of dirty things that instructions can potentially do after being decoded. Things that go against modern high-performance CPU design principles.
The key is modern RISC, not RISC. x86 is horribly inefficient. I'm not talking about the instruction decoder, I'm talking about the instruction semantics. x86 was never designed for today's high-performance CPUs, and the result is that the instruction set basically allows the programmer to do anything they want, even if it goes against modern CPU design optimizations. This forces the CPU to devote a large amount of die area to workaround logic that detects the thousands of possible dirty tricks that a programmer might use which are allowed by the ISA. For example, every modern RISC requires that the programmer issue cache flush instructions when modifying executable code. This is common sense. x86 doesn't, which means there needs to be a large blob of logic checking for whether the data you just touched happens to be inside your code cache too. The fact that on x86 you can e.g. use one instruction to modify the next instruction in the pipeline is just so ridiculously horribly wrong it's not even funny. There are similar screw-ups related to e.g. the page tables. I can't even begin to imagine the pains that x86 CPU engineers have to go through.
You can make an x86 chip reasonably small and very slow, or very large and very fast. x86 doesn't let you have it both ways to any reasonable degree.
Um, no. Cache is very important, especially with 64-bit code. In fact, x86 is a terribly die-area-inefficient architecture; we'd be a lot better off with a modern RISC, opening up space for more cache.
Of course, the OMAP is more of a mobile kind of part. I wasn't suggesting that particular board. I've heard good things about Marvell's implementation of the ARM architecture.
What I want to see are "performance" offerings with proper interconnects (especially Gigabit Ethernet and SATA) and multiple Cortex-A9 cores. That'd be great for all kinds of server applications, datacenter or home alike. The thing with Marvell's fast chips is that they seem to implement just the old ARMv5 instruction set, which is no fun. They also have ARMv7 versions, but those are for mobile applications mostly (e.g. single core).
Not netbooks. If anything, it'll have to be an ARM single board computer, something like this. I have one of those; they're awesome in quite a few ways.
I'm not sure if there's a way of explicitly testing all of L2 on an x86 chip (it might be vendor-specific, if possible). However, anything that exercises large amounts of memory in certain patterns is liable to test CPU caches to a reasonable degree. I believe memtest86 does enable cache for some of its tests, so it might be a good idea if all you're worried about is L2.
L2 failure is one of those things that should eventually cause obvious instability with many tests and workloads, although the degree of instability can probably vary quite widely.
Some CPUs (e.g. PowerPC) have better specified cache behavior and document specific testing methods.
You don't think the diagnostic puts any sort of stress test on anything other than the memory?
The diagnostic doesn't put any sort of uniform stress on anything other than memory. Even wondered why it does a ton of passes on a ton of different modes with a ton of patterns on RAM? That's testing for as many possible RAM failure modes as it can. No attempt is made to test the CPU. You're stressing some parts of the CPU, but you're neglecting the vast majority (e.g. floating point and SIMD).
Really? You don't think a test that is notorious for pushing the CPU to high load and high temperatures is a diagnostic for anything?
If anything, it might be a diagnostic for your cooling system. Sure, it helps ensure that nothing is blatantly wrong with the CPU, and it does a better job at testing the CPU than memtest86, but it isn't even remotely a comprehensive test of CPU functionality.
This isn't overclocking we're talking about here. When you overclock, you stress the entire CPU more as a whole. When tests like memtest86 and Prime95 start failing, you know that your CPU is definitely unstable. Then you back off and you hope the untested parts of the CPU will do OK with whatever safety margin you gave it.
When you enable a core, it might have some broken parts, or it might not. Those parts can be flaky, or they can be borked, period. Unless you run software that has a chance of testing those parts, you will never find out. E.g. if the hardware for a specific floating point instruction is borked, memtest86 will be useless, and Prime95 will be useless unless it happens to use that specific instruction. If the transistor in charge of forbidding kernel memory access from user mode is borked, you won't find out until an unstable application takes down your entire system by scribbling all over the kernel.
Unless you are suggesting that there are absolutely no diagnostic tests that are available to consumers to test stuff like this
I am absolutely sure there is no test that will match what Intel and AMD do - because they know exactly how their CPUs work and what to test for. I do know that you can do a whole lot better than memtest86 or Prime95. I haven't checked whether someone actually has attempted to produce a comprehensive architecture test of this sort.
Your mistake is attempting to extrapolate from tools used for testing overclocking (which typically results in overall instability) as a means to test for disabled and possibly subtly broken hardware. Any failures from a defective core are likely to show up only with workloads that exercise the defective bits, and the rest of the CPU will work fine.
memtest86 is a diagnostic test for RAM. Prime95 isn't a diagnostic test for anything. Both are reasonable CPU burn-in tests, but they don't test all (or even most) features of the CPU. I'm not even aware of memtest86 using more than one core. Sure, if you run them for a while you can be reasonably sure that the critical parts of a core are working properly, but there's a very real possibility that its problem is a more obscure one that only shows under certain circumstances. For example, some specific app might corrupt data, while everything else works fine.
In order to properly test a CPU core, you at least need a full suite of tests for that architecture, including OS/kernel-level tests, and even those are likely to miss things particular to the specific manufacturer's implementation of the architecture.
Slashdot Mirror
I disagree. An open network is not an invitation to join it and use it (associate), but an unencrypted network is an invitation for anyone to sniff your traffic passively. This would be like satellite TV providers sending their feeds unencrypted and then complaining that non-subscribers are watching their channels. What do you expect if you're broadcasting your data on the air in the clear into public space?
Granted, sniffing everything is not nice of Google (and probably an unintended screwup), but you really shouldn't expect that people won't do it.
AP information is packet data (they're called beacon frames). Looking for beacon frames is a lot more effective at finding APs on the move than using whatever built-in scan feature your card drivers have. They probably had a SNAFU and forgot to filter out data packets in their capturing setup, instead storing everything that hits the antenna (or some engineer didn't realize it would be an issue).
It's not a man-in-the-middle attack. They were probably just capturing all WiFi traffic in order to search for hotspots, but forgot to filter it so only beacon frames were stored. A proper set of cards sniffing are much more effective at detecting faint hotspots than just mashing on the "scan" button on one card, which probably discards stray beacons.
It's your fault if you're broadcasting your data all over the airwaves unencrypted where anyone with a passive receiving antenna can pick it up.
Does not assemble. Try this:
get_magic:
ADR r0, magic
BX lr
magic: .ascii "Magical\0"
The same goes for conventional computing. No computer is error-free, and bit errors can and do happen. There are unsolved/unsolvable problems in electronics like metastability that always come with a P-value which you can make as large as you want by trading off speed.
Conventional computers are tuned such that the error rates are small enough that people can live with them (e.g. once a few months for crappy consumer hardware, or hopefully once every decade or more for proper servers). The question is whether quantum computing will still be faster after being tuned to similar error rates. There are also tricks you can use, such as ECCs and other types of parity for conventional computers. For example, on quantum computing you can have several computers running the same problem and then require that they agree on the result.
You're definitely confused about this (see my earlier reply to you). The backlight on an LCD panel runs at a rate in the kHz range and has nothing to do with the refresh rate. For all intents and purposes it's a constant source of light.
Nope. The "fluorescent" light in the back is a cold cathode fluorescent lamp driven by an inverter running anywhere from 20kHz to 50kHz. Beat effects with the backlight are not an issue (except on badly designed monitors that PWM too slowly to control brightness).
The dual-layer drive issue was widely publicized and affected lots of Wii owners (Nintendo supposedly fixed those Wiis for free). The pixel snow issue is considerable too.
They are nowhere near the 360 issues, of course. The RROD issue was a massive problem for MS, and early 360s were definitely crap as far as hardware quality. However, I'd say the Wii and the PS3 are on the same league as far as hardware issues. In other words, about average for a game console. Other OS doesn't count as that's not a hardware issue.
Oh, and there may be a new Wii hardware issue in the making. On recent consoles, we've detected certain memory corruption glitches in homebrew under certain circumstances. We've so far been unable to isolate the cause, and so far tests point at the issue existing while Nintendo's code runs too (it just happens not to cause issues for e.g. the system menu). We've all but confirmed that the hardware is definitely glitching, so the only thing that can mitigate it is if there's a memory controller setting that can fix the issue. This may be related to the recent die unification of Hollywood (Vegas and Napa are now one die, and Napa holds the memory in question).
Since this is a sporadic failure and doesn't happen with some workloads, it's quite possible it's been slipping through console manufacturing testing.
In other words, if this problem is anywhere near common in new consoles and it simply isn't showing up with some typical games, Nintendo might have a real problem on their hands when a game comes out that totally bombs on these consoles. I'm not going to say it will definitely happen, as we're still speculating, but it might. Keep an eye out for it.
All consoles have their problems (though the 360 admittedly had more) and the Wii is no exception. You might want to look up WC24 mode overheating issues (the Hollywood's power management is horrid and their software doesn't help by keeping the ARM CPU usage at 100% while the console is "off"), graphical corruption issues which may or may not be caused by said overheating (search for "pixel snow" or something like that), and DVD drive issues, both mechanical and related to disc read performance (for some reason just about all console disc drives suck, ask Nintendo about their issues with dual-layer games). Not to mention their latest update bricked a bunch of consoles because their bootloader update code is broken (they blame it on homebrew, but we know for a fact that's utter FUD).
Actually, mediocre decoders (ffmpeg) on mediocre hardware (some Core 2 Duo laptop, for example) will not play high-bitrate/high-complexity scenes properly at all. 1080p H.264 does push today's CPUs quite a bit. This is why you want GPU acceleration. My one-year-old desktop replacement laptop lags through some 1080p streams using just the CPU, but let the GPU do the work through VDPAU and it just breezes through everything. Heck, I have an underpowered HTPC that can play everything without a hitch using one of Nvidia's cheapest cards (a 8400GS).
The IPv6 one is dead now too. A +trace run ends here:
Both the v4 and v6 IP for ns00.rs.dns-oarc.net. are dead, so the whole thing just dies after that.
Yes (slightly outdated).
Yes, and piracy advocates will come out with a piracy tool shortly after it is completely broken.
Yes, Sony is shooting itself in the foot bigtime.
I'm not saying that there's inherent value in doing so, just that it's the only sane way of encrypting things like people's names in a database. The problem with record-level encryption is that it totally breaks thing such as indexing. You do not have this issue with filesystem/block-level encryption.
Filesystem encryption involves just a constant overhead for filesystem access (this is pretty obvious when you think about it). In other words, it just increases the CPU usage of IO operations. Sure, it will decrease database performance, but by a constant factor (as opposed to the ridiculous performance problems brought by e.g. being unable to properly index an encrypted field). I don't have hard numbers around, but I would expect the impact of a properly designed implementation using modern server CPUs (i.e. those with hardware AES acceleration) would be fairly small. Plus the encryption would likely operate at a level below the filesystem RAM cache, so cached accesses would not be affected.
You're implying that the only way to do this is encryption of the database contents at the record level. There's an easier way with a constant smaller impact on database performance: just encrypt the filesystem where the database lives.
It doesn't matter if the internet connection is still IPv4. As long as you have IPv6, and you can talk to the IPv6 Internet, nobody cares what kind of tunneling you're doing along the way. It isn't really any different from using PPPoE as a tunnel for IPv4. You'll still be able to talk to IPv6-only servers, which is what matters.
It would be perfectly fine for existing IPv4 users to use tunneling to get to IPv6, as this doesn't consume any extra IPv4 addresses. Once servers and clients are firmly in IPv6-capable land we can start pestering the ISP holdouts to finally offer native IPv6 the entire way.
You clearly haven't bothered to look at any die photos. Check out the Atom. Less than half of the main area is L2. You can see the smaller L1 blocks and other caches, but the vast majority of the rest is logic. That's at least 40-50% logic, more if you count the FSB IO areas. larger CPUs aren't much different.
Then you're also missing the fact that the caches themselves are more complicated (and larger per size) on x86, due to the aforementioned extra snooping required.
I love how everyone jumped so quickly on the instruction decoding bandwagon. Of course instruction decoding is cheap these days, even for x86. The problem isn't decoding, it's the huge amount of dirty things that instructions can potentially do after being decoded. Things that go against modern high-performance CPU design principles.
The key is modern RISC, not RISC. x86 is horribly inefficient. I'm not talking about the instruction decoder, I'm talking about the instruction semantics. x86 was never designed for today's high-performance CPUs, and the result is that the instruction set basically allows the programmer to do anything they want, even if it goes against modern CPU design optimizations. This forces the CPU to devote a large amount of die area to workaround logic that detects the thousands of possible dirty tricks that a programmer might use which are allowed by the ISA. For example, every modern RISC requires that the programmer issue cache flush instructions when modifying executable code. This is common sense. x86 doesn't, which means there needs to be a large blob of logic checking for whether the data you just touched happens to be inside your code cache too. The fact that on x86 you can e.g. use one instruction to modify the next instruction in the pipeline is just so ridiculously horribly wrong it's not even funny. There are similar screw-ups related to e.g. the page tables. I can't even begin to imagine the pains that x86 CPU engineers have to go through.
You can make an x86 chip reasonably small and very slow, or very large and very fast. x86 doesn't let you have it both ways to any reasonable degree.
Um, no. Cache is very important, especially with 64-bit code. In fact, x86 is a terribly die-area-inefficient architecture; we'd be a lot better off with a modern RISC, opening up space for more cache.
Apparently all of those videos on that page have been pulled. Including the pure white noise one. I wonder how they justify that one.
Of course, the OMAP is more of a mobile kind of part. I wasn't suggesting that particular board. I've heard good things about Marvell's implementation of the ARM architecture.
What I want to see are "performance" offerings with proper interconnects (especially Gigabit Ethernet and SATA) and multiple Cortex-A9 cores. That'd be great for all kinds of server applications, datacenter or home alike. The thing with Marvell's fast chips is that they seem to implement just the old ARMv5 instruction set, which is no fun. They also have ARMv7 versions, but those are for mobile applications mostly (e.g. single core).
Not netbooks. If anything, it'll have to be an ARM single board computer, something like this. I have one of those; they're awesome in quite a few ways.
I'm not sure if there's a way of explicitly testing all of L2 on an x86 chip (it might be vendor-specific, if possible). However, anything that exercises large amounts of memory in certain patterns is liable to test CPU caches to a reasonable degree. I believe memtest86 does enable cache for some of its tests, so it might be a good idea if all you're worried about is L2.
L2 failure is one of those things that should eventually cause obvious instability with many tests and workloads, although the degree of instability can probably vary quite widely.
Some CPUs (e.g. PowerPC) have better specified cache behavior and document specific testing methods.
The diagnostic doesn't put any sort of uniform stress on anything other than memory. Even wondered why it does a ton of passes on a ton of different modes with a ton of patterns on RAM? That's testing for as many possible RAM failure modes as it can. No attempt is made to test the CPU. You're stressing some parts of the CPU, but you're neglecting the vast majority (e.g. floating point and SIMD).
If anything, it might be a diagnostic for your cooling system. Sure, it helps ensure that nothing is blatantly wrong with the CPU, and it does a better job at testing the CPU than memtest86, but it isn't even remotely a comprehensive test of CPU functionality.
This isn't overclocking we're talking about here. When you overclock, you stress the entire CPU more as a whole. When tests like memtest86 and Prime95 start failing, you know that your CPU is definitely unstable. Then you back off and you hope the untested parts of the CPU will do OK with whatever safety margin you gave it.
When you enable a core, it might have some broken parts, or it might not. Those parts can be flaky, or they can be borked, period. Unless you run software that has a chance of testing those parts, you will never find out. E.g. if the hardware for a specific floating point instruction is borked, memtest86 will be useless, and Prime95 will be useless unless it happens to use that specific instruction. If the transistor in charge of forbidding kernel memory access from user mode is borked, you won't find out until an unstable application takes down your entire system by scribbling all over the kernel.
I am absolutely sure there is no test that will match what Intel and AMD do - because they know exactly how their CPUs work and what to test for. I do know that you can do a whole lot better than memtest86 or Prime95. I haven't checked whether someone actually has attempted to produce a comprehensive architecture test of this sort.
Your mistake is attempting to extrapolate from tools used for testing overclocking (which typically results in overall instability) as a means to test for disabled and possibly subtly broken hardware. Any failures from a defective core are likely to show up only with workloads that exercise the defective bits, and the rest of the CPU will work fine.
memtest86 is a diagnostic test for RAM. Prime95 isn't a diagnostic test for anything. Both are reasonable CPU burn-in tests, but they don't test all (or even most) features of the CPU. I'm not even aware of memtest86 using more than one core. Sure, if you run them for a while you can be reasonably sure that the critical parts of a core are working properly, but there's a very real possibility that its problem is a more obscure one that only shows under certain circumstances. For example, some specific app might corrupt data, while everything else works fine.
In order to properly test a CPU core, you at least need a full suite of tests for that architecture, including OS/kernel-level tests, and even those are likely to miss things particular to the specific manufacturer's implementation of the architecture.