CRUX, una travesía de 26 días y contando.

Reconstrucción de un "largo y ventoso camino" de un hombre y una máquina con CRUX: un instalador modular KISS para CRUX Linux.

Let me know the way: crónica cronológica del período 1 al 23 de agosto de 2026.

Hugo Napoli, Entropía binaria.

Esta crónica se reconstruye a partir de 8 hilos simultáneos de trabajo de Hugo Napoli sobre CRUX Linux, desarrollados a lo largo de todo el mes de agosto de 2026. Una línea de tiempo actúa como columna vertebral. Sobre ella penden aciertos, decisiones de arquitectura, problemas graves, responsabilidades ajenas, sano entusiasmo y enorme amor y esfuerzo genuino por utilizar y compartir una de las piezas más nobles que el software libre haya podido parir: un gran sistema operativo que invita a que lo arme uno mismo, micropieza por micropieza, y cuya invitación linuxera le llega al compañero usuario de software realmente libre, justo en el mismo momento en el que, por ejemplo, un gran mecánico podría estar dándose cuenta de que jamás armó su propio automóvil, pero que siempre ha vivido reparándole a otros, con dedicación profesional, lo que nadie repara.

Esta crónica con mixtura de andanza y travesía, está escrita en gran parte en tercera persona, porque para esto "se evaluó" que era la mejor posibilidad y el mejor escenario: de este modo la libertad poética es mayor, a la vez que la distancia emocional también. Porque los procesos técnicos complejos están cargados de emociones. Siempre.

Vas a encontrarte con partes demasiado técnicas y otras mucho más narrativas. Si te copa, hacé el esfuerzo y leé todo, intentando comprender de qué se está hablando. Fue enriquecedor haberlo transitado, y quizás para ti, querido lector, querido amigo, también lo sea al leer este texto. 

Los 2 protagonistas y sus responsabilidades.

Antes de la cronología, conviene fijar quién puso qué, porque esto fue titánico y fue de a 2, un hombre y una máquina. Porque en Entropía sentimos que es un orgullo y un privilegio trabajar con una máquina de las prestaciones que hoy nos brindan los LLM, y más cuando el fin es noble: hacer lo que nadie hizo antes, y además compartirlo.

Hugo (el hombre). Intervención directa en hardware real, dmesgs, logs, criterio férreo e innegociable de qué se quería y qué no, filosofía KISS, X11, no-Wayland, no-systemd, no-PipeWire, no-Gnome, no-blobs innecesarios.
También la decisión de arquitectura en cada milimétrica, cuidada y recelosa bifurcación, y - esto es central - la exigencia de verificar exhaustiva y empíricamente antes de dar nada por cierto. Leyó cada respuesta en vez de copiar y pegar recetas de una máquina, para no volverse él mismo máquina de la máquina. Cazó bichos, corrigió errores de diagnóstico, se hizo cargo de su propia derrota técnica así como también de cada aprendizaje, incluso estando muchas veces agotado, estresado, "caliente", siempre sin perder el norte: lo comunitario, lo que no solo "está bien PARA MÍ".

Claude (la máquina). Investigó y puso los símbolos de kernel, las reglas de dependencias, las búsquedas, los diffs quirúrgicos en el estilo BASH de Hugo. Se equivocó varias veces con hipótesis presentadas con demasiada confianza, y fue detenida, corregida, reencauzada, con precisión, experiencia y donde cupo, experticia humana acumulada.

Pero "responsabilidades", también significa otra cosa en esta crónica: el registro de las trabas estructurales evitables que cargaron sobre el proyecto gentes que recitaron mal su parte. Eso tiene su propia sección al final ("El acta"), y aparece señalado en la línea de tiempo cada vez que corresponde. Zapatero, a tus zapatos, seas Torvalds o Gates. Con la verdad no se ofende ni se teme, y no se le hace el caldo gordo a nadie ni se barre para abajo de la alfombra. Como militantes, debemos denunciar lo que dentro del software libre funcione mal, o estamos siendo títeres de otros ante gente que nos escucha sincera y atentamente y que nos regala su confianza. ¿Hay algo más preciado que eso? ¿Algo que cuidar más? Para nosotros, este es - y será siempre - el fin de la discusión.

El origen antes del origen (julio de 2026).

La travesía de CRUX no empieza ni ahora ni con CRUX, increíblemente. Ya se venía peleando contra un mismo enemigo estructural, pero en otro frente: Barry (el metabuscador en Go de entropIA criolla, la IA local del laburante, que podés encontrar y descargar gratuitamente desde acá) se daba de frente contra "Anubis", el "proof-of-work anti-bots" que había vuelto inservibles las instancias públicas de SearXNG, haciendo que respondiesen "0 de 74". Con ese mismo "Anubis" nos íbamos a volver a cruzar, salvo que esta vez con otro compañero (CRUX), pero días después. El monstruo convocado conscientemente y a sabiendas por terceros (es importante resaltar que no solo es utilizado por mega corporaciones como Google) ya estaba presentado antes de que empezara la presentación por orden alfabético del elenco completo de los actores de esta, en parte, obra de terror.

LÍNEA DE TIEMPO.

1° de agosto de 2026, el verdadero punto de partida.

