However, single-bit errors are possible with faulty disk hardware. The cache RAM on the disk or its interface can be flaky, and for PATA disks a bad cable can cause single-bit errors. SATA disks usually catch IO errors since they use a more complicated encoding and make use of checksums.
The perl script will stay cached until something else pushes it out of RAM or until you reboot the system. In general, files are loaded once and stick around for quite a while unless you're low on RAM. In my case, it stayed cached while I investigated it, and I could see the broken character with various viewers. Bad RAM could also cause an intermittent issue if it happened to affect memory used by the Perl interpreter to load the file (that would change each time), but in this case it affected the kernel's file cache, which is quite persistent in the medium or even long term.
I probably had the RAM error for a long time and never noticed. It likely caused a few kernel panics and segfaults along the way, but I probably attributed those to stuff like buggy X11 drivers. The broken Perl script was the first odd thing that I could directly attribute to a RAM problem, later confirmed with memtest86 (the broken bit also matched the change that happened to the character).
I experienced almost exactly that issue with a RAM error. My system was apparently stable, and then one day I got a syntax error in a system Perl script: one character had changed. The script was owned by root and otherwise untouched. After puzzling over it for quite a while I realized it could be a RAM error and ran memtest86. It reported a single permanently stuck bit in my 512MB of RAM. I found a kernel patch to manually mark problem RAM areas as reserved and kept on running with that RAM for a few years.
Are you sure that perl script issue was caused by a drive error? A RAM error can cause the same apparent problem, if the corruption happens in the kernel's cache. However, it shouldn't be permanent as it will not be written back to disk (the cache won't be dirty) unless someone actually modifies the file.
Smug and clueless. Consider the following timeline: On October 23rd, 2008, they released their first "real" update (attempting to block exploits). Shortly after that, homebrew was available again, of course. However, softmod piracy was blocked because at the time homebrew did not provide full system control (i.e. BootMii), and we did not publicly disclose the exploit that we used to install the Homebrew Channel. Then someone released a separate exploit for other reasons (to install DVDX which we had neglected to make available at the time), and the pirates latched on to it as their "gateway" into the system.
Then they went through two updates and 7 months, trying to patch the holes that we used to install homebrew, never once attempting to patch the hole that was the root of all softmod piracy on the Wii at that stage. Then we released BootMii on May 13th, 2009 which gives the user full control (for WiiLinux, NAND backup and restore functionality, etc.) and therefore can be used to launch softmod tools. Nonetheless, I'd say the vast majority of pirates kept using the old hole. Nintendo kept trying to block our homebrew exploits and ignored that one silly hole that the pirates so love.
Now they've finally fixed the hole so loved by Wii pirates. After 20 months.
Of course, then there's the way that they're currently deleting The Homebrew Channel: by hardcoding our channel ID. They did that last time. We changed our ID to JODI, a reference to Jodi Daugherty, "Nintendo of America's senior director of anti-piracy" who ignored, then cyberstalked and harassed bushing when he tried to report a sensitive bug. Now the Wii System Menu contains code to delete "JODI". We'll just switch to another ID.
In other words, it's just another Samsung processor like the ones in previous iPhones, which were already Apple-custom anyway. A4 is just marketing. Apple has been using more and more custom application processors for a while now; they've just decided to flip the PR switch and use it as an advertised feature.
Gnash is, well, pretty crappy. It's slow as heck, doesn't sync audio properly (mostly because it tends to render way too slowly and doesn't know how to frameskip right), and can't handle most nontrivial Flash content. It appears they've ditched the OpenGL backend (which is poor anyway), and the AGG backend is uselessly slow at nontrivial output sizes. I've had better luck with the two years abandoned swfdec than with Gnash. It really ought to be a lot better by now.
I've seen people create weird Flash-player-ish things in a few days or weeks that seem to do lots of things better than Gnash. To me it sounds like the Gnash devs just don't really know what they're doing. Personally, I'm hoping that lightspark will finally become THE decent open-source Flash player.
They don't abstract the filesystem, but they abstract the hell out of the lowlevel Flash blocks and just present you with a pretty array of sectors that all work perfectly... until they don't, and then you're screwed.
Good luck, but I wouldn't hold my breath. These things are essentially disposable, and probably more trouble than it's worth reviving.
The specifics:
Any USB reader is going to present itself as a USB mass storage device. This is the worst possible option, because USB mass storage is horridly generic, and pretty much guaranteed to abstract away any chance of lowlevel operations on particular memory card interfaces. Some readers might have undocumented lowlevel operations, but then you'll almost certainly need a tool specific for your reader or chipset. There's no generic lowlevel format for USB mass storage card readers.
SD/MMC cards themselves have a high level controller. As far as I can tell from skimming the standard, all you get to do besides read and write is "erase" sectors in blocks, which may or may not help. There may or may not be proprietary commands to do other stuff. Your best bet for a reader is one embedded in a laptop that is not internally SD - that is, one that's a standard SD Host Controller attached to the PCI/PCIe bus. Or an embedded system like some hackable cellphone or a Wii.
SmartMedia and xD are bare Flash chips in a pretty package, with no controller. If you can get a reader that will expose the low level flash block I/O, you might be able to get somewhere.
CompactFlash cards are basically IDE/ATA drives with some extra modes. IDE low level format commands may apply. Your best bet here is an actual CF to IDE/ATA converter.
I don't know about Memory Stick and other cards, but most are along the same lines as SD
OK, upon further testing (I don't use a passcode myself so I never even looked into this) and getting some information from others, it looks like this isn't a total oversight on Apple's part, but it is a real bug that requires a specific sequence to trigger.
Here's how it's supposed to work:
The first time you connect an iPhone to a specific computer, the iPhone will "pair" with the computer. This happens behind the scenes.
This pairing process is disabled while the phone is locked with a passcode.
Once paired, that computer will always be able to talk to that phone, even while locked.
The actual bug is that there's a race condition during boot. There's a window during which the lock code setting hasn't been read, during which the phone will accept pairing requests even though it shouldn't.
If you want to try it on Linux, do this:
Delete ~/.config/{libiphone,libimobiledevice} to clear the pairing data
Create a directory to mount the device on
Configure a passcode on your device and shut it dow
Have a syslog window open
Plug it into USB and power it on
As soon as you see your device enumerate with the USB subsystem, start spamming ifuse <mountpoint> on a terminal
With any luck it will pair and mount. From now on you can unmount it and mount it as many times as you wish with this computer.
Notice how the "slide to unlock" SpringBoard screen will not have yet appeared when this works. Once it does, the passcode has been configured and pairing will no longer work. On the latest version of ubuntu it tries to automount as soon as it sees the device, which makes this bug a lot more obvious.
The "S" stands for "crappy failed security-through-obscurity DRM that absolutely no one actually uses in the real world". It has nothing to do with actual security.
The iPhone 3GS supposedly uses whole-disk encryption. This does squat when your USB comms protocol doesn't request authentication though, since you can pull the data off through the iPhone kernel's transparent decryption layer.
In other words, this hack has nothing to do with encryption and everything to do with an insecure protocol that makes no attempt to actually request PIN authentication before handing over all your data. Nobody expected your PIN to actually act as key for encryption anyway; that's impossible, as the iPhone has to be able to access your data even while locked.
Correct. I wrote most of the usbmuxd implementation that we use on Linux as a clone of Apple's version. In fact, you should (as of yesterday) be able to compile libusbmuxd and libimobiledevice and maybe even ifuse (with macFUSE?) and use them together with Apple's usbmuxd on OSX to pull off this hack there. Heck, I think at least libusbmuxd and libimobiledevice should even build on Windows these days (Apple provides a Windows version of usbmuxd with iTunes).
They're not a block device, so you can't mount their filesystem as such. Instead, they're effectively network drives: the proprietary AFC file transfer protocol tunneled over a hugely mutilated version of TCP stuffed into USB packets. Which you can mount under Linux, using FUSE and the appropriate apps (usbmuxd, libimobiledevice, and ifuse). I maintain usbmuxd.
Apparently Apple relies on security through obscurity here (only their apps are usually able to talk to an iDevice), and the actual protocols aren't secured.
Incidentally, this is where the term "jailbreaking" comes from: breaking out of the AFC filesystem jail (which is usually limited to the user's data partition). Jailbreaking's original feature was to introduce a secondary AFC share with root privileges on the root directory, and jailbreaks to this day still do. You can use ifuse --root under Linux to mount this secondary share.
why can't I set the clock from the taskbar to sync with an nntp server
I'm assuming you mean an NTP server, not a USENET news server (NNTP).
Have you ever been able to do this anyway? You can't set the time on a Linux system without root, and ntpd usually runs as a system daemon anyway. It doesn't make much sense on the taskbar clock applet. This kind of stuff belongs in the distro-specific control panel / customizations, since different distros configure ntpd in different ways.
With no way to fine-tune who is allowed sound and who isn't.
With a browser implementation of an open standard, it would be easy to add features such as muting a page's audio when (*gasp*) it's not in the foreground tab. Besides, there will no doubt be plenty of ways to turn off audio, partially or completely. And plug-ins like greasemonkey work great to hack around website JS features, while you can't do anything with Flash SWF blobs other than turn them on and off.
As you can now see, it's Slashdot's fault. Apparently someone is too lazy to update the Unicode whitelist with characters that are actually useful on a tech site.
Actually, tons of points of failure, each of which is equally critical. The PKI infrastructure is fundamentally flawed. Control VeriSign and you don't control the bulk Internet's public key infrastructure; you control the entirety of the Internet's public key infrastructure. Or you could control any other CA, or even any other intermediate CA. All it takes is one rogue or compromised CA to sign anything and everything that the attacker wants.
Most probably include some sort of DSP, but it's not guaranteed to be externally programmable (the firmware might be in ROM), and key portions of the decoder are implemented in hardware. Sure, it might be a DSP, but not a general-purpose DSP.
Hardware support will be good on the TI OMAP line of cellphone chips, which include an actual programmable DSP (instead of a hardcoded decoder). There's already a Theora implementation for them. These chips are used e.g. on the Droid and the N900.
Re:Sorry, just one more science fiction joke
on
The Laser Turns 50
·
· Score: 1
Don't forget 2013, the 20 year anniversary of the modern high-brightness blue/white LED, without which no modern electronic gadget could have existed.
Slashdot Mirror
However, single-bit errors are possible with faulty disk hardware. The cache RAM on the disk or its interface can be flaky, and for PATA disks a bad cable can cause single-bit errors. SATA disks usually catch IO errors since they use a more complicated encoding and make use of checksums.
The perl script will stay cached until something else pushes it out of RAM or until you reboot the system. In general, files are loaded once and stick around for quite a while unless you're low on RAM. In my case, it stayed cached while I investigated it, and I could see the broken character with various viewers. Bad RAM could also cause an intermittent issue if it happened to affect memory used by the Perl interpreter to load the file (that would change each time), but in this case it affected the kernel's file cache, which is quite persistent in the medium or even long term.
I probably had the RAM error for a long time and never noticed. It likely caused a few kernel panics and segfaults along the way, but I probably attributed those to stuff like buggy X11 drivers. The broken Perl script was the first odd thing that I could directly attribute to a RAM problem, later confirmed with memtest86 (the broken bit also matched the change that happened to the character).
I experienced almost exactly that issue with a RAM error. My system was apparently stable, and then one day I got a syntax error in a system Perl script: one character had changed. The script was owned by root and otherwise untouched. After puzzling over it for quite a while I realized it could be a RAM error and ran memtest86. It reported a single permanently stuck bit in my 512MB of RAM. I found a kernel patch to manually mark problem RAM areas as reserved and kept on running with that RAM for a few years.
Are you sure that perl script issue was caused by a drive error? A RAM error can cause the same apparent problem, if the corruption happens in the kernel's cache. However, it shouldn't be permanent as it will not be written back to disk (the cache won't be dirty) unless someone actually modifies the file.
Smug and clueless. Consider the following timeline: On October 23rd, 2008, they released their first "real" update (attempting to block exploits). Shortly after that, homebrew was available again, of course. However, softmod piracy was blocked because at the time homebrew did not provide full system control (i.e. BootMii), and we did not publicly disclose the exploit that we used to install the Homebrew Channel. Then someone released a separate exploit for other reasons (to install DVDX which we had neglected to make available at the time), and the pirates latched on to it as their "gateway" into the system.
Then they went through two updates and 7 months, trying to patch the holes that we used to install homebrew, never once attempting to patch the hole that was the root of all softmod piracy on the Wii at that stage. Then we released BootMii on May 13th, 2009 which gives the user full control (for WiiLinux, NAND backup and restore functionality, etc.) and therefore can be used to launch softmod tools. Nonetheless, I'd say the vast majority of pirates kept using the old hole. Nintendo kept trying to block our homebrew exploits and ignored that one silly hole that the pirates so love.
Now they've finally fixed the hole so loved by Wii pirates. After 20 months.
Of course, then there's the way that they're currently deleting The Homebrew Channel: by hardcoding our channel ID. They did that last time. We changed our ID to JODI, a reference to Jodi Daugherty, "Nintendo of America's senior director of anti-piracy" who ignored, then cyberstalked and harassed bushing when he tried to report a sensitive bug. Now the Wii System Menu contains code to delete "JODI". We'll just switch to another ID.
In other words, it's just another Samsung processor like the ones in previous iPhones, which were already Apple-custom anyway. A4 is just marketing. Apple has been using more and more custom application processors for a while now; they've just decided to flip the PR switch and use it as an advertised feature.
Gnash is, well, pretty crappy. It's slow as heck, doesn't sync audio properly (mostly because it tends to render way too slowly and doesn't know how to frameskip right), and can't handle most nontrivial Flash content. It appears they've ditched the OpenGL backend (which is poor anyway), and the AGG backend is uselessly slow at nontrivial output sizes. I've had better luck with the two years abandoned swfdec than with Gnash. It really ought to be a lot better by now.
I've seen people create weird Flash-player-ish things in a few days or weeks that seem to do lots of things better than Gnash. To me it sounds like the Gnash devs just don't really know what they're doing. Personally, I'm hoping that lightspark will finally become THE decent open-source Flash player.
That should be not internally USB. D'oh.
They don't abstract the filesystem, but they abstract the hell out of the lowlevel Flash blocks and just present you with a pretty array of sectors that all work perfectly... until they don't, and then you're screwed.
Good luck, but I wouldn't hold my breath. These things are essentially disposable, and probably more trouble than it's worth reviving.
The specifics:
OK, upon further testing (I don't use a passcode myself so I never even looked into this) and getting some information from others, it looks like this isn't a total oversight on Apple's part, but it is a real bug that requires a specific sequence to trigger.
Here's how it's supposed to work:
The actual bug is that there's a race condition during boot. There's a window during which the lock code setting hasn't been read, during which the phone will accept pairing requests even though it shouldn't.
If you want to try it on Linux, do this:
Notice how the "slide to unlock" SpringBoard screen will not have yet appeared when this works. Once it does, the passcode has been configured and pairing will no longer work. On the latest version of ubuntu it tries to automount as soon as it sees the device, which makes this bug a lot more obvious.
Just make it shut down the phone after 5 attempts. Considering how long it takes for the iPhone to boot, that should be enough of a deterrent.
The "S" stands for "crappy failed security-through-obscurity DRM that absolutely no one actually uses in the real world". It has nothing to do with actual security.
The iPhone 3GS supposedly uses whole-disk encryption. This does squat when your USB comms protocol doesn't request authentication though, since you can pull the data off through the iPhone kernel's transparent decryption layer.
In other words, this hack has nothing to do with encryption and everything to do with an insecure protocol that makes no attempt to actually request PIN authentication before handing over all your data. Nobody expected your PIN to actually act as key for encryption anyway; that's impossible, as the iPhone has to be able to access your data even while locked.
Correct. I wrote most of the usbmuxd implementation that we use on Linux as a clone of Apple's version. In fact, you should (as of yesterday) be able to compile libusbmuxd and libimobiledevice and maybe even ifuse (with macFUSE?) and use them together with Apple's usbmuxd on OSX to pull off this hack there. Heck, I think at least libusbmuxd and libimobiledevice should even build on Windows these days (Apple provides a Windows version of usbmuxd with iTunes).
They're not a block device, so you can't mount their filesystem as such. Instead, they're effectively network drives: the proprietary AFC file transfer protocol tunneled over a hugely mutilated version of TCP stuffed into USB packets. Which you can mount under Linux, using FUSE and the appropriate apps (usbmuxd, libimobiledevice, and ifuse). I maintain usbmuxd.
Apparently Apple relies on security through obscurity here (only their apps are usually able to talk to an iDevice), and the actual protocols aren't secured.
Incidentally, this is where the term "jailbreaking" comes from: breaking out of the AFC filesystem jail (which is usually limited to the user's data partition). Jailbreaking's original feature was to introduce a secondary AFC share with root privileges on the root directory, and jailbreaks to this day still do. You can use ifuse --root under Linux to mount this secondary share.
There's a live application blacklist backdoor/killswitch built into the iPhone. It hasn't been used yet.
I'd bet money that if a Flash-enabled browser were snuck into the App Store, Apple would make their inaugural blacklist entry.
I'm assuming you mean an NTP server, not a USENET news server (NNTP).
Have you ever been able to do this anyway? You can't set the time on a Linux system without root, and ntpd usually runs as a system daemon anyway. It doesn't make much sense on the taskbar clock applet. This kind of stuff belongs in the distro-specific control panel / customizations, since different distros configure ntpd in different ways.
With no way to fine-tune who is allowed sound and who isn't.
With a browser implementation of an open standard, it would be easy to add features such as muting a page's audio when (*gasp*) it's not in the foreground tab. Besides, there will no doubt be plenty of ways to turn off audio, partially or completely. And plug-ins like greasemonkey work great to hack around website JS features, while you can't do anything with Flash SWF blobs other than turn them on and off.
Third, unlike Theora and H.264, Vorbis is actually much better than MP3.
Try last month. They unconditionally (and probably illegally) pulled out a major feature of the PS3 for all PS3 owners.
As you can now see, it's Slashdot's fault. Apparently someone is too lazy to update the Unicode whitelist with characters that are actually useful on a tech site.
That's 36 extra seconds for the whole day, not per visit. That's about a 25% increase.
Actually, tons of points of failure, each of which is equally critical. The PKI infrastructure is fundamentally flawed. Control VeriSign and you don't control the bulk Internet's public key infrastructure; you control the entirety of the Internet's public key infrastructure. Or you could control any other CA, or even any other intermediate CA. All it takes is one rogue or compromised CA to sign anything and everything that the attacker wants.
Most probably include some sort of DSP, but it's not guaranteed to be externally programmable (the firmware might be in ROM), and key portions of the decoder are implemented in hardware. Sure, it might be a DSP, but not a general-purpose DSP.
Hardware support will be good on the TI OMAP line of cellphone chips, which include an actual programmable DSP (instead of a hardcoded decoder). There's already a Theora implementation for them. These chips are used e.g. on the Droid and the N900.
Don't forget 2013, the 20 year anniversary of the modern high-brightness blue/white LED, without which no modern electronic gadget could have existed.