Atención: Post largo no apto para tadingas L5, muchas letras y pocos dibujos. Se recomienda un IQ superior a 100 para leer/entender/comentar.



Arch Linux toma un nuevo rumbo




En distribuciones rolling como Arch, se intercalan las temporadas tranquilas en que no hay que preocuparse demasiado por el sistema con temporadas de bastante movimiento, en la que las listas de correo arden en discusiones eternas y en las que el usuario tiene que tomar cartas en ciertos asuntos por fuerza.

Así, después de un tiempo sin mucha novedad, de pronto, nos encontramos la semana pasada con un movimiento frenético en varios frentes.

Comenzamos con un llamado del mismísimo Allan McRae de hacer una especie de censo de quién está haciendo qué, continuamos con un anuncio sorprendente de que se pasaba a usar la nueva ABI (Interfaz Binaria de Aplicaciones) de C++11 (que implicaba una actualización enorme del sistema) y, para cerrar la semana, con un segundo anuncio de que Arch Linux abandonaba oficialmente el soporte a KDE Plasma 4 y acaba ayer domingo con un mensaje de Allan McRae que considero una clarísima declaración de intenciones en la mejor de las direcciones.

Aunque seguramente buena parte de lo que ha sucedido estos días ya se vendría cociendo entre los desarrolladores en su lista de correo privada, la sensación "estética" que me dio, al menos a mí, si se me permite la metáfora, fue que un curioso y sano mensaje de Allan McRae, uno de los desarrolladores más conocidos e importantes de Arch, dinamitó todo un vendaval de cambios.


1. Sábado 5/12: ¿Dónde están las claves "maestras"?



Allan McRae envía el siguiente mensaje a arch-dev-public, en el que pide que se llame la atención sobre algo que sería francamente preocupante en cualquier distribución:


We have an issue with the response time of master key holders. Currently there are two new TUs that have not had their key signed by three master key holders.
[...]
Is it time to cycle our key holders? There are some good candidates that have been around here for multiple years and are very active still.



El problema consistía en que faltaba firmar con las claves "maestras" de la distribución las claves de dos nuevos TUs (Trusted Users, los encargados de supervisar AUR y de mantener el repositorio community).

Este procedimiento, que existe, con sus particularidades, en todas las distribuciones grandes, es el equivalente criptográfico a que una organización certifique que una persona tiene un cargo en su estructura interna. Es una forma técnica de reconocer a esos TUs que efectivamente lo son.

Que no se les firmaran sus claves no les impedía, al menos técnicamente, que ellos pudieran firmar paquetes, pero en la red de confianza PGP no figuraría en su firma el hecho de que Arch confía en su identidad, cosa que se lleva a cabo para certificar que quien está empaquetando o manteniendo un cierto paquete oficial del repositorio comunitario es alguien avalado por la distribución y para lo cual en Arch basta tan solo con la firma de tres claves maestras de un total de cinco.


(Nota: AUR no es el repositorio comunitario de Arch, a pesar de lo que muchas veces se dice en blogs erróneamente; AUR es un repositorio de ports de usuarios. AUR no es parte de Arch Linux y un repositorio comunitario, por definición, es parte oficial de la distribución, aunque el soporte de los paquetes incluidos en él sea limitado; normalmente esto quiere decir que la distribución no publica parches propios de esos programas, sino que tan solo se actualiza usando código de upstream.

Se lo llama comunitario porque es mantenido por usuarios de la distribución y porque, en principio, cualquiera puede optar a ese puesto tan solo demostrando ser un usuario activo y capaz de la distribución. Esta situación es la misma que se da en Ubuntu con el repositorio comunitario
universe, por dar un ejemplo).


Como cualquier firma criptográfica solo la puede hacer quien tiene control sobre la clave privada, es necesario que los "dueños" de las claves maestras de Arch Linux estén activos. Si no, es absolutamente imposible que se pueda conseguir el requisito de que las claves OpenPGP de estos TUs puedan ser firmadas por tres claves "maestras" de Arch Linux, con el consiguiente retraso en la asunción de funciones de esos nuevos TUs que se traduce, al fin y al cabo, en menos capacidad de respuesta en el mantenimiento de paquetes.


La pregunta final del mensaje de Allan McRae presagia lo que se ejecuta inmediatamente ese mismo sábado: es urgente hacer un censo de quién está activo y quién no en Arch Linux.


