Odio tener que publicar dos posts el mismo día, pero la ocasión lo merece. Ya es oficial, ya no es sólo un rumor: Windows 8 funcionará sobre ARM. Y también Office (y, es de esperar, más software de Microsoft).
Si recuerdan, un servidor ya habló aquí de la encrucijada que tenía Microsoft frente a los smartphones de última generación que han visto la luz tras el iPhone. Una de sus características es utilizar la misma base de sistema operativo y aplicaciones y APIs básicas que en los equipos de sobremesa, y ante eso Microsoft estaba retrasado, ya que dependía de Windows CE (y todo lo que elso representaba, como carecer de un navegador decente). Con Windows phone 7 optaron por crear un nuevo entorno de desarrollo, exclusivo .NET, ejecutado sobre CE.
Con el anuncio de Windows 8 sobre ARM, los planes de Microsoft parecen aclararse. Parece ser que Microsoft quiere usar este Windows 8 sobre ARM en tabletas, lo cual descarta que vayan a hacer una versión de Windows Phone 7, con CE. ¿Cual es su plan de futuro para ambos sistemas? Lo lógico, llegados a este punto, sería hacer lo mismo que han hecho sus
competidores: Unificar todo. Primero, usando núcleo NT, y no el cacharrete de CE, para todos los dispositivos de
consumo. Segundo, la plataforma de Windows Phone 7 debería poder ejecutarse sobre entornos NT sin problemas de compatibilidad, asi que lo lógico sería ver tabletas con Windows8-ARM utilizando aplicaciones de Windows Phone 7. ¿Se permitirán aplicaciones con la API Win32 pero en versión ARM? Dado que Microsoft va a portar Office, parece que si, pero habrá que esperar a más datos sobre la tienda de aplicaciones para windows.
Lo interesante de esto es que Microsoft va a tener que ganarse a los desarrolladores para que porten y programen para todas estas nuevas plataformas. La multinacional que supo ganarse el afecto de casi todos los desarrolladores del mundo ya quedó atrás, ahora esos desarrolladores admiran y llenan sus bolsillos con la Apple Store. ¿Quien va a recompilar software Win32 a ARM? Especialmente teniendo en cuenta que Microsoft parece dejadarlo cada vez más de lado en favor de .NET. También tendrá que convencer a los fabricantes de hardware de que adopten su sistema operativo, claro. Es uno de esos problemas en los que la pescadilla se muerde la cola.
También entra en juego el avance de ARM en servidores. En realidad, el que más sale perdiendo de todo esto es Intel. Quien iba a decirnos hace dos ó 3 años...
5 de enero de 2011
Las novedades de Linux 2.6.37
Ya se ha anunciado la publicación de la versión 2.6.37 de Linux. Las novedades de esta versión son: mejoras de escalabilidad y rendimiento en Ext4 y XFS, posibilidad de desactivar el Big Kernel Lock, un dispositivo de bloques basado en el sistema de archivos distribuido Ceph, soporte para limitación del ratio de transferencia de E/S, varias mejoras en Btrfs, soporte en perf para analizar módulos y variables globales, compresión de la imagen de hibernación con LZO, soporte de PPP sobre IPv4, varias microoptimizaciones de la implementación TCP/IP, y muchos otros cambios menores y drivers nuevos. Lista completa en inglés en este enlace.
· Ext4: mejor escalabilidad SMP, mkfs más rápido:
· Mejoras de escalabilidad: En esta versión, Ext4 utilizará la capa llamada "bio" en lugar de otra llamada buffer". La capa "bio" (que es un alias de "block I/O": Se trata de la parte del kernel que se encarga de enviar peticiones al I/O scheduler) fue una de las primeras características que se incluyeron en Linux 2.5.1, y fue un reemplazo de la capa que sustituía, llamada "buffer", que tenía muchos problemas de escalabilidad y rendimiento: Al usarla, Ext4 sólo podía hacer peticiones de 4KB cada vez; utilizando la capa bio Ext4 puede enviar peticiones de 512KB cada vez. En el benchmark FFSB ejecutado en un equipo con 48 procesadores AMD y con almacenamiento de array RAID de 24 discos SAS, utilizando 192 threads paralelos de ffsb, la mejora fue del 300% http://thunk.org/tytso/blog/2010/11/01/i-have-the-money-shot-for-my-lca-presentation/
· mkfs más rápido: Una de las partes más lentas al crear un sistema de archivos Ext4 es inicializar la tabla de inodos. mkfs puede saltarse este paso y dejar las tablas sin inicializar. Cuando se monte el sistema de archivos por primera vez, el kernel creará un thread -ext4lazyinit- que inicializará las tablas.
· Mejoras de escalabilidad de XFS: Se ha mejorado la escalabilidad de cargas que operan con metadatos. Una máquina con 8 procesador ejecutando una instancia del benchmark fs_mark de 50 millones de archivos mejoró un 15%, y la eliminación de esos mismos archivos un 100%.
· Posibilidad de desactivar el Big Kernel Lock: El Big Kernel Lock (BKL) es un bloqueo gigante que fue introducido en Linux 2.0, cuando Alan Cox añadió por primera vez soporte para SMP. Pero fue sólo un paso para conseguir escalabilidad SMP - en Linux 2.0, solo un proceso podía ejecutar código del kernel a la vez, a largo plazo hay que reemplazar el BKL por múltiples bloqueos que abarquen pequeñas partes del código. En esta versión, por primera vez es posible compilar un kernel sin ningún tipo de soporte de BKL. Nótese que esto no tiene impacto en el rendimiento: todas las rutas de código críticas están libres de BKL desde hace mucho tiempo, pero quedaban muchos lugares no críticos -ioctls, drivers, sistemas de archivo poco conocidos- que continuaban usándolo por comodidad. Esos son los lugares donde se ha eliminado el uso del BKL, pero sólo ha sido sustituido por mutexes, que no mejoran el paralelismo.
· Dispositivo de bloques basado en el sistema de archivos distribuido Ceph: Ceph es un sistema de archivos distribuido que fue incluido en Linux 2.6.34. En el diseño de Ceph hay "dispositivos de almacenamiento de objetos", y "servidores de metadatos", que almacenan metadatos de los objetos. Ceph utiliza ambos para implementar su sistema de archivos; sin embargo esos objetos pueden utilizarse también para implementar un dispositivo de bloques exportable en red (o incluso almacenamiento de objetos compatible con Amazon S3)
Esta versión incluye el dispositivo de bloques Rados (RBD). RBD permite crear un dispositivo de bloques que esté repartido en red, apoyado sobre el almacenamiento de objetos distribuido de Ceph. A diferencia de alternativas como iSCSI o AoE, las imágenes RBD están replicadas varias veces y esparcidas en el cluster Ceph, proporcionando un dispositivo de bloques de red fiable (si un nodo falla, los otros siguen respondiendo) y escalable. RBD también soporta snapshots de sólo lectura con rollback, y también hay parches para crear en Qemu un dispositivo de bloques virtual que esté apoyado en un cluster Ceph.
· Limitación del ratio de transferencia de E/S: Se ha añadido soporte de límites de E/S, es decir la capacidad de especificar cuántos MB/s de escritura/lectura a un disco puede consumir, como mucho, un grupo de procesos. Esta capacidad es configurable mediante la interfaz cgroups. Ejemplo:
Montar cgroup de blkio:
# mount -t cgroup -o blkio none /cgroup/blkio
Especificar el ancho de banda en un dispositivo particular. El formato es ": "
# echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device
Esto pondrá un límite de 1MB/segundo a todos los procesos del cgroup en las lecturas del disco con los números de dispositivo 8:16.
Los límites también pueden especificarse en operaciones E/S por segundo (blkio.throttle.read_iops_device). También hay equivalentes para escritura: blkio.throttle.write_bps_device y blkio.throttle.write_iops_device. Esta característica no reemplaza el controlador de "peso" de E/S que fue incluido en 2.6.33.
· Jump label: Un punto de trazado podría describirse como un printf() especial, que se usa en el kernel para analizar el comportamiento del kernel mientras se ejecuta, para ello se utilizan herramientas como perf, LTT o systemtap. Hay dos tipos de puntos de trazado: dinámicos y estáticos. Los dinámicos modifican el código del kernel en tiempo de ejecución para insertar las instrucciones de CPU necesarias para obtener los datos. Esto es lo que systemtap hace cuando se intentan analizar puntos aleatorios del kernel. El nombre que se da a los puntos de trazado dinámico en Linux es "kprobes", y su impacto en el rendimiento ya fue optimizado en Linux 2.6.34.
Los puntos de trazado estáticos, en cambio, son insertados por los desarrolladores en puntos estratégicos del código. Por ejemplo, Ext4 tiene 50 puntos de trazado estático. Esos puntos son compilados junto al resto del kernel, y por defecto están desactivados - nadie los invoca hasta que alguien los active. Básicamente, una condición "if" que comprueba una variable. El impacto en el rendimiento es apenas notable, pero puede mejorarse, y eso es lo que se hace con "jump label": Se insertan instrucciones de CPU "no operación" en lugar de la comprobación condicional. De modo que un punto de trazado estático tiene sobrecarga cero. (Consejo: Puede utilizar el comando "sudo perf list" para ver la lista completa de puntos de trazado estático disponibles en su sistema)
· Novedades en Btrfs:
· Cacheado de la información de espacio libre en el disco: En esta versión, Btrfs almacena la información sobre las partes del disco que están libres en el propio disco, lo cual hace que cachear un grupo de bloques sea más rápido. Hasta ahora, cuando había que hacer asignaciones de espacio de un grupo de bloques que no había sido cacheado previamente, se tenía que escanear el árbol de extents (que representa las zonas del disco utilizadas por los archivos) por completo, para representar en las estructuras de memoria las zonas libres del disco. Ahora el espacio libre se escribe en el disco cada vez que se realiza una transacción. Esto supone un cambio en el formato de disco, pero no hay problemas de compatibilidad con los viejos kernels, ya que continuarán funcionando igualmente, con la diferencia de que generarán el caché del modo antiguo. También hay que tener en cuenta que esta característica está por el momento desactivada y tiene que activarse con la opción -o space_cache. También hay una opción -o clear_cache, útil solo para casos de depuración, que limpia los caches.
· Creación asíncrona de snapshots: Esto permite evitar tener que esperar a que un nuevo snapshot sea escrito al disco. Ha sido desarrollado teniendo en cuenta al demonio del sistema de archivos de Ceph, pero también está disponible para cualquier usuario añadiendo "async" al comando "btrfs subvolume snapshot"
· Permitir que un usuario sin privilegios elimine un subvolumen. Requiere utilizar la opción de montaje -o user_subvol_rm_allowed
· Cambiar el buffer de extents de un red-black tree a un radix tree, y utilizar RCU en lugar de spinlocks, lo cual mejora el rendimiento en algunos casos.
· Refinar la asignación de chunks: Soporte para grupos de bloques que puedan albergar datos+metadatos a la vez (util en dispositivos con poco almacenamiento), no asignar los chunks tan agresivamente (evita fallos de -ENOSPC debido a la sobreasignación de espacio para metadatos)
· Mejoras de perf probe: En esta versión se ha añadido soporte para mostrar las variables locales y globales en un punto determinado del código, mediante la opción "-V" (o "--vars"). Esto ayuda a buscar las variables locales que están disponible como argumentos de un evento determinado. Por ejemplo: "# perf probe -V call_timer_fn:23", mostrará las variables locales disponibles en ese punto de esa función. También es posible mostrar las variables globales con el parámetro "--externs". También se ha añadido soporte para analizar los módulos utilizando el parámetro "--module". Por ejemplo. "# ./perf probe --module drm drm_vblank_info:3 node m"
· Mejoras de gestión de energía: Compresión de la imagen de hibernación con LZO, autosuspensiones retrasadas:
· Autosuspensiones retrasadas: Esta es una característica que mejora a otra añadida en Linux 2.6.32, "runtime power management". Sin embargo, algunos drivers no quieren suspender el dispositivo tan pronto como sea posible, quieren que antes haya un periodo mínimo. Esto es lo que implementa esta característica.
· Compresión de la imagen de hibernación con LZO, que ayuda a comprimir y descomprimir más rápido la imagen.
· Soporte de PPP sobre IPv4: Esta versión incluye soporte de PPP sobre IPv4. Comparado con las implementaciones en espacio de usuario (poptop/pptpclient), mejora dramáticamente el rendimiento de las conexiones pptp vpn y reduce el consumo de CPU. Hay un proyecto accel-pptp project para utilizar este módulo.
Esta es la lista de novedades más importantes. La lista completa, en inglés, como siempre en este enlace.
· Ext4: mejor escalabilidad SMP, mkfs más rápido:
· Mejoras de escalabilidad: En esta versión, Ext4 utilizará la capa llamada "bio" en lugar de otra llamada buffer". La capa "bio" (que es un alias de "block I/O": Se trata de la parte del kernel que se encarga de enviar peticiones al I/O scheduler) fue una de las primeras características que se incluyeron en Linux 2.5.1, y fue un reemplazo de la capa que sustituía, llamada "buffer", que tenía muchos problemas de escalabilidad y rendimiento: Al usarla, Ext4 sólo podía hacer peticiones de 4KB cada vez; utilizando la capa bio Ext4 puede enviar peticiones de 512KB cada vez. En el benchmark FFSB ejecutado en un equipo con 48 procesadores AMD y con almacenamiento de array RAID de 24 discos SAS, utilizando 192 threads paralelos de ffsb, la mejora fue del 300% http://thunk.org/tytso/blog/2010/11/01/i-have-the-money-shot-for-my-lca-presentation/
· mkfs más rápido: Una de las partes más lentas al crear un sistema de archivos Ext4 es inicializar la tabla de inodos. mkfs puede saltarse este paso y dejar las tablas sin inicializar. Cuando se monte el sistema de archivos por primera vez, el kernel creará un thread -ext4lazyinit- que inicializará las tablas.
· Mejoras de escalabilidad de XFS: Se ha mejorado la escalabilidad de cargas que operan con metadatos. Una máquina con 8 procesador ejecutando una instancia del benchmark fs_mark de 50 millones de archivos mejoró un 15%, y la eliminación de esos mismos archivos un 100%.
· Posibilidad de desactivar el Big Kernel Lock: El Big Kernel Lock (BKL) es un bloqueo gigante que fue introducido en Linux 2.0, cuando Alan Cox añadió por primera vez soporte para SMP. Pero fue sólo un paso para conseguir escalabilidad SMP - en Linux 2.0, solo un proceso podía ejecutar código del kernel a la vez, a largo plazo hay que reemplazar el BKL por múltiples bloqueos que abarquen pequeñas partes del código. En esta versión, por primera vez es posible compilar un kernel sin ningún tipo de soporte de BKL. Nótese que esto no tiene impacto en el rendimiento: todas las rutas de código críticas están libres de BKL desde hace mucho tiempo, pero quedaban muchos lugares no críticos -ioctls, drivers, sistemas de archivo poco conocidos- que continuaban usándolo por comodidad. Esos son los lugares donde se ha eliminado el uso del BKL, pero sólo ha sido sustituido por mutexes, que no mejoran el paralelismo.
· Dispositivo de bloques basado en el sistema de archivos distribuido Ceph: Ceph es un sistema de archivos distribuido que fue incluido en Linux 2.6.34. En el diseño de Ceph hay "dispositivos de almacenamiento de objetos", y "servidores de metadatos", que almacenan metadatos de los objetos. Ceph utiliza ambos para implementar su sistema de archivos; sin embargo esos objetos pueden utilizarse también para implementar un dispositivo de bloques exportable en red (o incluso almacenamiento de objetos compatible con Amazon S3)
Esta versión incluye el dispositivo de bloques Rados (RBD). RBD permite crear un dispositivo de bloques que esté repartido en red, apoyado sobre el almacenamiento de objetos distribuido de Ceph. A diferencia de alternativas como iSCSI o AoE, las imágenes RBD están replicadas varias veces y esparcidas en el cluster Ceph, proporcionando un dispositivo de bloques de red fiable (si un nodo falla, los otros siguen respondiendo) y escalable. RBD también soporta snapshots de sólo lectura con rollback, y también hay parches para crear en Qemu un dispositivo de bloques virtual que esté apoyado en un cluster Ceph.
· Limitación del ratio de transferencia de E/S: Se ha añadido soporte de límites de E/S, es decir la capacidad de especificar cuántos MB/s de escritura/lectura a un disco puede consumir, como mucho, un grupo de procesos. Esta capacidad es configurable mediante la interfaz cgroups. Ejemplo:
Montar cgroup de blkio:
# mount -t cgroup -o blkio none /cgroup/blkio
Especificar el ancho de banda en un dispositivo particular. El formato es "
# echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device
Esto pondrá un límite de 1MB/segundo a todos los procesos del cgroup en las lecturas del disco con los números de dispositivo 8:16.
Los límites también pueden especificarse en operaciones E/S por segundo (blkio.throttle.read_iops_device). También hay equivalentes para escritura: blkio.throttle.write_bps_device y blkio.throttle.write_iops_device. Esta característica no reemplaza el controlador de "peso" de E/S que fue incluido en 2.6.33.
· Jump label: Un punto de trazado podría describirse como un printf() especial, que se usa en el kernel para analizar el comportamiento del kernel mientras se ejecuta, para ello se utilizan herramientas como perf, LTT o systemtap. Hay dos tipos de puntos de trazado: dinámicos y estáticos. Los dinámicos modifican el código del kernel en tiempo de ejecución para insertar las instrucciones de CPU necesarias para obtener los datos. Esto es lo que systemtap hace cuando se intentan analizar puntos aleatorios del kernel. El nombre que se da a los puntos de trazado dinámico en Linux es "kprobes", y su impacto en el rendimiento ya fue optimizado en Linux 2.6.34.
Los puntos de trazado estáticos, en cambio, son insertados por los desarrolladores en puntos estratégicos del código. Por ejemplo, Ext4 tiene 50 puntos de trazado estático. Esos puntos son compilados junto al resto del kernel, y por defecto están desactivados - nadie los invoca hasta que alguien los active. Básicamente, una condición "if" que comprueba una variable. El impacto en el rendimiento es apenas notable, pero puede mejorarse, y eso es lo que se hace con "jump label": Se insertan instrucciones de CPU "no operación" en lugar de la comprobación condicional. De modo que un punto de trazado estático tiene sobrecarga cero. (Consejo: Puede utilizar el comando "sudo perf list" para ver la lista completa de puntos de trazado estático disponibles en su sistema)
· Novedades en Btrfs:
· Cacheado de la información de espacio libre en el disco: En esta versión, Btrfs almacena la información sobre las partes del disco que están libres en el propio disco, lo cual hace que cachear un grupo de bloques sea más rápido. Hasta ahora, cuando había que hacer asignaciones de espacio de un grupo de bloques que no había sido cacheado previamente, se tenía que escanear el árbol de extents (que representa las zonas del disco utilizadas por los archivos) por completo, para representar en las estructuras de memoria las zonas libres del disco. Ahora el espacio libre se escribe en el disco cada vez que se realiza una transacción. Esto supone un cambio en el formato de disco, pero no hay problemas de compatibilidad con los viejos kernels, ya que continuarán funcionando igualmente, con la diferencia de que generarán el caché del modo antiguo. También hay que tener en cuenta que esta característica está por el momento desactivada y tiene que activarse con la opción -o space_cache. También hay una opción -o clear_cache, útil solo para casos de depuración, que limpia los caches.
· Creación asíncrona de snapshots: Esto permite evitar tener que esperar a que un nuevo snapshot sea escrito al disco. Ha sido desarrollado teniendo en cuenta al demonio del sistema de archivos de Ceph, pero también está disponible para cualquier usuario añadiendo "async" al comando "btrfs subvolume snapshot"
· Permitir que un usuario sin privilegios elimine un subvolumen. Requiere utilizar la opción de montaje -o user_subvol_rm_allowed
· Cambiar el buffer de extents de un red-black tree a un radix tree, y utilizar RCU en lugar de spinlocks, lo cual mejora el rendimiento en algunos casos.
· Refinar la asignación de chunks: Soporte para grupos de bloques que puedan albergar datos+metadatos a la vez (util en dispositivos con poco almacenamiento), no asignar los chunks tan agresivamente (evita fallos de -ENOSPC debido a la sobreasignación de espacio para metadatos)
· Mejoras de perf probe: En esta versión se ha añadido soporte para mostrar las variables locales y globales en un punto determinado del código, mediante la opción "-V" (o "--vars"). Esto ayuda a buscar las variables locales que están disponible como argumentos de un evento determinado. Por ejemplo: "# perf probe -V call_timer_fn:23", mostrará las variables locales disponibles en ese punto de esa función. También es posible mostrar las variables globales con el parámetro "--externs". También se ha añadido soporte para analizar los módulos utilizando el parámetro "--module". Por ejemplo. "# ./perf probe --module drm drm_vblank_info:3 node m"
· Mejoras de gestión de energía: Compresión de la imagen de hibernación con LZO, autosuspensiones retrasadas:
· Autosuspensiones retrasadas: Esta es una característica que mejora a otra añadida en Linux 2.6.32, "runtime power management". Sin embargo, algunos drivers no quieren suspender el dispositivo tan pronto como sea posible, quieren que antes haya un periodo mínimo. Esto es lo que implementa esta característica.
· Compresión de la imagen de hibernación con LZO, que ayuda a comprimir y descomprimir más rápido la imagen.
· Soporte de PPP sobre IPv4: Esta versión incluye soporte de PPP sobre IPv4. Comparado con las implementaciones en espacio de usuario (poptop/pptpclient), mejora dramáticamente el rendimiento de las conexiones pptp vpn y reduce el consumo de CPU. Hay un proyecto accel-pptp project para utilizar este módulo.
Esta es la lista de novedades más importantes. La lista completa, en inglés, como siempre en este enlace.
9 de diciembre de 2010
Chrome OS
En realidad, más que "Chrome OS" debería llamarse "Chrome Browser", porque eso es lo que es y nada más. Google ha centrado todo su marketing en alabar la simplicidad de su idea, de venderlo como "Quitamos lo prescindible y dejamos lo esencial", pero lo cierto es que por esa regla de tres, Ubuntu puede definirse como "ChromeOS con muchas más cosas".
¿Cómo es Chrome OS? Un servidor lo ha probado y se cree humildemente capacitado para describirlo con algo más de detalle de lo que se ha visto por ahí. Técnicamente, consiste en convertir al navegador en el shell de escritorio. Nada más abrirlo, hay una ventana de Chrome que ocupa toda la pantalla. No se puede maximizar ni minimizar ni cerrar: no existen botones para ello, de hecho han sido sustituidos por un reloj con la hora, un icono que permite configurar la red, y otro informar del estado de la batería y apagar el equipo. Hay un gestor de ventanas cuyo único propósito es mantener todo tal como se ha descrito, incluido reiniciar el shell - el navegador- si intentas matarlo o muere por algún fallo. Si sueñas con algo distinto...olvídate de ello.
Por lo demás, se pueden abrir nuevas instancias de Chrome ("abrir enlace en ventana nueva" funciona) que se comportan exactamente igual que la primera, y para los que quieran trastear se puede activar un shell -que se abre a pantalla completa- pulsando Control+Alt+T. Respecto a la mecánica interna de esta peculiar distribución de Linux, se ha eliminado absolutamente todo lo que no sea imprescindible para ejecutar el navegador. El logín del sistema se hace con una cuenta de Google, y los directorios de usuario -que en la práctica sirven para guardar configuraciones y poco más- por defecto son archivos cifrados que se descifran y montan en el logín.
Este sistema es la materialización de la propuesta de utopía de la computación en nubes: Lo local sólo se utiliza para hacer funcionar el navegador, el resto deben ser aplicaciones web. En el rarísimo caso de necesitar ejecutar código nativo, la gente de ChromeOS propone que se use NativeClient, o sea, ejecutarlo en una sandbox y visualizarlo en una pestaña del navegador. A mi esto último, más que "cloud computing", casi me parece persecución con saña al código nativo...
Y ahí se acaba la descripción de Chrome OS. No hay más. Y ahí está el problema: Chrome OS es tan aburrido y tan limitado, que no hay nada que decir de él. Toda aquella persona que haya usado un navegador en un SO normal, ya ha visto más de lo que verá con Chrome OS, ya han probado todo lo que les puede ofrecer y además han usado todos los "extras locales", tales como "editor gráfico de archivos de texto", "reproductor de música capaz de gestionar gigas de mp3", que no tendrán en ChromeOS. ¿Tendrá éxito comercial? Vaya usted a saber. En el momento en que haya aplicaciones web para todo tipo de necesidades (y a medida que progrese el desarrollo de Chrome navegador, es decir, del "shell de escritorio"), quizás si. Pero a día de hoy, resulta difícil pensar que pueda triunfar algo que tan solo ofrece desventajas respecto a una distro Linux normal, que es algo que ya de por si tiene desventajas respecto a otros SOs de escritorio.
¿Cómo es Chrome OS? Un servidor lo ha probado y se cree humildemente capacitado para describirlo con algo más de detalle de lo que se ha visto por ahí. Técnicamente, consiste en convertir al navegador en el shell de escritorio. Nada más abrirlo, hay una ventana de Chrome que ocupa toda la pantalla. No se puede maximizar ni minimizar ni cerrar: no existen botones para ello, de hecho han sido sustituidos por un reloj con la hora, un icono que permite configurar la red, y otro informar del estado de la batería y apagar el equipo. Hay un gestor de ventanas cuyo único propósito es mantener todo tal como se ha descrito, incluido reiniciar el shell - el navegador- si intentas matarlo o muere por algún fallo. Si sueñas con algo distinto...olvídate de ello.
Por lo demás, se pueden abrir nuevas instancias de Chrome ("abrir enlace en ventana nueva" funciona) que se comportan exactamente igual que la primera, y para los que quieran trastear se puede activar un shell -que se abre a pantalla completa- pulsando Control+Alt+T. Respecto a la mecánica interna de esta peculiar distribución de Linux, se ha eliminado absolutamente todo lo que no sea imprescindible para ejecutar el navegador. El logín del sistema se hace con una cuenta de Google, y los directorios de usuario -que en la práctica sirven para guardar configuraciones y poco más- por defecto son archivos cifrados que se descifran y montan en el logín.
Este sistema es la materialización de la propuesta de utopía de la computación en nubes: Lo local sólo se utiliza para hacer funcionar el navegador, el resto deben ser aplicaciones web. En el rarísimo caso de necesitar ejecutar código nativo, la gente de ChromeOS propone que se use NativeClient, o sea, ejecutarlo en una sandbox y visualizarlo en una pestaña del navegador. A mi esto último, más que "cloud computing", casi me parece persecución con saña al código nativo...
Y ahí se acaba la descripción de Chrome OS. No hay más. Y ahí está el problema: Chrome OS es tan aburrido y tan limitado, que no hay nada que decir de él. Toda aquella persona que haya usado un navegador en un SO normal, ya ha visto más de lo que verá con Chrome OS, ya han probado todo lo que les puede ofrecer y además han usado todos los "extras locales", tales como "editor gráfico de archivos de texto", "reproductor de música capaz de gestionar gigas de mp3", que no tendrán en ChromeOS. ¿Tendrá éxito comercial? Vaya usted a saber. En el momento en que haya aplicaciones web para todo tipo de necesidades (y a medida que progrese el desarrollo de Chrome navegador, es decir, del "shell de escritorio"), quizás si. Pero a día de hoy, resulta difícil pensar que pueda triunfar algo que tan solo ofrece desventajas respecto a una distro Linux normal, que es algo que ya de por si tiene desventajas respecto a otros SOs de escritorio.
Suscribirse a:
Entradas (Atom)