Same reason why plumbers, electricians, HVAC workers, and vend a goat repairmen don't get offshored... it just costs too much to grab people off the boat, train them in US standards [1], then them licensed in the specific state.

Here is what I don't get: What exactly is a "solar job"?

First, there is the actual placing of PV panels. This is just physical moving of the object, dropping it into place and bolting it down, perhaps making sure the single or double-axis controller is calibrated.

Second, and this is the most important: Electrician work. PV panels, wiring to proper code, not getting high voltage across the nipples, getting power from the PV panels to the inverter or the battery charge controller (depending on if the person wants an on grid or off grid setup.)

Third is architecture and placing panels. Will the panels be too heavy for a roof, are they facing south, etc.

All these skills are not really just "solar skills", but items used from other occupations.

[1]: Since the US was the first country to go electric, the standards in place are primitive. Tesla's three-phase system helped things, and 120VAC was good for the time, but as metals and materials improved, 240VAC is a better standard overall because it allows for thinner gauge wires.

I like having all of the above:

All disks encrypted, which is mainly so the meth-head who breaks in and grabs the hardware doesn't have access to the data. Hardware can be claimed on insurance. Data opens up blackmail, extortion, and many other avenues.

Encrypted VMs as a way to isolate programs from each other, where I can keep my Quicken/QuickBooks in a VM, move it between computers when needed. Backup? Burn the .vmdk or the .vhdx to a BD-R disk.

File based encrypted volumes as a way of stashing client projects, as well as stashing document backups by date before burning to CD.

Of course, it would be nice to have encrypted archives as well, when one doesn't need to hide the length of the files. PGP Zip covers this, but it would be nice to have a higher level of compression like xz, bzip2, or LZMA, as well as the ability to add an ECC record (similar to WinRAR), so if an archive is damaged, it has a chance of being able to be completely repaired.

My ideal would be to have storage and compute nodes interchangeable, and use something like vMotion to move VMs back and forth between local nodes and cloud based nodes. For example, if I have some VMs that do nothing most of the time (a VM that does quarterly/annual reports, for example), it can sit on a remote cloud provider until it needs to be used heavily... then moved to local computer/storage nodes. Once the reports are done, it gets shoved back to the cloud again.

On the storage side, async storage would be useful, especially for volumes that have critical data. At least it is a form of backup, even though there were still I/O transactions still in flight when things went down.

This functionality was mentioned in Windows Server 2016, so when the preview comes out, it might be interesting to see what MS has improved in this department.

Of course, this is assuming security issues are a solved problem... which isn't the case in real life.

The problem is that with those environments, you could find a way to export your data from the locked down computer somehow... even if you turned your database tuples into a very nasty .CSV file and had some programmers import every table back into another format.

There is no physical access to the data in the cloud, and generally few companies will back up their data stored in the cloud... of if they do, the backups are stored in the cloud. So, in theory, all it takes is a bad guy to do a purge on the provider's side... and the cloud provider's client is now out of business.

Without physical possession, how can one actually say who is doing what with the data, and where it is located? For example, what keeps a US cloud provider from outsourcing capacity to a European provider... which outsources to a provider in a hostile country to the US.

At least with an IBM mainframe, you knew where your data was and could back it up. With cloud computing, all your critical business data can be destroyed or corrupted and nobody would be able to tell until it is too late.

I remember seeing one OSS company working on a generic API that works with whatever one's cloud provider of choice, so it doesn't matter what is on the backend, one can spin up a VM, provision it, do what is needed, then kill it. For storage, any application can use the API, and it deals with whatever cloud storage provider one is using (S3, Azure.)

I do worry about cloud computing as a whole for the open aspect, as well as the security aspect... just for the fact that once you lose physical access, you only have someone's word that their security is up to snuff.

Of course, once people are locked into a specific cloud provider, it becomes quite hard to move to a different provider or back to in-house. That is a concern.

With SCOM, SCCM, and in a Hyper-V world, SCVMM, it isn't bad. In fact, Windows Server 2012 and newer ship with Server Core on by default (not hard to get the full UI if you want), because one is expected to use management tools and PowerShell.

No UI (Server Core) is useful. One less subsystem that a bad guy can attack.

Same boat here. I did my programming for CS, earned my bones there.

These days, it is mainly shell scripts, but I do consult the camel if something more sophisticated is needed. If I had to do web stuff, I'll just probably go with mod_perl, although it might be better to do a more "web-centered" language for a larger project.