El llamamiento se hace a través de otro mensaje y con la habilitación de una página en la Arch Wiki donde cada miembro del personal de la distribución debe explicar qué hace y qué no. 



2. Sábado 5/12 y jueves 10/12: La nueva ABI de C++



No contento, se ve, con hacer ver que hay un problema con las claves "maestras", Allan McRae envía ese mismo sábado otro mensaje:


Hi everyone,
GCC-5.x release libstdc++ with a dual ABI [1]. The time has come torebuild everything C++ related to the new one!
This means:
- do not use for anything else
- do not update anything C++ until it is done
- help fixing anything that does not build...
[...]



Seguramente a todos vosotros os sonarán más las siglas API, de Interfaz de Programación de Aplicación (Application Programming Interface), concepto que creo que es mejor dejar para otra ocasión. La ABI es la Interfaz Binaria de Aplicación (Application Binary Interface) y consiste en el conjunto de interfaces que utilizan los programas una vez compilados para comunicarse entre ellos.

Si dos programas deben comunicarse (por ejemplo, un ejecutable que está vinculado a una biblioteca compartida), pero sus ABIs no son compatibles por alguna razón, la ejecución del conjunto formado por ambos fallará o, lo que es peor, puede acabar en comportamiento errático que corrompa datos en memoria.


En este caso se trataba ni más ni menos de una actualización de ABI de la biblioteca estándar de C++ en su implementación más utilizada en el Software Libre, a saber, la del Proyecto GNU. Una incompatibilidad de ABI en este nivel podría dejar un sistema entero bajo mínimos (quizás solo superable en grave por una incompatibilidad de ABI con la biblioteca estándar de C). Por ejemplo, la mayor parte de KDE Plasma, por no decir todo lo que esté diseñado para funcionar con Qt, estaba afectada por estar escrito en C++ y así, muchos otros componentes de uso bastante regular en cualquier distribución Linux. Este cambio no ha venido por simple "versionitis": aunque la actual versión del compilador C++ de GNU permite usar o la ABI anterior o la actual, Arch Linux ha tomado la decisión de forzar el uso de la nueva porque introduce cambia el funcionamiento de dos tipos de objetos muy utilizados para evitar ciertos problemas que hasta podrían acabar en vulnerabilidades de seguridad (para los iniciados en C++: elimina la posibilidad de Copy-on-Write en std::string y obliga a std::list a incluir su propio tamaño).




Así pues, los paquetes de programas escritos en C++ han tenido que ser recompilados, aunque sin cambios, para que sean compatibles otra vez con la nueva ABI.

Esto no puede traer problema alguno en los paquetes oficiales, porque, de hecho, se hizo de forma automática y probándolo en un repositorio oficial llamado staging, que Arch utiliza para acumular cambios que luego deben ser aplicados en bloque a toda la distribución. Sin embargo, donde esto sí puede provocar problemas es con aquellos paquetes que hayamos instalado y que no hayan sido actualizados por Arch; es decir, los paquetes de AUR, a los que se refuere bajo el oscuro término non-repo packages, supongo, para no dar la impresión de que Arch soporta AUR, pero no solo a estos, sino también a todos los paquetes que derivadas de Arch como Antergos o Manjaro agregan por sí mismas y que, técnicamente, desde el punto de vista de Arch son non-repo packages.


El día 10 se publica un anuncio oficial al respecto, el cual incluye un script para comprobar los paquetes no oficiales instalados en el sistema que necesitan ser recompilados. Sin embargo, Arch realmente no tenía ninguna necesidad de anunciar el cambio de ABI; el cambio se podría haber llevado perfectamente mediante una actualización de sistema, porque la solución para los paquetes oficiales afectados no pasaba más allá que por una actualización regular. Por otro lado, AUR realmente no es parte oficial de la distribución y mucho menos puede Arch hacerse responsable de los paquetes de otras distribuciones, sin importar que estas "beban" de sus repositorios.

Sin embargo, está claro que el equipo de la distribución sabe que el uso de AUR es mayoritario. Publicando ese anuncio con un script para comprobar qué paquetes locales (¡solo comprueba los locales!) están afectados por el cambio de ABI, el equipo de Arch (y la comunidad) se ahorra una buena cantidad de hilos en las listas de correo y tiempo. Sin anuncio, además, las derivadas se podrían  encontrado un día con que nada escrito en C++ funciona correctamente, sin que estas pudieran encontrar la causa en su propia distribución. De esta manera, en cambio, Arch deja claro qué es lo que ha hecho, con total transparencia, y, entonces, sí puede descargar a las derivadas la responsabilidad de rehacer sus paquetes afectados.



