Como hacer tu propio Google Chrome OS (sólo para ansiosos y entendidos) – Parte 1 (Teoría)
Con el misterio alrededor del nuevo sistema operativo Google Chrome OS de nuestro lado, no hay otra alternativa que imaginarse y suponer cómo puede llegar a ser el futuro competidor de Microsoft, Apple y por qué no todas las distribuciones basadas en GNU/Linux.
Luego de repasar información sobre algo que había anunciado Google hace unos meses, llamado Native Client, creo que puedo llegar a imaginarme algo más cercano a la realidad de lo que será el nuevo S.O.
Native Client fue ideado para funcionar en los navegadores actuales mediante un plug-in, y hablando mal y pronto vendría a ser algo similar a Flash. Aplicaciones descargadas desde la web por el equipo cliente que la visita, y luego ejecutadas y procesadas en el equipo local (a diferencia de las aplicaciones cliente-servidor, donde el procesamiento se realiza en el servidor y el equipo cliente solo recibe los resultados).
Hablando bien y tomándome un poco más de tiempo para explicarlo, se podría decir que Native Client, a diferencia de Flash, Javascript y Silverlight, no requiere de la ejecución de una máquina virtual para poder interpretar el código que descargamos. El código que recibimos es directamente interpretado por el hardware real, mediante instrucciones que “sobrepasan” al sistema operativo y van directo al procesador x86 ó ARM.
Native Client posee APIs (algo así como lo intermedio entre el código que escribimos en un lenguaje de alto nivel y las instrucciones aplicables al hardware luego de compilar) no sólo para el acceso a los principales componentes de la PC que utilicemos, sino también multimedia, que nos permitirá hacer uso de audio y video de forma nativa.
Todo enmarcado en un alto nivel de seguridad, que es en lo que más énfasis pone Google (recordemos el fraudulento Microsoft ActiveX, que con el tiempo entró en desuso debido a la facilidad de infiltrar código malicioso). Una de las formas de evitar algunas estrategias de inclusión de código indeseado es realizando un control del flujo de instrucciones en el código Native Client antes de su ejecución en el equipo local, validando que la aplicación no salga de las “barreras” de seguridad.
En febrero de este año Google liberó el código de Native Client y realizó un concurso en el que los participantes debían implementar mejoras de seguridad, entregando premios a las que consideraron más valiosas contribuciones.
Especificamente hablando de las aplicaciones, las mismas pueden ser desarrolladas en C o C++, en Windows, Mac Os y Linux, utilizando las herramientas de desarrollo que ofrece en su sitio. Luego de compilada la aplicaciòn, el archivo ejecutable adquiere la extensión .nexe (Network Executable). La ventaja de poder utilizar un lenguaje como C++, el más común para desarrollar aplicaciones tanto para Windows como para Mac o Linux, radica en la simplicidad que supone traducir programas ya existentes a la plataforma Native Client.
Hasta aquí vemos que toma la forma de un software bastante completo:
- Una plataforma que funciona sobre cualquier navegador (sólo basta con instalar un plugin).
- Permite utilizar aplicaciones desarrolladas en lenguajes de alto nivel de los que ya se ha hecho mucho uso.
- Ejecuta instrucciones en el equipo local directamente con mínima intervención del sistema operativo sobre el que corre.
- Tiene un robusto desarrollo en materia de seguridad y control de lo que se ejecuta.
- Velocidad en procesamiento de información, audio y video. Soporte de gràficos 3D mediante API O3D.
- Almacenamiento posible tanto en un servidor remoto como en uno local.
- Còdigo abierto. Libre. Gratuito.
Por todo esto, y remarcando en negrita lo más importante, Native Client ha sido el puntapié inicial de lo que han dado en llamar Google Chrome.
A este nuevo sistema operativo (al igual que al GNU de Stallman) le falta algo vital, algo básico para cualquier sistema operativo: el núcleo. Y aquí llega de nuevo, a la salvación, y qué mejor compañero de un código libre que otro código libre, el kernel Linux.
Pero… Un momento! Tenemos el kernel (interfaz hardware/sistema operativo), tenemos las aplicaciones (interfaz shell o GUI/usuario), pero nos faltan dos ingredientes muy importantes: el S.O. propiamente dicho y el shell y/o GUI.
En cuanto al S.O., no hay ninguna razón por la cual Google tuviera la necesidad de reinventar la rueda, y tranquilamente podría estar basado GNU/Linux, que ya trae consigo shell, herramientas de compilación, controles del sistema, etc. Esto es algo necesario ya que las aplicaciones correrán sobre el navegador Chrome, el cual debe correr sobre algún sistema operativo.
En cuanto al shell, ya lo tenemos, pero el usuario general, normal, no técnico, de un pc no es el principal amigo de los shell. Por lo que se necesita un GUI, la forma amigable del shell, por así decirlo. Sobre GNU/Linux existen actualmente varios GUI, llamados Administradores de Escritorios/Ventanas. Los ejemplares más conocidos son: KDE, Gnome.
KDE y Gnome se caracterizan por ser amigables, bonitos, tienen efectos 3D, pero en cuanto a rendimiento se refiere, pierden la guerra contra gestores como Blackbox, por ejemplo, que consiste simplemente en un fondo de pantalla, y unos cuantos menúes sencillos. Cabe aclarar que todos estos GUI corren sobre un sistema gráfico llamado Xorg, sistema de las X, Sistema X, X, etc. Algunos seguidores de Apple (si no lo saben ya) quizás se pregunten si tiene algo que ver con el Mac OS X y la respuesta es: sí. Mac está basado en varios componentes de GNU/Linux, pero ese es otro tema… o no?
No dudo de la capacidad de los desarrolladores de Google (presentes y futuros) de programar desde cero un entorno gráfico (llamemos a esto fondo de pantalla, ventanas, escritorios, barra de tareas, etc.) basado en X. La principal diyuntiva es sí han optado por instrumentar un GUI directamente mediante X (utilizando el código nativo tradicional), o un GUI totalmente Native Client.
Si te interesa saber más sobre Cómo hacer tu propio Google Chrome OS, seguí leyendo la 2da parte haciendo clic acá.
Fuentes:
[...] Esta es la continuación del post: Como hacer tu propio Google Chrome OS (sólo para ansiosos y entendidos) – Parte 2 (Teoría). [...]