On the other hand, the Find 7 has two things the Nexus 5 will never have:

* removable battery

* microSD card

And as a practical matter, it's about as open as the Nexus 5. I think I even read that it has open-source drivers for one or two chips that are proprietary binary blobs in the Nexus 5.

A Nexus 5 can run Cyanogenmod with minimal difficulty. A Find 7 gets to have Cyanogenmod as its official operating system right out of the box.

Over at XDA, the Find 7 is a popular choice for "next phone" among Nexus 5 owners, and became the #1 choice of users who WERE looking at the Galaxy S5 almost overnight, once news leaked that even the T-Mobile S5 would have a locked bootloader.

Zero latency is impossible due to both the speed of sound in air and the speed of light (which indirectly governs the speed of information-conveyance by electrons over a wire. For the sake of being pedantic, the actual electrons travel along the wire at a relatively slow speed).

Imperceptible latency is impossible with anything besides analog modulation schemes like FM, or uncompressed PCM. By the very definition of stream and block compression, you have to buffer SOMETHING.

That doesn't mean there's no room for improvement... but what you're asking for basically at odds with data compression.

It's the same reason why hearing aids are still overwhelmingly analog devices. Digital technologies -- especially cheap ones -- introduce unacceptable latency.

> I doubt that this would fit comfortably in a pocket.

Think again. The Find 7 was explicitly designed to minimize horizontal bezel. Its width is less than most phones that have screens a full centimeter smaller.

I havne't personally laid my hands on a Find 7 yet, so I can't guarantee it will fit in a back pocket... but I'll be shocked if it's really too big to fit in the back pocket of an average, non-obese male wearing relaxed-fit jeans.

Mobile games don't suck because the displays are too high resolution... they suck because it's nearly impossible to buy a phone with proper analog & digital gamepads and buttons.

Touchscreens are unfit controls for anything that requires hair-trigger muscle memory responses, and accelerometers/gyros would only be suitable in some scenarios if the display you're looking at weren't part of the same slab being tilted. And the few devices that DO have gamepads make too many compromises for the sake of having a thin profile, and destroy most of the advantages of having a real gamepad in the first place. It's like manufacturers think that things like tactile snap and accuracy cease to matter the moment you add a radio modem to your pocket videogame system.

> Seems most manufacturers (and users?) forgot the "phone" bit.

What's this "phone" thing people keep talking about? You mean that old legacy "voice" mode that nobody uses anymore? Ew... Voice calls just seem so rude and intrusive.

> My Samsung Galaxy S3 Mini gets around three days stand-by with light to medium use..

ROFLMAO. How the other half lives...

I've managed to wring my Galaxy S3's stock battery dry in about 2 hours, and would estimate that my ~3,000mAH Seidio extended battery is good for about 5 hours of really hardcore use (though it usually doesn't fall below 10% until an hour or two before I'm ready to go to bed).

Admittedly, part of the reason my battery life is so bad is because I have zero tolerance for touch-latency or lag. I have my kernel tweaked to keep the CPU running full-bore if I've turned on the display within the past 5 seconds, or touched the screen within the past 10 seconds. The basic strategy is "ramp up to max speed at the slightest hint of upcoming interactive use, but allow it to slowly reduce the speed if I go for more than 5 seconds without touching the screen, or allow it to rapidly slow down & go to sleep if I actually turn off the display. It's spoiled me. Using a S3 with a stock ROM and normal CPU governor feels like I'm slogging through wet concrete. The truth is, 99% of the lag people complain about with Android phones is due to CPU-throttling. Force it to run at full-bore, and the lag magically goes away.

> Unfortunately, not for a phone with this kind of a screen.

Fortunately, Oppo listened to the feedback from people who saw the Find 5, and wisely gave it a removable battery (as well as LTE and microSD). So, you'll be able to buy a nice, big, beefy 6,000-8000mAH+ aftermarket battery for it. Or buy a half-dozen spare regular batteries from someone on eBay, and swap them out as needed throughout the day and night.

