Yes that wraps it up nicely. The sad thing is I find the less doctored photo looks much better.

If the people who had designed IP6 had just fixed the actual issue and not bolted on stuff nobody needed; we would have been done in the last millennium, and saved a LOT of money.

ARM SoCs are developing incredibly fast. They are 12 months from obliterating current gen consoles (Tegra 5s will have Kepler GPUs). 2-3 years is much less certain, but current road-maps show them easily beating next-gen consoles.
I certainly agree that tablets generally aren't heavily used, and that this dose indicate they are probably in a bubble. I was just claiming that if they where being used, then the replacement cycle would sustain the market without needed an upgrade cycle.

The batteries are sufficient designed obsolescences to prevent that from happening. A heavily used tablet has 1 year possibly 18 months before it is just a digital picture frame.
This years round of consoles is also going to raise the graphics bar substantially, tablets are 2 to 3 years from matching this.

Apart from the stacked CPU/RAM, the Raspberry PI could be sold as an assemble it yourself kit. All the key components are still produced in Asia, and will be for decades unless Wales wants to invest high-billions in new fabs.

We are all frustrated by Apple at one time or another, but that don't justify spreading ridiculous FUD.
Apple has more cash then ANYONE IN HISTORY; security their supply lines is hardly going to be difficult.

That is precisely the problem. You could require that the doctor can only see your medical records in special bunker under the Pentagon, after he has submitted to a full cavity search and provided 20 forms of ID. It doesn't have any bearing on whether the next day he phones up his friendly drugs rep. to say he has an interesting new case. If you share information with someone it have to TRUST them to use it wisely, the is no technology that will help with that.
Sending records securely over the public Internet is a solved problem and most people manage to do this every day. Storing records securely is also solved, though this is less uniformly applied. Trying to give people information (digital or otherwise) and then controlling precisely what they do with that information is quite simply impossible.

I am afraid you are confused.
SSL and safely storing bank documents are jobs for encryption and this works very well. Basically you send a lockable chest to your bank but retain the key, they put your documents into it, close the lock, and send it back. Ensuring that only your key can open it. This is absolutely vital to modern society, but isn't a type of DRM.
DRM usually requires encryption, but also something else. The content producers send their content in a locked box and then try and send the key to your computer in a way where the computer can use it open the box and play back the content but you can't use it to open the box and take the content out. This is obviously logically impossible, which is why you are always hearing of DRM schemes being broken just to watch a film (conversely if you could break a modern encryption system you could literally steal all the money in every bank in the world).
So logically you can't actually implement DRM in closed source software, but with sufficient obfuscation you can get close (Intel literally burns some of the key into a special chip on your motherboard which makes finding it extremely hard). If you are open about what you code is and dose, that includes telling people where you hare trying to hide the key, making the game of hide and seek a bit shorter.

Look at it as a valuable opportunity. First you get paid to train him on-top of the ongoing development whilst he gets up to speed.
Then if he is no good (or you aren't a very good trainer) then you haven't lost anything and they will revert to using you for ongoing development.
Alternatively if he picks it up well, then you will have a good working relationship with a competent and trained professional who fully understands your preferred coding practices, and who you happen to know is still on a rock-bottom contract that he agreed when he had no experience or training. Simply higher him away and grow your consulting business.

The guy who invented the Oculus started out by giving simple instructions to build your own:
http://projects.ict.usc.edu/mxr/open-source/fov2go/

A smart phone and some 35mm slide 3D glasses gives you a very compelling experience.

This really is superb. Has a really nice Android client as well as the web interface.

A good video card is connected to your CPU via a 32GB/s bus. Either you have a very good network, are wasting your graphics card, or you aren't going to get anything close to network transparency.

Costs aren't only the license fees paid (and this is operating outside any copyright territory so licences fees would be extremely prohibitive to enforce anyway).

The biggest cost of Windows/OS:X is that can't make changes. A satellite may well have hard real-time requirements or require other kernel changes that exist for Linux but not for closed source general purpose OSs.

Against who? Anyone who can field anything that could even shoot in the general direction of a single F-22 also have nukes.

Passwords should (and usually are) stored as hashes which means you can very quickly hash the user's entry and compare if it is exactly the same as the password, but by design can't infer any other details about the password if the entry is wrong.

Anything that allows you to compare how 'close' an entry is to the users current password is obviously makes guessing that password far easier.

If your passwords are securely salted and hashed then storing additional old entries shouldn't lower security, and as you say ensures that the user can't reuse a password precisely, but any minor change to the password with result in a completely unrelated hash.