I've found that most of the time the only permission I really need to deny is the ability to access the internet. Since Android has iptables that's easy, and there are front ends (I like AFWall+) if you don't want to use a shell script for it. The "Android Tuner" app can also apparently manage permissions, using the Xposed framework.

If a battery doesn't come charged and can't be recharged, it's not much use to anyone. Batteries don't have to be rechargeable, but if they aren't they must be sold charged. The "batteries" in the article Eravnrekaree described wouldn't come charged, and couldn't be charged without refueling. While refueling might be a possibility, that would require all the fuel components to have a long shelf life. Since the issue is that the fuel components have such a short shelf life that they can't even be successfully shipped to consumers that's a bit of a problem.

This is a fuel cell, not a battery. It can't be recharged without refueling it. The enzymes are probably what breaks down, so you'd need to put more in. Since they break down rapidly (as most enzymes do) that means making them locally. You can't just plug these into the wall to recharge them, you have to empty and refuel them.

It likely is at least partly an attempt to lower prices. India is developing the weapons and some other systems for the PMF, and is paying 35% of the cost for the plane's development. They can threaten to lower that 35% and do more of the development at HAL (in-house).

Essentially it seems to be a problem with the entire concept of "fifth generation" fighters. The idea that you can have useful all-aspect stealth without sacrificing performance in other areas is ridiculous with current technology. The PAK FA (Russian version) sacrifices stealth for performance, the HAL/PMF (Indian version) changes the avionics and tries to add more stealth features. No 5th gen fighter has lived up to its manufacturer's promises of "invisible, supermanuverable ultra plane!!! At a reasonable price!!!" They're all over budget with worse performance than promised. The F-35 is an un-stealthy brick, in the variants that actually work. It also costs as much as an F-22, if not more. The F-22 was cancelled because it cost too much. The PAK FA is a 4th gen fighter with some front-aspect stealth tacked on, and better avionics, including anti-stealth radar. It's probably also going to be the cheapest of the lot.

Adam Smith's "Freely Competitive Market" is probably the best term overall.

The "easy" bit is not about creating the files, but about finding an upper bound for n to get a collision probability of 1. Sorry for phrasing that poorly.

The problem is how government contracts work.
If I, as a private citizen, hire a plumber to replace my bathtub, that plumber provides an estimate, tells me the hourly rate and the value of the parts, and I does the work. If the plumber doesn't replace the bathtub and instead installs a sink, I can sue to recover the money (and damages.) If the plumber provides a wildly inaccurate estimate I can also sue.
If a government contractor provides a wildly inaccurate estimate for a new fighter, and delivers a sack of bricks strapped to a jet engine instead of a fighter, the government gives them more money and time.

Simple fix:
Government publishes requirements. Contractors bid with time/cost estimates. If contractors go over budget, they are liable for the overages. If contractors don't deliver, they must give the government all partially completed work (plans, etc) and pay a penalty proportional to the amount of unfinished work. Contractors must place a bond in addition to a bid, to cover a portion of any overages that may occur. Any changes to the requirements allow for a new bidding process, and the existing contractor may hand over all existing work and withdraw at no penalty if the requirements are changed.
That would provide a very strong incentive to give realistic initial bids, since overages will cut directly into profits. It provides an incentive for the government to finalize requirements before opening bidding. Etc. Initial cost estimates would be higher, but final costs would likely be the same or lower. Since it would allow a better cost/benefit analysis before starting projects it would benefit taxpayers.

It will never happen, of course.

Image deduplication is a much harder problem than you (and many of the posters here) seem to think. It's certainly not terrifically hard, but it's not as simple as comparing file size and content hash.
What if the image was resized?
What if a watermark was added?
What if the image was saved in a different format, eg PNG and JPEG?
What if the image had its lighting curves adjusted?
etc.
You may still want to find these duplicates, but size/hash methods will fail.
The findimagedupes tool works well in most of these cases, most of the shell scripts proposed here won't.

An "easy" way to find a guaranteed collision is to simply create more files than 2^(bits in hash). So a bit over 3.4 x 10^38 files for MD5 and you'll get collisions on all subsequent files.
This should be obvious, but just in case:
If you can ask an oracle for a file with a hash not in a list of hashes, then you can keep adding the new files to the list. An n-bit hash can have 2^n unique values, so after 2^n files created no new value can possibly be added to the list.

I've used <a href="http://www.duplicate-finder.com/photo.html">Duplicate Photo Finder</a> for a while, but VisiPics looks like it's probably better. That said, I have tested and Duplicate Photo Finder worked for me with WINE.

Yes, thus the "or similar" in my OP. I know American Express also offers a similar service, and there are numerous brands of prepaid card. Sadly not every bank offers such temporary numbers, so the added hassle of a prepaid card can be worth it to some people for the extra safety.

Or just track the phones of everyone who works on Wall St, and get the same data more easily.

That's why I recommend Diceware. Strong entropy, big alphabet, easy to remember. Much better than trying to pick randomly, but with all the same benefits otherwise.

Well, it's now +5, Insightful.

I've found that screen readers provide a good quick test for many security systems: if it works with screen readers, then it's probably not just an obfuscatory scam. If it breaks them, it's almost certainly useless for real security. It also provides a good test for usability: if your system breaks when a disabled person tries to use it, your system probably isn't that usable by non-disabled people either, and it's certainly not robust.