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...
12 de noviembre de 2010
En defensa de X.org
Entre la última entrada y los planes de Ubuntu -cuyo anuncio fue claramente planificado para fastidiar mi entrada- de usar Wayland en el futuro, se han dejado oir mil voces contra X.org. No tendría nada de malo (yo también lo hice un poco) si no fuera porque se han vuelto a repetir los mismos tópicos sobre la lentitud de X.org, sin especificar por qué razón en concreto. O, peor aun, achacándoselo a la "transparencia de red", el recurso favorito de quienes no tienen mucha idea de cómo funcionan las X.
Aunque fue diseñado como un protocolo, a X11 no hay que verlo como tal, sino más bien como una API cualquiera, expuesta por el servidor y utilizada por los clientes. En un sistema remoto, la librería libX11 abstrae las llamadas a esa API y las envía a través de red, pero en un sistema local se envían a través de un socket Unix. Que son muy rápidos, más que suficiente para implementar un sistema gráfico de alto rendimiento. ¿Adivinen que sistema de IPC utiliza Wayland para comunicar a los clientes con el servidor? Exacto, sockets Unix. De hecho, no sería difícil hacer que Wayland funcionara a través de un socket de red (aunque haría falta algún protocolo adicional para comunicar los buffers).
Es cierto que X11 es un protocolo anticuado, pero no es menos cierto se ha conservado bastante bien: No hubiera durado tanto de no ser así. Si, incluye cosas obsoletas y estúpidas como el dibujado de fuentes dentro del servidor, pero a día de hoy nadie utiliza eso (las aplicaciones dibujan las fuentes en su propia ventana mediante freetype, ignorando por completo la API original de X11). Lo mismo con las operaciones gráficas (se recurre a Cairo). Para estar al día han sido necesarias las famosas extensiones, que en realidad son un ingenioso sistema para extender el protocolo (la API) sin romper la compatibilidad. Las extensiones pueden ser bastante radicales en cuanto a los nuevos modelos que introducen, por ejemplo, la extensión XRender se presentó como "un nuevo modelo de renderizado para X", y en la práctica, aunque sea retrocompatible, efectivamente viene a ser un servidor gráfico nuevo. Igual de radicales son la extensión Composite, Damage, Randr o DRI2. Incluso hay una extensión XFixes, cuyo objetivo es resolver problemas en el core de X11. Por extender, hasta sería posible intentar introducir un hipotético X12 como una extensión de X11.
Con esto quiero decir que X.org no está especialmente anticuado: parcheado hasta la saciedad si (lo cual no equivale a "bloated": mi /usr/bin/Xorg pesa tan solo 1.6M, y las extensiones no son mucho más grande), pero no "anticuado", al menos en el sentido de obsoleto. En la práctica, lo que más ha determinado el mal rendimiento de X.org han sido los drivers. X.org tiene un montón de código, una especie de subsistema, que los drivers utilizan para implementar las peticiones gráficas del servidor. Esta arquitectura y los drivers nunca han terminado de madurar, hace relativamente poco que se empezó a invertir en drivers libres para Linux, y gran parte de ese tiempo se ha dedicado a implementar KMS/GEM (el driver de Intel incluso perdió rendimiento en la transición). Es triste decir que aun hoy, hay tookits que en algunos casos son más rápidos haciendo por software lo que XRender hace mediante aceleración por hardware (además, XRender no tiene manera de notificar si los drivers están acelerando por hardware una operación gráfica o si se está recurriendo a un "fallback" de software, por lo que los toolkits algunas veces pasan de atreverse a usar XRender)
Pero si estuviera bien implementado, si hubiera una buena arquitectura y unos buenos drivers, un escritorio X.org no tendría grandes problemas de rendimiento. Hubo un intento (Xgl, del mismo autor de Compiz) de implementar el servidor X.org sobre OpenGL (básicamente, sustituir los drivers por Mesa), tras él hubo un intento de hacerlo de otra manera (Glucose). También hay quien ha experimentado con hacer con un Cairo-drm (con resultados muy prometedores). Ninguno de ellos maduró -y no porque no fueran buenas ideas-, pero hay que tener presente que nada, absolutamente nada de esto indica un problema en X11 como protocolo/API. De hecho, de haber tenido éxito quizás Wayland no existiría.
Con todo esto quiero decir que el principal problema de los gráficos en Linux es, y seguirá siendo, los drivers. Wayland tiene razón de ser, pero es solo una minúscula pieza de todo el sistema (9.332 líneas de código, incluyendo ejemplos). Para dibujar utiliza OpenGL-ES/Mesa, que no va a ser mágicamente mejor por el hecho de utilizarla un servidor gráfico nuevo, y cuyos drivers están sufriendo o van a sufrir reescrituras masivas debido a Gallium3D. La ventaja es que Wayland puede provocar un revulsivo que de más impulso a Mesa, a los toolkits y al resto de proyectos implicados, pero por lo demás, X.org no está tan maldito como algunos quieren hacer creer.
Aunque fue diseñado como un protocolo, a X11 no hay que verlo como tal, sino más bien como una API cualquiera, expuesta por el servidor y utilizada por los clientes. En un sistema remoto, la librería libX11 abstrae las llamadas a esa API y las envía a través de red, pero en un sistema local se envían a través de un socket Unix. Que son muy rápidos, más que suficiente para implementar un sistema gráfico de alto rendimiento. ¿Adivinen que sistema de IPC utiliza Wayland para comunicar a los clientes con el servidor? Exacto, sockets Unix. De hecho, no sería difícil hacer que Wayland funcionara a través de un socket de red (aunque haría falta algún protocolo adicional para comunicar los buffers).
Es cierto que X11 es un protocolo anticuado, pero no es menos cierto se ha conservado bastante bien: No hubiera durado tanto de no ser así. Si, incluye cosas obsoletas y estúpidas como el dibujado de fuentes dentro del servidor, pero a día de hoy nadie utiliza eso (las aplicaciones dibujan las fuentes en su propia ventana mediante freetype, ignorando por completo la API original de X11). Lo mismo con las operaciones gráficas (se recurre a Cairo). Para estar al día han sido necesarias las famosas extensiones, que en realidad son un ingenioso sistema para extender el protocolo (la API) sin romper la compatibilidad. Las extensiones pueden ser bastante radicales en cuanto a los nuevos modelos que introducen, por ejemplo, la extensión XRender se presentó como "un nuevo modelo de renderizado para X", y en la práctica, aunque sea retrocompatible, efectivamente viene a ser un servidor gráfico nuevo. Igual de radicales son la extensión Composite, Damage, Randr o DRI2. Incluso hay una extensión XFixes, cuyo objetivo es resolver problemas en el core de X11. Por extender, hasta sería posible intentar introducir un hipotético X12 como una extensión de X11.
Con esto quiero decir que X.org no está especialmente anticuado: parcheado hasta la saciedad si (lo cual no equivale a "bloated": mi /usr/bin/Xorg pesa tan solo 1.6M, y las extensiones no son mucho más grande), pero no "anticuado", al menos en el sentido de obsoleto. En la práctica, lo que más ha determinado el mal rendimiento de X.org han sido los drivers. X.org tiene un montón de código, una especie de subsistema, que los drivers utilizan para implementar las peticiones gráficas del servidor. Esta arquitectura y los drivers nunca han terminado de madurar, hace relativamente poco que se empezó a invertir en drivers libres para Linux, y gran parte de ese tiempo se ha dedicado a implementar KMS/GEM (el driver de Intel incluso perdió rendimiento en la transición). Es triste decir que aun hoy, hay tookits que en algunos casos son más rápidos haciendo por software lo que XRender hace mediante aceleración por hardware (además, XRender no tiene manera de notificar si los drivers están acelerando por hardware una operación gráfica o si se está recurriendo a un "fallback" de software, por lo que los toolkits algunas veces pasan de atreverse a usar XRender)
Pero si estuviera bien implementado, si hubiera una buena arquitectura y unos buenos drivers, un escritorio X.org no tendría grandes problemas de rendimiento. Hubo un intento (Xgl, del mismo autor de Compiz) de implementar el servidor X.org sobre OpenGL (básicamente, sustituir los drivers por Mesa), tras él hubo un intento de hacerlo de otra manera (Glucose). También hay quien ha experimentado con hacer con un Cairo-drm (con resultados muy prometedores). Ninguno de ellos maduró -y no porque no fueran buenas ideas-, pero hay que tener presente que nada, absolutamente nada de esto indica un problema en X11 como protocolo/API. De hecho, de haber tenido éxito quizás Wayland no existiría.
Con todo esto quiero decir que el principal problema de los gráficos en Linux es, y seguirá siendo, los drivers. Wayland tiene razón de ser, pero es solo una minúscula pieza de todo el sistema (9.332 líneas de código, incluyendo ejemplos). Para dibujar utiliza OpenGL-ES/Mesa, que no va a ser mágicamente mejor por el hecho de utilizarla un servidor gráfico nuevo, y cuyos drivers están sufriendo o van a sufrir reescrituras masivas debido a Gallium3D. La ventaja es que Wayland puede provocar un revulsivo que de más impulso a Mesa, a los toolkits y al resto de proyectos implicados, pero por lo demás, X.org no está tan maldito como algunos quieren hacer creer.
10 de noviembre de 2010
Red Hat 6
Red Hat acaba de anunciar la publicación de Red Hat 6. No dejaría de ser una noticia más sobre distros si no fuera porque Red Hat es la punta de lanza de la implantación comercial del software libre y el mayor contribuidor de código de varios proyectos críticos.
Técnicamente, Red Hat 6 no ofrece ninguna novedad para quienes seguimos la evolución de la distros de Linux, pero para quienes usan Red Hat 5 -publicada en 2005, con kernel Linux 2.6.18- supone enfrentarse de repente a las novedades de los últimos 3 años (¡gestor de procesos CFS!), y también supone que otros SOs comerciales pasarán a tener que compararse con esta versión en benchmarks.
Quien busque información, aquí hay material promocional de todo tipo.
Técnicamente, Red Hat 6 no ofrece ninguna novedad para quienes seguimos la evolución de la distros de Linux, pero para quienes usan Red Hat 5 -publicada en 2005, con kernel Linux 2.6.18- supone enfrentarse de repente a las novedades de los últimos 3 años (¡gestor de procesos CFS!), y también supone que otros SOs comerciales pasarán a tener que compararse con esta versión en benchmarks.
Quien busque información, aquí hay material promocional de todo tipo.
4 de noviembre de 2010
El estado de Wayland, aspirante a reemplazar X.org
La última vez que se mencionó en este blog al servidor gráfico Wayland, fue con la descripción de "revolucionario y raquítico a la vez". No era una apreciación del todo errónea; tengo la manía de clonar los repositorios de proyectos interesantes para ojear de vez en cuando su actividad, y como proyecto con la no precisamente leve vocación de ser alternativa a X.org, la evolución de Wayland no era muy esperanzadora (13 commits en 8 meses, todos menos dos de su creador). Me equivocaba, fue escribir esa entrada y aumentar el número de commits y buenas noticias.
Aunque la actividad no se haya disparado por las nubes, en los últimos meses se ha visto que Wayland progresa más rápido de lo esperado. Para empezar, MeeGo tiene interés en él a largo plazo para usarlo como servidor gráfico en dispositivos móviles-táctiles (un detalle interesante es que Kristian Høgsberg, el autor, creó Wayland en la época en que trabajaba en Red Hat, pero no como algo de la compañía, sino durante su tiempo libre, mientras que ahora trabaja en Intel, en parte en Wayland). Pero lo más determinante para el futuro de Wayland no es algo que esté ocurriendo en su código. Lo más difícil para un proyecto así es conseguir apoyo de los toolkits y proyectos relacionados con el escritorio. Yo creía que se tardarían años en ver progresos en este sentido, pero ha resultado ser al contrario: Ya se están portando QT, GTK y Clutter (capturas). Claro que, teniendo en cuenta el enormemente intrincado mundo del vídeo es difícil imaginar una transición fácil y breve. Pero incluso para eso hay buenas noticias, Wayland puede usarse para mostrar servidores X completamente funcionales, lo cual permitiría compatibilidad al estilo de XQuartz (X11 sobre OS X).
Probablemente, parte de la aparente sencillez en portar QT y GTK se debe a su diseño (eso, y que en el mundo gráfico de Linux hay cada vez más inversión). Wayland es muy simple, se limita compartir buffers de memoria con las aplicaciones clientes, las cuales notifican a Wayland de los cambios, quien a su vez envía la imagen final al hardware vía OpenGL ES. Esa función de coordinador de buffers, mas el envio de eventos desde dispositivos de entrada a las ventanas, son prácticamente sus únicas funciones, por eso es tan pequeño, simple e ideal para dispositivos táctiles. El renderizado de las ventanas en si, en el que X.org, con su anticuado diseño, trata de tomar parte (la propia API nativa de dibujado, las obsoletas fuentes en el servidor, extensiones como Composite para hacer posible software como Compiz), se deja completamente en manos del cliente.
Afortunadamente, todos los toolkits modernos están diseñados para funcionar de acorde con lo que Wayland espera, por lo cual portarlos significa (a los ojos de este humilde servidor no experto en gráficos) implementar el código que envie los contenidos a Wayland, e interactuar con él cuando hay que redibujar algo. El divorcio con X.org es tal, que el concepto de "gráficos a través de la red" del protocolo X11 en realidad no queda excluido ni obsoleto, pasa a ser asunto de las aplicaciones clientes, como algo opcional.
Todo esto suena muy bien para Wayland, y hay que tener en cuenta que este servidor no es por si mismo una revolución, más bien es el punto final a todas las novedades de los últimos años en APIs de acceso a hardware (KMS) y las novedades y capacidades de los toolkits y el progreso en Mesa: Wayland es el broche final que une ambos mundos de manera correcta, prescindiendo del obsoleto X.org. Pero tampoco hay que darlo todo por hecho: Imaginen que a alguien se le ocurre añadir una extensión a X.org implementando algo similar. En un mundo tan atacado por el relativismo moral, no hay que descartar semejantes desvaríos.
(PD: Ubuntu ha anunciado, precisamente justo después de publicar esta entrada, que pretende usar Wayland en el futuro)
Aunque la actividad no se haya disparado por las nubes, en los últimos meses se ha visto que Wayland progresa más rápido de lo esperado. Para empezar, MeeGo tiene interés en él a largo plazo para usarlo como servidor gráfico en dispositivos móviles-táctiles (un detalle interesante es que Kristian Høgsberg, el autor, creó Wayland en la época en que trabajaba en Red Hat, pero no como algo de la compañía, sino durante su tiempo libre, mientras que ahora trabaja en Intel, en parte en Wayland). Pero lo más determinante para el futuro de Wayland no es algo que esté ocurriendo en su código. Lo más difícil para un proyecto así es conseguir apoyo de los toolkits y proyectos relacionados con el escritorio. Yo creía que se tardarían años en ver progresos en este sentido, pero ha resultado ser al contrario: Ya se están portando QT, GTK y Clutter (capturas). Claro que, teniendo en cuenta el enormemente intrincado mundo del vídeo es difícil imaginar una transición fácil y breve. Pero incluso para eso hay buenas noticias, Wayland puede usarse para mostrar servidores X completamente funcionales, lo cual permitiría compatibilidad al estilo de XQuartz (X11 sobre OS X).
Probablemente, parte de la aparente sencillez en portar QT y GTK se debe a su diseño (eso, y que en el mundo gráfico de Linux hay cada vez más inversión). Wayland es muy simple, se limita compartir buffers de memoria con las aplicaciones clientes, las cuales notifican a Wayland de los cambios, quien a su vez envía la imagen final al hardware vía OpenGL ES. Esa función de coordinador de buffers, mas el envio de eventos desde dispositivos de entrada a las ventanas, son prácticamente sus únicas funciones, por eso es tan pequeño, simple e ideal para dispositivos táctiles. El renderizado de las ventanas en si, en el que X.org, con su anticuado diseño, trata de tomar parte (la propia API nativa de dibujado, las obsoletas fuentes en el servidor, extensiones como Composite para hacer posible software como Compiz), se deja completamente en manos del cliente.
Afortunadamente, todos los toolkits modernos están diseñados para funcionar de acorde con lo que Wayland espera, por lo cual portarlos significa (a los ojos de este humilde servidor no experto en gráficos) implementar el código que envie los contenidos a Wayland, e interactuar con él cuando hay que redibujar algo. El divorcio con X.org es tal, que el concepto de "gráficos a través de la red" del protocolo X11 en realidad no queda excluido ni obsoleto, pasa a ser asunto de las aplicaciones clientes, como algo opcional.
Todo esto suena muy bien para Wayland, y hay que tener en cuenta que este servidor no es por si mismo una revolución, más bien es el punto final a todas las novedades de los últimos años en APIs de acceso a hardware (KMS) y las novedades y capacidades de los toolkits y el progreso en Mesa: Wayland es el broche final que une ambos mundos de manera correcta, prescindiendo del obsoleto X.org. Pero tampoco hay que darlo todo por hecho: Imaginen que a alguien se le ocurre añadir una extensión a X.org implementando algo similar. En un mundo tan atacado por el relativismo moral, no hay que descartar semejantes desvaríos.
(PD: Ubuntu ha anunciado, precisamente justo después de publicar esta entrada, que pretende usar Wayland en el futuro)
27 de octubre de 2010
Fricciones Gnomeras
No es que las relaciones entre Canonical/Ubuntu y Gnome fueran tan perfectas como se cree, pero en una sola semana han surgido un par de asuntos que ha disparado y seguirá disparando la tensión entre ellos. El primero y más comentado es la adopción del shell Unity no ya como alternativa a Gnome Shell, sino al gnome-panel de toda la vida. Teniendo en cuenta que la novedad más importante de Gnome 3 es el cambio de shell -también lo fue en KDE4, no nos engañemos-, esto representa una divergencia de mentalidades de difícil solución.
Por lo que se puede leer por ahí, que muchos Gnomeros no están nada contentos con esta decisión. Como se trata de software libre y lo único que pueden hacer es fastidiarse, las críticas se han dirigido al lugar previsible: acusar a Canonical de no tener espíritu de comunidad. Pero, como ha explicado Shuttleworth, el problema se debe a divergencias técnicas. Ellos quieren una barra de menús global -al estilo OS X-, y la gente de Gnome no. Ellos consideran que Mutter (el gestor de ventanas de Gnome Shell) es lento y prefieren Compiz, Gnome no. Asi que Canonical ha desarrollado Unity, y despues de probar con Mutter se han pasado a Compiz, que por lo visto es más rápido.
Y yo me pregunto: ¿Por qué Canonical es aquí el malo? La barra de menús global es una idea aceptable, pero ante todo es una idea puesta en práctica y muy trillada. ¿Por qué debería Canonical renunciar a ello sólo porque a otras personas de Gnome no les guste? Este problema -dos requisitos que chocan entre sí- es una situación crítica que ha destruido no pocos proyectos de software libre, y que en el kernel Linux se ha resuelto tradicionalmente con pragmatismo: Permitir ambas opciones. Está claro que la solución óptima es que Gnome Shell pueda configurarse para utilizar menús globales o individuales, o que al menos pueda personalizarse fácilmente la UI para permitir una opción u otra. No conozco los detalles de los flames entre la gente de Canonical y Gnome/GTK, pero si Canonical no tenía otra salida, hizo bien creando Unity. Por otro lado, Unity tiene un lado muy negativo, y es que Canonical requiere asignación de copyright a las contribuciones de sus proyectos (mal, muy mal).
Además de esto, hay otro punto de fricción entre Gnome y Canonical. Le ha causado Matt Zimmerman, Chief Technological Officer de Canonical, o sea, el tipo que en última instancia toma decisiones tecnológicas y organiza a los desarrolladores. Este señor ha dicho en su blog que QT -si, la QT que usa KDE- es un gran toolkit, que es una gran plataforma para los desarrolladores y que Ubuntu la tendrá en cuenta como alternativa. Pero no sólo él piensa que QT es un buen toolkit, el propio Shuttleworth dice, mientras habla de un asunto de licencias, que Gtk "se ha estancado", mientras que QT no. Que los líderes de la principal distro Gnome digan algo así tiene su cosa...
Por lo que se puede leer por ahí, que muchos Gnomeros no están nada contentos con esta decisión. Como se trata de software libre y lo único que pueden hacer es fastidiarse, las críticas se han dirigido al lugar previsible: acusar a Canonical de no tener espíritu de comunidad. Pero, como ha explicado Shuttleworth, el problema se debe a divergencias técnicas. Ellos quieren una barra de menús global -al estilo OS X-, y la gente de Gnome no. Ellos consideran que Mutter (el gestor de ventanas de Gnome Shell) es lento y prefieren Compiz, Gnome no. Asi que Canonical ha desarrollado Unity, y despues de probar con Mutter se han pasado a Compiz, que por lo visto es más rápido.
Y yo me pregunto: ¿Por qué Canonical es aquí el malo? La barra de menús global es una idea aceptable, pero ante todo es una idea puesta en práctica y muy trillada. ¿Por qué debería Canonical renunciar a ello sólo porque a otras personas de Gnome no les guste? Este problema -dos requisitos que chocan entre sí- es una situación crítica que ha destruido no pocos proyectos de software libre, y que en el kernel Linux se ha resuelto tradicionalmente con pragmatismo: Permitir ambas opciones. Está claro que la solución óptima es que Gnome Shell pueda configurarse para utilizar menús globales o individuales, o que al menos pueda personalizarse fácilmente la UI para permitir una opción u otra. No conozco los detalles de los flames entre la gente de Canonical y Gnome/GTK, pero si Canonical no tenía otra salida, hizo bien creando Unity. Por otro lado, Unity tiene un lado muy negativo, y es que Canonical requiere asignación de copyright a las contribuciones de sus proyectos (mal, muy mal).
Además de esto, hay otro punto de fricción entre Gnome y Canonical. Le ha causado Matt Zimmerman, Chief Technological Officer de Canonical, o sea, el tipo que en última instancia toma decisiones tecnológicas y organiza a los desarrolladores. Este señor ha dicho en su blog que QT -si, la QT que usa KDE- es un gran toolkit, que es una gran plataforma para los desarrolladores y que Ubuntu la tendrá en cuenta como alternativa. Pero no sólo él piensa que QT es un buen toolkit, el propio Shuttleworth dice, mientras habla de un asunto de licencias, que Gtk "se ha estancado", mientras que QT no. Que los líderes de la principal distro Gnome digan algo así tiene su cosa...
20 de octubre de 2010
Las novedades de Linux 2.6.36
Ya se ha anunciado la versión final de Linux 2.6.36. Las principales novedades de esta versión son: Soporte de la arquitectura Tilera,
un nuevo sistema de notificación de archivos que reemplaza a inotify, un rediseño de las workqueues para aprovechar mejor la concurrencia, cacheo local de CIFS, soporte para la "gestión energética inteligente" de Intel, integración del depurador del kernel con KMS, inclusión del sistema de seguridad AppArmor, varios nuevos drivers y pequeñas mejoras.
· Soporte para la arquitectura Tilera: El procesador Tile, de Tilera Corporation, es una nueva arquitectura diseñada para ser multicore y soportar cientos de cores en un solo chip. El objetivo es conseguir una CPU de gran rendimiento y energéticamente eficiente, con más flexibilidad que los chips de propósito específico como DSPs. El chip consiste de una red mesh de 64 "tiles", en la que cada "tile" contiene un procesador de propósito general, caché, y un router que se utiliza para comunicarse con otros tiles.
· Inclusión preliminar de fanotify, una nueva interfaz de notificación de archivos: Las APIs para la notificación de eventos sucedidos sobre archivos definitivamente no han sido el punto fuerte de Linux. La cosa empezó con dnotify, que era una basura. Robert Love lo sustituyó con inotify como parte del en su día famoso "Proyecto Utopía". Sin embargo, los autores de inotify se conformaron con hacer una interfaz que les sirviera a ellos y que fuera mejor que dnotify (no muy difícil). Fnotify solventa las condiciones de carrera y problemas de escalabilidad de inotify y dnotify e incluso permite notificación con bloqueo previo. Las APIs de dnotify y inotify siguen existiendo, pero su código interno ha sido reescrito para basarse en el motor de fanotify. Se puede encontrar un ejemplo de uso de fanotify en este repositorio. Nótese que las llamadas al sistema de fanotify se encuentran desactivadas en esta versión hasta que los desarrolladores acuerden una API adecuada.
· Integración KMS+KDB: Gracias a las bondades de KMS, en esta versión será posible activar el depurador del kernel KDB estando en la misma sesión X. Presionando Sysrq-g mostrará la consola KDB, y al salir (usando el comando KDB) se volverá al escritorio. De momento, esta integración solamente está disponiblepara chips Intel. Las instrucciones para compilar y activar esta funcionalidad pueden encontrarse aquí.
· Workqueues optimizadas para la concurrencia: Las workqueues son una especie de pool de threads que permiten añadir a una cola trabajo que hacer. Sin embargo, el sistema actual permitía crear varias workqueues, las cuales podrían competir entre ellas por la CPU. En esta versión, y tal como ya se trató en este blog, se ha implementado una solución análoga al GCD de Apple: Existe un mecanismo que regula la cantidad de threads disponibles para ejecutar workqueues y encargado de distribuir los trabajos entre ellos, de modo que se optimizan los recursos.
· Soporte de la "gestión inteligente de energía" de Intel: En las plataformas con chips Intel i3/5 y gráficos integrados, existe la capacidad de sincronizar las variaciones de frecuencia de la CPU y la GPU simultáneamente para alcanzar un consumo y rendimiento concretos. En esta versión, Linux añade un driver que implementa esta funcionalidad.
· Cacheo local en CIFS: FS-Cache es una capa de cacheo que permite que los sistemas de archivos de red implementen un caché local. FS-Cache fue incluido en Linux 2.6.30 con soporte de NFS y AFS; en esta versión se ha añadido soporte para CIFS.
· Mejorar la respuesta del escritorio en casos raros: Existen algunos casos en los que un escritorio se puede volver verdaderamente inusable al utilizar un dispositivo de almacenamiento USB bajo cierta presión de memoria. En esta versión, se han corregido esos casos.
· Inclusión de AppArmor: AppArmor es un sistema de seguridad MAC que fue desarrollado inicialmente por Immunix en 1998 y ha sido utilizado por algunas distros como alternativa a SELinux. La diferencia fundamental entre ambos es que SELinux aplica políticas de seguridad a "etiquetas" que se asignan a archivos, y AppArmor aplica las políticas a las rutas de archivo.
Esto viene a ser todo. Como siempre, aquí está la lista completa.
· Soporte para la arquitectura Tilera: El procesador Tile, de Tilera Corporation, es una nueva arquitectura diseñada para ser multicore y soportar cientos de cores en un solo chip. El objetivo es conseguir una CPU de gran rendimiento y energéticamente eficiente, con más flexibilidad que los chips de propósito específico como DSPs. El chip consiste de una red mesh de 64 "tiles", en la que cada "tile" contiene un procesador de propósito general, caché, y un router que se utiliza para comunicarse con otros tiles.
· Inclusión preliminar de fanotify, una nueva interfaz de notificación de archivos: Las APIs para la notificación de eventos sucedidos sobre archivos definitivamente no han sido el punto fuerte de Linux. La cosa empezó con dnotify, que era una basura. Robert Love lo sustituyó con inotify como parte del en su día famoso "Proyecto Utopía". Sin embargo, los autores de inotify se conformaron con hacer una interfaz que les sirviera a ellos y que fuera mejor que dnotify (no muy difícil). Fnotify solventa las condiciones de carrera y problemas de escalabilidad de inotify y dnotify e incluso permite notificación con bloqueo previo. Las APIs de dnotify y inotify siguen existiendo, pero su código interno ha sido reescrito para basarse en el motor de fanotify. Se puede encontrar un ejemplo de uso de fanotify en este repositorio. Nótese que las llamadas al sistema de fanotify se encuentran desactivadas en esta versión hasta que los desarrolladores acuerden una API adecuada.
· Integración KMS+KDB: Gracias a las bondades de KMS, en esta versión será posible activar el depurador del kernel KDB estando en la misma sesión X. Presionando Sysrq-g mostrará la consola KDB, y al salir (usando el comando KDB) se volverá al escritorio. De momento, esta integración solamente está disponiblepara chips Intel. Las instrucciones para compilar y activar esta funcionalidad pueden encontrarse aquí.
· Workqueues optimizadas para la concurrencia: Las workqueues son una especie de pool de threads que permiten añadir a una cola trabajo que hacer. Sin embargo, el sistema actual permitía crear varias workqueues, las cuales podrían competir entre ellas por la CPU. En esta versión, y tal como ya se trató en este blog, se ha implementado una solución análoga al GCD de Apple: Existe un mecanismo que regula la cantidad de threads disponibles para ejecutar workqueues y encargado de distribuir los trabajos entre ellos, de modo que se optimizan los recursos.
· Soporte de la "gestión inteligente de energía" de Intel: En las plataformas con chips Intel i3/5 y gráficos integrados, existe la capacidad de sincronizar las variaciones de frecuencia de la CPU y la GPU simultáneamente para alcanzar un consumo y rendimiento concretos. En esta versión, Linux añade un driver que implementa esta funcionalidad.
· Cacheo local en CIFS: FS-Cache es una capa de cacheo que permite que los sistemas de archivos de red implementen un caché local. FS-Cache fue incluido en Linux 2.6.30 con soporte de NFS y AFS; en esta versión se ha añadido soporte para CIFS.
· Mejorar la respuesta del escritorio en casos raros: Existen algunos casos en los que un escritorio se puede volver verdaderamente inusable al utilizar un dispositivo de almacenamiento USB bajo cierta presión de memoria. En esta versión, se han corregido esos casos.
· Inclusión de AppArmor: AppArmor es un sistema de seguridad MAC que fue desarrollado inicialmente por Immunix en 1998 y ha sido utilizado por algunas distros como alternativa a SELinux. La diferencia fundamental entre ambos es que SELinux aplica políticas de seguridad a "etiquetas" que se asignan a archivos, y AppArmor aplica las políticas a las rutas de archivo.
Esto viene a ser todo. Como siempre, aquí está la lista completa.
30 de septiembre de 2010
Azure: Un pasito adelante y un pasito hacia atrás
Desde que Steve Ballmer anunció que Microsoft se lo jugaba todo a la carta de la computación en forma de 'nubes' (si, todos odiamos el término, pero no merece la pena rebelarse) no se han oido muchas cosas sobre el tema. Sin embargo, en el breve espacio de dos días se han producido dos noticias muy reveladoras.
En una de ellas, Microsoft acaba de convencer al Estado de Minnesota para que migre a 30.000 de sus usuarios a Azure. Que yo sepa, este es uno de los primeros grandes casos de migración masiva a una nube, y tal vez advertencia de lo que se viene encima a los sysadmins en los años venideros. Las compañías o instituciones que adopten este modelo no quieren tener un departamento de IT, del mismo modo que no quieren tener un taller de reparación de coches propio. Prefieren "subcontratar" todo lo que puedan a la nube, hacer que los clientes se autentifiquen y comuniquen con una instancia Azure ubicada en servidores de Microsoft en lugar de hacerlo en un servidor local. Como plantilla de IT se mantiene a los programadores que desarrollen aplicaciones para la nube (o se subcontrata a una consultora), y poco más. Las empresas se ahorran complejidad y parece ser que también dinero.
Pero no nos vayamos por las nubes (¿Lo han pillado? Ja. Ja.): Cuando hablamos de movimientos de IT en instituciones, es inevitable hablar de lobbing. ¿Cuánto dinero se ha gastado Microsoft en intentar convencer a Minessota? ¿Qué generosas ofertas les ha hecho, con cargo a las deudas de Microsoft, solo por conseguir un cliente que puede funcionar como marketing -"miren lo que hicieron en Minessota"- para abrirle la puerta de muchos otros? Que conste que no pretendo acusar a nadie de malas prácticas, esto es algo normal en cualquier negocio. Pero solo el tiempo nos aclarará lo verdaderamente efectivo, sencillo y costoso que puede llegar a ser la idea esta de deslocalizar departamentos de IT a un cluster.
Por otro lado, Microsoft ha anunciado que Live Spaces, su plataforma de blogs, pasa a mejor vida, y se pasa a Wordpress. Lo cual es completamente alucinante. A ver, Microsoft tuvo un déficit de 696$ millones en su división online en el último trimestre, eso son 6$ millones perdidos al día (gastar, gastan aun más). ¿Y no son capaces de desarrollar una plataforma de blogs decente? Dicen que van a "apostar todo en la nube", que quieren convertirse en los reyes de internet. ¿Merece dominar Internet una empresa que tiene que "deslocalizar" algo tan esencial como los blogs? ¿Con qué argumentos va a vender la moto de Windows+IIS+ASP.Net+SQL Server una compañía que tiene que deslocalizar su plataforma de blogging a otra basada en LAMP? Si Azure es tan potente...¿por qué no reconvertir Live Spaces, Hotmail, y los demás servicios gratuitos de Live para funcionar en una especie de instancia gratuita Azure independiente para cada usuario?
Resumiéndolo en una pregunta: ¿Puede fiarse Minessota de mover toda su infraestructura a Azure, cuando el propio creador de Azure no es capaz de desarrollar una plataforma de blogs exitosa sobre su propio invento?
En una de ellas, Microsoft acaba de convencer al Estado de Minnesota para que migre a 30.000 de sus usuarios a Azure. Que yo sepa, este es uno de los primeros grandes casos de migración masiva a una nube, y tal vez advertencia de lo que se viene encima a los sysadmins en los años venideros. Las compañías o instituciones que adopten este modelo no quieren tener un departamento de IT, del mismo modo que no quieren tener un taller de reparación de coches propio. Prefieren "subcontratar" todo lo que puedan a la nube, hacer que los clientes se autentifiquen y comuniquen con una instancia Azure ubicada en servidores de Microsoft en lugar de hacerlo en un servidor local. Como plantilla de IT se mantiene a los programadores que desarrollen aplicaciones para la nube (o se subcontrata a una consultora), y poco más. Las empresas se ahorran complejidad y parece ser que también dinero.
Pero no nos vayamos por las nubes (¿Lo han pillado? Ja. Ja.): Cuando hablamos de movimientos de IT en instituciones, es inevitable hablar de lobbing. ¿Cuánto dinero se ha gastado Microsoft en intentar convencer a Minessota? ¿Qué generosas ofertas les ha hecho, con cargo a las deudas de Microsoft, solo por conseguir un cliente que puede funcionar como marketing -"miren lo que hicieron en Minessota"- para abrirle la puerta de muchos otros? Que conste que no pretendo acusar a nadie de malas prácticas, esto es algo normal en cualquier negocio. Pero solo el tiempo nos aclarará lo verdaderamente efectivo, sencillo y costoso que puede llegar a ser la idea esta de deslocalizar departamentos de IT a un cluster.
Por otro lado, Microsoft ha anunciado que Live Spaces, su plataforma de blogs, pasa a mejor vida, y se pasa a Wordpress. Lo cual es completamente alucinante. A ver, Microsoft tuvo un déficit de 696$ millones en su división online en el último trimestre, eso son 6$ millones perdidos al día (gastar, gastan aun más). ¿Y no son capaces de desarrollar una plataforma de blogs decente? Dicen que van a "apostar todo en la nube", que quieren convertirse en los reyes de internet. ¿Merece dominar Internet una empresa que tiene que "deslocalizar" algo tan esencial como los blogs? ¿Con qué argumentos va a vender la moto de Windows+IIS+ASP.Net+SQL Server una compañía que tiene que deslocalizar su plataforma de blogging a otra basada en LAMP? Si Azure es tan potente...¿por qué no reconvertir Live Spaces, Hotmail, y los demás servicios gratuitos de Live para funcionar en una especie de instancia gratuita Azure independiente para cada usuario?
Resumiéndolo en una pregunta: ¿Puede fiarse Minessota de mover toda su infraestructura a Azure, cuando el propio creador de Azure no es capaz de desarrollar una plataforma de blogs exitosa sobre su propio invento?
26 de septiembre de 2010
Oracle y el trono perdido de Java ME
The Register tiene este domingo un interesante artículo (consecuencia de este otro) sobre los planes de Oracle para la versión de Java para móviles, Java ME. Junto al ataque legal por patentes de Java a Google, parece obvio que Oracle pretende sustituir a Android como plataforma Java para móviles, y ya de paso adelantar a todas las demás. Desde luego, al señor Ellison no se le puede acusar de no tener más moral que el Alcoyano.
Si mi memoria no me falla, en todos los artículos que he leido en todos estos años desde que el iPhone inauguró la "tactilitis", no he leido a nadie mencionar a Java ME como plataforma de desarrollo con futuro. A día de hoy el éxito de una plataforma para teléfonos móviles se cuenta por el número de aplicaciones disponibles en su tienda de aplicaciones, y los números son estos: 250.000 para iPhone, 120.000 para Android, 7.422 para Blackberry, 6.118 para Nokia, 4.475 para Palm y 1.200 para Microsoft. Sun anunció con mucha grandilocuencia la que iba a ser la tienda de aplicaciones más grande del mundo, para aplicaciones Java de todo tipo, multiplataforma y todo eso, pero a día de hoy aun está en beta, y de una versión específica o una adaptación para Java ME no se sabe nada.
Resulta sorprendente que Oracle tenga fe en Java ME. Para empezar, porque a día de hoy se ha convertido en sinónimo de "obsoleto". La propia noticia detalla las mejoras que Oracle planea (es decir, planea añadir en el futuro, aun no están disponibles): aceleración gráfica para crear interfaces fluidas. Guste o no, el iPhone es quien ha sentado las bases de lo que se considera "requisitos mínimos" en un teléfono móvil, y la aceleración gráfica que hace más intuitiva las necesarias transiciones de las interfaces táctiles está entre esos requisitos. Para hacerse una idea, vean esta captura del toolkit con el que andaban coqueteando, inspirado en Swing. Ahora pasan de eso y parece ser que quieren usar JavaFx, imitando a Microsoft con Silverlight en el Windows Phone 7. Solo que Oracle está aun más retrasado que ellos.
Pero hay otro problema con Java ME, que es la fragmentación. A Sun siempre le gustó llenarse la boca con palabras bonitas sobre la multiplataforma de Java, hablar sobre el "ejecutar en cualquier sitio", pero la realidad es distinta. Java ME como plataforma estaba muy fragmentada, no tanto por la plataforma en si, sino por las diferentes configuraciones de hardware existentes y la manera en la que los fabricantes lo integraban en sus teléfonos. En realidad, este es el mismo riesgo que Android sufre -en realidad ya está sufriendo-, que una aplicación funcione o deje de funcionar dependiendo del modelo de teléfono.
Uno no puede evitar pensar que Oracle lo hubiera tenido más fácil intentando adoptar la plataforma Android como sustituto de ME, en vez de intentar -inútilmente- de cargársela y sustituirla, que es algo que difícilmente va a lograr. Especialmente teniendo en cuenta que a Oracle le falta algo crítico: un sistema operativo para móviles. Pero oiga, si Ellison cree que Html5 es una chapuza y que JavaFx es la mejor manera de programar páginas web y que no hay nada más que discutir [1], ¿por qué no iba a creer que Java ME puede eclipsar al resto de plataformas de desarrollo para teléfonos móviles? Quizás Apple acabe rindiéndose a sus pies y pidiéndoles que les ayuden a incluir Java ME en el iPhone.
[1]: A pesar de que Ellison piensa eso, la realidad es que en JavaFx 2.0 han cambiado completamente su punto de vista. Han añadido un motor de aceleración gráfica que, aparte de renderizar en DirectX o OpenGL, también será capaz de hacerlo en Html5. Si, como suena: escribir aplicaciones que se visualizen en Html5 pero escritas inicialmente en JavaFx, supongo que al estilo del Google Web Toolkit.
Si mi memoria no me falla, en todos los artículos que he leido en todos estos años desde que el iPhone inauguró la "tactilitis", no he leido a nadie mencionar a Java ME como plataforma de desarrollo con futuro. A día de hoy el éxito de una plataforma para teléfonos móviles se cuenta por el número de aplicaciones disponibles en su tienda de aplicaciones, y los números son estos: 250.000 para iPhone, 120.000 para Android, 7.422 para Blackberry, 6.118 para Nokia, 4.475 para Palm y 1.200 para Microsoft. Sun anunció con mucha grandilocuencia la que iba a ser la tienda de aplicaciones más grande del mundo, para aplicaciones Java de todo tipo, multiplataforma y todo eso, pero a día de hoy aun está en beta, y de una versión específica o una adaptación para Java ME no se sabe nada.
Resulta sorprendente que Oracle tenga fe en Java ME. Para empezar, porque a día de hoy se ha convertido en sinónimo de "obsoleto". La propia noticia detalla las mejoras que Oracle planea (es decir, planea añadir en el futuro, aun no están disponibles): aceleración gráfica para crear interfaces fluidas. Guste o no, el iPhone es quien ha sentado las bases de lo que se considera "requisitos mínimos" en un teléfono móvil, y la aceleración gráfica que hace más intuitiva las necesarias transiciones de las interfaces táctiles está entre esos requisitos. Para hacerse una idea, vean esta captura del toolkit con el que andaban coqueteando, inspirado en Swing. Ahora pasan de eso y parece ser que quieren usar JavaFx, imitando a Microsoft con Silverlight en el Windows Phone 7. Solo que Oracle está aun más retrasado que ellos.
Pero hay otro problema con Java ME, que es la fragmentación. A Sun siempre le gustó llenarse la boca con palabras bonitas sobre la multiplataforma de Java, hablar sobre el "ejecutar en cualquier sitio", pero la realidad es distinta. Java ME como plataforma estaba muy fragmentada, no tanto por la plataforma en si, sino por las diferentes configuraciones de hardware existentes y la manera en la que los fabricantes lo integraban en sus teléfonos. En realidad, este es el mismo riesgo que Android sufre -en realidad ya está sufriendo-, que una aplicación funcione o deje de funcionar dependiendo del modelo de teléfono.
Uno no puede evitar pensar que Oracle lo hubiera tenido más fácil intentando adoptar la plataforma Android como sustituto de ME, en vez de intentar -inútilmente- de cargársela y sustituirla, que es algo que difícilmente va a lograr. Especialmente teniendo en cuenta que a Oracle le falta algo crítico: un sistema operativo para móviles. Pero oiga, si Ellison cree que Html5 es una chapuza y que JavaFx es la mejor manera de programar páginas web y que no hay nada más que discutir [1], ¿por qué no iba a creer que Java ME puede eclipsar al resto de plataformas de desarrollo para teléfonos móviles? Quizás Apple acabe rindiéndose a sus pies y pidiéndoles que les ayuden a incluir Java ME en el iPhone.
[1]: A pesar de que Ellison piensa eso, la realidad es que en JavaFx 2.0 han cambiado completamente su punto de vista. Han añadido un motor de aceleración gráfica que, aparte de renderizar en DirectX o OpenGL, también será capaz de hacerlo en Html5. Si, como suena: escribir aplicaciones que se visualizen en Html5 pero escritas inicialmente en JavaFx, supongo que al estilo del Google Web Toolkit.
20 de septiembre de 2010
Microoptimización
En la próxima versión de Linux hay una microoptimización de código que me ha parecido interesante. El problema se origina en dos funciones con switch()s que contienen una cantidad considerable de cases, los cuales a su vez contiene varios ORs en cada uno: "case BPF_ALU|BPF_ADD|BPF_X".
Dado un switch(variable) con un montón de cases, el compilador normalmente no lo traduce a ensamblador tal y como los concibe el programador, es decir, como una secuencia de condiciones "si variable=A saltar a dirección x, si variable=B saltar a dirección y", sino como una especie de salto: "saltar a dirección x+variable". Sin embargo, parece ser que todos esos ORs de las funciones citadas impiden al compilador hacer su optimización (es más, según he leido en la wikipedia, parece ser que la misma secuencia de números que puede contener la variable puede afectar a la optimización).
Con lo cual esas funciones son ensambladas como una lista gigantesca de condiciones de 567 bytes de longitud. Sin embargo, eliminando los ORs se consigue que gcc optimize correctamente el código y todo sea como debiera de ser. Nótese que poner por separado todos esos ORs supone tener que crear un case adicional para cada uno, es decir, aumentar el número de líneas de código, pero contando la optimización lograda sigue siendo una mejora.
Estas cosas naturalmente no merece la pena ni mirarlas por regla general, pero si se trata de una parte del código cuyo rendimiento es crítico, como parece ser el caso, pues quizás si. El otro día recuerdo haber leído un artículo (lamento no poder recuperar el enlace) de un experto en análisis que afirmaba que la parte del código más importante para el rendimiento de un programa solía ser el 1% de todo el código, y que normalmente los programadores no suelen analizarlo, a pesar de que se pueden lograr mejoras notables con pequeñas optimizaciones. No es mala advertencia, desde luego.
Y si han llegado hasta aquí tal vez les interese saber que ya se pueden ver las primeras capturas de cómo se está portando QT (también se está portando GTK, tengo entendido) para funcionar de manera nativa en Wayland, que es un servidor gráfico alternativo a X.org basado en las últimas tecnologías gráficas de Linux.
Dado un switch(variable) con un montón de cases, el compilador normalmente no lo traduce a ensamblador tal y como los concibe el programador, es decir, como una secuencia de condiciones "si variable=A saltar a dirección x, si variable=B saltar a dirección y", sino como una especie de salto: "saltar a dirección x+variable". Sin embargo, parece ser que todos esos ORs de las funciones citadas impiden al compilador hacer su optimización (es más, según he leido en la wikipedia, parece ser que la misma secuencia de números que puede contener la variable puede afectar a la optimización).
Con lo cual esas funciones son ensambladas como una lista gigantesca de condiciones de 567 bytes de longitud. Sin embargo, eliminando los ORs se consigue que gcc optimize correctamente el código y todo sea como debiera de ser. Nótese que poner por separado todos esos ORs supone tener que crear un case adicional para cada uno, es decir, aumentar el número de líneas de código, pero contando la optimización lograda sigue siendo una mejora.
Estas cosas naturalmente no merece la pena ni mirarlas por regla general, pero si se trata de una parte del código cuyo rendimiento es crítico, como parece ser el caso, pues quizás si. El otro día recuerdo haber leído un artículo (lamento no poder recuperar el enlace) de un experto en análisis que afirmaba que la parte del código más importante para el rendimiento de un programa solía ser el 1% de todo el código, y que normalmente los programadores no suelen analizarlo, a pesar de que se pueden lograr mejoras notables con pequeñas optimizaciones. No es mala advertencia, desde luego.
Y si han llegado hasta aquí tal vez les interese saber que ya se pueden ver las primeras capturas de cómo se está portando QT (también se está portando GTK, tengo entendido) para funcionar de manera nativa en Wayland, que es un servidor gráfico alternativo a X.org basado en las últimas tecnologías gráficas de Linux.
30 de agosto de 2010
Curiosidades python
Me ha parecido curiosa esta manera de corregir un typo en todas las páginas de un wiki. No sabía que existían este tipo de librerías, python siempre logra sorprenderme.
27 de agosto de 2010
Novedades en systemd
Desde que Lennart Poettering, autor de Pulseaudio, anunció el nacimiento de systemd, un reemplazo de init/upstart (si quieren, también pueden leer el enlace anterior en este otro sitio en el que me copian el texto del blog sin poner ni una cita), han pasado 4 meses. Suele pasar en ocasiones que un proyecto sale a la luz y la luz lo seca o lo debilita como a un brote reciente (caso de Wayland, tan revolucionario y tan raquítico a la vez). No ha sido este caso. Systemd se ha saltado etapas de crecimiento a una velocidad pasmosa y ya se acerca a árbol, como puede comprobarse en este post de Lennart sobre la evolución del proyecto.
En primer lugar, han implementado los varios tipos de "unidades" que habían prometido y faltaban. Han añadido las unidades timer. Su propósito es sustituir la funcionalidad de cron (aunque de un vistazo a la documentación es evidente que aun le falta funcionalidad para lograrlo por completo). Otro tipo de unidad es path, que puede utilizarse para invocar automáticamente un servicio cuando hay actividad en alguna parte del sistema de archivos, o cuando se crea un directorio determinado (es, por así decirlo, una especie de herramienta para usar inotify). Y el último tipo de unidad implementado es swap, que indica a systemd las particiones de intercambio que hay que montar (recordemos que, entre otras cosas, systemd pretende conseguir que /etc/fstab sea teóricamente innecesario).
Otra novedad importante es que systemd se ha integrado con todo lo que ha encontrado por delante: SELinux a la hora de crear directorios o sockets, TCP wrappers, PAM, y los inicios/paradas de los servicios se reportan al sistema de auditoría del kernel. También se ha integrado el sistema con D-Bus, de modo que los servicios que utilicen las interfaces D-Bus para comunicarse con los clientes pueden informar de ello en sus archivos de configuración, y systemd se encargará de arrancar automáticamente esos servicios cuando un cliente intente comunicarse con él (básicamente se trata de lo mismo que se hace con los sockets de red, pero aplicado a las conexiones D-BUS).
Otra novedad, muy curiosa, es cómo han utilizado las características de systemd para conseguir que no se pierda absolutamente ningún mensaje destinado a archivos log, desde el arranque del sistema hasta su apagado. Nada más iniciarse, systemd se pone a escuchar en el socket /dev/log, y envía los mensajes que allí se envían al buffer del kernel (el de dmesg). Posteriormente se arranca syslog (a quien se cede el control de /dev/log), el cual, como primera operación, guarda ese buffer del kernel en el disco. De ese modo, no se pierde ni un solo mensaje. Es más, si syslog muere por cualquier razón, o cuando el sistema se está apagando y hay que apagar el proceso, se restablece la comunicación /dev/log -> dmesg.
Respecto a la adopción, parece que systemd va a ser el sistema de inicio por defecto para Fedora 14. A esto ayuda, no cabe duda, que los mecanismos de systemd hacen posible convivir servicios con configuraciones systemd y otros con configuraciones antiguas sin que haya problemas de ningún tipo. Upstart necesitó ser tremendamente conservador para evitar problemas (pagando como precio el no estar aun terminado, de acuerdo con su autor). Systemd no necesita tantos cuidados. Quizás sea esa la razón por la que ya hay paquetes y scripts disponibles para OpenSUSE, Debian, Gentoo y Arch. Aunque en Debian habría problemas para utilizarlo como sistema de inicio por defecto, porque systemd sólo funciona para Linux y Debian está empeñada en soportar kernels BSD...
En primer lugar, han implementado los varios tipos de "unidades" que habían prometido y faltaban. Han añadido las unidades timer. Su propósito es sustituir la funcionalidad de cron (aunque de un vistazo a la documentación es evidente que aun le falta funcionalidad para lograrlo por completo). Otro tipo de unidad es path, que puede utilizarse para invocar automáticamente un servicio cuando hay actividad en alguna parte del sistema de archivos, o cuando se crea un directorio determinado (es, por así decirlo, una especie de herramienta para usar inotify). Y el último tipo de unidad implementado es swap, que indica a systemd las particiones de intercambio que hay que montar (recordemos que, entre otras cosas, systemd pretende conseguir que /etc/fstab sea teóricamente innecesario).
Otra novedad importante es que systemd se ha integrado con todo lo que ha encontrado por delante: SELinux a la hora de crear directorios o sockets, TCP wrappers, PAM, y los inicios/paradas de los servicios se reportan al sistema de auditoría del kernel. También se ha integrado el sistema con D-Bus, de modo que los servicios que utilicen las interfaces D-Bus para comunicarse con los clientes pueden informar de ello en sus archivos de configuración, y systemd se encargará de arrancar automáticamente esos servicios cuando un cliente intente comunicarse con él (básicamente se trata de lo mismo que se hace con los sockets de red, pero aplicado a las conexiones D-BUS).
Otra novedad, muy curiosa, es cómo han utilizado las características de systemd para conseguir que no se pierda absolutamente ningún mensaje destinado a archivos log, desde el arranque del sistema hasta su apagado. Nada más iniciarse, systemd se pone a escuchar en el socket /dev/log, y envía los mensajes que allí se envían al buffer del kernel (el de dmesg). Posteriormente se arranca syslog (a quien se cede el control de /dev/log), el cual, como primera operación, guarda ese buffer del kernel en el disco. De ese modo, no se pierde ni un solo mensaje. Es más, si syslog muere por cualquier razón, o cuando el sistema se está apagando y hay que apagar el proceso, se restablece la comunicación /dev/log -> dmesg.
Respecto a la adopción, parece que systemd va a ser el sistema de inicio por defecto para Fedora 14. A esto ayuda, no cabe duda, que los mecanismos de systemd hacen posible convivir servicios con configuraciones systemd y otros con configuraciones antiguas sin que haya problemas de ningún tipo. Upstart necesitó ser tremendamente conservador para evitar problemas (pagando como precio el no estar aun terminado, de acuerdo con su autor). Systemd no necesita tantos cuidados. Quizás sea esa la razón por la que ya hay paquetes y scripts disponibles para OpenSUSE, Debian, Gentoo y Arch. Aunque en Debian habría problemas para utilizarlo como sistema de inicio por defecto, porque systemd sólo funciona para Linux y Debian está empeñada en soportar kernels BSD...
19 de agosto de 2010
Dos pájaros de un tiro
A Oracle solo le faltó anunciar algo de MySQL para hacer triplete. Android y Opensolaris apuntalados por Larry Ellison el mismo día. Desde que se anuncio la compra de Sun todo fueron especulaciones sobre qué haría Oracle con su rutilante compra a precio de saldo, la más común en círculos linuxeros, incluido este blog, era la sospecha de que el señor Ellison antepondría absolutamente todo a su avaricia, como así ha sido. En fin, fue bonito mientras duró. Sirvan estas líneas de apoyo póstumo a Sun y su plan de apoyo al software libre.
Como ya saben, este blog se precia de no ser una de esas fotocopiadoras que regurgitan lo que otros escriben en la blogosfera, aquí se generan vómitos propios. Por lo tanto asumo que ustedes ya habrán leído la avalancha de noticias sobre el tema. Lo que le preocupa a este humilde servidor de ustedes es...¿y ahora qué?
El asunto de Android y su implementación de Java es peliagudo. Uno no acaba de adivinar el propósito de Oracle. Un sudor frío me recorre la espalda al pensar que tal vez quería la posesión de Java simplemente para exprimir la dependencia que de Java tienen quienes han escrito miles y miles de líneas de código en él. ¿Qué otra opción cabe? Si su intención es mantener la unidad de Java, nada les ayudará a lograr ese fin declararlo tecnología propiedad exclusiva de Oracle. A las plataformas de desarrollo y lenguajes de propósito general se les asume una libertad similar a la de los estándares de Internet. Que te demanden por no seguir un estándar o unas librerías al pie de la letra es una manera de decir: "Esto es nuestro, no se atreva a tocarlo, limítese a usar nuestros programas". Se dirá que Java en realidad sí es verdaderamente libre, con la pequeña condición de adherirse incondicionalmente al estándar, pero hay analogías, salvando las diferencias, con el modelo de sindicato único de ciertos regímenes.
Naturalmente, Oracle es libre de hacer lo que desee con su propiedad, pero Java ya no será verdaderamente libre, al menos para sus usuarios. Y esto es un cambio radical para el que sigue siendo uno de los principales lenguajes de programación del mundo. Porque una de las claves para la construcción del imperio de Java fue una especie de consenso con el resto de la industria. La única razón por la que una compañía como IBM apoyó con tanta fuerza este lenguaje creado por el que en su día era quizás su más fiero competidor, es que sabían que Sun jamás se iba a aprovechar de su posición para fastidiar a los clientes de IBM. Es de imaginar que los señores de Big Blue estarán hoy pero que muy enfadados y preocupados por este rumbo escogido por Oracle. De hecho, teniendo en cuenta que Larry Ellison ha declarado a IBM como su mayor enemigo, ¿no es posible que las adquisición de Java no tenga otro objetivo que fastidiar a IBM?
El tema de OpenSolaris es menos preocupante, porque podemos ser cínicos y tomarlo como buenas noticias para Linux. Por muy Linuxero que uno fuera, en su día la liberación de Solaris solo cabía aceptarse como buena, muy buena noticia para el software libre. Pero ahora, aunque el software libre salga perdiendo, Linux en particular sale reforzado, ya que el escenario principal de sistemas operativos de software libre vuelve a ser exclusivamente suyo. Incluso si Oracle hace de Solaris un gran sistema operativo, con más maravillas del tipo de ZFS, sus competidores por inercia invertirán en Linux...en los hilos de los sitios de noticias, hay personas interesadas en dejar OpenSolaris y volver a Linux (o al menos a FreeBSD, que por otra parte sale mal parado por todo este asunto). No se puede pillar a los usuarios de OpenSolaris igual que a los de Java. Así que vaya lo uno por lo otro.
Como ya saben, este blog se precia de no ser una de esas fotocopiadoras que regurgitan lo que otros escriben en la blogosfera, aquí se generan vómitos propios. Por lo tanto asumo que ustedes ya habrán leído la avalancha de noticias sobre el tema. Lo que le preocupa a este humilde servidor de ustedes es...¿y ahora qué?
El asunto de Android y su implementación de Java es peliagudo. Uno no acaba de adivinar el propósito de Oracle. Un sudor frío me recorre la espalda al pensar que tal vez quería la posesión de Java simplemente para exprimir la dependencia que de Java tienen quienes han escrito miles y miles de líneas de código en él. ¿Qué otra opción cabe? Si su intención es mantener la unidad de Java, nada les ayudará a lograr ese fin declararlo tecnología propiedad exclusiva de Oracle. A las plataformas de desarrollo y lenguajes de propósito general se les asume una libertad similar a la de los estándares de Internet. Que te demanden por no seguir un estándar o unas librerías al pie de la letra es una manera de decir: "Esto es nuestro, no se atreva a tocarlo, limítese a usar nuestros programas". Se dirá que Java en realidad sí es verdaderamente libre, con la pequeña condición de adherirse incondicionalmente al estándar, pero hay analogías, salvando las diferencias, con el modelo de sindicato único de ciertos regímenes.
Naturalmente, Oracle es libre de hacer lo que desee con su propiedad, pero Java ya no será verdaderamente libre, al menos para sus usuarios. Y esto es un cambio radical para el que sigue siendo uno de los principales lenguajes de programación del mundo. Porque una de las claves para la construcción del imperio de Java fue una especie de consenso con el resto de la industria. La única razón por la que una compañía como IBM apoyó con tanta fuerza este lenguaje creado por el que en su día era quizás su más fiero competidor, es que sabían que Sun jamás se iba a aprovechar de su posición para fastidiar a los clientes de IBM. Es de imaginar que los señores de Big Blue estarán hoy pero que muy enfadados y preocupados por este rumbo escogido por Oracle. De hecho, teniendo en cuenta que Larry Ellison ha declarado a IBM como su mayor enemigo, ¿no es posible que las adquisición de Java no tenga otro objetivo que fastidiar a IBM?
El tema de OpenSolaris es menos preocupante, porque podemos ser cínicos y tomarlo como buenas noticias para Linux. Por muy Linuxero que uno fuera, en su día la liberación de Solaris solo cabía aceptarse como buena, muy buena noticia para el software libre. Pero ahora, aunque el software libre salga perdiendo, Linux en particular sale reforzado, ya que el escenario principal de sistemas operativos de software libre vuelve a ser exclusivamente suyo. Incluso si Oracle hace de Solaris un gran sistema operativo, con más maravillas del tipo de ZFS, sus competidores por inercia invertirán en Linux...en los hilos de los sitios de noticias, hay personas interesadas en dejar OpenSolaris y volver a Linux (o al menos a FreeBSD, que por otra parte sale mal parado por todo este asunto). No se puede pillar a los usuarios de OpenSolaris igual que a los de Java. Así que vaya lo uno por lo otro.
2 de agosto de 2010
Las novedades de Linux 2.6.35
Linus ha anunciado la versión 2.6.35, como siempre aquí está la traducción castellana de las novedades principales. A vista de pájaro, esta versión añade soporte para repartir automáticamente la carga de red entrante entre varias CPUs, soporte de Direct I/O para Btrfs, un modo de journaling alternativo para XFS, inclusión de la interfaz del depurador KDB, varias mejoras de perf, aceleración de vídeo H.264 y VC1 en hardware Intel G45+, soporte del futuro Intel Cougarpoint, un sistema de defragmentación de la memoria, soporte de L2TP versión 3 (RFC 3931), varios drivers y muchas pequeñas mejoras más. Lista completa en inglés aquí.
· Reparto automático entre varias CPUs del tráfico de red de entrada: Las tarjetas de red actuales han mejorado su rendimiento hasta el punto de que para una sola CPU moderna es cada vez más difícil mantener el ancho de banda de recepción al máximo. Dos nuevas características, contribuidas por Google, ayudan a repartir automáticamente la carga de los paquetes de red entrantes entre varias CPUs (los salientes ya se reparten por si solos). El procesado de protocolos(IP, TCP) se ha modificado para que pueda hacerse en paralelo. Cada dispositivo de red utiliza diferentes heurísticas para decidir en qué CPU se procesará el paquete (hash de la cabecera del paquete, afinidad con la CPU en la que se está ejecutando la aplicación que lo va a recibir). Esta característica emula por software lo que una tarjeta de red multiqueue hace en hardware. Un benchmark de 500 instancias del test netperf TCP_RR con 1 byte de petición y respuesta en una e1000e montada en un servidor con CPU Intel de 8 cores ascienden de 104K tps a 303K tps. Un test RPC con 100 threads en cada host, va de 103K tps a 223K, y con menos latencia.
· Mejoras Btrfs: Direct I/O y -ENOSPC completo. Direct I/O es una técnica utilizada para saltarse el caché a la hora de escribir. Esto daña el rendimiento (es como montar un sistema de archivos en modo "sync"), pero es utilizado extensivamente en grandes bases de datos a las que les gusta implementar su propio cache optimizado. -ENOSPC completo: Linux 2.6.32 ya tenía soporte de -ENOSPC para el uso común del sistema de archivos, pero existían varios casos raros en ciertas operaciones complejas, como operaciones de gestión de volumenes, en los que podía haber fallos. El código -ENOSPC de esta versión maneja correctamente todos los casos: balanceo de espacio libre, gestión de discos, logging de fsync y otros.
· XFS delayed logging: Esta versión añade un nuevo modo de journaling para XFS llamado "delayed logging", que ha sido modelado según los sistemas de journaling de Ext3/4 y reiserfs. Permite acumular múltiples transacciones asíncronas en memoria. La reducción del ancho de banda utilizado para el log decrece en gran medida, y las cargas que hacen un uso intensivo de los metadatos aumentan su rendimiento en la misma proporción. El formato de disco del journal no ha cambiado, solo las estructuras en memoria y el código. Esta característica es aun experimental, asi que no está recomendada excepto para pruebas. Puede activarse con la opción "-o delaylog"
· Frontend del depurador KDB: Linux ha tenido un depurador desde 2.6.26, llamado Kgdb. Pero desde hace años existen dos depuradores para Linux, Kgdb y KDB. La diferencia entre ambos siempre fue que Kgdb requiere un ordenador adicional en el que ejecutar una instancia de gdb, que permite una depuración profunda. KDB, en cambio, puede utilizarse en el mismo ordenador, pero sus características de depurado son más simples. En esta versión se ha incluido también el depurador KDB, pero modificado para funcionar sobre los mecanismos internos de KGDB.
· Mejoras de perf:
- Modo "live" perf-inject: Hasta ahora, los usuarios tenían que ejecutar "perf record" y "perf report" en dos comandos diferentes. Perf-inject introduce un modo "live", que permite grabar y reportar en un solo comando, como por ejemplo perf record -o - ./hackbench 10 | perf inject -v -b | perf report -v -i - . Pero esto es demasiado complejo, asi que se ha añadido soporte para invocar automáticamente el modo live si no se especifica record/report. Por ejemplo: perf trace rwtop 5. Cualquiera de los scripts listados en 'perf trace -l' pueden utilizarse directamente el modo live.
- perf kvm: Una herramienta para monitorizar el rendimiento de las VMs desde el host.
- perf probe: Soporte para acceder a miembros de las estructuras de datos. Con est, perf-probe acepta miembros de estructuras (es decir, acepta los operadores punto '.' y flecha '->') como argumentos. Ejemplos: # perf probe --add 'schedule:44 rq->curr'. O # perf probe --add 'vfs_read file->f_op->read file->f_path.dentry'
- Mejorar --list: para mostrar las sondas existentes con número de línea y nombre de archivo. Esto permite comprobar fácilmente qué linea está "sondeada". Por ejemplo:
· Mejoras gráficas: i915: Soporte de aceleración para vídeo H.264 y VC1 en hardware G45+, soporte del futuro Intel Cougarpoint, monitorización de energía y autorefresco de memoria en hardware Ironlake. Radeon: Trabajo inicial para la gestión de energía, simplificación y mejora del reseteo de GPU, implementación varias partes importantes para soportar chips Evergreen, permitir el uso de VRAM no mapeable, soporta para cuando no hay salidas de vídeo conectadas.
· Compactación de memoria: Este es un mecanismo que trata de reducir la fragmentación externa de la memoria que intenta agrupar las páginas utilizadas y las libres en un gran bloque de páginas usadas y un gran bloque de páginas libres, lo que permite hacer asignaciones de memoria grandes que no son posibles si hay fragmentación. La implementación consiste en dos escanners, uno de páginas a migrar, que empieza a buscar páginas utilizadas por el principio de la zona de memoria, y otro de páginas libres, que empieza a buscar páginas libres por el final. Cuando ambos escanners se encuentran en el medio de la zona, se mueven las páginas utilizadas al lugar de las libres. Las pruebas han mostrado que la cantidad de I/O requerido para satisfacer una gran asignación disminuye drásticamente. La compactación puede activarse de tres modos diferentes: manualmente, escribiendo algún valor a /proc/sys/vm/compact_memory. Puede activarse manualmente, pero para una sola zona determinada, escribiendo algún valor a /sys/devices/system/node/nodeN/compact. Y también se activa automáticamente cuando no se consigue asignar una gran porción de memoria.
· Soporte para múltiples tablas de ruta multicast: normalmente, un router multicast ejecuta un demonio en espacio de usuario que decide con un paquete fijándose en las direcciones de origen y destino. Esta característica añade soporte para múltiples tablas de rutas multicast, así el kernel es capaz de tomar las interfaces y las marcas de los paquetes y ejecutar múltiples demonios en espacio de usuario simultaneamente, cada uno manejando una sola tabla.
· Soporte de L2TP versión 3 (RFC 3931): Esta versión añade soporte para Layer 2 Tunneling Protocol (L2TP) version 3, RFC 3931.
· Protocolo CAIF: Se trata de un protocolo utilizado por módems ST-Ericsson.
· ACPI Platform Error Interface: Soporte para la ACPI Platform Error Interface (APEI). Este sistema mejora especialmente la gestión de NMI (interrupciones no enmascarables). Además, soporta una tabla para guardar errores MCE en flash.
Esto viene a ser todo. Como siempre, aquí está la lista completa.
· Reparto automático entre varias CPUs del tráfico de red de entrada: Las tarjetas de red actuales han mejorado su rendimiento hasta el punto de que para una sola CPU moderna es cada vez más difícil mantener el ancho de banda de recepción al máximo. Dos nuevas características, contribuidas por Google, ayudan a repartir automáticamente la carga de los paquetes de red entrantes entre varias CPUs (los salientes ya se reparten por si solos). El procesado de protocolos(IP, TCP) se ha modificado para que pueda hacerse en paralelo. Cada dispositivo de red utiliza diferentes heurísticas para decidir en qué CPU se procesará el paquete (hash de la cabecera del paquete, afinidad con la CPU en la que se está ejecutando la aplicación que lo va a recibir). Esta característica emula por software lo que una tarjeta de red multiqueue hace en hardware. Un benchmark de 500 instancias del test netperf TCP_RR con 1 byte de petición y respuesta en una e1000e montada en un servidor con CPU Intel de 8 cores ascienden de 104K tps a 303K tps. Un test RPC con 100 threads en cada host, va de 103K tps a 223K, y con menos latencia.
· Mejoras Btrfs: Direct I/O y -ENOSPC completo. Direct I/O es una técnica utilizada para saltarse el caché a la hora de escribir. Esto daña el rendimiento (es como montar un sistema de archivos en modo "sync"), pero es utilizado extensivamente en grandes bases de datos a las que les gusta implementar su propio cache optimizado. -ENOSPC completo: Linux 2.6.32 ya tenía soporte de -ENOSPC para el uso común del sistema de archivos, pero existían varios casos raros en ciertas operaciones complejas, como operaciones de gestión de volumenes, en los que podía haber fallos. El código -ENOSPC de esta versión maneja correctamente todos los casos: balanceo de espacio libre, gestión de discos, logging de fsync y otros.
· XFS delayed logging: Esta versión añade un nuevo modo de journaling para XFS llamado "delayed logging", que ha sido modelado según los sistemas de journaling de Ext3/4 y reiserfs. Permite acumular múltiples transacciones asíncronas en memoria. La reducción del ancho de banda utilizado para el log decrece en gran medida, y las cargas que hacen un uso intensivo de los metadatos aumentan su rendimiento en la misma proporción. El formato de disco del journal no ha cambiado, solo las estructuras en memoria y el código. Esta característica es aun experimental, asi que no está recomendada excepto para pruebas. Puede activarse con la opción "-o delaylog"
· Frontend del depurador KDB: Linux ha tenido un depurador desde 2.6.26, llamado Kgdb. Pero desde hace años existen dos depuradores para Linux, Kgdb y KDB. La diferencia entre ambos siempre fue que Kgdb requiere un ordenador adicional en el que ejecutar una instancia de gdb, que permite una depuración profunda. KDB, en cambio, puede utilizarse en el mismo ordenador, pero sus características de depurado son más simples. En esta versión se ha incluido también el depurador KDB, pero modificado para funcionar sobre los mecanismos internos de KGDB.
· Mejoras de perf:
- Modo "live" perf-inject: Hasta ahora, los usuarios tenían que ejecutar "perf record" y "perf report" en dos comandos diferentes. Perf-inject introduce un modo "live", que permite grabar y reportar en un solo comando, como por ejemplo perf record -o - ./hackbench 10 | perf inject -v -b | perf report -v -i - . Pero esto es demasiado complejo, asi que se ha añadido soporte para invocar automáticamente el modo live si no se especifica record/report. Por ejemplo: perf trace rwtop 5. Cualquiera de los scripts listados en 'perf trace -l' pueden utilizarse directamente el modo live.
- perf kvm: Una herramienta para monitorizar el rendimiento de las VMs desde el host.
- perf probe: Soporte para acceder a miembros de las estructuras de datos. Con est, perf-probe acepta miembros de estructuras (es decir, acepta los operadores punto '.' y flecha '->') como argumentos. Ejemplos: # perf probe --add 'schedule:44 rq->curr'. O # perf probe --add 'vfs_read file->f_op->read file->f_path.dentry'
- Mejorar --list: para mostrar las sondas existentes con número de línea y nombre de archivo. Esto permite comprobar fácilmente qué linea está "sondeada". Por ejemplo:
# perf probe --list
probe:vfs_read (on vfs_read:8@linux-2.6-tip/fs/read_write.c)
- Implementación de una UI en la consola con newt.· Mejoras gráficas: i915: Soporte de aceleración para vídeo H.264 y VC1 en hardware G45+, soporte del futuro Intel Cougarpoint, monitorización de energía y autorefresco de memoria en hardware Ironlake. Radeon: Trabajo inicial para la gestión de energía, simplificación y mejora del reseteo de GPU, implementación varias partes importantes para soportar chips Evergreen, permitir el uso de VRAM no mapeable, soporta para cuando no hay salidas de vídeo conectadas.
· Compactación de memoria: Este es un mecanismo que trata de reducir la fragmentación externa de la memoria que intenta agrupar las páginas utilizadas y las libres en un gran bloque de páginas usadas y un gran bloque de páginas libres, lo que permite hacer asignaciones de memoria grandes que no son posibles si hay fragmentación. La implementación consiste en dos escanners, uno de páginas a migrar, que empieza a buscar páginas utilizadas por el principio de la zona de memoria, y otro de páginas libres, que empieza a buscar páginas libres por el final. Cuando ambos escanners se encuentran en el medio de la zona, se mueven las páginas utilizadas al lugar de las libres. Las pruebas han mostrado que la cantidad de I/O requerido para satisfacer una gran asignación disminuye drásticamente. La compactación puede activarse de tres modos diferentes: manualmente, escribiendo algún valor a /proc/sys/vm/compact_memory. Puede activarse manualmente, pero para una sola zona determinada, escribiendo algún valor a /sys/devices/system/node/nodeN/compact. Y también se activa automáticamente cuando no se consigue asignar una gran porción de memoria.
· Soporte para múltiples tablas de ruta multicast: normalmente, un router multicast ejecuta un demonio en espacio de usuario que decide con un paquete fijándose en las direcciones de origen y destino. Esta característica añade soporte para múltiples tablas de rutas multicast, así el kernel es capaz de tomar las interfaces y las marcas de los paquetes y ejecutar múltiples demonios en espacio de usuario simultaneamente, cada uno manejando una sola tabla.
· Soporte de L2TP versión 3 (RFC 3931): Esta versión añade soporte para Layer 2 Tunneling Protocol (L2TP) version 3, RFC 3931.
· Protocolo CAIF: Se trata de un protocolo utilizado por módems ST-Ericsson.
· ACPI Platform Error Interface: Soporte para la ACPI Platform Error Interface (APEI). Este sistema mejora especialmente la gestión de NMI (interrupciones no enmascarables). Además, soporta una tabla para guardar errores MCE en flash.
Esto viene a ser todo. Como siempre, aquí está la lista completa.
28 de julio de 2010
Lo táctil entra en el escritorio
Apple ha anunciado un nuevo invento: el Magic Trackpad. Me resulta personalmente muy gracioso, porque la semana pasada sin ir más lejos a un servidor le llegó a casa su nueva tableta Wacom Bamboo Touch & Pen: Una tableta gráfica con capacidades táctiles. Que venía a sustituir a mi antigua Bamboo no-táctil. Efectivamente, uso tabletas gráficas como reemplazo del ratón. Por eso me llama la atención este asunto.
El nombre del invento, "Trackpad", le hace honor, ya que está lejos de ser una tableta gráfica. Lo de Apple es, literalmente, un trackpad gigante, algo inútil para diseño gráfico, donde la sensibilidad a la presión de los lápices de las tabletas gráficas gana por goleada. Está pensado por tanto para ser utilizado como reemplazo del ratón, que irónicamente es para lo único que yo uso mi tableta. Para serles sincero, de haber sabido de la existencia de este aparato una semana antes, no me hubiera comprado mi tableta. Y no tanto porque esté diseñado explícitamente para lo que yo quiero usarlo sino sobretodo porque es 30 eurazos más barato (seguramente por prescindir de la sensibilidad del lápiz de una tableta gráfica). Aunque he de decir que las capacidades gráficas de un tableta son algo por lo que merece la pena pagar 30€ y más (aunque si soy totalmente sincero el entorno ideal que me gustaría probar a día de hoy sería un aparato con formato iPad conectado vía wireless a mi ordenador)
Pero lo que me sorprende de este aparato es la generalización de las interfaces táctiles. Hace dos días que los fabricantes de teléfonos móviles se volvieron locos por las pantallas táctiles, y ya tenemos cosas táctiles metiéndose en los escritorios. Que Apple se haya molestado en fabricar este aparato por ellos mismos deja claro que creen en lo táctil como elemento primario de interacción también para el escritorio, es decir, para todo tipo de dispositivos. Eso lo ha dejado bastante claro el iPad, que, entre otras cosas, se vende bien porque la gente normal prefiere mil veces una pantalla táctil al dispositivo infernal de los portátiles: si, también es un trackpad, pero su ridículo tamaño hace que se tengan que aplicar al puntero velocidades de aceleración enormemente diferentes (aceleración enorme en movimientos rápidos, cuando se quiere transportar el puntero a grandes distancias, aceleración casi nula en movimientos lentos, para fijar el puntero exactamente donde queremos ponerlo) y muy poco intuitivas (la degradación de aceleración rápida a lenta es brusca). Por eso el gadget más utilizado en los portátiles tras el cargador -que el iPad también evita prescindiendo de esos procesadores rapidísimos que tanta gente dice que Apple debería haber utilizado- es un miniratón.
Pero una vez aumentado el tamaño del trackpad esas divergencias de aceleración se aminoran y pasan a ser las del ratón de toda la vida (que también tiene aceleración cambiante) . Si creen que algo así es poco intuitivo, se equivocan. En realidad, no se trata de una eliminación del ratón, sino de su perfeccionamiento. Utilizamos el ratón para mover un puntero, y los botones para iniciar acciones, pero para ello dependemos de esos trozos de plástico que ponemos debajo de nuestros manos para que una luz intensa o bolita detecte el movimiento. Un trackpad o una tableta con capacidades táctiles no pretenden cambiar esto, sino prescindir del plástico y empujar el puntero de una manera diferente.
Y puedo asegurarles -lo he podido probar en mi Wacom- que acercar el puntero a un botón con la sensibilidad de las yemas de los dedos es más intuitivo que hacerlo empujando un trozo de plástico, y que hacer click dejando caer el dedo es más cómodo que accionando el mecanismo de un ratón (aunque al principio se cuesta acostumbrarse). Eso sin entrar en poder hacer scrolling en el navegador -donde seguramente pasen casi todo el tiempo- simplemente arrastrando dos dedos. Mención aparte es la capacidad de las tabletas gráficas, cuando se usa con lápiz, de poder configurarse en modo "absoluto", es decir, que cada punto de la tableta pasa a tener un equivalente en la pantalla, de modo que la esquina inferior izquierda lleva siempre a la esquina inferior izquierda de la pantalla, no hay "arrastre": A mi esta funcionalidad me encanta, pero en la funcionalidad táctil parece ser mejor la técnica de arrastre. Parece ser que todo es cuestión de gustos. Si quieren probar algo nuevo, les recomiendo comprarse una Wacom Bamboo Touch o el Magic Trackpad. Eso si, en Linux el soporte de Wacom está presente (ellos mismos pagan a un programador para que lo soporte) pero necesita mejoras en sus capacidades táctiles, y del Magic Trackpad de momento no esperen nada.
El nombre del invento, "Trackpad", le hace honor, ya que está lejos de ser una tableta gráfica. Lo de Apple es, literalmente, un trackpad gigante, algo inútil para diseño gráfico, donde la sensibilidad a la presión de los lápices de las tabletas gráficas gana por goleada. Está pensado por tanto para ser utilizado como reemplazo del ratón, que irónicamente es para lo único que yo uso mi tableta. Para serles sincero, de haber sabido de la existencia de este aparato una semana antes, no me hubiera comprado mi tableta. Y no tanto porque esté diseñado explícitamente para lo que yo quiero usarlo sino sobretodo porque es 30 eurazos más barato (seguramente por prescindir de la sensibilidad del lápiz de una tableta gráfica). Aunque he de decir que las capacidades gráficas de un tableta son algo por lo que merece la pena pagar 30€ y más (aunque si soy totalmente sincero el entorno ideal que me gustaría probar a día de hoy sería un aparato con formato iPad conectado vía wireless a mi ordenador)
Pero lo que me sorprende de este aparato es la generalización de las interfaces táctiles. Hace dos días que los fabricantes de teléfonos móviles se volvieron locos por las pantallas táctiles, y ya tenemos cosas táctiles metiéndose en los escritorios. Que Apple se haya molestado en fabricar este aparato por ellos mismos deja claro que creen en lo táctil como elemento primario de interacción también para el escritorio, es decir, para todo tipo de dispositivos. Eso lo ha dejado bastante claro el iPad, que, entre otras cosas, se vende bien porque la gente normal prefiere mil veces una pantalla táctil al dispositivo infernal de los portátiles: si, también es un trackpad, pero su ridículo tamaño hace que se tengan que aplicar al puntero velocidades de aceleración enormemente diferentes (aceleración enorme en movimientos rápidos, cuando se quiere transportar el puntero a grandes distancias, aceleración casi nula en movimientos lentos, para fijar el puntero exactamente donde queremos ponerlo) y muy poco intuitivas (la degradación de aceleración rápida a lenta es brusca). Por eso el gadget más utilizado en los portátiles tras el cargador -que el iPad también evita prescindiendo de esos procesadores rapidísimos que tanta gente dice que Apple debería haber utilizado- es un miniratón.
Pero una vez aumentado el tamaño del trackpad esas divergencias de aceleración se aminoran y pasan a ser las del ratón de toda la vida (que también tiene aceleración cambiante) . Si creen que algo así es poco intuitivo, se equivocan. En realidad, no se trata de una eliminación del ratón, sino de su perfeccionamiento. Utilizamos el ratón para mover un puntero, y los botones para iniciar acciones, pero para ello dependemos de esos trozos de plástico que ponemos debajo de nuestros manos para que una luz intensa o bolita detecte el movimiento. Un trackpad o una tableta con capacidades táctiles no pretenden cambiar esto, sino prescindir del plástico y empujar el puntero de una manera diferente.
Y puedo asegurarles -lo he podido probar en mi Wacom- que acercar el puntero a un botón con la sensibilidad de las yemas de los dedos es más intuitivo que hacerlo empujando un trozo de plástico, y que hacer click dejando caer el dedo es más cómodo que accionando el mecanismo de un ratón (aunque al principio se cuesta acostumbrarse). Eso sin entrar en poder hacer scrolling en el navegador -donde seguramente pasen casi todo el tiempo- simplemente arrastrando dos dedos. Mención aparte es la capacidad de las tabletas gráficas, cuando se usa con lápiz, de poder configurarse en modo "absoluto", es decir, que cada punto de la tableta pasa a tener un equivalente en la pantalla, de modo que la esquina inferior izquierda lleva siempre a la esquina inferior izquierda de la pantalla, no hay "arrastre": A mi esta funcionalidad me encanta, pero en la funcionalidad táctil parece ser mejor la técnica de arrastre. Parece ser que todo es cuestión de gustos. Si quieren probar algo nuevo, les recomiendo comprarse una Wacom Bamboo Touch o el Magic Trackpad. Eso si, en Linux el soporte de Wacom está presente (ellos mismos pagan a un programador para que lo soporte) pero necesita mejoras en sus capacidades táctiles, y del Magic Trackpad de momento no esperen nada.
17 de julio de 2010
Caraterística segura del próximo modelo de iPhone
"La mejor calidad de recepción de todo el mercado".
En serio, conociendo la forma tradicional de actuar de Apple, y tras el duro golpe a su orgullo -por muchas explicaciones que den, tener que regalar un protector de goma es una humillación a su imagen- me parece inevitable.
En serio, conociendo la forma tradicional de actuar de Apple, y tras el duro golpe a su orgullo -por muchas explicaciones que den, tener que regalar un protector de goma es una humillación a su imagen- me parece inevitable.
13 de julio de 2010
OpenSolaris lanza un ultimatum a Oracle
Según nos hemos enterado por el blog de un tal Ben Rockwood, el OpenSolaris Governing Board (OGB), o sea, la máxima entidad administrativa de la comunidad OpenSolaris, ha lanzado un ultimatum a Oracle: O envían un representante de la compañía para tratar el futuro de la comunidad y del desarrollo de OpenSolaris antes del 16 de Agosto, o la OGB se autodisolverá y devolverá la gestión de la comunidad a Oracle, algo que vendría a ser equivalente a certificar su muerte.
Esta medida drástica sin duda ha sido provocada por la clamorosa ausencia de actualizaciones de OpenSolaris. Se suponía que su próxima versión debería haber visto la luz en Marzo (tras haber sido retrasada un mes). En Marzo no apareció nada, y se dijo a la comunidad que la nueva versión se retrasaría hasta Junio. Estamos a principios de Julio, y ni rastro de nuevas versiones. Si hay motivos razonables que justifiquen tal retraso, Oracle no se los ha comunicado a la comunidad, no ha dado ni una sola explicación.
En un post de hace dos días, relacionado con este asunto, un tal Giovanni Tirloni revela como el número de casos PSARC (un sistema burocrático para hacer propuestas de nuevas características de Solaris) que no son revelados a la comunidad ha aumentado drásticamente hasta un 30% del total. Dicho de otra manera, que Oracle está planeando las nuevas características de Solaris en secreto, al margen de la comunidad. Desde luego todas estas cosas no son señales esperanzadoras. Esta situación es la que empuja a la OGB a tomar la medida drástica del ultimatum, a forzar a Oracle a aclarar sus planes de software libre, o a sincerarse y acabar con la farsa.
¿Qué hará Oracle? Difícil adivinarlo. Por las declaraciones hechas hasta hoy, no parece que tengan intención alguna de hacer que Solaris vuelva a ser un SO completamente propietario. Lo revelado hasta hoy apunta más bien a que quieren hacer una mezcla de partes privativas y libres con mayor presencia -mayor de la que ya de por si hacía Sun- de partes privativas. De ir por ese camino, es dudoso que la comunidad acepte alegremente tales reglas, y aun aceptándolas OpenSolaris no dejaría de ser una farsa que jamás desarrollaría una verdadera comunidad. Algunos en la comunidad hablan ya de volver a Linux/FreeBSD.
De matar Oracle la utopía de un Solaris verdaderamente libre, la única esperanza estaría en algo como Nexenta, que es una compañía análoga a Red Hat, con su distro de OpenSolaris propia, con la que es capaz de sacar algún dinero con el que contratar a programadores propios e impulsar el desarrollo del SO libre ellos solos. Claro que también cabe la posibilidad de que Oracle espabile y arregle todo este absurdo meollo de OpenSolaris en el que ellos mismos han decidido introducirse. ¿Pero acaso no han tenido ya tiempo de sobra para arreglar las cosas y no lo han hecho?
Esta medida drástica sin duda ha sido provocada por la clamorosa ausencia de actualizaciones de OpenSolaris. Se suponía que su próxima versión debería haber visto la luz en Marzo (tras haber sido retrasada un mes). En Marzo no apareció nada, y se dijo a la comunidad que la nueva versión se retrasaría hasta Junio. Estamos a principios de Julio, y ni rastro de nuevas versiones. Si hay motivos razonables que justifiquen tal retraso, Oracle no se los ha comunicado a la comunidad, no ha dado ni una sola explicación.
En un post de hace dos días, relacionado con este asunto, un tal Giovanni Tirloni revela como el número de casos PSARC (un sistema burocrático para hacer propuestas de nuevas características de Solaris) que no son revelados a la comunidad ha aumentado drásticamente hasta un 30% del total. Dicho de otra manera, que Oracle está planeando las nuevas características de Solaris en secreto, al margen de la comunidad. Desde luego todas estas cosas no son señales esperanzadoras. Esta situación es la que empuja a la OGB a tomar la medida drástica del ultimatum, a forzar a Oracle a aclarar sus planes de software libre, o a sincerarse y acabar con la farsa.
¿Qué hará Oracle? Difícil adivinarlo. Por las declaraciones hechas hasta hoy, no parece que tengan intención alguna de hacer que Solaris vuelva a ser un SO completamente propietario. Lo revelado hasta hoy apunta más bien a que quieren hacer una mezcla de partes privativas y libres con mayor presencia -mayor de la que ya de por si hacía Sun- de partes privativas. De ir por ese camino, es dudoso que la comunidad acepte alegremente tales reglas, y aun aceptándolas OpenSolaris no dejaría de ser una farsa que jamás desarrollaría una verdadera comunidad. Algunos en la comunidad hablan ya de volver a Linux/FreeBSD.
De matar Oracle la utopía de un Solaris verdaderamente libre, la única esperanza estaría en algo como Nexenta, que es una compañía análoga a Red Hat, con su distro de OpenSolaris propia, con la que es capaz de sacar algún dinero con el que contratar a programadores propios e impulsar el desarrollo del SO libre ellos solos. Claro que también cabe la posibilidad de que Oracle espabile y arregle todo este absurdo meollo de OpenSolaris en el que ellos mismos han decidido introducirse. ¿Pero acaso no han tenido ya tiempo de sobra para arreglar las cosas y no lo han hecho?
2 de julio de 2010
Linux y la fragmentación: el asignador de bloques de Ext4
(Nota: Este post es el cuarto y último de una serie de varios artículos sobre la fragmentación. Se recomienda leer la serie completa: 1, 2 y 3).
Continua la serie de artículos sobre la fragmentación en sistemas de archivo Linux. Este nuevo post trata sobre las novedades que incorporó Ext4 a su asignador de bloques. La información está sacada de este documento, y se puede también encontrar en un gran comentario al principio del archivo fs/ext4/mballoc.c.
El sistema de asignación de bloques es en gran medida el corazón de todo sistema de archivos, y los algoritmos utilizados tienen una gran importancia. Se trata de uno de esos puntos clave cuyos mecanismos siempre deben estar bien aceitados. No solo se les exige evitar la fragmentación, temática de esta serie de posts, también se les pide ser endiabladamente rápidos y muy escalables.
Una de las técnicas de organización del espacio que la mayoría de sistemas de archivos utilizan es subdividir el espacio disponible en partes de varios cientos de MB, de ese modo el sistema de archivos puede operar en varias subdivisiones a la vez casi independientemente. En el caso de Ext4, esa subdivisión se llama "grupo de bloques", y tiene un tamaño de 128 MB. Cada grupo de bloques tiene una serie de bloques dedicados a tareas especiales: hay unos en los que se almacenan los inodos (y cuya cantidad es estática y determinada por mkfs, razón por la que Ext4 no puede variar el número de inodos dinámicamente); también hay un bloque que se emplea en almacenar un mapa de bits que indica los bloques libres y los utilizados, y otro mapa de bits utilizado para indicar qué inodos están siendo utilizados. Cuando se va a iniciar una operación en un archivo, la decisión de asignación de bloques comienza, en principio, en el grupo de bloques al que pertenece el inodo del archivo, el cual suele asignarse en el grupo de bloques en el que está el inodo del directorio.
Ext4 dispone de dos espacios de preasignación principales a partir de los cuales se asignan bloques en un grupo de bloques: preasignación de CPU y preasignación de inodo. Las preasignaciones son rangos de bloques que no están siendo utilizados, pero están reservados y, en principio, no serán utilizados por nadie más. Si el archivo va a tener un tamaño menor a 16 bloques (64 KB), se utiliza el primer espacio de preasignación, si no, el segundo. De no poder atender la petición de asignación del espacio de preasignación, se procede a buscar espacio libre en un sistema de asignación "buddy" que contiene el resto del espacio que no está u ocupado o en las preasignaciones.
La razón por la que existen dos espacios de preasignación es para evitar que los archivos creados en una presignación no se entrometa en las del otro. Los archivos pequeños en un mismo directorio (por ejemplo, /etc/*) se benefician de estar ubicados uno a continuación del otro, los archivos grandes de asignaciones grandes y continuas. El sistema de preasignación de inodos (archivos grandes) también tiene, aparte de la preasignación, un sistema de "reservas" para casos en los que múltiples archivos se escribien simultáneamente.
Existe una forma muy curiosa de probar este sistema de preasignaciones, un ejemplo que curiosamente apareció en el segundo post de esta serie: la prueba del archivo al que se le añadía un bloque (4KB) en 200 ocasiones consecutivas, y que resultaba tener una fragmentación notable:
----------------------------------------------------------------
["oflag=append conv=notrunc" son ambos necesarios para que se vayan añadiendo datos al archivo, "conv=fsync" sincroniza el archivo a disco para asegurarse de que no se queda en RAM]
# for i in `seq 200`; do dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
[Un montón de datos de salida de dd]
----------------------------------------------------------------
Este archivo esta bastante fragmentado a pesar de ser un test simple y estar el sistema de archivos de pruebas completamente vacío. Echando un ojo a la salida detallada de filefrag, se puede intentar adivinar las causas de este comportamiento:
----------------------------------------------------------------
# filefrag -v prueba
Filesystem type is: ef53
File size of prueba is 819200 (200 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 34304 3
1 3 34816 34306 1
2 4 34307 34816 3
3 7 34817 34309 1
4 8 34310 34817 2
5 10 34818 34311 1
6 11 34312 34818 1
7 12 34819 34312 1
8 13 34313 34819 2
9 15 34820 34314 1
10 16 33808 34820 184 eof
prueba: 11 extents found
----------------------------------------------------------------
2 pequeños extents de 3 bloques, 2 de 2 bloques, 6 de 1 bloque...y luego uno grande de 184 bloques. ¿Por qué esa distribución tan absurda de los bloques? Si sumamos todos los extents pequeños -todos menos el de 184 bloques- obtenemos exactamente 16 bloques (64 KB). Precisamente el límite mencionado entre el espacio de preasignación para archivos pequeños y el de archivos grandes. ¿Que ha ocurrido? Parece ser que mientras el archivo era menor de 16 bloques, Ext4 le asignó espacio de la preasignación para archivos pequeños; una vez que creció más allá de ese tamaño se le asignaron bloques de espacio de preasignación para archivos grandes, que colocó los 184 bloques restantes contiguos, uno detrás de otro...
¿Por qué, sin embargo, se han creado tantos fragmentos pequeños en la preasignación de CPU, optimizada para archivos pequeños? El problema es que la preasignación de CPU, llamada "per-CPU" en su idioma original, contiene en si mismo varias preasignaciones, una para cada CPU. Esta técnica per-CPU es muy común en el kernel Linux, se tratan de arrays de variables, una para cada procesador del sistema, para que cada CPU pueda operar en su variable sin interferir con las demás. En el caso de la preasignación de CPU de Ext4, más que por cuestiones de escalabilidad el objetivo es que las asignaciones de un mismo proceso -que se ejecuta en una CPU determinada- estén físicamente juntas. El comando tar, por ejemplo, podría desempaquetar un conjunto de archivos pequeños, y al ejecutarse tar en una misma CPU, los desempaquetaría en el espacio de preasignación de esa CPU.
¿Qué ha ocurrido entonces en el ejemplo anterior del archivo? Pues que mi sistema tiene 2 CPUs, y el proceso dd se ha ejecutado cada vez en una de las CPUs, de modo que en cada añadidura de 4KB se utilizaba el espacio de preasignación de cada CPU. Cuando, por casualidad, dd se ha ejecutado en la misma CPU dos o tres veces seguidas, ha logrado crear pequeños extents de 2 ó 3 bloques, pero cuando había alternancia entre las CPUs utilizadas era necesario empezar un nuevo extent discontiguo respecto al anterior. Y hay un modo muy simple de confirmar esta teoría, que es forzar la ejecución de dd en una CPU determinada, utilizando taskset(1):
----------------------------------------------------------------
# for i in `seq 200`; do taskset -c 1 dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
[Un montón de datos de salida de dd]
Esta vez dd ha accedido en todas las ocasiones al mismo espacio de preasignación de CPU, y por consiguiente ha ubicado los 16 primeros bloques contiguos.
Para terminar el post, ¿por qué, podría preguntarse alguien, hay un límite entre ambas preasignaciones para archivos pequeños y grandes que está fijado 16 bloques, por qué ese número? Ese valor es, en realidad, configurable, y se puede cambiar en el archivo /sys/fs/ext4/DISPOSITIVO/mb_stream_req. Y con esto se descubre ese desconocido directorio, que como se puede comprobar, contiene otros archivos de configuración, varios de ellos parámetros para tunear el comportamiento del asignador de bloques (y documentados en Documentation/ABI/testing/sysfs-fs-ext4). La disponibilidad de tales parámetros demuestra que la asignación de bloques es un tema muy complejo, que puede necesitar atención en casos especiales o susceptible a optimizaciones para una carga determinada. Espero que todo esto demuestre que el tópico de que Linux no sufre fragmentación es muy opinable y depende de multitud de factores (y eso que ni siquiera se ha mencionado la necesidad actual de que los diferentes archivos de una misma aplicación estén contiguos), de ahí que la disponibilidad de e4defrag es necesaria y bienvenida.
Continua la serie de artículos sobre la fragmentación en sistemas de archivo Linux. Este nuevo post trata sobre las novedades que incorporó Ext4 a su asignador de bloques. La información está sacada de este documento, y se puede también encontrar en un gran comentario al principio del archivo fs/ext4/mballoc.c.
El sistema de asignación de bloques es en gran medida el corazón de todo sistema de archivos, y los algoritmos utilizados tienen una gran importancia. Se trata de uno de esos puntos clave cuyos mecanismos siempre deben estar bien aceitados. No solo se les exige evitar la fragmentación, temática de esta serie de posts, también se les pide ser endiabladamente rápidos y muy escalables.
Una de las técnicas de organización del espacio que la mayoría de sistemas de archivos utilizan es subdividir el espacio disponible en partes de varios cientos de MB, de ese modo el sistema de archivos puede operar en varias subdivisiones a la vez casi independientemente. En el caso de Ext4, esa subdivisión se llama "grupo de bloques", y tiene un tamaño de 128 MB. Cada grupo de bloques tiene una serie de bloques dedicados a tareas especiales: hay unos en los que se almacenan los inodos (y cuya cantidad es estática y determinada por mkfs, razón por la que Ext4 no puede variar el número de inodos dinámicamente); también hay un bloque que se emplea en almacenar un mapa de bits que indica los bloques libres y los utilizados, y otro mapa de bits utilizado para indicar qué inodos están siendo utilizados. Cuando se va a iniciar una operación en un archivo, la decisión de asignación de bloques comienza, en principio, en el grupo de bloques al que pertenece el inodo del archivo, el cual suele asignarse en el grupo de bloques en el que está el inodo del directorio.
Ext4 dispone de dos espacios de preasignación principales a partir de los cuales se asignan bloques en un grupo de bloques: preasignación de CPU y preasignación de inodo. Las preasignaciones son rangos de bloques que no están siendo utilizados, pero están reservados y, en principio, no serán utilizados por nadie más. Si el archivo va a tener un tamaño menor a 16 bloques (64 KB), se utiliza el primer espacio de preasignación, si no, el segundo. De no poder atender la petición de asignación del espacio de preasignación, se procede a buscar espacio libre en un sistema de asignación "buddy" que contiene el resto del espacio que no está u ocupado o en las preasignaciones.
La razón por la que existen dos espacios de preasignación es para evitar que los archivos creados en una presignación no se entrometa en las del otro. Los archivos pequeños en un mismo directorio (por ejemplo, /etc/*) se benefician de estar ubicados uno a continuación del otro, los archivos grandes de asignaciones grandes y continuas. El sistema de preasignación de inodos (archivos grandes) también tiene, aparte de la preasignación, un sistema de "reservas" para casos en los que múltiples archivos se escribien simultáneamente.
Existe una forma muy curiosa de probar este sistema de preasignaciones, un ejemplo que curiosamente apareció en el segundo post de esta serie: la prueba del archivo al que se le añadía un bloque (4KB) en 200 ocasiones consecutivas, y que resultaba tener una fragmentación notable:
----------------------------------------------------------------
["oflag=append conv=notrunc" son ambos necesarios para que se vayan añadiendo datos al archivo, "conv=fsync" sincroniza el archivo a disco para asegurarse de que no se queda en RAM]
# for i in `seq 200`; do dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
[Un montón de datos de salida de dd]
----------------------------------------------------------------
Este archivo esta bastante fragmentado a pesar de ser un test simple y estar el sistema de archivos de pruebas completamente vacío. Echando un ojo a la salida detallada de filefrag, se puede intentar adivinar las causas de este comportamiento:
----------------------------------------------------------------
# filefrag -v prueba
Filesystem type is: ef53
File size of prueba is 819200 (200 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 34304 3
1 3 34816 34306 1
2 4 34307 34816 3
3 7 34817 34309 1
4 8 34310 34817 2
5 10 34818 34311 1
6 11 34312 34818 1
7 12 34819 34312 1
8 13 34313 34819 2
9 15 34820 34314 1
10 16 33808 34820 184 eof
prueba: 11 extents found
----------------------------------------------------------------
2 pequeños extents de 3 bloques, 2 de 2 bloques, 6 de 1 bloque...y luego uno grande de 184 bloques. ¿Por qué esa distribución tan absurda de los bloques? Si sumamos todos los extents pequeños -todos menos el de 184 bloques- obtenemos exactamente 16 bloques (64 KB). Precisamente el límite mencionado entre el espacio de preasignación para archivos pequeños y el de archivos grandes. ¿Que ha ocurrido? Parece ser que mientras el archivo era menor de 16 bloques, Ext4 le asignó espacio de la preasignación para archivos pequeños; una vez que creció más allá de ese tamaño se le asignaron bloques de espacio de preasignación para archivos grandes, que colocó los 184 bloques restantes contiguos, uno detrás de otro...
¿Por qué, sin embargo, se han creado tantos fragmentos pequeños en la preasignación de CPU, optimizada para archivos pequeños? El problema es que la preasignación de CPU, llamada "per-CPU" en su idioma original, contiene en si mismo varias preasignaciones, una para cada CPU. Esta técnica per-CPU es muy común en el kernel Linux, se tratan de arrays de variables, una para cada procesador del sistema, para que cada CPU pueda operar en su variable sin interferir con las demás. En el caso de la preasignación de CPU de Ext4, más que por cuestiones de escalabilidad el objetivo es que las asignaciones de un mismo proceso -que se ejecuta en una CPU determinada- estén físicamente juntas. El comando tar, por ejemplo, podría desempaquetar un conjunto de archivos pequeños, y al ejecutarse tar en una misma CPU, los desempaquetaría en el espacio de preasignación de esa CPU.
¿Qué ha ocurrido entonces en el ejemplo anterior del archivo? Pues que mi sistema tiene 2 CPUs, y el proceso dd se ha ejecutado cada vez en una de las CPUs, de modo que en cada añadidura de 4KB se utilizaba el espacio de preasignación de cada CPU. Cuando, por casualidad, dd se ha ejecutado en la misma CPU dos o tres veces seguidas, ha logrado crear pequeños extents de 2 ó 3 bloques, pero cuando había alternancia entre las CPUs utilizadas era necesario empezar un nuevo extent discontiguo respecto al anterior. Y hay un modo muy simple de confirmar esta teoría, que es forzar la ejecución de dd en una CPU determinada, utilizando taskset(1):
----------------------------------------------------------------
# for i in `seq 200`; do taskset -c 1 dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
[Un montón de datos de salida de dd]
# filefrag -v prueba
Filesystem type is: ef53
File size of prueba is 819200 (200 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 34304 16
1 16 33808 34319 184 eof
prueba: 2 extents found
----------------------------------------------------------------Filesystem type is: ef53
File size of prueba is 819200 (200 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 34304 16
1 16 33808 34319 184 eof
prueba: 2 extents found
Esta vez dd ha accedido en todas las ocasiones al mismo espacio de preasignación de CPU, y por consiguiente ha ubicado los 16 primeros bloques contiguos.
Para terminar el post, ¿por qué, podría preguntarse alguien, hay un límite entre ambas preasignaciones para archivos pequeños y grandes que está fijado 16 bloques, por qué ese número? Ese valor es, en realidad, configurable, y se puede cambiar en el archivo /sys/fs/ext4/DISPOSITIVO
27 de junio de 2010
Linux y la fragmentación: "delayed allocation"
(Nota: Este post es el tercero de una serie de varios artículos sobre la fragmentación. Se recomienda leer la serie completa: 1, 2 y 4).
El anterior post tenía ejemplos de fragmentación de archivos en Ext4. Hay que recalcar que eran ejemplos muy muy simples, que en el mundo real ocurren cosas muchas más complejos como que haya una actualización de seguridad mientras algún programa hace otra cosa. Había afirmado que este post detallaría los algoritmos de asignación de bloques de Ext4, pero en su lugar tratará sobre la técnica "delayed allocation" (asignación retardada), que es quien se encarga de llamar a esos algoritmos y por tanto condiciona su funcionamiento.
En los sistemas de archivos sin asignación retardada, cuando una aplicación llama a write(), como parte de esa llamada se asignan los bloques para los datos. Aunque los datos no se vayan a escribir al disco en ese preciso momento y vayan a permanecer hasta decenas de segundos en el cache, aunque durante ese tiempo los bloques asignados no sean escritos, se asignarán igualmente. Este sistema puede provocar fragmentación, dado que en muchos casos se necesitan múltiples llamadas a write() para escribir enteramente un archivo. Se llamará, por tanto, al asignador de bloques en todas esas escrituras. Y, ¿cómo puede el asignador predecir todas las escrituras que se van a hacer, cómo predecir que un archivo va a llegar a los 2 GB cuando recibe el encargo de asignar los bloques para del primer mega? Simplemente no puede.
La técnica de asignación retardada, utilizada en sorprendentemente pocos sistemas de archivos (concretamente: en Ext4, XFS, ZFS, Btrfs y HFS+; su escaso uso se debe a haber sido considerada como peligrosa durante mucho tiempo), retrasa la asignación de los bloques hasta el momento en el que el caché se sincroniza al disco. Las llamadas a write() no provocan ninguna asignación de bloques, quienes las provocan son las rutinas de la VM cuando decide que es hora de sincronizar el caché. Este sistema permite que la escritura al disco de ese archivo se haga de una sola vez. El asignador de bloques sabe el tamaño total a asignar, tiene más información, por lo tanto puede tomar decisiones de asignación más inteligentes. En Ext4 existe una forma muy gráfica de ilustrar el funcionamiento de este mecanismo con ayuda, cómo no, del comando filefrag:
----------------------------------------------------------------
$ # Creamos un archivo de 4KB sin sincronizarlo inmediatamente al disco
$ dd if=/dev/zero of=prueba bs=1K count=4
[salida de dd]
$ filefrag -v prueba
Filesystem type is: ef53
File size of prueba is 4096 (1 block, blocksize 4096)
ext logical physical expected length flags
0 0 0 1 unknown,delalloc,eof
prueba: 1 extent found
----------------------------------------------------------------
----------------------------------------------------------------
$ sync
$ filefrag -v prueba
Filesystem type is: ef53
File size of prueba is 4096 (1 block, blocksize 4096)
ext logical physical expected length flags
0 0 36681 1 eof
prueba: 1 extent found
----------------------------------------------------------------
Como se ve, ya se ha asignado su bloque (igualmente se hubiera escrito al disco si dejamos pasar el tiempo).
Este sistema es muy bonito. Sin embargo, sería un error afirmar que es una receta para la infalibidad contra la fragmentación, ya que la sincronización del caché al disco se hace cuando a la VM le de la gana...y el comportamiento de la VM es muy, muy variable. En situaciones de poca memoria, una de las primeras cosas que hace es solicitar la sincronización del caché con el disco. Dada una situación extrema de escasez de memoria, se dará el caso de que nada más enviar una llamada write() la VM ordenará la sincronización del caché y provocará una asignación de bloques casi inmediatamente, aproximándose al comportamiento de sistemas de archivos sin asignación retardada.
Una prueba empírica: en el primer ejemplo del post anterior se escribían dos archivos de 10GB en paralelo, los parámetros de dd eran "bs=512M count=20", lo cual hacía que cada dd ocupara en memoria 512MB. El resultado fue de 164 y 155 extents en cada archivo. Repitiendo la prueba pero con parámetros "bs=1G count=10" hace que los dos procesos dd ocupen 2GB, lo cual aumenta la presión de memoria en mi sistema y provoca mayores llamadas de sincronización de la VM. Resultado, 305-311 extents por archivo, con mayor entrecruce de ambos archivos en el disco.
Por lo tanto, se observa como la fragmentación del sistema de archivos puede variar con algo tan trivial como la presión de memoria del sistema (y noten que muy a menudo se hacen benchmarks sin intentar reproducir este tipo de condiciones), y cómo es poco prudente afirmar la ausencia de fragmentación en Linux. Todo esto viene a girar alrededor de un concepto ya afirmado en el primer post: Todos los archivos se enfrentan a GBs y GBs de espacio libre, y la decisión de colocar un archivo en un lado u otro depende muy en gran medida de la implementación.
El próximo post tratará -esta vez si- sobre los algoritmos de asignación de bloques de Ext4.
El anterior post tenía ejemplos de fragmentación de archivos en Ext4. Hay que recalcar que eran ejemplos muy muy simples, que en el mundo real ocurren cosas muchas más complejos como que haya una actualización de seguridad mientras algún programa hace otra cosa. Había afirmado que este post detallaría los algoritmos de asignación de bloques de Ext4, pero en su lugar tratará sobre la técnica "delayed allocation" (asignación retardada), que es quien se encarga de llamar a esos algoritmos y por tanto condiciona su funcionamiento.
En los sistemas de archivos sin asignación retardada, cuando una aplicación llama a write(), como parte de esa llamada se asignan los bloques para los datos. Aunque los datos no se vayan a escribir al disco en ese preciso momento y vayan a permanecer hasta decenas de segundos en el cache, aunque durante ese tiempo los bloques asignados no sean escritos, se asignarán igualmente. Este sistema puede provocar fragmentación, dado que en muchos casos se necesitan múltiples llamadas a write() para escribir enteramente un archivo. Se llamará, por tanto, al asignador de bloques en todas esas escrituras. Y, ¿cómo puede el asignador predecir todas las escrituras que se van a hacer, cómo predecir que un archivo va a llegar a los 2 GB cuando recibe el encargo de asignar los bloques para del primer mega? Simplemente no puede.
La técnica de asignación retardada, utilizada en sorprendentemente pocos sistemas de archivos (concretamente: en Ext4, XFS, ZFS, Btrfs y HFS+; su escaso uso se debe a haber sido considerada como peligrosa durante mucho tiempo), retrasa la asignación de los bloques hasta el momento en el que el caché se sincroniza al disco. Las llamadas a write() no provocan ninguna asignación de bloques, quienes las provocan son las rutinas de la VM cuando decide que es hora de sincronizar el caché. Este sistema permite que la escritura al disco de ese archivo se haga de una sola vez. El asignador de bloques sabe el tamaño total a asignar, tiene más información, por lo tanto puede tomar decisiones de asignación más inteligentes. En Ext4 existe una forma muy gráfica de ilustrar el funcionamiento de este mecanismo con ayuda, cómo no, del comando filefrag:
----------------------------------------------------------------
$ # Creamos un archivo de 4KB sin sincronizarlo inmediatamente al disco
$ dd if=/dev/zero of=prueba bs=1K count=4
[salida de dd]
$ filefrag -v prueba
Filesystem type is: ef53
File size of prueba is 4096 (1 block, blocksize 4096)
ext logical physical expected length flags
0 0 0 1 unknown,delalloc,eof
prueba: 1 extent found
----------------------------------------------------------------
Como
vemos, filefrag no muestra la ubicación lógica ni física del archivo, la muestra como "unknow,
delalloc". Es decir, que no se sabe, y que está en estado de asignación retardada: La ubicación simplemente no existe aun, está aun pendiente de realizarse. Sin embargo, si ordenamos sincronizar inmediatamente
después el caché con el disco...
----------------------------------------------------------------
$ sync
$ filefrag -v prueba
Filesystem type is: ef53
File size of prueba is 4096 (1 block, blocksize 4096)
ext logical physical expected length flags
0 0 36681 1 eof
prueba: 1 extent found
----------------------------------------------------------------
Como se ve, ya se ha asignado su bloque (igualmente se hubiera escrito al disco si dejamos pasar el tiempo).
Este sistema es muy bonito. Sin embargo, sería un error afirmar que es una receta para la infalibidad contra la fragmentación, ya que la sincronización del caché al disco se hace cuando a la VM le de la gana...y el comportamiento de la VM es muy, muy variable. En situaciones de poca memoria, una de las primeras cosas que hace es solicitar la sincronización del caché con el disco. Dada una situación extrema de escasez de memoria, se dará el caso de que nada más enviar una llamada write() la VM ordenará la sincronización del caché y provocará una asignación de bloques casi inmediatamente, aproximándose al comportamiento de sistemas de archivos sin asignación retardada.
Una prueba empírica: en el primer ejemplo del post anterior se escribían dos archivos de 10GB en paralelo, los parámetros de dd eran "bs=512M count=20", lo cual hacía que cada dd ocupara en memoria 512MB. El resultado fue de 164 y 155 extents en cada archivo. Repitiendo la prueba pero con parámetros "bs=1G count=10" hace que los dos procesos dd ocupen 2GB, lo cual aumenta la presión de memoria en mi sistema y provoca mayores llamadas de sincronización de la VM. Resultado, 305-311 extents por archivo, con mayor entrecruce de ambos archivos en el disco.
Por lo tanto, se observa como la fragmentación del sistema de archivos puede variar con algo tan trivial como la presión de memoria del sistema (y noten que muy a menudo se hacen benchmarks sin intentar reproducir este tipo de condiciones), y cómo es poco prudente afirmar la ausencia de fragmentación en Linux. Todo esto viene a girar alrededor de un concepto ya afirmado en el primer post: Todos los archivos se enfrentan a GBs y GBs de espacio libre, y la decisión de colocar un archivo en un lado u otro depende muy en gran medida de la implementación.
El próximo post tratará -esta vez si- sobre los algoritmos de asignación de bloques de Ext4.
17 de junio de 2010
Linux y la fragmentación: provocando fragmentación en Ext4
(Nota: Este post es el segundo de una serie de varios artículos sobre la fragmentación. Se recomienda leer la serie completa: 1, 3 y 4).
El anterior post defendiendo la existencia de fragmentación bajo Linux fue recibido con escepticismo. Para ser justos, la excesiva longitud del anterior post llevó a no extenderlo más de lo necesario. En este post, mostraremos un par de casos triviales en los que se puede observar fragmentación en sistemas Linux usando Ext4.
En primer lugar, una prueba muy simple, escribir dos archivos grandes a la vez. Se lanzan en paralelo dos procesos dd que crearán sendos archivos de 10 GB. Para que no haya dudas, la prueba se hace en un sistema de archivos recién formateado (nota: dd parece ocupar la memoria especificada en bs, es decir, en este test los dos procesos dd ocupan 1GB de RAM)
----------------------------------------------------------------
Una vez terminados de crear los archivos, se examina la fragmentación....
----------------------------------------------------------------
prueba-2: 155 extents found
----------------------------------------------------------------
Antes de continuar, aclarar que el tamaño máximo de un extent en Ext4 es de 128 MB. Eso quiere decir que dada una asignación de bloques perfecta, un archivo de 10 GB ocuparía 80 extents contiguos. Sin embargo, los archivos recién creados han necesitado el doble (en otros sistemas o con diferentes parámetros de dd puede haber muchos menos o muchos más, y tiene su explicación).
No suena nada bien, y los detalles pueden revisarse comprobando la ubicación y límites de cada extent con filefrag prueba* -v (cuya extensa salida no pondré aquí). En mi caso hay varios extents de tamaño máximo, 32768 bloques -128 MB-, pero también varios de 4096 -16 MB- y alguno incluso con menos, varios de 20 y pico mil, 16 mil, 12 mil...en definitiva: irregular. Si cotejamos datos de la columna "physical" de ambos archivos, el problema es más evidente: los extents de los dos archivos se van entrecruzando. Por ejemplo, el primer extent de archivo-1, el primero de archivo-2, y el segundo extent de archivo-1, van uno detrás de otro.
Y esto es con dos archivos. Imagínense 5 ó 10. O más. Y no estamos hablando de casos extravagantes y sacados de contexto, sino simplemente de copiar archivos.
Hay que ser justos y señalar que esto no es un problema de rendimiento en equipos comunes, ya que una cosa es fragmentarse en pedacitos de pocos KB por todo el disco, y otra hacerlo en pedazos de 128 ó incluso 16 MB, esta fragmentación probablemente ni siquiera se note en benchmaks. Sin embargo, no sirve de excusa para ignorarla. En equipos donde se requieran sistemas de almacenamiento profesionales es de imaginar que Ext4 no de la talla (por esta razón existen empresas con sistemas de archivo e incluso SOs propietarios especializados exclusivamente en optimizar casos como estos). Pero tampoco hay que irse por las nubes, bastaría con copiar dos archivos grandes a la vez a través de una interfaz gráfica para reproducir este problema.
Pero hay otros ejemplos simples. ¿Qué tal, por ejemplo, un archivo vacío al que se añaden 4KB (1 bloque) 200 veces, simulando una especie de archivo de log que va creciendo? En un sistema de archivos Ext4 nuevamente formateado desde cero, por supuesto. Cabría esperar que simplemente se añadieran los 200 bloques uno detrás de otro, ¿verdad?
----------------------------------------------------------------
["oflag=append conv=notrunc" son ambos necesarios para que se vayan añadiendo datos al archivo, "conv=fsync" sincroniza el archivo a disco para asegurarse de que no se queda en RAM]
# for i in `seq 200`; do dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
[Un montón de datos de salida de dd]
# filefrag prueba
prueba: 9 extents found
----------------------------------------------------------------
Si echamos un ojo a los datos de filefrag prueba -v, resulta que los 200 bloques están divididos en un extent con 184 bloques, otro con 7, dos con 2, y cinco con 1, y los extents no son contiguos entre ellos. Fragmentación discriminada y absurda (tengo una teoría razonable que explique este absurdo comportamiento, pero tendrá que esperar a un artículo posterior).
En definitiva, como se puede ver la fragmentación en Linux ocurre. Probablemente se podrían buscar más casos, algunos de ellos retorcidos como variar el tamaño de los archivos asignados con truncate(1) o archivos "sparse"...pero estos casos son simples y demuestran que no hace falta romperse la cabeza para encontrar fragmentación en Linux. Si quieren encontrar fragmentación en sus propios sistemas, prueben a buscar con filefrag por su $HOME. Sugiero empezar por este:
# filefrag ~/.mozilla/firefox/*.default/*.sqlite
Los archivos places.sqlite, cookies.sqlite, formhistory.sqlite y urlhistory3.sqlite, que corresponden a las bases de datos sqlite que utiliza Firefox en versiones modernas, seguramente estén divididos en varios fragmentos si su perfil de Firefox lleva funcionando un tiempo. Cosas como esta, entre otras, son las que hacen que nada más arrancar Firefox y se trata de introducir una url, la AwesomeBar tarde un poco más en leer el disco y reaccionar. Si son administradores de bases de datos, los archivos de la base de datos pueden tener cierta fragmentación acumulada. /var (las bases de datos de paquetes dpkg/rpm en particular) también son buenos candidatos. ¿A que ahora los desfragmentadores no parecen una idea tan estúpida? (un modo cutre y fácil de imitarlos es copiar el archivo fragmentado en otro y mover el archivo copiado al original)
El próximo post será sobre el funcionamiento de los algoritmos de asignación de bloques de Ext4. Ya puestos, por qué no hacer de esto una serie...
El anterior post defendiendo la existencia de fragmentación bajo Linux fue recibido con escepticismo. Para ser justos, la excesiva longitud del anterior post llevó a no extenderlo más de lo necesario. En este post, mostraremos un par de casos triviales en los que se puede observar fragmentación en sistemas Linux usando Ext4.
En primer lugar, una prueba muy simple, escribir dos archivos grandes a la vez. Se lanzan en paralelo dos procesos dd que crearán sendos archivos de 10 GB. Para que no haya dudas, la prueba se hace en un sistema de archivos recién formateado (nota: dd parece ocupar la memoria especificada en bs, es decir, en este test los dos procesos dd ocupan 1GB de RAM)
----------------------------------------------------------------
# for i in `seq 2`; do (dd if=/dev/zero of=prueba-$i bs=512M count=20 &); done
---------------------------------------------------------------- Una vez terminados de crear los archivos, se examina la fragmentación....
----------------------------------------------------------------
# filefrag prueba*
prueba-1: 164 extents foundprueba-2: 155 extents found
----------------------------------------------------------------
Antes de continuar, aclarar que el tamaño máximo de un extent en Ext4 es de 128 MB. Eso quiere decir que dada una asignación de bloques perfecta, un archivo de 10 GB ocuparía 80 extents contiguos. Sin embargo, los archivos recién creados han necesitado el doble (en otros sistemas o con diferentes parámetros de dd puede haber muchos menos o muchos más, y tiene su explicación).
No suena nada bien, y los detalles pueden revisarse comprobando la ubicación y límites de cada extent con filefrag prueba* -v (cuya extensa salida no pondré aquí). En mi caso hay varios extents de tamaño máximo, 32768 bloques -128 MB-, pero también varios de 4096 -16 MB- y alguno incluso con menos, varios de 20 y pico mil, 16 mil, 12 mil...en definitiva: irregular. Si cotejamos datos de la columna "physical" de ambos archivos, el problema es más evidente: los extents de los dos archivos se van entrecruzando. Por ejemplo, el primer extent de archivo-1, el primero de archivo-2, y el segundo extent de archivo-1, van uno detrás de otro.
Y esto es con dos archivos. Imagínense 5 ó 10. O más. Y no estamos hablando de casos extravagantes y sacados de contexto, sino simplemente de copiar archivos.
Hay que ser justos y señalar que esto no es un problema de rendimiento en equipos comunes, ya que una cosa es fragmentarse en pedacitos de pocos KB por todo el disco, y otra hacerlo en pedazos de 128 ó incluso 16 MB, esta fragmentación probablemente ni siquiera se note en benchmaks. Sin embargo, no sirve de excusa para ignorarla. En equipos donde se requieran sistemas de almacenamiento profesionales es de imaginar que Ext4 no de la talla (por esta razón existen empresas con sistemas de archivo e incluso SOs propietarios especializados exclusivamente en optimizar casos como estos). Pero tampoco hay que irse por las nubes, bastaría con copiar dos archivos grandes a la vez a través de una interfaz gráfica para reproducir este problema.
Pero hay otros ejemplos simples. ¿Qué tal, por ejemplo, un archivo vacío al que se añaden 4KB (1 bloque) 200 veces, simulando una especie de archivo de log que va creciendo? En un sistema de archivos Ext4 nuevamente formateado desde cero, por supuesto. Cabría esperar que simplemente se añadieran los 200 bloques uno detrás de otro, ¿verdad?
----------------------------------------------------------------
["oflag=append conv=notrunc" son ambos necesarios para que se vayan añadiendo datos al archivo, "conv=fsync" sincroniza el archivo a disco para asegurarse de que no se queda en RAM]
# for i in `seq 200`; do dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
[Un montón de datos de salida de dd]
# filefrag prueba
prueba: 9 extents found
----------------------------------------------------------------
Si echamos un ojo a los datos de filefrag prueba -v, resulta que los 200 bloques están divididos en un extent con 184 bloques, otro con 7, dos con 2, y cinco con 1, y los extents no son contiguos entre ellos. Fragmentación discriminada y absurda (tengo una teoría razonable que explique este absurdo comportamiento, pero tendrá que esperar a un artículo posterior).
En definitiva, como se puede ver la fragmentación en Linux ocurre. Probablemente se podrían buscar más casos, algunos de ellos retorcidos como variar el tamaño de los archivos asignados con truncate(1) o archivos "sparse"...pero estos casos son simples y demuestran que no hace falta romperse la cabeza para encontrar fragmentación en Linux. Si quieren encontrar fragmentación en sus propios sistemas, prueben a buscar con filefrag por su $HOME. Sugiero empezar por este:
# filefrag ~/.mozilla/firefox/*.default/*.sqlite
Los archivos places.sqlite, cookies.sqlite, formhistory.sqlite y urlhistory3.sqlite, que corresponden a las bases de datos sqlite que utiliza Firefox en versiones modernas, seguramente estén divididos en varios fragmentos si su perfil de Firefox lleva funcionando un tiempo. Cosas como esta, entre otras, son las que hacen que nada más arrancar Firefox y se trata de introducir una url, la AwesomeBar tarde un poco más en leer el disco y reaccionar. Si son administradores de bases de datos, los archivos de la base de datos pueden tener cierta fragmentación acumulada. /var (las bases de datos de paquetes dpkg/rpm en particular) también son buenos candidatos. ¿A que ahora los desfragmentadores no parecen una idea tan estúpida? (un modo cutre y fácil de imitarlos es copiar el archivo fragmentado en otro y mover el archivo copiado al original)
El próximo post será sobre el funcionamiento de los algoritmos de asignación de bloques de Ext4. Ya puestos, por qué no hacer de esto una serie...
12 de junio de 2010
Linux y la fragmentación: si, ocurre
(Nota: Este post es el primero de una serie de varios artículos sobre la fragmentación. Se recomienda leer las serie completa: 2, 3 y 4).
El tópico de que Linux no necesita desfragmentación ha vuelto renacer. Suele hacerlo periódicamente, aunque por desgracia eso no lo haga más cierto. Ese argumento de que los sistemas de archivos en Linux no se fragmentan o que lo hace tan poco que apenas se nota, y que en NTFS en cambio lo hacen una barbaridad, nunca va acompañado, si se fijan, de una explicación. Eso es porque no la hay.
Creo que el origen del mito es visual. Windows tiene un desfragmentador de serie que muestra (mostraba) un bonito gráfico donde se ve el estado y progreso de la fragmentación, la cual deja de ser un concepto abstracto para volverse algo real, que se puede percibir mediante los sentidos. Oh, mira cuanta fragmentación. En una instalación Linux típica no hay ningún desfragmentador y mucho menos con gráficos, y al no verse nada es como que no existe (o se obtiene la cifra media de fragmentos/archivo, que es una bonita manera de ocultar la realidad con estadísticas): Oh, no tenemos fragmentación. Pero aunque no la veamos, existe. Hubo un tiempo en el que un servidor de ustedes muy de vez en cuando movía todo su sistema de una partición a otra del disco duro (cp -a), y la disminución del tiempo de inicio del sistema y del tiempo que transcurre entre KDM/GDM y la aparición del escritorio se podían medir en el reloj y en el menor carraspeo del disco duro. Apostaría a que la acertada decisión de eliminar la parte visual del desfragmentador en Windows Vista/7 se debe a la falsa sensación de conocimiento que mucha gente creía tener con las imágenes visuales.
Hay un par de cosas respecto a este asunto de la fragmentación que la mayoría de la gente (y en este blog, gente = frikis/geeks) desconoce de los sistemas de archivos. La primera es que los sistemas de archivos tienen muchas partes en común. El asignador de bloques para los datos, en particular -responsable de la fragmentación-, es un asignatura bastante común a todos, por no mencionar esos oscuros rincones en los que el sistema de archivos se funde de manera ambigua con la gestión de memoria.
En segundo lugar, una cosa es el formato físico del sistema de archivos, y otra su implementación. Una buena implementación puede incluso tapar los defectos de un sistema de archivos antiguo, y hacerlo mejor que uno nuevecito con una mala implementación. En Linux hay ejemplos muy próximos en los dos sentidos. Ext3/4 son sistemas de archivos viejos, desfasados, a diferencia de, por ejemplo, NTFS, que es claramente más moderno. Sin embargo la implementación de Ext4 es sobresaliente, capaz de competir con NTFS sin problemas e incluso con XFS en algunos puntos. En cambio Reiserfs v3 tiene un diseño muy nuevo, pero su implementación deja bastante que desear, por eso las empresas se pasaron a Ext4. Y algo con tanto prestigio como ZFS en todo su esplendor tuvo, nada más ser publicado y antes de mejorarlo, un algoritmo de asignación de bloques que se podía resumir con la frase "aquí te pillo, aquí te mato".
Uniendo los dos párrafos anteriores, se puede obtener la conclusión de que tomar decisiones de asignación de bloques que creen o no fragmentación en la disposición de los datos en el disco duro depende en gran medida de la implementación.
En principio, en teoría cualquier sistema de archivos puede hacer magníficas decisiones de asignación de bloques en lo que se refiere a fragmentación (otra cosa es el rendimiento y otros factores). Un buen ejemplo para comprenderlo es el caso de dos procesos escribiendo datos simultáneamente a dos archivos diferentes. Un asignador de bloques simple entrecruzará a lo largo del disco duro los datos de ambos archivos: primero un trozo del primer proceso, luego otro del segundo, posteriormente otro trozo del primero, etc, causando una fragmentación masiva. En cambio, un buen sistema debería detectar esta situación y tratar, por lo menos, de que los trozos que se entremezclen sean de un gran tamaño. Este tipo de heurísticas no dependen del formato del disco, y aunque cierto es que la facilidad para implementarlas esté influida por otros aspectos del sistema de archivos, a base de empeño un buen programador con muy poco respeto por la humanidad podría hacer maravillas hasta con FAT.
Resumiendo: Toda discusión sobre la fragmentación debería estar razonada en base a los algoritmos de asignación de bloques, que son quienes causan o evitan esa fragmentación. Los de Windows/NTFS no se conocen ni se conocerán nunca en detalle, pero los de Linux si que se conocen (aunque en todo google solo existan un par de referencias). Sin embargo, nunca los he visto expuestos en una discusión (no, esto no es suficiente), en cambio de Windows siempre se supone que no tienen absolutamente ni una sola línea de código dedicada a evitar la fragmentación, lo cual es una presunción (veo la imagen del desfragmentador, luego creo saber) demasiado atrevida. Sirva de ejemplo de desconocimiento de este tema que a pesar de que Ext4 incorpora varios cambios para evitar diferentes tipos de fragmentación, en tiempos del reinado del Ext3, que carece de esos cambios (y por tanto se fragmenta más), se afirmaba de todos modos que Linux no sufría fragmentación. O, peor aun, se afirma que los sistemas de archivos Unix previenen la fragmentación basándose en...¿exactamente qué hechos? (es más, ZFS y Btrfs se fragmentan una auténtica barbaridad por virtud de las técnicas COW).
Echen en Linux un ojo a la herramienta filefrag, como curiosidad yo tengo una ISO de un DVD en un Ext4 bajada con wget que está dividida en mil y pico extents. Y un SVG de 1.2 MB con 8 (un caso muy raro), y varias películas divididas en cientos cada una. Fragmentación pura y dura bajo un kernel 2.6.35-rc3 (eso si, si obtenemos la cifra media de fragmentos/archivo, los miles de archivos menores de 4KB rebajarán la media y harán que parezca que no pasa nada). Y no todo es culpa del sistema de archivos, no es casualidad que POSIX tenga la función fallocate(), es una prueba de que existen casos en los que un asignador de bloques no pueden predecir el futuro. Además, hay que tener en cuenta la fragmentación entre diferentes archivos, un tipo de fragmentación muy importante para el rápido inicio del sistema y de las aplicaciones y que prácticamente requiere un desfragmentador. No es casualidad que XFS, Ext4, y Btrfs tengan desfragmentadores, simplemente se necesitan (para Btrfs puede llegar a convertirse en un requisito).
Por supuesto, si usted quiere puede vivir sin desfragmentador, e incluso las distros Linux podrían no usarlo bajo la regla de que casi nunca hace falta, pero por esa regla de tres también Windows podría eliminarlo basándose en esa lógica. Lo acertado de Microsoft en este campo es que en vez de negar el problema y pretender que no existe, han proporcionado una herramienta para arreglarlo (también es bonito lo que hace OS X, defragmentar automáticamente un archivo al abrirlo si detecta que está fragmentado). Es como el caso de "no-tenemos-fsck-porque-nuestro-sistema-de-archivos-no-lo-necesita", puedes negar que necesitas un fsck todo lo que quieras, pero el mundo real es muy puñetero y aparecen usuarios necesitándolo. Lo mismo para los desfragmentadores.
Este tema es muy amplio (y se podría hablar de las mejoras de algoritmos que usa Ext4 y tal, y casos que no cubren), pero definitivamente no será en esta entrada, que ya es lo suficientemente larga...
El tópico de que Linux no necesita desfragmentación ha vuelto renacer. Suele hacerlo periódicamente, aunque por desgracia eso no lo haga más cierto. Ese argumento de que los sistemas de archivos en Linux no se fragmentan o que lo hace tan poco que apenas se nota, y que en NTFS en cambio lo hacen una barbaridad, nunca va acompañado, si se fijan, de una explicación. Eso es porque no la hay.
Creo que el origen del mito es visual. Windows tiene un desfragmentador de serie que muestra (mostraba) un bonito gráfico donde se ve el estado y progreso de la fragmentación, la cual deja de ser un concepto abstracto para volverse algo real, que se puede percibir mediante los sentidos. Oh, mira cuanta fragmentación. En una instalación Linux típica no hay ningún desfragmentador y mucho menos con gráficos, y al no verse nada es como que no existe (o se obtiene la cifra media de fragmentos/archivo, que es una bonita manera de ocultar la realidad con estadísticas): Oh, no tenemos fragmentación. Pero aunque no la veamos, existe. Hubo un tiempo en el que un servidor de ustedes muy de vez en cuando movía todo su sistema de una partición a otra del disco duro (cp -a), y la disminución del tiempo de inicio del sistema y del tiempo que transcurre entre KDM/GDM y la aparición del escritorio se podían medir en el reloj y en el menor carraspeo del disco duro. Apostaría a que la acertada decisión de eliminar la parte visual del desfragmentador en Windows Vista/7 se debe a la falsa sensación de conocimiento que mucha gente creía tener con las imágenes visuales.
Hay un par de cosas respecto a este asunto de la fragmentación que la mayoría de la gente (y en este blog, gente = frikis/geeks) desconoce de los sistemas de archivos. La primera es que los sistemas de archivos tienen muchas partes en común. El asignador de bloques para los datos, en particular -responsable de la fragmentación-, es un asignatura bastante común a todos, por no mencionar esos oscuros rincones en los que el sistema de archivos se funde de manera ambigua con la gestión de memoria.
En segundo lugar, una cosa es el formato físico del sistema de archivos, y otra su implementación. Una buena implementación puede incluso tapar los defectos de un sistema de archivos antiguo, y hacerlo mejor que uno nuevecito con una mala implementación. En Linux hay ejemplos muy próximos en los dos sentidos. Ext3/4 son sistemas de archivos viejos, desfasados, a diferencia de, por ejemplo, NTFS, que es claramente más moderno. Sin embargo la implementación de Ext4 es sobresaliente, capaz de competir con NTFS sin problemas e incluso con XFS en algunos puntos. En cambio Reiserfs v3 tiene un diseño muy nuevo, pero su implementación deja bastante que desear, por eso las empresas se pasaron a Ext4. Y algo con tanto prestigio como ZFS en todo su esplendor tuvo, nada más ser publicado y antes de mejorarlo, un algoritmo de asignación de bloques que se podía resumir con la frase "aquí te pillo, aquí te mato".
Uniendo los dos párrafos anteriores, se puede obtener la conclusión de que tomar decisiones de asignación de bloques que creen o no fragmentación en la disposición de los datos en el disco duro depende en gran medida de la implementación.
En principio, en teoría cualquier sistema de archivos puede hacer magníficas decisiones de asignación de bloques en lo que se refiere a fragmentación (otra cosa es el rendimiento y otros factores). Un buen ejemplo para comprenderlo es el caso de dos procesos escribiendo datos simultáneamente a dos archivos diferentes. Un asignador de bloques simple entrecruzará a lo largo del disco duro los datos de ambos archivos: primero un trozo del primer proceso, luego otro del segundo, posteriormente otro trozo del primero, etc, causando una fragmentación masiva. En cambio, un buen sistema debería detectar esta situación y tratar, por lo menos, de que los trozos que se entremezclen sean de un gran tamaño. Este tipo de heurísticas no dependen del formato del disco, y aunque cierto es que la facilidad para implementarlas esté influida por otros aspectos del sistema de archivos, a base de empeño un buen programador con muy poco respeto por la humanidad podría hacer maravillas hasta con FAT.
Resumiendo: Toda discusión sobre la fragmentación debería estar razonada en base a los algoritmos de asignación de bloques, que son quienes causan o evitan esa fragmentación. Los de Windows/NTFS no se conocen ni se conocerán nunca en detalle, pero los de Linux si que se conocen (aunque en todo google solo existan un par de referencias). Sin embargo, nunca los he visto expuestos en una discusión (no, esto no es suficiente), en cambio de Windows siempre se supone que no tienen absolutamente ni una sola línea de código dedicada a evitar la fragmentación, lo cual es una presunción (veo la imagen del desfragmentador, luego creo saber) demasiado atrevida. Sirva de ejemplo de desconocimiento de este tema que a pesar de que Ext4 incorpora varios cambios para evitar diferentes tipos de fragmentación, en tiempos del reinado del Ext3, que carece de esos cambios (y por tanto se fragmenta más), se afirmaba de todos modos que Linux no sufría fragmentación. O, peor aun, se afirma que los sistemas de archivos Unix previenen la fragmentación basándose en...¿exactamente qué hechos? (es más, ZFS y Btrfs se fragmentan una auténtica barbaridad por virtud de las técnicas COW).
Echen en Linux un ojo a la herramienta filefrag, como curiosidad yo tengo una ISO de un DVD en un Ext4 bajada con wget que está dividida en mil y pico extents. Y un SVG de 1.2 MB con 8 (un caso muy raro), y varias películas divididas en cientos cada una. Fragmentación pura y dura bajo un kernel 2.6.35-rc3 (eso si, si obtenemos la cifra media de fragmentos/archivo, los miles de archivos menores de 4KB rebajarán la media y harán que parezca que no pasa nada). Y no todo es culpa del sistema de archivos, no es casualidad que POSIX tenga la función fallocate(), es una prueba de que existen casos en los que un asignador de bloques no pueden predecir el futuro. Además, hay que tener en cuenta la fragmentación entre diferentes archivos, un tipo de fragmentación muy importante para el rápido inicio del sistema y de las aplicaciones y que prácticamente requiere un desfragmentador. No es casualidad que XFS, Ext4, y Btrfs tengan desfragmentadores, simplemente se necesitan (para Btrfs puede llegar a convertirse en un requisito).
Por supuesto, si usted quiere puede vivir sin desfragmentador, e incluso las distros Linux podrían no usarlo bajo la regla de que casi nunca hace falta, pero por esa regla de tres también Windows podría eliminarlo basándose en esa lógica. Lo acertado de Microsoft en este campo es que en vez de negar el problema y pretender que no existe, han proporcionado una herramienta para arreglarlo (también es bonito lo que hace OS X, defragmentar automáticamente un archivo al abrirlo si detecta que está fragmentado). Es como el caso de "no-tenemos-fsck-porque-nuestro-sistema-de-archivos-no-lo-necesita", puedes negar que necesitas un fsck todo lo que quieras, pero el mundo real es muy puñetero y aparecen usuarios necesitándolo. Lo mismo para los desfragmentadores.
Este tema es muy amplio (y se podría hablar de las mejoras de algoritmos que usa Ext4 y tal, y casos que no cubren), pero definitivamente no será en esta entrada, que ya es lo suficientemente larga...
Suscribirse a:
Entradas (Atom)