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 el 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 que no deberían existir, o que no deberían existir todavía, o que no deberían imponerse de la manera en la cual se están imponiendo. El concepto NTI no es una crítica reaccionaria contra el cambio, sino un análisis riguroso de cómo el poder corporativo está usando la "innovación" como caballo de Troya para recuperar el control que el software libre les había quitado.

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 son molestas y representan un desperdicio de recursos, pero no son peligrosas. Son síntomas del consumismo, no amenazas al software libre.

2. Tecnologías innecesarias.

Las tecnologías innecesarias son técnicamente funcionales, a veces hasta bien implementadas, pero completamente redundantes. Son soluciones que duplican funcionalidades existentes sin ofrecer ventajas significativas. representan 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). 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.

Upstart (2006-2014): un sistema init creado cuando sysvinit funcionaba perfectamente. Fue reemplazado por systemd, demostrando que toda esa innovación fue en vano.

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:

  • respaldadas por corporaciones con recursos masivos,
  • se convierten en "estándares de facto" 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.

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, aunque los PCs con CP/M eran significativamente más caros.
Microsoft comenzó una guerra de "desgaste por rozamiento contínuo", 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 no 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. 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.

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;
  5. controla el 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 todo, 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 alternativas como 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.

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 sistema operativo. 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: crear dependencia de un paradigma específico en lugar de enseñar principios transferibles.

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. Pulse audio es "legacy". La transición no es por superioridad técnica objetiva, sino por decisión corporativa de hacia dónde mover el ecosistema.
Cuando una sola entidad controla múltiples implementaciones de la misma funcionalidad, puede manipular la percepción 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".

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 hacer el sistema inmutable. La inmutabilidad no agrega seguridad real, solo automatiza configuraciones de manera grotesca, que ya eran posibles de manera sencilla y por defecto.
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 vos decidís 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 operativo.
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.

El problema del adoctrinamiento infantil.

Si le das 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 aprende informática. Aprende "Sugar". Y "Sugar" no le servirá para nada cuando se enfrente a un "ordenador real".
Esto no es educación: es adoctrinamiento. Es condenar a ese niño a una dependencia tecnológica específica sin darle habilidades transferibles.
El 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 metió estas máquinas en el sistema educativo sin consideración real de si eran la mejor herramienta pedagógica.
El plan eventualmente evolucionó y mejoró, pero el daño inicial ya estaba hecho: una generación de niños uruguayos aprendió un paradigma de interacción que no es transferible a ningún otro sistema.

Tecnología invasiva 5: systemd.

Systemd es el ejemplo máximo de tecnología invasiva. Es un sistema init (el primer proceso que arranca en Linux) que ha reemplazado a Sysvinit en la mayoría de las distribuciones principales.

Contexto técnico.

Un "init system" es el proceso número 1 en Linux. Su función es:

  1. iniciar el kernel;
  2. iniciar servicios del sistema;
  3. gestionar el estado de los servicios.

Durante décadas, Linux usó Sysvinit: simple, probado, confiable. Filosofía UNIX pura: hacer pocas cosas y hacerlas perfectamente.

Systemd hace (y es) mucho más:

  • 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);
  • y muchas más 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 que intentan hacer todo.

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 innecesario 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 ser más rápido. en la práctica, las diferencias son insignificantes: medio segundo, un segundo máximo. no es una ventaja real.

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 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 en cualquier hardware. No son una suite. No poseen millones de líneas de código.  Trabajan perfectamente a nivel POSIX, es decir, frente a cualquier porograma que haga lo que tiene que hacer, y lo haga bien, 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 funciona "mejor" con 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 y multiplica las tensiones, 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 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é esto? ¿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 peor, 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 rápido. Igual que IBM, y no es de sorprender, ya que Red Hat es parte de IBM y ahora refuerza y reivindica sus individualistas prácticas contumaces. 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" (sus "recursos humanos"). 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 costosa.

Esto es imposición por saturación: 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 bien ganados a pulso y ofrecía verdaderas herramientas de superación y diversión a granel 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:


Enlace de descarga de este documento:

https://drive.google.com/drive/folders/1Ip_WNaRl9x3JLsb_mpdQCPmDIchlF4Xf?usp=sharing 

 

Registro de actualizaciones.
Primera: 30/1/26