Podemos decir que el día 10 Arch Linux actuó un poco como Debian. Aunque no sean de su responsabilidad, ha querido evitarle problemas a sus derivadas y a los usuarios (y mantenedores) de paquetes de AUR.

Cuando una distribución mira un poco más allá de los límites de aquello que considera como "propio" y empieza a pensar en las consecuencias externas de sus decisiones es porque está tomándose muy en serio lo que está haciendo. Debian comunica a Ubuntu y derivadas todo tipo de cambios (recordad el caso de systemd) e, incluso, esta comunicación sucede a la inversa. Con pasos como estos, aunque en esta ocasión, que se sepa, no ha habido una apelación directa a las derivadas, se abren lentamente las puertas de la colaboración entre proyectos, tradicionalmente cerradas o no totalmente abiertas entre los miembros de la familia de distribuciones basadas en Arch (especialmente con Manjaro, como recordaréis de las polémicas entradas de McRae en su blog).




3. Sábado 12/12: Adiós a KDE Plasma 4

Arch decide, oficial y públicamente, abandonar el soporte a KDE Plasma 4 el día 12. Realmente ha sido una decisión esperable, dado que el Proyecto KDE ya no soporta Plasma 4 desde hace meses y, de hecho, ya se venía presagiando que esto pasaría en algún momento del año 2015 cuando se anunció que Plasma 5 entraba a los repositorios oficiales de Arch allá por el mes de enero.


Hasta aquí parece una simple transición hacia una versión más moderna de un programa (o conjunto de programas), pero el cambio sorprendió a algunos usuarios que mostraron de inmediato su disconformidad con la decisión. Resulta conocido para todos nosotros que, aunque KDE Plasma 5 tenga ya más de un año de vida oficial, sin contar tiempo de desarrollo (Plasma 5.0 fue publicado en julio de 2014), no está aún maduro, a pesar de ir ya por su quinta versión menor (Plasma 5.5 fue publicado este mes de diciembre).

Esto ha obligado a usuarios a mantenerse en Plasma 4 todo este tiempo, por diversas razones, como la que explica este usuario, que ha enviado un mensaje a arch-general en el cual explica que le es imposible usar dos monitores con Plasma 5 (el usuario lo atribuye a Qt 5, pero me parece extraño que tenga que ver con una biblioteca de creación de interfaces gráficas).


Esta noticia parece desconectada del resto, pero no lo está. Por un lado, se relaciona con la necesidad de racionalizar el trabajo de un equipo que, si bien no está sobrepasado, necesita deshacerse de todo aquello que pueda ser eliminado para concentrarse en lo que realmente vale la pena.

Por otro, el cambio de ABI de C++ podía tener consecuencias en el recompilado de KDE Plasma 4; el cambio de ABI es retrospectivo y afecta también a código que no esté escrito, en principio, según los nuevos estándares de C++ (C++11 y "C++14", que realmente es una revisión de C++11). Tener que recompilar un código tan monstruoso y que no está ya más soportado para hacerlo funcionar con una nueva ABI puede, de hecho, engendrar más problemas que soluciones.

En el caso de un programa que sí esté soportado por sus desarrolladores, siempre se puede contactar con ellos para buscar soluciones en caso de que un cambio así tenga efectos no deseados, pero en el caso de una versión descontinuada, poco se puede hacer.


Los componentes esenciales han sido puestos a disposición de los usuarios en AUR, pero la petición del usuario antes mencionado es imposible de cumplir por parte de Arch, que es una distribución que no puede permitirse el lujo de mantener por su propia cuenta y riesgo un código que, por mucho cariño que le podamos tener aquellos a los que nos gustaba Plasma 4, ya no tiene el soporte ni de sus propios creadores.


Una distribución, como su propio nombre indica, distribuye software, no lo mejora ni lo mantiene funcionando; ni siquiera una distribución como Debian, que es la antítesis de Arch en términos de ritmos, lo hace: su soporte se restringe a parchar sus paquetes para incorporarles actualizaciones de seguridad o a resolver fallos de los componentes más críticos del sistema operativo.



4. Domingo 13/12: El manifiesto programático de Allan McRae


Así llegamos a ayer domingo 13 de diciembre, día en que nos encontramos con este mensaje de Allan McRae, que no es ni más ni menos un "programa" de hacia dónde caminará Arch Linux en el tiempo que viene. No lo copio aquí porque tiene cierta longitud, pero recomiendo vivamente su lectura.


