"Free"desktop.org: una camarilla amiguista creada para posicionarse y ordenar, no para sugerir lo mejor para el ecosistema UNIX.

Hacía mucho tiempo que quería desahogarme en cuanto a un tema que me tenía extremadamente preocupado, como tantos temas de la comunidad que nos ponen así. Y no se trata de "toxicidad en las comunidades" o amarillismos por el estilo. Afortunadamente, Entropía es un espacio sano, inclusivo, de respeto y tolerancia, y si bien la tónica es la que ya los compañeros y allegados conocen (no systemd, no Wayland, no Snaps, no Flatpaks, no Ubuntu, no RedHat, no IBM, y podríamos seguir...), tenemos colegas que utilizan estas tecnologías desde que son parte del grupo y seguimos siendo amigos hasta el día de hoy, cada cual por su camino; cada uno con lo que entiende que es mejor o con lo que le gusta o interesa más.

El artículo trata sobre la "free"desktop. Así, escrita entrecomilladamente.

Desde tiempos muy lejanos esta organización no me cerraba: yo veía claramente cómo pisoteaban, cómo se escondían detrás de un nombre, cómo tomaban posición por tecnologías de mierda en lugar de sugerir lo más sano para el ecosistema UNIX con argumento sólido.
Entonces, al necesitar redactar documentación para CRUX, me vi en la necesidad de tener que escribir sobre Python, Rust y sobre la "free"desktop para poder expresarme correctamente y poder presentar mis ideas con claridad, no dejando sombras de duda, porque para la militancia es importante no escribir en modo panfleto. Es importante que nos respeten por ser militantes, y sin el lado técnico, es difícil convencer o hacer dudar a quienes generalmente no quieren escuchar. Si se apela solo a la militancia, esta será una causa perdida.

Entonces, me decidí a buscar información pero sin sesgo de confirmación. No quise ir "año por año" o ir a la sección "controversias" de un apartado de Wikipedia, por más que hubiese estado muy bien hacerlo. Quise forzarme a hacerlo bien: con la pasión de siempre, pero exponiendo a la "free"desktop de manera que nadie pudiese decir "estás mintiendo", "estás atacando por atacar", "le erraste", o "esto es más de lo mismo".
Fui a mirar el prontuario de freedesktop.org, como te comentaba, y fui encontrando mucho más de lo que había ido a buscar en principio. Y esto fue revelador: no solo encontré muchas más cagadas de la "free"desktop que las que yo ya sabía que habían cometido, sino que encontré un patrón sistemático.
Y a este patrón sistemático no es mi intención dártelo servido, sino que mi idea es que vos mismo lo vayas descubriendo a medida que vayas leyendo. Hay que desenmascarar a los idiotas, uno por uno. Hay que exponerlos. No conozco una mejor forma de honestidad ni de brindar respeto a quienes confían en mí.

Durante la construcción de mi instalador para CRUX me topé, una y otra vez, con el mismo nombre en el medio de cada problema: "free"desktop.org. Al principio pensé que al menos en una pequeña parte era mala suerte: "justo este paquetito está alojado en los servidores de ellos y no se puede descargar, bueno, lo busco en otro lado, debe ser infraestructura mal mantenida". Después empecé a ver que no era "solo ese paquetito" o "solo aquél". Y empecé, inconscientemente, a "registrar mentalmente". Y cuando esa "música" se empezó a repetir incontroladamente dentro de mi cerebro, me di cuenta de que no estaba mirando una serie de accidentes, sino algo con forma. Así que me senté a investigar en serio: qué es "free"desktop, qué prometió ser, y qué hizo realmente en sus 26 años de vida. Lo que sigue no son mis impresiones. Son los hechos que encontré, con fecha y con fuente. Al final, a la conclusión, si es que la tenés, prefiero que la termines sacando vos solo.

Abajo del todo, vas a encontrar enlaces a los artículos involucrados en la investigación previa a escribir este artículo.  

Empecemos por lo que dicen ser.

Según su propio Mission Statement, "free"desktop.org existe para ser un foro neutral en donde compartir ideas sobre tecnologías de escritorios de código abierto, y para apoyar especificaciones compartidas entre múltiples escritorios. Su principio rector, escrito por ellos, es que un desarrollador pueda usar el entorno de su elección sin quedar atado a uno en particular. 

Retené a estas 3 palabras: neutral, agnóstico, libre.

Ahora, los hechos.

El origen (marzo de 2000). freedesktop.org fue fundada por Havoc Pennington, quien era desarrollador de GNOME y trabajaba directamente para Red Hat. El "foro neutral entre todos los escritorios" nació, entonces, de la mano del escritorio más grande y de la empresa comercial más interesada en el asunto. Este es un dato fundacional que yo intuía e imaginaba pero que no sabía. Y al leerlo, no pude empezar a frotarme las manos como lo hacen las moscas.

HAL (2000–2011). La Hardware Abstraction Layer fue uno de los primeros grandes proyectos de "free"desktop. Era una capa que "permitiría" a los escritorios detectar hardware de forma portátil. GNOME y KDE, juntos en este tipo de decisiones, como siempre, la adoptaron como pieza central de su stack. Poco después, ya era obligatoria. Y con el tiempo, la propia gente que la impulsó la describió -cito a la documentación de Ubuntu de la época- como "una mole monolítica inmantenible" que además duplicaba funciones que ya resolvían udev y el kernel. Todos sabemos lo pesado y tosco que se fue volviendo Ubuntu con el correr del tiempo. Lo que pienso es que si esta gente erradicó este adefesio por las mismas razones por las cuales se convirtieron en lo que son, ¿cuánto más adefesio era HAL de lo que nos podemos imaginar?
La abandonaron. Ubuntu, Debian, Fedora, KDE, GNOME y XOrg tuvieron que hacer la "halsectomía" (terminología del momento, "halsectomy"): arrancarse HAL de encima y rehacer el trabajo. Lo impuesto ayer fue el lastre de mañana, y el costo de migrar lo pagaron las distros y los usuarios, no quien lo empujó. ¿Hubo consecuencias para la "free"desktop? ¿Perdió credibilidad ante tamaña barrabasada? ¿Hizo autocrítica? ¿Corrigió su accionar después de esto? ¿Dejó de ser tenida en cuenta?

PulseAudio: otra pieza empujada "verde" por la "free"desktop (2004–2008).
El servidor de sonido de "free"desktop, creado por otro personaje cuestionable, Lennart Poettering, se convirtió en el estándar de audio de facto de Linux. Pero más allá de que hoy no solo funciona bien, sino que increíblemente logró convertirse en una de las piezas bastión más importantes -al César lo que es del César-, lo interesante es cómo llegó a serlo. En 2008, en plena conferencia técnica (Linux Plumbers Conference), el propio Poettering resumió el estado del audio en Linux con una frase cercana a "es un quilombo", y describió a su propia criatura, para los usuarios al día, como "el software que actualmente te rompe el audio". Insisto, lo dijo su propio autor, en público, y lo reportó LWN también. El problema no era el diseño ni el trabajo de Poettering, en este caso, sino que hubo un organismo que, otra vez, se lo empujó a las distribuciones cuando todavía estaba inmaduro. Cuando Ubuntu lo adoptó por defecto en "Hardy Heron" (8.04) y a los usuarios se les rompió el sonido en masa, la respuesta de Poettering fue que Ubuntu "no hizo un trabajo estelar, no hizo bien la tarea". Es decir: se distribuye a todo el ecosistema un componente que el propio autor sabe que no está listo, que explota en la cara de la gente, y la culpa termina puesta en quien lo adoptó, también, apresuradamente. El patrón -empujar temprano, que el costo lo paguen las distros y los usuarios- ya estaba escrito acá, años antes de systemd. Yo no lo había visto, ¿y vos?

Systemd, hospedado en casa (2010). Poettering, otra vez, presentó a systemd como un reemplazo del init, con una promesa soberbia y pedante: mejorar un arranque que tenía años de ingeniería social y estabilidad y que no necesitaba ser mejorado. "free"desktop.org lo hospeda, y conviene detenerse acá un segundo.

¿Un "foro de interoperabilidad de escritorios" adopta, alberga y bendice a un init system, que no es un escritorio ni tiene que ver con interoperabilidad entre escritorios? Hoy, systemd creció hasta absorber los logs, la red, el DNS, los montajes, la resolución de nombres y la hora. ¿Ya sabía de esto la "free"desktop?

Y respecto a aquella petulante promesa original de "arrancar mejor", la discusión técnica nunca estuvo de su lado: init systems como runit, s6 u OpenRC arrancan igual o más rápido, con una fracción de la complejidad y de forma comprensible y KISS. No se impuso por ser mejor en lo que prometía: se impuso. Y listo.

La amenaza de udev (2012). Este es el hito que más me sorprendió, porque está por escrito, en la lista de correo de la propia "free"desktop. Los desarrolladores de systemd/udev -Kay Sievers y... Poettering, una máquina imparable de producir herramientas de mierda para UNIX- declararon, más o menos textualmente: "udev en sistemas sin systemd es, a nuestros ojos, un callejón sin salida... espero con ansias el día en que podamos abandonar ese soporte por completo".

Por favor, leelo de nuevo si es necesario, para situarte en el contexto real.

Un componente esencial para detectar hardware, del que dependía todo el mundo Linux, con sus mantenedores anunciando que planeaban cortar el soporte a quien no adoptara a systemd: esto está citado, en la web, con fecha.

La telaraña org.freedesktop.* (permanente). Abrí una terminal y pedile a dbus la lista de servicios (busctl list --system)... Vas a ver desfilar a piezas que por cuyos nombres parecen sacadas de Android:

org.freedesktop.Accounts 
org.freedesktop.DBus
org.freedesktop.DisplayManager
org.freedesktop.Flatpak.SystemHelper
org.trinitydesktop.hardwarecontrol
org.freedesktop.login1
org.freedesktop.NetworkManager
org.freedesktop.nm_dispatcher
org.freedesktop.nm_priv_helper 
org.freedesktop.PolicyKit1
org.freedesktop.RealtimeKit1
org.freedesktop.resolve1
org.freedesktop.UDisks2
org.freedesktop.UPower
org.freedesktop.systemd1

