I think that now we can see clearly, where ~BadAnalogyGuy has gone to...

How do you propose to practically achieve this "burned" ID?

How can you prevent the attacker from obtaining cards from a different manufacturer who doesn't do this "burning in" and lets the users to set any value in any stored field?

The whole aim of having the cards being "smart" is that they can be equipped with a protected private key that they don't allow to be read from the outside world and that these cards perform cryptographic signing internally, without letting any secret information about performed cryptography out.

That's also why there's so much effort put into making smart cards tamper-evident (see Design principles for Tamper-Resistant Smartcard Processors (1999)) and withstand electromagnetic eavesdropping (see ElectroMagnetic Analysis (EMA): Measures and Counter-measures for Smart Cards) - so that you can't just put a receiver close to them when a transaction is being performed and steal their private key.

As far as I understand, the flaws in various public transit card systems are mostly due to weak implementations of cryptography. Your proposed solution, on the other hand, is completely wide open to attacks, so it's much worse.

Do you really think it's that simple? If it was, there would be no problem.

Your proposed non-smart card solution (as any stored value one) is inherently susceptible to cloning. Anybody with a RFID/NFC reader can pass close to you just once, then produce a card that's an identical copy (from the perspective of the system) of yours. He can then have a few rides at your cost and discard the cloned card or load another individual's captured data onto it so that he can avoid using a particular person's card for too long.

The transport company could see symptoms of duplication (rides by the same customer at the same time observed in different areas), but good luck with distinguishing between the original user and the clone! They'd have to employ careful analysis of riding patterns to isolate the individual who uses cloned cards (assuming that his transport usage patterns are uniform).

For cell towers, there alredy exists such a database:

OpenCellID.org

There are numerous client apps for Android (e.g. Tower Collector) that allow you collect logs of GPS coordinates+visible tower cell IDs and submit these logs to OpenCellID.

It seems that in this case, indeed, Helium would be the byproduct. More specifically, Helium-4 according to the list of important fusion reactions on Wikipedia.

But as you can see from this list, there are several fusion reactions theoretically available for terrestrial use - most produce Helium, but there are also ones that produce isotopes of Beryllium, Tritium, Lithium and even an aneutronic one that produces Carbon.

Nonetheless, the high energy yield of fusion reactions means that, although we'd get immense amounts of energy from them, the amount of Helium created as a byproduct would be negligible, so it would be unlikely to solve our helium shortage problems. Much more likely is that availability of cheap, safe and clean energy from fusion would make it feasible to establish permanent mining colonies on the moon to extract helium from its soil and deliver it to Earth.

Some flaws with your argument and proposal:

1. 1) Windows 8 install will not overwrite the *whole* contents of your disk, only the parts that will be written to during the installation process - that's only as much as the OS needs for its system files. The rest of the disk content will remain untouched.
2. 2) You can always configure your disk wipe tool so that the last passes over the disk will write non random content - e.g. only zeros or ones, and random writes will only be used with preceding intermediate passes. So the disk will end up guaranteed holding non-random, non-incriminating content.
3. 3) The probability of random data creating incriminating stuff you refer to is so negligible that you suffer from larger risk of being hit and killed by a meteorite falling from the sky during the next minute. That is considering that there has only been a single recorded case in human history of a person being killed by a meteorite, and, coming from a 1677 italian manuscript, it cannot be considered a verified fact. In other words, you have much more probable risks to worry about than that.

Statistically speaking, you almost certainly lost more of your lifetime only by thinking about that risk just now, than lost to the actual risk. Please, read this article so that you're more rational about thinking about your risks.

Did you secure the machine against passive electromagnetic emissions eavesdropping when it is powered on? That would require making a full faraday cage out of your CA machine's server room, with a fully self-contained power source (possibly a fossil-fueled powered generator?) within and no communication wires whatsoever crossing the cage's boundary.

Are the private keys of your VPN nodes stored in secure, physically tamper-proof hardware security module devices both resitant to electromagnetic eavesdropping and trusted to not have NSA backdoors, or are they on disks or other non protected memory?

Depending on answers to those questions, your precautions against NSA spying may not be effective at all.

I've tried feedly, and it integrates on-line with Google authentication, asking access to my Reader data:

Then it has seamlessly and practically instantly imported all my feeds, categorized, and all starred items.

If "the cloud" (the whole of it) is gone someday, there also won't be any RSS/ATOM feeds left for you to use your desktop app with.

My point is, "the cloud" being gone isn't very probable - some services like Google Reader may disappear, but if they are popular, others will immediately spot the opportunity to take their place (like presently feedly.com, netvibes.com or newsblur.com), possibly even improving upon these on their way out.

The 95% of business that you had experience with must have been from some bottom of the barrel places, intelectually-wise.

In the three companies I've worked for in the last 12 years (the last two counting > 10k employees), the "track changes" functionality, along with all related stuff (review comments, automated tracked change merging, accept/reject) was in active, constant use as an integrated part of work processes and culture. This extended to all of those companies' partners throughout any collaborative work on any set of documents.

That's not to say that the dreaded document versioning scheme using name suffixes (Document_2012-11-28.docx, etc.) wasn't in use - one practice doesn't exclude the other. It has been a common sight to see multiple document copies with different versions in their names cluttering a shared network drive, SVN directory (!) or a SharePoint document library, even when the underlying store was capable of versioning by itself. Still, lots of those versions were "draft" ones with tracked changes and comments inside them.

Too many software projects/architects have an easy-in, hard-out policy on features. "We can't drop feature X, it's been there for years and some crazy people in siberia still use it". It's ok to drop features on major-cycle releases. Perhaps even necessary for long-term project health.

What for? In the name of what? With such approach, when breaking feature-level backward compatibility, you'd give lots of people (not only "crazy people in Siberia") loads of pain since they would be forced to devise a strategy for getting rid of/replacing those deprecated features.

On the other hand, the model of "old things become outdated, new things emerge, some people stick with the old and are happy, some jump onto the new stuff because it suits them better" works quite well IMHO. It's the natural way the world works. Including nature, civilization, science, technology and so on. Do you imply that there's something wrong with that and we should artificially force some change upon those who are unwilling to take it?

..., due to relatively poor performance, high cost and limited software availability.

Poor performance, high cost? That sounds exactly like systems that big business love the best (judging from looking around me).

Not quite. Without PV, lots of solar enerdy would simply get reflected (assuming that the tents would be made of a bright material - you could even possibly use bare sheet metal roofs that would act like mirrors, reflecting most of that energy with just a fraction of complexity of the system involving PV and Peltier).

With PV, you are deliberately accepting that energy using dark solar panels and have to do something with it.