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.
22 de noviembre de 2010
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.
Suscribirse a:
Entradas (Atom)