El origen de todo, en realidad no fue un capricho, sino un acto de responsabilidad. Tim "beerman" Biermann, uno de los desarrolladores más activos de CRUX, vio la saga de videos sobre CRUX producidas en Entropía, junto con las 2 guías escritas (CRUX y CRUX EX), las cuales incluyó en la web oficial y podés ver acá ( https://crux.nu/Main/Links ) y señaló, con muy buena onda (con ese apodo no podía proceder de mala onda nunca), un error común a todas: las instalaciones de Entropía terminaban utilizando a rEFInd para el arranque del sistema, cuando en realidad, CRUX, no lo necesita. No lo dijo con amenaza ("cambialo o borro tus links"), lo dijo como un par. Pero sobre todo, como consejo sabio de un buen tipo.

Se dejó pasar el tiempo, se extravió el e-mail en donde estaba dicha información (1), y ahora se quiso saldar esa deuda pendiente con CRUX y con Tim, corrigiendo esto y generando, además, un aporte útil que en lo posible elevara la apuesta y fuese importante.

Y acá viene una anécdota dolorosa, que fue el verdadero combustible para poder arrancar de una vez todos los motores a su máxima potencia. Y en esto, Ni Tim ni CRUX tuvieron nada que ver.

Para quienes poseemos el gusto por compartir -el mundo del software libre está repleto de gente así-, uno disfruta mucho esa situación. Uno no hace cosas "para compartirlas", como si fuese una misión en la vida. Uno hace cosas, y luego, si cabe, las comparte. Y como sabe que terminará compartiendo lo bueno, no cualquier cosa, cada cosa que se lleva entre manos a algún lugar para ser compartida, es un tesoro para quien genuinamente posee ese sentimiento: "voy a entregar esta gema altamente preciada por mí a una comunidad, o a un amigo, o a alguien que creo que de verdad lo necesita... tanto como yo lo necesito". Porque esta es la idea. No se trata de hacer cualquier cosa y creernos sénecas que todo lo que producimos va a iluminar, a importar o a ser necesario o útil.
Cuando trabajás durante semanas, con ahínco, con seriedad, con pasión y responsabilidad sobre algo específico... Cuando sabés que ese algo es complejo y que lo estás comprendiendo, que se te van develando sus misterios a cada paso que das en tus investigaciones y prácticas... Cuando avanzás a paso lento pero firme... y cuando culminás la etapa exitosamente, es cuando te decís... ¿y ahora, en dónde hará honores esta querida pieza a la que tanta dedicación le puse, tanto tiempo y esfuerzo me llevó, y a la cual sé que hay gente que la quiere? Eso fue lo que representó "TDE" (Trinity Desktop Environment) para mí.

El proyecto se llamó "TDEntropía", y se basó en llevar TDE a Void Linux, y lo podés encontrar acá, junto con su complemento "tYb" (Trinity y Bambino) y un panel de control 100% funcional hecho en estilo "dialog" (TDE_YaST).

La comunidad de Entropía fue siguiendo los avances, con respeto, colaborando, aconsejando, esperando el resultado. Como siempre. Es la barra que sabés que no te va a dejar tirado. Uno va construyendo y programando, apoyándose en la confianza de compañeros que se sabe que están siempre ahí. Al terminar y hacerse la pregunta "¿y ahora?", en lo primero que se piensa, es en "en el epicentro mismo", el cual, en este caso, era en la comunidad de Void Linux, sistema desde el cual por ahora se maneja todo lo de Entropía y lo de Hugo.

Se publicó en el reddit de Void Linux este arduo trabajo.
Duró cientos de visualizaciones, algunos "likes" y... menos de 2 minutos reloj, siendo eliminado sin miramientos por alguien del equipo de moderación.

Enlace (caduco) a la publicación: https://www.reddit.com/r/voidlinux/comments/1v9y21s/contenido_eliminado_por_la_moderaci%C3%B3n/ 

Imagen del (in)suceso:

Ante el debido y estupefacto reclamo, no se recibió más que (más) distancia y frialdad (aún), marcándose notoriamente la distancia que media entre algunos desarrolladores, o moderadores, o ambas cosas, y los programadores que queremos contribuír no con ellos, sino con toda una comunidad entera, pero que sabemos bien que el primer filtro empieza con quienes están al frente de la custodia... Custodia que a veces se pasa de horno.

Pero hay otro combustible que nos mueve desde siempre: el anticorporativismo, sobre todo el que está tiñendo a todo Linux y al cual no es posible evitar ni esquivar sin conocimiento y esfuerzo, y que es aquél que promueve, por ejemplo, a una pieza inmadura y eternamente impresentable como WayLand por sobre el bastión de bastiones, XOrg. O la que profesa que "systemd" llegó "en un inicio" para "mejorar el arranque de los sistemas Linux", mientras que, ni llegó para eso, ni lo logró después de bastante más de una década. Y se podría seguir con las particularidades de la comunidad de Gnome y con el propósito y la estética de sus productos, con PipeWire, y ya de paso, con IBM, RedHat, Canonical con Ubuntu y sus polémicas re-creaciones. Pero ya es más que suficiente, mucho más que para un simple buen entendedor. Y que se entienda bien: Entropía no condena ni discrimina al usuario de a pie, sino a la idea y a quienes la impulsan. Que vos uses Ubuntu, Wayland, Snaps, Flatpaks, Gnome, a Entropía no le interesa ni tampoco le interesa "corregirte". Lo que nos interesa es que te llegue nuestra palabra (cuando se trata de conversaciones con linuxeros o BSDeros, le hablamos a un 1% dentro de un 6% y lo tenemos claro) y que pienses por ti mismo.

De este caldo de cultivo nació todo.

La cadena fue:

1. Como las guías de Entropía (videos, posts) utilizaban rEFInd erróneamente, y...
2. una de ellas (la más general, profusa y global) fue actualizada, reemplazando rEFInd por GRUB... Y como GRUB en UEFI es en donde más suelen aparecer trabas, y para CRUX es maquinaria de sobra, y esto no era lo mejor...
3. Se trabajó en el método correcto, que era el que el desarrollador comentaba, y que supusimos que era "EFI Stub puro", en donde el kernel es iniciado por la propia UEFI, de manera directa desde una entrada UEFI con "efibootmgr", sin "bootloader" intermedio.

Y acá ya se estaba compilando al kernel de CRUX con "CONFIG_EFI_STUB=y", habiendo construido ya medio camino hecho sin ser conscientes de esto.

Decisión de arquitectura #1: no corregir solo la guía, sino construir un instalador automatizado ("InstaCrux.sh") que hiciera la instalación entera por EFI Stub, para compartirlo y pulirlo con/en la comunidad de Entropía primeramente y presentárselo a los desarrolladores luego de estar medianamente maduro el proceso, es decir, pasar de "corregir un post" a "construir infraestructura socialmente útil".

Acierto importante #1: entender que el problema del bootloader no se resolvía eligiendo otro gestor, sino eliminando la capa entera. El método más simple era además el más robusto. KISS en estado puro.

Primeros días de agosto: InstaCrux.sh, el instalador base.

Este es el hilo troncal más largo de toda esta travesía plagada de cientos de anotaciones. Acá el instalador base fue tomando su forma definitiva al quedar demostrado que podía particionar, formatear, compilar el kernel, instalar software base, configurar el teclado, la zona horaria y arrancar por EFI Stub... Y acá también es en donde empezaron a aparecer los primeros golpes serios. 

Los hitos dentro de esta etapa.

Problema grave #1: el "kernel panic" de la microSD y el gestor de NVRAM.

Al pasar de la máquina virtual al hardware real (una laptop Acer Aspire A325-42, AMD Barcelo/Ryzen, con CRUX en una microSD), el sistema entraba en pánico: "VFS: Unable to mount root fs". El kernel buscaba la raíz en "/dev/sda2" pero no la encontraba a tiempo.

El diagnóstico se hizo en frío, desde Void, montando a la partición de CRUX sin necesidad de "bootearla". En varias ocasiones, no fue necesario arrancar el sistema roto para poder trabajarlo.
Entonces, apareció la pista que no cerraba: un "lsblk -o NAME,SIZE,TRAN" mostró que la microSD se presentaba como "sda", con transporte USB, y esto significaba que la ranura "SD" de la laptop estaba cableada internamente como lector USB, por eso el sistema nunca la vería como el esperable "mmcblk", y por eso los drivers MMC no servían de nada -los que importaban eran los USB-. El ajuste final resultó ser un detalle mínimo pero difícil de terminar encontrando: faltaba "rootdelay". Sin initramfs, el kernel salía a buscar a la raíz antes de que el circuito USB terminara de despertar, y fallaba estrepitosamente. Con darle 5 segundos de paciencia ("rootdelay=5") al "CONFIG_CMDLINE", validándolo primero con una entrada NVRAM de prueba descartable antes de volver a compilar ("efibootmgr -c ... -u 'root=/dev/sda2 rootdelay=5'"), todo empezó a fluir.

Como CRUX no posee un cargador de arranque dedicado, como GRUB y otros, se creó un script BASH para gestionar la NVRAM de manera directa, especialemte tras cada reinstalación, ya que es posible que se dupliquen las entradas de arranque del sistema. Dicho script es "00_EFI_acomodeitor_[CRUX].sh", y lo podés encontrar acá, junto a otros de su misma especie: https://codeberg.org/entropiabinaria/AMPCI

Acierto importante #2: rechazar los diagnósticos a ciegas.

Frente a la avalancha de comandos y el debug "ad infinitum", el freno "no intentar resolver 20 interrogantes juntas, sino ir de a una cosa por vez" fue lo que mantuvo el método limpio y evitó quemar tiempo e introducir ruido y basura en un proceso que siempre intentó mantenerse limpio y pulcro.

Decisiones de arquitectura de esta etapa.

- Kernel sin initramfs, con los drivers de arranque (SATA/NVMe/USB/MMC/SCSI) forzados built-in ("=y").
- Función "elegir_tipo_medio" con opción interna/externa/manual, para agregar "rootdelay" condicionalmente.
- Función "advertencia_updated": avisar al usuario que utilice la ISO comunitaria de Jaeger (crux.ninja) y no la oficial, para evitar compilar monstruos como "fftw", "gcc-fortran", "rust" o "llvm" a mano. ¡Gracias, Jaeger!
- Corrección del teclado en chroot: mover "elegir_teclado" antes de establecer_password_root" y aplicar "loadkeys" de inmediato, para que la contraseña se tipee con el "layout" correcto.

10 de agosto de 2026: el video en VirtualBox.

Hilo "Solucionar video en Crux VirtualBox sin Guest Additions". CRUX en VBox no levantaba X: "no screens found", porque no existía "/dev/dri/" (faltaba el módulo "vboxvideo").

Decisión de arquitectura #2: en lugar de compilar las "Guest Additions" (pesado, solo para pruebas), evaluar el driver vesa forzado, que no toca "/dev/dri" en absoluto y renderiza por framebuffer. KISS. La idea posterior: que el instalador pregunte al final "¿MV? [1] QEMU [2] VirtualBox [3] No" y actúe en consecuencia, dejando el hardware real intacto. Esto no se implementó y está lejos de hacerse: no es prioridad en este momento. Si alguien quiere hacer ese aporte, será bienvenido.

Que CRUX funcionara, en un inicio, en VBox y no en bare metal, no fue demérito del instalador, sino un caso trivial. El NIC y el video emulados de VBox utilizan drivers universales. El "bare metal" es el examen de verdad, y lo que importa. Tal vez más adelante se brinde cobertura para máquinas virtuales, pero por ahora, la idea es que CRUX funcione bien en donde ya lo está haciendo y en donde realmente debe hacerlo, lo cual es en máquinas físicas. 

12 de agosto de 2026. El ciclo de trabajo se había vuelto agotador: producir en Void, subir a CodeBerg multiplicidad de scripts y subscripts (todos con cambios de prueba mínimos), eliminar vestigios de procedimientos anteriores en CRUX, hacer "rollback", descargar en CRUX por consola las nuevas versiones, ejecutar, ver si los "fixes" habían resuelto los problemas y volver a empezar ante cada error, muchas veces reinstalar CRUX por encima de CRUX otra vez, recompilando a lo bestia...

Anyway, you'll never know... The many ways I've tried...

Los LLM son superestructuras espectaculares, sí, pero muchas veces la ayuda de un LLM no es la solución total ni final, ni ahorra tanto tiempo como parece... o como debería.

Un ejemplo concreto: la ISO resultante quedaba con archivos pertenecientes a root, y hubo que resolverlo con "ajustar_propietario", usando las variables $SUDO_UID y $SUDO_GID para devolver la propiedad al usuario invocante. Pero el punto de fondo no es que la IA escribiera código frágil: es que lo escribió con patrones que produjeron fallos en el borde, en el momento del éxito, que es en donde menos se los busca. No reventaba en el camino fácilmente auditable. Y este "camino feliz en el bosque de Caperucita Roja" no es en donde se termina fogueando a una buena pieza de software libre.

También se creó a EtherFI.sh, una herramienta para conectar a Internet a un sistema sin entorno gráfico, especialmente por WiFI, en donde el proceso es tedioso, mecánico y repetitivo:

https://codeberg.org/entropiabinaria/EtherFi

Mediados de agosto - crux-instapelao.sh, la post-instalación.

https://codeberg.org/entropiabinaria/crux-instapelao 

Chat "Instapeláo" (el más extenso de todos hasta el momento de escribir este artículo) y "Purga de XFCE". Nace este otro script, que corre sobre el CRUX ya instalado y arrancado. Es un terreno menos hostil (sin chroot, sin kernel, sin particiones), pero no por esto estuvo (ni está, posiblemente, aún) exento de enormes batallas. Quizás las peores.

Corrección de fondo #1: CRUX no utiliza OpenRC (como Void), ni runit, ni systemd. Usa SysVinit clásico con initscripts al estilo "BSD": los servicios se hallan en el array "SERVICES=(...)" de "/etc/rc.conf". dbus se levanta agregándolo al array, no con "sv", "rc-service". ni mucho menos con systemctl. Yo a esto no lo tenía tan claro: solo lo recordaba apenas, por haber trasteado con algún Windows Manager como OpenBox y el que más me gusta, IceWM. Resultó ser increíblemente sencillo de utilizar, y lo mejor de todo, sumamente intuitivo:

/etc/rc.d/servicio start servicio

Decisión de arquitectura #3 (fuerte): root es root y user es user. Nada de la idiotez de sudo y "poné-tu-propia-contraseña". Nada de la sobreidiottez del "sudo timeout". Separación estricta de privilegios, seguridad, privacidad desde el diseño raíz.

Purga de XFCE: por la poca fiabilidad del hosting y por ser XFCE experimental en CRUX, se extirparon quirúrgicamente del script 2 de las piezas elegidas inicialmente como más importantes, no sin pesar: XFCE y SLiM, dejando intacto todo lo demás (XOrg base, audio, usuario, servicios, infraestructura). Se tuvo que hacer una intervención con inteligencia artificial para eliminar los rastros, porque de otro modo, la opción hubiese sido reescribir todo desde cero, en medio de un estado demasiado avanzado de progreso. Se depuraron y purgaron decenas de funciones huérfanas y variables muertas durante esta etapa.

La idea era entregar a CRUX con XFCE, y se trabajó en ello hasta que fue más sensato abandonarlo que "seguir trabajando en el reviente 1/? de la pieza 1/58 luego de  5 días seguidos de incertidumbre, caos, estrés y ganas reales de abandonar todo el proyecto por ser en extremo agotador y muy poco prometedor en los hechos".

Resiliencia ante infraestructura rota: se construyó "intentar_depinst", una función que envuelve a "prt-get depinst" con reintento automático, detección de fallos de descarga y un menú de cuatro opciones (reintentar / saltear este / saltear todos / abortar), más su compañera "verificar_conexion_y_ports". Para la señal interna de "salteado a propósito" se eligió el código de salida 13. La primera opción había sido 666 —por razones que no hace falta explicar, tratándose de quien se trata-, pero los códigos de salida en UNIX solo llegan hasta 255: cualquier número mayor "se da vuelta" y 666 terminaba convertido en 154. Detalle tonto, pero ilustrativo del terreno. Y esta contención resultó profética: fue exactamente lo que evitó que el script muriera más adelante, cuando "free"desktop empezó a rechazar descargas.

Corrección y problema grave #2: Rust "el foráneo" y la variable "JOBS" vacía.

"prt-get sysup" fallaba compilando rust 1.98.0 con:
"error: a value is required for '--jobs <JOBS>' but none was supplied".
Se persiguió primero la hipótesis equivocada (el jobserver de GNU Make colándose por "MAKEFLAGS"). Hubo explicaciones confiadas que resultaron incorrectas. Lo que resolvió el caso fue la insistencia en ver la fuente real: "prt-get cat rust" reveló la línea del Pkgfile, en donde aparecía, otra vez en un lugar totalmente predecible, un viejo conocido: Python.

./x.py --config=... install -j ${JOBS}

¡Como para no tenerles bronca!

El port usa la variable "JOBS", no "MAKEFLAGS". Se había definido MAKEFLAGS="-j16" pero nunca "JOBS", así que Rust ejecutaba "./x.py install -j" con la variable vacía (ver "Rust" y "py" juntos en la misma oración ya empieza a causarle estragos a mi paz mental...). El error era propio, no de Rust: la evidencia empírica del Pkgfile mató a todas las suposiciones. La solución fue que "configurar_paralelismo" siempre exportase ambas variables ("JOBS" y "MAKEFLAGS"), incluso en modo mononúcleo, en donde se fija explícitamente "JOBS=1". Porque este es el detalle fino: a Rust no le molesta compilar con 1 solo núcleo, lo que le molesta es que la variable esté vacía. Con "JOBS=1" (bien definida), compila sin chistar aunque sea con 1 solo core, siendo que lo que no perdona es el "-j" pelado, sin número detrás. Rust en este caso no supo qué hacer con la situación, ya que no pudo manejar a una variable en blanco, la cual, si nos ponemos estrictos, no es necesaria ni intuitiva dentro del mundo UNIX. Lleve su chirlo por bruto, y a caminar derechito. 

Por este tipo de "detalles omnipresentes" es que digo que una tecnología es foránea -muchas veces tildándola como "NTI"- (3), que muchos desarrolladores, al implementar tecnologías, no saben lo que hacen -pese a que "sepan mucho"-, que no les interesa el verdadero contexto, que no son de acá, que no pertenecen a este ecosistema, que no lo entienden. Son como caballos con antiparras: sabrán muchísimo, sí, pero programan como quien llega a una casa ajena y empieza a mover los muebles sin preguntar. Porque no saben -ni les importa- el hecho de que la organización de las piezas es el producto de la depuración de ensayos, en el tiempo, el que lleva a los habitantes de ese ecosistema a disponerlos así y ahí.

Acierto importante #3, y metodológicamente quizás el más valioso: la autoexigencia de ver el Pkgfile en vez de aceptar cualquier explicación teórica al segundo o tercer error grave.

No adivinemos: leamos la fuente. Esta disciplina es la que distingue a un ser sólido de uno que simplemente fue afortunado durante el mismo.

Problema grave #3: el footprint NEW de... otra vez, Rust.

Compilar Rust "exitosamente" -si es que se puede decir así- fue una de las peores "malas ligas" de todo el proceso. Justo había aparecido una versión nueva de Rust que dejaba obsoleta, por un pelín nomás, a la que Jaeger tenía empaquetada en la ISO Updated, y eso obligó a más de 2 horas de compilación solo para esto. Y al terminar, "prt-get" lo marcaba de todos modos como fallido, ahora por mismatches de footprint (hashes de librerías). Se resolvió instalando el paquete que se acababa de compilar y de manera directa con "pkgadd -u", que saltea la verificación de footprint. Y eso destapó algo: los fallos previos de Rust nunca habían sido de footprint: eran siempre el mismo error de "--jobs". Dicho esto, Rust no me cae en gracia porque en su cadena de dependencias actúa como si fuese un "Python mejorado". Y esto, claramente, no es un elogio.

And still, they lead me back...

Problema grave #4: Anubis en "free"desktop, y el cerco de los mirrors.

Ahora sí, preparate para la repartija de cascarazos, chirlos y piñas a lo Bud Spencer y Terence Hill, porque llegamos al corazón del "Acta de Responsabilidades".

"gstreamer.freedesktop.org" devolvía HTTP 503 debido a la implementación de Anubis, un "PoW" "proof-of-work anti-scraping" que bloquea justamente a "curl y a "pkgmk".

Mediante trabajo empírico real (otra vez: evidencia, no simple opinión) se midió subdominio por subdominio de "free"desktop con "curl -sI". Resultado:

- gstreamer.freedesktop.org → 503. Anubis. "Doble paria" confirmado.
- www.freedesktop.org → 200 OK
- dbus.freedesktop.org → 200 OK
- poppler.freedesktop.org → 200 OK
- xorg, xcb, dri, mesa, gitlab → 200 OK

Conclusión probada con datos: de todo el universo "free"desktop, el único con Anubis era gstreamer. La implementación se supone fragmentada y sin criterio unificado, en donde cada subproyecto administra su subdominio y mete proof-of-work por su cuenta cuando le explota el problema, rompiendo la descarga de fuentes área por área. Hoy fue gstreamer, seguramente mañana sea otro, o todo. No es teoría, insisto: se midió.

La odisea de mirrors que siguió (un pantano documentado, peor que el de "Born on the Bayou").

- MacPorts → versión atrasada.
- kernel.org → 404 en su mirror de Gentoo para el tarball de gstreamer. 

Como ves, kernel.org tampoco se salva: no por Anubis, sino porque corta descargas largas - los hoy 620 MB de linux-firmware- y devuelve 404 en su vista de distfiles.
- Gentoo raíz y Gentoo por hash del nombre → 404 (utiliza otra convención de layout).

GitHub (monorepo oficial de GStreamer) → rechazado: es un repo de 38 MB con bindings de Python (2) que el Pkgfile de CRUX no espera, y rompe compilando "py3cairo.h".

Surge un pensamiento en medio del cerco: "nos están rodeando los cacos, hay que rajar de acá".

La salida: ¡Fossies.org! (https://fossies.org/linux/misc/), que espeja los tarballs de release oficiales, idénticos a los de "free"desktop (mismo md5sum, sin necesidad de "-im"/"-is"). Confirmado para gstreamer y gst-plugins-base 1.28.6. El mecanismo "rescatar_de_fossies" intenta primero a "free"desktop -exponiendo su fallo ante el usuario, con toda intención- y solo entonces cae a "Fossies". ¿Querés salir de esa lista, "free"desktop? Entonces involucrate como corresponde: dejá de hacerle los mandados a quienes generan el conflicto (Gnome, ¿te suena?) y sé equilibrado, que para eso estás ahí. Es lo que menos hacés: empezá a pensar primero en los usuarios y después en las corporaciones y los grupitos de amigos.

Decisión de arquitectura #4, y es de principios: no mezclar a "free"desktop en tándem con gente seria y verdaderamente preocupada. O freedesktop queda afuera al 100%, o queda primero exponiéndose cada vez que falle por su propia mediocridad y mala leche, y los serios (MIT, Fossies) entran solo a rescatar. No como equivalentes. El criterio ético trasladado a la arquitectura del código. Cuando además de técnicos somos militantes, y encima honestos, estas cosas pasan. "Comprendanlón".

18 al 22 de agosto y contando: DRIVERS Y BLOBS: la epopeya del kernel de red.

Se abre un nuevo hilo de investigación: "DRIVERS Y BLOBS!". El problema más grande y más colectivo de toda la travesía: CRUX no veía ninguna tarjeta de red en bare metal. Nunca. En ninguna máquina. ¿Cómo podía ser? Los compañeros de Entropía reportaban lo mismo en "bare metal", mientras que en VirtualBox le funcionaba bien la red a todo el mundo. Creo que lo mismo sucedía con el video, pero, honestamente, a esto no lo recuerdo bien.

El encuadre que lo cambió todo (acierto importante #4): no era la máquina de nadie en particular. Era el instalador produciendo sistemas sin red de forma sistemática y reproducible. Los datos, aportados por la comunidad de Telegram:

- En VBox siempre hay red (caso trivial, NIC emulado).
- En bare metal, NUNCA: 3 máquinas distintas, 3 chips distintos, 3 personas distintas (un compañero con Gentoo, otro con Arch, otro con 2 con Void en 2 máquinas diferentes).
- El mismo hardware funcionaba perfectamente con otras distros, pero en CRUX, incluso un adaptador Ethernet USB-C tampoco aparecía en el "ip address show".

Si fueran drivers puntuales faltando por casualidad, sería una combinación de mala racha y mala suerte imposibles. El denominador común no era un driver: era algo transversal a toda la pila de red. La hipótesis: un ".config" de kernel castrado (probablemente por un "localmodconfig" corrido en MV, que eliminaba todo driver no cargado en ese momento).

El clímax técnico — el eslabón fantasma RFKILL: tras varios ciclos de depuración en frío, la causa raíz resultó ser que "CONFIG_RFKILL=m" capaba a toda la pila WiFi. Como "CFG80211" y "MAC80211" dependen de "RFKILL", tenerlo en módulo arrastraba la cadena entera a módulo, y en cascada descartaba a todos los drivers WiFi de manera pareja. Nunca había sido tocado eso. Era el símbolo que nadie era capaz de ver.

La metodología que lo encontró fue el "dry-run", el ensayo en seco: en vez de compilar 45 minutos a ciegas, se forzaban los símbolos en un ".config" de prueba, se corría "make olddefconfig < /dev/null", y se "grepeaba" el resultado. En un ratito se veía si la cadena quedaba "built-in" o si se degradaba, sin quemar tiempo en toda una pesada compilación completa para averiguarlo.
Ahora bien, seamos honestos sobre cómo se llega a una solución así... No se trata de experiencia en esto, ya que no es el caso del autor de este artículo. Se llega por desesperación: cuando estás a punto de darle un piñazo al monitor y atravesarlo de lado a lado del estrés acumulado... con suerte.

La solución -el patrón "forzar_simbolos"-: forzar la cadena de dependencias de abajo hacia arriba ("RFKILL" primero, después "CFG80211"/"MAC80211" como "=y", Ethernet como "=y", drivers WiFi como "=m"), y recién después "olddefconfig" (que resuelve sin degradar lo ya configurado y establecido). Este patrón se replicó para "forzar_simbolos_video" y "forzar_simbolos_entrada".

El timing de firmware (una sutileza fina): los drivers de almacenamiento y Ethernet van built-in ("=y") porque casi no dependen de programa externo del dispositivo. Pero el WiFi va modular ("=m") a propósito. Si fuera built-in, inicializaría tan temprano que "/lib/firmware" todavía no estaría montado, y pediría su firmware con error -2 (ENOENT) aunque el archivo esté ahí, en el disco. Al ser de naturaleza modular, en cambio, carga después de montar la raíz: encuentra su firmware, y recién entonces levanta la interfaz.
Todo esto, por supuesto, no fue fácil, ni intuitivo, ni evidente, sobre todo para alguien que al iniciar todo este proyecto no tenía la menor experiencia aceptable en compilación ni en kernels. Así se aprende: a los golpes, en las peores batallas, que son las únicas que enseñan a lo grande.

Contribución de la comunidad: se agradece a Nico Vasconi y Miguel González, que hacían ronda de mate desde 2 orillas distintas del mismo río mientras ayudaban a pensar esto: quedaron grabados en los comentarios del propio código. Maxi Rica sacaba los mejores turrones españoles del horno, mientras Henry Jones y otros participaron de un filoso y atinado diagnóstico grupal, asado mediante, por Telegram. Nolberto empezó a preparar las arepas en cuanto entramos de lleno en su terreno: los Window Managers. Esto no fue una comilona de un hombre degustando y una máquina tragando tornillos aceitados solamente, fue de un hombre, una máquina, y una comunidad que le puso el hombro al binomio sin entrar en la pavada.

Pero, no todo es color de rosa... Acá empezaron los sub-problemas.

Cuando se estaba redondeando la base... el touchpad (trackpad) de la Acer no era visible al kernel por faltar "CONFIG_I2C_HID_ACPI" y "CONFIG_HID_MULTITOUCH".
"I2C_HID" era el contenedor cuya ausencia como "=m" impedía (en cascada) que "I2C_HID_ACPI=y". Confirmado por dry-run (en seco, como buen "tatequiéto").

El video (subproblema): en el hardware real, el amdgpu (para la GPU AMD Barcelo) faltaba del kernel config activo. Tras recompilar, la GPU levantó y "/dev/dri" apareció.

Pero en esta travesía hubo espacio hasta para la metalingüística. Me refiero a la cuestión terminológica del término "blob", que fue corregida por el excelentísimo "Dr. en Ciencias del Rompepelotismo", Prof. Hugo Napoli, quien rechazó una vez más, abiertamente y con fundamento, el uso de vocabulario técnico incorrecto -en este caso, el del término "blob" para el firmware-.

El planteo parte de un esquema clásico:

Hardware: pieza eléctrica/electromecánica.
Software: programas.
Firmware: hardware con software.

Y el problema es este: la industria estiró el término "firmware" hasta hacerlo reventar. Dejó de grabar el programa en un chip de la placa (en donde estaría "firme") y desde hace años pasó a cargarlo desde un archivo suelto en "/lib/firmware" en cada arranque… pero le siguió diciendo "firmware" igual. Es un nombre heredado, mal puesto -lo mismo que decir "disco SSD"-. La formulación precisa que debería adoptarse es "programa de dispositivo": software de fuente cerrada que corre dentro del chip de la placa, no en la CPU, y que el controlador le inyecta al arrancar.

Dicho en criollo, y para que no queden dudas del temperamento con que se defiende esto, se cita textual al Dr. (sic):

"A mí no me vengá' con cosa' rara': o e' járguar, o e' sójguar, o e' fírguer. Y si e' otra cosa, lo arreglamo' afuera. Ningún bló de járguar, ¿m'entendé?"

O, como dice mi amigo Sergio Arce:

Acá no vengá' a jodé'.

Y no es una manía aislada, es la misma bronca de fondo que la del fraude de GiB (qué nombre más estúpido e intelectualoide de quinta) frente a GB, usado para robarle a la gente inflando cifras. Misma familia de abusos: llamar mal a las cosas para justificar la impunidad. Por eso Realtek y NVIDIA se llevaron una puteada explícita, y con razón: entregan hardware que no anda, en cajas negras inauditables.

23 de agosto - InstaBox: una de las últimas piezas del "Moon Cresta".

https://codeberg.org/entropiabinaria/InstaBox

Hilos "Etapa SOLO openbox (constructo)" y "Etapa SOLO openbox (pulido)". InstaBox representó al acople gráfico final, aunque no terminó siendo el último, al instalar openbox + tint2 + feh + dunst sobre el CRUX ya sólido. Corre como root, instala dependencias (imlib2 con "-if" por un footprint mismatch conocido de los loaders jpeg/svg/tiff), detecta usuarios "humanos" (UID ≥ 1000, sesión real), y se "baja" al usuario elegido con "su - usuario -c" para desplegar ".xinitrc" y fondos.

La ocurrencia que, muy tarde, cambió el ritmo de todo: SSH.

Durante semanas se había trabajado con la MV, sacando fotos de la pantalla con el teléfono y pasándoselas a Gemini para hacer OCR, porque no se contaba con posibilidad de copiar y pegar, ni con red. A mitad de este hilo se estableció el acceso por SSH a la MV y a la laptop física. con reacción registrada al pie. Cito, textual:

"Soy profesor de REDES... ¡REDES! Y no consideré JAMÁS usar SSH para proyectos como este... ¡Soy un PELOTUDO! Pero, ¿en qué carajos estaba pensando?"

Lo que sucede, y me gusta pensarlo así para no tener que autoflagelarme con un cable UTP: utilizar SSH todos los días para enseñarlo, no es lo mismo que aplicarlo a un proyecto puntual. Estás en otra cosa, venís como pájaro al que le abren la jaula: sabés que "no se puede salir" y por más que te abran la puerta, ni se te pasa por la cabeza hacerlo. Es un punto ciego, quizás, no una incapacidad. Pero el cambio fue enorme: se acabó "el parto de la isla" mucho después de haberse logrado la conectividad. A partir de ahí todo fluyó con una velocidad enorme y un estrés "galopante pero en bajada p'abajo, ¿vio?".

Verificaciones de esta etapa: se contrastó todo el stack gráfico contra el árbol de ports real de CRUX 3.8, y aparecieron varios hallazgos. Picom no estaba en el catálogo. Tampoco había ningún gestor de archivos gráfico en las colecciones oficiales: PCManFM arrastra medio LXDE, y xfe pide a "FOX toolkit", que está ausente, así que el gestor de archivos quedó diferido a una futura v2... si llega. Veremos. Y Tint2, que ya había aparecido en contrib con un parche glib, volvió obsoleto al port de Tint2 que se había pretendido armar.

Todo esto en medio de un delirio constante: la búsqueda a los tumbos de soluciones de débiles humanos para problemas de titanes.

El 23 de agosto aún habían quedado pendientes: el fondo de feh pisado por el gris default de openbox-session (menos de 1 segundo después), y la fase 2 de applets de bandeja (volumen, nm-applet, blueman). Finalmente, ante un humano estupefacto, el cuerpo de InstaBox queda diseñado y la pieza logra verse en pantalla: X arranca, openbox corre, el menú contextual anda, Firefox abre y reproduce video... pero no sonido, no te afilé'. No te vistá' que no va'. No te pinté' lo' labio' que la foto es en blanquinegro.

ACTA DE RESPONSABILIDADES AJENAS.

Registro de miserias y mediocridades estructurales evitables. Es, sí, en gran parte, desahogo, pero cada punto está verificado. El criterio de "labración" del acta: la falla burda y evitable, con nombre, sin importar "genio" ni figura.

1. "free"desktop.org: Anubis fragmentado y con un criterio anticomunitario.

Falla concreta y medida: implementaron proof-of-work (Anubis) en "gstreamer.freedesktop.org", rompiendo la descarga de fuentes vía curl, pkgmk, etc., con "HTTP 503" (servidor saturado de tráfico), mientras el resto de sus subdominios (dbus, poppler, xorg, xcb, dri, mesa) siguen en 200 (éxito). Es una implementación por áreas, descoordinada, que va minando y resquebrajando a la infraestructura de fuentes de a pedazos. Claro... Esto, viéndolo desde afuera, porque desde adentro, la autocomplacencia y las palmadas en la propia espalda son un gran indicador del "vamos bien" y del "hicimos lo correcto". Un servidor que se supone abierto, libre y central para "medio ecosistema Linux" (por no exagerar), administrado por gente que otrora se ganó un merecido renombre por ser una agrupación orientadora en cuanto a qué ingredientes poner en las recetas de las interfases, pero que hoy se dedica más a militar posturas por sobre lo técnico que a sostener una infraestructura democrática -nunca mejor colocado este concepto-, habiendo dejado de mostrar un claro y desintoxicado camino a seguir, y no presentando criterio unificado en temas realmente excluyentes.
Esto fue medido con curl, subdominio por subdominio. No es solo una opinión. Son también -y esto es lo más importante-, hechos.

You left me standing here... A long, long time ago...

2. La kernel.org tampoco se salva.

Falla concreta: corte sistemático de descargas largas (los más de 620 MB de linux-firmware) dejándolas a medias, y su vista de distfiles de Gentoo devuelve 404 para tarballs que deberían estar. No es malicia como Anubis, es desprolijidad de infraestructura en un servidor que se presenta como confiable y peor aún, como bastión elegido por la comunidad.

3. La documentación que empuja al error.

Falla concreta: la documentación oficial (incluido material de referencia como Linux From Scratch) advierte que poner "DRM_AMDGPU", "DRM_RADEON" y similares como "=y" "no es recomendado", pero no explica con claridad el porqué -el problema del timing de firmware-. Así, al que compila sin initramfs lo deja tropezar solo con el error -2. Y ese error despista: ante semejante fallo, uno imaginaría que el kernel se quedó sin memoria, o que el archivo empaquetado es más grande que el espacio disponible, o... cualquier cosa, excepto la de la verdadera causa. La otra trampa, la de "scripts/config --set-val" (que no resuelve el árbol de dependencias, y que "olddefconfig" después degrada) tampoco está documentada de forma que un humano pueda esquivarla antes de venírsele encima la curva de la muerte. Para desenredar este tipo de cosa es que hace falta una máquina.

4. Los Pkgfile escritos asumiendo un único escenario.

Falla concreta: el port de Rust asume el "pkgmk.conf" por defecto de CRUX (con "JOBS" / "MAKEFLAGS" comentados) y utiliza "-j ${JOBS}" sin defensa alguna ante una "JOBS" vacía. Quien active el paralelismo por el camino "natural" (MAKEFLAGS) sin saber del "JOBS" oculto, choca con un error críptico. No hay validación ni mensaje útil. ¿Por qué? Porque no están en esto, porque no saben de esto: están en RUST. Saben de RUST. Y así nos van limando, redondeando, a imagen y semejanza de otros, perdiéndose, en ese detestable camino, identidad, volviéndonos grises.

5. La deriva de proyectos "libres" financiados "férreamente" desde arriba.

Este, sin duda, es, el hilo conductor de toda el acta. Las trabas más grandes no vinieron de la falta de recursos, sino de exceso de recursos mal administrados, infraestructura sostenida por fundaciones y empresas (el ecosistema alrededor de Canonical / Red Hat / IBM) que toma decisiones unilaterales (Anubis, layouts de mirror, políticas) que cagan a medio pueblo sin consultar ni avisar al pueblo. El contraste es el punto entero de esta crónica.

EL OTRO LADO DEL ACTA: EL ESFUERZO GENUINO (AJENO Y PROPIO).

Frente a cada traba estructural, colosal, mediocre por definición de poder, la respuesta fue de gente con infraestructura pequeña que puso el cerebro y el cuerpo como para lograr soluciones 20 veces más poderosas que los que son 20.000 veces más poderosos.

- CRUX mismo.

Tim Biermann y Matt Housh sostienen a una distro entera, a sus paquetes, a MATE, y a la ISO "Updated", con una fracción de los recursos de las grandes. Cuando el proyecto choca contra un límite, es por falta de recursos, no por arrogancia desde el abulonamiento y/o la corrupción y/o traición imperdonable de valores puros a nivel comunitario y del software libre.

- La comunidad de Entropía binaria.

Maxi, "Henry Jones", Nicolás Vasconi, Miguel González, "Nólbert" y otros compañeros, diagnosticando por Telegram en máquinas, sistemas y entornos distintos, sin hacer alarde, por el gusto de aportar genuinamente y de que la cosa funcione. Sus nombres quedaron en los comentarios del código, además de acá, pero son los que quedan en el "cuore".

- Un docente uruguayo, casi solo, en 1 mes de laburo, peleando contra sus propias miserias, inseguridades, poniendo sus fortalezas a tope, utilizando las tecnologías más a mano, valiéndose de recursos dignos de un McGyver en serio, conectando máquinas por SSH, negándose a bajar el estándar aunque el agotamiento y la bronca hubiesen rebasado límites mucho más allá de lo tolerable, leyendo cada información "de por ahí", cada respuesta de IA, milimétricamente, militarmente, religiosamente, posesamente, en vez de copiar y pegar y hacerlo más fácil, más rápido, menos estresante y frustrante, pero también más irresponsable y menos pedagógico. A los valores no se les traiciona. A las personas tampoco.

Don't keep me waiting here...

La asimetría no es de talento ni de ganas, es de recursos, de poder y de pureza mental. Y esta es exactamente la denuncia que sostiene todo este proyecto.

A los atornillados y abulonados a su cargo y posición, a los "grandes", a los que "hostean recursos": háganse cargo de lo que realmente vean que van a poder dominar, hagan bien su laburo, no prometan nada que no sean capaces de defender con la misma determinación y vehemencia de los exabruptos dichos. No borren con el codo lo que escriben con la mano, no hagan más mandados para nadie.

Esta crónica es un esqueleto cambiante, un esbozo, un garabato inmaduro. Cada sección seguramente termine expandiéndose, siendo retocada. El "Acta" y el "Esfuerzo Genuino" son las 2 columnas editoriales que le dan alma.
El villano no es CRUX, no es DeVUAn, no es Artix: es la infraestructura "libre" mal gestionada. El héroe colectivo es todo el conjunto de gente no vendida a las corporaciones ni a entregada a sus productos, que pone amor genuino, sin personalismos ni egos rotos, y con los recursos honestamente posibles.

Situación hoy, pasado el 23 de agosto.

Ya existe "InstaMate.sh", un script totalmente funcional para instalar al escritorio "Mate" de manera automatizada.

https://codeberg.org/entropiabinaria/InstaMate

Se está trabajando cuidadosamente en "TtyLog.sh", una pantalla de login BASH para tty, para que no haya que iniciar con pantalla negra, autenticarse por tty y levantar al entorno gráfico manualmente (startx).

https://codeberg.org/entropiabinaria/TtyLog

CRUX es totalmente funcional. Se puede instalar utilizando los instaladores de Entropía binaria en cascada y terminás con un CRUX con Mate o con OpenBox.
También con red, sonido y todos los chiches. 

NOTAS AL PIE:

(1) El e-mail fue a parar a una migración general a Thunderbird de todos mis correos desde 2007 hasta ahora: al estar ahí y no estar más en GMail (eliminé todo para empezar desde cero), ese mensaje de Tim que explicaba cómo prescindir de rEFInd quedó respaldado, y debido a mis prácticas con CRUX, aún no reinstalé a Thunderbird ni le hice releer la millonada de mensajes en "backup". De ahí que tuviera que reconstruir el método del arranque por EFI Stub desde cero.

(2) Sobre por qué Python es un problema técnico concreto y no un capricho ni una postura filosófica, lo desarrollé aparte, en detalle y con ejemplos, acá: https://entropiabinaria.blogspot.com/2026/08/el-por-que-de-mi-rechazo-tecnico.html

(3) Sobre las NTI, podés leer el artículo completo acá:
https://entropiabinaria.blogspot.com/2026/01/nuevas-tecnologias-innecesarias-un.html