The Motofone F3 is dirt cheap, light, compact and lasts long on a charge. It features an epaper display that is perfectly readable in full sunlight and is always on. It's quite convenient to be able to read the time without pressing the power button first. The disadvantage is that the segment display shows only a few letters at a time. If you want to do any amount of texting, it's too inconvenient.

Why wait for Tesla when you can get a Zero motorcycle?

John Kiriakou, the whistleblower went to jail.

Most doctors don't take the Hippocratic Oat.

Nearly half of the students aiming for a bachelors or masters degree in mathematics in Germany are women. I had assumed that it's the same internationally, but actually this seems not to be the case. Interesting.

We do have gender equity in math. Is that because math is more "societally meaningful" than CS or engineering?

I've written a somewhat popular Android app and most of its crashes are either the fault of the runtime or of vendor specific customizations.

The Developer Console provides excellent reporting on both uncaught Java exceptions and crashes in native code. Most often, the Dalvik VM crashes during garbage collection. The Dalvik class loader is also flaky and has issues with multithreading that only got worked around in newer versions. I've also seen the libchromium crash inside my app from adverts delivered by Googles Admob service, which is somewhat scary from a security perspective.

Another issue is that apps using Googles compatibility library now crash on HTC devices running Android 4.1 as soon as the user presses the menu key. HTC is no longer providing updates and Google simply states that it's not their fault and therefore not their problem. Now thousands of app developers have to independently find out about the issue and work around it.

So when an app crashes, there's a good chance that it's not the fault of the app developer. On a brighter note, the ART VM used in Android 5 and newer seem to be rock solid.

AFAIK, Stingray is based on an IMSI catcher. It simulates a cell tower and gets cell phones in the area to connect to it by providing the strongest signal. It then records the data of all connected cell phones and forwards it to the network.

Since IMSI catchers are well understood, all this secrecy is a bit surprising. It makes speculation about additional capabilities plausible. It could use exploits in the modem software to install malware. Such malware could do all sorts of things like reading local files, including contacts, messages, browsing history and possibly passwords. It could also store files on the device. It could provide side channels for encrypted communication from https to WhatsApp calls. It could also turn on the microphone and camera. All this is pure speculation, but it seems plausible.

SpaceX made similar claims and reduced the dependency from suppliers by producing as much a s possible in-house.

Forensic analysis methods are not scientifically validated in general. AFAIK any forensic evidence is admissible if the the judge decides so. The general standard is that is sounds plausible.

The Soviets never shot people for looking funny at the Kremlin. Mathias Rust pulled a very similar stunt in 1987. He was sentenced to four years, but released after one year as a sign of political goodwill.

I'm afraid this is a bit too technical for senators. Who will be able to see their dick picks?

Firefox comes with a couple of calculators built in. It has since before it was called Firefox.

Usually, "epoxy" around the edges of a BGA chip is neither an anti-hacking attempt nor a light-proofing attempt. It's called underfill, and its chief purpose is to increase mechanical strength and make the bond more durable than tiny bare solder balls would be on their own.

Yes they are. Most multimedia processing is parallelizable, and thus benefits greatly from SIMD instructions - for example, just about every CPU-based video codec ever. If you want an actual example, I wrote a high-performance edge detection algorithm for laser tracing, with its convolution cores written in optimized in SSE2 assembly, and am hoping to write a NEON version. It'll never run reasonably on the original Raspberry Pi because it's too underpowered to do it without SIMD (I didn't even bother writing a plain C version of the cores, because honestly any platforms without SSE2 or NEON are going to be too slow to use anyway).

Obviously you can use SIMD instructions for a lot more, but multimedia is the obvious example. And as I mentioned, the Pi makes up for it for standard codecs only with its GPU blob decoder, but that doesn't help you with anything that isn't video decoding (e.g. filtering).