"With 1828 ‘seeders’ and just 76 ‘leechers’, True is a fair distance behind the 100th most popular torrent overall: PC game Far Cry 4, which has 1604 ‘seeders’ plus 1260 ‘leechers’."

Keep in mind that:
1) Once a "leecher" finishes downloading, they become a "seeder"
2) Nearly all clients will stop being a "seeder" once a predetermined share ratio is reached

Considering a typical music album is FAR smaller than a game (probably 100-200MB at most, depending on bitrate for encoding, vs. multiple gigabytes for a game - FC4 is over 10GB I'd guess, I can't view TPB to check from my current location), "leechers" become "seeders" far faster, and "seeders" disconnect from the torrent due to hitting the share ratio cap of the client (kTorrent defaults to 1.30 for example) far faster.

If you read the article, the kid already has a suspension on file for daring to bring http://www.amazon.com/The-Book... to school.

Apparently because it had an illustration of a pregnant lady (I'm assuming, since it's a children's book, an appropriately clothed one...)

"Nobody has EVER found that radioactive fly ash despite looking since the 1970s."

http://www.world-nuclear-news....

Nobody has EVER found what the Chinese are developing the capability to MINE?

Possibilities I see are:
1) The media itself is able to withstand many "purge cycles" using acid to dissolve the calcification. I've had good results with citric acid to remove humidifier scale - the problem is that at least with my humidifier, the acid also attacks the wick so eventually the wick falls apart. A plastic mesh wick might be able to withstand this abuse.
2) The vastly increased surface area of this approach might significantly reduce the airflow needed, and especially reduce the backpressure encountered by any air circulation mechanism.

That said, it's still just a glorified swamp cooler so it won't work in many areas. In most of the areas it WOULD work, water is a precious resource.

Yeah. That's why I said that Google did things right as far as I can tell with Keyboard. From talking to various people, the AOSP keyboard gains the nifty "Google" features if you add a few native libraries. So rather than clone-and-own with the original version being left to rot, there's a "plugin" architecture for the Google integration.

If Google had done the same with the other apps that have been left to rot, I don't think you'd be seeing people as concerned about the future of AOSP. But when multiple components of AOSP appear to have been abandoned, and the quality control of GMS-free AOSP has clearly gone way downhill along with that, people start getting nervous.

That said, Kirt McMaster's ranting about the "tyranny of Google" is going way overboard. The truth is, so far Cyngn has done no better than Google in this regard. First they attempted to obtain commercial dual-licensing rights to Focal forcefully using their CLA (fortunately, the CLA doesn't allow them to do that for a GPL app), then they responded to Google moving Gallery and Camera towards a closed-source approach by... Creating their own closed-source Gallery and Camera! Kirt (and the rest of cyngn leadership) are seriously delusional...

The only thing I use Vbox for is to perform firmware updates of devices where the manufacturer decided to only allow updating from Windows

Pretty much:
DJI Phantom 2 Vision+
Sony digital cameras

As long as USB passthrough works I'm golden.

International or USA GS3?

FYI, most of the maintainers for the International version (I9300) want to see Cyngn fail because the leadership screwed one of them (I avoid using the term "us" in this particular instance since while I did Exynos4 work, I never did I9300 work) royally with the Focal relicensing fiasco.

Leadership did make us look like fools by marking N7000 and I9100 as "stable" to inflate the "stable" user counts for CM10.1 to make themselves look better to investors. (Prior to that, a device only got a "stable" build if the maintainers signed off on it, so if a device was mistakenly declared "stable" it was the maintainer who screwed up.)

Um, by definition they're a start-up. They have only been established as a company for approximately two years, with only around 1.25 of those in public existence.

"for a while now" - less than a year for OnePlus One, just a tiny bit over a year for the Oppo N1 - which they completely failed to continue updating by not deploying KitKat until after Lollipop was released.

Umm... You read the first sentence of my post and completely ignored the rest.

Messaging?
Launcher?
Calendar?
Email? (AOSP version of the app crashes when the IMAP server does not have calendar info - WTF?)
Music player?
Browser? How did something that FCs on Settings->General make it out the door?

These are all cases of applications within AOSP where Google started work on a proprietary version of the app and abandoned work on the open-source component. With the exception of Browser, the move was not due to security reasons.

I can understand the desire to integrate Google's services, but the fact that inevitably the open-source non-integrated application gets abandoned is where all of this "AOSP is becoming more closed" sentiment comes from.

