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.

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...

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.