En mis entradas número uno y dos sobre VMWare Fusion y Paralells for Mac, comparaba en escenarios reales el rendimiento y la respuesta durante días y días de trabajo habitual dependiendo de Windows «virtualizado».
Las condiciones eran simples, utilizar Visual Studio 2005, las herramientas de Microsoft SQL 2005 (Cliente) y Subversion (TortoiseSVN), durante todos los días, programando en C#.NET una aplicación de Windows Forms subjetivamente «grande».
Pues bien, la historia, por si no tenéis ganas de leer los dos artículos anteriores es mas o menos así:
Comencé con Parallels cuando era nuevo. Estaba sorprendidísimo de poder utilizar un Windows XP y que funcione tan bien; sobre todo porque venía de experiencias con el VirtualPC de Microsoft. Cuando salió el VMWare Fusion, el Paralells andaba tan bien que no sentí que fuese necesario cambiar. La gente tenía (y tiene) opiniones mixtas sobre VMWare Fusion. Gente que reportaba que le funcionaba «mucho más rápido» y otros que opinaban exactamente lo contrario; como me considero un usuario que realmente empuja los límites de la virtual machine, decidí que era un buen momento para compararlos en mi día a día. Y eso hice.
No me encontré con grandes sorpresas, pero si con algunos detalles del VMWare que no me gustaron mucho (y otros que -por el contrario- me parecían muy buenos). La conclusión final fue que ambos son similares y se pueden utilizar indistintamente. En mi situación particular, noté que -a pesar de ser más «pesado»- el Paralells respondía con mayor fluidez dentro de la virtual machine, sumado a que el mapping de teclas del VMWare hacían más incómodo el cambio de Windows / Mac y encima, el «enter» del teclado numérico de mi Apple Keboard no hace las veces de Enter en VMWare (una tecla que uso bastante).
Debido a esos detalles y dado que no aportaba ninguna mejoría considerable, es que trabajé unos 30 días continuos con el VMWare y cuando acabó la versión de pruebas, volví al Paralells. Luego se actualizó el Mac OS X, se actualizaron el Paralells y el VMWare con updates y las cosas cambiaron. De modo que volví al VMWare y todo seguía en orden; treinta días después estaba otra vez en el Paralells (nuevamente actualizado).
Amén de los ligeros cambios, mejoras aquí y allí, al final, nada cambió significativamente para mi. El Visual Studio sigue funcionando bien -con sus detalles- y todo funciona como es debido. Pero los últimos meses, estuve en Paralells, dejando al VMWare abandonado. Un gentil lector (y otros tantos RSS Feeds) me avisaron de la nueva Beta del VMWare 2.0, que supuestamente «corrige» muchos de los problemas que yo mencionaba. De modo que armado de valor (y aprovechándolo como excusa para probar nuestra aplicación con Service Pack 3 de Windows XP) me lancé a instalarlo…
Mi objetivo no es comparar si mejora tal o cual cosa, sino jugar con escenarios reales, con lo que yo usaría. No me importa si la mejora es debido al Service Pack 3 de XP o al nuevo VMWare o a que, simplemente que yo usaré *eso* y es mejor (o peor) que *aquello*.
Así pues, descargar el VMWare 2.0 Beta es un juego de niños y de 300MB. Se descarga, se instala (reemplaza al anterior) y arranca. Mi virtual machine estaba suspendida en la versión 1.1, sin embargo esto no fue un problema. Arrancó y me indicó que las VMWare tools estaban desactualizadas y requerían un update.
Lo primero que me sorprendió al ver el nuevo VMWare es la nueva pantalla de «Librería de Máquinas Virtuales».
Es subjetivamente mejor que la anterior que era muy sosa. Otra pantalla que también ha sufrido un rediseño considerable, es la de las propiedades de la máquina virtual.
Como pueden ver, está todo más ordenado y accesible; de momento esto es sin dudas mucho mejor que en Paralells. Sin embargo uno no accede a estas opciones tan a menudo como para que ello signifique el día y la noche.
Las VMWare tools se actualizaron sin problemas…
Aunque en Paralells este proceso es un poco más interesante, porque él mismo se encarga de arrancarlo automáticamente. Si bien esto puede parecer una tontería, muchos de los problemas de las VMs suele deberse a versiones incorrectas o mal instaladas de las herramientas. Paralells de algún modo, nos fuerza a instalarlas, lo cual es bueno desde mi humilde punto de vista.
To Service Pack 3 or To Not Service Pack 3
Cuando arranqué la VM que tenía en mi «antiguo» VMWare Fusion, me indicó que el Windows tenía nuevas actualizaciones, entre las cuales figuraba Service Pack 3. Me pareció un excelente momento para probarlo. De modo que lo puse a instalar. Tardó todo el proceso una hora mas o menos (entre que lo descargó, lo instaló, reinició, etc.) Luego vinieron los momentos del síndrome de «es todo más rápido». La realidad es que según Microsoft (no tengo aquí el vínculo) hay ciertas mejoras de performance en el Service Pack 3. Cuales son o dónde están, es algo que desconozco. Lo interesante es que con el SP3 instalado, todo siguió funcionando sin problemas. El Visual Studio 2005 arrancó, mi solución cargó, compiló y se ejecutó de maravillas. Da la impresión de ir ligeramente más rápido que el anterior, especialmente en el tema del vídeo, pero es una percepción que no puedo asegurar. Nuestra aplicación dibuja mucho en GDI y GDI+ (inherentemente lentos) y se nota el redraw. En VMWare era bastante más lento que en Paralells, y ahora parecen ir igual.
No puedo saber si es gracias al VMWare o al Paralells, pero eso no me interesa (sospecho que es el VMWare), dado que como dije al principio, mi intención no es ponerlos palmo a palmo para decir este es mejor que el otro, sino poder encontrar la herramienta que nos permita programar más rápida y cómodamente.
Como ya hice una revisión de ambos productos en su momento, no voy a hacerla nuevamente, en su lugar voy a listar las cosas buenas y malas (según mi opinión y experiencia) y luego aceptaré comentarios.
Tanto el modo Coherence de Paralells como el Unity de VMWare tenían ventajas y desventajas. Pero creo que VMWare ha dado en el clavo logrando solucionar el inconveniente más grande de ambos: Pantallas Múltiples. El primer día que tuve más de una pantalla fui muy feliz. Realmente la capacidad de tener la aplicación en una y el Visual studio en otra es importantísima. Nos permite interactuar con la aplicación, al tiempo que vemos como pasan las líneas de código, los Watchs, etcétera. Si hay breakpoints podemos ir haciendo debug en simultáneo, mientras vemos como se actualiza la aplicación. Es brillante y sin dudas, como el mismísimo Jeff Atwood recomienda, un programador debe tener por lo menos dos pantallas.
Cuando me pasé a las Virtual Machines en Mac OS X y dejé de lado mi PC con Windows, perdí esa capacidad de algún modo. Porque ahora había una tercera pantalla en juego. Por un lado necesitaba mis «dos pantallas» para Windows, pero también necesitaba poner las aplicaciones de Mac OS X en otro sitio. Resultado: Ni Paralells ni VMWare podían trabajar bien en sus respectivos modos «Coherence» o «Unity». Hasta hoy.
El VMWare 2.0 realmente reconoce las pantallas como es debido. Ya no más diálogos en el centro de ambas. Ahora puedo tener mi Aplicación en un sitio y el Visual Studio en el otro. Todo gracias a VMWare 2.0. Anda ligeramente «mas lento» visualmente, es decir, se nota que es Beta y que lo están ajustando pero, realmente funciona como es debido. En lugar de usar Full Screen común y corriente, lo puse en modo Unity y boom. Moví la barra de tareas de Windows (que se puede ocultar desde un menú de VMWare) hacia la derecha en el segundo monitor, en modo vertical (como siempre la he usado) y el Visual Studio también, lo maximicé y quedó sólo en esa pantalla. Bien. Ejecuté mi proyecto y para mi alegría, respondió como en Windows. La aplicación (que se maximiza) fue a parar a la pantalla 1 (la de OSX) por lo que tuve que ocultar el Dock (alt-cmd-d). Brillante. Mi funcionalidad había vuelto. Me falta probarla más para determinar qué problemas puede tener, ya sea porque es Beta o porque hay algo que está mal implementado desde mi punto de vista. De momento anda maravillosamente. Quizás el único problema es que cuando apagas el Windows, se pasa a modo Full Screen con una resolución que abarca todos los monitores y si hay algún diálogo de guardar o algo, no lo verás bien. Esto posiblemente sea un Bug que esperemos corrijan a futuro en la versión final.
Una de las cosas que se pierden con Unity (o Pantalla Completa) son los iconos que indican la actividad de la VM. En VMWare lamentablemente no cambian de color o estado según la actividad (como recalqué en mi entrada original). Esto sigue siendo así, sin embargo, han agregado una curiosa funcionalidad.
Se pueden montar dispositivos presentes tocando sobre los iconos «grises». O sea, si tienes un Disco Duro externo conectado al USB y no está montado en Windows, pero si en OSX, puedes montarlo allí también, o administrar las carpetas compartidas desde estos pequeños iconos. Lamentablemente, los azules (CD, HDD y Red) no cambian de color cuando hay actividad, como lo hacen en Paralells. Esto es importante para saber qué hace la VM en todo momento. Desgraciadamente en modo Unity y Pantalla Completa, perdemos estos cómodos iconos, aunque no se me ocurre una forma de solucionarlo.
Pues bien, el modo Unity funciona como ningún otro, gran punto para VMWare. ¿Pero qué pasa con las teclas?
En la versión 1.0 de VMWare (y de Paralells) el mapping de teclas entre Windows y OSX era diferente. Todos sabemos que en Macintosh, copiar, pegar, cortar, deshacer, etcétera, se hacen desde la tecla «cmd», en lugar del «control» de Windows. Copiar y pegar algo entre Windows y OS X era una tarea compleja porque había que recordar cambiar de control a cmd todo el tiempo. El resultado era simple: fallabas 20 veces por día.
Con el paso del tiempo y las actualizaciones, esto fue reparado permitiendo que el mismo CMD-C/V/X/etc. de Mac OS X, respondiera del mismo modo en Windows. De modo que ahora se puede copiar dentro de windows con cmd-C y pasar a Mac OS X y pegar con cmd-v.
Tanto Paralells como VMWare lo han implementado de forma diferente. Y Aquí creo que el punto sigue siendo para Paralells. El tema es más complejo de lo que parece porque ni Windows ni OS X son iguales. Sin embargo VMWare sólo ha mapeado 3 ó 4 teclas, mientras que Paralells optó por intercambiar las teclas.
¿Qué pasa con el método VMWare? Que cmd-c hace copy, pero control-c también. Eso no sería un problema, si no fuese porque en Windows la mayoría de los programas guardan sus datos con control-S (de Save, guardar). En Paralells esto funciona perfectamente porque es cmd-S (recordar que ellos invirtieron la tecla, el cmd-responde como control en Windows), sin embargo en VMWare no. VMWare sólo ha mapeado copy, paste, cut. De modo que acostumbrado a usar cmd-s en Mac y en Windows/Paralells, tengo que recordar usar control-XXX para todas las demás funciones cuando estoy en VMWare. Esto es muy incómodo y lleva a errores todo el tiempo. La memoria muscular de usar control y tener que cambiar a cmd es automática con el paso del tiempo, porque al usar Mac OS X, indefectiblemente te acostumbras a usar cmd. Amén que OS X tiene un excelente soporte de shortcuts (atajos) y muchas funciones se hacen con el teclado. Lo que no es fácil de entrenar, es la memoria músculo para que recuerde sólo unas funciones con cmd- y otras con control-. Eso es malo. Muy molesto. Y repito, me lleva a cometer errores todo el tiempo. El sistema operativo es Mac OS X, es quien manda. Casi se puede decir que es lo mismo que Control en Windows. Sin temor a equivocarme aseguro que el 90% de las funciones que en Windows se hacen con alguna combinación de Control, en Mac OS se hacen con cmd. (Guardar, Imprimir, Copiar, Pegar, Cortar, Buscar, etcétera). ¿por qué no invertirlas como hizo Paralells?
En fin, este detalle es muy molesto en el día a día y lamento que los chicos de VMWare no hayan ofrecido la posibilidad que ofrece Paralells. No se si es lo mejor o peor, pero para Visual Studio, es mucho más cómodo acostumbrarse a usar todo el tiempo cmd (como si de una Mac se tratase) a que tener que estar recordando cambiar de ctrl a cmd todo el tiempo. Este inconveniente ya lo mencioné en su momento y lamentablemente sigue igual. 😦
¿Imprimir?
La impresión en ambos productos desde la máquina virtual funcionaba bien. Agregabas la impresora normalmente en Windows y listo. VMWare ha dado un paso más. Asume que si tienes tu impresora configurada en OS X, pues deberías poder imprimir en Windows perfectamente. De modo que han activado una opción para ello:
Como podéis ver, es bastante simple. Yo tengo tres impresoras, dos HP y una Brother (por defecto). De modo que me lancé a probarlo. El primer problema que me encontré fue que el Printer Spooler service estaba apagado (yo lo había apagado) de modo que tuve que ir a Servicios y encenderlo; tan pronto como hice eso, me apareció una _#VMWareVirtualPrinter (feo nombre). No pude saber a que impresora corresponde, de modo que tuve que probarlo…
No me anduvo inicialmente, porque tengo que autenticarme en Mac OS X antes de que me dejen imprimir los compañeros de Windows (las impresoras están conectadas a un Windows y me conecto vía samba).
La realidad es que tampoco me anduvo después de eso, así como tampoco me respetó las propiedades de papel (A4 en lugar de Letter); en fin, supongo que esto funcionará bien en un futuro cercano, inclusive será completamente automático; sin embargo mi experiencia es: no me anda. Tampoco me ha permitido elegir otra impresora, dado que sólo me aparece una. He desactivado todo (dado que no imprimo desde Windows) pero tenerlo en cuenta. En cualquier caso, siempre se pueden instalar los drivers nativos de Windows y saltarse esta automatización.
Un interesante shortcut que nos ofrece VMWare 2.0 es el cmd-L para lanzar aplicaciones en la máquina virtual, como incluye «live search», es una forma muy QuickSilver/Spotlight de lanzar aplicaciones de Windows.
La búsqueda es muy rápida y resulta útil, algo que jamás hubiese pensado. En fin, es cómodo y poco más.
El Dock de OS X
En modo Unity, el VMWare no nos deja elegir si queremos que las aplicaciones de Windows aparezcan en el Dock o no; aparecen siempre. Esto es bueno y malo. Malo porque me gustaría quitarlas, pero bueno porque al final, se integra con el cmd-TAB de OS X. De modo que puedo pasar del Visual Studio al Mail.app con cmd-tab, algo que antes requería (inclusive en Paralells), que cambie a la VM usando cmd-TAB y luego use control-TAB (en Windows) para cambiar de aplicaciones. El modo Unity permite que eso esté integrado y ahora que respeta los múltiples monitores, no hay motivo para no usarlo. Con el lanzador de aplicaciones y los iconos en el Dock, quizás hasta sea posible eliminar la barra de Windows, dado que contiene un Reloj (que ya tengo en la barra de OS X) y el System Tray, que sería lo único que no tendría (ni uso). De modo que me arriesgué y desactivé la barra de Windows
El resultado fue que la barra desapareció unos 2 ó 3 segundos después y gané todos esos pixels. 😉 Si me acostumbro al cmd-L, ya no la necesitaré de vuelta. Paralells también tiene esta funcionalidad, pero el problema es que el modo Coherence no respeta las múltiples pantallas, y eso es un punto negativo que hace que haya que usarlo en Pantalla Completa o en Pantalla. Y claro, perdemos el amor de los múltiples displays.
Bugs, Dudas, Comentarios, Annoying things, etcéteras…
Hay algunas cosas raras, me imagino que siendo una versión Beta 1, pues está claro que existirán. Veamos algunas de ellas.
Suspender la máquina virtual anda más rápido que antes (gracias), sin embargo hace cosas raras en modo Unity. Pasa a un pseudo pantalla completa y mueve las ventanas.
Al restaurarlas, las ventanas no vienen a la posición que estaban. La barra de tareas, que está oculta via VMWare, realmente está allí, sólo que con algún truquillo no se ve. Pero las notificaciones del System Tray aparecen…
…o eso parece. El resultado es que las ventanas viajan de un monitor a otro y cambian de tamaño y que durante algún momento el maximizar no es «suficiente» hasta que VMWare no guarde la barra de tareas en el Bag of Holding en el que la guarda.
La red no funciona ni bien arranca el VMWare porque fuerza un refresco de la dirección IP (en el caso de usar DHCP como yo).
¿Qué es eso? Bueno yo lo sé, pero un usuario puede sentir temor, amén que si tenías alguna aplicación que usaba la red, estará desconectada hasta que el «renovar» de la red acabe. Y eso puede demorar unos segundos. En mi opinión debería mantener la red como estaba. No lo sé. En todo caso la ventana de «DOS» es fea.
Los iconos de Windows no son «bonitos» en alta resolución como en OS X (512×512), de modo que se ven «feos» cuando haces cmd-TAB. Esto no es un problema del VMWare pero bueno, lo menciono como un detalle. En el Dock se ven «ok» siempre y cuando no uses un dock del tamaño de un refrigerador.
Conclusión Final (y temporal)
Paralells fue actualizado pero era más bien un «service pack» para reparar problemas con Leopard. Leopard fue actualizado a 10.5.2 (pronto 10.5.3) y todo funcionó un poco mejor. VMWare había sido actualizado también (ver. 1.1) y corregía más fallos y problemas con Leopard, pero no fue sino hasta ahora, que creo que las cosas se han desnivelado para el lado de VMWare. Si bien siguen sin arreglar el Keyboard Mapping como creo que sería mejor, al fin y al cabo la versión 2.0 promete mucho. Naturalmente la gente de Paralells no se quedará sentada mirando y aparecerá con algo similar. Sólo resta saber si será mejor o peor. Eso es lo bueno de la competencia entre ambos. El tiempo nos dará las respuestas de Paralells y VMWare. Lo que si es seguro es que desde el día uno en que apareció Paralells, las cosas siempre han ido mejorando notablemente. Recordar que yo trabajo en un «humilde» Macbook Pro con «sólo» 2GB de memoria.
Durante los próximos días trabajaré en VMWare 2.0 Beta exclusivamente y a medida que obtenga más información, actualizaré esta entrada o agregaré una nueva para comentarles que hay de nuevo. Stay in touch.
The thing that should not be 