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.
9 de diciembre de 2010
22 de noviembre de 2010
Buenas y malas noticias en la compra de Novell
La retahíla de ventas empresariales que inició la crisis se ha llevado por delante a otra de las grandes candidatas que se murmuraban últimamente: Novell, histórica compañía de IT donde las haya, y dueña de SUSE Linux.
El comprador, "Attachmate Corporation", va a pagar 2.200$ milloncejos por ella. De esa cantidad hay que sustraer los 450 que les va a dar un consorcio liderado por Microsoft a cambio de su propiedad intelectual. Estas son las "malas noticias": Novell posee cientos de patentes (882 en total) relacionadas con las tecnologías que la hicieron famosa: redes (en su sentido más original), servicios de directorio, y cosas así. Del tipo de cosas que todo SO lleva haciendo desde hace décadas. ¡Sin olvidar el famoso copyright de Unix que reclamaba SCO! Si, UNIX podría pasar en su sentido legal a manos de Microsoft (no está claro si traspasan toda la propiedad intelectual o sólo patentes).
Una verdadera joya legal que Microsoft se mete en el bolsillo por cuatro duros: en el famoso trato de patentes con Novell/SUSE ya tuvieron que apoquinar 348$ millones, y en esta ocasión van a pagar 450$ millones, apenas 100 más, por meterse las patentes en cuestión en el bolsillo, con la posibilidad de recuperarlos con creces haciendo el tipo de cosas que las multinacionales de software suelen hacer con las patentes. Casi mejor no pensar lo que puede venirnos encima.
Respecto a la empresa en si, va a ser dividida en Novell y SUSE. Vuelta a los orígenes. En realidad, SUSE era la única división de Novell "sana", era la única que crecía con fuerza, las demás poco a poco iban hundiéndose. Esta es la parte buena de la noticia: Que SUSE sea tratada con miramientos y puesta en una división para ella sola es señal de que los compradores creen en ella y conocen su valor (Icaza ya anuncia que Mono seguirá desarrollándose como antes). Veremos que tal les va a partir de ahora.
El comprador, "Attachmate Corporation", va a pagar 2.200$ milloncejos por ella. De esa cantidad hay que sustraer los 450 que les va a dar un consorcio liderado por Microsoft a cambio de su propiedad intelectual. Estas son las "malas noticias": Novell posee cientos de patentes (882 en total) relacionadas con las tecnologías que la hicieron famosa: redes (en su sentido más original), servicios de directorio, y cosas así. Del tipo de cosas que todo SO lleva haciendo desde hace décadas. ¡Sin olvidar el famoso copyright de Unix que reclamaba SCO! Si, UNIX podría pasar en su sentido legal a manos de Microsoft (no está claro si traspasan toda la propiedad intelectual o sólo patentes).
Una verdadera joya legal que Microsoft se mete en el bolsillo por cuatro duros: en el famoso trato de patentes con Novell/SUSE ya tuvieron que apoquinar 348$ millones, y en esta ocasión van a pagar 450$ millones, apenas 100 más, por meterse las patentes en cuestión en el bolsillo, con la posibilidad de recuperarlos con creces haciendo el tipo de cosas que las multinacionales de software suelen hacer con las patentes. Casi mejor no pensar lo que puede venirnos encima.
Respecto a la empresa en si, va a ser dividida en Novell y SUSE. Vuelta a los orígenes. En realidad, SUSE era la única división de Novell "sana", era la única que crecía con fuerza, las demás poco a poco iban hundiéndose. Esta es la parte buena de la noticia: Que SUSE sea tratada con miramientos y puesta en una división para ella sola es señal de que los compradores creen en ella y conocen su valor (Icaza ya anuncia que Mono seguirá desarrollándose como antes). Veremos que tal les va a partir de ahora.
19 de noviembre de 2010
Novedades en systemd, II
La última vez que Leenart Poettering habló sobre las últimas novedades incorporadas en el desarrollo de systemd, este blog se hizo eco. Ahora que D. Lennart ha publicado una nueva compilación de novedades incorporadas en los últimos meses lo justo es volver a hacer lo mismo.
La principal novedad, que no se menciona en el blog, es que al final systemd no fue incluído en Fedora 14 y lo será en Fedora 15. A pesar del legítimo enfado de su autor, este retraso tiene la ventaja de que podrán tener tiempo para implementar un puñado de cosas que había dejado temporalmente de lado por motivos de estabilidad. Como viene a demostrarse en los cambios implementados en los últimos dos meses:
· systemd es capaz de iniciar el sistema sin ningún script shell de por medio (exceptuando algunas configuraciones y casos atípicos). Por lo visto, esto hace ganar algunos segundos en el inicio, y además hace que el inicio sea mucho más "limpio" estéticamente (el primer número de PID disponible nada más iniciar es mucho más bajo)
· Se ha implementado un apagado del sistema totalmente en C, capaz de gestionar la matanza de procesos, desmontado de sistema de archivos, dispositivos loop y volúmenes de manera correcta. A diferencia, al parecer, de los scripts shell, que no tienen en cuenta las dependencias que ese tipo de actividades pueden tener entre ellas.
· systemd ha implementado un sistema de readahead, capaz también de defragmentar en sistemas de archivos Btrfs.
· systemd es capaz de administrar la ejecución de fsck y las quotas de usuario.
· Cada servicio, usuario y sesión tiene su propio cgroup. Este es el equivalente al "parche mágico de 200 líneas" que tantas portadas ha llenado estos días. Este sistema tiene el efecto de que si un servicio ejecuta 100 hijos ejecutando un loop cerrado, y un usuario en el escritorio ejecuta una aplicación haciendo lo mismo, los 100 procesos tendrán un 50% de CPU a repartirse entre todos, y la aplicación de escritorio el otro 50%.
· systemd provee desde su inicio el socket /dev/log desde el inicio del sistema. Si syslog aun no se está iniciando, los mensajes se envían al buffer de dmesg. Cuando syslog se inicia, recoge en su log el dmesg y por tanto también todos los mensajes enviados a /dev/log. Cuando syslog se apaga, se vuelve a redirigir /dev/log a dmesg. Se garantiza la disponibilidad de logs desde el primer al último instante.
· systemd es capaz de cargar políticas de SELinux. Lo cual, por lo visto, permite soportar inicios con y sin initrd, que al parecer es importante.
· El locale del sistema es configurado (como variables de entorno del proceso) en el PID 1 y por lo tanto heredado por todos los hijos, es decir, todos los procesos del sistema.
· systemd soporta discos encriptados, tanto como si son parte del inicio, como si son memorias USB con el contenido encriptado. Para ello han creado una infraestructura básica capaz de preguntar la clave en en X11 o en la consola (¡incluso ahí te avisan mediante wall(1)! ), según haga falta.
· Una especie de sistema de plugins (es como ha sido implementado el soporte de discos encriptados).
· Limpieza automática de directorios temporales.
· Cada vez que se inicia el sistema, systemd escribe al log cuánto ha tardado el sistema, y qué parte de esa ha sido en iniciarse el kernel y cual en iniciar los servicios.
· systemd se encarga de matar todos los procesos de una sesión de un usuario cuando se sale de ella. Era algo de lo que hasta ahora no se preocupaba absolutamente nadie y que causaba que procesos de usuario se quedaran sueltos por ahí hasta el mismo momento del reinicio.
· Se pueden enlazar archivos de servicios a /dev/null para desactivarlos por completo.
· Se pueden activar unidades (el archivo básico de configuración de systemd) si un directorio está vacío o si está presente una determinada opción en la línea de comandos del kernel.
· Se puede reiniciar el systema mediante kexec.
En fin, que systemd se está convirtiendo en toda una joya. Y todavía le queda mucho para lograr sus objetivos, entre los cuales se encuentra reemplazar a gnome-session como sistema de inicio de sesión...
La principal novedad, que no se menciona en el blog, es que al final systemd no fue incluído en Fedora 14 y lo será en Fedora 15. A pesar del legítimo enfado de su autor, este retraso tiene la ventaja de que podrán tener tiempo para implementar un puñado de cosas que había dejado temporalmente de lado por motivos de estabilidad. Como viene a demostrarse en los cambios implementados en los últimos dos meses:
· systemd es capaz de iniciar el sistema sin ningún script shell de por medio (exceptuando algunas configuraciones y casos atípicos). Por lo visto, esto hace ganar algunos segundos en el inicio, y además hace que el inicio sea mucho más "limpio" estéticamente (el primer número de PID disponible nada más iniciar es mucho más bajo)
· Se ha implementado un apagado del sistema totalmente en C, capaz de gestionar la matanza de procesos, desmontado de sistema de archivos, dispositivos loop y volúmenes de manera correcta. A diferencia, al parecer, de los scripts shell, que no tienen en cuenta las dependencias que ese tipo de actividades pueden tener entre ellas.
· systemd ha implementado un sistema de readahead, capaz también de defragmentar en sistemas de archivos Btrfs.
· systemd es capaz de administrar la ejecución de fsck y las quotas de usuario.
· Cada servicio, usuario y sesión tiene su propio cgroup. Este es el equivalente al "parche mágico de 200 líneas" que tantas portadas ha llenado estos días. Este sistema tiene el efecto de que si un servicio ejecuta 100 hijos ejecutando un loop cerrado, y un usuario en el escritorio ejecuta una aplicación haciendo lo mismo, los 100 procesos tendrán un 50% de CPU a repartirse entre todos, y la aplicación de escritorio el otro 50%.
· systemd provee desde su inicio el socket /dev/log desde el inicio del sistema. Si syslog aun no se está iniciando, los mensajes se envían al buffer de dmesg. Cuando syslog se inicia, recoge en su log el dmesg y por tanto también todos los mensajes enviados a /dev/log. Cuando syslog se apaga, se vuelve a redirigir /dev/log a dmesg. Se garantiza la disponibilidad de logs desde el primer al último instante.
· systemd es capaz de cargar políticas de SELinux. Lo cual, por lo visto, permite soportar inicios con y sin initrd, que al parecer es importante.
· El locale del sistema es configurado (como variables de entorno del proceso) en el PID 1 y por lo tanto heredado por todos los hijos, es decir, todos los procesos del sistema.
· systemd soporta discos encriptados, tanto como si son parte del inicio, como si son memorias USB con el contenido encriptado. Para ello han creado una infraestructura básica capaz de preguntar la clave en en X11 o en la consola (¡incluso ahí te avisan mediante wall(1)! ), según haga falta.
· Una especie de sistema de plugins (es como ha sido implementado el soporte de discos encriptados).
· Limpieza automática de directorios temporales.
· Cada vez que se inicia el sistema, systemd escribe al log cuánto ha tardado el sistema, y qué parte de esa ha sido en iniciarse el kernel y cual en iniciar los servicios.
· systemd se encarga de matar todos los procesos de una sesión de un usuario cuando se sale de ella. Era algo de lo que hasta ahora no se preocupaba absolutamente nadie y que causaba que procesos de usuario se quedaran sueltos por ahí hasta el mismo momento del reinicio.
· Se pueden enlazar archivos de servicios a /dev/null para desactivarlos por completo.
· Se pueden activar unidades (el archivo básico de configuración de systemd) si un directorio está vacío o si está presente una determinada opción en la línea de comandos del kernel.
· Se puede reiniciar el systema mediante kexec.
En fin, que systemd se está convirtiendo en toda una joya. Y todavía le queda mucho para lograr sus objetivos, entre los cuales se encuentra reemplazar a gnome-session como sistema de inicio de sesión...
Suscribirse a:
Entradas (Atom)