Comprendiendo “sed” en “GeneWeb”: una mirada crítica al código barroco generado por IA.

Comprendiendo “sed” en “GeneWeb”: una mirada crítica al código barroco generado por IA.


sed: una herramienta tan contraintuitiva como poderosa.

Introducción: el problema del código generado por IA.

Cuando trabajamos con inteligencias artificiales para generar código, nos encontramos con un dilema fundamental: las IAs resuelven problemas de manera eficiente, pero respondiendo a su propio límite de “tokens por chat” y con “cabeza máquina”.
Por estas mismas razones es que normalmente producen código compacto y críptico que sacrifica la legibilidad. Este es precisamente el caso que vamos a analizar hoy.

En “GeneWeb” (un generador de páginas HTML estáticas escrito en BASH), necesitaba transformar títulos de artículos en nombres de archivo válidos. La IA me sugirió esta línea:

nombre_base=$(echo "$titulo" | sed 's/|.*//; s/[^a-zA-Z0-9 ]//g; s/ /-/g' | tr '[:upper:]' '[:lower:]')

Funciona perfectamente, pero… ¿qué “diantres” hace exactamente? ¿Podés leerla y entenderla de un vistazo? Muy probablemente no, a menos que seas un experto en “sed”. En lo personal, estuve rato tratando de entender qué hacía “sed” ahí. Y aquí radica el problema: en el “código que funciona en base a tu pérdida de autonomía como programador.

Por eso -y no creas que me resultó fácil- decidí reformularla de esta manera:

nombre_base=$(echo "$titulo" |\     # "|\" se usa como "continuador" (al otro renglón).
    sed 's/|.*//' |\                # Quitar todo después de "|". 
    sed 's/[^a-zA-Z0-9 ]//g' |\     # Quitar caracteres especiales. 
    sed 's/ /-/g' |\                # Convertir espacios a guiones. 
    tr '[:upper:]' '[:lower:]')     # Convertir a minúsculas.

Esto hace exactamente lo mismo, pero ahora puedo leerlo, entenderlo, modificarlo… y EXPLICARLO.


Pero, esperá…
Ahora mismo, en el momento de la redacción de esta entrada, me doy cuenta de que a esto

tr '[:upper:]' '[:lower:]')     # Convertir a minúsculas.

yo no lo hubiera hecho así, sino que hubiera utilizado algo más sencillo y fácil de recordar, estilo "${nombre_base,,}"...

Entonces... Caray, necesito volver a reformular…

nombre_base=$(echo "$titulo" |\     # "|\" se usa como "continuador en el otro renglón".
    sed 's/|.*//' |\                # Quitar todo después de "|". 
    sed 's/[^a-zA-Z0-9 ]//g' |\     # Quitar caracteres especiales. 
    sed 's/ /-/g')                  # Convertir espacios a guiones.

nombre_base="${nombre_base,,}"      # Convertir a minúsculas.

Ahora sí es mi estilo, mi manera de hacer las cosas. Ahora sí voy a proceder a desglosar cada parte con enorme gusto. Antes, ni siquiera me “olía bien” ese código primario, barroco, feo, críptico, entreverado y contraintuitivo, como el escritorio Gnome, por ejemplo. ¿O no?



 
La estructura general: sustitución de comandos y tuberías (o “pipelines”).

Antes de “entrarle de lleno” a “sed”, veamos la estructura general del código resultante y una explicación por adelantado.

Las tuberías (o “pipelines”) son “el resultado de una fase que se convierte en la próxima… Algo así como la “carrera de postas”, en donde, si el corredor “anterior” no resolvió su parte, tampoco podrán hacerlo los subsiguientes.

nombre_base=$(...)

Esto es conocido en programación como “sustitución de comandos”. Todo lo que esté dentro de $(...) se ejecuta, y su salida no se envía a la terminal, sino que se le asigna a una variable; en este caso: “nombre_base". En esta idea me basé para generar el “doble búfer” en mis juegos ASCII en BASH: en lugar de “imprimir directamente en pantalla”, mando todo un escenario gráfico para adentro de una variable y llegado el momento muestro el contenido de esa variable en pantalla (en lugar de ir mostrando paso a paso la construcción de dicho escenario).

Si soy o fui tu profe, sabrás que me voy por las ramas a veces… Me acaba de pasar… Recapitulando…

