Pues si, he probado la Alpha 2 de la R1 de Haiku. Y como tengo un blog, cuento mi impresión. Siento decepcionar por adelantado a quien espere una opinión positiva: Francamente, no entiendo que haya quien siga poniendo a este SO como ejemplo de lo que deben ser los SOs en el futuro. Eso, y que me encanta intentar ganar lectores perdiendo a otros.
No me interpreten mal. Entiendo que haya gente que escriba SOs alternativos, entiendo que haya gente que reescriba AmigaOS, BeOS o el propio Windows en código libre. Lo entiendo, lo admiro, y en algunos casos hasta lo apoyo (Wine me parece un proyecto imprescindible). Linux, en su día, fue uno de esos SOs alternativos, y sin la tozudez de sus defensores, si no se hubieran abrazado a sus aspiraciones más que a la triste realidad de lo que tenían entre manos, jamás habría salido de ese estado.
Sin embargo, no entiendo que un SO como Haiku se refugie en una especie de penitencia-imitación hasta el punto de haberse preocupado de implementar compatibilidad a nivel de código fuente y a nivel binario con un SO que nunca tuvo tantas aplicaciones como para hacer esa compatibilidad algo de vida o muerte. La actitud de los desarrolladores de Linux en sus primeros años siempre fue la contraria, más dispuestos a inventar cosas por si mismos que a fotocopiar exactamente las de otros Unix.
Uno se enfrenta por primera vez al escritorio de Haiku, le da al "botón de inicio" y lo primero que le viene a la cabeza es: Windows 98. ¿Qué otra idea va a venir, si la presentación de la lista de programas en forma de menú es idéntica, y la barra de tareas vertical es el mismo concepto que Microsoft ha abandonado en Windows 7? La interfaz es del mismo estilo: color gris uniforme, sin ningún tipo de degradado o animación simple. El diseño de las interfaces de usuario, muy a los 90. En el aspecto estético, es un viaje al pasado. Y que no se diga que la apariencia no es importante: Lo es porque la abundancia de adornos inútiles sin impacto en el rendimiento demuestran superioridad técnica ("yo puedo permitírmelo y tú no"), y lo es especialmente para un SO que pretende ser lo mejor en los escritorios.
Todo esto, repito, es normal y no es algo criticable (Linux tampoco es que sea precisamente perfecto), pero a uno le vienen los beoseros hablando del Sagrado Grial de los escritorios y tal, atacando con cualquier cosa cuando comentas en que a día de hoy el líder del asunto escritoril es OS X, y luego al probarlo
en ningún momento le da a uno la sensación de que esto sea el futuro de
los escritorios. De hecho, parece más bien un pasado ya superado, además de compartir los mismos errores de los escritorios actuales. El escritorio de BeOS y sus APIs no fue fundado sobre la aceleración de GPU que CoreAnimation o Clutter tratan de proporcionar, sino sobre el mismo modelo "2D" que ha demostrado ser insuficiente para, por ejemplo, hacer animaciones vitales para las interfaces táctiles. La única novedad gráfica que me ha parecido interesante es el visor de procesos que muestra una lista de procesos y barras que cambian dinámicamente en un menú contextual. Y no es algo precisamente revolucionario ni que no esté al alcance de otros toolkits.
Y quien dice gráficos, dice lo demás. Las novedades revolucionarias de BeOS ya no lo son tanto. ¿Volumen de sonido para cada aplicación? Linux lo tiene con Pulseaudio (tengo un plasmoid en mi escritorio con el que controlo los volúmenes de las diferentes aplicaciones que es francamente cómodo). ¿Queries del sistema de archivos? Akonadi tendrá más potencia que ese sistema. ¿Aprovechar las múltiples CPUs de un sistema multicore? El Gran Central Dispatch de OSX 10.6 logra lo mismo, excepto que es más potente y más simple de implementar en las aplicaciones. ¿Microkernel? Haiku ya no lo es, ha traicionado esos principios por razones de rendimiento.
En mi opinión, lo que debería hacer el proyecto Haiku es olvidarse de emular al viejo y superado BeOS, y construir un verdadero SO de escritorio del futuro. Tienen la posibilidad de ello porque tienen una ventaja que ningún SO tiene hoy en día, que es no partir completamente de cero, y poder permitirse modificaciones radicales al sistema. Cuanto más tarden en ponerse a ello, más difícil tendrán esa tarea.
29 de mayo de 2010
20 de mayo de 2010
Más rápido de lo que se esperaba
Interesantes tiempos estos que vivimos, en los que contemplamos en directo eventos como la liberación de VP8 ayer o la nueva Google TV de hoy. Sin embargo, la sensación que deja leer información de las charlas de la Google I/O 2010 es distinta. Tiene más que ver con uno de las notas de prensa que ha publicado Google estos días: La Web como la plataforma de desarrollo predilecta, la más requerida, en la que más dinero se invierte.
Esclarecedor ha sido ese momento de la keynote inicial de Google en la que hacen recuento de las aplicaciones de escritorio "tradicionales" más importantes del mundo, y como a partir de 2004 no ha aparecido ninguna gran aplicación nueva: El mismo año en que empiezan a salir a la luz cosas como Gmail o Google maps. Otro muy esclarecedor ha sido cuando han explicado con números que la TV es un medio mucho más masivo que internet, y que con GoogleTV, al mezclar TV e Internet, se abre la posibilidad de aplicaciones webs a toda esa gente.
El Google I/O de este año se ha establecido por lo tanto como el evento clave para anunciar las novedades más importantes en la web, el que define el rumbo que se seguirá. Sitios como http://mugtug.com/darkroom/ o http://www.clicker.tv han sido las encargadas de mostrar ayer el estado actual de las aplicaciones HTML5 -que no consta solo HTML- y de demostrar que no va en broma.
No sé a ustedes, pero a mi todas estas noticias de hoy me han dejado por fin claro el lugar de las aplicaciones web en el mundo, un lugar que hasta el día de hoy nunca había logrado comprender con claridad. Me parece que ese lugar es el de toolkit, con aspiraciones de lograr algo análogo a QT, Cocoa o .NET, pero distinto, y sin eliminar ni quitar relevancia a todo lo que no son toolkits (la definición de "toolkit", por supuesto, es otro tema). Todo esto no invalida los toolkits tradicionales, claro, pero los hace menos relevantes. ¿Es una locura pensar que de aquí a unos años la plataforma gráfica para juegos no de consola por definición será WebGL, y no Directx, por poner un ejemplo? ¿Es una locura que Gnome 3 tenga algunos de sus programas en Javascript?
Parece ser, por tanto, que todo este asunto de la web está avanzando a pasos agigantados, que ya no estamos teorizando sobre lo que veremos dentro de unos años sino que estamos ya en él, sumergiéndonos más y más con cada nueva versión del navegador. Parece que el futuro ha llegado mucho más rápido de lo que se esperaba.
Esclarecedor ha sido ese momento de la keynote inicial de Google en la que hacen recuento de las aplicaciones de escritorio "tradicionales" más importantes del mundo, y como a partir de 2004 no ha aparecido ninguna gran aplicación nueva: El mismo año en que empiezan a salir a la luz cosas como Gmail o Google maps. Otro muy esclarecedor ha sido cuando han explicado con números que la TV es un medio mucho más masivo que internet, y que con GoogleTV, al mezclar TV e Internet, se abre la posibilidad de aplicaciones webs a toda esa gente.
El Google I/O de este año se ha establecido por lo tanto como el evento clave para anunciar las novedades más importantes en la web, el que define el rumbo que se seguirá. Sitios como http://mugtug.com/darkroom/ o http://www.clicker.tv han sido las encargadas de mostrar ayer el estado actual de las aplicaciones HTML5 -que no consta solo HTML- y de demostrar que no va en broma.
No sé a ustedes, pero a mi todas estas noticias de hoy me han dejado por fin claro el lugar de las aplicaciones web en el mundo, un lugar que hasta el día de hoy nunca había logrado comprender con claridad. Me parece que ese lugar es el de toolkit, con aspiraciones de lograr algo análogo a QT, Cocoa o .NET, pero distinto, y sin eliminar ni quitar relevancia a todo lo que no son toolkits (la definición de "toolkit", por supuesto, es otro tema). Todo esto no invalida los toolkits tradicionales, claro, pero los hace menos relevantes. ¿Es una locura pensar que de aquí a unos años la plataforma gráfica para juegos no de consola por definición será WebGL, y no Directx, por poner un ejemplo? ¿Es una locura que Gnome 3 tenga algunos de sus programas en Javascript?
Parece ser, por tanto, que todo este asunto de la web está avanzando a pasos agigantados, que ya no estamos teorizando sobre lo que veremos dentro de unos años sino que estamos ya en él, sumergiéndonos más y más con cada nueva versión del navegador. Parece que el futuro ha llegado mucho más rápido de lo que se esperaba.
17 de mayo de 2010
Lo que trae Linux 2.6.34
Perdonen la falta de detalles, pero no he tenido tiempo de terminarlo (y quizás así sea mejor, porque me obliga a resumir). 2.6.34 ha sido publicado, entre las novedades están dos sistemas de archivos, un driver para obtener rendimiento de red nativo con KVM, mejoras de Btrfs, lockdep para RCU, optimizaciones de kprobes, mejoras de perf, suspensión/resumen del sistema asíncrono, soporte preliminar de Radeon 5xxx....he aquí una explicación detallada. La lista completa en inglés está aquí, como siempre
(aunque a lo mío yo no lo llamaría "inglés", y de hecho siempre viene
alguien detrás a corregirme pequeños fallos):
· Ceph: Un sistema de archivos distribuido, que puede considerarse vagamente similar a los conceptos de lustre o el googlefs. Es decir, distribuye varias copias de los datos entre los servidores, y si uno de ellos falla se replica en otro. Como suele ocurrir en este tipo de sistemas de archivo, los datos y metadatos se almacenan por separado, pero a diferencia de otros como Lustre, Ceph permite tener múltiples servidores de metadatos. Su autor principal es Sage Weil, quien lo inicio como parte de su tesis. En este artículo (o en este otro) se explica en detalle su funcionamiento. De progresar, podría hacer frente a Lustre y, además, estar mejor integrado en Linux. Una cosa curiosa es que Ceph utiliza para implementar ciertas características funcionalidades exclusivas de Btrfs (y, de hecho, han enviado parches para implementarlas), de modo que Ceph utiliza Btrfs como almacen seguro de sus objetos. Cabe notar además que es un sistema de archivos aun muy experimental
· LogFS: Es un sistema de archivos diseñado para dispositivos basados en "memoria flash" (SSD) y, como su nombre indica, su diseño está basado en la idea de estructura en forma de log (es decir, todas las operaciones del sistema de archivos se van añadiendo linealmente a la cabeza de log). Puede considerarse como el sucesor de JFFS2, al que supera en prácticamente todos los sentidos. A diferencia de otros sistemas de archivos para dispositivos SSD, tiene soporte rudimentario para funcionar en dispositivos basados en bloques (discos duros).
· Mejoras de Btrfs: En esta versión, Btrfs añade varias cosas:
· La capacidad de configurar qué subvolumen es el subvolumen por defecto. Esto permite cosas como, a la hora de actualizar el sistema, tomar un snapshot, actualizar, y configurar a a las actualizaciones como subvolumen por defecto. Y, si algo falla, se reconfigura el snapshot anterior como subvolumen por defecto. De hecho, ya existe en F13 un plugin que automáticamente toma snapshots antes de las actualizaciones y modifica incluso la configuración de Grub, permitiendo probar una versión de Fedora y volver a la anterior en caso de tener problemas con ella.
· Se ha añadido una nueva herramienta para gestionar btrfs, el comando "btrfs". Esta herramienta reemplaza a todas las herramientas anteriores.
· Se ha añadido la capacidad de listar todos los subvolúmenes del sistema (comando btrfs subvolume list)
· Se ha modificado el cálculo de df (que, para btrfs es mucho más complejo de lo normal), y se ha añadido un df propio detallado (comando btrfs filesystem df)
· Se pueden defragmentar archivos individuales, e incluso rangos determinados dentro de un archivo.
· Vhost net: Se trata de un driver que realiza una optimización para las funciones de red de virtio (la interfaz de IO de Linux para interactuar con eficiencia entre huéspedes e invitados de virtualización). Este driver elimina 4 llamadas al sistema por cada paquete de red, y consiguientemente toda la sobrecarga que ello implica. De ese modo, los invitados de un sistema KVM pueden tener un rendimiento de red prácticamente idéntico al del hardware nativo.
· Kprobes jump: Kprobes es el sistema que utiliza Systemtap para insertar "sondas" (probes) en puntos aleatorios del código kernel. Estas sondas insertan la instrucción "int3", que provoca una interrupción que el código de kprobes atiende obteniendo todos los datos que sean necesarios para Systemtap. En esta versión, Kprobes puede utilizar una simple instrucción "jmp", es decir, para llamar a Kprobes simplemente se hace un salto de código, que es mucho más eficiente. Con "int 3", una sonda tarda 0.5-1 microsegundos en desapacharse, con "jmp" apenas 0.1. Esto hace que la instrumentación en vivo sea aun menos notable en el sistema.
· Mejoras de perf: una nueva herramienta que analiza estadísticas de bloqueos (perf lock), y soporte para análisis entre distintas plataformas, por ejemplo un x86-32 bits y un SPARC 64 bits. Esto permite "empaquetar" los datos de un análisis de una carga concreta, y enviarselos por email a alguien para que sepa revisarlos y encontrar problemas.
· Lockdep para RCU: Lockdep es una herramienta de depuración que trata de precedir posibles fallos en los bloqueos del código mientras se ejecuta el sistema. Sin embargo, hasta ahora no incluía depuración para uno de los tipos de bloqueo más importantes y complejos de Linux, RCU. Esta versión, se añade soporte para ello.
· Generalized TTL Security Mechanism, private VLAN proxy arp: Dos nuevos RFCs (5082 y 3069). El primero es un sistema de protección especialmente útil para proteger routers contra ataques con paquetes BGP.
· Suspension/resumen asíncrono: Hasta ahora, la suspensión y resumen de los dispositivos en Linux era síncrono, es decir, se hacían las operaciones de suspensión y resumen del dispositivo uno detrás de otro. En esta versión se hacen en paralelo, lo cual acelera el proceso, especialmente el de resumen del sistema, aunque de momento solo lo utilizan los dispositivos PCI, USB y SCSI.
· Alternancia entre GPUs: Algunos portátiles incluyen múltiples GPUs, una de bajo rendimiento y consumo y otra de alto, y permiten cambiar dinámicamente entre ambas. Esta versión añade soporte para ello en Linux (aunque requiere reiniciar las X).
· Soporte preliminar de Radeon HD5xxx: Pero solo preliminar...
· Driver Ballon de VMware: El "Balloning" es una técnica que permite limitar la memoria que utilizan los invitados en los sistemas virtualizados con colaboración del invitado. Con este driver, los invitados Linux en huéspedes VMware podrán realizar esta función correctamente.
Esto es todo. Para la lista completa, ya saben, aquí.
· Ceph: Un sistema de archivos distribuido, que puede considerarse vagamente similar a los conceptos de lustre o el googlefs. Es decir, distribuye varias copias de los datos entre los servidores, y si uno de ellos falla se replica en otro. Como suele ocurrir en este tipo de sistemas de archivo, los datos y metadatos se almacenan por separado, pero a diferencia de otros como Lustre, Ceph permite tener múltiples servidores de metadatos. Su autor principal es Sage Weil, quien lo inicio como parte de su tesis. En este artículo (o en este otro) se explica en detalle su funcionamiento. De progresar, podría hacer frente a Lustre y, además, estar mejor integrado en Linux. Una cosa curiosa es que Ceph utiliza para implementar ciertas características funcionalidades exclusivas de Btrfs (y, de hecho, han enviado parches para implementarlas), de modo que Ceph utiliza Btrfs como almacen seguro de sus objetos. Cabe notar además que es un sistema de archivos aun muy experimental
· LogFS: Es un sistema de archivos diseñado para dispositivos basados en "memoria flash" (SSD) y, como su nombre indica, su diseño está basado en la idea de estructura en forma de log (es decir, todas las operaciones del sistema de archivos se van añadiendo linealmente a la cabeza de log). Puede considerarse como el sucesor de JFFS2, al que supera en prácticamente todos los sentidos. A diferencia de otros sistemas de archivos para dispositivos SSD, tiene soporte rudimentario para funcionar en dispositivos basados en bloques (discos duros).
· Mejoras de Btrfs: En esta versión, Btrfs añade varias cosas:
· La capacidad de configurar qué subvolumen es el subvolumen por defecto. Esto permite cosas como, a la hora de actualizar el sistema, tomar un snapshot, actualizar, y configurar a a las actualizaciones como subvolumen por defecto. Y, si algo falla, se reconfigura el snapshot anterior como subvolumen por defecto. De hecho, ya existe en F13 un plugin que automáticamente toma snapshots antes de las actualizaciones y modifica incluso la configuración de Grub, permitiendo probar una versión de Fedora y volver a la anterior en caso de tener problemas con ella.
· Se ha añadido una nueva herramienta para gestionar btrfs, el comando "btrfs". Esta herramienta reemplaza a todas las herramientas anteriores.
· Se ha añadido la capacidad de listar todos los subvolúmenes del sistema (comando btrfs subvolume list)
· Se ha modificado el cálculo de df (que, para btrfs es mucho más complejo de lo normal), y se ha añadido un df propio detallado (comando btrfs filesystem df)
· Se pueden defragmentar archivos individuales, e incluso rangos determinados dentro de un archivo.
· Vhost net: Se trata de un driver que realiza una optimización para las funciones de red de virtio (la interfaz de IO de Linux para interactuar con eficiencia entre huéspedes e invitados de virtualización). Este driver elimina 4 llamadas al sistema por cada paquete de red, y consiguientemente toda la sobrecarga que ello implica. De ese modo, los invitados de un sistema KVM pueden tener un rendimiento de red prácticamente idéntico al del hardware nativo.
· Kprobes jump: Kprobes es el sistema que utiliza Systemtap para insertar "sondas" (probes) en puntos aleatorios del código kernel. Estas sondas insertan la instrucción "int3", que provoca una interrupción que el código de kprobes atiende obteniendo todos los datos que sean necesarios para Systemtap. En esta versión, Kprobes puede utilizar una simple instrucción "jmp", es decir, para llamar a Kprobes simplemente se hace un salto de código, que es mucho más eficiente. Con "int 3", una sonda tarda 0.5-1 microsegundos en desapacharse, con "jmp" apenas 0.1. Esto hace que la instrumentación en vivo sea aun menos notable en el sistema.
· Mejoras de perf: una nueva herramienta que analiza estadísticas de bloqueos (perf lock), y soporte para análisis entre distintas plataformas, por ejemplo un x86-32 bits y un SPARC 64 bits. Esto permite "empaquetar" los datos de un análisis de una carga concreta, y enviarselos por email a alguien para que sepa revisarlos y encontrar problemas.
· Lockdep para RCU: Lockdep es una herramienta de depuración que trata de precedir posibles fallos en los bloqueos del código mientras se ejecuta el sistema. Sin embargo, hasta ahora no incluía depuración para uno de los tipos de bloqueo más importantes y complejos de Linux, RCU. Esta versión, se añade soporte para ello.
· Generalized TTL Security Mechanism, private VLAN proxy arp: Dos nuevos RFCs (5082 y 3069). El primero es un sistema de protección especialmente útil para proteger routers contra ataques con paquetes BGP.
· Suspension/resumen asíncrono: Hasta ahora, la suspensión y resumen de los dispositivos en Linux era síncrono, es decir, se hacían las operaciones de suspensión y resumen del dispositivo uno detrás de otro. En esta versión se hacen en paralelo, lo cual acelera el proceso, especialmente el de resumen del sistema, aunque de momento solo lo utilizan los dispositivos PCI, USB y SCSI.
· Alternancia entre GPUs: Algunos portátiles incluyen múltiples GPUs, una de bajo rendimiento y consumo y otra de alto, y permiten cambiar dinámicamente entre ambas. Esta versión añade soporte para ello en Linux (aunque requiere reiniciar las X).
· Soporte preliminar de Radeon HD5xxx: Pero solo preliminar...
· Driver Ballon de VMware: El "Balloning" es una técnica que permite limitar la memoria que utilizan los invitados en los sistemas virtualizados con colaboración del invitado. Con este driver, los invitados Linux en huéspedes VMware podrán realizar esta función correctamente.
Esto es todo. Para la lista completa, ya saben, aquí.
2 de mayo de 2010
systemd, otro reemplazo de init
Justo cuando parecía seguro que upstart era el futuro, cuando todas las distribuciones lo habían integrado o planeaban hacerlo, ocurre lo que tantas veces en el mundo linuxero: Sale alguien implementado algo totalmente diferente porque no termina de gustarle la nueva propuesta. Estas cosas sin duda son una enorme pérdida tiempo en muchos casos, pero también una gran fuente de creatividad. Ese es el caso de systemd, el nuevo juguete de Lennart Poettering (tambien creador del magnífico Pulseaudio).
Pero antes, algo sobre upstart. En lugar de usar dependencias de unos archivos a otros, como hicieron varias intentonas de paralelización del sistema tradicional sysvinit, las dependencias son en base a eventos. Por ejemplo, al iniciarse el sistema upstart genera el evento "startup". A continuación, upstart interpreta todos los archivos de eventos (trabajos, en jerga upstart) de /etc/event.d que tengan la dependencia "start on startup". El trabajo puede ejecutar un script, un comando, o emitir un evento ("emit mi-propio-evento"). En este último caso, upstart ejecutaría todos los trabajos que tengan un "start on mi-propio-evento". Tambien hay eventos específicos para interfaces de red, etc.
Poettering ha aplicado otro punto de vista al problema. Prescinde de las dependencias y la sincronización la relega a mecanismos sistémicos de bajo nivel. Bajo systemd todos los servicios del sistema podrían arrancarse a la vez, sin preocuparse de que tal servicio depende de otro. Por ejemplo, podría arrancarse X.org antes que D-Bus (que X.org necesita para pedir a udev la lista de dispositivos de entrada). Esto, claro está, causaría un fallo en el inicio de X.org, las dependencias de upstart existen, precisamente, para prevenir este problema. ¿Y qué hace systemd para evitar el fallo de X.org?
El truco utilizado es el mismo que utiliza inetd o el launchd de Mac OS X. Buena parte de las dependencias de sysvinit o de upstart están para que un servicio (ej, X.org) espere a que otro servicio arranque y cree un socket Unix (ej, el socket de D-Bus) para poder comunicarse con él. Bien, pues resulta que esos sockets pueden crearse antes de que los servicios (D-Bus en este caso) arranquen. systemd, mismamente, puede crearlos -pero sin "escuchar" lo que se envía a ellos-, y las aplicaciones (X.org) pueden conectarse e incluso escribir a ese socket, porque el kernel va guardando en un buffer todo, a espera de que alguien se decida a leerlo. Solo cuando esto sucede, systemd decide iniciar el servicio (D-Bus), que una vez finalizado su arranque se pone al día leyendo los buffers acumulados. Esto implica que las dependencias no son necesarias, systemd crearía todos los sockets de todos los servicios pero sin iniciar ninguno inicialmente, solo los arrancaría a medida que los clientes los intentan utilizar.
Hay una gran ventaja de este sistema sobre upstart, derivado de la ausencia de dependencias. Si en upstart hay, por ejemplo, varios servicios que tienen la línea "start on dbus", al iniciar D-Bus se iniciarán esos servicios (X.org, avahi, networkmanager, vaya usted a saber). Esto ocurre incluso si no era esa la intención del administrador. Con systemd esta situación no es posible. Simplemente se iniciaría X.org, o Networkmanager, o avahi, y D-Bus sería iniciado automáticamente sólo cuando alguien intente leer su socket.
Aun con todo lo hasta aquí descrito, systemd no sería más que una reimplementación del launchd de Mac OS X. Sin embargo, no se queda ahí. Poettering identifica otro "punto de contención" en el inicio: los montajes en el sistema de archivos. Ciertos servicios tienen que esperar a que ciertos puntos de montaje estén disponibles antes de iniciarse. Además, al iniciar el sistema hay que montar -y quizás fsck'ear- los sistemas de archivo que indique /etc/fstab (y mientras se hace esta tarea quizás se pierde la oportunidad de iniciar algunos scripts que tienen sus puntos de montaje ya montados). systemd se basa en el viejo y fiable autofs (un "montador automático") para aplicar la misma idea que en los sockets: todos los montajes posibles se pre-crean sin que esté montados realmente, y autofs los irá montando de verdad -y quizás fsckeando- a medida que los servicios intenten acceder a ellos, pero no antes. Con este sistema, systemd hace que /etc/fstab sea algo obsoleto o al menos prescindible.
Todo esto ya de por si hace de systemd una seria alternativa a upstart y una mejora respecto a otros sistemas de inicio. Sin embargo, un sistema de inicio debe hacer más cosas que gestionar lo descrito anteriormente. Debe intentar reiniciar un servicio si se cae, o apagarle y enviar una alerta al administrador si se cae demasiado. Para hacer bien esta tarea de niñera, el sistema de inicio debe tener conocimiento de lo que hacen todos los procesos hijos que los servicios crean, algo que no es sencillo en Unix (upstart lo logra analizando datos de /proc), ya que los procesos "nietos" del sistema de inicio pueden perderse y existir a su aire sin que su "abuelo" se entere de qué ocurre.
Para solucionarlo Poettering usa, en vez de los trucos que utilizan otros sistemas, una de las novedades más potentes y menos conocidas de los últimos kernels: "Control Groups" (cgroups). cgroups son "grupos de procesos" elegidos al azar, y que comparten, como grupo, una serie de características. Los hijos de un proceso de un cgroup heredan la pertenencia a ese cgroup. Esto permite a systemd gestionar a nietos y biznietos con seguridad. Pero tengamos en cuenta que las propiedades configurables de los cgroups pueden ser cosas como límites de CPU, de memoria, de prioridad de disco...pues systemd tambien permite, ya de paso, que los servicios puedan configurar todas esas características. Por ejemplo, updatedb puede configurarse para usar una prioridad de disco baja.
Hay mucho más que decir de este sistema: los tipos de archivos de configuración, o units, una UI para visualizar los servicios -escrita en Vala-, planes de una unit timer que sustituiría a cron, una unit swap, potencial reemplazo al menos de parte de la funcionalidad de los gestores de sesion de los escritorios (gnome-session/kdeinit), etc. Y varias funcionalidades avanzadas (por ejemplo, guardar el estado de los servicios en un momento dado, apagarlos todos, ir a un shell de emergencia, y regresar al estado anterior). El documento del proyecto es una lectura muy recomendable. Aun así, podemos decir que es, en principio, conceptualmente superior a upstart, y es muy fácil de migrar a él por no ser necesario reescribir scripts y crear nuevas dependencias.
Dado que Poettering trabaja para Red Hat, no será sorprendente que Fedora lo adopte en futuras versiones.
Pero antes, algo sobre upstart. En lugar de usar dependencias de unos archivos a otros, como hicieron varias intentonas de paralelización del sistema tradicional sysvinit, las dependencias son en base a eventos. Por ejemplo, al iniciarse el sistema upstart genera el evento "startup". A continuación, upstart interpreta todos los archivos de eventos (trabajos, en jerga upstart) de /etc/event.d que tengan la dependencia "start on startup". El trabajo puede ejecutar un script, un comando, o emitir un evento ("emit mi-propio-evento"). En este último caso, upstart ejecutaría todos los trabajos que tengan un "start on mi-propio-evento". Tambien hay eventos específicos para interfaces de red, etc.
Poettering ha aplicado otro punto de vista al problema. Prescinde de las dependencias y la sincronización la relega a mecanismos sistémicos de bajo nivel. Bajo systemd todos los servicios del sistema podrían arrancarse a la vez, sin preocuparse de que tal servicio depende de otro. Por ejemplo, podría arrancarse X.org antes que D-Bus (que X.org necesita para pedir a udev la lista de dispositivos de entrada). Esto, claro está, causaría un fallo en el inicio de X.org, las dependencias de upstart existen, precisamente, para prevenir este problema. ¿Y qué hace systemd para evitar el fallo de X.org?
El truco utilizado es el mismo que utiliza inetd o el launchd de Mac OS X. Buena parte de las dependencias de sysvinit o de upstart están para que un servicio (ej, X.org) espere a que otro servicio arranque y cree un socket Unix (ej, el socket de D-Bus) para poder comunicarse con él. Bien, pues resulta que esos sockets pueden crearse antes de que los servicios (D-Bus en este caso) arranquen. systemd, mismamente, puede crearlos -pero sin "escuchar" lo que se envía a ellos-, y las aplicaciones (X.org) pueden conectarse e incluso escribir a ese socket, porque el kernel va guardando en un buffer todo, a espera de que alguien se decida a leerlo. Solo cuando esto sucede, systemd decide iniciar el servicio (D-Bus), que una vez finalizado su arranque se pone al día leyendo los buffers acumulados. Esto implica que las dependencias no son necesarias, systemd crearía todos los sockets de todos los servicios pero sin iniciar ninguno inicialmente, solo los arrancaría a medida que los clientes los intentan utilizar.
Hay una gran ventaja de este sistema sobre upstart, derivado de la ausencia de dependencias. Si en upstart hay, por ejemplo, varios servicios que tienen la línea "start on dbus", al iniciar D-Bus se iniciarán esos servicios (X.org, avahi, networkmanager, vaya usted a saber). Esto ocurre incluso si no era esa la intención del administrador. Con systemd esta situación no es posible. Simplemente se iniciaría X.org, o Networkmanager, o avahi, y D-Bus sería iniciado automáticamente sólo cuando alguien intente leer su socket.
Aun con todo lo hasta aquí descrito, systemd no sería más que una reimplementación del launchd de Mac OS X. Sin embargo, no se queda ahí. Poettering identifica otro "punto de contención" en el inicio: los montajes en el sistema de archivos. Ciertos servicios tienen que esperar a que ciertos puntos de montaje estén disponibles antes de iniciarse. Además, al iniciar el sistema hay que montar -y quizás fsck'ear- los sistemas de archivo que indique /etc/fstab (y mientras se hace esta tarea quizás se pierde la oportunidad de iniciar algunos scripts que tienen sus puntos de montaje ya montados). systemd se basa en el viejo y fiable autofs (un "montador automático") para aplicar la misma idea que en los sockets: todos los montajes posibles se pre-crean sin que esté montados realmente, y autofs los irá montando de verdad -y quizás fsckeando- a medida que los servicios intenten acceder a ellos, pero no antes. Con este sistema, systemd hace que /etc/fstab sea algo obsoleto o al menos prescindible.
Todo esto ya de por si hace de systemd una seria alternativa a upstart y una mejora respecto a otros sistemas de inicio. Sin embargo, un sistema de inicio debe hacer más cosas que gestionar lo descrito anteriormente. Debe intentar reiniciar un servicio si se cae, o apagarle y enviar una alerta al administrador si se cae demasiado. Para hacer bien esta tarea de niñera, el sistema de inicio debe tener conocimiento de lo que hacen todos los procesos hijos que los servicios crean, algo que no es sencillo en Unix (upstart lo logra analizando datos de /proc), ya que los procesos "nietos" del sistema de inicio pueden perderse y existir a su aire sin que su "abuelo" se entere de qué ocurre.
Para solucionarlo Poettering usa, en vez de los trucos que utilizan otros sistemas, una de las novedades más potentes y menos conocidas de los últimos kernels: "Control Groups" (cgroups). cgroups son "grupos de procesos" elegidos al azar, y que comparten, como grupo, una serie de características. Los hijos de un proceso de un cgroup heredan la pertenencia a ese cgroup. Esto permite a systemd gestionar a nietos y biznietos con seguridad. Pero tengamos en cuenta que las propiedades configurables de los cgroups pueden ser cosas como límites de CPU, de memoria, de prioridad de disco...pues systemd tambien permite, ya de paso, que los servicios puedan configurar todas esas características. Por ejemplo, updatedb puede configurarse para usar una prioridad de disco baja.
Hay mucho más que decir de este sistema: los tipos de archivos de configuración, o units, una UI para visualizar los servicios -escrita en Vala-, planes de una unit timer que sustituiría a cron, una unit swap, potencial reemplazo al menos de parte de la funcionalidad de los gestores de sesion de los escritorios (gnome-session/kdeinit), etc. Y varias funcionalidades avanzadas (por ejemplo, guardar el estado de los servicios en un momento dado, apagarlos todos, ir a un shell de emergencia, y regresar al estado anterior). El documento del proyecto es una lectura muy recomendable. Aun así, podemos decir que es, en principio, conceptualmente superior a upstart, y es muy fácil de migrar a él por no ser necesario reescribir scripts y crear nuevas dependencias.
Dado que Poettering trabaja para Red Hat, no será sorprendente que Fedora lo adopte en futuras versiones.
Suscribirse a:
Entradas (Atom)