International Bing is complete crap, even here in the EU. It falls so much for SEO and linkfarms and spam it's not even funny. A few months back in one of the Google vs Bing discussions I posted an analysis showing just how terribly bad it was, and after some investigation by others it turned out it was a lot better from the US. It looks like Bing is only worth considering if you live on the other side of the pond.
Run PowerTOP on Linux (and use a tickless kernel, of course). There are some offenders, but most of those background services aren't using any power. As long as the processes are sleeping most of the time and don't wake up often (once every few seconds at most), they aren't going to increase your power usage.
There are a few slightly annoying ones (ntp tends to wake up once per second, and I think mysql wakes up twice per second), but most of the crap comes from poorly-written GUI apps that poll for stuff or feel the need to wake up tens or hundreds of times per second. Bad user preferences also don't help (hint: anything that's moving on the screen at any sort of framerate while the computer is otherwise idle is going to massively increase power usage over a truly quiescent CPU).
Windows 95 is way, way worse than any modern OS, even Vista and Windows 7. Back in the '95 days OSes didn't put the CPU into idle mode and certainly didn't support any power management, effectively running the CPU at full throttle 100% of the time.
Sorry, you made the erroneous assumption that low system requirements equals low power. Try again.
But the iPhone was actually new and 'magic' given the status quo (and the competition is -slowly- catching up). The iPad, though, is just a glorified large iPod Touch. We all know roughly how it works already, because we have the iPhone as a reference.
I think Apple is going to have to go for more than 'magic' this time around if they want to achieve any kind of mass market penetration sort of like the iPhone did. As it stands, I'm not sure Steve's RDF will be enough to make the masses buy one (which is definitely what Apple has stated they're hoping). Sure, it'll sell reasonably, but it may wind up as one of those gadgets that are mostly bought by gadgetophiles (particularly those which already use Macs anyway), not the general public. I could very well be wrong, but I somehow doubt the iPad will succeed at the scale that the iPhone has. Besides, everyone and their mom carries a cellphone, but netbooks/tablets aren't nearly as popular.
Yup, but that wouldn't have fixed the problem entirely. You see, there's also an Ethernet RX clock (running yet another piece of FPGA logic), and that one's determined by the outside world (whoever talks to the Ethernet jack) and it's not even constant. Can't get around that one. I was also hoping to be able to vary the core clock independently of the Ethernet clock, without being restricted to multiples of the latter.
That's not metastability, that's a floating input that doesn't have a defined level and therefore floats around various levels depending on a myriad of conditions (e.g nearby electric fields). It can cause metastability, but that's the least of your worries if your reset line is floating.
Metastability is different, it's what you get when you wire a switch (no matter what kind of cleanup hardware you place externaly - even if it's a perfect pulse) to internal FPGA logic without a couple synchronization flipflops, since you're connecting an asynchronous input to synchronous FPGA logic (the same happens when you cross clock domains without sync). If you hit the button at just the right time (such that setup/hold time specs for the flipflop are violated), the next flipflop in your internal logic will go metastable and mess up the next layer of logic. If you're lucky, the button just glitches. If you're unlucky, it can cause inconsistent internal states and even result in impossible conditions for state machines that physically lock up your FPGA algorithms.
The rule of thumb to avoid metastability is to always place two or more synchronizing flip flops between any signal and your core logic if that signal isn't synchronous to your core clock. Then if the first flipflop goes metastable, hopefully the second one will clean it up before it reaches your logic. The disadvantage is the two-cycle delay; such is the tradeoff between avoiding metastability and reacting instantly to input signals.
For example, I had this issue when I was connecting two FPGA blocks, one clocked by a free-running Ethernet clock (25Mhz) and one clocked by a separate xtal for the FPGA (50Mhz). Although the frequencies are multiples of one another, they drift constantly (separate oscillators), and since they're so close they're almost guaranteed to violate setup and hold times for a few cyles many times per second. The net result is that the main state machine in the FPGA logic consistently locked up after a while due to getting stuck in an impossible state encoding.
Considering iPhones can be disassembled (not particularly easily, but certainly not requiring cracking plastic seals apart), I have a hard time believing it's welded shut. My old 2G certainly wasn't (it was held on by annoying metal clips, but no welds). I haven't taken apart my 3G, but the guides out there don't hint at stuff being welded shut. The plastic mounts onto the metal frame/rim, it's not an all-plastic construction.
The moisture sensors are in the headphones jack (exposed to the outside) and in the dock connector (exposed to the outside). Those are probably affected by the conditions outside the phone much more than those inside the phone (which is also hardly welded shut - it's not water or airproof).
It doesn't break. The article isn't about breaking, it's about the environmental change triggering the sensors. The ramifications are that Apple may/will refuse warranty service if they have been triggered, even if the failure was not a consequence of the humidity/condensation.
So you take your phone out on a cold day, bring it back in, then three months later it dies of natural causes. Apple refuses to fix it because some condensation occurred three months prior.
Although it's rare for a device to die just from some slight condensation, it's technically outside the specification. The way the warranty is worded, though, it would appear that they can only refuse to service devices for actual damage caused by the out-of-spec environment, not just because the device ever was in that environment. However, the burden of proving that the condensation didn't cause the issue is probably on you.
That one's certainly interesting. There are a few key differences there (55 bytes versus a megabyte, purely functional code for the toner crypto vs. an actual creative game, and consumable goods vs. nonconsumable cartridges), but some of the things the judges said do make me wonder. It would certainly be interesting if this ever got tested in court. Particularly, a comment by one of the judges is pretty favorable:
I write separately to emphasize that our holding should not be limited to the narrow facts surrounding either the Toner Loading Program or the Printer Engine Program. We should make clear that in the future companies like Lexmark cannot use the DMCA in conjunction with copyright law to create monopolies of manufacturer goods for themselves[...]
Didn't the original Gameboy require the Nintendo logo to be in the cartridge? If you turned it on without a cartridge, a black rectangle would scroll up the screen instead of the logo.
Yup, though you can use a "smart" cartridge to trick the gameboy by alternately "showing" it the real logo and your own logo (enable the real logo when it checks it, enable your logo while it copies it to the screen). This also worked (in a more complex way) for the gameboy pocket, color, and the super gameboy, though I don't think anyone really discovered the latter until the ROM was dumped quite recently. But it is indeed possible to make a GB cartridge that shows your trademark while still working (though it still has to include the Nintendo one in the data, even if it never makes it to the screen).
Nope, one coax cable != one twisted pair, for the reasons you stated.
One coax cable is functionally equivalent to one twisted pair, given proper adaptation (that means a balun). My point is you do not need two coax cables to carry the signal from one differential Ethernet pair; one coax cable suffices, as long as you use a balun on each end to convert the differential signal to single-ended coax and back. The differential signal is just another transmission format, it does not encode twice the information or twice the bits, and you can convert it to a single coax and back.
Resistors don't work for bidirectional signals (which 10base2 is), because they only provide the desired effect one way (the other way, you end up with the opposite effect).
Interesting that they do it only with one coax run. I wonder if that's only for half-duplex, or they do some sort of magic to isolate the received from the transmitted signal.
I don't think 100mbps Ethernet cares about skew between pairs. There are two unidirectional twisted pairs, and clock is recovered from the incoming signal (regardless of alignment to the outgoing signal). Skew between the wires in a pair obviously matters, but that isn't an issue with coax (which is unbalanced), since one pair maps to one coax cable, not two.
One coax cable = one twisted pair, except twisted pairs are balanced and coax is unbalanced, so you need a balun to convert between them (and also adjust impedance). The theory is sound, but you need some proper background in RF to proper calculate the kind of balun you need and what the performance of the coax is going to be. Plus you need four baluns per Ethernet connection (two on each end, one for TX and one for RX). And then you also have ground loops and the like to worry about, if you're not careful (Ethernet is by design isolated, but your coax hack may not be).
RF doesn't work that way, that's not even going to remotely work - you can't magically transform the impedance of a cable just by sticking resistors on the ends. At best, if he has any chance of getting it to work, he needs baluns (transformers) to transform the 100ohm balanced pair into 75ohm unbalanced coax, but I highly doubt it's worth trying, and I wouldn't count on getting it to work at 100mbps (and forget about GigE, that needs four pairs).
Yup, dirty tricks like pretending cables are, well, hunks of copper stop working once you go beyond 1Mhz or so. Ethernet requires twisted pair wiring. Strictly speaking you might be able to use baluns of some kind to go from twisted pair to coax and back, and it might work, but it's so not worth it (plus you'd better know your RF theory) and you'd still need two coax wires per Ethernet jack (TX and RX). Just use the coax as a guide to pull brand new Cat5e or Cat6 wiring.
Slashdot Mirror
International Bing is complete crap, even here in the EU. It falls so much for SEO and linkfarms and spam it's not even funny. A few months back in one of the Google vs Bing discussions I posted an analysis showing just how terribly bad it was, and after some investigation by others it turned out it was a lot better from the US. It looks like Bing is only worth considering if you live on the other side of the pond.
Run PowerTOP on Linux (and use a tickless kernel, of course). There are some offenders, but most of those background services aren't using any power. As long as the processes are sleeping most of the time and don't wake up often (once every few seconds at most), they aren't going to increase your power usage.
There are a few slightly annoying ones (ntp tends to wake up once per second, and I think mysql wakes up twice per second), but most of the crap comes from poorly-written GUI apps that poll for stuff or feel the need to wake up tens or hundreds of times per second. Bad user preferences also don't help (hint: anything that's moving on the screen at any sort of framerate while the computer is otherwise idle is going to massively increase power usage over a truly quiescent CPU).
Windows 95 is way, way worse than any modern OS, even Vista and Windows 7. Back in the '95 days OSes didn't put the CPU into idle mode and certainly didn't support any power management, effectively running the CPU at full throttle 100% of the time.
Sorry, you made the erroneous assumption that low system requirements equals low power. Try again.
Nevermind, I confused the Vevo version with the original.
Won't work from here. At least now they're blaming it straight on Vevo, though.
But the iPhone was actually new and 'magic' given the status quo (and the competition is -slowly- catching up). The iPad, though, is just a glorified large iPod Touch. We all know roughly how it works already, because we have the iPhone as a reference.
I think Apple is going to have to go for more than 'magic' this time around if they want to achieve any kind of mass market penetration sort of like the iPhone did. As it stands, I'm not sure Steve's RDF will be enough to make the masses buy one (which is definitely what Apple has stated they're hoping). Sure, it'll sell reasonably, but it may wind up as one of those gadgets that are mostly bought by gadgetophiles (particularly those which already use Macs anyway), not the general public. I could very well be wrong, but I somehow doubt the iPad will succeed at the scale that the iPhone has. Besides, everyone and their mom carries a cellphone, but netbooks/tablets aren't nearly as popular.
Yup, but that wouldn't have fixed the problem entirely. You see, there's also an Ethernet RX clock (running yet another piece of FPGA logic), and that one's determined by the outside world (whoever talks to the Ethernet jack) and it's not even constant. Can't get around that one. I was also hoping to be able to vary the core clock independently of the Ethernet clock, without being restricted to multiples of the latter.
That's not metastability, that's a floating input that doesn't have a defined level and therefore floats around various levels depending on a myriad of conditions (e.g nearby electric fields). It can cause metastability, but that's the least of your worries if your reset line is floating.
Metastability is different, it's what you get when you wire a switch (no matter what kind of cleanup hardware you place externaly - even if it's a perfect pulse) to internal FPGA logic without a couple synchronization flipflops, since you're connecting an asynchronous input to synchronous FPGA logic (the same happens when you cross clock domains without sync). If you hit the button at just the right time (such that setup/hold time specs for the flipflop are violated), the next flipflop in your internal logic will go metastable and mess up the next layer of logic. If you're lucky, the button just glitches. If you're unlucky, it can cause inconsistent internal states and even result in impossible conditions for state machines that physically lock up your FPGA algorithms.
The rule of thumb to avoid metastability is to always place two or more synchronizing flip flops between any signal and your core logic if that signal isn't synchronous to your core clock. Then if the first flipflop goes metastable, hopefully the second one will clean it up before it reaches your logic. The disadvantage is the two-cycle delay; such is the tradeoff between avoiding metastability and reacting instantly to input signals.
For example, I had this issue when I was connecting two FPGA blocks, one clocked by a free-running Ethernet clock (25Mhz) and one clocked by a separate xtal for the FPGA (50Mhz). Although the frequencies are multiples of one another, they drift constantly (separate oscillators), and since they're so close they're almost guaranteed to violate setup and hold times for a few cyles many times per second. The net result is that the main state machine in the FPGA logic consistently locked up after a while due to getting stuck in an impossible state encoding.
Considering iPhones can be disassembled (not particularly easily, but certainly not requiring cracking plastic seals apart), I have a hard time believing it's welded shut. My old 2G certainly wasn't (it was held on by annoying metal clips, but no welds). I haven't taken apart my 3G, but the guides out there don't hint at stuff being welded shut. The plastic mounts onto the metal frame/rim, it's not an all-plastic construction.
The moisture sensors are in the headphones jack (exposed to the outside) and in the dock connector (exposed to the outside). Those are probably affected by the conditions outside the phone much more than those inside the phone (which is also hardly welded shut - it's not water or airproof).
The iPhone might be well within the specified temperature range, but not within the specified humidity range.
Emphasis mine. Turns out condensation is outside the environmental specifications.
It doesn't break. The article isn't about breaking, it's about the environmental change triggering the sensors. The ramifications are that Apple may/will refuse warranty service if they have been triggered, even if the failure was not a consequence of the humidity/condensation.
So you take your phone out on a cold day, bring it back in, then three months later it dies of natural causes. Apple refuses to fix it because some condensation occurred three months prior.
Although it's rare for a device to die just from some slight condensation, it's technically outside the specification. The way the warranty is worded, though, it would appear that they can only refuse to service devices for actual damage caused by the out-of-spec environment, not just because the device ever was in that environment. However, the burden of proving that the condensation didn't cause the issue is probably on you.
So make the lameness filter reject posts with a large proportion of non-ASCII characters.
Besides, who cares. This is why we have moderation.
That one's certainly interesting. There are a few key differences there (55 bytes versus a megabyte, purely functional code for the toner crypto vs. an actual creative game, and consumable goods vs. nonconsumable cartridges), but some of the things the judges said do make me wonder. It would certainly be interesting if this ever got tested in court. Particularly, a comment by one of the judges is pretty favorable:
Yup, though you can use a "smart" cartridge to trick the gameboy by alternately "showing" it the real logo and your own logo (enable the real logo when it checks it, enable your logo while it copies it to the screen). This also worked (in a more complex way) for the gameboy pocket, color, and the super gameboy, though I don't think anyone really discovered the latter until the ROM was dumped quite recently. But it is indeed possible to make a GB cartridge that shows your trademark while still working (though it still has to include the Nintendo one in the data, even if it never makes it to the screen).
One coax cable is functionally equivalent to one twisted pair, given proper adaptation (that means a balun). My point is you do not need two coax cables to carry the signal from one differential Ethernet pair; one coax cable suffices, as long as you use a balun on each end to convert the differential signal to single-ended coax and back. The differential signal is just another transmission format, it does not encode twice the information or twice the bits, and you can convert it to a single coax and back.
It'd be nice if they maintained a reasonably comprehensive whitelist then. It isn't hard to allow known-good pages without control characters.
Resistors don't work for bidirectional signals (which 10base2 is), because they only provide the desired effect one way (the other way, you end up with the opposite effect).
Interesting that they do it only with one coax run. I wonder if that's only for half-duplex, or they do some sort of magic to isolate the received from the transmitted signal.
I don't think 100mbps Ethernet cares about skew between pairs. There are two unidirectional twisted pairs, and clock is recovered from the incoming signal (regardless of alignment to the outgoing signal). Skew between the wires in a pair obviously matters, but that isn't an issue with coax (which is unbalanced), since one pair maps to one coax cable, not two.
One coax cable = one twisted pair, except twisted pairs are balanced and coax is unbalanced, so you need a balun to convert between them (and also adjust impedance). The theory is sound, but you need some proper background in RF to proper calculate the kind of balun you need and what the performance of the coax is going to be. Plus you need four baluns per Ethernet connection (two on each end, one for TX and one for RX). And then you also have ground loops and the like to worry about, if you're not careful (Ethernet is by design isolated, but your coax hack may not be).
RF doesn't work that way, that's not even going to remotely work - you can't magically transform the impedance of a cable just by sticking resistors on the ends. At best, if he has any chance of getting it to work, he needs baluns (transformers) to transform the 100ohm balanced pair into 75ohm unbalanced coax, but I highly doubt it's worth trying, and I wouldn't count on getting it to work at 100mbps (and forget about GigE, that needs four pairs).
Yup, dirty tricks like pretending cables are, well, hunks of copper stop working once you go beyond 1Mhz or so. Ethernet requires twisted pair wiring. Strictly speaking you might be able to use baluns of some kind to go from twisted pair to coax and back, and it might work, but it's so not worth it (plus you'd better know your RF theory) and you'd still need two coax wires per Ethernet jack (TX and RX). Just use the coax as a guide to pull brand new Cat5e or Cat6 wiring.
... but apparently Slashdot never quite became friends with Unicode, and instead decides to do weird stuff when you try.
Except 10Base-2 is 50ohm coax, while TV coax (which is probably what he has) is 75ohm. Nope, not going to work.
Damn, I wanted to use a cute unicode omega, but apparently