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.

This.

What we will see are vendors conflating locking the device away from its user with anti-malware protection... two different things, but both are considered "security".

I will also not be surprised to see more remote monitoring, where if a device reports that it was jailbroken or rooted, the cellular network blacklists that device's IMEI.

The future is now. Look at the latest generation of consoles as what we are going to have in our pockets and on our desks. Consoles have no issues with malware and a 0% piracy rate. The main game makers (for the most part) thrive off of the same IP that was out over a decade ago. Any issues result in the console being blacklisted. To boot, you never know if you are being watched. A closed environment like a console can easily have an update pushed to turn the console into a 24/7/365 monitoring device, and there is no way for the user to fix it, outside of physically killing cameras, depowering it or tossing the console in the garbage.

We will also see a tipping point. If a group of people find a bootrom exploit that allows for the next iPhone to be jailbroken, or the exploit allows malware to be put on devices without detection... the malware authors will pay millions for it, while a JB might result in very little. Especially with the time a phone stays jailbroken being days to weeks before Apple pushes an update that closes the hole. In this time, a malware author can make a lot of money with no way to detect or trace his/her works.

Desktops used to be a bastion of freedom, but that is getting encroached as well. The hardware spec for Windows 10 allows CPU vendors to lock down the UEFI Secure Boot to just Windows, and the hardware spec mandates a TPM chip that is shipped on. In fact, any PC certified with Windows 8.1 has the TPM 2.0 chip present.

The only reason why we have not seen a wholesale push to get users completely in the cloud is the fact there is pushback due to the fact that bandwidth in the US is expensive and will remain so.

The sad thing is that we won this battle. In the early 1990s, there was a battle for the device that would be used for consumer browsing. It was the desktop versus the TV set top box. The desktop won because the STB was a monolithic environment and couldn't innovate. Now, we are seeing a rematch, and this time, innovation is stagnant for the desktop and new features, while the set top box has a lot of money behind it, and a lot more technology to lock it down.

A lot of people rather take a console with its ability to report everything you do to anyone upstream and other privacy constaints than a desktop. Trading freedom for security is a dumb thing.

The nice thing about the breadboard is that you can work on one project, and either keep it, or yank the components off and put something different.

Even a short run device that allows one-off PCBs means that if stuff needs modified, the PCB needs to be tossed and a new one made.

I would give this device a place in the lab, but for the original product development, the breadboard will still be king. However, for testing an appliance, being able to one-off custom PCBs... especially multilayered ones... is quite useful.