Dentro, tenemos una tubería. Te lo ejemplifico con “echo” (y simplificado) para que quede más claro.

echo "$titulo" | comando_1 | comando_2 | comando_3 | comando_4

Cada “|”, toma la salida del comando anterior y se la pasa como entrada al siguiente. Al ejemplo del corredor de postas, podemos sumarle el siguiente: una cadena de montaje donde cada estación procesa el producto y lo pasa a la siguiente. A propósito… ¿viste “Tiempos modernos” de Charles Chaplin? Deberías...

El “backslash” (\) al final de cada línea, le dice a BASH (en dialecto rioplatense “uruguayizado”): “esto no termina acá; no te pongás a descansar que hay que seguir laburando en la siguiente línea, valor”. Es código netamente estético, creado para mejorar la legibilidad y forzar a que algo “estrambótico” y que “suene” a “pegado con cinta” dentro de BASH, quede más agradable “al ojo”. Pero, aunque la mona se vista de seda...


 
Primera transformación:
sed 's/|.*//'

Esta es la primera llamada a “sed”. Me da “sed” de solo mirarla. Vamos a diseccionarla completamente.

Pero… Primero que nada, y ahora sí...

¿Qué es “sed”?

"sed" (Stream EDitor) es un editor que procesa texto caracter por caracter, línea por línea, secuencialmente, aplicando transformaciones según las instrucciones que le des. Su sintaxis es notoriamente críptica, herencia de su origen en los años 70. A propósito… ¿te suena “UNIX”?
Si Hugo es tu profesor y aún no te habló de eso, levantá la mano ya mismo, decí “¡sacrilegio!” y decile a Hugo que “el Hugo digital” te dijo que “el hugo real” tiene que explicar ya mismo qué es UNIX. Y como “penitencia”, decile que también tiene que explicar qué es KISS y qué es POSIX.

Anatomía del comando.

La estructura general de una sustitución en sed es:

sed 's/patrón/reemplazo/banderas'
  • "s", significa “sustituír”

  • el primer “/”, es el delimitante inicial para el proceso “patrón a buscar”,

  • el segundo “/”, es el delimitante final para el proceso “patrón a buscar”, y a su vez, también el “delimitante inicial para el proceso reemplazo”.

  • el tercer “/”, o bien cierra el comando, o bien es el delimitante inicial para la colocación de banderas, aunque las banderas son opcionales y en este ejemplo no las usaremos, para no complejizar más al asunto. ¿Viste cuánta seda precisa la mona?

En nuestro caso:

sed 's/|.*//' 
  • patrón a buscar: "|.*"

  • reemplazo: (vacío; nada entre "//")

  • banderas: ninguna.

Descifrando al patrón: "|.*"

Acá es en donde la cosa se empieza a poner... interesante... “ponele”…
Este patrón usa expresiones regulares:

  • "|" es el caracter literal “pipe” (barra vertical),

  • "." significa “cualquier caracter”,

  • "*" significa “tantas veces como sea necesario”.

Entonces, “|.*” significa: “encontrá el primer pipe | y todo lo que venga después de él, sin importar qué $%&/# sea”.
¿Notás que “pipe” es nuestro delimitador representado por “|”, y que ese delimitador podría ser cualquier otro, o bien podrían ser varios? En GeneWeb -y también en otros de mis programas, como en “BurocraTux”-, utilizo a “sed” con el delimitador “///” (en lugar de “|”) y el resultado es el mismo.

Ejemplo práctico.

Si mi título es “Mi primer artículo | Borrador”:

el patrón “|.*” encuentra “| Borrador” (el “pipe” -o delimitador- y todo lo demás), y lo reemplaza por “nada” (es decir, lo elimina). Resultado: “Mi primer artículo”.

Importante: “sed”, por omisión, solamente busca la primera coincidencia en cada línea.
Y aquí es en donde entran en juego las banderas: si quisiéramos eliminar (o sustituir) todas las ocurrencias y no solo la primera, deberíamos usar la bandera “g” (global).


 
Segunda transformación: sed 's/[^a-zA-Z0-9 ]//g'

sed 's/[^a-zA-Z0-9 ]//g'

Esta es la más compleja de todas. Vamos por partes.