> Why this incessant focus on processing power?

Because modern webapps depend on Javascript for everything, and Javascript completely sucks on most current mobile platforms. Like it or not, a webapp that uses Javascript to render itself into an empty [body/] tag's DOM needs a metric shit ton of ram and a fast, multi-core CPU. Unfortunately, that description now includes a large plurality of the web sites that we use today.

The solution isn't to make our phones slow and laggy to maximize battery life. The solution is to give our phones bigger batteries so they can keep chugging along at full speed all day, remain alive overnight, and have enough power left to get you through breakfast online.

10-15 years ago, nobody bitched about the size or weight of a Palm Pilot or PocketPC. Our phones have now grown to the approximate length and width of a turn of the century PDA, but there's still an industry-wide unhealthy obsession with being thin and light at all costs. I'd LOVE a phone with the approximate dimensions of a 2001 iPaq that fills most of its interior with 12,000mAH or more of lithium ion goodness.

I only wish it were that simple. On my computer at work, I have at least one Java app that literally dies on launch unless you have BOTH 32-bit AND 64-bit Java installed. It exhibits this behavior on everybody's computer, and not just mine. Nobody, including its author, really knows why.

That oddball app notwithstanding, installing only a 64-bit JRE on a computer running 64-bit Windows 7 is NOT the universal solution. Google finally fixed it, but for the longest time, you literally couldn't do Android software development under Eclipse on a computer with ONLY a 64-bit JRE. It would randomly forget how to find the SDK, fail compilation due to bugs in your code that didn't actually exist (if you cut the class into the clipboard, saved the now-empty class, then pasted it back, all the errors would go away), completely mangle R.java, and would do a phantom cursor-left whenever you typed a semicolon at the end of a line, so that when you pressed return a quarter-second later, it moved the semicolon down to the next line and caused an error.

There a other examples of vehemently-32bit apps, but it's late and Android-Eclipse is the huge one that drove me nuts for about 2 years. Note that I'm not conflating Android and Java... Eclipse itself is what was screwing up when run on a 64-bit VM.

It's not nearly as bad as the situation with C(++), but the way Java's classloader refuses to allow jars-in-jars is still pretty stupid. We should be able to create an executable jarfile with a virtual /libs directory that contains all the thirdparty jarfiles our own app needs.

It's 2014. Nobody *cares* how much space the compiled bytecode takes anymore, because it's insignificant compared to the amount of RAM needed at runtime for the various heaps. And when there's an exception to that rule, it's usually with some app that's so utterly niche, the likelihood of having some other app on the same system that uses the same meaningfully-huge library is almost nonexistent anyway.

Ten years ago, we could cheat & copy the thirdparty jarfiles we used all the time to the JRE's /ext directory. That doesn't work anymore, because Java's near-weekly auto-updates mean it's now a moving target. The /ext subdirectory of today's JRE will be an orphaned wasteland by the middle of next week, and every app that depends upon automagically finding Log4j, HttpComponents, JSAP, and everything else in that directory will break unless we give our app its own copy anyway.

Far BETTER would be if Java could be aware of how much ram the computer has, and enlarge its heaps as necessary & possible. Few things piss me off more than getting OutOfMemoryException on a computer with 16 gigs because I forgot to manually specify a larger heap size when I launched some executable jarfile from the commandline.

I mean, seriously. Would it really be *that* hard for the JVM to handle TWO sets of memory pools instead of just one, so that if the Eden space (for example) gets exhausted and is due for GC, the JVM would check with Windows to see how much physical RAM is free, and if there's a lot of it, just allocate a new chunk that's roughly double the size of the old one, start sticking new data into the new one immediately, and consolidate data from the old one into the new one as a very, very low-priority non-blocking background thread that eventually returns the first chunk of RAM to Windows once everything in it has been either moved or freed. For longer-lived services where memory leaks are a real issue, you could tell it, "expand by doubling up to [max megs or percent free], then fall back to conventional garbage collection -- possibly, grabbing a new chunk of ram that's the same size as the old one if possible so the time-consuming object-copy can be deferred and done in the background"

