90 segundos odiando a systemd

¿Por qué, oh dioses de GNU/Linux, tenemos que aguantar estas regresiones? ¿Cómo es posible que a la gente le guste el engendro que aspira a controlarlo todo? ¿Es Poettering un topo destinado a destruir la paciencia del común de los usuarios? Si suben un poco más las temperaturas, ¿acabaré asado en mi propia casa? Tantas preguntas que responder y tan pocas ganas de hacer otra cosa que no sea despotricar… sí, amigos, esto es una entrada de «ranting», al más puro estilo norteamericano, de quejas y lamentos. De vez en cuando no viene mal desahogarse. Ya lo he hecho en varias ocasiones, así que tampoco es novedad. Algunos no entienden que personas que usan software libre y de código abierto tengan derecho a algo así. Son los del «aprende a programar y lo arreglas tú mismo». Perdonen si me descojono.

El error: «a stop job is running…»

Comencé a padecer esta lacra de minuto y medio de duración en Chakra, a raíz de una actualización que incluía una nueva versión de systemd, no recuerdo la numeración, por desgracia. El problema se repite en mi actual instalación de Arch Linux con KDE. Uno apaga el equipo y, de repente, cual mensaje pre-actualización de Windows, debe esperar un minuto y medio a que no-sé-cuál proceso termine.

Noventa segundos no es tanto. Puede parecer caprichoso, pero una de las razones por las que uno se compra un disco SSD es que el sistema se apague con rapidez. Especialmente cuando estás a punto de irte a dormir y has de esperar para apagar la regleta de enchufes. Será una estupidez, será una nimiedad y todo lo que queráis, pero hace unos meses no pasaba y ahora sí, lo cual saca a relucir, una vez más  – qué espanto – la palabra más lamentable en GNU/Linux desde que existe como sistema: regresión.

Al principio, como de costumbre, me puse en modo «esto lo arreglo yo». Duró poco esta vez, lo que tardé en encontrar montones de hilos a lo largo y ancho de la red de redes comentando el mismo problema. En lo que a Arch se refiere, hay uno en particular que sostiene que se ha solucionado el problema con una actualización en febrero. No es cierto. A lo mejor para el que abrió el hilo lo es, pero no para mí ni para muchos otros usuarios. En algunas de esas discusiones se echa la culpa a Chrome, en otras se sugiere acabar con los «core dumps» y así hasta acumular un buen puñado de remedios, ninguno de las cuales lo es, al menos para mí. Y a tenor de que dichos hilos ni tan siquiera han sido marcados con la etiqueta «Solucionado», parece que no soy el único.

En mis investigaciones sobre el asunto he encontrado algunos informes de este problema que se remontan al verano de 2014. Dos años, un lapso de tiempo que en términos informáticos es una auténtica barbaridad. Se podrá argumentar que hubo períodos en los que el error desapareció, aunque es difícil asegurarlo debido a que no es un problema dependiente de la distribución (el informe que acabo de enlazar se refiere a Fedora) y no todos los usuarios se topan con él. Parece claro, eso sí, que tampoco está relacionado con el entorno de escritorio que se use, pues les ha pasado a quienes usan gestores de ventanas, como i3. Si uno sigue rebuscando, esto es, empleando su tiempo en encontrar soluciones que no llegan, podrá observar cómo Poettering da por zanjado el asunto con un «patch» que lanzó en Abril. Por desgracia para él, y por ende para los demás usuarios, siguieron apareciendo informes con errores de este estilo, hasta llegar a mi favorito, en el que el propio desarrollador sentencia que el problema está en systemd, cierra el reporte de error y emplaza a los usuarios a abrir otros nuevos con cada fallo individual que encuentren. Qué horror.

La conclusión que saco de esto es que ha llegado el momento en que systemd se ha vuelto tan complejo, tan ingobernable, que saben que falla algo – cientos de usuarios damos fe de ello – pero no son capaces, tras meses de trabajo, de identificar qué es. Ese «puede ocurrir por una gran variedad de causas» que suelta Poettering es exactamente a lo que me refiero. Y así fue como GNU/Linux se alejó de los principios que le permitían que cada programa hiciese una cosa y la hiciese bien para convertirse en la amalgama de servicios que es a día de hoy. Un poquito más cerca de algo a lo que todo usuario de Windows se ha enfrentado más de una vez: que un fallo en el sistema sea imposible de localizar y de solucionar, siquiera por el caro soporte técnico de Microsoft. Enhorabuena, ya lo hemos conseguido.

El desencanto de un simple usuario de a pie

No puedo profundizar, aunque lo desee, en las causas técnicas del error. No tengo derecho porque carezco de los conocimientos para hacerlo. Otros, como Emiliano Marini o Eugenio M. Vigo, quienes saben mucho más que yo de los entresijos de systemd, han tratado estos temas en varias oportunidades en sus respectivos blogs. Mi postura es la del común de los usuarios de GNU/Linux, quien se cansa, con toda la razón, de estas regresiones infinitas, mientras observa con una mueca de escepticismo como se siguen lanzando «forks» y derivados de supuestas soluciones. La última, la que faltaba ya, la división en un sistema único de empaquetado que debía terminar con el infierno de las dependencias. El que aparezcan «división» y «único» en la misma frase creo que es lo suficientemente elocuente por sí solo y describe muy bien el eterno galimatías, el triste amateurismo en el que nunca dejará de moverse nuestro sistema preferido.