... y más... una tras otra.

Buena parte del sistema operativo, de punta a punta, cuelga del namespace (el espacio de nombres, el prefijo bajo el cual se registran servicios) de freedesktop. PolicyKit necesita dbus, tu escritorio necesita PolicyKit, logind conversa con systemd. La dependencia no se impone con un decreto: se teje, pieza sobre pieza, hasta que sacar una sola termina por arrastrarlas a todas juntas.

El costo de resistir: elogind. ¿Qué pasa si no querés a systemd pero tu escritorio pide logind? Alguien tiene que arrancar logind desde adentro de systemd y hacerlo funcionar en solitario: eso es elogind, y lo mantienen a pulmón proyectos como Gentoo, Void y Slackware. La libertad de no usar systemd no es gratuita: cuesta trabajo de ingeniería sostenido hecho silenciosa y generosamente por "terceros" para tapar el agujero que dejó otro diseño acoplado más de la "free"desktop.

La confesión (XDC 2018). No hace falta que se los acuse desde afuera de haber perdido el rumbo, porque el diagnóstico surgió desde el corazón mismo de la bestia. En el "XOrg Developers Conference" de 2018 (La Coruña), Daniel Stone -una de las figuras centrales de "free"desktop- dio una charla repasando la historia y el futuro del proyecto. Como lo resumió LWN (uno de los medios técnicos más serios del mundo Linux) al cubrir esa presentación: "free"desktop había empezado con foco en los escritorios libres y su interoperabilidad, pero perdió ese rumbo -y su rumbo en general- por el camino. Es decir: la propia organización, presentándose a sí misma ante los suyos, admitió haberse desviado de aquello para lo que... supuestamente... había nacido. Cuando el que confiesa el extravío es el propio protagonista, sobran los dedos acusadores.

Wayland y el tic tac de un reloj que permanentemente desmiente. Wayland es un proyecto de la propia "free"desktop.org -se desarrolla bajo su paraguas y se aloja en su infraestructura- (¿no es raro esto?), presentado en 2012 como el "sucesor" de X11: otro acto ya no solo de transgresión, sino de gula y soberbia endémica. Y acá es en donde el tic tac los delata. Estamos en 2026, es decir, 14 años después del inicio de este insuceso "ad aeternum".
A un proyecto joven se le puede perdonar que "aún esté verde", pero a uno que lleva 14 años de "desarrollo" y todavía con ínfulas, me parece que no. Porque más o menos ese fue exactamente el tiempo que tenía XOrg cuando ya era una roca sólida sobre la que se paraba toda infraestructura seria "UNIX like". Wayland tuvo el mismo plazo, con el respaldo institucional, además, de "free"desktop (¡y con Red Hat detrás!), y todavía hoy y ya con un XOrg sin mantenimiento serio, va rezagado respecto a él en cosas fundamentales como accesibilidad, grabación de pantalla, restauración de sesión, utilizando parches de funcionamiento tosco y "momentáneos para toda la vida" para que las aplicaciones diseñadas para XOrg funcionen bajo este "protocolo". El dato que importa, entonces, no es que Wayland sea inmaduro, por más que este sí sea un dato excluyente y determinante: es que se lo empujó verde, otra vez, tal como se hizo con otros productos, desde el primer día como el reemplazo inevitable, con todo el peso de la organización que decía ser un "foro neutral", y 14 años y un imperio de recursos después sigue sin cubrir lo que X11 ya cubría. La adopción se decretó; la madurez que la justificara nunca llegó.

XLibre y la purga (junio de 2025). Enrico Weigelt, uno de los desarrolladores más activos de XOrg, bifurcó a este proyecto en otro llamado XLibre, para seguir manteniendo y modernizando a X11, y esto fue tanto un hito a nivel general dentro de la órbita del software libre, como una victoria "personal" para muchos de nosotros, entre quienes me incluyo. Fue hermoso estar en Artix justo cuando surgió XLibre y ya poder empezar a usarlo de entrada. Yo estuve ahí.
Al día siguiente de anunciarlo, "free"desktop le baneó la cuenta de su GitLab a Enrico, le borró los repositorios, le cerró los tickets y junto con esto, hicieron que se perdiesen más de 140 merge requests. El baneo lo ejecutó, nada menos que el Comité de "Código de Conducta" de la organización, el cual hasta hoy no explicó públicamente qué hizo Weigelt para merecerlo. Del lado de GNOME, algunos desarrolladores lo trataron públicamente de "nazi" y "fascista".

Y acá tengo que ser escrupulosamente justo, porque es la única forma de que esto valga.

Weigelt no me parece que sea ningún santo, y de hecho, yo no comparto algunas de sus posturas. Es, sin dudas y por más que me encante lo que significa XLibre en todo sentido, un personaje polémico. En 2021 tuvo un encontronazo sonado en la lista del kernel por difundir seudociencia antivacunas. Y ojo: que lo haya cruzado y reprendido públicamente Torvalds, por esto, me parece perfecto, pero no lo pongo como sentencia moral ni ética incuestionable, porque tampoco Torvalds es garantía demasiado confiable, más allá del kernel "per se" en donde sí es un líder que no se discute y un excelente director de proyecto. Tristemente, pienso que ninguna de nuestras figuras de mayor relevancia están exentas de poder atacarlos de manera crítica con munición pesada. Ni siquiera Stallman, por más que aquí se lo respete, y mucho.

XLibre, además, se proclama "libre de DEI" (Diversidad, Equidad e Inclusión), metiéndose en una guerra cultural que no es necesaria ni es la mía.
El mismo hombre que lo lidera es el que difunde seudociencia antivacunas en foros técnicos, mezcla su proyecto con retórica de guerra cultural, y es también el mismo que en su discurso público utiliza términos como "elementos tóxicos" y "buitres de Big Tech" con un tono que a mucha gente le puede sonar tanto a anticorporativismo, por un lado (Entropía sí suscribe fuertemente a esto) como a guerra cultural de derecha dura, no a meritocracia tecnológica descontaminada, que es como verdaderamente deberían manejarse estos proyectos: si sos bueno/a en lo que hacés, bienvenido, sin importar tu orientación sexual ni las cuestiones de género, nacionalidad, etc.
Cuando alguien pone "libre de DEI" en un README de un servidor gráfico -en donde claramente el comentario es un sapo de otro pozo y resta enormemente- no creo que lo esté poniendo como regla de arquitectura, sino como bandera, como inequívoca señal de pertenencia a un bando cultural por el cual ni siquiera tengo simpatía. No sé si ese es exactamente el enfoque de Weigelt, pero me hace ruido, a mí, que tampoco soy de opinión blanda ni de esquivar el bulto, como ves.

XLibre también empieza a tener críticas técnicas grandes que empiezan a parecer legítimas. De hecho, otra vez en Entropía se dio un intercambio interesante respecto al tema, de la mano de los compañeros "Leo" y Miguel González, quienes comentaron -recién- que hubo tremendo revuelo en Artix por problemas no solo técnicos con XLibre sino también graves y de conducta de uno de los mantenedores de XLibre -no sé quién-, y que Artix decidió erradicar a XLibre de sus repositorios y sus ISOs.
 
No estoy santificando a nadie, como claramente podés ver; digo exactamente esto y ni un ápice más. Pero justamente por eso el caso es tan claro: no importa lo "impresentable" que a uno le pueda llegar a resultar una persona. Una cosa es discutir el mérito de un fork, o repudiar las ideas de quien lo hace, y otra muy distinta es que el "foro neutral" -a través de su comité "de conducta", sin causa pública- borre del mapa al que se atreve a mantener vivo lo que ellos decidieron enterrar unilateralmente. Porque acá está la contradicción que los desenmascara: a ese X11 supuestamente muerto lo siguen manteniendo hasta el día de hoy. ¿No era reemplazable a corto plazo? ¿No era que el futuro era Wayland? ¿Qué futuro, de qué realidad paralela, o de qué realidad "para lelos"?

La estocada, 10 días atrás (20 de agosto de 2026). Y acá llegamos al presente, con un episodio que se puede leer quizás de varias maneras, así que haré esto: yo te lo cuento entero y vos elegís lo que más te interese.

Salió el XOrg Server 26.1.0 Release Candidate (acabo de enterarme, yo de esto no sabía nada, y agradezco pertenecer a un espacio como el de Entropía, en el cual cualquier compañero, en cualquier momento, puede arrimarte una información importante: en este caso los laureles se los lleva Matías Gastón Santiago por arrimar al grupo de Telegram un artículo hablando de esto, cosa que celebro).
Salió la última actualización mayor de X11, entonces, como te venía contando, siendo anunciada como una de las limpiezas más agresivas en 35 años del X Window System.
¿Qué hace, concretamente? Extirpa a XWayland del árbol de XOrg y lo migra hacia un proyecto separado, siendo 1 solo merge request el que tocó decenas de archivos y borró decenas de miles de líneas de código.

Para entender el gesto hay que recordar la secuencia más o menos entera.
XOrg fue declarado "abandonado" por su propio project owner, Adam Jackson -de, no podía ser otro lugar que, Red Hat-. Durante los años de total, irresponsable y vergonzoso abandono, lo único que se mantenía vivo y activo dentro del árbol de XOrg era, justamente, XWayland: la única pieza que le sirve y le es funcional a Wayland. ¿No es esto, también, extremadamente raro?
Ahora, esa pieza se va a un repositorio propio, cuidado y con futuro, y a XOrg le queda el resto, la "contención en modo mantenimiento", sin desarrollo arquitectónico nuevo, solo con mínimos y estrictamente necesarios parches de seguridad. La justificación oficial es algo así como "tiene sentido, dado hacia dónde va (mejor dicho, "logramos forzar a que vaya") el ecosistema; la mayoría de las distros ya utilizan a Wayland -nunca mejor dicho- "por defecto". Porque Wayland sigue siendo un defecto.