La “clase de caracteres”: [...]

Los corchetes [] definen una clase de caracteres, es decir, un conjunto de caracteres válidos. Por ejemplo:

  • [abc] coincide con a, b o c

  • [0-9] coincide con cualquier dígito

  • [a-z] coincide con cualquier letra minúscula

La negación: [^...]

El acento circunflejo ^ al inicio de una clase de caracteres, niega esa clase:

  • [^abc] coincide con cualquier caracter excepto a, b o c

  • [^0-9] coincide con cualquier caracter que no sea un número.

Desglosando [^a-zA-Z0-9 ]

Esta clase dice: “cualquier caracter que NO sea”:

  • a-z: letras minúsculas de la a la z,

  • A-Z: letras mayúscula de la A la Z,

  • 0-9: dígito (números del 0 al 9),

  • : espacio (ese espacio “que no está negado” -después del 9- es importante).

En otras palabras: elimina todo excepto letras, números y espacios.

La bandera global “g"

sed 's/[^a-zA-Z0-9 ]//g'

La “g" al final, significa “global” y aplica el reemplazo a todas las coincidencias, no solamente a la primera, tal como lo comenté antes.

Ejemplo práctico.

Si tenemos “¿Cómo funciona BASH? ¡Explicación completa!”, los caracteres que no son letras, números o espacios, son, por ejemplo: ¿, ó, ?, ¡, !

Después de correr la línea de más arriba aplicándola a esta frase, el resultado sería el siguiente:

"Cmo funciona BASH Explicacin completa".

Nota: observá que la “ó" desapareció completamente porque no está en el rangoa-zA-Z", el cual no contempla vocales con acento. Esto es una limitación intencional para generar nombres de archivo seguros.


 
Tercera transformación: sed 's/ /-/g'

sed 's/ /-/g' 

Así como la anterior era la más difícil, acá te traigo el “cafecito con Massini”… ¿No conocés el postre “Massini”? Pues… Deberías mirar “Tiempos modernos” desde un sistema “UNIX-like”, y comiendo un Massini.

Esta es la más sencilla de todas:

  • patrón: “ “ (un espacio),

  • reemplazo: “-” (un guión),

  • bandera: “g” (global, todos los espacios y no solo el primero que “haiga”).

Simplemente convierte todos los espacios en guiones.

Ejemplo práctico

Siguiendo con nuestro ejemplo, la frase “Cmo funciona BASH Explicacin completa”, se convertirá en: “Cmo-funciona-BASH-Explicacin-completa”.


 
Cuarta transformación: tr '[:upper:]' '[:lower:]'

tr '[:upper:]' '[:lower:]'

Finalmente, salimos de sed y usamos tr (translate, traducir).

¿Qué es “tr”, aparte del sonido de un redoblante?

¡No te asustes, que “tr” es más simple que “sed” y además ya estamos terminando!
“tr
traduce o elimina caracteres. Su sintaxis básica es:

tr 'conjunto_1' 'conjunto_2'

Reemplaza cada caracter del “conjunto_1” con el caracter correspondiente del “conjunto_2”.

Las clases POSIX: [:upper:] y [:lower:]

¿Te acordás de que antes hablamos de lo que era una clase? ¿Te diste cuenta de que las podías crear vos? Pues, bien: también hay clases predefinidas, por ejemplo estas 2:

  • [:upper:] representa a todas las letras mayúsculas,

  • [:lower:] representa a todas las letras minúsculas.

Esto es más robusto que usar A-Z y a-z porque funciona correctamente con diferentes “locales” (variables del sistema para definir el área de localización geográfica, los formatos de fecha, hora, moneda, etc).

Ejemplo práctico.

El texto "Cmo-funciona-BASH-Explicacin-completa", al ser "pasado por el tamiz" de estas clases, se
convertiría en "cmo-funciona-bash-explicacin-completa".



El resultado final

Partiendo del título original:

¿Cómo funciona BASH? ¡Explicación completa! | Borrador

Las transformaciones sucesivas son:

  1. Después de sed 's/|.*//':

    ¿Cómo funciona BASH? ¡Explicación completa! 
  2. Después de sed 's/[^a-zA-Z0-9 ]//g':

    Cmo funciona BASH Explicacin completa 
  3. Después de sed 's/ /-/g':

    Cmo-funciona-BASH-Explicacin-completa-
  4. Después de tr '[:upper:]' '[:lower:]':

    cmo-funciona-bash-explicacin-completa-