La conclusión de Allan McRae, al hilo, obviamente, de los problemas que hubo con las claves "maestras" es que Arch debe mejorar su organización. De ahí que el anuncio de la creación de equipos temáticos, al igual que Debian, es una de las mejores noticias con las que cerrar el año 2015 y comenzar el 2016.

Es un paso en la dirección a ser una distribución de referencia con personas especializadas en el empaquetado y mantenimiento de distintos tipos de aplicaciones. Vemos referencias a que hay que ponerse las pilas con el firmado de repositorios (no solo de paquetes, como ya se viene haciendo), a que se ha mejorado en seguridad pero que el equipo de seguridad debería tener permisos de empaquetado como los TUs y desarrolladores, etc.




4. ¿A qué viene todo esto?



El hilo conductor de las acciones producidas durante estos días me parece evidente: Arch cumple como una distribución para los que somos unos entusiastas fanáticos de las distribuciones Linux porque recibimos lo último de lo último (en general) y sin modificaciones, pero ahora que se ha ganado cierta masa crítica se debe dar el salto a una mejor y mayor infraestructura.

Debian es lo que es porque tiene una infraestructura sencillamente bestial, incluyendo estadísticas de casi todo lo que sucede en ella, un sistema robusto de toma de decisiones al tiempo que una estructura de trabajo muy definida, etc. Arch Linux por ahora lo ha tenido fácil porque, en el fondo, ha hecho muy bien su trabajo porque se "limitaba" a empaquetar ("Arch es Linux con un gestor de paquetes", se solía decir), pero a medida que ha ido creciendo, se ha tomado en serio la responsabilidad de cuidar a sus usuarios, hasta el punto de prevenir implícitamente también a sus derivadas, como se ha visto con el cambio de ABI. 


Veo ambición sana por ser una distribución que funcione como las grandes. No nos debemos engañar; Arch está sobrerrepresentada en los blogs de blogsfera linuxera hispanohablante, supongo, porque es la que permite probar más cosas en menos tiempo, pero esa imagen no se corresponde con el peso real de Arch en el mundo de los sistemas Linux actualmente.

Arch Linux no es una distribución mayoritaria ni aspira a serlo, pero tampoco es, por el momento, una distribución relevante,
porque hasta ahora no ha podido tomar decisiones tecnológicamente interesantes, salvo, quizás, pacman. Esta falta de capacidad viene justamente por la hasta ahora falta de "cuerpo" de la distribución. Ciertamente, tampoco la ha necesitado justamente por lo que he comentado antes, porque el trabajo de Arch se limitaba en buena medida en proporcionar paquetes, pero creo que ya es hora de que Arch muestre al resto de la comunidad su experiencia como rolling extrema que funciona sin problemas.


Confío en que los cambios que se vislumbran harán de Arch Linux una distribución relevante en la comunidad Linux. Poder influir con código o formas de hacer las cosas es un objetivo noble e incluso diría necesario para aportar a la gran comunidad del Software Libre experiencias y conocimientos nuevos de los que se puedan aprovechar todos. Mayoritaria no lo será nunca, porque la filosofía que defiende implica que el usuario tenga un perfil determinado (no diría de "experto", sino de "manitas" y con ganas de leer documentación), pero puede dar a luz a cosas realmente interesantes.

Lo que me parece indudable es que ya esta semana Arch se ha probado el "traje" de distribución "grande" y tiene toda la pinta de que ese es el camino que se quiere seguir.



Se vienen tiempos interesantes y fascinantes, de eso no hay dudas. Seguramente no soy imparcial, porque Arch es la distribución en la cual confío para trabajar diariamente y todo el mundo que me conoce sabe que siento profunda admiración por la calidad del trabajo que lleva a cabo esta distribución todos los días, sin que quepan pequeños descansos como en las distribuciones con lanzamientos periódicos. Incluso así, aun sabiéndome totalmente parcial, creo que esta semana ha sido, por supuesto, maravillosa para la maduración de Arch, pero, indirectamente, puede ser también el comienzo de algo bueno para toda la comunidad. Me quedo expectante por la futura evolución de los hechos.


Imagen: La imagen es una captura de pantalla de los registros del comando pacman -Syu el día 10 de diciembre en mi sistema, para que veáis tan solo una parte de lo que significó el cambio de ABI de C++.










Arch Linux toma un nuevo rumbo