This is a double-edged sword. Once people are locked out of their cars, what is to prevent automakers from charging for the ability to go above 45, to go on country roads, to go outside of a state, have more stations on the radio, allow full use of the speakers, allow use of the sunroof, or many other features?

It would be trivial for automakers to license these features just to the owner... so the used car market would dry up, just like it did with used game sales and the fact that most content is from DLC, not on the game disc. Do we want to see automakers demand $5000 from the next person you sell your car to in order to have a software license to start the vehicle?

Look at the console market and how gamers are charged for virtually everything. Would people want that in their cars where they have to pay $100 a month in order to keep access to their climate control and radio? Remember, the car will come with a EULA and those have stood quite well in courts.

IMHO, the Google/Android security team is doing a good job. I have never gotten stung on the Play Store, and I've not encountered "fishy" apps (ones that have horror stories in the reviews) that didn't get taken down quickly in a long time.

Of course, I am still partial to XPrivacy, because it doesn't deny an app permissions... it just feeds it BS. However, I do think Google has kept with the times in terms of security.

The black eye with Android isn't Google's fault. Virtually all reports of malware I see here in the US are due to people going to shady repositories for pirated apps. Yes, it might "save" $1.99 on an app, but there is a good chance, a lot more "functionality" might come with the .apk file.

I've seen people buy a HTC Mini Plus (which is a BlueTooth device that appears as a feature phone, but uses your recent HTC phone) just so they can leave their big phone in their pocket and talk on something less cumbersome.

There are a lot of people who don't want a phablet. The reason why phone makers are making these is less of customer demand... but more surface area needed to disperse the heat on the multi-core CPU/GPU dies that are present.

What should happen is that CAs should be part of SSL's security, not all of it. There should be some additional options:

1: QR codes a company can print out to validate not just their address, but a key ID and fingerprint.

2: Some form of P2P mechanism, coupled with trust weightings. That way, if Alice says a key to Last National Bank is genuine, it has more weight to Bob than 1000 other people who have no reputation, but are showing different key IDs for the same bank.

3: Some caching to notice if an intermediary key changes.

None of this is perfect. #1 can be defeated by an attacker printing out their own flyers. #2 can be defeated by a lot of bogus peers saying that someone else's key is bogus, and by hacking people's accounts for better rep. #3 doesn't work if a computer is new or compromised. However, in combination with a CA, it can help preserve security.

There is always having a key signed by multiple CAs so if one CA is compromised, another shows a key is valid... but the hard part would be making sure people know a key is signed by multiple CAs, versus a bogus key that states they are only vetted by one. Perhaps this could be a different icon (similar to how EV SSL certs have a green titlebar.)

This is why so many variants of adware that sneak their certs into the root CA list and then create a local loopback proxy is so common -- nobody looks at what key is presented. If the lock icon is green... good enough.

Even worse is that certificates can't be removed on some devices. For example, if a CA is broken on iOS, there is no way to mark that CA as untrusted until Apple gets around to pushing out a set of new root certs. Android, it is easier, but still onerous going through every unwanted CA and unchecking it.

The CA system is a subset of a WoT system. It was placed originally because CAs used to be meticulous about who they signed certs for. Now, especially after the fiascos a few years back, no so much.

The fix? Part of it would probably say prompt the user on the device to install the relevant CAs for their geographic region. If on mainland China, having a CA for the HK post office makes sense. Not so in the US, unless one travels abroad or has a lot of business with Chinese sites.

The second fix is that OS and Web browser makers will need to enforce with sheer brutality the rules they have on how CAs behave. If the CA screws up, they get their cert pulled, no questions, no appeals.

The Dash button might be useful in the office or the enterprise, especially if it could be configured to send the order requests to purchasing:

1: You are running out of tape media, and it is time for a quarterly offsite in a few weeks. Mash the button, get the tapes in a few days, continue on.

2: The office supply cabinet is low on pens. Mash the button for the style of pens that is needed, go on one's day.

3: Paper is low. Hit the button by the copier.

I can see a number of uses for this device, more than just ordering bathroom supplies for home.

Another person mentioned adding a button similar to a watch crown and a color e-Ink display, which would list one's favorite items.

Even without the selector, it would be nice to have this with an e-Ink display just so it can be reused for other items.