At least Google seems to have done it right with Keyboard, where IIRC (I can't check now, so I could be wrong in my memory of this) the AOSP version gains all of the features of the GMS version if a certain native library from GMS is present, but gracefully degrades by simply not offering certain features if it's not present, with the remainder of the keyboard app behaving identically to the GMS variant.

Yeah. I think Kirt's ranting about the "tyranny of Google" is BS. Although I can sort of understand where they MIGHT be coming from after the Cornerstone mess - but that was probably a no-win situation for everyone involved.

That said, I fully agree with the people that are seeing a slow move towards AOSP becoming more and more closed source. One by one, the following happens:
Google wants to integrate GMS further with a given app (no problem here)
Google forks said app to add GMS integration (no problem here, although moving it to some sort of plugin-style approach might work better as it avoids what has proven to be the inevitable result)
Google stops development on the open-source component that the GMS-integrated component was forked from within AOSP, leaving it to rot. This annoys people and is where the perception that Google is slowly "closing down" AOSP comes from.

There's also the fact that AOSP's strict scope-limiting to Nexus devices only tends to cause people to not bother upstreaming to it - https://android-review.googles... for example

Also annoying is the fact that Google still builds AOSP using prebuilt kernel images, which often depend on toolchains deleted from AOSP. Also, AOSP uses kernel headers that just happen to match the actual kernel itself in structural organization but have different names, so Bad Things happen if you try to build AOSP against actual kernel headers now:
https://github.com/omnirom/and...
and
https://github.com/omnirom/and...

AOSP?
Omni? (I'm biased here - the history is that it was founded by a number of Cyanogenmod maintainers that left as a result of the Focal fiasco. However I'll be honest, a lot of the developers have burned out and as a result we're really behind on a lot of things...)
Some of the Omni guys along with people from EOS and Slim are talking about forming a project that is strictly limited in focus to hardware support. Some of the ex-Gummy guys already formed such a project (AOD) but a number of people (including myself) are holding back because they kind of rushed things - starting to code without planning the project, while the challenge of such a project is planning and organization/politics. Screw up the planning and organization/politics and best case is that you wind up "just another ROM".

AOKP is dead due to Cyngn hiring Roman
Same for ChameleonOS

As a former Cyanogenmod maintainer (I left the project as a result of the Focal fiasco), I'm 90% certain no officially supported device ever used flash memory for swap.

The closest I can think of was that some devices used zram (which Google added official support for in KitKat IIRC...) - zram was pseudo-swap where the system would swap into "compressed" RAM.

Yeah, that's the part that doesn't make sense to me. Why invest in Cyngn 6 months after you killed off every Android device in your portfolio?

The problem is that unlike on the desktop, the display subsystem on many devices is more than just the GPU. Also, the subcomponents of the display subsystem interact with other subcomponents in such a way that if an OEM makes changes, those changes ripple throughout the whole subsystem.

The end result is that if one component of the display subsystem (and this includes the camera, since it has hooks into the display subsystem to handle preview and such) is closed-source and deviates from the reference implementation for that platform, it's a nightmare of reverse engineering to get the other components open-sourced.

That's why, for example, most of the original CyanogenMod maintainers for Samsung Exynos4 devices ditched the platform. Samsung had reference source at Insignal, but it was vastly outdated (Their "ICS" source had significant architectural components that dated back to Gingerbread) and didn't even remotely match what ANY OEM used (Samsung's own handsets did NOT use the "gingerbready" components referenced previously). Getting that source usable with any real device was a nightmare. The kernel wasn't the issue, it was all of the HAL stuff - hwcomposer/gralloc/etc - especially hwcomposer.

Cyngn (the abbreviation I use to refer to Cyanogen Inc) does have access to all the proprietary goodies that should allow them to support a device very well, but so far, their track record has been to do no better than the OEMs they claim to be trying to provide an alternative.
Oppo N1 - didn't receive KitKat OTA until November 2014, 1 year after KK was released. Epic fail. Yeah, there were CM11 nightlies, but Cyngn staff will aggressively remind you that community builds (including CM nightlies) are NOT supported
OnePlus One - Their current state is "average" - many OEMs upated to Lollipop within a month of Google releasing it, Cyngn is at 3 months and counting.

Actually the banks have been pushing for a transition to EMV, but merchants are resisting it right and left for various reasons.

Watch all the merchants change their tune in October when all of the banks institute a liability shift to the merchant for non-EMV transactions (magstripe).