Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Battery life (Score 2) 116

by thb3 (#42109849) Attached to: Dual Interface Mobile Devices To Address BYOD Issue

The only major concern I have is battery life. You don't see any figures from the manufacturers or the hypervisor companies (aka. VMware) as to what this will do to the already short battery life of a smart phone that is heavily used. Additionally, what incentive does a customer have to buy a device that supports this? Granted a company could prefer one or the other, but the days of "You own X device or Y device only (ie. Blackberry - no iPhone)" are over and it defeats the purpose of BYOD.

Comment: Non x86 HW/Software or Certified systems (Score 2) 464

by thb3 (#40174813) Attached to: Ask Slashdot: What Type of Asset Would You Not Virtualize?

The only workloads that you can't really virtualize tend to be things like OS/400, but that is where things like LPARs can come in OR workloads that do a lot of privileges calls to the CPU or a specific instruction set. Also there are a slew of non-technical reasons I've seen like in Healthcare or Pharma where a specific machine is written into a specification for drug manufacturing or such.

Even still there really aren't any workloads you can't virtualize and realize some sort of benefit from. Even those with high requirements for CPUs or Memory hogs can be virtualized. It's not always the best financial decision from the hardware cost and licenses, but most organizations benefit then from the ability to move the VM from one physical host to another to avoid downtime and easier backups. Having worked on a lot of the largest VMware deployments out there, I've yet to find an application we can't virtualize for some gain in performance (newer hardware) or get better resiliency (less downtime, easier backups, HA features outside of the OS).

It's not so hard to lift yourself by your bootstraps once you're off the ground. -- Daniel B. Luten

Working...