Se podría decir que parte de esa limpieza es "higiene legítima", albergándose código desde hace más de 20 años, lo cual, por sí solo, no justificaría su remoción, pero démosle un mínimo de crédito para no pensar mal siempre. Además, modernizar no es, precisamente, un crimen. De acuerdo. Concedido.
Pero en cuanto dirigís la vista hacia quién sostiene la pala y hacia dónde cava, ves que son los mismos que declararon a XOrg abandonado y a Wayland como "el futuro". Los mismos que durante años solo cuidaron la parte pro-Wayland. Y la aceleración de todo esto llega justo después de aparecer un fork dispuesto a mantener a X11 con vida. No hace falta discutir si cada línea borrada estaba bien borrada: alcanza con mirar en la misma dirección que la intención que la tiñe, y quién la eligió.

Quién paga esta joda colosal. Spoiler: no es "free"desktop, el impune tacaño abusador de siempre y el origen de todos estos males.
Como recordó "The Register" -que no es precisamente un panfleto, ¿verdad?-, "free"desktop no escribió a XOrg. Lo heredó, así como el hijo vago e inútil de un multimillonario hereda todo su patrimonio solo por ser "hijo de". Y el patrocinador principal del mantenimiento de una enorme cantidad de ese código es Red Hat, subsidiaria de IBM desde 2018, la misma empresa de la que emergió el autor de systemd. La organización que hospeda a systemd, que define el namespace del que cuelga la dependencia moderna, que empuja a Wayland obscena e incansablemente, que baneó al que resistió y que ahora parece estar empezando a desmantelar a XOrg, siempre sin dar explicaciones, está financiada y poblada, en su núcleo, por la misma corporación.

Ese es el prontuario. Lo dejo acá, con las fechas y las fuentes sobre la mesa.

Y ahora sí, después de los hechos, me permito una sola reflexión, porque creo que me gané ese derecho, leyendo honestamente y denunciando más de una vez a todas estas cosas.

Hay una enorme diferencia entre una organización que arbitra y una que conduce, entre ser juez y ser parte. Un árbitro serio se basa en reglas parejas y deja hacer, y cuando se equivoca y hay dudas de su accionar, siempre se puede ir a consultar su historial y ver si se equivocó, también, de manera pareja. Lo que muestran estos hechos, uno tras otro, no es a un árbitro que a veces erra parejo, sino a una constante: siempre el mismo escritorio favorecido, el mismo init alabado, el mismo servidor gráfico empujado con vehemencia y sin escrúpulos, la misma empresa detrás. Y del otro lado, siempre lo mismo, también: el bastión abandonado, lo fácilmente auditable desmantelado, el que resiste, descartado sin miramientos. 26 años son demasiado tiempo como para que todo caiga siempre en el mismo lado, solamente por cuestión de puro azar: cuando la moneda sale "cara" 26 veces seguidas, la explicación honesta no es la suerte, es mucho más fácil y directa: la moneda es trucha, y el dueño de la moneda es corrupto y responsable de eso. Y debe pagar proporcionalmente, según el daño causado.

Por eso, cuando escribo "free"desktop -con las comillas puestas como pinzas, como al intentar asir algo en avanzado estado de descomposición-, no es un exabrupto ni es "joda": es la acción a la que me llevaron los propios hechos. Miralos vos y sacá la tuya.

FUENTES CONSULTADAS:

https://en.wikipedia.org/wiki/Freedesktop
https://wiki.ubuntu.com/Halsectomy
https://en.wikipedia.org/wiki/PulseAudio
https://en.wikipedia.org/wiki/Lennart_Poettering
https://lkml.iu.edu/hypermail/linux/kernel/1210.0/03783.html
https://u1f383.github.io/linux/2025/05/25/dbus-and-polkit-introduction.html
https://alien.slackbook.org/blog/replacing-consolekit2-with-elogind-first-steps
https://lwn.net/Articles/767258/
https://www.bigiron.cc/guides/wayland-vs-x11-in-2026-what-still-doesnt-work-on-wayland
https://commandlinux.com/statistics/wayland-vs-xorg-adoption-trends/
https://lists.x.org/archives/xorg-devel/2025-June/059396.html
https://www.theregister.com/2025/06/10/xlibre_new_xorg_fork/
https://www.webpronews.com/xlibre-promises-to-revitalize-x11/
https://lists.x.org/archives/xorg-announce/2026-August/003741.html
https://www.linuxcompatible.org/story/xorg-server-2610-release-candidate-drops-xwayland-kills-autoconf-and-strips-legacy-code
https://www.theregister.com/2021/09/22/xorg_server_21_1_0/

Read More

LVM: la gran mentira corporativa del almacenamiento (o por qué tus medios de almacenamiento no son piezas de Lego)

LVM: la gran mentira corporativa del almacenamiento (o por qué tus medios de almacenamiento no son piezas de Lego).

En Entropía binaria siempre defendimos a rajatabla la filosofía KISS (Keep It Simple, Stupid) y la soberanía sobre nuestros sistemas. Creemos en el software que hace una sola cosa y que la hace bien, y en mantener el control absoluto sobre los fierros. Pero de vez en cuando, la industria nos quiere vender espejitos de colores, empaquetando complejidad innecesaria bajo la promesa de la "comodidad". Hoy vamos a hablar de una de las peores basuras corporativas que se han estandarizado en el mundo Linux: el Logical Volume Manager, o LVM.

Te lo venden en todos los manuales y cursos genéricos como la solución definitiva. Te dicen que con LVM administrar discos es como jugar con piezas de Lego: podés poner y sacar unidades en caliente, expandir el espacio mágicamente y ser feliz.
Lo piden en "LinkedIn" y muchas veces puede llegar a ser bueno incluirlo en tu CV, solo para agarrar ese laburo.
Pero es una profunda y absoluta mentira.

El ADN de LVM.

Al código original de LVM lo escribió un alemán llamado Heinz Mauelshagen en 1998. El tipo trabajaba para una empresa llamada Sistina Software. ¿Y de dónde sacó la inspiración? Copió el diseño del administrador de volúmenes de HP-UX (el pesado UNIX propietario de Hewlett-Packard), que a su vez estaba basado en el sistema de Veritas. Desde su ADN, es tecnología pensada para armarios llenos de discos en datacenters de los años 90.
Como a Red Hat no solo produce este tipo de tecnologías basura sino que también le interesa adquirirlas cuando no las pueden crear en casa, la necesitaban para vender soporte caro a los bancos (que tenían servidores de base de datos gigantes), y en 2003 terminan comprando Sistina Software. A partir de ahí, Red Hat adoptó a LVM como su hijo pródigo, lo estandarizó (lo metieron por defecto en los instaladores de RHEL y Fedora) y financiaron el desarrollo de LVM2. Por eso, hoy en día, LVM es sinónimo del ecosistema Red Hat/SUSE y su filosofía de "venderte la cura para la enfermedad de complejidad que ellos mismos te encajaron de prepo", solo porque a ellos les sirve, no a vos, como siempre.

Mi experiencia en el barro: preso en mi propio sistema.

Hablo desde la experiencia cruda, porque cometí el error de probarlo en mi instalación diaria hace tiempo, cuando todavía usaba openSUSE, que lo ofrece en su instalador como "una opción más a considerar". El resultado fue catastrófico; quedé más preso y atado de manos que si hubiera comprado un producto de Apple. No podía zafar de ninguna manera de ese ecosistema sórdido.

El mito del "Lego" se me desmoronó en la cara el día que necesité desconectar físicamente un disco duro secundario. Era una unidad que solo contenía datos intrascendentes, archivos sueltos. Nada del sistema operativo estaba ahí. Tiré del cable SATA y, al encender la máquina, se me jodió (sí, no hay otra palabra posible, creeme) todo el sistema LVM entero. El núcleo entró en pánico y la máquina se negó a arrancar.
¿Por qué? Porque para esta tecnología de mierda (no hay otra palabra posible), vos no tenés discos independientes. Tenés una "bolsa negra", una volqueta con tapa. Si le sacás un bloque a esa bolsa, aunque sea de datos inútiles, el gestor asume que toda la estructura está corrupta. No opera en caliente un carajo; si no le avisás por terminal con comandos rebuscados que vas a retirar un volumen, te destruye el acceso al resto.

Y ni se te ocurra intentar formatear una de esas particiones lógicas por tu cuenta. Al hacerlo, le cambiás el UUID a la partición. La capa de LVM pierde el rastro, el fstab enloquece y, de nuevo, te cargás todo el arranque del sistema. Es una trampa mortal diseñada para alejarte del control real de tu máquina.
Humo corporativo: ¿quién usa realmente esto?
Nos repiten que es un "estándar de la industria". Pero hagámonos una pregunta seria: ¿Google, Netflix, Spotify o Anthropic usan LVM en sus servidores de producción masiva?
La respuesta es un rotundo "no".

Esos gigantes tecnológicos no pierden el tiempo con un administrador redimensionando volúmenes lógicos a las tres de la mañana. Operan con sistemas de archivos distribuidos y tratan a los servidores como tristemente se trata al ganado. Si un disco se llena o falla, el nodo se descarta, el tráfico se redirige y se levanta una máquina nueva. LVM ahí es puro ruido, una capa de abstracción inútil que solo agrega puntos de fallo.
LVM es, en esencia, tecnología heredada para infraestructuras corporativas monolíticas y dinosaurios informáticos. Está pensado para ese viejo servidor Red Hat en el sótano de un banco que corre una base de datos gigante que no se puede apagar nunca, o para tapar la pésima planificación de hardware de un administrador que necesita meter tres discos nuevos a un NAS departamental sin cortar el servicio. Para tu PC de escritorio, para tu notebook o para un servidor web limpio, es un estorbo. Es el ejemplo perfecto de una NTI (Nueva Tecnología Innecesaria).

Conociendo al enemigo: cómo funciona la trampa.

