Esta es la continuación del post: Como hacer tu propio Google Chrome OS (sólo para ansiosos y entendidos) – Parte 1 (Teoría).

En la primera parte nos habíamos quedado en la difícil decisión que debió tomar Google, si utilizar un GUI tradicional sobre el sistema de las X, o uno propio en Native Client. Vamos a analizarlo:

¿Por qué un GUI tradicional?

La principal ventaja de utilizar un GUI tradicional es que ya está hecho. Algunos usuarios de GNU/Linux prefieren la confiabilidad de Gnome, otros la innovación de KDE, y otros más la agilidad y sencillez de Blackbox. En mi opinión personal, si hubiera que elegir alguno de estos tres para implementar el GUI de Google Chrome OS, la elección más acertada sería KDE. Ya que aunque aún está en sus inicios (pero ya ha superado los problemas que tenía de estabilidad en su primerísimas versiones), es muy prometedor, la estructura con que se ha desarrollado es muy OOP y elegante, soporta imágenes vectorizadas y permite animaciones 2D fluidas, así como también efectos 3D.

Se preguntarán entonces: pero… ¿no iba a ser totalmente orientado a la web? ¿no era tan sencillo desarrollar aplicaciones .nexe? ¿no iban a ser todos los programas Native Cliente en el futuro Google Chrome OS?.

Yendo por partes, como diría Jack el Destripador. Cómo será el nuevo Google Chrome OS no lo sé, ya que no trabajo para Google, ni conozco a nadie que lo haga. Sólo puedo imaginarme cómo será, y cómo podríamos crear nuestro propio Chrome OS si así lo quisiéramos…

El GUI basado en KDE, por ej., se encargaría de mostrarnos la ventana de bienvenida y login, un bonito fondo de pantalla, una elegante barra de tareas, una simpática decoración de ventanas, efectos de transición entre ventanas y escritorios en 2D y 3D, animaciones, widgets, etc. Todo el contenido de las ventanas, o las aplicaciones en sí, serían Native Client. Tanto las aplicaciones visuales como las no visuales, para generalizar: aplicaciones .nexe.

Pasando en limpio, algunas de las ventajas serían:

• Ahorro de tiempo: la mayoría ya está hecho, sólo haría falta adicionar cuestiones de Branding Google (logos, imágenes personalizadas, etc.)
• Trabajo en conjunto con comunidades OpenSource: las mejoras en KDE se verían reflejadas en Chrome OS, y viceversa, y así con todos los componentes opensource que se utilicen. Esta es la ventaja filantrópica y a mi entender el aporte más valioso.
• Plataforma Multi-platafórmica: a lo que me refiero usando esta conjunción de palabras poco feliz es que se podrán utilizar no sólo aplicaciones desarrolladas para Native Client, sino también las desarrolladas para Gnome y Kde, simplemente instalando los paquetes correspondientes a cada una.

¿Por qué un GUI totalmente Native Client?

Si bien requerirá mayores tiempos y esfuerzos, un GUI desarrollado totalmente en Native Client (corriendo sobre Xorg), permitiría levantar entornos gráficos no solo de manera local, sino también remotos. La clave está en la conjugación de qué será unívocamente ejecutado de forma local y qué podrá ser también ejecutado de manera remota. No olvidemos que el entorno visual es una de las partes más pesadas, hablando en términos de disco duro, de las distribuciones de GNU/Linux de hoy en día.

Además, cuanto más haya desarrollado Google a su antojo, mayor poder y control tendrá sobre el Sistema Operativo.

Si, en teoría, con Native Client se pueden realizar aplicaciones de todo tipo con un amplio acceso a las funciones del sistema, no debería tener mayores complicaciones desarrollar un GUI en esta plataforma.

¿Chrome OS = Kernel Linux + (GNU + Xorg + Servidor Web + Motor Chrome) + Native Client Apps << GUI >> Native Client Apps?

Esta podría ser la fórmula que tienen en mente. Como podemos ver, algo que tendrían en común las dos variantes analizadas anteriormente en referencia al entorno gráfico, sería un servicio corriendo sobre el kernel del motor Native Client, que se encargaría de hacer la ejecución del código recibido desde un servidor.

La parte pintada de rojo corresponde a todo lo que indefectiblemente debe estar instalado en la pc local, una Netbook por ej. La parte verde es una zona libre que puede ser tanto offline (local) como online (remota). ¿De que sirve un GUI remoto? Algunos GUI podrían ser personalizables, y tendríamos el mismo GUI en cualquier PC que utilicemos, en algunos se podría limitar el uso de ciertas aplicaciones, etc.

Native Client se encarga de ejecutar código no-seguro de páginas de internet alojadas en un servidor HTTP. Pero este servidor puede estar tanto en Internet, o en otra PC de la WAN o LAN, o en nuestra misma Netbook.

Me animo a vaticinar que si lo especulado hasta ahora es relativamente correcto, Chrome OS traerá implementado un servidor web donde se almacenarán todas las aplicaciones que podremos ejecutar en nuestra PC sin necesidad de una conexión a Internet. La posibilidad de ejecutar programas sin estar conectados 24×7 es clave para la aceptación del público en general, ya que no todo el mundo tiene los medios económicos para contratar una banda ancha ilimitada y portatil.

Hasta aquí llegó mi humilde y teórica opinión, vagas especulaciones, y demás. A continuación invito a todos los que quieran ponerse manos a la obra para desarrollar su propio sistema operativo al estilo Google Chrome OS.

Siguiente >>

Si querés seguir leyendo el tutorial para hacer tu propio Google Chrome OS, hacé clic acá.