Muchos informes de error yacen en frías tumbas, de años de duración, sin que se lleguen a solucionar nunca del todo. La comunidad y los desarrolladores están siempre en continuo frenesí para sacar novedades, actualizaciones, características y funcionalidades… ¿por qué no pararse de una puñetera vez a arreglar lo que no funciona? La gente normal, el usuario «no poderoso» (del término «power user», en inglés, que creo que refleja bien lo que quiero decir) no precisa que se liberen versiones con tanta rapidez. Si todavía hay un buen puñado de gente aferrada a su Windows XP, ¿no tiene mucho más sentido pulir lo que ya tenemos, dotarlo de una sólida base? Pues no, en lugar de eso se crean «forks», nuevas versiones de escritorios que no son necesarias y la bola de nieve crece y crece. Más novedades, más errores sin solucionar, más frustraciones.

Bonus track: ¿y la suspensión para cuándo?

El culmen de mi infelicidad con esta postura del desarrollador linuxero lo alcanzo cuando pienso en la suspensión a RAM de mi equipo. Cuando lo compré, tras investigar un poco, conseguí que lo que hace Windows sin despeinarse – poner el ordenador en suspensión pasado un rato – lo hiciera también GNU/Linux. Llegó un momento en que esta capacidad dejó de funcionar, como se puede atestiguar por las revisiones, imagino que a partir de determinado kernel. Y eso es lo que hay. Hace tres años podías poner el sistema en suspensión y hoy no puedes. Si no te gusta, ya sabes, te tocará arreglarlo a ti mismo. Haber estudiado.

El software libre tiene multitud de lados buenos, algunos de los cuales poseen aristas envenenadas que nos llevan a lugares menos buenos. Es el precio a pagar por la libertad y se ha de aceptar tal cual. Un mundo donde los desarrolladores dejan a un lado sus egos y su voluntad de controlarlo todo en aras del bien común es, por crudo que suene, un sitio utópico al cual jamás se podrá llegar. Por eso siempre estaremos metidos en esta rueda, mil veces reinventada, donde «mi equipo funciona bien, salvo por esto y esto otro…»

«Yo uso GNU/Linux»

«¿Y te va bien?»

«De escándalo. Soy libre. Va tela de fluido. Lo único que pasa es que no puedo jugar al juego tal. Pero da igual, juego en mi partición Windows»

«Bah, entonces eso es poca cosa, ¿no?»

«Sí. También he tenido que cambiar de cliente P2P, porque el que me gusta no pilla los torrents al iniciar. No sé qué problema con el levantamiento de la red y no lo he podido arreglar»

«Bueno, hay muchos clientes de ésos, qué más da»

«Ya, claro. Luego está el asunto de la calidad del sonido… suena mucho mejor en Windows que en Linux, salvo en openSUSE, no sé por qué»

«Es raro, sí»

«Tampoco consigo que entre en modo suspensión. Es un coñazo, porque a veces me voy un rato de la habitación y sirve para ahorrar energía. Pero no va»

«Joder, vaya tela. ¿Alguna cosa más?»

«Bueno, sí. Al copiar archivos grandes a un pendrive el equipo se congela. Me pasaba en openSUSE y también en Arch, aunque en este último se soluciona al cabo de unos segundos. Solamente va bien en Ubuntu y derivadas»

«Uf, demasiados problemas me parecen ya»

«Pues también hay un icono que me desaparece de la bandeja del sistema de repente. Antes no me pasaba. Y luego está lo del apagado del equipo…»

«¿Qué pasa con eso?»

«Que no se apaga del tirón. Tengo que esperar 90 segundos a que se cierre un servicio o algo así»

«¿Y qué haces en ese tiempo?»

«Me acuerdo de Poettering y la madre que parió a systemd»

«Eres un friki»

Termino mi perorata, no se me enfaden. La auto-complacencia en que vive instalada mucha gente que participa en el desarrollo en GNU/Linux no es buena, a mi entender. Hay muchas cosas que no funcionan bien, algunas llevan años así, como en permanente estado beta. Sin embargo, artículos como este dan pie a que se mate al mensajero, o si no que se lo digan a Artem S. Tashkinov. Si es ese vuestro deseo, pues aquí esta el tío para aguantar lo que le echen.

Salud

PD 1: La imagen de cabecera está sacada del blog «Hack the system«, donde enlazan al genial artículo de Emiliano Marini titulado «¿Por qué systemd es una mierda?»

PD 2: Casi ninguno de los problemas mencionados se dan en Linux Mint 17.3, de hecho, únicamente el del sonido algo más bajo que en Windows. He tenido la suerte de regresar gracias a que he podido recuperar la copia de seguridad que hice con Clonezilla y cuyo primer intento de restauración me falló. Una vez más he encontrado problemas en Arch y, aunque me he esforzado en solucionarlos, no parece que de momento eso sea posible.