Require OEMs to have >80% of devices sold in the last 2 years capable of running the most recent version of Android within 3 months of release.

Racked at the house...
Dell C6100, 4x { 2x L5639, 32GB ram }
Dell C1100, 2x L5639, 48GB ram
Dell Powerconnect 5324 with a permanent fan error because I unplugged it, the noisy bastard.
Ubiquiti ERL-3

Maybe half full of SATAs, most of which are spun down. Further sliced into VMs because I like to play around with KVM/ESXi. Mostly used for ADC, media serving, local backup, test build environments, autodeployment script tests, etc. It'll draw 6-8A @110V easy with everything spinning max load, but it usually idles around 1.2-2A as I only wake 3 of the C6100 sleds on-demand. Config exactly mirrors my colo, which pays for both, but is not my job.

Workstation's notable components are the G530, GTX460, a cheap-as-it-comes asus MB, and 3x displays.
Half a dozen or so ARM SBCs (rpi, udoo, beaglexM, etc) doing menial things like RTP audio endpoints, ethernet-attached GPIO, openelec.

That sounds amazingly convoluted and backward, but I don't doubt that's how it works.

However, if Qualcomm sells Samsung a part without licenses and separately licenses/sells/supports the driver software without licenses (I am dangerously assuming Samsung didn't write their own), conditionally saying the driver cannot be used with the part because that would be in violation of the patent, then Samsung uses them together and distributes it, why would not Qualcomm go to town on Samsung in the spirit of cover-your-ass? They'd have to be in collusion to commit patent fraud. But if Qualcomm licensed the driver to Samsung for use with the part, the two together seem like patent exhaustion would have to apply, unless, like you said, Samsung assumed responsibility for paying Qualcomm's patent royalties and fees. Samsung wouldn't be using the patent directly, Samsung would be using a part that uses the patent.

I guess fundamentally I am misapprehending how you can somehow sell a product or combination of products as fit for purpose that are covered by patents and yet not assume patent license liability. Thanks for your insight on how this whole thing works.

Ok, I think I now see where you are coming from here, as well as AC below you. Since Qualcomm didn't have a license, Samsung couldn't have triggered patent exhaustion because Qualcomm never had a license to exhaust. It's then open to court interpretation whether or not Samsung should be liable for use of the patent.

The difference between this case and Quanta v. LG (2008) is that Qualcomm didn't have a patent license to sell their part. Even if Samsung is not practicing the patent itself, they might still be liable. This is then the part that confuses me: if Qualcomm acquires a license for historical sales, wouldn't Samsung again be protected from infringement?

Thank you all for straightening out my confusion.

I'm specifically referencing exhaustion/first sale doctrine. I believe that should apply, but as you pointed out, I could be wrong.

Just curious, has anyone done a gpu power/performance comparison of Imagination Technology's powervr and Nvidia's tegra platforms recently? I don't know that they would clean up by licensing their IP out; it seems to me Nvidia stuff has always been more performance focused than power conscious which is something that is extremely hard to sell in the mobile segment.

I am not a lawyer, but I find it hard to believe Samsung is violating any of Nvidia's patents directly by using Qualcomm's Snapdragon 801 and 805 in a product. They received the part and associated driver software from QCOM as a final product and all components and features therein are protected from patent violations. Just like you can't be sued for violating Nvidia's patents by using an AMD GPU which has Nvidia-patented features in your PC, Samsung is protected by purchasing the part from QCOM. Nvidia could block further sales of the Snapdragon CPU to Samsung, but not sales of derived products; even though to to the end consumer it amounts to the same thing. So unless Samsung is violating their agreement with QCOM by enabling features they didn't license from QCOM, NV can't touch them here.

Similar deal with Exynos (Samsung's SOC) since it licenses the IP involved directly from ARM and Imagination Technologies (Mali and PowerVR GPUs respectively). Unless Samsung's legal team is collectively idiots and/or assholes, they should be protected by their upstream licensing agreements.

Then again, NV is never going to sue ARM because they would be in a seriously shitty position to renew *their* ARM licenses (if ARM didn't just terminate them on the spot) and then ARM would laugh all the way to the bank about who isn't shipping products.

Based on that, it's my opinion that Samsung shouldn't be involved in this lawsuit and Nvidia just pulled them in because that's where the money is.

FMIQ (as implemented in the imgSeek server) is pretty good at detecting everything but crops, and that was 5-6 years ago when I last played with it. It likely has no problems with them now. This is a reasonably well solved problem.

The only part I care about is being able to take the interchangeable radio/baseband unit out of model A on carrier X and put it in model B and continue my service on X with them none the wiser, or even remove the radio entirely and operate without cellular features. Maybe even swap in a part97 radio instead. Ok, that's asking for the moon, but I can dream.

From the way the article reads, it's more like everyone else made their save vs spell... Or perhaps that he lost his save vs PPDM. Seems like after he made his initial critical mistake (allowing investment options to bypass his majority ownership), he couldn't recover without just divesting himself from TSR and starting over before the flagship D&D product was born, which, as a primary creator, he might have been able to pull off.
The behind closed doors shenanigans, manipulations and backstabbery are about right for any D&D game I've ever been in.

They probably have regression test cases to make sure bugs in the source are preserved. Wouldn't want to spoil the original experience...

Or more established/full featured, openvz, xen pv, lxc, cgroups/namespaces, and friends. I think linux (the kernel) already has the tools necessary to do task prioritization like the article requests.

Maybe.

I can design a shed and oversee or perform its construction. That does not make me an architect.
I can design and build a model car with a little spring-and-gear engine. That does not make me a mechanical engineer.
I can design and build a little circuit "piano" with pushbuttons and a 555 timer. That does not make me an electrical engineer.

I can lead a team to build proposals; reasonably accurately gauge task complexity; predict completion dates and manpower requirements; define deliverables and release criteria; control defect introduction through manual and automated unit and system tasting; build accurate development, maintenance, and operation documentation; and actually write, debug, and review efficient, best-practices-compliant code for custom software exceeding 100k LOC of new code or modifications per contract, not counting software packages integrated from other ISVs, capable of reliably processing millions of financial and medical transactions per day. Does that make me a software engineer?

Your cellphone is just a brick without software and firmware designed by thousands of developers with millions of hours of dev time, a significant portion of it in critical areas where flaws can result in physical damage, horrible performance or just plain crashing. Your car engine is controlled by a PCM driven by software, weighing in with probably multiple megabytes of code and lookup tables, designed to increase your fuel efficiency beyond what you could get with a mechanical system alone, where flaws will very likely cause serious mechanical and safety problems. The ridiculously convoluted system of wires, routers, switches, and servers that got this message from me to you is all dependent on software largely written by some team or other of developers in a controlled and systematic process and certainly not a million monkeys at random.

Software engineering is real. Many of them are even licensed as professional engineers now. Your conception of who they are, what they do, and their importance to your way of life appears to be flawed.

Of all the explanations given so far, AC is the only one that has hit the crux of the matter. I don't agree with his assessment of runtime/tooling as there is middleware which will enable porting with relative ease between platforms. But it's absolutely true that if the garden owner tosses you out, your options are few in number, especially as a small developer and they can do so for any reason they want. If the platform owner changes the way part of their platform works and it completely breaks your application (android 4.4.2 anyone?) you must quickly adapt or (get bad reviews and) die--hobbiests don't have time to drop everything and fix their app and if my understanding is correct, there is no expectation of long term (>2 yr) platform API stability (in specific example, push notifications on android).

Mobile devs are stuck with three evil giants who are conflicted on whether they want you to fill their garden with useful tools or toss you because you've stepped into their safety zone.

As far as development costs go, that is absolutely rock-bottom cheap. Indy mobile developers don't pay 1.5k+ USD for a development-only unit with in-system debugging capability. They don't pay 1k+ per year, per seat for the tool suite. They don't pay 10k+ for external auditing and verification for major releases. It costs nothing to load unsigned apks on android. It costs nothing to load a binary from Xcode onto a target iOS device. The only thing that costs money is development equipment, which is less than 600 USD each for all major mobile platforms, and distribution, the 100$/yr being discussed.

500 per year for an entire team is laughable if you produce one good app with 500 sales (or donations) per year at a dollar each. Get four friends with the same hobby as you. Buy your release licenses as a club. Hell, go to your mom with the app you wrote and have her play around with it. I bet if she likes it she'll just give you the 100 USD to buy an iOS distribution license.