NAND exhaustion is going to depend on manufacturing tolerance and operating conditions. They figures manufacturers supply are conservative estimates. I'm not at all surprised a handful of drives considerably out perform their specs.

And the native cell endurance has very little to do with it.
Erase block size is more important. As well as over-provisioning.

They don't go in to details, but if they can re-purpose a MLC cell as SLC after it has worn out too much to function as MLC, that's going to increase the drive endurance/decrease amount of required over provisioning.

All of those questions are about the controller and it's wear levelling software, not the flash chips.
In regards to your questions about security, the specific number of times a cell can be erased is irrelevant, only that wear level takes place and physical data is moved around to different locations and not immediately (or potentially, ever) erased from the old location.

In theory, you should just need to delete the encryption key, because the controller encrypts all the data on the flash chips 256bit AES encryption. Again, that's entirely in the controller software.

Dumbass

I don't understand how the native cell life is relevant.
You're not buying flash chips from them, you're buying an SSD. The write endurance of the drive is what matters. How that is achieved is irrelevant.

Wow, that's an impressive 1mm camera.

1mm is about 15% of the total thickness.

Hang on a minute, it uses about the same amount of power as a Raspberry Pi.
It's a crap load more powerful.

It's to be expected though, it's a power optimised 22nm CPU.

Not really. They've increased a bit above inflation, but the amount I'm spending on electricity has remained pretty constant, increasingly slightly below inflation (increases in device efficiency offsetting increase in costs). The amount I'm paying for gas has gone up a bit more.

I switched to DuckDuckGo and haven't looked back. They used to be noticeably worse in results quality, but Google has gone a long way downhill. Occasionally I don't find things with DDG and try Google. When I do, I have to wade through pages of totally irrelevant stuff to find that there are no matches, whereas at least DDG tells me straight away that it can only find half a dozen possibly-relevant things. I especially like the way DDG integrates with a number of domain-specific search engines.

It isn't. It runs natively via the NDK.

Given that Boeing will already be 3 years late to the party, when SpaceX has manned capability up and running this coming January? We're supposed to wait another couple of years for manned launch capability, when the Russians have already said they wouldn't be hailing our asses into orbit any more? I don't think "Time To Market" is a difficult argument.

One thing Swift will address... There are currently 3 memory management models in use in Objective-C, and for some of those models, you don't get a retain count automatically (for example, this is the case for a number of collection objects when doing an insertion).

Swift has the opportunity to rationalize this, which is not something you could do with the Objective-C libraries themselves, since doing so would change historical APIs and thus break old code.

It wasn't really until Metrowerks basically became incompatible with the Intel switchover and the 64 bit support had to drop certain types of support from Finder due to 64 bit inode numbers, and while I happily would have made them new header files so that they would have continued to work with the UNIX Conformance work, where Ed Moy and I basically broke their local private copies of their header files, since Motorola sold off the Intel version of the Metrowerks C the week because Apple announced Intel, it was pretty much DOA at that point.

So it basically took an Act Of God to get some people to get the hell off some of the old APIs we had been dooming and glooming about for half a decade.

Swift is another opportunity for that type of intentional non-exposure obsolescence to clean up the crappy parts of the APIs and language bindings that haven't been cleaned up previously due to people hanging onto them with their cold, dead hands. Hopefully, they will advantage themselves of this opportunity.

I maintain the GNUstep / Clang Objective-C stack. Most people who use it now do so in Android applications. A lot of popular apps have a core in Objective-C with the Foundation framework (sometimes they use GNUstep's on Android, more often they'll use one of the proprietary versions that includes code from libFoundation, GNUstep and Cocotron, but they almost all use clang and the GNUstep Objective-C runtime). Amusingly, there are actually more devices deployed with my Objective-C stack than Apple's. The advantage for developers is that their core logic is portable everywhere, but the GUIs can be in Objective-C with UIKit on iOS or Java on Android (or, commonly for games, GLES with a little tiny bit of platform-specific setup code). I suspect that one of the big reasons why the app situation on Windows Phone sucks is that you can't do this with a Windows port.

It would be great for these people to have an open source Swift that integrated cleanly with open source Objective-C stacks. Let's not forget that that's exactly what Swift is: a higher-level language designed for dealing with Objective-C libraries (not specifically Apple libraries).

Objective-C is a good language for mid-1990s development. Swift looks like a nice language for early 2000s development. Hopefully someone will come up with a good language for late 2010s development soon...