The biggest problem with Java is the fact that it makes dealing with 32-vs-64-bit and user-vs-admin in shell and script environments needlessly painful under Windows.

I mean, seriously. Why, in 2014, do we STILL have bullshit like:

java -jar foo.jar arg1 arg2 arg3

(silent crash), or
[*very public crash*], or
"This application requires a 64-bit JVM"

then, have to screw around figuring out what the path is THIS WEEK to the right java.exe, because every goddamn semi-daily update changes the installation path, so you end up having to do something like:

{swear violently and with frustrated rage}
dir "c:\program files\java"
(see what the installation dir is this week)
"c:\program files\java\jdk1.7.0.69\bin\java.exe" foo.jar arg1 arg2 arg3

I mean, would it really kill them to give us an installer that installs BOTH the 32 and 64-bit JDKs, then creates a bunch of symlinks to a file named java.exe that -- when launched -- looks at the jarfile, determines whether it needs a 32- or 64-bit JVM, finds the latest 32- or 64-bit JVM as appropriate, and launches it -- passing the path to itself and the rest of the args as args?

This is an endless source of pain to me. Java is my main language & I end up using it for almost everything, and its awful handling of commandline launches has driven me crazy for years. When I write some tool I use a lot, I'll go to the trouble of setting it up to build with JSmooth so it can wrap the whole thing in a .exe file... but that's a royal pain in itself, and I'm dreading the day when I have to figure out how to use it to wrap a 64-bit Java app (I'm not even sure it can).

Java also needs to seriously improve the way it deals with UAC... like maybe install a privileged Java background service (that's normally asleep and idle) so we can launch apps as regular users under Windows 7, and programatically auto-elevate via UAC by having Java delegate sensitive tasks to that background service when necessary under Windows 7 or later. Or at least, create something like WindowsUACException that's a subclass of IOException (so Windows-aware apps can catch it explicitly and deal with it gracefully, without breaking Windows-unaware apps that are oblivious to UAC) that gets thrown when something fails due to UAC, instead of throwing some misleading Exception that makes it look like the filesystem is missing.

Regardless, Java's handling of Windows commandline launches of executable Jarfiles *sucks* under Java 7, and we can only hope they've had mercy on us and made it less dysfunctional under Java 8.

No sane airline would *allow* the President to fly commercially. It would be like painting a red target across its metaphorical face and daring terrorists to attack them, in return for less money and staggeringly-higher security expenses than it would otherwise have if normal people bought the tickets. And when the inevitable attack *did* happen, they'd get hit by lawsuits from everyone who ended up being "collateral damage". The amount of money they'd have to charge to guarantee that the service would be revenue-neutral for them (taking into account things like attacks) would probably be four times the amount we currently pay for the Secret Service and military to handle the logistics.

One bit of info that *might* be of interest... cell phone towers beacon to announce their presence to phones, but individual phones actually *poll* towers every few seconds. The reply from the tower lets them know when there's an incoming call, deliver SMS & voicemail notifications, etc. In theory, at least, if the mobile phone of any passenger came within range of a cell tower it was allowed to poll, there's probably a log of it somewhere.

That said, if the jet was at cruising altitude, the likelihood of a phone on board *doing* that is almost nil, because tower antennas are generally aimed downwards... partly, to minimize interference from airborne mobile phones that could otherwise splatter noise over a 40-100 mile radius (the line of sight when your transmitter is 5+ miles up in the air).

And how many atoms thick does the insulating layer between adjacent photosensitive or photoemitting structures need to be to prevent light emitted by one pair's LED from unduly influencing the state of an adjacent photodiode/phototransistor?

What, exactly, is the benefit of building a chip whose internal connections are basically all optoisolators?