Y ese sería el contenido de la variable nombre_base, que luego se usaría para generar el nombre del archivo HTML.

 



Comparando las dos versiones.

Código rígido generado por IA:

nombre_base=$(echo "$titulo" | sed 's/|.*//; s/[^a-zA-Z0-9 ]//g; s/ /-/g' | tr '[:upper:]' '[:lower:]')

Ventajas:

- código “oneliner” (ocupa una sola línea),
- es más “eficiente” (menor cantidad de código -y por eso la IA la elige-).

Desventajas:

- prácticamente ilegible para quien no domine sed
- los tres comandos sed están concatenados con “;” dentro de la misma invocación (barroquismo),
- difícil de modificar o “debuggear”
- perdés autonomía como programador: no entender qué hace cada parte, es no poder mejorarla: es como autoimponerte una “caja negra” cuando estás trabajando con open source… un contrasentido total.

Código “esponjoso” creado por un profesor que además de querer que tu programa funcione, quiere que entiendas cada “mísero” caracter que hayas puesto en tu programa:

nombre_base=$(echo "$titulo" |\ 
    sed 's/|.*//' |\ 
    sed 's/[^a-zA-Z0-9 ]//g' |\ 
    sed 's/ /-/g' |\ 
    tr '[:upper:]' '[:lower:]') 

Ventajas:

- legible: cada transformación es clara,
- comentable: podés agregar comentarios línea por línea (que fue lo que hice yo mismo),
- modificable: si necesitas cambiar una transformación, sabes exactamente dónde hacerlo,
- educativo: otros programadores pueden entenderlo, independientemente de su nivel de “nerdcidad”.

Desventajas:

- ocupa más líneas, ergo, más recursos de espacio,
- ¿hay realmente alguna otra desventaja?


 
Conclusión: código legible vs. código obsesivamente eficiente.

Este ejemplo ilustra un principio fundamental en programación: el código se escribe una vez, pero se lee muchas veces.

La versión “eficiente” de la IA ahorra código, pero a costa de la comprensión. En un script personal que compartís públicamente (como los míos en CodeBerg), la legibilidad es mucho más valiosa que la micro-optimización. En la vida de un profesor, también. Rara vez encontrarás a un profesor que enseñe de manera críptica. Se puede, y es un gran desafío, pero no es lo común. Lo que sí es común, es que profesores escriban de manera barroca y te digan “esto se hace así, anotátelo en el cuaderno porque es imposible de memorizar” y que siga con su clase: me ha pasado y soy enemigo acérrimo de ese tipo de “docente”.

El verdadero problema del código barroco generado por IA (y más con instrucciones que son un imán para las dificultades, como “sed” o “awk”) no es que esté mal: es que te puede alejar del control de tu propio código. Si no entendés cada parte de lo que hace tu programa, no sos dueño del mismo: sos su rehén. O sos rehén de la IA...

Por eso, aunque “sed” sea una herramienta poderosísima, su sintaxis barroca y contraintuitiva exige que siempre expliquemos lo que hacemos. Ya sea mediante comentarios, mediante código más “verborrágico”, o (como en este artículo) mediante documentación externa.

El conocimiento profundo de nuestras herramientas es lo que nos diferencia de quien simplemente copia y pega código que no comprende.

 



Referencias y recursos adicionales.

Si ahora te gustó el “temita este” y querés profundizar, te recomiendo:

  • GNU sed manual: "info sed" o "man sed"

  • Regular-Expressions.info: excelente recurso para entender expresiones regulares

  • El libro sed & awk de O’Reilly: el clásico definitivo sobre estas herramientas (podés encontrarlo en la biblioteca de Entropía binaria, en el grupo de Telegram, junto a otras joyas de este estilo).

Y recordá siempre: no hay preguntas tontas cuando se trata de entender tu propio código. Si algo te parece críptico, probablemente lo sea también para otros. Explicarlo es un acto de generosidad hacia la comunidad y hacia la fuerza digital ética y moral de tu yo del futuro.


Flag Counter Visitas previas a la existencia de este contador: 3433

Artículos aleatorios

    Páginas: