An off-the-shelf SATA 840 EVO SDD hits 98,000 read IOPS, and all those tasks you mention added together wouldn't hit more than 1% of that. They're the very definition of network bound operations. The average email in my IMAP spool right now is 43KB and would take 11 4KB operations to completely read from or write to storage. Browsers site there idle 99.9% of the time. IRC? Not that I've ever seen.

I haven't bothered to look at their methodology but I tentatively agree with their conclusion: almost no desktop users would be able to tell the difference. I mean, even a HDD benching at 103 read IOPS seems spritely for most use cases. A SATA SSD working 950 times faster is as close to instantaneous as most desktop uses could ever hope for.

A guy named Amdahl had something to say on the subject. SSDs excel at IOPS, but that buys you little if you're not IOPS-constrained.

Examples of things that eat operations as fast as you can throw them at 'em: databases, compilation, most server daemons.

Examples of things that couldn't care less: streaming large assets that are decompressed in realtime, like audio or video files. Loading a word processing document. Downloading a game patch. Encoding a DVD. Playing RAM-resident video games.

It should be a shock to roughly no one that buffing an underused part won't make the whole system faster. I couldn't mow my lawn any faster if the push mower had a big block V8, nor would overclocking my laptop make it show movies any faster.

TL;DR non-IO-bound things don't benefit from more IO.

Yeah. I've only seen CB used very recently - I think I first saw an alert for it in early 2013. At least once, an Amber Alert went out by CB which really freaked a bunch of people out because they'd never seen a CB alert before.

I think you didn't understand what you linked to when you stated, "is apparently present for some fairly popular devices, but not activated in software"

The problem is that since FM is a highly niche feature, there's no standard for FM HALs in Android. This means that those manufacturers that do implement FM do it in their stock firmware in whatever way they want. With one exception (STMicro's implementation used in many Sony devices), they never document this methodology. (STM's HALs were supported in CyanogenMod for a while, but was eventually dropped because while STMicro documented the basic HAL interfaces, there was no opensource reference HAL implementation, and thus the interface only supported older Sony devices with blobs supported by that HAL.)

You'll note that:
1) All of the devices that app supports are older devices.
2) All of the devices that app supports DID support FM in their stock firmwares. The only issue was that if you replaced the stock firmware with an AOSP derivative, you lost FM, because it was a niche feature and no device maintainer had the time to work on it, partly due to the lack of any reference implementation of an STMicro HAL. I speak from experience in this - I was the CyanogenMod maintainer for the original Galaxy Note from Spring 2012 until I left CM in August 2013 - the Note had FM, but all of my time was consumed reverse engineering core functionality and not niche functionality.)

I haven't seen a smartphone with onboard FM hardware in a while. They aren't simply "disabling" it - an FM receiver costs more, requires board real estate, and as you said, has the additional challenge of an antenna.

It's cost for a feature very few people use. FM is deprecated and obsolete - it's been dead in Europe in favor of DAB for years, and in the USA, satellite radio is the go-to for vehicles and streaming is the go-to for anywhere with wired Internet access (the backhaul for wi-fi in 95%+ of cases is wired DSL, cable, or fiber).

The NAB should look at themselves before complaining about others. FM is no longer a desirable feature for most people thanks to Clear Channel abusing every loophole in station ownership rules (There are various rules that are supposed to prevent one company from owning too many stations, among other things to promote a diversity of content.) The end result is that the content of FM stations is utter crap. The last time I drive without XM, on a single 4-hour drive I listened to one song at least three times, I think it was four. There were numerous other repeats. Meanwhile, if I do that drive with my XM subscription, it's rare that I'll hear even a single repeat.

Simply put, if a phone has FM now, I see that as a reason NOT to buy it, because that is paying extra for hardware that I'm NEVER going to use.

...unless you're a smoker and have highly depressed CO2 overload sensations due to your constant saturation.

Nothing like releasing your review the day after units start shipping, ie when it's too late to find out the unit's faults.

Goddammit I hate embargos...the only reason they exist is to hide flaws and problems from people who could get a refund. Ray, stop being the industry's bitch. You have a ton of readers, tell gadget makers to pound sand if they tell you that you can't release a review before it ships.

You seem to have forgotten the announcement that they're working on a device for Blu that will not contain GMS.

They are one and the same. Every person who has a leadership role in the CyanogenMod project is an employee of Cyanogen Inc.

CyanogenMod is trademarked, Cyanogen (in respect to Android operating systems) is trademarked - and Cyanogen Inc. (or Steve Kondik personally, I'm not sure, but he's CTO of Cyngn) is the holder of those trademarks.

Key being "Yet".

Every time Cyngn fucks up PR-wise, CM gets splash damage.

Why? Because for all you want to say Cyanogen Inc. != CyanogenMod - that's not true. Every person who has a leadership role in CyanogenMod and drives the direction of the project is an employee of Cyngn. That's a fundamental conflict of interest that cannot be resolved.

Yeah the MS junk won't be installed into CM just yet - but wait until that "Deep integration" Kirt McMaster keeps talking up starts happening - you're going to see architectural changes happen in CM designed solely to be beneficial to Microsoft.

Yeah. As much as I'd like to be as "massively open" as Replicant is (and the Replicant guys' work was HUGELEY beneficial with some of the nightmares that were Haxxinos, I have had some great conversations with Paul during the days when Teamhacksung was active), the truth is that as long as SoC manufacturers are douchebags (Sadly, Qualcomm is the most open of the viable vendors out there - for all of the bad things they've done for open source, some of which were the final straw that led to JBQ stepping down as AOSP lead, Samsung and MediaTek are FAR worse. I've heard good things about Freescale's ARM i.MX6 chips as far as openness, but their "newest" offering is a quad Cortex-A9...)

Reverse engineering all of that is a MASSIVELY time consuming effort, and it doesn't help that some of the best tools for reducing that time investment are incredibly expensive - Hex-Rays Decompiler for ARM is a few thousand dollars.

WAT?

https://cyngn.com/blog/its-tim... - They constantly talk about how they're all about an "open OS" and "open Android".

The problem is that their actions are always inconsistent with their talk. While they talk an Open OS, their reaction to Google moving more and more components of AOSP into GMS and abandoning the open-source AOSP variants is:
Take that list of applications and create their own proprietary versions or license them from someone else:
First Focal, and when attempting to use their CLA to obtain dual-licensing rights to Focal failed (due to their CLA fortunately lacking some of the nastiness found in other CLAs like Harmony - not all CLAs are created equal, as Koush learned the hard way with Focal), CameraNext
GalleryNext
EmailNext aka Boxer
Now, Microsoft's suite of proprietary apps, ones which contribute further to the continued dominance of Office by encouraging use of proprietary formats prone to vendor lock-in (Google is, in contrast, pretty good about giving people who want to migrate away their data in open formats - http://en.wikipedia.org/wiki/G... )