Yo fui librero durante 15 años. Llegué a odiar a autores como Osho y Paulo Coelho, y a muchos otros que ni siquiera operaban en ese nivel, lucrando con las miserias de la gente de a pie. Una vez, una clienta me dijo "si no lo leíste no podés criticarlo solo por la "pinta" o por las contratapas de sus libros". Más allá de que ese es un error bastante importante, porque vos podés informarte sobre esdta clase de fantasma literario por artículos y charlas que dan escritores de verdad, leí, muy a mi pesar y finalmente "El alquimista". ¿Te imaginás lo que pasó cuando la clienta volvió?

Para odiar algo con fundamentos técnicos, primero hay que entender cómo funciona.
El problema central de LVM es que destruye la relación directa entre el sistema operativo y el metal, inyectando tres pesadas capas de abstracción.

Vamos a desarmar esta arquitectura "de arriba hacia abajo".

1. PV (Physical Volume - Volumen físico).

Esta es la capa base, el metal real. Un PV puede ser un disco duro entero (/dev/sdb) o una partición de hardware clásica (/dev/sda2). En un sistema limpio, acá es en donde formateás y guardás tus datos. Pero en LVM, al hardware se lo "marca" y se lo vacía de identidad para entregárselo al gestor. El disco deja de ser un disco para convertirse en un simple ladrillo ciego.

2. VG (Volume Group - Grupo de volumen).

Acá es en donde ocurre el desastre lógico. LVM agarra todos esos "ladrillos" (los PVs) y los mete adentro de una gran "caja de fierro", fusionándolos. Este es el VG. Si metiste un disco de 500GB y otro de 1TB, el VG le dice al sistema: "hola, soy un gran tanque de 1.5TB".
El problema mortal reside en que los datos se esparcen por este tanque de forma abstracta. Por eso, cuando yo saqué mi disco de datos en openSUSE, el VG sintió que le habían arrancado un pedazo de su propia carne y bloqueó toda la estructura.

3. LV (Logical Volume - Volumen lógico).

Como el sistema operativo no puede instalarse en una "volqueta", LVM tiene que crear particiones virtuales para engañarlo. Esos son los LVs. Dentro de tu gran Grupo de Volumen, vos recortás pedazos de espacio virtual y les ponés nombre: un LV para la raíz (/), un LV para la swap, otro para el /home.
A los ojos de tu sistema Linux, estos LVs parecen particiones reales y recién a ellos se les da un formato (ext4, xfs). Pero es una ilusión; por debajo, están fragmentados y dependientes de esa gran "bolsa frágil" que es el VG.

Conclusión para administradores de verdad.

La soberanía digital empieza por entender exactamente dónde están guardados nuestros bits. Cada capa de abstracción que metemos entre el software y el hardware es un lugar oscuro donde los problemas se esconden y se multiplican.
Si querés un sistema robusto, rápido y del que tengas el control absoluto, mantenete alejado de LVM. Usá lsblk para mirar el mapa, cfdisk para esculpir el metal con precisión, dale un formato directo y montalo limpio en tu fstab mediante su UUID. Esa es la verdadera forma UNIX. Todo lo demás, es humo corporativo. O, por qué no, mierda corporativa.

Apéndice: cómo RedHat justifica esta basura.

Para poder comprender cómo esta corporación (la cual es la sombra corta de IBM) justifica esta tecnología excrementicia y por qué la implementan en el mundo real, tenés que posicionarte mentalmente en el sótano de un banco o en el datacenter de una multinacional tradicional en donde no importa la filosofía KISS, los principios POSIX, la elegancia del código ni la soberanía digital; ahí lo único que importa es que el servidor todopoderoso no se apague nunca, porque si el sistema de tarjetas de crédito se llega a caer tan solo por 5 minutos, las cabezas seguro empezarán a rodar (porque eso sí les importa, que el capitalismo de consumismo funcione "24-7" y que lo demás reviente tranquilamente porque "eso no es problema de ellos").
Red Hat implementa LVM (pienso que casi exclusivamente) para resolver 3 problemas corporativos de infraestructura pesada que el en el mundo de las particiones físicas no se puede solucionar a menos que se hable de "algunos reinicios de por medio".

Estos son 3 escenarios reales que vi que tienen validez, al menos para comprender este tema.

Escenario 1. Retiro de unidades de almacenamiento a punto de "sonar como arpa vieja": el comando "pvmove".

Imaginemos que en el 5° subsuelo de un Banco existe un servidor que tiene un "grupo de volúmenes" (la "bolsa negra" o "volqueta" de la que te hablé antes) conformado por cuatro "discos duros de gran tamaño". De repente, el sistema de monitoreo avisa que el disco número 3 está reportando errores mecánicos y dando avisos determinantes de que va a morir en cualquier momento.
Si fuera "metal puro", el administrador tendría que apagar el servidor, sacar el disco, poner uno nuevo, colocar el disco dañado en otro equipo, arrancar a ese equipo con un "LiveCD", extraer los datos, copiárselos a un servidor en marcha, en caliente y quién sabe haciendo no se sabe qué peripecias - porque el consumismo debe continuar vivo - y finalmente rezar, aunque sea ateo, para que no se hayan perdido datos ni hayan quedado configuraciones corruptas.
Con "LVM", el administrador conecta un disco nuevo al rack en caliente. Lo mete a la volqueta usando vgextend. Luego, ejecuta el comando mágico de esta tecnología: pvmove. Este comando agarra todos los bloques de datos del disco que está fallando y los muda físicamente al disco nuevo, en segundo plano, mientras el servidor y la base de datos siguen atendiendo clientes sin enterarse de nada. Cuando termina la mudanza, el administrador saca el disco roto de la volqueta con "vgreduce" y lo tira a la basura; todo dentro de un tiempo de inactividad récord en comparación a lo que sucedería sin LVM.

Escenario 2. El precongelamiento a la velocidad del rayo (los respaldos tipo "snapshot").

Esta es una gran carta bajo la manga para poder "vender" LVM a grandes empresas sin que siquiera sepan de qué se trata. En una base de datos de 10 Terabytes en la cual se están escribiendo transacciones todo el tiempo, no es posible "simplemente copiar los archivos a un disco externo para hacer un respaldo": como los datos cambian mientras se copian, el respaldo queda corrupto.
Acá LVM se usa a modo de "viveza criolla": el administrador ejecuta "lvcreate -s" y toma un snapshot (una instantánea). Esto no copia los 10 Terabytes en el acto a "velocidad imposible", sino que "congela" el estado de los bloques en ese milisegundo exacto. El administrador hace su copia de seguridad leyendo ese "fotograma congelado", mientras los de la "película" en la base de datos, siguen en movimiento.

Escenario 3. El pánico del espacio agotado: "lvextend".

Son las 4 y media de la tarde, el servidor de archivos principal de la empresa llega al 100% de capacidad y nadie puede guardar un documento más. Con particiones tradicionales, habría que migrar los datos a un disco más grande en la madrugada, tal como ya hemos hablado en el escenario 1: apagar el servidor, sacar el disco, poner uno nuevo, colocar el disco dañado en otro equipo...
Con "LVM", el administrador va corriendo al rack, le enchufa tres discos nuevos y los configura para que empiecen a formar parte de la volqueta, ejecutando "lvextend" para hacerle saber al "volumen lógico" que ahora es más grande, y luego utiliza una herramienta como "resize2fs" para estirar el sistema de archivos (el cual posiblemente no sea el legendario ext4 sino alguno estilo "NTI" como btrfs o xfs). En menos de 30 minutos, quizás, "el disco C del "Güíndor Server 2003 con Áti Dirétory", pasa de tener 10 Terabytes de capacidad a tener 26, mientras los empleados del Banco siguen dando préstamos y VISA sigue permitiendo que las personas retiren TVs de 40 pulgadas en cómodas cuotas expedidas en un supermercado barrial.

Quise explicar todo esto para terminar siendo justo con la herramienta pero implacable con su filosofía y advertirte fuertemente en cuanto a su uso. LVM, pese a "sonar interesante", es una herramienta de contingencia corporativa que perpetúa el descontrol y el desorden: es un parche complejo diseñado para que un sysadmin no tenga que apagar un servidor monolítico (así se le llama a los servidores poseedores de la tríada interfaz, lógica de negocio y base de datos) ni se detenga nunca a prever este tipo de problemática de antemano.
Por eso me arruinó la instalación en mi PC y por eso es una porquería para el 99% de los casos de uso normales. No está diseñado para un usuario normal ni para un administrador de servidores que planifica bien su almacenamiento y quiere tener soberanía total sobre sus discos; está diseñado para la desesperación empresarial de no poder apagar un equipo y quizás hasta para ahorrar costos en planificación y mantenimiento.
La regla de oro a esta escala es que el hardware se asume como descartable. Con LVM en servidores realmente imponentes, como podrían ser los de Google para Gemini, Netflix, Spotify, Anthropic, DeepSeek, etc, tendrías que estar manejando más de "100.000 discos duros". Cada día fallarían entre 0 y 50. Con LVM, tendrías que tener a cargo un verdadero ejército de administradores tipeando comandos de rescate las 24 horas. Para evitar eso, a esta escala se usa el Almacenamiento Definido por Software (SDS) y los Sistemas de Archivos Distribuidos, no este "barro en la joya" de LVM.
Red Hat te encaja LVM por defecto para el servidor monolítico de una PyME o de una oficina gubernamental. Pero cuando a Red Hat la contrata una empresa de telecomunicaciones para armar un datacenter realmente grande o un clúster con miles de nodos, Red Hat tampoco usa LVM.
Para la escala masiva, Red Hat compró otra empresa y te vende Ceph (Red Hat Ceph Storage), el cual es un sistema de almacenamiento distribuido por red que lee directamente el disco físico desnudo (BlueStore) saltándose a LVM por completo porque agrega latencia y puntos de falla innecesarios.

¿Viste ahora cómo es la cosa? ¡Saludos!

Read More

Nuevas Tecnologías Innecesarias: un análisis crítico del progresismo tecnológico en el ecosistema del software libre.

Logotipo oficial de "NTI".

Nuevas Tecnologías Innecesarias: un análisis crítico del progresismo tecnológico en el ecosistema del software libre.

Introducción.

