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:
- una corporación con recursos masivos identifica un ecosistema;
- crea o adopta tecnologías que puede controlar;
- utiliza su poder para imponerlas como "estándares";
- margina o elimina alternativas técnicamente viables, generalmente bajo un irresponsable discurso futurista;
- 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:
- ser el padre de todos los procesos en el sistema operativo,
- disparar la activación de la swap,
- iniciar a todos los servicios que necesite el sistema,
- verificar el estado de cada proceso y gestionarlo correctamente,
- 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.
- "Init system" no-systemd (ni upstart): sysvinit, openrc, runit, s6, etc.
- Sistema de paquetería nativo, no "Snaps" ni "Flatpaks".
- Soporte completo de X11/XLibre (Wayland en carácter opcional, conviviendo con X11, no único ni obligatorio).
- Sistema no inmutable.
- Escritorio ligero (XFCE, LXDE, Mate, Cinnamon, etc.) o Window Manager (IceWM, i3, openbox).
Criterios organizacionales.
- 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".
- Base de desarrollo no controlada enteramente por empresas estadounidenses.
- Comunidad activa y decisiones democráticas o meritocráticas transparentes.
Criterios de estabilidad.
- Lanzamientos estables o semi-rolling (no "full rolling release").
- Modo "live" disponible para pruebas.
- Preferencia de "independientes" sobre "forks dependientes".
- 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
