The reason is simply that in the past there have been times when a storm would kill cell phone service, even knock out the power, but phone-over-copper was still up.
That's funny. Around here thunderstorms tend to knock out the phone and DSL, but cells continue to work. Even more WTF is that the DSL often comes back on hours before the dialtone, even though they come from the same remote box. I guess the DSLAM portion is more reliable than the phone portion.
For what it's worth, nVidia cards can do this just fine and have been able to for a long time. See the "full GPU scaling" option in nvidia-settings. My HTPC's nVidia card also shows the BIOS on my HDTV at 1080p link resolution (while pretending to be VGA to the software).
There's already a standard for file-based accesses to USB devices. It's called PTP and it's what many cameras use. It shouldn't be too hard to adapt for more general FS access.
You're a victim of the marketing. There's a difference between "how fast a pixel can flip" and "how long it takes to START flipping after the computer tells it to". 2ms response time means no ghosting. It doesn't mean the LCD processing won't take over 50ms to actually propagate the change to the screen. In fact, very often, these low pixel response times are achieved using driving tricks and heavy preprocessing, which ADD lag by buffering more input frames.
Long ago, the complaint was ghosting and blurriness in high motion environments, but that's long since gone. The problem now are some LCDs which buffer a bunch of frames in order to perform questionable advanced processing, and which adds a ton of lag to the actual picture. Manufacturers don't quote numbers for that, unfortunately.
It's a stupid playlist. Try opening the file as text, copying the first line, and playing it with mplayer: mplayer rtsp://157.150.195.57:554/ondemand/specialevents/2009/se090317pm.rm?cloakport=80,554,7070
The quality is substantially inferior to YouTube though.
And they heavily obfuscate the software that deals with that signature, both on the host and the device, to prevent any reverse engineering.
On the iPhone 2.x firmware you can just turn the check off if it's jailbroken, but I imagine you're pretty screwed when it comes to a closed device like the iPod.
I believe that is the case for NTFS, not FAT32. On FAT (all variants), the inode information is stored together with the short filename. You can use any short filename (it doesn't have to be an abbreviation of the LFN), and some drivers might even let you null it out if they just use the long filename (though I'm pretty sure that's outside the spec), but there's no way around the fact that the SFN field is there and that the LFNs are still the same patented hack on top of them.
Sure, but the same applies to FAT16. I just wanted to point out that FAT12 isn't inferior to FAT16 in this regard, and, in fact, is still widely used on small devices. VFAT was developed for FAT16 but also "backported" to FAT12, so FAT16 and FAT12 are essentially identical as far as filenames go. In fact, all three filesystems share the same LFN hack. The only real differences are the FAT entry size and, for FAT32, some reorganization and cleanup (for example, the root directory is a normal directory on FAT32, part of the data cluster area, and can grow using the normal FAT methods).
That would make it incompatible with all versions of Windows. At which point you might as well use another filesystem.
FAT files need the stupid short names. It's a requirement. You can't physically have a FAT filesystem without short names. The patents are about the fugly hack that long filenames on FAT are (which makes them compatible with short filenames; it doesn't add that capability to them).
FAT12 has long filenames all right. You still see small SD cards formatted as FAT12 these days. FAT12/16/32 is typically chosen based on the device size.
The bricking chance for installing The Homebrew Channel on a Wii is essentially zero. I have never heard of it ever happening. It's about as likely as getting bricked by buying a WiiWare game from the shop.
On the other hand, the bricking chance is fairly high if you subsequently install random packs that you can find on the Internet that mutilate, modify, and break your wii's firmware in several ways with the purpose of playing copied games without a modchip.
If all you want to do is run homebrew applications from an SD card (emulators, media players, etc), you're golden. The only ones who often brick their Wiis are the clueless newbies who NEED TO HAVE custom Wii Menu graphics (even though they don't really understand what they're doing to their firmware) and the people who install the aforementioned soft-mod packs or otherwise mess with critical parts of the Wii's firmware.
Wrong. A NULL pointer is implementation-defined in C and !p would work just as well if the bit value of p were 0xdeadbeef for a NULL pointer. The compiler is responsible for that.
0 is used because it's convenient for compilers and architectures, not for programmers. Programmers don't care, they never see the bit pattern of a NULL pointer unless they're doing things wrong (casting to integers) or working on lower level architecture-specific code. Most think they do, though. See the C-faq section on NULL pointers.
Bollocks. CDs don't have missing material - what they have are pits metalized at a different depth (which is calibrated to cause destructive interference of the laser light). The depth can vary. Then there's an entire X-Y surface plane for the track to have jitter in.
CDs are as analog as all other digital media and signals: that is, quite a bit. We build pretty good devices to recover the digital data from them and clean out the imperfections though.
Your average Flash chip does 100k erase/write cycles. 18k is certainly reasonable for new tech, which will certainly improve over time. The number refers to the number of operations per erasable block (or it will in the future), so in practice you get a much larger number of total I/O operations on the entire chip, given a reasonable wear leveling algorithm.
Not that I'm an apple defensor, but I'm pretty certain that the iPod has a volume control, and last time I used one scrolling one item on the scoll wheel wasn't difficult.
iTunes, on the other hand, is indeed a stinking pile of fail.
Easy. A supercap for the microcontroller, a decent normal cap for the relay. Use a latching relay. Have the micro power on the main PSU when the supercap runs low, until it charges back up.
At a place where I used to work, we used to have units running microcontrollers and communicating in an RF network, plus opening and closing large 12V valves at times, with an average current consumption in the microamps range. Some of the newer units were a lot smaller than a matchbox and had enough burst power to turn a rather large solenoid valve on or off. Even with generous allowance for opening and closing valves, the current consumption was lower than the self-discharge rate of the 12V SLA batteries that we used to power them. They were designed to run for several years without requiring a battery change. We also had smallish supercap banks that could run the things for a few days, used as accumulators for solar cells.
An IR receiver and a micro that just checks for a signal and turns a small relay on? That's trivial in comparison. You could easily get down to the microwatt range, iff you make sure you run the thing off of a supercap and have the power supply physically off most of the time (i.e. use a relay).
Memory chips contain a lot more logic than you think they do. For starters, the miniscule charge stored in the capacitors has trouble getting through a microscopic bitline in the DRAM chip, so there's no way it would make it out to a chip pin much less the memory controller - that's why DRAM has highly sensitive differential amplifiers (one for each bitline pair). Modern DRAM uses relatively interesting interfaces that, while still closely related to the actual operations needed to read out the charge in the RAM, require quite a bit of logic. They tend to come with auto-refresh modes and the like. Adding a zero operation on power-on doesn't sound like a very big deal, although making it resistant to attacks (glitches / power changes / anything to interrupt the zeroing) would be more interesting.
Slashdot Mirror
That's funny. Around here thunderstorms tend to knock out the phone and DSL, but cells continue to work. Even more WTF is that the DSL often comes back on hours before the dialtone, even though they come from the same remote box. I guess the DSLAM portion is more reliable than the phone portion.
The first sentence.
Sodium melts at 98C. I somehow doubt your CPU is going to be very happy.
For what it's worth, nVidia cards can do this just fine and have been able to for a long time. See the "full GPU scaling" option in nvidia-settings. My HTPC's nVidia card also shows the BIOS on my HDTV at 1080p link resolution (while pretending to be VGA to the software).
There's already a standard for file-based accesses to USB devices. It's called PTP and it's what many cameras use. It shouldn't be too hard to adapt for more general FS access.
You're a victim of the marketing. There's a difference between "how fast a pixel can flip" and "how long it takes to START flipping after the computer tells it to". 2ms response time means no ghosting. It doesn't mean the LCD processing won't take over 50ms to actually propagate the change to the screen. In fact, very often, these low pixel response times are achieved using driving tricks and heavy preprocessing, which ADD lag by buffering more input frames.
Long ago, the complaint was ghosting and blurriness in high motion environments, but that's long since gone. The problem now are some LCDs which buffer a bunch of frames in order to perform questionable advanced processing, and which adds a ton of lag to the actual picture. Manufacturers don't quote numbers for that, unfortunately.
That was back when the term was coined. These days we have IOMMUs.
I tried ripping the stream, but it cut out halfway through :(
It's a stupid playlist. Try opening the file as text, copying the first line, and playing it with mplayer:
mplayer rtsp://157.150.195.57:554/ondemand/specialevents/2009/se090317pm.rm?cloakport=80,554,7070
The quality is substantially inferior to YouTube though.
What the heck kind of fire were you using that achieved the 1084C temperature needed to melt copper?
And they heavily obfuscate the software that deals with that signature, both on the host and the device, to prevent any reverse engineering.
On the iPhone 2.x firmware you can just turn the check off if it's jailbroken, but I imagine you're pretty screwed when it comes to a closed device like the iPod.
I believe that is the case for NTFS, not FAT32. On FAT (all variants), the inode information is stored together with the short filename. You can use any short filename (it doesn't have to be an abbreviation of the LFN), and some drivers might even let you null it out if they just use the long filename (though I'm pretty sure that's outside the spec), but there's no way around the fact that the SFN field is there and that the LFNs are still the same patented hack on top of them.
Sure, but the same applies to FAT16. I just wanted to point out that FAT12 isn't inferior to FAT16 in this regard, and, in fact, is still widely used on small devices. VFAT was developed for FAT16 but also "backported" to FAT12, so FAT16 and FAT12 are essentially identical as far as filenames go. In fact, all three filesystems share the same LFN hack. The only real differences are the FAT entry size and, for FAT32, some reorganization and cleanup (for example, the root directory is a normal directory on FAT32, part of the data cluster area, and can grow using the normal FAT methods).
That would make it incompatible with all versions of Windows. At which point you might as well use another filesystem.
FAT files need the stupid short names. It's a requirement. You can't physically have a FAT filesystem without short names. The patents are about the fugly hack that long filenames on FAT are (which makes them compatible with short filenames; it doesn't add that capability to them).
FAT12 has long filenames all right. You still see small SD cards formatted as FAT12 these days. FAT12/16/32 is typically chosen based on the device size.
The bricking chance for installing The Homebrew Channel on a Wii is essentially zero. I have never heard of it ever happening. It's about as likely as getting bricked by buying a WiiWare game from the shop.
On the other hand, the bricking chance is fairly high if you subsequently install random packs that you can find on the Internet that mutilate, modify, and break your wii's firmware in several ways with the purpose of playing copied games without a modchip.
If all you want to do is run homebrew applications from an SD card (emulators, media players, etc), you're golden. The only ones who often brick their Wiis are the clueless newbies who NEED TO HAVE custom Wii Menu graphics (even though they don't really understand what they're doing to their firmware) and the people who install the aforementioned soft-mod packs or otherwise mess with critical parts of the Wii's firmware.
Wrong. A NULL pointer is implementation-defined in C and !p would work just as well if the bit value of p were 0xdeadbeef for a NULL pointer. The compiler is responsible for that.
0 is used because it's convenient for compilers and architectures, not for programmers. Programmers don't care, they never see the bit pattern of a NULL pointer unless they're doing things wrong (casting to integers) or working on lower level architecture-specific code. Most think they do, though. See the C-faq section on NULL pointers.
Bollocks. CDs don't have missing material - what they have are pits metalized at a different depth (which is calibrated to cause destructive interference of the laser light). The depth can vary. Then there's an entire X-Y surface plane for the track to have jitter in.
CDs are as analog as all other digital media and signals: that is, quite a bit. We build pretty good devices to recover the digital data from them and clean out the imperfections though.
The human eye actually has a rather limited ability to detect polarization. Pretty sure it won't work for this experiment, though.
Pointer aliasing is poisonous for any kind of performance - that's why it's severely restricted in modern C.
Your average Flash chip does 100k erase/write cycles. 18k is certainly reasonable for new tech, which will certainly improve over time. The number refers to the number of operations per erasable block (or it will in the future), so in practice you get a much larger number of total I/O operations on the entire chip, given a reasonable wear leveling algorithm.
Not that I'm an apple defensor, but I'm pretty certain that the iPod has a volume control, and last time I used one scrolling one item on the scoll wheel wasn't difficult.
iTunes, on the other hand, is indeed a stinking pile of fail.
Easy. A supercap for the microcontroller, a decent normal cap for the relay. Use a latching relay. Have the micro power on the main PSU when the supercap runs low, until it charges back up.
At a place where I used to work, we used to have units running microcontrollers and communicating in an RF network, plus opening and closing large 12V valves at times, with an average current consumption in the microamps range. Some of the newer units were a lot smaller than a matchbox and had enough burst power to turn a rather large solenoid valve on or off. Even with generous allowance for opening and closing valves, the current consumption was lower than the self-discharge rate of the 12V SLA batteries that we used to power them. They were designed to run for several years without requiring a battery change. We also had smallish supercap banks that could run the things for a few days, used as accumulators for solar cells.
An IR receiver and a micro that just checks for a signal and turns a small relay on? That's trivial in comparison. You could easily get down to the microwatt range, iff you make sure you run the thing off of a supercap and have the power supply physically off most of the time (i.e. use a relay).
Most PICs aren't too power efficient. What you want is something like a TI MSP430. Those things can run for ages on a supercap.
Memory chips contain a lot more logic than you think they do. For starters, the miniscule charge stored in the capacitors has trouble getting through a microscopic bitline in the DRAM chip, so there's no way it would make it out to a chip pin much less the memory controller - that's why DRAM has highly sensitive differential amplifiers (one for each bitline pair). Modern DRAM uses relatively interesting interfaces that, while still closely related to the actual operations needed to read out the charge in the RAM, require quite a bit of logic. They tend to come with auto-refresh modes and the like. Adding a zero operation on power-on doesn't sound like a very big deal, although making it resistant to attacks (glitches / power changes / anything to interrupt the zeroing) would be more interesting.