Dentro del ecosistema del software libre existe una tensión fundamental entre dos fuerzas aparentemente contradictorias: la innovación técnica y la estabilidad filosófica.
Esta tensión no es nueva, pero ha alcanzado un punto crítico en la última década con la proliferación de tecnologías que, bajo el pretexto de modernización y mejora, están fragmentando al ecosistema, concentrando poder en corporaciones, y alejándonos de los principios fundacionales del software libre.

Este documento introduce y analiza el concepto de "NTI" (Nuevas Tecnologías Innecesarias): una clasificación tripartita de tecnologías cuya existencia debería ser insignificante y opcional, que no deberían existir todavía, o que no deberían ser impuestas de la manera en la cual lo están haciendo las grandes corporaciones. El concepto NTI no es una crítica reaccionaria contra el necesario y justificado cambio en el momento realmente oportuno, sino un análisis riguroso de cómo el poder corporativo está utilizando a la seudo innovación como caballo de Troya para recuperar el control que el software libre le está quitando.

Taxonomía de las NTI.

Las NTI se dividen en tres categorías distintas, cada una con características propias y diferentes niveles de peligrosidad para el ecosistema.

1. Tecnologías inútiles.

Las tecnologías inútiles son aquéllas que no resuelven ningún problema real. Son soluciones en busca de problemas, productos del consumismo tecnológico que intentan crear necesidades en donde nunca habían existido.

Características:

• no mejoran ningún proceso existente,
• su única función es generar ventas,
• suelen fracasar comercialmente,
• no representan peligro real para el ecosistema.

Ejemplos ilustrativos:

• transformadores de "palitos chinos" en cuchara,
• cucuruchos motorizados para helado,
• gomas "limpiadoras" para teclados que limpian peor que un pincel y una buena soplada,
• sistemas de sonido automotriz que reproducen ruidos falsos de motor deportivo.

Estas tecnologías pueden llegar a transformarse en indeseables porque representan un desperdicio de recursos, pero, en sí, no representan un peligro. Son síntomas del consumismo, no amenazas al ecosistema del software libre.

2. Tecnologías innecesarias.

Las tecnologías innecesarias son técnicamente funcionales y en ocasiones incluso están bien implementadas, pero poseen caácter redundante. Son soluciones que duplican funcionalidades existentes sin ofrecer ventajas significativas respecto al maduro y preexistente. Representan a la fragmentación del ecosistema por capricho corporativo.

Características:

• duplican tecnologías existentes y maduras,
• fragmentan esfuerzos de desarrollo,
• confunden a usuarios y desarrolladores,
• generalmente son abandonadas por sus creadores,
• crean dependencias temporales problemáticas.

Caso de estudio: Canonical y su compulsión por reinventar la rueda.

Canonical, la empresa detrás de Ubuntu, es el ejemplo paradigmático de este fenómeno. Su historial incluye:

MIR (2013-2017): un servidor gráfico creado cuando ya existían X11 (maduro y estable) y Wayland (en esa época en desarrollo y con amplio soporte comunitario, aunque era inmaduro ayer y sigue siéndolo hoy). MIR no ofrecía ventajas técnicas significativas, solo aislaba a Ubuntu del resto del ecosistema. Fue abandonado en 2017 cuando Canonical adoptó Wayland.

Unity (2010-2017): un entorno de escritorio creado cuando ya existían XFCE, KDE, GNOME, LXDE, y docenas de otros. Unity no era técnicamente malo, pero era innecesario. 7 años de desarrollo fueron abandonados para volver a Gnome, escritorio casi indistinguible respecto a Unity y antecesor del mismo.

Upstart (2006-2014): un sistema de inicio (init) creado cuando "sysvinit" funcionaba - y sigue funcionando - perfectamente. La decisión posterior de Canonical fue reemplazarlo por la suite "systemd", demostrando que toda esa seudo innovación, además de ser inoportuna e innecesaria, fue vana.

