Sun spreads more VirtualBox love
1) Cut a deal for the box. 2) Put your OS in that box...
As Sun Microsystems gets closer to the release of its xVM server virtualization platform, it's aiming to ease developers into the fold by spreading its lightweight desktop hypervisor around to hardware vendors.
Sun earlier this week said that inked new multi-year OEM agreements for VirtualBox with three new businesses.
VirtualBox is a hypervisor weighing in at under 20MB that lets developers run multiple operating systems side-by-side so that code can be more easily tested across Windows, Linux, Mac, and OpenSolaris. Sun picked up the technology from its acquisition of the German-based innotek (lower-case i and all) in February.
Sun signed Avanquest Software, Q-Layer and Zenith InfoTech to OEM deals for the code.
"Sun xVM VirtualBox has become hugely popular with developers and power users, and with a modular core that enables it to be embedded in many other solutions, xVM VirtualBox is expanding its reach to new audiences," said Steve Wilson, veep for xVM at Sun.
Avanquest Software plans to produce and publish VirtualBox bundled with OpenSolaris in retail outlets in the UK, Germany, Italy, Spain and France.
Q-Layer plans to use the software to provide datacenter virtualization capabilities for its customers.
India-based Zenith Infotech, meanwhile, has made a network attached storage (NAS) appliance for small and medium businesses using Virtualbox.
Presently VirtualBox is available for free under a personal use license. OEMs can license an open-source version of VirtualBox under GPLv2 or under a commercial license. ®
you seem to have answered your own question ,or would have if you had read the Lebfrevec pages.
libfreevec appears to be an evolving SIMD routine replacement for GlibC , in this case optimised with Altivec code for any PPC CPU that has this SIMD ability.
just as you could replace the generic slower GlibC routines for any CPU that has other SIMD Co-pro abilitys, MMX/SSE etc with optimised versions there.
even GPU Co-processors if you wanted, and were willing to add to the work already done, such as the Gallium3D driver framework http://www.bitblit.org/gsoc/g3dvl/proposal.shtml with some imagination.
the point being made seems to be there are many totally or little used Co-Processors on many generic Chips and pluged into PC motherboards that could be used to give a massive boost to everyday apps by changing the generic glibc and related librays in whatever CPU family you are using today.
markos of that libFreeVec for instance tells you have to simply start using his replacements and get that needed boost
"...The next application you will load you will use the AltiVec functions in libfreevec! Enjoy! :)..."
"libfreevec 1.0.4 has been released a while ago, but it's only today that I've managed to finish with the benchmarks. Check the URL to see how a G4, a G5 and a MPC8610 compare to a Athlon X2 5000! :D
sure, its far harder to wrap 128bit Alitvec code into MMX/SSE SIMD, that the other way around SSE wrapper into Altivec native for Emulation etc but it could still be far better as you pint out above, they hardly even tryed to use the current hardware capabilitys to its SIMD potential
I don't know what all your comments about freevec are on about... If you look at the Linux kernel, you will find for x86 it basically uses MMX or SSE only for memcpy and I think calculating checksums for RAID stuff. It enables an Altivec bit (so apps can use it), and has Altivec emulation if an app decides to use it without checking if it's on the right CPU type. It's up to applications writers, GCC, and glibc beyond that.
None of this has much to do with virtualbox -- if they use altivec instructions in it, great. If not, the kernel can't help that.
Works for me
It works perfectly for me. I'm running windows xp (because I am forced to for work) in VB on top of OSX. No problems. No slowness. It lightweight, reliable, and free. What more could you want?