Completely undocumented... <CARUSO NAME="david" STYLE="csi/miami" SHADES="true"> ...until now. </CARUSO>

YEAAAAAAAAAH!

Unfortunately, BitPim would not have been an option for this situation, as the T-Mobile Sidekick does not store any data locally - simply plus down an image from the giant server in the sky on a reboot.

And that's the 'server' that's gone, now.

This is an epic fail; many bards will send their sons to school on the song that will be sung from this gross misadventure.

You don't know - and neither does the computer.

Decryption is a mathematical operation. You are given a blob of yunk. You can be fairly certain it is encrypted with a given cipher because it meets certain characteristics - either length, or hash-depth, or there is a header or footer of a given length, or some revealing information about the cipher may have been sent prior to or alongside the encrypted blob.

Then, if you're smart enough, or you have enough money, or time, or computing power, or a lot of luck, the decryption operation might occur. You can check as to whether or not you've successfully decrypted the data mathematically - e.g. does the result set fit with the function I've just run and give me the source data I started with? If so, yes, you've decrypted the data.

It's your responsibility as a researcher to decide what to do with whatever came out the other side. You may have to decrypt it again before proceeding. You may find out that what you just decrypted was nothing more sinister than ICMP_FRAGMENTATION_REQUIRED (Frak!).

The holy grail of cryptography may infact be steganographical encryption - or binary / machine language that reads as Grandmother's Cookie Recipe, but when run as an executable it actually glasses the machine. Who knows?

Unless Jobsy himself has told you this, I'm pretty sure that running this article either violates HIPPA, or is simply full of lies...

Where did the information about a transplant come from? I hope the source was verified, and re-verified, and then re-verified again. Remember when CNN posted that Jobs had had a heart attack, but it simply turned out to be "citizen journalism" gone horribly, horribly wrong? Gotta be careful with this crap.

Either way, all the best to The Steve.

Counter-nits:

US Airways Flight 1549 is recorded as an Airbus A320-214. The crusing speed of an A320 is Mach 0.78. Mach 0.78 is 593.7415 miles per hour, which is closer to 600 than 500, I believe. In holding with being a complete bastard, 91% of Mach 1 is 692.698416 miles per hour, fully 98.95 miles per hour more than your claim. (The speed of sound being 761.207051 miles per hour, for reference.)

You are correct about the rate-of-climb at the time of incident, though - it was grossly less than the cruse speed.

Also, nits - not nicks - are often picked, unless you're creating a new account.

Agreed to the point of the destruction of the recovered disk. If the disk was still any good, it probably wouldn't have needed SpinRite in the first place. Trash it - GBs are cheap these days.

Psh. Your puny mesh screen isn't going to stop the bird; it just means his death-by-CF6 sentence is commuted, only instead to being put through a fine mesh screen.

Yes, but then you include metal rounds as a class of objects that likely will be SUCKED INTO THE ENGINE. If my options for aspirating something are a bird versus a bullet, I think the plane would fair better ingesting a bird. Not to mention the hazard of turning one falling (suckable) objects into many falling (suckable) objects.

Generally, yes, the flocks are difficult to pick up on radar, due to the small cross-section, and generally squishy nature of birds. The speed of an aircraft is also an issue - moving at 600mph (~880 feet per second) - means the flock (given radar / VFR issues) will probably already be upon you even before you have a chance to react. Even if you did have time to react, an Airbus A320 doesn't exactly (safely) turn on a dime.

This is so true that it's sad.

And, of course, the apps were originally outsourced to India, developed by GroupX. Now, GroupY will be brought in to re-tool them, and management asks 'But it already works. Why do we need to update it?'

The business doesn't see it as a value - it's not broken, to them, and therefore doesn't need to be fixed (or have a dime spent on it).

SpinRite works to identify bad sectors on a track on magnetic media. Once it locates a bad sector, it attempts to re-read (repeatedly) the bitmap from that sector. If successful, it will re-write that bitmap to an unused sector, mark the original sector as bad, and provide a pointer in the index of the drive to the newly created sector.

For me, SpinRite has successfully corrected fubared Windows installations (STOP error at boot, unreadable boot volume, registry .xxx missing at boot time, etc), repairing a disk with a FileVaulted sparseimage (allowing it to mount), repairing a disk that was TrueCrypted (allowing it to mount), as well as repairing a drive enough to the point where I can make an image copy of it and recover atleast some (and in some cases, most) of the data on it.

SpinRite is also the only tool I'm comfortable running on an encrypted volume.

It's not voodoo, and I run it quarterly for maintenance purposes.

Except those who would simply dBAN the device and run Linux on it. There are quite a few machines out there that can't run Vista for shit, but as soon as you load Ubuntu/Kubuntu/SuSE on them, they handle the task pretty well. The only gripes are super proprietary wireless drivers, and those've come a good long way in the last 18 months.

My MSI Wind (U 100, h4ckint*sh :-O!) use a standard SATAii 2.5" drive.

http://www.newegg.com/Product/Product.aspx?Item=N82E16822148371 - with that 500GB Seagate drive being all of $90, the future is now.

I wish 3G in the States was that cheap.

It's seriously between thirty and sixty dollars a month here, depending on your subscription area, and data plan.