Snap (2014-presente): un sistema de paquetería que duplica la funcionalidad de .deb (el formato nativo de Debian y de otros formatos universales como Appimage. 

Snap es:

• más pesado que los paquetes nativos,
• más lento en arranque y ejecución,
• menos eficiente en uso de almacenamiento (cada paquete incluye todas sus dependencias),
• un claro intento de centralizar la distribución de software en servidores de Canonical.

El patrón es claro: Canonical crea tecnologías no porque la comunidad las necesite, sino porque quiere diferenciarse, controlar su propio "stack", y eventualmente, monetizar. Cuando la tecnología falla en ganar tracción, la abandonan, dejando a los "early adopters" con código muerto y deuda técnica.

Análisis del impacto.

Las tecnologías innecesarias tienen costos concretos:

• fragmentación de esfuerzos: desarrolladores trabajando en soluciones paralelas en lugar de mejorar las existentes;
• confusión de usuarios: decisiones técnicas complicadas sin beneficios claros;
• deuda técnica: código que eventualmente será abandonado pero que mientras tanto genera dependencias y desperdicia recursos;
• erosión de confianza: la comunidad deja de confiar en las innovaciones corporativas.

3. Tecnologías invasivas.

Las tecnologías invasivas son las más peligrosas. No son simplemente inútiles o redundantes: son tecnologías que se imponen mediante poder corporativo, que saturan el mercado, que eliminan alternativas, y que concentran control en manos de corporaciones.

Características:

• son respaldadas por corporaciones de desbordantes recursos,
• se convierten en "estándares de facto", es decir, no por mérito técnico sino por saturación, como el IBM-PC en su momento,
• crean ecosistemas de dependencias,
• eliminan o marginan alternativas técnicamente viables,
• centralizan el poder de decisión.

Contexto histórico: IBM y la imposición tecnológica.

Para entender a las tecnologías invasivas actuales, es necesario examinar el modus operandi histórico de IBM, que hoy controla a Red Hat, y junto a Microsoft y por extensión, a gran parte del ecosistema "enterprise" de Linux.

Caso histórico 1: la muerte de CP/M y el nacimiento del monopolio Microsoft.

En los años 70, Gary Kildall creó CP/M, un sistema operativo revolucionario con kernel autoadaptable. En una época en donde cada ordenador requería su propio sistema operativo específico, CP/M podía funcionar sobre diferente hardware con configuración mínima. Era técnicamente superior a cualquier alternativa, e incluso puedo dar fe de ello, ya que lo corrí en mi Commodore 64, en su momento.

Cuando IBM decidió lanzar su PC personal, tuvo dos opciones:

• CP/M de Gary Kildall, quien ofrecía licenciar su sistema cobrando regalías por cada PC vendida.
• D.O.S. de Microsoft, quien ofrecía vender el sistema una sola vez, sin regalías posteriores.

IBM eligió la opción más conveniente para sí misma, no la mejor técnicamente.
Pero la elección no fue neutral.
IBM comenzó a vender PCs con ambos sistemas bajo un esquema de competencia desleal, por lo cual los PCs con CP/M eran significativamente más caros por razones obvias: D.O.S. era mucho más barato para IBM.
Microsoft comenzó una guerra de "desgaste por rozamiento contínuo y, curiosamente, también haciendo competencia desleal", ofreciendo descuentos a desarrolladores que crearan software exclusivo para D.O.S.
Algunos programas verificaban activamente la presencia de CP/M y se negaban a ejecutarse, incluso cuando eran técnicamente compatibles.
Resultado: Digital Research (la empresa de Kildall) quebró. CP/M desapareció. D.O.S. se convirtió en estándar. "Pequeñosoft" se convirtió en "Grandesoft". Y nada de esto fue por superioridad técnica, sino por poder de mercado.
IBM no solo eligió la opción más conveniente para sus necesidades: saboteó activamente a la alternativa superior, y luego se hizo la desentendida, como si tampoco hubiera sabido lo que Microsoft estaba haciendo.

Caso histórico 2: la extinción de la diversidad en ordenadores personales.

A principios de los '80, el mercado de ordenadores personales era vibrante y diverso: Commodore 64, Sinclair Spectrum, Atari, Adam y decenas de marcas más. Cada uno con sus características, comunidades y desarrolladores.

Técnicamente, muchos eran superiores al IBM PC.

• Commodore 64: sonido multicanal cuando IBM PC era monoaural. Miles de colores cuando IBM PC era monocromático. Arquitectura elegante y eficiente.
• Sinclair spectrum: extremadamente popular, excelente relación precio-prestaciones.
• Atari: gráficos y sonido superiores. excelente para juegos, al igual que la Commodore 64.

El IBM PC tenía dos ventajas: velocidad (procesador de 10 MHz versus 1 MHz de la competencia) y memoria. Pero... ¿para hacer qué? No había software. Las interfaces eran toscas. Era rápido para hacer nada.
IBM usó su poder económico y político para saturar el mercado. Produjo y produjo hasta inundar todo con IBM PCs. Las otras empresas no podían competir contra el poder financiero de IBM, que podía permitirse pérdidas masivas mientras eliminaba competidores.
Resultado: todas las alternativas quebraron. Hoy usamos "arquitectura IBM PC" no porque sea la mejor, sino porque IBM tuvo - y tiene - el poder de eliminar a todas las alternativas para quedar en el lugar de la Reina.

La lección histórica.

Estos casos ilustran el patrón que se repite hoy con "Red Hat-IBM" en el ecosistema Linux:

1. una corporación con recursos masivos identifica un ecosistema;
2. crea o adopta tecnologías que puede controlar;
3. utiliza su poder para imponerlas como "estándares";
4. margina o elimina alternativas técnicamente viables, generalmente bajo un irresponsable discurso futurista;
5. controla al ecosistema resultante.

Caso contemporáneo: Red Hat, IBM y el control del ecosistema "Linux enterprise".

Red Hat fue adquirida por IBM en 2019 por 34 mil millones de dólares. No fue una compra por amor al software libre. Fue una compra para controlar infraestructura crítica y dictar estándares en el ecosistema "enterprise".
Red Hat no solo crea tecnologías: crea ecosistemas de dependencias donde todo depende de uun espiral centrípeto y Red Hat controla el epicentro.

Tecnología invasiva 1: Gnome.

Red Hat es el mayor contribuyente corporativo de Gnome, el entorno de escritorio predeterminado de Fedora, CentOS Stream, y Red Hat enterprise Linux, todos sistemas basados en Linux y dependientes de esta empresa de manera directa.

Problemas técnicos de  Gnome.

• Pesado: consume significativamente más recursos que sus alternativas directas (XFCE, Cinnamon o incluso Plasma), siendo mucho menos funcional que cualquiera de estos.
• Paradigma contraintuitivo: no posee barra de tareas tradicional. Las ventanas minimizadas desaparecen visualmente sin indicación clara.
• Dependencia forzada de Systemd: Gnome no funciona sin Systemd, creando un acoplamiento técnico innecesario y apuntando directamente a un esquema de trabajo anti escalable (no POSIX).

Problema de seguridad en Gnome.

El paradigma de ventanas minimizadas de Gnome crea un riesgo de seguridad concreto: cuando minimizás una aplicación, desaparece de la vista sin indicación visual clara de que sigue ejecutándose. Un usuario puede minimizar un navegador con sesiones activas (email, redes sociales, almacenamiento en la nube), creer que cerró todo, y dejar la máquina desatendida. Cualquiera que acceda a esa máquina tiene acceso completo a todas esas sesiones.
Esto es contraintuitivo y peligroso.

Problema de adoctrinamiento en Gnome.

Gnome enseña un paradigma de interacción completamente diferente al de cualquier otro escritorio o entorno gráfico. Un niño que crece usando este escritorio aprende una forma de trabajar que no es transferible a ningún otro entorno. Esto es adoctrinamiento tecnológico: creación de dependencia de un paradigma específico en lugar de enseñanza de principios transferibles. De nuevo se demuestra una clara intencionalidas no escalable, pero esta vez no solo a nivel técnico.

Tecnología invasiva 2: casos "Pulseaudio y Pipewire".

Red Hat desarrolla tanto Pulseaudio como Pipewire. Ambos son sistemas de gestión del sonido en Linux, y hacen esencialmente lo mismo. ¿Por qué existen ambos?
Porque Red Hat puede decidir cuál impulsar y cuál desatender, y esto le da control sobre la dirección del ecosistema.
Pipewire fue creado específicamente para integrarse con Wayland, Flatpak y el ecosistema que Red Hat está construyendo, y para esto, PulseAudio es "legacy". La transición no se da a raíz de una superioridad técnica objetiva - lo cual sería lo razonable y deseable - , sino por decisión corporativa de hacia dónde mover el ecosistema: otra vez, hacia el epicentro de una espiral centrípeta.
Cuando una sola entidad controla múltiples implementaciones de las mismas funcionalidades, termina manipulando la percepción acerca de "cuál es mejor" simplemente invirtiendo más recursos en una que en otra y haciendo mayor alharaca en la defensa de la adopción de una por sobre la restante, generalmente con conceptos no abiertos a discusión, tales como "X es inmanejable e Y es escalable", "Y llegó para quedarse", "Y es el futuro", "Y es más moderno", "Y es más seguro"... Pero nunca "porque "Y" es mío y me sirve a mí".

Tecnología invasiva 3: Fedora Silverblue y las distribuciones inmutables.

"Silverblue" es una distribución Linux "inmutable": el sistema de archivos raíz es de solo lectura. Solo "/home" y "/tmp" son escribibles.
El argumento es "la seguridad": si el sistema es inmutable, es más difícil comprometerlo. 

Pero esto es falso: en un Linux tradicional, con los permisos correctamente configurados (chmod, chown, grupos, políticas de seguridad), lográs el mismo nivel de seguridad sin necesidad de caer en semejante despropósito. La inmutabilidad no agrega seguridad real, solo automatiza configuraciones de manera grotesca, que ya eran posibles de manera sencilla y por defecto. ¿Qué es Linux, sino un sistema en donde la gracia es, justamente, poder tener el control total de lo que el mismo hace y resuelve?
Pero las distros inmutables tienen una característica particular: se actualizan durante el reinicio, como Windows. Windows es inmutable, el concepto es de Microsoft. El sistema se actualiza mientras reinicia, no cuando el usuario decide hacerlo.
Esto viola un principio fundamental dentro del ecosistema Linux: el usuario controla cuándo y cómo se actualiza el sistema. El usuario tiene el control, no el sistema.
Las distros inmutables funcionan como Windows disfrazados de Linux: automatización forzada presentada como "innovación".

Tecnología invasiva 4: Sugar y el Plan Ceibal.

Sugar es un entorno de escritorio diseñado por la idea que tenían "ciertas mentes" sobre lo que eran las necesidades de niños muy pequeños frente a un ordenador. Fue creado para el proyecto "One Laptop Per Child" (OLPC) de Nicholas Negroponte.
El proyecto "OLPC" suena noble: proveer ordenadores baratos a niños en países en desarrollo. Pero la implementación fue desastrosa:

• ordenadores extremadamente limitados técnicamente (laptops "XO");
• sistema operativo Fedora (Red Hat);
• entorno de escritorio Sugar, completamente diferente a cualquier otro paradigma (lo mismo que sucede con Unity).

El problema del adoctrinamiento infantil.

Si se le da a un niño de un contexto de pobreza un ordenador que no sirve para nada con un entorno de escritorio que no se parece a nada más, ese niño no aprenderá informática. Aprenderá "Sugar". Y "Sugar" no le servirá para nada cuando se enfrente a un "ordenador real": porque ni el ordenador ni su entorno gráfico resolverán nada: ni bien, ni de manera universal.
Esto no es educación: es adoctrinamiento. Es condenar a ese niño a una dependencia tecnológica específica sin darle habilidades transferibles.
Plan Ceibal en Uruguay implementó exactamente esto: laptops XO con Fedora (un sistema operativo pesado y corporativo) y Sugar (una interfaz de uso sin "escalabilidad pedagógica") en todas las escuelas públicas. Un acuerdo entre el presidente Tabaré Vázquez, Nicholas Negroponte, y Miguel Brechner inyectó impunemente estas máquinas en el sistema educativo sin consideración real de si eran la mejor herramienta pedagógica.
El plan eventualmente fue, lerda, costosa y toscamente evolucionando y mejorando, pero el daño inicial ya estaba hecho: varias generaciones de niños uruguayos aprendieron un paradigma de interacción intransferible.

Tecnología invasiva 5: systemd.

Systemd es el ejemplo máximo de tecnología invasiva. Es un sistema init (el primer proceso que inicia en Linux) que ha reemplazado a Sysvinit (y a varios programas que constituyen aún hoy los eslabones de la cadena de arranque de varios sistemas operativos "edge") en la mayoría de las distribuciones principales.

Contexto técnico.

Un "init system" es el proceso número 1 en Linux. Sus funciones principales - a grandes rasgos y en términos generales - son:

1. ser el padre de todos los procesos en el sistema operativo,
2. disparar la activación de la swap,
3. iniciar a todos los servicios que necesite el sistema,
4. verificar el estado de cada proceso y gestionarlo correctamente, 
5. disparar el inicio del entorno gráfico, la red, el sonido.

Durante décadas, Linux usó Sysvinit: simple, probado, confiable. Filosofía UNIX pura: hacer una cosa y hacerla bien.

Systemd no debería ser considerado "un init", sino una "suite multifuncional reiteradora" ya que hace (y es) mucho más que "solo eso":

• init system,
• gestor de servicios,
• gestor de logs         (systemd-journald),
• gestor de sesiones     (systemd-logind),
• servidor de tiempo     (systemd-timesyncd),
• gestor de red          (systemd-networkd),
• gestor de nombres      (systemd-resolved),
• cargador de arranque   (systemd-boot),
• gestor de dispositivos (systemd-udevd),
• entre muchas otras funcionalidades.

Violación de la filosofía UNIX.

La filosofía UNIX, articulada por Ken Thompson y Dennis Ritchie, es clara: hacer una cosa y hacerla bien. Systemd hace 28 cosas. Esto no es filosofía UNIX, es filosofía Windows: monolitos digitales que intentan resolver tareas a granel y que poseen aún mayor cantidad de software que el necesario.

Problemas técnicos concretos de systemd.

1. Barroquismo y complejidad innecesarias: ¡más de 1 millón de de líneas de código solamente para hacer las mismas cosas que ya hacían otros programas! Cuanto más código, más programas funcionales y mejores quedan afuera, más "bugs" potenciales se presentan, más formas de fallar se generan, más tiempo, estrés, energías invierte la comunidad entera en algo que antes, cuando no existía, todo lo que eso ahora resuelve ya se resolvía, y mejor.

2. Mayor consumo de recursos: pruebas empíricas comparando Artix Linux (openrc) vs OpenSUSE (Systemd) vs Ubuntu (Systemd + Wayland), muestran consistentemente que openrc inicia menos procesos y consume menos RAM.

• XFCE:    Artix 80, OpenSUSE 90, Ubuntu 110.
• Gnome:   Artix 90, OpenSUSE 93, Ubuntu 100.
• i3wm:    Artix 42, OpenSUSE 64, Ubuntu  71.
• Openbox: Artix 62, OpenSUSE 67, Ubuntu  95.

3. Velocidad de arranque: systemd fue diseñado para paralelizar el arranque y bajo el discurso de "hacerlo más rápido (aún)". En la práctica, no es posible asegurar que systemd sea - en la enorme mayoría de los casos - más rápido en iniciar el sistema que openrc, por ejemplo, sino... mas bien todo lo contrario: generalmente es más lento. 

4. Inadecuado para hardware limitado: systemd es en primer lugar una suite: o lo es todo, o es nada. No hay punto medio. No hay - como ya había antes de Systemd y sigue habiendo post Systemd - un conjunto de programas intercambiables, elegibles, configurables por separado que realizaran todo lo que realiza Systemd. Además, consume recursos de hardware de manera criticable, resolviendo... ¡nada de lo que decían "venir" a solucionar! En hardware viejo o de baja potencia, esto es un problema: Sysvinit, Openrc, Runit funcionan perfectamente. No son una suite. No poseen millones de líneas de código.  Trabajan perfectamente a nivel POSIX, es decir, frente a cualquier programa escalable, no solamente frente a los programas incrustados en Systemd que Systemd espera que estén ahí "o sino crashea".

5. Acoplamiento forzado: cada vez más software requiere systemd como dependencia. Gnome requiere Systemd. Wayland requiere Systemd. Pipewire se integra con Systemd. Todo el ecosistema se tiene que adaptar y acoplar forzadamente a una pieza de software que nadie pidió y que divide a la comunidad, multiplicando las tensiones y aportando... nada. El "cuentito" era el "arranque en paralelo para mejorar la velocidad de inicio". Si no probaste sistemas con otro init (Void, Artix, etc.), probalos y comprobá cuál de los dos inicia más rápidamente.

6. Uso a nivel de laboratorio corporativo: Red Hat utiliza a Systemd para experimentar. Le agregó un cargador de arranque (systemd-boot), cuando, como ya se comentó antes, siempre hubo piezas de software intercambiables y elegibles por separado para realizar este proceso. Le agregó también una "BSOD", es decir, una "pantalla azul de la muerte" (sí, literal): un sistema de distinta naturaleza, con un ecosistema totalmente diferente a lo que realiza Microsoft, con una tomada de pelo a toda la comunidad: la pantalla azul que Windows muestra cuando falla. ¿Por qué? ¿No bastaba ya con haber mancillado decenas de aplicaciones, dividido a toda la comunidad y haber doblegado a la enorme mayoría doblegable de sistemas Linux a reverenciarse y trabajar para Systemd y Red Hat que incluso esto tuvieron que hacer? Agregar funcionalidades que no tienen justificación técnica, solo hace aumentar el código y los errores potenciales, y peor aún, transferir el poder a una corporación que vela por sus intereses antes que por los comunitarios, en un ecosistema 100% social.

La verdadera razón de systemd.

Systemd no se impuso por el normal devenir de un producto que fue siendo adoptado por uso, prueba y convencimiento de la gente, sino porque Red Hat tenía el poder de embutirlo a la fuerza y a velocidad de ráfaga. Igual que IBM.
Y no es de sorprender, ya que Red Hat es parte de IBM y ahora refuerza y reivindica sus individualistas y contumaces prácticas. Sus áreas de influencia, que siempre operaron a los ojos de todos, eran - y son - la cooptación y el empleo de desarrolladores muy capaces pero con con mucha visión personal y nulo compromiso social, filosófico, político e histórico por el ecosistema libre y "lo comunitario para la gente". También controló - y controla - a Fedora, a la vez que poseía - y posee - influencia en otras distribuciones (su campo de pruebas). Y con las dos anteriores "características", tuvo - y sigue teniendo - el "paño tendido" para poder seguir creando el ecosistema de dependencias. Solo falta que hagan fallar a propósito a Systemd para que podamos ver la BSOD mientras comemos "pop" sentados frente a la pantalla (azul).

Cuando Canonical inyectó sin problemas a Systemd en Ubuntu (comunidad acrítica que solo  busca "lo funcional" aceptando permanentemente lo que Canonical hace), cuando Debian adoptó Systemd (después de una votación controversial), cuando Arch Linux adoptó Systemd (misma situación que en Debian), no fue por superioridad técnica objetiva. fue porque el ecosistema entero se estaba moviendo en esa dirección, y la resistencia era - y es - cada vez más tenaz y costosa.

Esto es imposición por saturación: el mismo método que IBM utilizó con los "IBM-PC" en los años 80, utilizando un producto centralizado, controlado, monótono, corporativo y que no cumplía con las normas OSI, diezmando a la generación dorada de los 8 bits que sí competía naturalmente por lugares de excelencia ganados a pulso y ofrecía verdaderas herramientas de superación y diversión a niveles alucinantes a la gente de la época.

Alternativas viables a systemd.

Existen alternativas técnicamente superiores o equivalentes.

• Sysvinit: Slackware (SysV con "tintura BSD"), MX Linux, Linux From Scratch...
• RC: FreeBSD, NetBSD, OpenBSD...
• Openrc: Artix, Alpine, Gentoo...
• Runit: Void, DeVUAn, Damn Small Linux...

Y hay bastantes más, como Dinit y S6. Estas alternativas funcionan, y bien. Son más simples, más ligeras, más eficientes. Hay incluso distribuciones como Artix y DeVUAn que mantienen a varias de ellas a la vez. Pero están siendo marginadas por abuso de poder corporativo.

Consecuencias de las NTI: obsolescencia programada y consumismo tecnológico.

Las NTI no existen en el vacío. Son parte de un sistema económico más grande basado en crecimiento continuo, consumo acelerado y obsolescencia programada.

El día de la "sobrecapacidad de la Tierra".

Existe un concepto ambiental: el día del año en que la humanidad haya consumido todos los recursos que la tierra puede regenerar en un año. Luego de ese día, estaríamos operando en déficit ecológico. Este día llega cada año más temprano.
¿Por qué? Porque la industria ha priorizado el crecimiento al infinito sobre la eficiencia. ha priorizado aspectos visuales, "facilidad de uso" superficial, y obsolescencia planificada sobre eficiencia real y durabilidad. Al escribir esto, pienso en las ciudades de Japón y Estados Unidos, con un nivel de incrustación de cartelería e iluminación embutidos en lo arquitectónico hasta lo insoportable. Y todo esto, va a tener aún más sentido a medida que sigas leyendo.

Obsolescencia programada en hardware.

Una "laptop" del año 2010 puede estar en perfecto estado de hardware: procesador funcional, RAM funcional, unidad de almacenamiento disco funcional. Pero se vuelve "obsoleta", en gran parte porque el software moderno y la información manipulada cada vez requieren más recursos.
Pero... ¿realmente es un requerimiento válido el antedicho, o simplemente se volvió todo más pesado sin la debida justificación?
Esa misma laptop de 2010 con Artix linux, openrc y LXDE funcionará perfectamente. Será rápida, eficiente, completamente funcional para la mayoría de tareas. Pero la inducida y errada creencia popular indica que una máquina, "en realidad", necesita Windows 11, o Ubuntu con systemd, Gnome y Wayland, y que para eso "tenés que tener" una computadora nueva con 16 GB de RAM - o más - y procesador moderno.

Las NTI como motor de obsolescencia.

Systemd consume demasiados recursos más que Sysvinit. Gnome consume una enormidad más que XFCE. Wayland consume también más que XLibre/X11y Snap bastante más que cualquier paquete nativo.
Piénsese en esta reacción en cascada: cada una de estas tecnologías, individualmente, impacta moderadamente, pero sumada a las demás, empujan en conjunto a los requisitos mínimos del sistema hacia arriba, y eso es lo que termina desplazando finalmente al hardware funcional hacia la obsolescencia.
¿Quién se beneficia? Los fabricantes de hardware que venden componentes de hardware nuevos y también máquinas nuevas; Microsoft, que vende versiones de MS Office y de MS Windows más pesadas cada vez; Red Hat, que vende "soporte enterprise"; Canonical, que vende Ubuntu "Pro".
¿Quiénes pierden? Usuarios con hardware que no es moderno, países en desarrollo con menos recursos, el medio ambiente (más residuos electrónicos), y el principio de eficiencia que debería ser central en la ingeniería de software: KISS.

NTI versus YAGNI: aclaración de conceptos.

Existe un principio de diseño de software llamado YAGNI: "You Aren't Gonna Need It" (no lo vas a necesitar).
YAGNI dice: no agregues funcionalidades "por si acaso las necesitás en el futuro": agregá solo lo que necesites ahora. Esto mantiene el código simple, mantenible y eficiente.
Puede que haya gente confundida entre "NTI" y "YAGNI". Pero son conceptos diferentes que operan en niveles diferentes.

YAGNI trata:

• un principio de diseño de software,
• una guía para programadores individuales o en equipo,
• sobre decisiones técnicas dentro de un proyecto,
• sobre mantener el código simple y enfocado.

NTI trata:

• un análisis sociopolítico del ecosistema de software libre,
• sobre corporaciones con poder económico imponiendo tecnologías,
• sobre el control del ecosistema y la concentración de poder,
• sobre la pérdida de libertad de elección y la fragmentación de la comunidad.

La confusión entre ambos conceptos es conveniente para las corporaciones: te permite desestimar críticas a sus tecnologías como "resistencia al cambio" o "conservadurismo técnico". Pero rechazar Wayland, Systemd, Gnome, Snaps, Flatpaks, no es resistencia al cambio. El cambio es bienvenido siempre para quienes voluntariamente decidan adoptarlo. Esto se trata de rechazo a la imposición al cambio "per se", al control corporativo y a la defensa de la filosofía UNIX y a los principios POSIX y KISS.

YAGNI es "no agregues esa función porque no la necesitarás en este momento".
NTI es "la corporación 'X' está imponiendo la tecnología 'Y', eliminando las alternativas mediante poder de mercado".
Son análisis en niveles completamente diferentes. Complementarios, sí; relacionados, también: pero no equivalentes ni sustituíbles.

Criterios para un sistema sin NTI.

Basándonos en el análisis anterior, es posible establecer criterios concretos para identificar distribuciones Linux que evitan las NTI.

Criterios técnicos.

1. "Init system" no-systemd (ni upstart): sysvinit, openrc, runit, s6, etc.
2. Sistema de paquetería nativo, no "Snaps" ni "Flatpaks".
3. Soporte completo de X11/XLibre (Wayland en carácter opcional, conviviendo con X11, no único ni obligatorio).
4. Sistema no inmutable.
5. Escritorio ligero (XFCE, LXDE, Mate, Cinnamon, etc.) o Window Manager (IceWM, i3, openbox).

Criterios organizacionales.

1. Independencia respecto a empresas y corporaciones (Canonical, IBM, Red Hat, SUSE), y si es posible, también respecto a código. Una cosa es "tomar prestado una vez". Otra, totalmente distinta, es "estar esperando permanentemente las novedades de un tercero para hacerlas mías y depender enteramente de ese tercero".
2. Base de desarrollo no controlada enteramente por empresas estadounidenses.
3. Comunidad activa y decisiones democráticas o meritocráticas transparentes.

Criterios de estabilidad.

1. Lanzamientos estables o semi-rolling (no "full rolling release").
2. Modo "live" disponible para pruebas.
3. Preferencia de "independientes" sobre "forks dependientes".
4. Documentación - al menos - en inglés completa, al estilo FreeBSD.

Distribuciones que cumplen con estos criterios.

• Slackware: la distribución más antigua activa. Independiente, usa Sysvinit, su filosofía es absolutamente conservadora y por lo tanto tremendamente estable.
• Gentoo: compilación desde código fuente. Control total, elección libre de init.
• Void Linux: independiente, usa Runit, con filosofía minimalista muy eficiente. Integra lo mejor de ambos mundos (rolling y static) ya que posee absoluto control sobre las actualizaciones, sobre todo en aquéllas que apuntan a "la última novedad del momento".
• Alpine Linux: independiente, usa OpenRC. Diseñada bajo la premisa de "seguridad a través de la simplicidad". Reemplaza la infraestructura habitual (glibc) por musl libc y Busybox. Minimalismo radical y ligereza extrema, resultando en un sistema blindado y sin un solo byte de desperdicio.
• PCLinuxOS: independiente, fiel defensora de Sysvinit. Un caso singular de "rolling release" conservadora; actualiza sus paquetes continuamente pero priorizando una estabilidad de roca. Se mantiene ajena a las tendencias de escritorio modernas, enfocándose en la experiencia de usuario clásica y eficiente.
• CRUX: independiente, usa scripts de inicio estilo BSD. La inspiración original de Arch, pero mucho más estricta en su filosofía "KISS". Sistema de puertos (ports) minimalista, documentación técnica impecable y orientada al usuario experto que exige control manual absoluto sin capas de abstracción.
• FreeBSD: sistema operativo integral, descendiente directo de UNIX. Totalmente independiente de Linux, gestionado mediante el robusto "init BSD" (RC). Separa tajantemente el sistema base de las aplicaciones (Ports). Es el estándar en documentación y coherencia; ingeniería conservadora pura que ofrece un refugio de orden y estabilidad frente al caos de las distribuciones modernas. 
• Artix Linux: distribución radicalista basada en Arch Linux, ofrece Dinit, Openrc, Runit, S6. Ligera, rápida, eficiente. Comunidad activa.
• DeVUAn: fork de Debian construído por veteranos. Sin systemd ni varias políticas nuevas de Debian a nivel de influencia corporativa. Mantiene a Sysvinit. "La estabilidad y el conservadurismo que tenía antes Debian, pero al día de hoy".

Estas distribuciones respetan la filosofía original de Linux y BSD, mantienen la eficiencia como prioridad, y preservan la libertad de elección real.

Implicaciones filosóficas y políticas.

Las NTI no son solo un problema técnico. Son un síntoma de un problema más profundo: la recaptura del software libre por intereses corporativos.

El software libre nació como resistencia.

Richard Stallman creó el movimiento del software libre como resistencia contra el control corporativo del software. Las 4 libertades (utilizar, estudiar, modificar, distribuir) no son solo técnicas: son políticas. son sobre quién controla las herramientas.

La paradoja del éxito.

El software libre tuvo tanto éxito que las corporaciones no pudieron ignorarlo. Linux y BSD dominan servidores, supercomputadoras, dispositivos móviles (Android, iPhones), sistemas embebidos. es infraestructura crítica de la civilización moderna.
Pero ese éxito creó una oportunidad: "si no puedes destruir el software libre, coóptalo: participa, contribuye, y lentamente toma control desde dentro".

El método de cooptación.

1. Contribuir con código y recursos significativos.
2. Ganar influencia y reputación en la comunidad.
3. Crear tecnologías que beneficien a los intereses corporativos.
4. Utilizar o ampararse en el poder económico para impulsar tecnologías.
5. Crear ecosistemas de dependencias.
6. Marginar alternativas que no puedes controlar.
7. Ir dictando la dirección del ecosistema.

Esto no es conspiración. es simplemente cómo operan las corporaciones. Buscan control, predictibilidad, ventajas competitivas. Y el software libre, con su naturaleza abierta, es enormemente vulnerable a este tipo de captura institucional.

La resistencia es posible.

Pero el software libre también tiene anticuerpos. La capacidad de "fork" es fundamental: si un proyecto se corrompe, la comunidad puede copiarlo y seguir sin los elementos corruptos. DeVUAn es fork de Debian sin systemd. LibreOffice es fork de un Open Office manoseado y mancillado en extremo. X11 es fork de XFree86. XLibre es fork de X11.
El fork es el equivalente tecnológico del derecho de secesión en el anarquismo: si no estás de acuerdo, podés irte y formar tu propia comunidad. Esto mantiene honestos a los mantenedores: saben que si se vuelven muy autoritarios o corporativos, la comunidad se les puede ir.

La batalla por el alma del software libre.

Las NTI representan una batalla por el alma del software libre. ¿Va a ser Linux un ecosistema controlado por IBM, IBM-Red Hat, Canonical, etc., en donde las decisiones las toman corporaciones basándose en sus intereses, o va a seguir siendo un ecosistema -todavía - diverso, meritocrático, donde las decisiones aún se pueden tomar por mérito técnico y consenso comunitario?
La respuesta a esas preguntas depende de las decisiones individuales de miles de usuarios y desarrolladores, no de las corporaciones únicamente. Cada persona que elige Void sobre Fedora, Artix sobre Ubuntu, Openrc sobre Systemd, XLibre/X11 sobre Wayland, está votando, silenciosa pero poderosísimamente, por un ecosistema más libre y menos controlado corporativamente.
Son votos pequeños, pero las revoluciones "no dirigidas" empiezan así.

Conclusión: hacia un software libre... "realmente" libre.

Las NTI existen. Están en todos lados. Systemd, Wayland, Snap, Flatpak, Gmome, Pipewire, distribuciones inmutables, Sugar. Todas empujan el ecosistema hacia mayor complejidad innecesaria, mayor consumo de recursos, mayor fragmentación de la comunidad libre, mayor cantidad y uniformidad a costa de una asfixiada y cada vez menor diversidad, mayor dependencia de corporaciones, menor libertad de elección.
Pero también existen las alternativas: distribuciones que respetan la filosofía original, "init systems" que siguen los principios UNIX, entornos gráficos de escritorio que priorizan intuitividad, usabilidad y eficiencia sobre estética corporativa, sistemas de paquetería que respetan la arquitectura del sistema.
Estas alternativas no tienen el respaldo de corporaciones multimillonarias. No tienen campañas de marketing, ni empleados "full-time". Pero tienen algo más importante: principios, filosofía, comunidad, valoración por la historia y resistencia.
La lucha contra las NTI no es una lucha que se gane de un día para el otro. Red Hat tiene mucho poder. IBM tiene muchísimo más poder y dinero. Canonical tiene demasiado marketing. Pero el software libre tiene algo que ellos nunca van a tener: la convicción de que el usuario debe controlar sus herramientas, no las corporaciones.
Cada servidor migrado a Alpine es una victoria. Cada instalación de Artix o DeVUAn es otra. Cada proyecto que rechaza a systemd es una victoria más. Como dijimos anteriormente: son victorias pequeñas, pero reales y con mucho más chances de permanecer y perpetuarse que Ubuntu "Pro" metido en Claude, la IA de Anthropic.
Porque al final, no se trata de qué init usás o qué escritorio tenés instalado: se trata de filosofía. Se trata de resistir el control corporativo en todas sus formas, de mantener vivo el espíritu original del software libre: libertad real, no libertad para elegir entre las opciones que las corporaciones te permiten elegir. Linux no es "prender la radio y escuchar lo primero que venga".
Las NTI son el cáncer del ecosistema. Pero esta enfermedad terminal sí puede ser vencida con conocimiento, con resistencia, con comunidad, con principios, así como el cáncer biológico hace mucho que debería haber sido vencido si las corporaciones - en este caso médicas - hubieran cedido el control a la ciencia y a la investigación para y por la gente, cosa que nunca van a hacer.

"Para quien nace enjaulado, la libertad no es derecho, sino deuda moral y propósito obligatorio."

Referencias.

- Stallman, R. (1983): "The GNU Manifesto".
- Raymond, E. (1999): "The Cathedral and the Bazaar".
- "Systemd Discussions--The Good Parts".
- Entropía binaria (2024), "NTI-Nuevas tecnologías innecesarias IV: ¡Artix vs openSUSE vs Ubuntu vs 9 escritorios vs 2 inits!"

Nota sobre autoría.

El concepto "NTI" fue desarrollado por quien escribe, Hugo Napoli (Entropía binaria) como "framework analítico" para poder entender las dinámicas de poder en el ecosistema del software libre. Este documento es una sistematización académica de ese concepto, basada en cuatro presentaciones en video y el análisis extensivo del ecosistema actual.

Los videos son los siguientes:

NTI-Nuevas tecnologías innecesarias I: tecnologías inútiles y tecnologías innecesarias (Canonical): https://www.youtube.com/watch?v=yujvJYCljNc
NTI-Nuevas tecnologías innecesarias II: tecnologías invasivas (Canonical, IBM, RedHat): https://www.youtube.com/watch?v=B9YG_tYe830
NTI-Nuevas tecnologías innecesarias III: análisis de systemd y otras tecnologías de RedHat: https://www.youtube.com/watch?v=-dwuUJtjE7U
NTI-Nuevas tecnologías innecesarias IV: ¡Artix vs openSUSE vs Ubuntu vs 9 escritorios vs 2 inits!: https://www.youtube.com/watch?v=dj0CuVJZy2Y

Una de las primeras veces en las cuales puedo documentar el uso del término a nivel público, es en el grupo de Telegram de Entropía binaria, en la fecha 14/5/2024:

 

Registro de actualizaciones.
Primera: 30/1/26
Segunda: 18/2/26

Read More