I'm reminded of fractal encryption done about 10-20 years ago. Everyone pushing it said it was 100% secure and unbreakable by mortal men. This encryption system seems to be a lot like fractals.

BitCoins are tracable forever. Those block chains never disappear. However, if one possesses a bunch of tainted coins in a wallet, and hands the wallet to someone else, in exchange for some other commodity, that can effectively hide where the coins came from.

Isn't the Yuan pinned to the dollar right now, so if China stopped accepting USD, it would only bite them, especially their debt holdings?

What is really worrisome is if China gets oil trade to move to a basket system and off the US dollar. Then things will get really pear-shaped, really quickly.

China isn't really Communist, nor communist. It definitely is a capitalist society with some vestiges of a command economy left, with the government having a voice as a part of any companies and ventures on their soil.

(All and all, that's not a bad thing... I wonder how better off the US would be if a FTC or SEC official had a say in all board meetings.)

It is a different culture. Some of what they have is good (they invested in core infrastructure while here in the US, cars were crushed, and China actually is trying to move to a decent UHC system), but some isn't.

What really needs to happen is separation of duties and storing the hashes the same way companies store private keys used for signing... a physically secure, hardened appliance with a limited interface out. Backups are done to a USB port physically on the appliance, and the data never is exposed on the network, only calls to use it.

We can use bcrypt, initial hashes, and such, but it might be better to consider a different protection method -- keep the data separate and physically isolated from everything else... i.e. put the hashes on their own separate box so that even if an attacker manages to get everything on the network, they only can access the stored hashes by trying user/password combos... and with a sane lockout method on the device with exponentially increasing lockouts, it is easy to prevent brute forcing an account.

What would be interesting is if the groups of devices could have their own individual WPA2 encryption key. That way, one wireless segment can use multiple keys in PSK mode. This way, if a smartphone is lost or changed out, just one password needs deleted rather than rekeying every device on the subnet.

Nail, head, hit. Even if someone had a device that had obvious security failings that were unfixable, the EULA/TOS by opening it up and turning it on would ensure that lawsuits would not proceed (either by forcing arbitration, or just a clause stating that it isn't their fault, no matter what.)

I have no interest in IoT. Realistically, what has to be on the Internet all the time and take commands? Why do we need to give devices full exposure if it isn't needed?

If someone wants status messages from devices, why not just have devices communicate via BlueTooth to a log box, and said log box present the data to where it needs to go? This would force an intruder to have to hack that core box, then use BlueTooth weaknesses to jump to actual devices, rather than just run scripts blindly and hope someone's widget shows up.

It would take some thought on layout to have a system that works, where if a motorcycle is in a blind spot (and sometimes they will drive on the breakdown lane to pass), it will show it.

The idea would be a very useful advance, but it would have to be tuned to be able to have information coming in at a glance so one doesn't have to take the time to notice that there is something coming in from the side or whatnot.

Maybe one compromise is on the road already. Freightliner Sprinter vans have a LED that lights up on the mirror when something is in a blind spot, as well as a decent camera arrangement when backing up.

If I had to choose between cameras or mirrors, I prefer both (since cameras add useful information, especially backup cameras), but I'd take mirrors, just because I can gauge depth in them.

I stand corrected... Your model is far better. The intent was to give an example of what core protocols need to be improved to handle modern attacks.

There are jobs out there. However, the days of 2008 where one could put out 99 cent fart apps and rake in the cash, or the days of 2012 where one could put out a free-to-play, pay-to-win game are now behind us. The market is saturated.

But there are markets where things are not like that and niches can be made. Embedded programming will be work that requires a real expert, just because each application (and hardware device) is different. A microcontroller for a RV's A/C will require a completely different set of code than a microcontroller that monitors a building's HVAC system at multiple locations. One size does not fit all in the embedded arena, so "commodity development" (i.e. offshoring) will be more expensive than hiring people domestically since there is new ground to be broken.

I'm sure the next bubble is going to be security. SSL/TLS need to be reworked to support multiple root CAs in case one is compromised. That way, if two CAs have no clue about a cert, but one CA vets it, this can raise a red flag. Security isn't something one can do on the cheap. This needs real expertise, and more than just reading "The Cookoo's Egg" and calling oneself a "security professional". White/black hat hacking is going to be an important part of things, and this, yet again, isn't something that comes cheap.

Then there is the fact that there are international issues now. Just last year, people were content to get all their hardware from one country, their software from another. Now, nations want to pack their own parachutes and develop their security in house, and not rely solely on the word of other countries that the smartphones or other items don't come bristling with backdoors and kill switches. So, there will be duplication of effort that wasn't around just a year ago.

On this note, governments will become a bigger client for developers. They will want their own infrastructures, social media sites, and many other items. This will be where the money lies for upcoming companies because governments have deep pockets, and the ability to work on things even if not an immediate profit is obtainable.

Then there are items to be addressed that would make money, infrastructure wise. Here in the US, there is plenty of LAN bandwidth to go around. WAN bandwidth is expensive. Someone making an infrared laser routing system and other means (microwave relay) to create a mesh network would likely make a lot of money, especially if it has innate encryption that consists of more than "trust us, the glowing 'it is encrypted' LED ensures 100% security" flim-flam.

Finally, the model of advertising revenue is going to hit a wall pretty soon. Once ad-supported sites start selling to advertisers every click, mouse wiggle, and keyboard stroke that subscribers do, or even worse, demand intrusive spyware be installed on subscribers' machines, then there will be no more they can sell to the advertisers. Once that happens, the bubble will collapse. Who knows from there. "Free" E-mail may become a thing of the past, perhaps even Google or other search engine use would require micropayments.

All and all, there are still niches to be filled. One just can't follow the herd all day long and expect to be able to get to fresh grass.

From the picture, it is even worse: "5V current ranges plus USB PD."

Realistically, how many amps is thing thing going to allow? 100 watts means that those wires will handle 20 amps, and handle this factoring in voltage drops, especially with the skinny cables and tiny connectors.

Realistically, I wish the USB-C connector could start at 5 volts but negotiate to 12 volts to offset voltage drop. Higher voltages would help more, but then there will be electrocution issues past 12-24 volts depending on a lot of factors. It would be nice to push 48 volts through two wires dedicated to power because that would easily allow 100 watts... but would one trust the bottom-basement Chinese electronic junk with such a high voltage that a short or a misrouted connection doesn't fry other connections or shock the user? I wouldn't.

Even at 12 volts, 10 amps through those small wires is asking a lot, so realistically, 100 watts of power is a joke. I'd expect at most 20-25 watts unless magically the USB consortium is able to spec and deliver on superconductive wires or goes to thicker cables and connectors.

However, any improvements from the usual 2.1 amps through current USB connectors is definitely a step in the right direction.

Here is how to do it. Remove caps on H-1B labor.

However, every H-1B coming in will require a payroll tax to be paid that is the difference between the H-1B's salary and either an average salary for a professional in that field or the median US income, whichever is higher. That way, if a place hired someone for $20,000.00/year, the company will have to pay a tax of $31,017.00 at the minimum ($51010/year was the median income in 2012.)

If a company needs specialized labor, they can get it and it won't cost them much relatively. However, this will put a stop to flooding a market with H-1Bs just to drive down wages, and the taxes obtained will help offset the spending power lost by US workers.

In the AIX world, compression does come into handy. Probably the ideal place are applications like low-volume Splunk indexers that end up getting handed redundant data (syslog entries, performance counters), so even the in-RAM read/write disk cache can be compressed.

Then there are those Web servers that have something oddball internally, but have to remain. Someone wants an internal wiki which nobody maintains, so that one is ideal for turning compression to max and just forgetting about.

Of course, there are VMs that you don't want compression on. The instance that does compiler builds comes to mind. Similar with very heavy I/O tasks like high-volume RDMS machines.

This isn't a completely new feature. AIX has had this since at least version 7.1.

It is useful for virtualization. VMs that don't really do much (a tertiary DNS or a rarely used DB server for example) can still be kept in RAM, but the RAM they use minimized so other tasks/VMs have it available.

Of course the downside is if all the VMs decide to go for maximum activity at the same time. On AIX, this will peg the CPU, and cause swapping (especially if the compression ratio is set high.) Not sure what this will do on Linux, likely add significantly to CPU load.

It is only going to backfire. If people realize that their files are being scanned and access blocked because they might be looked at, Dropbox will either become a ghost town or people will just grab a copy of TrueCrypt and start encrypting everything, and then everything goes dark in regards of scanning. If DB blocks encryption, then people will just give them the middle finger and move to GDrive which offers a lot more storage for the unit of currency.

The last thing Dropbox needs is bad publicity. Google is nipping on their heels with very inexpensive storage. Google's app may not be as polished as DB's for photo uploads on iOS, but it is still usable.