DEV Community: lu1tr0n

D2 libera TALA, su algoritmo de autolayout, bajo licencia MPL-2.0

lu1tr0n — Tue, 08 Sep 2026 08:28:37 +0000

Terrastruct acaba de liberar el código fuente de TALA, el algoritmo de autolayout que usa D2 para acomodar diagramas de arquitectura sin que nadie mueva cajas a mano. Ahora corre bajo licencia MPL-2.0, la misma que D2, y ya viene incluido de fábrica desde la versión 0.9.0 del lenguaje.

Hasta ahora TALA era la pieza propietaria de un proyecto por lo demás abierto. Con este anuncio, D2 queda completamente open source de punta a punta: del parser al renderizado final.

TL;DR

TALA (Terrastruct's AutoLayout Algorithm) es ahora open source bajo licencia MPL-2.0, la misma que D2.- Viene incluido en D2 desde la versión 0.9.0 y se activa con el flag --layout=tala.- Es un motor de layout ortogonal pensado para diagramas de arquitectura tipo pizarra, no para grafos DAG largos.- Permite fijar coordenadas top y left en nodos específicos y dejar el resto al motor automático (posicionamiento híbrido).- Usa 3 semillas aleatorias por defecto y elige el layout con mejor puntaje: mismo input y semillas producen el mismo diagrama.- El playground https://play.d2lang.com corre 100% en el navegador y permite probar TALA sin instalar nada.- El repositorio de benchmarks de rendimiento está publicado en github.com/d2lang/d2-benchmarks.- Gavin Nishizawa y Júlio César Batista lideraron buena parte del desarrollo, según el anuncio oficial de Terrastruct.

Introducción

D2 es un lenguaje de diagramación por texto: escribís unas líneas describiendo cajas y flechas, y D2 genera el SVG. La competencia directa es Mermaid, pero D2 se diferenció desde el principio por la calidad visual de sus layouts automáticos.

Esa calidad venía en gran parte de TALA, un motor de autolayout que Terrastruct desarrolló puertas adentro y mantuvo cerrado mientras el resto de D2 ya era MIT. Eso cambió esta semana.

Qué pasó

Terrastruct publicó el código de TALA en el mismo repositorio de D2 en GitHub, bajo licencia Mozilla Public License 2.0. Es la continuación de un anuncio previo donde la empresa ya había adelantado que esto venía.

El repositorio explica que TALA combina ideas de varios papers de graph drawing (citados directamente en el código fuente) con técnicas propias para lograr diagramas más legibles. El objetivo declarado es optimizar varias métricas de "estética" a la vez: simetría, distancia mediana entre nodos conectados, dirección del flujo y agrupamiento de nodos similares.

Terrastruct agradece explícitamente a Gavin Nishizawa por contribuciones amplias a TALA y a Júlio César Batista por su trabajo en los algoritmos de jerarquía. El proyecto pasa ahora a aceptar contribuciones externas de la comunidad de D2.

Contexto e historia

D2 ya incluía dos motores de layout desde el principio: Dagre y ELK, ambos basados en grafos dirigidos acíclicos (DAG). Funcionan bien para diagramas que crecen en una dirección: pipelines, flujos de datos, árboles de dependencias.

El problema es que un diagrama de arquitectura de software real casi nunca crece en una sola dirección. Se parece más a lo que dibujarías en un pizarrón: cajas por todos lados, conexiones que cruzan en varios sentidos. Para ese caso, Terrastruct construyó TALA como motor de layout ortogonal, diseñado desde cero pensando en software architecture diagrams.
TALA prioriza simetría y clustering; Dagre y ELK priorizan dirección de flujo.
Terrastruct probó TALA contra archivos D2 públicos tomados de GitHub, sin selección manual. La empresa aclara que en algunos casos el layout de Dagre o ELK puede seguir siendo preferible: no es que TALA gane siempre, es que ataca un problema distinto.

Detalles técnicos y rendimiento

TALA no produce un único layout determinista por diagrama. Por defecto prueba 3 semillas aleatorias, genera un layout candidato por cada una, les asigna un puntaje según las métricas de estética mencionadas arriba, y se queda con el mejor. Mismo input y mismas semillas producen siempre el mismo resultado.

El punto incómodo: agregar un solo nodo puede cambiar por completo la disposición del diagrama, porque las semillas exploran el espacio de soluciones de nuevo. Dagre y ELK, en cambio, tienden a mantener el layout previo y solo acomodar el nodo nuevo en su lugar.

⚠️ Ojo: si necesitás que un diagrama grande mantenga su forma estable a medida que le agregás nodos con el tiempo (por ejemplo, documentación que se actualiza seguido), Dagre o ELK son más predecibles que TALA.

Otra capacidad exclusiva de TALA es fijar la posición de nodos individuales con las claves top y left, dejando que el motor resuelva el resto (incluido el routing de las conexiones). Terrastruct señala un uso concreto: modelos de IA generativa pueden ubicar cajas razonablemente bien en un plano 2D, pero fallan al trazar las líneas que las conectan sin que se crucen. TALA resuelve justo esa segunda parte.
MotorCuándo usarloVentajaLimitaciónDagrePipelines, flujos CI/CD, grafos que crecen en una direcciónLayout estable al agregar nodos nuevosPoco control estético en diagramas no linealesELKJerarquías grandes con muchos niveles anidadosBuen manejo de subgrafos jerárquicosPrioriza dirección sobre estética tipo pizarraTALADiagramas de arquitectura con conexiones cruzadasOptimiza simetría, clustering y permite fijar coordenadasAleatoriedad entre ejecuciones; más lento en diagramas grandes
Sobre rendimiento, Terrastruct es honesto: TALA escala de forma no lineal y tarda más que Dagre o ELK en diagramas grandes. El benchmark de referencia está publicado en github.com/d2lang/d2-benchmarks, donde cualquiera puede correr sus propias mediciones contra su hardware.

Cómo empezar

TALA no se instala aparte: viene empaquetado dentro de D2 desde la versión 0.9.0. Basta con instalar D2 y pasar el flag correspondiente.

# macOS (Homebrew)
brew install d2

# Linux
curl -fsSL https://d2lang.com/install.sh | sh -s --

# Windows (con Scoop)
scoop install d2

Con D2 instalado, un diagrama mínimo se ve así. Guardalo como arquitectura.d2:

frontend -> api_gateway: peticion HTTP
api_gateway -> auth_service: valida token
api_gateway -> orders_service: crea orden
orders_service -> database: INSERT
orders_service -> cache: invalida clave

Y para renderizarlo usando TALA en vez del motor por defecto:

d2 --layout=tala arquitectura.d2 arquitectura.svg

Este comando genera arquitectura.svg con el layout ortogonal de TALA, en lugar del Dagre por defecto. Para el posicionamiento híbrido (algunos nodos fijos, el resto automático), D2 admite fijar coordenadas directamente en el nodo:

estacion_cyan: {
  top: 0
  left: 0
}
estacion_magenta: {
  top: 0
  left: 200
}
estacion_amarillo: {
  top: 0
  left: 400
}
estacion_negro: {
  top: 0
  left: 600
}
controlador_registro -> estacion_cyan
controlador_registro -> estacion_magenta
controlador_registro -> estacion_amarillo
controlador_registro -> estacion_negro

Fijar top y left en algunos nodos deja el routing en manos de TALA.
Acá los cuatro nodos superiores quedan clavados en su fila, mientras que TALA calcula solo el trazado de las conexiones hacia el controlador. Es exactamente el patrón que Terrastruct describe para diagramas generados por agentes de IA.

Para confirmar que tu instalación efectivamente usa TALA (y no cae de nuevo a Dagre por versión vieja), revisá la versión de D2 antes de renderizar:

d2 --version
# debe reportar 0.9.0 o superior

Si el binario reporta una versión anterior a 0.9.0, el flag --layout=tala no existe todavía y hay que actualizar D2 primero.

💡 Tip: si querés probar TALA sin instalar nada, el playground play.d2lang.com corre el compilador completo en el navegador, incluido TALA.

Impacto y análisis

El cambio más relevante no es de licencia sino de mantenimiento: hasta ahora, cualquier bug o mejora en TALA dependía exclusivamente del equipo de Terrastruct. Con el código abierto, la comunidad de D2 puede enviar pull requests directamente sobre el motor de layout, algo que antes era imposible.

También reduce el riesgo típico de las herramientas con núcleo propietario: si Terrastruct como empresa cambiara de rumbo, D2 ya no dependería de una pieza cerrada para su funcionalidad más distintiva. Es el mismo argumento que sostuvo la migración completa de proyectos como herramientas de código abierto en general: menos punto único de fallo organizacional.

El caso de uso agéntico que menciona Terrastruct merece atención aparte. A medida que más equipos generan diagramas de arquitectura con asistentes de IA a partir de una descripción en texto, la parte difícil deja de ser "dónde poner cada caja" y pasa a ser "cómo trazar las conexiones sin que se crucen". TALA ataca justamente ese segundo problema, dejando la ubicación gruesa en manos del modelo y el routing fino en manos del algoritmo.

Qué sigue

Terrastruct dice esperar con interés las mejoras que la comunidad proponga ahora que el código es público, en particular sobre el manejo de diagramas grandes, donde el rendimiento no lineal de TALA sigue siendo su punto más débil frente a Dagre y ELK.

No hay un roadmap con fechas públicas más allá de eso. La vía más directa para seguir el desarrollo es el propio repositorio de D2 en GitHub, donde TALA ahora vive junto al resto del compilador.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instalá D2 con brew install d2 (o el script de Linux) y corré tu primer diagrama con d2 --layout=tala para comparar el resultado contra Dagre.

Preguntas frecuentes

¿Qué significa TALA?

Son las siglas de Terrastruct's AutoLayout Algorithm, el motor de layout ortogonal que Terrastruct construyó para D2.

¿Necesito instalar TALA por separado?

No. Viene incluido dentro de D2 desde la versión 0.9.0 y se activa con el flag --layout=tala.

¿TALA reemplaza a Dagre y ELK?

No. D2 sigue soportando los tres motores. TALA conviene para diagramas de arquitectura con conexiones cruzadas; Dagre y ELK siguen siendo mejores para grafos que crecen en una sola dirección.

¿Por qué el mismo diagrama se ve distinto cada vez que agrego un nodo?

Porque TALA prueba 3 semillas aleatorias por defecto y elige la de mejor puntaje. Agregar un nodo cambia el espacio de búsqueda y puede producir un layout completamente distinto.

¿Sirve TALA para diagramas generados por IA?

Sí, es uno de los casos de uso que Terrastruct destaca: un modelo puede ubicar nodos en coordenadas 2D y dejar que TALA resuelva el routing de las conexiones, tarea en la que los modelos suelen fallar.

¿Bajo qué licencia quedó TALA?

MPL-2.0, la misma licencia que ya usaba el resto de D2.

Referencias

Anuncio oficial de Terrastruct: publicación original donde se confirma la apertura del código de TALA.- Repositorio de D2 en GitHub: código fuente completo del lenguaje y de TALA.- d2-benchmarks: comparativas de rendimiento entre TALA, Dagre y ELK.- D2 Playground: entorno para probar D2 y TALA sin instalar nada, corre 100% en el navegador.- Mozilla Public License 2.0: texto completo de la licencia bajo la que se liberó TALA.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

CADO-NFS factoriza una clave RSA de 512 bits de una CA de 1999

lu1tr0n — Tue, 08 Sep 2026 02:30:31 +0000

Un investigador reconstruyó en su propio escritorio la clave privada RSA de 512 bits de una autoridad certificadora real: una que Netscape 4.51 marcó como confiable para SSL en marzo de 1999. El hallazgo no pone en riesgo a nadie hoy, porque esa raíz expiró en 2003 y fue retirada de los navegadores en 2002.

Pero el experimento pone números concretos sobre la mesa: cuántas horas de cómputo hacen falta hoy para romper lo que hace 25 años se consideraba seguro. La respuesta, en este caso, cabe en un fin de semana largo con un solo procesador de escritorio.

TL;DR

Matthew McPherrin factorizó dos claves RSA de 512 bits de la CA canadiense E-Certify, confiable en Netscape 4.51 desde marzo de 1999.- Usó CADO-NFS en un Ryzen 9 5950X: 32 horas para la clave "Gold Server" (SSL) y 29 horas para "Gold Client" (S/MIME).- La RSA-155, también de 512 bits, ya había sido factorizada en 1999, el mismo año en que Netscape emitió estas raíces.- Netscape retiró las raíces de E-Certify en 2002; el certificado expiró el 16 de octubre de 2003.- Internet Explorer nunca distribuyó raíces SSL de 512 bits, así que el experimento queda limitado a esa ventana de Netscape.- McPherrin publicó las claves privadas, los certificados y el código en GitHub, en mcpherrinm/ancientroots.- Para verificarlo montó un servidor TLS a medida en Go, publicado en e-certify.fly.dev, compatible solo con Netscape 4.51.- Las raíces se hallaron extrayendo certificados de instaladores históricos archivados, con ayuda de Claude Code.

Qué pasó

El 7 de septiembre de 2026, el desarrollador Matthew McPherrin publicó en su blog personal el relato completo de cómo factorizó las claves RSA de una autoridad certificadora real de los años noventa. Todo empezó con una pregunta simple: ¿existe algún certificado raíz lo bastante débil como para romperlo con una computadora de escritorio actual?

Para responderla, descargó los instaladores históricos de Netscape e Internet Explorer alojados en el Internet Archive y usó Claude Code para extraer de forma automática todas las raíces incluidas en cada versión, publicando el resultado en una página web filtrable. Buscando por tamaño de clave encontró el objetivo: en marzo de 1999, Netscape 4.51 distribuyó dos certificados raíz de 512 bits de la desaparecida autoridad canadiense E-Certify, uno habilitado para SSL ("Gold Server") y otro para S/MIME ("Gold Client").

Internet Explorer, en cambio, nunca llegó a incluir raíces de 512 bits para SSL, así que la ventana de este experimento quedó acotada a una etapa muy específica de Netscape entre 1999 y 2002.

El siguiente diagrama resume el proceso completo, desde la extracción de las raíces archivadas hasta la carga de una página firmada por la clave reconstruida en el navegador original de 1999:

flowchart TD
A["Instaladores archivados de Netscape e IE"] --> B["Extraccion de raices con Claude Code"]
B --> C["Filtro: certificados RSA de 512 bits"]
C --> D["CADO-NFS factoriza el modulo"]
D --> E["Reconstruccion de la clave privada"]
E --> F["Emision de un certificado firmado"]
F --> G[("Servidor TLS a medida en Go")]
G --> H["Netscape 4.51 carga la pagina"]

Contexto e historia

La seguridad de RSA depende de que factorizar un número semiprimo grande sea computacionalmente costoso, pero qué tan grande debe ser esa clave cambia con el tiempo. En 1999, el mismo año en que Netscape emitía las raíces de E-Certify, un equipo internacional ya había factorizado RSA-155, un semiprimo de 512 bits del RSA Factoring Challenge. Es decir: la clave que Netscape marcó como confiable para cifrar tráfico ya era, en teoría, insegura desde su nacimiento.

El límite sigue subiendo con el tiempo. Hace apenas unos días, alguien completó la factorización de RSA-260, un semiprimo de 862 bits y la mayor factorización pública conocida hasta ahora. El Web PKI, el sistema de confianza que usan los navegadores, dejó de aceptar claves RSA de 1024 bits hace más de una década. Hoy el estándar mínimo son 2048 bits, aunque ese tamaño también tiene fecha de vencimiento ante la eventual llegada de computadoras cuánticas capaces de correr el algoritmo de Shor.

Ese contexto histórico importa para entender por qué existía siquiera una raíz de 512 bits en 1999: Netscape lanzó soporte para SSL en 1994, en plena era de restricciones de exportación de criptografía impuestas por Estados Unidos, cuando la industria todavía no tenía estándares mínimos de tamaño de clave para autoridades certificadoras.
En 1999, 512 bits ya no alcanzaba: RSA-155 cayó ese mismo año.

Detalles técnicos: cómo se factorizó la RSA de 512 bits

Para reconstruir la clave privada a partir de la pública, McPherrin corrió CADO-NFS, una implementación open source de la criba general del cuerpo de números (GNFS), el algoritmo clásico para factorizar semiprimos grandes. El proceso consta de varias fases: selección de polinomio, criba, filtrado de relaciones, álgebra lineal y raíz cuadrada final. Para un módulo de 512 bits, la fase de criba es la que más tiempo consume en hardware de escritorio.

El trabajo corrió en un Ryzen 9 5950X de escritorio, sin clúster ni GPU: 32 horas para factorizar la clave "E-Certify RSA 512 Gold Server" y 29 horas para "E-Certify RSA 512 Gold Client". La siguiente tabla ubica ese resultado dentro de la escala histórica de factorizaciones RSA conocidas:
ClaveTamañoEstadoTiempo o hitoRSA-155512 bitsFactorizada en 1999Esfuerzo distribuido internacionalE-Certify Gold Server512 bitsFactorizada en 202632 horas en un Ryzen 9 5950XE-Certify Gold Client512 bitsFactorizada en 202629 horas en un Ryzen 9 5950XRSA-260862 bitsFactorizada recientementeMayor factorización pública conocidaRSA de 1024 bits1024 bitsDeprecada por el Web PKISin factorización pública confirmadaRSA de 2048 bits2048 bitsEstándar mínimo actualVigente en certificados TLS modernos
Un ejemplo simplificado de cómo se invoca CADO-NFS sobre un número compuesto (un semiprimo de juguete para ilustrar la sintaxis, no la clave real):

./cado-nfs.py 2087213345157128459857544877488990849241708931948717
# la herramienta corre las fases de criba, filtrado y algebra lineal,
# y al final imprime los dos factores primos encontrados

Con el módulo público del certificado real el comando es el mismo, pero el número tiene 512 bits: la diferencia está en el tiempo de cómputo, no en el algoritmo. Para confirmar que una clave privada reconstruida corresponde de verdad al certificado público, se compara el módulo de ambos:

openssl x509 -noout -modulus -in e-certify-gold-server.pem | openssl md5
openssl rsa -noout -modulus -in e-certify-gold-server-key.pem | openssl md5
# si los dos hashes coinciden, la clave privada es valida para ese certificado

Cómo probarlo

McPherrin publicó las claves privadas, los certificados originales y las herramientas usadas en el repositorio github.com/mcpherrinm/ancientroots. Cualquiera con Netscape 4.51 corriendo en una máquina virtual con el reloj atrasado a antes de octubre de 2003 puede usarlas para emitir certificados y probarlos contra e-certify.fly.dev, un servidor TLS a medida escrito en Go que McPherrin tuvo que construir porque ningún stack TLS moderno comparte cifrados con ese navegador de 1999.

Para instalar CADO-NFS y reproducir la parte de factorización en tu propia máquina, usando un número más chico salvo que tengas varios días libres de CPU:

# Linux (Debian/Ubuntu)
sudo apt install build-essential cmake libgmp-dev
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && make

# macOS (Homebrew)
brew install cmake gmp
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && make

# Windows (via WSL2; CADO-NFS no tiene build nativo para Windows)
wsl --install -d Ubuntu
wsl
sudo apt install build-essential cmake libgmp-dev
git clone https://gitlab.inria.fr/cado-nfs/cado-nfs.git
cd cado-nfs && make

Impacto y análisis

El resultado no reabre ningún riesgo real: la raíz de E-Certify fue eliminada de Netscape en 2002 y el certificado expiró en 2003, así que ningún tráfico moderno depende de esa cadena de confianza. El valor del experimento está en otro lado: muestra, con horas y hardware concretos, la brecha entre lo que se consideraba seguro en 1999 y lo que exige hoy el Web PKI.

💭 Clave: el mismo año en que Netscape emitía una raíz de 512 bits, RSA-155, también de 512 bits, ya había caído. La debilidad no era un secreto técnico oculto: era pública desde el primer día.

El caso también ilustra cómo cambió la disponibilidad de herramientas de cómputo. En 1999, factorizar RSA-155 exigió un esfuerzo internacional distribuido entre varios grupos de investigación durante meses. En 2026, un desktop con un solo procesador Ryzen hizo el mismo trabajo, para una clave del mismo tamaño, en menos de un día y medio.
Un Ryzen 9 5950X de escritorio bastó: sin clústeres ni GPU dedicada.

⚠️ Ojo: replicar pruebas con stacks TLS antiguos, como el servidor a medida para Netscape 4.51, debe hacerse siempre en entornos aislados, nunca contra tráfico de producción o usuarios reales.

Para las autoridades certificadoras actuales, el mensaje de fondo es el mismo que exige hoy el CA/Browser Forum: el tamaño mínimo de clave no es una preferencia estética, es una fecha de vencimiento calculada según el poder de cómputo disponible en cada época.

Qué sigue

Según el propio McPherrin, el margen para repetir este experimento es angosto: Internet Explorer nunca distribuyó raíces SSL de 512 bits, así que la ventana queda limitada a esa etapa muy específica de Netscape entre 1999 y 2002. El catálogo de raíces antiguas que generó con Claude Code queda disponible igualmente, para que otros investigadores sigan buscando casos similares en instaladores de esa época.

En paralelo, la migración hacia criptografía poscuántica avanza por el mismo motivo que hizo caer a estas raíces de 512 bits: el poder de cómputo disponible solo crece. El NIST ya estandarizó ML-KEM (FIPS 203) como reemplazo de los esquemas de intercambio de claves basados en factorización y logaritmo discreto, anticipando el día en que una computadora cuántica suficientemente grande haga con RSA de 2048 bits lo que un Ryzen de escritorio ya hace hoy con 512 bits.

📖 Resumen en Telegram: Ver resumen

Probalo vos: cloná mcpherrinm/ancientroots y corré openssl x509 -noout -modulus sobre certificados viejos que tengas a mano para ver de qué tamaño de clave dependía tu propia navegación hace 25 años.

Preguntas frecuentes

¿Este hallazgo pone en riesgo la navegación actual?

No. La raíz de E-Certify fue retirada de Netscape en 2002 y el certificado expiró el 16 de octubre de 2003, así que ningún navegador moderno confía en ella.

¿Cuánto tardó la factorización?

32 horas para la clave "Gold Server" y 29 horas para "Gold Client", ambas de 512 bits, corriendo CADO-NFS en un Ryzen 9 5950X de escritorio.

¿Qué es CADO-NFS?

Es una implementación open source de la criba general del cuerpo de números (GNFS), el algoritmo estándar para factorizar semiprimos grandes como los módulos RSA.

¿Por qué una clave de 512 bits ya era débil en 1999?

Porque ese mismo año un equipo internacional factorizó RSA-155, otro semiprimo de 512 bits del RSA Factoring Challenge, demostrando en público que ese tamaño no alcanzaba.

¿Se puede reproducir el experimento?

Sí. Las claves privadas, los certificados originales y las herramientas están publicados en el repositorio de GitHub de McPherrin, junto con el servidor TLS a medida para probarlos con Netscape 4.51.

¿Qué tamaño de clave RSA se considera seguro hoy?

El mínimo aceptado por el Web PKI es de 2048 bits, aunque la migración hacia esquemas poscuánticos como ML-KEM ya está en marcha de cara al riesgo de las computadoras cuánticas.

Referencias

mcpherrin.ca: publicación original de Matthew McPherrin con el detalle completo del proceso de factorización.- github.com/mcpherrinm/ancientroots: repositorio con las claves privadas, certificados y herramientas usadas.- cado-nfs.gitlabpages.inria.fr: página oficial del proyecto CADO-NFS, la herramienta de factorización usada.- en.wikipedia.org/wiki/RSA_Factoring_Challenge: historial del RSA Factoring Challenge, incluyendo RSA-155.- csrc.nist.gov: estándar FIPS 203 (ML-KEM) del NIST para criptografía poscuántica.

BZip3 reduce el peso de BZip2 en 84% al comprimir código real

lu1tr0n — Mon, 07 Sep 2026 20:25:17 +0000

BZip3 acaba de demostrar que se puede comprimir el mismo archivo hasta un 84% más chico que con BZip2, sin tocar una sola línea del contenido original. El proyecto de código abierto, publicado en GitHub por el desarrollador iczelia, se presenta como el sucesor espiritual de BZip2: mismo objetivo general, pero con un motor completamente distinto por dentro.

En un benchmark público con el código fuente completo de Perl 5, bzip3 pasó de un archivo de 3,44 GB comprimido con BZip2 a uno de apenas 546 MB. Es la clase de mejora que importa cuando administrás backups, repositorios de código o pipelines de CI que mueven gigabytes de texto todos los días.

TL;DR

BZip3 es un compresor open source que se presenta como sucesor espiritual de BZip2, publicado en GitHub por iczelia.- Con Perl 5 completo, BZip3 -b511 comprimió el archivo a 546.456.978 bytes frente a 3.441.163.911 bytes de BZip2.- Eso equivale a un archivo casi 84% más chico que el de BZip2 con el mismo contenido de prueba.- LZMA (xz -9) llegó a 2.056.645.240 bytes: mejor que BZip2, pero muy por detrás de BZip3 -b511.- BZip3 descomprimió el corpus en 4min06s frente a 9min22s de BZip2 y 4min40s de xz, en un disco HDD.- Combinado con lrzip para deduplicación de largo alcance, BZip3 bajó el resultado final a apenas 60.672.608 bytes.- El motor usa BWT vía arrays de sufijos, RLE+LZ77 con modelado PPM y un codificador de entropía por mezcla de contexto.- El repositorio acumula 1.400 estrellas y 61 forks en GitHub, y ya se instala con brew install bzip3 en macOS.

Qué pasó

El repositorio iczelia/bzip3 lleva tiempo publicado en GitHub, pero volvió a circular en comunidades de desarrolladores por sus números de compresión frente a herramientas clásicas como BZip2, LZMA (xz) y Zstandard. El autor documentó un benchmark propio: descargó cada versión de Perl 5 publicada en CPAN, las descomprimió y empaquetó todo en un único archivo .tar para comparar compresores en igualdad de condiciones.

El resultado con BZip2 fue un archivo de 3.441.163.911 bytes. Con LZMA (xz -9) bajó a 2.056.645.240 bytes. Pero bzip3, corriendo con bloques de 511 MiB, lo redujo a 546.456.978 bytes: menos de un sexto del tamaño que ocupaba con BZip2.

Contexto e historia

BZip2 nació en 1996 y todavía se usa en distribuciones Linux, en el formato .tar.bz2 y en herramientas de compresión de vieja guardia. Su compresor se basa en la transformada de Burrows-Wheeler combinada con codificación Huffman, un diseño eficaz para su época pero que no aprovecha las CPUs multinúcleo ni los avances en modelado de entropía de las últimas dos décadas. Podés repasar su historia completa en la página de BZip2 en Wikipedia.

bzip3 toma la misma idea central (BWT más agrupar símbolos similares antes de comprimir) pero cambia casi todo el resto del pipeline. En vez de Huffman, usa un codificador de entropía con mezcla de contexto de orden 0. En vez de un solo paso de reordenamiento, agrega una etapa de RLE combinada con emparejamiento de cadenas estilo LZ77 y modelado estilo PPM antes de entrar al codificador final.
El repositorio acumula 1.400 estrellas y 61 forks en GitHub.
El proyecto declara soporte probado en diez arquitecturas distintas: x86, x86_64, armv6, armv7, aarch64, ppc64le, mips, mips64, sparc y s390x. Esa cobertura es poco común para un proyecto de compresión relativamente joven y sugiere que ya corrió en hardware embebido, servidores ARM y máquinas legacy por igual.

Detalles técnicos de BZip3 y su rendimiento

La tabla siguiente resume el benchmark contra sus principales alternativas, comprimiendo el mismo archivo .tar con el historial completo de Perl 5:
MétodoTamaño comprimidoTiempo total de compresiónLZMA (xz -9, 16 hilos)2.056.645.240 bytes12min 09sBZip2 -93.441.163.911 bytes17min 16sBZip3 -b 256 (12 hilos)1.001.957.587 bytes7min 10sBZip3 -b 511 (4 hilos)546.456.978 bytes7min 08sZstandard -16 (12 hilos)3.076.143.660 bytes6min 35s
Con bloques de apenas 256 MiB, bzip3 ya comprime a menos de un tercio del tamaño de BZip2, en la mitad de tiempo. Subir el bloque a 511 MiB reduce el tamaño final casi a la sexta parte del de BZip2, aunque exige más memoria: el proceso con -b 256 -j 12 llegó a usar 18.301 MiB de RAM durante la compresión, y con -b 511 -j 4 el pico bajó a 12.178 MiB.

En descompresión, medida aparte sobre un disco mecánico WD Blue, bzip3 en modo paralelo tardó 4min 06s: más rápido que BZip2 (9min 22s) y que LZMA (4min 40s), y casi a la par de Zstandard (3min 51s).
De 3,44 GB con BZip2 a 546 MB con BZip3: el mismo contenido, un sexto del peso.
El pipeline interno de bzip3 encadena tres etapas antes de escribir el archivo final:

flowchart TD
A["Datos de entrada"] --> B["BWT via arrays de sufijos"]
B --> C["RLE + LZ77 con modelado PPM"]
C --> D["Codificador de entropia (mezcla de contexto orden 0)"]
D --> E["Archivo .bz3"]

El rendimiento real depende mucho del compilador. Según la documentación del repositorio oficial de bzip3, los builds de Linux x64 compilados con Clang 13 alcanzan hasta 17 MiB/s de compresión y 23 MiB/s de descompresión por hilo. Los builds de Windows y de 32 bits suelen rendir bastante menos.

💡 Tip: el flag -j controla cuántos hilos usa bzip3. Con bloques grandes (-b 511) necesitás menos hilos para saturar la CPU porque cada bloque ya es una unidad de trabajo grande; con bloques chicos conviene subir -j para paralelizar más.

Cómo empezar con BZip3

Instalar bzip3 no requiere pasos raros: es un proyecto con autotools y CMake, y ya llegó a los gestores de paquetes más comunes.

# Linux (compilar desde un clon del repositorio con git)
$ ./bootstrap.sh
$ ./configure
$ make
$ sudo make install

# macOS (via Homebrew)
$ brew install bzip3

# Windows (via CMake, con Visual Studio o MinGW/MSYS2 instalado)
> cmake -B build -S . -DCMAKE_BUILD_TYPE=Release
> cmake --build build --config Release

En Linux, si instalaste desde un paquete de código fuente (no un git clone), podés saltarte el paso de ./bootstrap.sh. En Windows y en builds de 32 bits, el propio proyecto advierte que el rendimiento suele ser considerablemente menor que en Linux x64.

Una vez instalado, comprimir y descomprimir un archivo real se ve así:

# Comprimir con bloques de 256 MiB y 12 hilos en paralelo
$ bzip3 -e -b 256 -j 12 backup.tar

# Descomprimir el resultado
$ bunzip3 backup.tar.bz3

El flag -e fuerza el modo de compresión explícito, -b fija el tamaño de bloque en MiB y -j el número de hilos. Para confirmar que la instalación quedó bien, corré bzip3 --help: tiene que listar esas opciones junto con -d para descompresión manual.

Impacto y análisis

El caso de uso donde bzip3 más se nota es texto y código fuente: repositorios git empaquetados, logs, datasets en CSV o JSON, y árboles de código como el benchmark de Perl 5. El propio README lo dice sin vueltas: bzip3, igual que su antecesor, "excels at compressing text or code". Para binarios ya comprimidos (imágenes JPEG, videos, archivos ZIP anidados) la ventaja se reduce, porque ahí ningún compresor de propósito general saca mucho jugo.

El combo con lrzip es interesante para archivos gigantes con mucha redundancia de largo alcance: lrzip hace la deduplicación entre partes distantes del archivo, y bzip3 comprime lo que queda. En el benchmark, esa combinación bajó el .tar.lrz de Perl 5 a 60.672.608 bytes, contra 64.774.202 bytes de lrzip+lzma y 75.685.065 bytes de lrzip+bzip2.

⚠️ Ojo: el propio proyecto advierte que ningún compresor puede garantizar al 100% que un archivo comprimido se pueda recuperar siempre. Antes de usar bzip3 para backups críticos, probá el ciclo completo de comprimir y descomprimir con datos de prueba y verificá el resultado.

La contrapartida de bzip3 es la memoria. Bloques grandes implican mantener varios cientos de megabytes por hilo activo en RAM durante la compresión, algo que Zstandard evita por diseño (687 MiB de pico en el mismo benchmark, contra más de 12 GB de bzip3 con bloques grandes). Para servidores con poca RAM o contenedores con límites estrictos, bzip3 con bloques chicos (-b 256 o menos) es la opción más razonable.

Qué sigue

El repositorio sigue activo, con 456 commits acumulados y soporte oficial ya empaquetado para macOS vía Homebrew. El README remite a comparativas adicionales contra Turbo-Range-Coder y BSC dentro del propio repositorio, lo que sugiere que el proyecto se sigue midiendo activamente contra el estado del arte en compresión sin pérdida.

Para equipos que hoy dependen de .tar.bz2 en pipelines de CI o de distribución de paquetes, el próximo paso lógico es correr el propio dataset (no el de Perl 5) contra bzip3 con distintos tamaños de bloque, y comparar tamaño final, tiempo de compresión y memoria pico antes de migrar cualquier proceso de producción.

📖 Resumen en Telegram: Ver resumen

Probalo vos: cloná el repositorio de bzip3 en GitHub y corré bzip3 -e -b 256 -j 4 sobre tu propio repositorio de código para comparar el tamaño final contra el .tar.gz que ya usás.

Preguntas frecuentes

¿BZip3 es compatible con archivos .bz2 de BZip2?

No. bzip3 usa un formato de contenedor propio (extensión .bz3) y un pipeline de compresión distinto. Para abrir un .bz2 necesitás bzip2 o una herramienta que lo soporte explícitamente; bzip3 no lee ese formato.

¿Cuánta memoria necesita BZip3 para comprimir?

Depende del tamaño de bloque. En el benchmark de Perl 5, correr bzip3 con -b 256 -j 12 llegó a usar 18.301 MiB de RAM; con -b 511 -j 4 el pico bajó a 12.178 MiB. Bloques más chicos consumen bastante menos memoria.

¿BZip3 corre en Windows?

Sí, mediante CMake con Visual Studio o MinGW/MSYS2, aunque el propio proyecto advierte que los builds de Windows y de 32 bits suelen rendir considerablemente menos que Linux x64 con Clang.

¿En qué arquitecturas está probado BZip3?

El README lista x86, x86_64, armv6, armv7, aarch64, ppc64le, mips, mips64, sparc y s390x como plataformas ya verificadas.

¿BZip3 sirve para comprimir imágenes o video?

No es su punto fuerte. bzip3 está optimizado para texto y código fuente; archivos binarios ya comprimidos (JPEG, MP4, ZIP) no se benefician tanto de su pipeline de BWT y modelado de contexto.

¿Es seguro usar BZip3 para backups sin probarlo antes?

El propio proyecto no lo recomienda: el disclaimer del README pide no comprimir datos críticos sin aceptar la posibilidad, aunque sea baja, de que el archivo no se pueda recuperar. Probar el ciclo completo de comprimir y descomprimir antes de confiar en él para producción es la práctica sensata.

Referencias

iczelia/bzip3 en GitHub: repositorio oficial, código fuente y benchmarks completos.- Archivo de versiones de Perl 5 en CPAN: el dataset usado en el benchmark de compresión.- Transformada de Burrows-Wheeler en Wikipedia: contexto sobre el algoritmo que comparten BZip2 y BZip3.- BZip2 en Wikipedia: historia y contexto del compresor predecesor.

SeoulTech crea un framework para probar la robustez de la visión por IA

lu1tr0n — Mon, 07 Sep 2026 16:17:27 +0000

SeoulTech, la Universidad Nacional de Ciencia y Tecnología de Seúl, presentó un framework pensado para exponer el momento exacto en que un sistema de visión por inteligencia artificial deja de reconocer lo que debería reconocer. La herramienta mide y busca mejorar la robustez de visión IA frente a ruido, desenfoque, compresión y perturbaciones calculadas para engañar al modelo.

El reporte, publicado por TMCnet, llega en un momento en que cámaras de seguridad, sistemas de asistencia a la conducción y equipos de diagnóstico médico dependen cada vez más de redes neuronales entrenadas con imágenes limpias que rara vez reflejan las condiciones reales de uso.

TL;DR

SeoulTech (Universidad Nacional de Ciencia y Tecnología de Seúl) presentó un framework para medir la robustez de visión IA.- El framework aplica perturbaciones adversariales y corrupciones naturales (ruido, niebla, compresión) a las imágenes de prueba.- Mide la caída de precisión del modelo frente a esas alteraciones y retroalimenta el reentrenamiento.- Se apoya en la misma línea que popularizó FGSM (Goodfellow, 2014) y el benchmark ImageNet-C (Hendrycks, 2019).- Herramientas abiertas como RobustBench y torchattacks permiten reproducir pruebas similares hoy mismo.- La robustez es cada vez más un requisito regulatorio para sistemas de IA de alto riesgo, no solo una métrica académica.- El principal trade-off: mejorar la robustez adversarial suele bajar algo la precisión en datos limpios.

Qué pasó

Según la cobertura de TMCnet, el equipo de SeoulTech construyó un framework de evaluación que somete modelos de visión por computadora a un conjunto de pruebas automatizadas antes de que salgan a producción. La idea central no es nueva: viene de una línea de investigación que arrancó hace más de una década, pero SeoulTech la empaqueta como un proceso repetible que un equipo de ingeniería puede correr contra su propio modelo, de forma parecida a un pipeline de integración continua que corre pruebas unitarias antes de un deploy.

El framework combina dos familias de pruebas. La primera aplica perturbaciones adversariales: ruido matemáticamente diseñado, casi imperceptible para un ojo humano, que aprovecha el gradiente del propio modelo para maximizar el error de clasificación. La segunda aplica corrupciones naturales: niebla, lluvia, desenfoque de movimiento, compresión JPEG agresiva, condiciones que una cámara real puede encontrar sin que nadie la esté atacando. Un modelo puede rendir bien en ambas pruebas, en una sola o en ninguna, y esa combinación define su robustez de visión IA en la práctica.

Lo que hace útil a un framework de este tipo no es solo detectar la falla, sino alimentar ese resultado de vuelta al entrenamiento: las imágenes que rompen al modelo se usan para generar ejemplos de aumento de datos o para un régimen de entrenamiento adversarial, cerrando parcialmente la brecha entre precisión de laboratorio y precisión en el mundo real.
Una perturbación casi invisible puede cambiar por completo la predicción de un modelo.

Contexto e historia

El punto de partida de este campo suele fijarse en 2014, cuando Ian Goodfellow y sus coautores publicaron el método FGSM (Fast Gradient Sign Method), que demostró que sumar un ruido casi invisible a una imagen podía hacer que una red neuronal de última generación la clasificara con total confianza como algo completamente distinto. Esa fragilidad, contraintuitiva para un sistema que superaba a los humanos en precisión bruta, abrió una subdisciplina completa dentro del aprendizaje automático.

En 2019, Dan Hendrycks y Thomas Dietterich publicaron ImageNet-C, un benchmark que en vez de atacar al modelo con matemática adversarial lo somete a quince tipos de corrupción cotidiana (ruido gaussiano, pixelado, niebla, cambios de brillo, entre otras) en cinco niveles de severidad. La conclusión del paper fue incómoda: modelos que ya superaban a los humanos en ImageNet limpio se desplomaban frente a corrupciones que un humano ni siquiera nota. Ese hallazgo es, en esencia, el problema que un framework como el de SeoulTech intenta resolver de forma sistemática.

Desde entonces se sumaron esfuerzos como RobustBench, un leaderboard académico que compara decenas de modelos bajo ataques y corrupciones estandarizadas, y programas como GARD (Guaranteeing AI Robustness against Deception) de DARPA en Estados Unidos, enfocados en certificar matemáticamente los límites de robustez de un modelo, no solo medirla empíricamente.

Detalles técnicos: cómo se mide la robustez de visión IA

La métrica central de cualquier evaluación de este tipo es la precisión robusta: el porcentaje de imágenes que el modelo sigue clasificando correctamente después de aplicarle una perturbación o corrupción, en contraste con la precisión limpia (clean accuracy) medida sobre el dataset original sin alterar. La diferencia entre ambas cifras expone qué tan frágil es un modelo en la práctica.
Tipo de pruebaEjemploCuándo usarlaLimitaciónPerturbación adversarial (FGSM, PGD)Ruido calculado con el gradiente del modeloEvaluar riesgo ante un atacante dirigidoCasi siempre requiere acceso white-box al modeloCorrupción natural (ImageNet-C)Niebla, desenfoque de movimiento, compresión JPEGEvaluar robustez ante condiciones reales de cámara o climaNo representa un atacante maliciosoCambio de distribución (domain shift)Imágenes de otra cámara, país o datasetEvaluar generalización fuera del set de entrenamientoDifícil de resumir en una sola métrica
Un dato que suele sorprender a quien no trabaja en el área: no hace falta acceso físico a la cámara ni al pipeline de producción para atacar un modelo. Basta con conocer su arquitectura, o incluso solo su salida en ataques black-box, para generar perturbaciones que funcionan de forma consistente contra la misma familia de redes.

Un pipeline típico de este tipo de framework sigue un ciclo simple: generar la perturbación, medir la caída de precisión y, si el resultado es malo, retroalimentar el entrenamiento.

flowchart TD
A["Imagen original"] --> B["Generador de perturbaciones"]
B --> C["Modelo de vision"]
C --> D["Medir precision robusta"]
D --> E{"Cae la precision?"}
E -->|"Si"| F["Reentrenar con aumentos"]
E -->|"No"| G["Modelo aprobado"]
F --> C

Cómo empezar a probarlo

No hace falta esperar a que SeoulTech publique su framework para empezar a medir la robustez de visión IA de un modelo propio. La comunidad de código abierto ya construyó las piezas necesarias, y correr una primera prueba toma minutos.

pip install torch torchvision torchattacks robustbench

Con eso instalado, el flujo mínimo es cargar un modelo preentrenado, aplicarle un ataque conocido y comparar la precisión antes y después.
Un ataque FGSM contra ResNet18 corre en menos de diez líneas de código.

import torch
import torchvision.models as models
from torchattacks import FGSM

model = models.resnet18(weights="IMAGENET1K_V1").eval()
atk = FGSM(model, eps=8/255)

adv_images = atk(images, labels)
outputs = model(adv_images)
robust_acc = (outputs.argmax(1) == labels).float().mean()
print(f"Precision robusta: {robust_acc.item():.2%}")

El parámetro eps controla cuánto se le permite mover el ruido a cada píxel: valores bajos generan perturbaciones casi invisibles, valores altos son más fáciles de detectar a simple vista pero también más fáciles de bloquear con filtros simples. Para corrupciones naturales en vez de ataques dirigidos, la librería imagecorruptions replica los quince tipos definidos en ImageNet-C sin necesidad de acceso al modelo.

💡 Tip: El parámetro eps en FGSM o PGD suele probarse en un rango de 2/255 a 16/255. Cuanto más alto, más fácil engañar al modelo, pero menos realista es la perturbación.

Impacto y análisis

La robustez de visión IA dejó de ser un tema exclusivamente académico. Un sistema de frenado automático que falla al reconocer una señal de alto parcialmente cubierta de nieve, o una cámara de control de acceso que un atacante engaña con un patrón impreso en una gorra, son el mismo problema que documentan estos benchmarks, solo que con consecuencias físicas.

Por eso frameworks de este tipo se están volviendo parte del proceso de desarrollo, no un experimento aparte: correrlos antes de cada despliegue permite detectar regresiones de robustez de la misma forma en que un test de integración detecta una regresión funcional.

⚠️ Ojo: Entrenar un modelo para resistir ataques adversariales casi siempre reduce algo de precisión sobre datos limpios. No existe robustez gratis: es un trade-off que hay que medir, no asumir.

El costo no es solo de cómputo. El entrenamiento adversarial, la técnica más usada para cerrar la brecha entre precisión limpia y precisión robusta, puede multiplicar el tiempo de entrenamiento porque cada lote de datos requiere generar primero sus versiones atacadas antes de actualizar los pesos del modelo.

Qué sigue

La tendencia regulatoria apunta a que estas pruebas dejen de ser opcionales. Marcos como el de la Unión Europea para sistemas de inteligencia artificial de alto riesgo ya incluyen requisitos de exactitud, robustez y ciberseguridad como condición para operar en sectores sensibles, lo que empuja a que evaluaciones como la de SeoulTech pasen de ser un paper académico a un paso obligatorio antes de un lanzamiento.

A nivel técnico, el área avanza hacia certificación formal: en vez de solo probar contra un puñado de ataques conocidos, las técnicas de robustez certificada intentan demostrar matemáticamente que ningún ataque dentro de un radio determinado puede cambiar la predicción del modelo. Es un estándar mucho más alto que superar un benchmark, y todavía es costoso de aplicar a modelos grandes.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instalá torchattacks y corré un ataque FGSM contra tu propio modelo de visión antes de tu próximo deploy para ver cuánto cae realmente su precisión.

Preguntas frecuentes

¿Qué es la robustez de visión IA?

Es la capacidad de un modelo de visión por computadora de mantener su precisión cuando la imagen de entrada cambia levemente, ya sea por ruido natural (niebla, compresión) o por una perturbación diseñada a propósito para engañarlo.

¿Un ataque adversarial y una corrupción natural son lo mismo?

No. Un ataque adversarial usa el gradiente del modelo para calcular el ruido más dañino posible; una corrupción natural simula condiciones reales de cámara o clima sin intención maliciosa. Ambas pueden bajar la precisión, pero se miden y se corrigen distinto.

¿Puedo evaluar la robustez de mi propio modelo hoy mismo?

Sí. Librerías abiertas como RobustBench y torchattacks permiten correr ataques FGSM o PGD contra cualquier modelo de torchvision en pocas líneas de código, como se muestra en la sección Cómo empezar a probarlo de este artículo.

¿Mejorar la robustez adversarial afecta la precisión normal?

Casi siempre sí, en algún grado. El entrenamiento adversarial suele reducir un poco la precisión sobre datos limpios a cambio de reducir mucho más la caída de precisión frente a ataques o corrupciones.

¿Dónde se aplica esto fuera del laboratorio?

En sistemas donde una falla de visión tiene consecuencias físicas o de seguridad: asistencia a la conducción, control de acceso por cámara, inspección industrial y diagnóstico por imagen médica.

Referencias

TMCnet: reporte sobre el framework de SeoulTech para robustez de visión por IA.- arXiv: Explaining and Harnessing Adversarial Examples: el paper de Goodfellow et al. que introdujo FGSM en 2014.- arXiv: Benchmarking Neural Network Robustness to Common Corruptions and Perturbations: el paper que presentó ImageNet-C.- RobustBench: leaderboard abierto que compara modelos bajo ataques y corrupciones estandarizadas.- Wikipedia: Adversarial machine learning: panorama general del campo y sus técnicas.

El 80% de los smartphones en la UE no cumple las reglas de reparabilidad

lu1tr0n — Mon, 07 Sep 2026 14:29:31 +0000

Más del 80% de los smartphones y tablets que llegan al mercado europeo todavía no publican la información que exige la ley de reparabilidad de smartphones, vigente hace exactamente un año. Lo confirmó Right to Repair Europe el 7 de septiembre de 2026, después de revisar el registro oficial donde cada fabricante declara su propio puntaje.

El hallazgo importa porque la norma se apoya en la palabra del fabricante: nadie más audita el dato antes de que el celular llegue a la góndola.

TL;DR

Más del 80% de los smartphones y tablets en la UE no publica su información de reparación obligatoria.- La norma exige un puntaje de reparabilidad autodeclarado y un enlace de repuestos desde junio de 2025.- De 2.334 registros de celulares en el EPREL, solo el 18% enlaza a una página real con repuestos o manuales.- Cerca del 50% de los registros deja en blanco el campo de URL de reparación.- Otro 19% remite a una página de soporte genérica, sin repuestos ni instrucciones.- Algunos registros mandan al comprador a buscar repuestos en Temu o AliExpress.- Fabricantes que incumplen igual se autoasignan la calificación máxima, clase A, en reparabilidad.- Desde febrero de 2027 los celulares nuevos deberán traer batería reemplazable por el usuario.

Qué pasó

Right to Repair Europe, la coalición que agrupa a organizaciones como iFixit en su rama europea, revisó el European Product Registry for Energy Labelling (EPREL), la base pública donde la Comisión Europea obliga a registrar cada modelo de celular y tablet que se vende en el bloque. Encontró 2.334 registros de smartphones dados de alta en el último año y revisó, uno por uno, si cada uno cumplía con publicar dónde conseguir repuestos y el manual de reparación.

El resultado: solo el 18% de esos registros enlaza a una página que realmente sirve, con precios de repuestos o instrucciones. Cerca de la mitad deja el campo vacío, sin ningún enlace. Otro 19% apunta a una página de producto o de soporte genérica, sin repuestos ni manual. En algunos casos, el fabricante remite directamente a Temu o AliExpress para conseguir piezas de repuesto.

Incluso cuando el precio del repuesto sí aparece, el dato puede ser inútil: algunos registros listan una batería de repuesto entre 14 y 128 euros, un rango tan amplio que no le sirve a nadie para decidir si vale la pena reparar el equipo.

Lo más llamativo es que varios fabricantes claramente incumplidores igual se otorgan a sí mismos la nota más alta posible, clase A, en el puntaje de reparabilidad que ellos mismos declaran. Y cuando el enlace sí existe y es válido, no siempre es fácil de usar: para marcas grandes como Apple y Samsung hace falta navegar varios clics antes de llegar al precio real de un repuesto, según el informe.

⚠️ Ojo: el sistema no tiene un verificador automático. Un fabricante puede dejar el campo de reparación vacío y aun así declararse clase A en reparabilidad, porque el puntaje es autoevaluado.

Contexto e historia

La obligación nació dentro del paquete de ecodiseño y etiquetado energético de la UE, que desde junio de 2025 extendió a smartphones y tablets el mismo esquema que ya existía para heladeras o lavarropas: una etiqueta con una nota de A a G y datos técnicos verificables. La diferencia con la energía es que, en electrodomésticos, hay laboratorios que miden el consumo. En reparabilidad, el puntaje lo pone el propio fabricante, sin auditoría previa.

Francia había probado algo parecido antes, con su índice de reparabilidad obligatorio para electrónica de consumo, y sirvió de referencia para el esquema europeo. La apuesta de Bruselas fue escalar esa idea a los 27 países del bloque, apoyada en el registro EPREL como ventanilla única de transparencia.
La ley exige publicar dónde conseguir estos repuestos, pero la mitad de los registros no lo hace.

Cómo funciona el registro EPREL

Cada fabricante que vende un smartphone o tablet en la UE tiene que crear un registro en EPREL antes de poner el producto a la venta. Ese registro incluye la ficha técnica del modelo, la etiqueta energética generada automáticamente y, desde junio de 2025, un campo obligatorio con la URL donde el comprador puede encontrar precios de repuestos y el manual de reparación.

El problema es estructural: EPREL valida que el campo de la URL exista y tenga formato de enlace, pero no valida que ese enlace lleve a información real. Right to Repair Europe tuvo que abrir manualmente cada uno de los 2.334 enlaces para clasificarlos. Así se ve la distribución que encontraron:
Categoría del registroQué significa% de los 2.334 registrosEnlace válido con datos de reparaciónLa URL lleva a precios de repuestos o instrucciones reales18%Campo de URL en blancoEl fabricante no completó el enlace obligatorio~50%Enlace genérico o irrelevanteRemite a una página de producto o soporte sin repuestos ni manual19%Otros casos, incluidos Temu y AliExpressEl enlace existe pero no cumple el propósito de la normaresto de los registros
El siguiente diagrama resume el recorrido de un registro típico, desde que el fabricante declara su puntaje hasta que un comprador intenta usar esa información:

flowchart TD
A["Fabricante lanza un modelo"] --> B["Declara su propio puntaje de reparabilidad"]
B --> C["Registra el modelo en EPREL"]
C --> D{"¿Publica una URL con repuestos y manual?"}
D -- "Sí, 18%" --> E["El consumidor encuentra la información"]
D -- "Campo vacío, ~50%" --> F["El consumidor no encuentra nada"]
D -- "Link genérico, 19%" --> G["El consumidor llega a una página sin datos"]

Cómo verificar la reparabilidad de smartphones vos mismo

El registro de EPREL es público, así que no hace falta esperar al próximo informe de una ONG para chequear un modelo puntual. El buscador web está en eprel.ec.europa.eu, filtrando por la categoría de smartphones y tablets. Ahí aparece la ficha de cada modelo con su etiqueta energética y, si el fabricante la cargó, la URL de reparación.

Para confirmar rápido si esa URL sirve, alcanza con revisar el código de estado HTTP:

curl -s -o /dev/null -w "%{http_code}\n" "https://soporte.ejemplo-fabricante.com/repuestos/modelo-x1"

Un 200 no garantiza que la página tenga precios de repuestos, solo que el enlace responde. El paso que hace Right to Repair Europe es bajar el contenido y buscar palabras clave asociadas a reparación real, no solo a soporte técnico genérico:

import csv
import requests

PALABRAS_CLAVE = ["repuesto", "spare part", "battery", "bateria", "manual de reparacion", "repair manual"]

def clasificar(url):
    if not url or not url.strip():
        return "vacio"
    try:
        resp = requests.get(url, timeout=10, allow_redirects=True)
    except requests.RequestException:
        return "inalcanzable"
    if resp.status_code != 200:
        return f"http_{resp.status_code}"
    texto = resp.text.lower()
    if any(palabra in texto for palabra in PALABRAS_CLAVE):
        return "cumple"
    return "irrelevante"

with open("eprel_smartphones.csv", newline="", encoding="utf-8") as archivo:
    filas = csv.DictReader(archivo)
    resultados = {}
    for fila in filas:
        estado = clasificar(fila["url_reparacion"])
        resultados[estado] = resultados.get(estado, 0) + 1

print(resultados)

El script recibe un CSV con los modelos y la URL de reparación que cada uno declaró en EPREL (se exporta a mano desde el buscador, porque EPREL no ofrece una API pública documentada para terceros), y devuelve un conteo por categoría. Si corrés esto sobre una muestra amplia, las proporciones deberían acercarse a las que reportó Right to Repair Europe: minoría en "cumple", cerca de la mitad en "vacío".

💡 Tip: antes de comprar un celular, buscá el modelo en EPREL y probá el enlace de reparación con el curl de arriba. Si tira 404 o redirige a la home del fabricante, el puntaje de reparabilidad que aparece en la caja no tiene respaldo real.

Impacto y análisis

Right to Repair Europe cuestiona todo el diseño del sistema. Si miles de registros tienen el campo vacío y nadie lo notó en un año, ninguna autoridad está revisando los datos que cargan los fabricantes.

Thomas Opsomer, vocero de políticas de la Unión Europea de iFixit y de la coalición Right to Repair Europe, lo resumió así: "The obligation for publicly available spare parts prices and repair manuals is a great step forward, but it needs to be enforced better" (la obligación de publicar precios de repuestos y manuales es un paso adelante, pero necesita mejor aplicación). Opsomer también planteó que, si el puntaje es autoasignado, los fabricantes deberían estar obligados a publicar toda la documentación que lo respalda, para que cualquiera pueda auditarlo, y que debería ser más fácil para consumidores y talleres reportar incumplimientos.

The Register le consultó a la Comisión Europea por estos hallazgos y, al momento de publicar el informe, todavía no había respuesta. Ese silencio es parte del problema que señala la ONG: no hay evidencia pública de que alguna autoridad esté auditando activamente los registros de EPREL.

Para quienes trabajan en software o en cumplimiento normativo, el caso es un ejemplo clásico de autoevaluación sin auditoría: cualquier sistema donde el regulado carga sus propios datos, sin un chequeo automático de calidad ni una sanción clara por dejar campos vacíos, tiende a llenarse de campos vacíos. El problema de fondo es que la reparabilidad de smartphones quedó en manos de quien menos interés tiene en que se audite: el propio fabricante.
La etiqueta muestra una nota de reparabilidad que el propio fabricante calcula.

Qué sigue

En febrero de 2027 entra en vigor otro tramo de la misma familia de reglas: los celulares nuevos vendidos en la UE deberán traer batería reemplazable por el usuario, con excepciones para categorías como los wearables. Esa exigencia es más fácil de auditar que un enlace roto, porque se verifica con el diseño físico del producto, no con un campo de texto que el fabricante puede dejar vacío.

Right to Repair Europe seguirá presionando por dos cambios concretos: que la Comisión obligue a publicar la documentación técnica detrás de cada puntaje autodeclarado, y que exista un canal simple para que consumidores y talleres de reparación reporten registros incumplidores en EPREL. Ninguno de los dos cambios requiere una ley nueva, alcanza con reglamentar mejor la que ya existe.

Para un lector fuera de la UE, el caso vale como advertencia temprana: cualquier ley de reparabilidad que se apoye en la autoevaluación del fabricante, sin auditoría ni sanción automática, corre el riesgo de terminar con la misma brecha entre lo que dice la etiqueta y lo que hay detrás del enlace.

📖 Resumen en Telegram: Ver resumen

Probalo vos: buscá el modelo de tu próximo celular en eprel.ec.europa.eu y corré el curl de arriba contra el enlace de reparación antes de confiar en la nota de reparabilidad que aparece en la caja.

Preguntas frecuentes

¿Qué es la etiqueta de reparabilidad de la UE?

Es una nota, de clase A a la más baja, que cada fabricante de smartphones y tablets debe autoasignarse desde junio de 2025, junto con un enlace donde el comprador puede ver precios de repuestos y el manual de reparación.

¿Qué es EPREL?

El European Product Registry for Energy Labelling es la base de datos pública de la Comisión Europea donde los fabricantes registran cada modelo antes de venderlo en el bloque, incluida su etiqueta energética y de reparabilidad.

¿Por qué el puntaje de reparabilidad no es confiable del todo?

Porque lo calcula y lo declara el propio fabricante, sin que un laboratorio externo lo verifique antes de publicarlo. Right to Repair Europe encontró fabricantes que se dan clase A pese a dejar vacío el campo obligatorio de información de reparación.

¿Qué pasa si un fabricante no cumple con la norma?

Según el informe, no hay evidencia de sanciones activas: miles de registros llevan un año con el campo de reparación vacío sin que ninguna autoridad los haya corregido.

¿La regla aplica también a marcas que venden a través de plataformas como Temu o AliExpress?

Sí, cualquier fabricante que venda smartphones o tablets en el mercado europeo debe registrarse en EPREL, sin importar su país de origen o el canal de venta.

¿Qué cambia en 2027?

Desde febrero de 2027, los celulares nuevos deberán traer batería reemplazable por el usuario, con excepciones para dispositivos como wearables.

Referencias

The Register: informe original sobre el incumplimiento de las reglas de reparabilidad en la UE.- EPREL: registro público de la Comisión Europea donde se cargan las etiquetas energéticas y de reparabilidad.- iFixit: organización de reparación citada como vocera de la coalición Right to Repair Europe.- Comisión Europea: autoridad responsable del reglamento de ecodiseño y etiquetado energético que incluye la reparabilidad.

Internet Archive: donación de $25 se triplica a $75 en septiembre

lu1tr0n — Mon, 07 Sep 2026 08:22:41 +0000

Un dólar donado a Internet Archive este mes se convierte en tres. La organización sin fines de lucro que sostiene la Wayback Machine y buena parte de la memoria pública de internet anunció una campaña de donaciones recurrentes para septiembre de 2026: cada aporte mensual desde $25 recibe un match de 2:1 durante todo el mes.

La noticia importa porque Internet Archive no terceriza su infraestructura central. Construye y mantiene sus propios servidores, sistemas de almacenamiento y refrigeración para preservar 210 petabytes de datos: libros, páginas web, audio, video y software. Sin financiamiento estable, esa capacidad de preservación depende directamente de campañas como esta.

TL;DR

Internet Archive lanzó en septiembre de 2026 una campaña de donaciones recurrentes con match 2:1.- Un aporte de $25 mensuales se convierte en $75 de impacto total gracias al match.- $50 mensuales generan $150; $100 mensuales generan $300, según el anuncio oficial.- El match aplica solo al primer aporte de una donación recurrente nueva iniciada en septiembre.- La organización preserva 210 petabytes: libros, páginas web, audio, video y software.- Internet Archive no cobra por acceso, no vende datos de usuarios ni muestra publicidad.- La donación promedio histórica de la organización ronda los $25 mensuales.- La campaña fue publicada el 1 de septiembre de 2026 en blog.archive.org.

Qué pasó

Internet Archive confirmó que todo nuevo donante recurrente que inicie un aporte de $25 o más durante septiembre de 2026 recibirá un match de 2:1 sobre su primera contribución. En la práctica, eso multiplica por tres el valor inicial de cada donación.

La organización lo explicó con ejemplos concretos en su blog oficial: un aporte mensual de $25 desbloquea $50 adicionales de match, para un total de $75 de apoyo. Un aporte de $50 se convierte en $150, y uno de $100 llega a $300. La siguiente tabla resume la mecánica:

Aporte mensual propioMatch 2:1Total generado$25+$50$75$50+$100$150$100+$200$300

El mensaje de Brewster Kahle, bibliotecario digital y fundador de Internet Archive, enmarca la campaña en la misión histórica de la organización: “El acceso universal a todo el conocimiento humano está a nuestro alcance. Nuestro trabajo es poner lo mejor que nuestro mundo tiene para ofrecer al alcance de nuestros hijos”.

La campaña se suma al programa permanente llamado Monthly Giving Circle, el grupo de donantes recurrentes que sostiene mes a mes las operaciones de la organización. Según el propio blog, la donación promedio en Internet Archive ronda los $25 mensuales, lo que confirma que el umbral elegido para el match no es arbitrario: coincide con el comportamiento real de sus donantes.

Contexto e historia de Internet Archive

Internet Archive nació en 1996 en San Francisco con un objetivo declarado desde el inicio: archivar internet antes de que desapareciera. Su proyecto más conocido, la Wayback Machine, empezó a estar disponible públicamente en 2001 y hoy permite consultar versiones históricas de miles de millones de páginas web.

La organización preserva 210 petabytes de datos con infraestructura propia.

A lo largo de tres décadas, el archivo creció mucho más allá de las páginas web. Hoy incluye libros digitalizados, grabaciones de audio y música, películas, videojuegos emulables, software histórico y colecciones de radio y televisión. Toda esa colección combinada suma, según el anuncio de septiembre de 2026, 210 petabytes de datos.

La decisión de no delegar esa infraestructura a proveedores externos es, en parte, un principio editorial: Internet Archive no cobra por el acceso, no vende datos de sus usuarios y no muestra publicidad. Ese modelo la diferencia de bibliotecas digitales comerciales, pero también la deja sin la palanca de ingresos que tienen esas empresas: publicidad, suscripciones premium o venta de datos agregados.

Internet Archive también atravesó momentos de tensión legal en los últimos años, principalmente por su programa de préstamo digital controlado de libros escaneados, cuestionado por editoriales en tribunales de Estados Unidos. Ese contexto explica por qué la organización insiste en la estabilidad financiera: cada frente de disputa legal consume recursos que también deberían sostener servidores y personal técnico.

Detalles técnicos y rendimiento de la infraestructura

Mantener 210 petabytes en operación no es solo un problema de espacio en disco. Cada dólar recaudado se reparte entre varios frentes técnicos: servidores de cómputo, arreglos de almacenamiento, redes internas, energía eléctrica y refrigeración de los centros de datos que la organización opera directamente.

El siguiente diagrama resume, de forma simplificada, cómo una donación recurrente se traduce en capacidad operativa real:

flowchart TD
A["Donación mensual"] --> B["Match 2:1 de Internet Archive"]
B --> C["Fondos para infraestructura"]
C --> D[("Servidores y almacenamiento")]
C --> E[("Energía y refrigeración")]
D --> F["Wayback Machine y colecciones"]
E --> F

A diferencia de un proveedor cloud comercial, Internet Archive no factura por consumo elástico: opera capacidad fija que debe crecer al ritmo de sus colecciones. Eso vuelve más predecible el gasto operativo, pero también más sensible a caídas de ingresos: si las donaciones bajan, la organización no puede simplemente reducir capacidad sin arriesgar la disponibilidad del archivo.

La infraestructura propia evita depender de proveedores cloud externos.

Esa autonomía tecnológica es, según la propia organización, parte de la razón por la que puede mantener el acceso gratuito y sin publicidad: no hay intermediarios comerciales entre el usuario y los datos que consulta.

Cómo empezar: donar o usar el archivo hoy mismo

Sumarse al Monthly Giving Circle es un trámite de un par de minutos: se hace desde archive.org/donate, eligiendo un monto recurrente de $25 o más antes de que termine septiembre de 2026 para calificar al match 2:1.

Pero no hace falta donar para aprovechar la infraestructura que sostiene esta campaña. Internet Archive expone una API pública y gratuita para consultar la Wayback Machine sin necesidad de credenciales. La forma más simple es preguntar si una URL específica ya está archivada:

curl 'http://archive.org/wayback/available?url=example.com'

Esa llamada devuelve un JSON con la instantánea más cercana disponible para example.com, incluyendo su timestamp y la URL directa al snapshot archivado. Es la misma verificación que hace el propio sitio cuando genera el aviso de página archivada.

Para explorar el historial completo de un dominio, Internet Archive expone la CDX API, pensada para listar snapshots con filtros de fecha:

const params = new URLSearchParams({
  url: 'example.com',
  output: 'json',
  from: '20200101',
  to: '20261231',
  limit: '5'
});

const res = await fetch(`https://web.archive.org/cdx/search/cdx?${params}`);
const rows = await res.json();

rows.slice(1).forEach(([urlkey, timestamp, original]) => {
  console.log(timestamp, original);
});

Ese script pide hasta cinco snapshots de example.com capturados entre 2020 y 2026, e imprime el timestamp y la URL original de cada uno. La primera fila de la respuesta es el encabezado de columnas, por eso el código la descarta con slice(1).

💡 Tip: el match 2:1 de septiembre solo aplica a la primera contribución de una donación recurrente nueva, no a donaciones únicas ni a aportes recurrentes ya existentes.

Impacto y análisis

El diseño de la campaña prioriza donantes recurrentes por encima de aportes únicos, y esa elección tiene una lógica financiera clara: un aporte mensual sostenido es más fácil de proyectar en un presupuesto operativo que una donación puntual, por grande que sea. Para una organización que paga servidores, energía y personal técnico todos los meses, la previsibilidad vale tanto como el monto total recaudado.

El match 2:1 también funciona como incentivo psicológico: convierte un aporte modesto de $25 mensuales en un impacto declarado de $75, sin que el donante tenga que desembolsar más. Es una estrategia común en organizaciones sin fines de lucro, pero poco habitual en el mundo del software y la infraestructura de internet, donde la mayoría de los servicios que usamos a diario están financiados por publicidad, suscripciones o venta de datos.

⚠️ Ojo: Internet Archive depende casi por completo de donaciones para financiar infraestructura que en una empresa comercial costaría cientos de millones de dólares al año en cómputo y almacenamiento.

Esa dependencia también es un punto débil estructural. A diferencia de una empresa con ingresos recurrentes garantizados por contrato, una biblioteca digital financiada por donaciones vive campaña a campaña. Si una campaña de matching no alcanza su objetivo, no hay una ronda de inversión de respaldo: la organización ajusta gasto operativo, lo que en la práctica puede significar menos capacidad de rastreo web, menos redundancia de almacenamiento o menos velocidad de respuesta en picos de tráfico.

Qué sigue

La campaña de matching 2:1 corre durante todo septiembre de 2026. Cada donación recurrente nueva que se registre en ese período con $25 o más mensuales calificará automáticamente, sin necesidad de un código promocional ni un paso adicional en el checkout de archive.org/donate.

Más allá del mes de campaña, Internet Archive seguirá enfrentando el mismo desafío estructural: sus colecciones crecen cada año, y con ellas el costo de almacenarlas y servirlas. La organización no anunció un cambio de modelo de financiamiento, así que campañas de matching como esta seguirán siendo, previsiblemente, una herramienta recurrente para sostener la operación.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré curl 'http://archive.org/wayback/available?url=tu-sitio.com' ahora mismo y confirmá si tu propio sitio ya quedó preservado en la Wayback Machine.

Preguntas frecuentes

¿Qué es Internet Archive?

Es una biblioteca digital sin fines de lucro fundada en 1996 que preserva páginas web, libros, audio, video y software, y opera la Wayback Machine para consultar versiones históricas de internet.

¿Cómo funciona el match 2:1 de septiembre de 2026?

Toda donación recurrente nueva de $25 mensuales o más iniciada en septiembre recibe el doble de ese monto en fondos adicionales: un aporte de $25 genera $75 de impacto total.

¿El match aplica a donaciones únicas?

No. Según el anuncio oficial, el match 2:1 aplica solo al primer aporte de una donación recurrente mensual nueva, no a contribuciones puntuales.

¿Cuánto almacenamiento usa Internet Archive?

La organización reporta 210 petabytes de datos preservados, distribuidos entre páginas web, libros digitalizados, audio, video y software histórico.

¿Internet Archive vende mis datos o muestra publicidad?

No. La organización declara explícitamente que no cobra por el acceso, no vende datos de usuarios ni muestra anuncios en ninguna de sus plataformas.

¿Puedo usar la Wayback Machine sin donar?

Sí. La Wayback Machine y su API de disponibilidad son de acceso público y gratuito, sin necesidad de registro ni de aporte económico.

Referencias

Internet Archive Blog: anuncio oficial de la campaña de matching 2:1 de septiembre de 2026.- archive.org/donate: página oficial para sumarse al Monthly Giving Circle.- Wayback Machine: acceso público a las instantáneas históricas de internet.- Wikipedia: historia y contexto general de Internet Archive.

GrapheneOS confirma que migra parte de su infraestructura a sistemas propios

lu1tr0n — Mon, 07 Sep 2026 02:23:30 +0000

GrapheneOS no usa mastodon.social ni ninguna instancia de terceros para comunicarse: opera su propio servidor de Mastodon en grapheneos.social. Desde esa misma cuenta, el proyecto publicó recientemente que está bien avanzado en el proceso de convertir parte de su infraestructura interna a sistemas propios.

El mensaje original, tal como quedó disponible públicamente, no detalla qué sistema específico se está migrando ni cuándo terminará el proceso. Pero el hecho en sí (un proyecto de seguridad y privacidad que prioriza tener el control total de su infraestructura propia) es coherente con cómo GrapheneOS ha operado desde siempre, y sirve como punto de partida para explicar qué significa autoalojar servicios críticos en 2026.

TL;DR

GrapheneOS anunció en su cuenta oficial de Mastodon que está bien avanzado en el proceso de convertir parte de su infraestructura interna.- El mensaje se publicó desde grapheneos.social, la instancia de Mastodon que el propio proyecto opera y administra.- GrapheneOS ya autoaloja varios servicios clave: su repositorio de apps en apps.grapheneos.org y su servidor de atestación remota en attestation.app.- La fuente disponible del anuncio no detalla el sistema específico convertido ni una fecha de finalización.- Autoalojar una instancia de Mastodon mínima requiere Docker, PostgreSQL y Redis, con 2 vCPU y 4 GB de RAM como referencia habitual.- La estrategia de infraestructura propia reduce puntos únicos de fallo y dependencia de moderación o suspensión por terceros.- El caso de GrapheneOS sirve como ejemplo práctico para equipos que evalúan migrar de SaaS centralizado a self-hosting.

Qué pasó

El anuncio salió del canal oficial de comunicación del proyecto en Mastodon, no de un blog post ni de un comunicado de prensa. GrapheneOS usa esa cuenta para avisos de seguridad, novedades de compatibilidad con Pixel y, en este caso, una actualización operativa: el equipo dijo estar bien avanzado en convertir parte de su infraestructura a sistemas que administra directamente.

Es un patrón habitual en el proyecto: GrapheneOS es una organización sin fines de lucro que se financia con donaciones y evita depender de infraestructura corporativa que no controla, algo que ya se nota en tres piezas de su stack actual: el repositorio de aplicaciones, el servicio de atestación remota y la propia red social donde anuncia estos cambios.

Contexto e historia

GrapheneOS empezó como CopperheadOS y desde el inicio construyó su reputación sobre un principio simple: minimizar la superficie de confianza. Eso aplica al sistema operativo (hardening del kernel, sandboxing reforzado, verified boot) pero también a la infraestructura que sostiene el proyecto puertas afuera.

Dos ejemplos ya consolidados de esa filosofía de infraestructura propia: el repositorio en apps.grapheneos.org, compatible con el cliente de F-Droid, que distribuye Auditor, Vanadium y otras apps first-party sin pasar por Google Play ni por un mirror de terceros; y attestation.app, el servicio que permite que cualquier Pixel con GrapheneOS demuestre criptográficamente su estado de arranque contra un servidor que el propio proyecto opera de punta a punta.
Autoalojar el repositorio de apps y la atestación evita depender de terceros.
Que la cuenta de anuncios también corra en un servidor propio (grapheneos.social) en lugar de una instancia genérica cierra ese círculo: ningún canal crítico del proyecto depende de un tercero que pueda suspender la cuenta, cambiar términos de servicio o insertar telemetría no deseada.

Detalles técnicos: cómo se sostiene una infraestructura propia

Montar y sostener infraestructura propia como la de GrapheneOS implica decisiones concretas de arquitectura. En el caso de un servidor de Mastodon autoalojado, el stack mínimo combina un proxy inverso, el proceso web de Mastodon, el proceso de streaming (para la línea de tiempo en tiempo real) y dos almacenes de datos: PostgreSQL para el estado persistente y Redis para colas y caché.

flowchart TD
    A["Cliente Mastodon"] --> B["Nginx (proxy inverso)"]
    B --> C["Mastodon Web"]
    B --> D["Streaming API"]
    C --> E[("PostgreSQL")]
    C --> F[("Redis")]
    D --> F
    subgraph Backend
    C
    D
    E
    F
    end

Antes de tocar configuración, conviene ver cómo responde una instancia real. Este primer bloque consulta la API pública de grapheneos.social y devuelve la versión de Mastodon que corre:

curl -s https://grapheneos.social/api/v2/instance | jq '.version'

Ese comando no requiere autenticación ni cuenta: cualquier instancia de Mastodon expone su versión y metadata básica por diseño, parte del protocolo ActivityPub que usa la red.

Para levantar tu propia instancia, el bloque siguiente es un docker-compose.yml reducido a los tres servicios imprescindibles (sin colas de trabajo en background separadas, que en producción conviene aislar):

services:
  db:
    image: postgres:15-alpine
    restart: always
    environment:
      POSTGRES_USER: mastodon
      POSTGRES_PASSWORD: cambia_esta_clave
      POSTGRES_DB: mastodon_production
    volumes:
      - ./postgres:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    restart: always
    volumes:
      - ./redis:/data

  web:
    image: tootsuite/mastodon:v4.3.0
    restart: always
    env_file: .env.production
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis

Con esos tres servicios arriba (docker compose up -d), Mastodon queda escuchando en el puerto 3000 detrás de tu propio proxy. La base de datos y la caché nunca salen de tu red interna, algo que en un SaaS centralizado no podés garantizar.

Cómo empezar a probarlo

Para reproducir un entorno mínimo de infraestructura propia como la que usa GrapheneOS, el primer paso es tener Docker corriendo. Los comandos de instalación varían por sistema operativo:

# Linux (Debian/Ubuntu)
curl -fsSL https://get.docker.com | sh

# macOS (con Homebrew)
brew install --cask docker

# Windows (con winget)
winget install Docker.DockerDesktop

Una vez instalado Docker y con el docker-compose.yml del ejemplo anterior en una carpeta junto a un archivo .env.production con las claves generadas por bin/tootctl (secreto de aplicación, claves VAPID y credenciales OTP), el arranque es:

docker compose up -d
docker compose exec web bin/tootctl accounts create admin --email admin@tudominio.com --confirmed --role Owner

Para confirmar que la instancia levantó correctamente, la misma llamada que usamos antes contra grapheneos.social funciona contra tu propio servidor:

curl -s http://localhost:3000/api/v1/instance | jq '.title, .version'

Si el JSON devuelve el título y la versión configurados, la instancia está viva y federando según la configuración de LOCAL_DOMAIN del .env.production.

⚠️ Ojo: una instancia de Mastodon en producción, con envío de correo, backups y moderación real, necesita bastante más que este stack de tres contenedores: colas de Sidekiq separadas, almacenamiento de medios (S3 o disco dedicado) y un plan de actualización de versión. El ejemplo de arriba es para entender la arquitectura, no para exponer a internet sin ajustes.

Impacto y análisis

La diferencia entre depender de una plataforma de terceros y sostener infraestructura propia no es cosmética. Cuando GrapheneOS aloja su propia atestación remota en attestation.app, el proyecto controla el árbol de confianza completo: no hay un intermediario que pueda cambiar el resultado de una verificación de arranque. Lo mismo pasa con apps.grapheneos.org: al ser compatible con F-Droid, cualquier cliente puede verificar las firmas de los paquetes sin pasar por Google Play.

La contrapartida es el costo operativo. Autoalojar significa parchear servidores, monitorear disponibilidad, pagar ancho de banda y absorber picos de tráfico sin el colchón de un proveedor gestionado. Para un proyecto con presupuesto de donaciones, ese costo compite directamente con desarrollo del propio sistema operativo.
OpciónCuándo usarlaVentajaLimitaciónMastodon autoalojadoCuando el control total del dato y la moderación es prioritarioSin dependencia de terceros ni riesgo de suspensión externaRequiere mantenimiento, backups y monitoreo propiosInstancia de Mastodon de terceros (ej. mastodon.social)Cuando el objetivo es solo tener presencia, sin operar servidoresCero mantenimiento, arranque inmediatoSujeto a políticas y disponibilidad de un terceroRed basada en AT Protocol (ej. Bluesky)Cuando se prioriza portabilidad de identidad entre proveedoresLa cuenta y el grafo social son portables entre hostsEcosistema de self-hosting menos maduro que ActivityPubAutoalojar cambia mantenimiento por control total del dato.

💭 Clave: el mismo argumento que lleva a GrapheneOS a operar attestation.app en vez de delegarlo a un tercero es el que explica por qué también aloja su propio Mastodon: cada pieza de infraestructura que no controlás es un punto donde alguien más puede decidir por vos.

Qué sigue

El mensaje original no especifica un cronograma de cierre para esta conversión de infraestructura, así que lo verificable hoy es lo que el proyecto ya opera de forma propia: el repositorio de apps, el servidor de atestación y la instancia de Mastodon desde la que se hizo el anuncio. Cualquier detalle adicional sobre el sistema puntual que se está migrando dependerá de futuras publicaciones oficiales del proyecto en ese mismo canal.

Para equipos de desarrollo que siguen este caso como referencia, el paso lógico es auditar qué servicios propios dependen hoy de un SaaS de terceros y evaluar, servicio por servicio, si el costo operativo de autoalojar se justifica frente al riesgo de depender de un proveedor externo.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré curl -s https://grapheneos.social/api/v2/instance | jq '.version' ahora mismo para ver en vivo la instancia de Mastodon que GrapheneOS opera con su propia infraestructura.

Preguntas frecuentes

¿Qué es grapheneos.social?

Es la instancia de Mastodon que GrapheneOS opera y administra directamente, en lugar de usar mastodon.social o cualquier otro servidor de terceros para su cuenta oficial.

¿Qué otra infraestructura autoaloja GrapheneOS?

Al menos dos piezas documentadas públicamente: el repositorio de apps en apps.grapheneos.org (compatible con F-Droid) y el servicio de atestación remota en attestation.app.

¿Qué significa exactamente "convertir infraestructura interna" en este anuncio?

El mensaje disponible públicamente no detalla el sistema específico ni el destino de la migración; solo confirma que el proceso está bien avanzado.

¿Necesito una cuenta para consultar la API de una instancia de Mastodon?

No. Endpoints como /api/v2/instance son públicos por diseño del protocolo ActivityPub y no requieren autenticación.

¿Cuánto hardware necesito para autoalojar Mastodon?

Para una instancia pequeña, la documentación oficial recomienda como referencia habitual 2 vCPU y 4 GB de RAM, además de espacio en disco para PostgreSQL y almacenamiento de medios.

¿Por qué un proyecto de privacidad como GrapheneOS prioriza infraestructura propia?

Porque reduce la cantidad de terceros que pueden decidir sobre disponibilidad, moderación o acceso a los datos de sus propios servicios críticos.

Referencias

Publicación original en grapheneos.social: el anuncio oficial de GrapheneOS sobre la conversión de infraestructura interna.- GrapheneOS (sitio oficial): documentación del proyecto y sus principios de seguridad.- GrapheneOS en GitHub: repositorios de código fuente del sistema operativo y sus herramientas.- Guía oficial de instalación de Mastodon: documentación de referencia para autoalojar una instancia.

Nitter resiste el cese y desistimiento de X Corp del 24 de agosto

lu1tr0n — Sun, 06 Sep 2026 20:32:37 +0000

El 24 de agosto de 2026, X Corp envió cartas de cese y desistimiento exigiendo el cierre permanente de todas las instancias de Nitter y la eliminación de su repositorio en GitHub. Doce días después, el proyecto respondió con una sola línea en su README: tras recibir asesoría legal, Nitter continúa activo y promete más detalles pronto.

Nitter es un front-end alternativo y de código abierto para Twitter/X, pensado para navegar sin JavaScript, sin rastreo y sin publicidad. La confirmación llegó directamente en el commit 1428b4c del repositorio oficial, firmado por su creador, zedeus.

TL;DR

El 24 de agosto de 2026, X Corp envió cartas de cese y desistimiento a zedeus exigiendo cerrar Nitter y borrar su repositorio en GitHub.- Tras recibir asesoría legal, el proyecto confirmó que Nitter continúa activo; prometió más detalles próximamente.- El anuncio se publicó en el README, en el commit 1428b4c2b4246f92a7e5b2673438e5fb39fcc4a3 del repositorio oficial.- Nitter funciona sin JavaScript y sin anuncios; el navegador nunca habla directamente con los servidores de Twitter/X.- Para el perfil @nim_lang, la página de Nitter pesa 60 KB frente a los 784 KB de twitter.com.- El proyecto está bajo licencia AGPLv3, que prohíbe expresamente instancias propietarias cerradas.- El mismo commit sumó Ko-fi a las vías de donación, junto a GitHub Sponsors, Patreon y Liberapay.- El roadmap da por resuelto el soporte de embeds y deja pendientes cuentas con timeline y archivado de tweets.

Qué pasó

Un cese y desistimiento (cease and desist) es una carta legal que exige detener una actividad bajo amenaza de demanda; no es una demanda en sí misma, pero suele ser el paso previo. Según el commit que actualizó el README de Nitter, X Corp envió estas cartas el 24 de agosto de 2026 pidiendo dos cosas concretas: que se cerraran todas las instancias públicas de Nitter y que se eliminara el repositorio del proyecto en GitHub.

El README original solo describía la amenaza. La actualización posterior, la misma que analiza este artículo, agrega una nota corta pero decisiva: "Following legal advice, the Nitter project will continue". No se detalla todavía qué argumento legal respalda esa decisión, ni si hubo negociación directa con X Corp. El propio proyecto adelantó que compartirá más información en los próximos días.
Nitter carga perfiles y tuits sin JavaScript ni rastreo del navegador.

Contexto e historia

Nitter nació en 2019 como una alternativa liviana a Twitter, inspirada directamente en el proyecto Invidious, el front-end abierto para YouTube. La idea central es la misma en ambos casos: un servidor intermedio que consulta la API del servicio original y le entrega al usuario una página limpia, sin scripts de rastreo ni anuncios.

Durante años, Nitter dependió de tokens de invitado (guest tokens) de la API no oficial de Twitter, un mecanismo pensado para la app móvil que no exigía registrar una cuenta de desarrollador. Ese acceso se volvió más frágil a partir de 2023, cuando Twitter (ya rebautizada X) empezó a restringir el uso gratuito de su API. En 2024, buena parte de las instancias públicas de Nitter dejaron de responder cuando X bloqueó el flujo de tokens del que dependían, y solo un puñado de instancias mantenidas por voluntarios logró sobrevivir a fuerza de parches constantes.

El episodio de agosto de 2026 es distinto en un punto importante: la amenaza no apunta solo a instancias individuales, algo que ya había pasado antes, sino al repositorio y al proyecto como tal. Es la primera vez que X Corp intenta cerrar Nitter en su origen y no solo en sus copias públicas.

Detalles técnicos y rendimiento

Lo que hace de Nitter algo más que un simple espejo de Twitter/X es su arquitectura: el navegador del usuario nunca se conecta a los servidores de X, solo a la instancia de Nitter, que actúa como intermediaria. Esto tiene consecuencias directas en privacidad y en peso de página.

Sin JavaScript obligatorio: la interfaz se genera en HTML del lado del servidor.- Cero anuncios: no hay integración con la red publicitaria de X.- Aislamiento del cliente: todas las peticiones pasan por el backend de Nitter, así que X nunca ve la IP ni la huella digital del navegador del usuario final.- API no oficial: usa el mismo acceso que la app móvil de Twitter, sin necesidad de cuenta de desarrollador.- Peso reducido: para el perfil @nim_lang, Nitter pesa 60 KB frente a los 784 KB que carga la versión oficial de twitter.com, según cifras publicadas en el propio repositorio.- RSS por instancia: cada instancia puede exponer feeds RSS, aunque muchas los desactivan por abuso de scraping.- Licencia AGPLv3: obliga a que cualquier fork, incluso corriendo como servicio web, publique su código fuente. La AGPLv3 es justamente la licencia elegida para impedir instancias propietarias cerradas.

Así se ve el flujo de una petición típica: el cliente nunca toca los servidores de X, solo la instancia de Nitter.

flowchart TD
    A["Navegador del usuario"] --> B["Instancia Nitter"]
    B --> C["API no oficial de Twitter/X"]
    B --> D[("Cache Redis")]
    subgraph Backend
    B
    D
    end

OpciónCuándo usarlaVentajaLimitaciónInstancia pública de NitterConsulta rápida sin instalar nadaCero configuraciónDepende de que alguien más la mantenga en pieInstancia propia (self-host)Uso frecuente o para un equipoControl total y disponibilidad propiaRequiere mantenimiento y expone al operador a riesgo legalTwitter/X oficialCuando se necesita interactuar (publicar, comentar)Funcionalidad completaJavaScript, anuncios y rastreo activados

Cómo probarlo

Nitter puede levantarse localmente con Docker Compose en minutos. Esta es la configuración mínima, con Redis como caché obligatorio:

version: "3.8"
services:
  nitter:
    image: zedeus/nitter:latest
    ports:
      - "8080:8080"
    volumes:
      - ./nitter.conf:/src/nitter.conf:ro
    depends_on:
      - nitter-redis
    restart: unless-stopped
  nitter-redis:
    image: redis:7-alpine
    command: redis-server --save '' --appendonly no
    restart: unless-stopped

Con eso arriba, docker compose up -d levanta el servicio en localhost:8080. El siguiente paso es escribir el archivo nitter.conf que ese contenedor monta como solo lectura, con la configuración real de la instancia:

[Server]
address = "0.0.0.0"
port = 8080
httpMaxConnections = 100
staticDir = "./public"
title = "mi-instancia"
hostname = "nitter.midominio.dev"
https = true

[Cache]
redisHost = "nitter-redis"
redisPort = 6379
listMinutes = 240
rssMinutes = 10

[Config]
hmacKey = "cambiar-por-una-clave-generada-con-openssl"
enableRSS = true
enableDebug = false

[Preferences]
replaceTwitter = "nitter.midominio.dev"
proxyVideos = true

La clave hmacKey conviene generarla con openssl rand -hex 32 antes de exponer la instancia a internet. En Windows, macOS y Linux el flujo es idéntico porque todo corre dentro de contenedores: solo cambia el binario de Docker Desktop (Windows/macOS) o Docker Engine (Linux).

Para confirmar que la instancia responde correctamente, basta con pedir la cabecera HTTP de la página de estado:

curl -sI https://nitter.midominio.dev/about | head -n 1
# HTTP/1.1 200 OK confirma que la instancia esta activa

⚠️ Ojo: operar una instancia pública de Nitter implica hacer scraping de la API no oficial de X, algo que puede tener consecuencias legales según la jurisdicción. Revisá los términos de servicio locales antes de exponerla a internet.

Impacto y análisis

El anuncio de continuidad es una buena noticia para periodistas, investigadores y usuarios que dependen de Nitter para acceder a contenido público de X sin crear cuenta ni exponerse a rastreo. También es una señal para el resto del ecosistema de front-ends alternativos (a YouTube, a Reddit, a Instagram): la amenaza legal directa al repositorio, y no solo a las instancias, marca un precedente que otros proyectos similares van a mirar de cerca.

La licencia AGPLv3 del proyecto juega un rol clave acá. Aunque X Corp lograra forzar el cierre del repositorio principal en GitHub, cualquier fork existente conserva el derecho legal a seguir publicando el código, siempre que mantenga la misma licencia. Es una protección estructural, no una garantía de que no haya consecuencias para zedeus como individuo.

💭 Clave: la amenaza legal no cambia la dependencia técnica de fondo: Nitter sigue funcionando porque X no ha bloqueado por completo el acceso que usa, no porque tenga un acuerdo con la empresa.

Ahí está la limitación honesta de esta historia: la continuidad legal del proyecto no resuelve el problema técnico de fondo. Nitter depende de una API no documentada que X puede cerrar en cualquier momento, como ya pasó parcialmente en 2024. Ganar la batalla legal no evita que una decisión técnica unilateral de X vuelva a tumbar instancias de un día para otro.

Qué sigue

El propio README promete "más detalles pronto", sin fecha concreta. Lo que hay que observar en las próximas semanas: si zedeus publica el argumento legal usado para resistir el cese y desistimiento, si X Corp escala a una demanda formal, y si el proyecto anuncia cambios operativos (por ejemplo, mover el repositorio a otro forge o modificar cómo se distribuyen las instancias públicas). El commit también sumó Ko-fi a las vías de donación existentes (GitHub Sponsors, Patreon, Liberapay), lo que sugiere que financiar una eventual defensa legal es parte de la conversación.

💡 Tip: si querés apoyar al proyecto, las cuatro vías activas hoy son GitHub Sponsors, Patreon, Liberapay y Ko-fi, todas enlazadas desde el repositorio oficial.

📖 Resumen en Telegram: Ver resumen

Probalo vos: cloná el repositorio con git clone https://github.com/zedeus/nitter y levantá tu propia instancia hoy con el docker-compose de arriba.

Preguntas frecuentes

¿Qué es exactamente un cese y desistimiento?

Es una carta legal donde una parte exige que otra detenga una actividad específica bajo amenaza de acción judicial. No implica una demanda automática, pero suele ser el paso previo si no hay respuesta.

¿Nitter sigue funcionando hoy?

Sí. Según el README oficial actualizado el 24 de agosto de 2026, el proyecto continúa activo tras recibir asesoría legal, aunque todavía no publicó los detalles completos de esa decisión.

¿Es legal usar una instancia pública de Nitter?

Depende de la jurisdicción y de los términos de servicio que aplique cada usuario final. Usar una instancia como lector es distinto, legalmente, a operar una instancia que hace scraping constante de la API de X.

¿Necesito una cuenta de Twitter/X para usar Nitter?

No. Nitter usa la API no oficial que la app móvil de Twitter/X expone sin requerir autenticación de desarrollador, por eso no hace falta cuenta ni token propio.

¿Cómo dono para apoyar el proyecto?

El repositorio lista cuatro vías activas: GitHub Sponsors, Patreon, Liberapay y, desde este mismo commit, Ko-fi.

¿Qué pasa si quiero armar mi propia instancia?

Podés seguir la guía de Docker Compose de este artículo. Tené en cuenta el aviso legal: operar una instancia pública implica scraping continuo de X, con el riesgo que eso conlleva según tu jurisdicción.

Referencias

Commit 1428b4c en zedeus/nitter: actualización del README que confirma la continuidad del proyecto tras el cese y desistimiento.- Repositorio oficial de Nitter: código fuente, features y roadmap del proyecto.- Guía de embeds de Nitter: documentación de la función de embeds mencionada en el roadmap.- Invidious: el proyecto que inspiró la arquitectura de Nitter para YouTube.- Licencia AGPLv3: los términos bajo los que se distribuye Nitter.

La automejora recursiva de la IA avanza más lento de lo previsto

lu1tr0n — Sun, 06 Sep 2026 16:21:30 +0000

En 1965, el matemático británico I.J. Good escribió que una máquina capaz de diseñar máquinas mejores que ella misma desataría una "explosión de inteligencia" imparable. Sesenta años después, un análisis publicado por MIT Technology Review el 18 de agosto de 2026 concluye que esa explosión sigue sin llegar.

El reportaje repasa por qué la automejora recursiva (recursive self-improvement o RSI), la idea de que un sistema de IA entrena a su propio sucesor sin intervención humana, avanza mucho más despacio de lo que anticipaban quienes apostaban por un despegue rápido hacia la superinteligencia.

TL;DR

MIT Technology Review publicó el 18 de agosto de 2026 un análisis que cuestiona la velocidad de la automejora recursiva en sistemas de IA.- La idea de la "explosión de inteligencia" proviene de un texto de 1965 del matemático I.J. Good.- Sistemas actuales como el Darwin Gödel Machine de Sakana AI ya editan su propio código, pero de forma acotada y supervisada.- Los cuellos de botella identificados incluyen el costo de cómputo creciente, la escasez de datos nuevos de calidad y la falta de evaluación externa objetiva.- AutoML-Zero (Google, 2020) demostró que buscar arquitecturas desde cero funciona, pero con un costo computacional que escala con el espacio de búsqueda.- El riesgo técnico central es el sobreajuste a benchmarks propios cuando el mismo sistema genera y evalúa sus mejoras.- El debate divide a la comunidad de IA entre quienes ven una meseta de rendimiento y quienes sostienen que el despegue rápido solo se retrasó.

Qué pasó

El artículo de MIT Technology Review, publicado el 18 de agosto de 2026, plantea una pregunta directa: si los laboratorios de IA llevan años prometiendo sistemas capaces de mejorarse a sí mismos sin ayuda humana, ¿por qué la automejora recursiva no se traduce todavía en el despegue exponencial que predecían los teóricos de la singularidad?

El texto ubica el debate en 2026. Es el año en que varios laboratorios, incluidos los que financia la iniciativa estadounidense Genesis Mission con 5.000 millones de dólares para IA aplicada a la ciencia, apuestan a que la propia IA acelere su investigación futura. La National Science Foundation también construye infraestructura de cómputo específica para investigación en IA, según reportó Government Executive el mismo mes. El argumento central del análisis es otro: la automejora recursiva en sentido estricto, un sistema que entrena, evalúa y despliega a su sucesor sin intervención humana, todavía no se observa a la escala que predecía la teoría del despegue rápido.
La automejora recursiva supone que un sistema entrena a su sucesor sin intervención humana.

Contexto e historia

De 1965 a la singularidad

El concepto no es nuevo. I.J. Good, criptógrafo que trabajó junto a Alan Turing en Bletchley Park, escribió en 1965 que una "máquina ultrainteligente" podría diseñar máquinas todavía mejores, generando una explosión de inteligencia que dejaría atrás cualquier capacidad humana de control. En 1993, el matemático y escritor Vernor Vinge popularizó la idea bajo el nombre de "singularidad tecnológica". Nick Bostrom retomó el debate en su libro Superintelligence, distinguiendo entre un "despegue rápido" (cuestión de días o meses) y un "despegue lento" (cuestión de años o décadas).

La pregunta que plantea el análisis de 2026 es en qué punto de ese espectro está realmente la tecnología actual. La automejora recursiva, en su forma más pura, requiere que un sistema no solo genere mejoras candidatas, sino que además las evalúe y las adopte sin que un humano revise el resultado.

Los intentos reales, generación por generación

Varios proyectos ya exploran versiones acotadas de esta idea. AutoML-Zero, publicado por investigadores de Google en 2020, mostró que un sistema de búsqueda evolutiva puede descubrir desde cero algoritmos de aprendizaje automático competitivos, sin partir de arquitecturas diseñadas por humanos. AlphaZero y sus sucesores demostraron que el autojuego (self-play) permite a un sistema superar el nivel humano en juegos de información perfecta sin ver una sola partida jugada por personas. Más recientemente, Sakana AI presentó el Darwin Gödel Machine, un agente que reescribe su propio código fuente para mejorar su desempeño en tareas de programación, evaluando cada versión contra un conjunto de benchmarks antes de adoptarla.

Detalles técnicos y rendimiento de la automejora recursiva

Técnicamente, un ciclo de automejora recursiva necesita tres piezas: un generador de variantes, un evaluador y un mecanismo de selección. El generador propone cambios al modelo, al código o a la arquitectura. El evaluador mide si la variante es mejor. El mecanismo de selección decide si esa variante reemplaza a la versión anterior. El diagrama siguiente resume ese ciclo:

flowchart TD
    A["Modelo base"] --> B["Genera una mejora candidata"]
    B --> C["Evalua la mejora en un benchmark fijo"]
    C --> D{"Mejora el puntaje?"}
    D -->|"Si"| E["Adopta la nueva version"]
    D -->|"No"| F["Descarta y ajusta la busqueda"]
    E --> A
    F --> B

La siguiente tabla compara los enfoques que hoy se usan como aproximaciones parciales a la automejora recursiva, cada uno con una limitación práctica distinta:
EnfoqueQué mejoraEjemplo conocidoLimitación prácticaBúsqueda de arquitecturas (AutoML/NAS)La arquitectura del modeloAutoML-Zero (Google, 2020)El costo de cómputo crece con el tamaño del espacio de búsquedaAutojuego (self-play)La política de decisiónAlphaZero y sus sucesoresFunciona bien solo en entornos con una señal de recompensa claraAutoedición de códigoEl propio código del agenteDarwin Gödel Machine (Sakana AI)Riesgo de sobreajustar a sus propios benchmarks de evaluaciónDestilación generacionalLos pesos del modelo sucesorEsquemas profesor-alumnoLa calidad del alumno queda acotada por la señal del profesor

⚠️ Ojo: cuando el mismo sistema que propone una mejora también decide si esa mejora es buena, el resultado tiende a sobreajustarse al criterio propio en lugar de mejorar en el mundo real. Por eso todo sistema de automejora recursiva serio necesita un benchmark externo y fijo que el generador nunca pueda modificar.

Un ciclo simplificado, sin ningún componente de IA real, ayuda a entender la mecánica de fondo. El siguiente ejemplo simula una búsqueda de tipo "hill climbing" que conserva la mejor variante encontrada:

def generar_variante(programa):
    return programa + '  # variante generada'

def evaluar(programa, benchmark):
    return benchmark(programa)

mejor_programa = programa_inicial
mejor_puntaje = evaluar(mejor_programa, benchmark_tareas)

for iteracion in range(20):
    candidato = generar_variante(mejor_programa)
    puntaje = evaluar(candidato, benchmark_tareas)
    if puntaje > mejor_puntaje:
        mejor_programa, mejor_puntaje = candidato, puntaje

print('Mejor puntaje tras 20 iteraciones:', mejor_puntaje)

Este bucle solo conserva una variante si supera a la anterior en el mismo benchmark. Con 20 iteraciones y un benchmark simple, el puntaje final debería ser igual o mayor al inicial. Si no mejora nada, es señal de que el generador de variantes no está explorando cambios útiles: el mismo problema de fondo que describe el análisis de MIT Technology Review a mayor escala.

Cómo probarlo

Para experimentar con un ciclo de automejora aplicado a código real, el patrón más simple es combinar una suite de tests con llamadas a un modelo de lenguaje que proponga correcciones cuando los tests fallan:

import subprocess

def pedir_mejora_al_modelo(codigo_actual, resultados_tests):
    contexto = 'Código actual y tests que fallan:'
    prompt = contexto + ' ' + codigo_actual + ' ' + resultados_tests + ' Proponé una version corregida que pase los tests.'
    return llamar_llm(prompt)

def correr_tests():
    resultado = subprocess.run(['pytest', '-q'], capture_output=True, text=True)
    return resultado.returncode == 0, resultado.stdout

codigo = leer_archivo('agente.py')
for ronda in range(5):
    ok, salida = correr_tests()
    if ok:
        break
    codigo = pedir_mejora_al_modelo(codigo, salida)
    escribir_archivo('agente.py', codigo)

La función llamar_llm representa cualquier cliente de API de un modelo de lenguaje. El punto clave no es qué proveedor se use, sino que correr_tests() siempre se ejecuta contra la misma suite fija, sin que el modelo pueda editarla. Eso es lo que evita que el generador haga trampa reescribiendo también el criterio de evaluación.

Para verificar si una ronda realmente mejoró el desempeño, y no solo el puntaje que el propio modelo reporta, conviene guardar el resultado contra un conjunto de pruebas separado ("held out") que nunca se le muestra al modelo generador, y comparar ambos puntajes con un comando simple, por ejemplo python benchmark.py --version v3 --set held_out. Si el puntaje sobre el conjunto reservado no sube al mismo ritmo que el de entrenamiento, hay sobreajuste.
Sakana AI probó agentes que reescriben su propio código de forma acotada.

Impacto y análisis

Si la automejora recursiva avanza más despacio de lo previsto, las consecuencias no son solo académicas. Buena parte del capex de IA anunciado en 2026 asume que la propia IA acelerará su propia investigación. Eso incluye programas como la Genesis Mission de Estados Unidos y el refuerzo de infraestructura de la NSF. Si ese efecto compuesto tarda más en llegar, los cronogramas de esas apuestas también deberían ajustarse.

💭 Clave: hay una diferencia importante entre "la IA hace más productivos a los investigadores humanos" (algo que ya ocurre, con herramientas de código asistido por agentes) y "la IA entrena a su sucesor sin humanos en el ciclo" (la definición estricta de automejora recursiva). Lo primero es real hoy; lo segundo sigue siendo, en gran medida, una proyección.

El análisis también toca un punto sensible: la dificultad de medir progreso cuando el propio sistema evaluado participa en diseñar su métrica. Es el mismo problema de fondo que motivó, en paralelo, un trabajo académico distinto. En agosto de 2026, la Seoul National University of Science and Technology presentó un marco para poner a prueba la robustez de sistemas de visión por computadora frente a variaciones que el propio modelo no generó.

Qué sigue

El propio reportaje deja la puerta abierta a que la automejora recursiva sí llegue, pero por un camino más gradual: mejoras compuestas, donde un modelo ligeramente mejor entrena a la siguiente generación con datos ligeramente mejores, en lugar de un salto discontinuo. En paralelo, crece el interés en investigación centrada en la colaboración humano-IA en lugar de la sustitución total. Un equipo de Carnegie Mellon University publicó en agosto de 2026 un estudio que plantea a los humanos y la IA como "compañeros de equipo" en tareas de investigación, un enfoque que no depende de que el sistema se automejore solo.

Lo más probable, a corto plazo, es que el debate se resuelva con más papers empíricos que midan directamente cuánto mejora un sistema entrenado por su predecesor sin intervención humana, en lugar de extrapolaciones teóricas sobre curvas de escalado.

📖 Resumen en Telegram: Ver resumen

Probalo vos: cloná un proyecto pequeño con una suite de tests automatizados, armá un bucle de cinco rondas como el del ejemplo de arriba y compará el puntaje contra un conjunto de pruebas reservado que nunca le muestres al modelo generador.

Preguntas frecuentes

¿Qué es la automejora recursiva (recursive self-improvement)?

Es la idea de que un sistema de inteligencia artificial puede diseñar, entrenar y desplegar una versión mejorada de sí mismo sin que un humano intervenga en ese ciclo, generación tras generación.

¿De dónde viene la idea de una "explosión de inteligencia"?

El matemático I.J. Good la planteó en 1965: una máquina "ultrainteligente" podría diseñar máquinas todavía mejores, en una cadena que se aceleraría sola.

¿Qué encontró el análisis de MIT Technology Review?

Que la automejora recursiva, en su forma estricta, avanza mucho más despacio de lo que predecían los defensores de un despegue rápido, por cuellos de botella técnicos concretos como el costo de cómputo y la falta de evaluación externa objetiva.

¿Hay sistemas que ya se automejoren hoy?

Existen aproximaciones parciales y supervisadas, como AutoML-Zero, AlphaZero y el Darwin Gödel Machine de Sakana AI, pero ninguno opera sin algún tipo de benchmark o supervisión fijados por humanos.

¿Cuál es el principal riesgo técnico de estos sistemas?

Que el mismo sistema que genera una mejora también la evalúe, lo que favorece el sobreajuste a un criterio propio en lugar de una mejora real y generalizable.

¿Esto significa que la superinteligencia no va a llegar?

No necesariamente. El análisis sugiere que el camino sería más gradual y compuesto, con mejoras incrementales entre generaciones, en lugar del despegue exponencial y discontinuo que planteaba la teoría original.

Referencias

MIT Technology Review: el análisis original sobre por qué la automejora recursiva de la IA avanza más lento de lo esperado.- Wikipedia: definición y contexto histórico del concepto de automejora recursiva.- Wikipedia: origen del concepto de explosión de inteligencia a partir del texto de I.J. Good de 1965.- Sakana AI: laboratorio detrás del Darwin Gödel Machine, un agente que edita su propio código fuente.

Pangram 4: el detector de texto de IA que ya casi no falla

lu1tr0n — Sun, 06 Sep 2026 14:27:37 +0000

El 78% de los desarrolladores deja de leer un texto apenas sospecha que lo escribió una IA, y el 71% evita al autor para siempre, según una encuesta a 668 desarrolladores citada por Bryan Cantrill, CTO de Oxide Computer.

Cantrill publicó The revolt of the reader el 5 de septiembre de 2026 y pone en el centro a Pangram 4, el detector de texto generado por IA de Pangram Labs, con una precisión que describe como sorprendentemente alta.

TL;DR

El 78% de los desarrolladores deja de leer si detecta IA, y el 71% evita al autor después.
El 98% de los encuestados prefiere un texto propio imperfecto antes que uno pulido por IA.
Bryan Cantrill publicó "The revolt of the reader" el 5 de septiembre de 2026 en su blog.
Pangram Labs lanzó Pangram 3 a fines de 2025 y Pangram 4 hace poco más de un mes.
Cantrill compara la detección de texto con IA con la guerra contra el spam de los 2000.
RFD 576 de Oxide Computer dice que usar IA para escribir anula el contrato social lector-autor.

Qué pasó

Bryan Cantrill escribe ensayos largos en dtrace.org desde hace más de una década, casi siempre sobre ingeniería de sistemas y cultura de trabajo en Oxide Computer. El publicado el 5 de septiembre de 2026 rompe ese patrón: en vez de hablar de hardware o de Rust, habla de por qué dejó de confiar en textos ajenos.

Su punto de partida es personal. Cantrill dice notar señales evidentes en textos con ayuda sustancial de un LLM: frases de transición vacías, afirmaciones que se autoelogian ("y por eso este enfoque importa") y una uniformidad de ritmo que un lector entrenado detecta en segundos. Antes esa sospecha era subjetiva. Ahora, dice, hay una herramienta que la confirma: Pangram 4.

El propio Cantrill había anticipado buena parte de este argumento en RFD 576, un documento interno de diseño de Oxide Computer: escribir con ayuda sustancial de una IA, sin que el lector lo sepa, anula el contrato social entre autor y lector. Ese contrato, dice, obliga al lector a esforzarse por entender una oración solo si el autor también se esforzó por escribirla.

Pangram Labs lanzó Pangram 3 a fines de 2025. Cantrill lo adoptó como herramienta diaria y reporta una tasa de falsos positivos muy baja: cuando el modelo marcaba un texto como mayormente escrito por IA, la sospecha se confirmaba casi siempre. Hace poco más de un mes la empresa lanzó Pangram 4, que Cantrill describe como un salto de tipo step-function sobre su predecesor, con una tasa de falsos positivos aún más baja y también menos falsos negativos.

Pangram Labs lanzó su primer modelo, Pangram 3, a fines de 2025.

Contexto: la guerra contra el spam se repite

Cantrill traza un paralelo directo con el correo no deseado. A inicios de los 2000 muchos temieron que el spam terminara con el correo electrónico como herramienta útil: la bandeja de entrada se volvía inutilizable. La bisagra llegó a fines de esa década, cuando el filtrado de spam mejoró lo suficiente como para romper la economía del spammer: enviar correo masivo dejó de ser rentable si nadie lo veía.

Ese cambio trajo un efecto secundario importante: ser etiquetado como spam pasó a tener un costo altísimo. Hoy una empresa que cae en listas negras de correo puede perder su dominio y su reputación en cuestión de días. Cantrill sostiene que algo parecido puede pasarle a la escritura asistida por IA sin declarar: a medida que detectores como Pangram 4 se vuelven confiables, ser identificado como autor de texto generado por IA empieza a tener el mismo costo reputacional que ser marcado como spam.

La diferencia es que el filtro no lo aplica un servidor de correo: lo aplica el propio lector, en tiempo real, decidiendo si sigue leyendo o cierra la pestaña.

Cómo funciona Pangram 4 y otros detectores de texto con IA

Pangram Labs no publica el detalle exacto de su clasificador, pero la familia de técnicas detrás de este tipo de herramientas es conocida. Un detector típico combina tres señales:

Perplejidad: qué tan predecible es cada palabra siguiente según un modelo de lenguaje de referencia. El texto generado por un LLM suele elegir sistemáticamente la palabra más probable, lo que produce una perplejidad más baja y estable que la prosa humana.
Burstiness: la variación en la longitud y complejidad de las oraciones. Un humano alterna oraciones largas y cortas de forma irregular; un LLM tiende a un ritmo más uniforme.
Huella estilística: repetición de conectores y muletillas típicas de un LLM ("cabe destacar", "es importante señalar", "en resumen"), estructura de párrafo muy simétrica y transiciones que se auto-explican.

Con esas señales, el clasificador se entrena con millones de ejemplos etiquetados como humanos o generados por IA, y aprende a separar ambas distribuciones. El resultado es un puntaje de probabilidad, no una certeza binaria: por eso Cantrill insiste en mirar la tasa de falsos positivos y falsos negativos del modelo, no solo su existencia.

El siguiente diagrama resume el flujo típico de este tipo de clasificadores:

flowchart TD
    A["Texto sin firmar"] --> B["Extraccion de senales: perplejidad, burstiness, estilo"]
    B --> C["Clasificador entrenado con texto humano y de LLM"]
    C --> D{"Puntaje de probabilidad"}
    D -->|"alto"| E["Marcado como generado por IA"]
    D -->|"bajo"| F["Marcado como humano"]

Ninguna de estas señales es infalible por separado. Lo que hace fuerte a un clasificador como Pangram 4 es combinarlas y entrenarlas contra una base de datos enorme y actualizada de ejemplos reales, algo que una heurística casera no puede igualar.

La varianza en longitud de oraciones es una de las señales que buscan estos clasificadores.

Cómo probarlo: heurísticas DIY antes de publicar

No hace falta pagar por Pangram 4 para hacer una primera pasada de control sobre un borrador. Una heurística simple de burstiness, calculada con la varianza en la longitud de las oraciones, ya sirve como alerta temprana. No reemplaza a un clasificador entrenado, pero ayuda a detectar párrafos sospechosamente uniformes antes de publicarlos.

Este primer ejemplo calcula la varianza de un párrafo suelto:

def burstiness(texto):
    oraciones = [s.strip() for s in texto.split(".") if s.strip()]
    largos = [len(s.split()) for s in oraciones]
    promedio = sum(largos) / len(largos)
    varianza = sum((l - promedio) ** 2 for l in largos) / len(largos)
    return varianza

texto_ejemplo = "El texto humano tiende a variar mucho. A veces una oracion es larga y con varias ideas encadenadas. A veces no."
print(burstiness(texto_ejemplo))

Una varianza baja (oraciones de longitud muy parecida) es una señal de alerta; una varianza alta sugiere un ritmo más humano. El siguiente ejemplo aplica la misma idea a un archivo completo, párrafo por párrafo, algo útil para revisar un borrador largo antes de publicarlo:

import statistics
import re

def analizar_parrafos(ruta_archivo):
    with open(ruta_archivo, encoding="utf-8") as f:
        contenido = f.read()

    parrafos = [p for p in contenido.split("\n\n") if p.strip()]
    for i, parrafo in enumerate(parrafos, start=1):
        oraciones = re.split(r"(? {alerta}")

analizar_parrafos("borrador.md")

Para confirmar que la señal funciona, corré el script sobre un texto que sepas que escribiste vos mismo y sobre una respuesta larga sin editar de un chatbot: si la varianza del segundo es sistemáticamente más baja, la heurística está capturando la señal que buscás. Es la misma verificación que hace cualquier equipo antes de confiar en un modelo: probarlo contra casos de origen conocido.

⚠️ Ojo: ningún detector es infalible. Pangram Labs reconoce una tasa de falsos negativos más alta de la deseada: un texto puede pasar el filtro sin ser enteramente humano. No uses un solo detector, propio o comercial, como prueba definitiva contra un autor.

Impacto y análisis

El dato más incómodo del ensayo de Cantrill no es sobre los detectores, sino sobre los lectores. El 98% de los desarrolladores encuestados dijo preferir un texto propio, con errores, antes que uno pulido por una IA. Eso contradice el argumento más común a favor de usar un LLM para escribir: que mejora la calidad. Para el lector, la autenticidad pesa más que la prolijidad.

La siguiente tabla compara los enfoques disponibles hoy para detectar o prevenir texto generado por IA sin declarar:

EnfoqueCómo funcionaVentajaLimitación

Clasificador propietario (Pangram 4)Modelo entrenado con millones de ejemplos humanos y de LLMMuy baja tasa de falsos positivos, según CantrillCódigo y datos de entrenamiento no son públicos
Heurística de burstiness (DIY)Mide la varianza en longitud de oracionesGratis, corre local, sin dependencias externasFácil de esquivar variando el ritmo a mano
Watermarking del generadorEl modelo marca su propia salida al generarlaDetección casi binaria si el generador cooperaInútil si el autor edita el texto o usa un modelo sin marca
Revisión humana expertaUn lector frecuente reconoce tics de estiloNo depende de ninguna herramienta externaNo escala más allá de unos pocos textos por día

El trade-off central es honesto y Cantrill lo reconoce: los detectores como Pangram 4 minimizan falsos positivos a costa de dejar pasar algunos textos generados por IA (falsos negativos). Para un editor esto significa que un puntaje bajo no es garantía de autoría humana; es solo evidencia insuficiente para acusar.

💭 Clave: el paralelo con el spam no es solo retórico. Cuando el costo de ser detectado supera el beneficio de ahorrar tiempo escribiendo, el comportamiento cambia. Eso fue lo que pasó con el spam de correo a fines de los 2000, y es la apuesta de Cantrill para el texto generado por IA.

Qué sigue

Si la analogía de Cantrill se sostiene, el próximo paso lógico es que plataformas de publicación y comunidades técnicas empiecen a correr detectores como Pangram 4 de forma rutinaria antes de aceptar un artículo, igual que hoy cualquier servidor de correo corre un filtro de spam antes de entregar un mensaje a la bandeja de entrada.

Eso no resuelve el problema de fondo: un autor puede seguir usando una IA para investigar, ordenar ideas o revisar gramática sin que el texto final se lea como generado. El punto de Cantrill no es prohibir el uso de IA en el proceso de escritura, sino que el resultado final refleje trabajo propio del autor, aunque sea imperfecto.

Para comunidades como Hacker News, donde según los datos citados el 78% de los lectores abandona apenas detecta IA, la presión ya es real: publicar con ayuda evidente de un LLM deja de ser una decisión neutral y empieza a tener un costo reputacional medible.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré la función de burstiness de este artículo sobre tu último borrador y compará el resultado contra un párrafo que sepas que es 100% tuyo.

Preguntas frecuentes

¿Qué es Pangram 4?

Es la última versión del detector de texto generado por IA de Pangram Labs, lanzada poco más de un mes antes del ensayo de Cantrill del 5 de septiembre de 2026, con una precisión que Cantrill describe como un salto notable sobre Pangram 3.

¿Pangram Labs es gratuito?

El research disponible no detalla precios públicos; Pangram Labs ofrece su detector como servicio orientado a editores y plataformas, así que conviene consultar directamente en su sitio oficial para conocer planes actuales.

¿Por qué el 78% de los desarrolladores abandona un texto con IA?

Según la encuesta citada por Cantrill, los lectores no rechazan la imperfección sino la falta de autenticidad: prefieren un texto propio con errores antes que uno pulido artificialmente.

¿Se puede engañar a un detector de texto generado por IA?

Sí, editando manualmente el ritmo de las oraciones o reescribiendo pasajes se reduce la señal que buscan estos clasificadores, aunque Cantrill reporta que Pangram 4 mantiene una tasa de falsos negativos baja incluso así.

¿Qué es RFD 576 de Oxide Computer?

Es un documento interno de diseño de Oxide Computer, la empresa donde Cantrill es cofundador y CTO, donde argumenta que usar una IA para escribir anula el contrato social entre autor y lector.

¿Qué relación hay entre esto y el spam de correo?

Cantrill compara la maduración de los detectores de texto con IA con la mejora del filtrado de spam a fines de los 2000: en ambos casos, cuando la detección se vuelve confiable, el costo reputacional de ser marcado supera el beneficio de la práctica.

Referencias

The revolt of the reader, de Bryan Cantrill: el ensayo original sobre la revuelta del lector contra el texto generado por IA.
Pangram Labs: la empresa detrás de Pangram 3 y Pangram 4, los detectores de texto generado por IA mencionados en el ensayo.
Email spam, en Wikipedia: contexto histórico de la guerra contra el spam que Cantrill usa como analogía.
Oxide Computer Company: la empresa donde Cantrill es cofundador y CTO, origen del documento interno RFD 576 citado en el ensayo.

78% de los desarrolladores abandona un texto si detecta escritura de IA

lu1tr0n — Sun, 06 Sep 2026 08:22:31 +0000

El 78% de los desarrolladores deja de leer un texto apenas detecta que lo escribió una inteligencia artificial, según una encuesta a 668 developers citada por el ingeniero Bryan Cantrill. El dato aparece en "The revolt of the reader", un ensayo que Cantrill publicó el 5 de septiembre de 2026 en su blog personal.

Cantrill, cofundador y CTO de Oxide Computer Company y uno de los creadores de DTrace, describe algo que llama la revuelta del lector: un rechazo silencioso pero creciente hacia la escritura generada por ia que circula sin aviso en blogs técnicos, redes sociales y hasta documentación de producto.

TL;DR

Bryan Cantrill publicó "The revolt of the reader" el 5 de septiembre de 2026 en bcantrill.dtrace.org.- Encuesta de Cynthia Dunlop a 668 developers: el 78% abandona la lectura al detectar texto de IA.- El 71% de esos lectores evita al mismo autor en publicaciones futuras.- El 98% prefiere un texto propio, imperfecto, antes que uno pulido por IA.- Pangram Labs lanzó Pangram 3 a fines de 2025 y Pangram 4 hacia fines de julio de 2026.- Cantrill compara la ola de escritura con IA con la crisis del spam de e-mail de los 2000.- El ensayo cita la RFD 576 de Oxide: usar IA para escribir anula el contrato social con el lector.

Qué pasó

El ensayo arranca con una confesión personal: Cantrill dice sentir exasperación al ver a colegas que respeta firmar piezas con marcas evidentes de haber sido escritas, o muy asistidas, por un modelo de lenguaje. Su pregunta central tiene dos ramas: ¿los autores creen que los lectores no pueden notarlo, o simplemente no les importa?

Su respuesta a la primera pregunta es tajante: los lectores frecuentes sí lo notan. Compara las marcas estructurales de la escritura generada por ia con dejarse la bragueta intelectual abierta, algo tan evidente para quien lee mucho que resulta difícil no verlo. Llega a confesar, medio en broma, que fantaseó con condenar a los autores de los textos más flagrantes a leerlos en voz alta ante público, convencido de que ni ellos mismos soportarían escuchar lo que publicaron.

A la segunda pregunta responde con los números de la encuesta de Cynthia Dunlop: de 668 developers encuestados, el 78% corta la lectura de inmediato al detectar el patrón, en lo que Cantrill describe como una especie de mecanismo de autopreservación cerebral que expulsa al lector a mitad de oración. El 71% de esas personas evita además al mismo autor en el futuro.

El dato más incómodo para quienes usan IA para escribir en público es otro: el 98% de los encuestados prefiere un texto propio, con errores, antes que uno pulido por un modelo. La preferencia no es por perfección lingüística, es por autenticidad.
El 71% de los lectores deja de seguir al autor tras detectar el patrón.

Contexto e historia

Cantrill traza un paralelo directo con la crisis del spam de correo electrónico de comienzos de los 2000. En esa época se temía, con razón, que el correo electrónico colapsara bajo el peso del spam: era la aplicación estrella de internet y perderla se sentía catastrófico.

El punto de inflexión llegó a fines de esa década: los filtros de spam mejoraron tanto que rompieron la economía del spam. Cuando enviar correo masivo dejó de ser rentable en términos de entregabilidad, ser etiquetado como spam pasó de ser una molestia a ser una sentencia de muerte para un dominio. Hoy, cualquier empresa seria cuida con celo su reputación de envío antes de mandar una campaña masiva.

Cantrill sostiene que la escritura con IA podría seguir el mismo arco: si los lectores identifican el patrón a escala, escribir con IA sin editar dejará de ser simplemente cuestionable para volverse, directamente, contraproducente. En sus propias palabras, usar un modelo para escribir en público anula el contrato social entre quien escribe y quien lee, una idea que ya había desarrollado en la RFD 576 de Oxide.

Para quien no conoce el sistema de Oxide: las RFD (Request for Discussion) son documentos internos de discusión técnica, similares en espíritu a un ADR (Architecture Decision Record) pero pensados para debatir cualquier decisión de ingeniería o cultura de la empresa antes de tomarla, y suelen hacerse públicos con el tiempo. La RFD 576 es donde Cantrill formalizó por primera vez la idea del contrato social entre autor y lector.

Detalles técnicos: cómo se detecta la escritura generada por ia

Antes de confiar en Pangram, Cantrill probó dos caminos que fallaron. El primero fue pedirle a los propios LLM que identificaran texto generado por otro LLM: la tasa de falsos negativos fue demasiado alta, los modelos aceptaban con demasiada facilidad textos que él sabía con certeza que eran de IA.

El segundo camino fueron los detectores basados en tics superficiales, como la frecuencia del guion largo. Ese enfoque falla porque Cantrill mismo es, según cuenta, un usuario habitual y sin culpa de ese signo en su propia escritura humana: un heurístico que penaliza un signo de puntuación produce falsos positivos contra escritores que simplemente tienen ese hábito.
Generación de detectorFalsos positivosFalsos negativosMomento de lanzamientoPangram 3Muy bajosMás altos de lo idealFines de 2025Pangram 4Extremadamente bajosBajosFines de julio de 2026
Cantrill describe la mejora entre versiones como un salto de función escalón: con Pangram 4 dice haber alcanzado una precisión que antes no existía en ningún detector que hubiera probado, al punto de perder confianza rápidamente en cualquier autor que la herramienta marque con alta certeza como generado por IA.

import re

MULETILLAS = [
    r"lo que sabemos", r"te contamos", r"todo lo que necesitas saber",
    r"esto cambia todo", r"guia completa de", r"en pocas palabras",
]

def puntaje_heuristico(texto):
    texto_low = texto.lower()
    hits = sum(len(re.findall(patron, texto_low)) for patron in MULETILLAS)
    ratio_guion_largo = texto.count(chr(8212)) / max(len(texto.split()), 1)
    return {"muletillas_detectadas": hits, "ratio_guion_largo": round(ratio_guion_largo, 4)}

if __name__ == "__main__":
    borrador = open("borrador.md", encoding="utf-8").read()
    print(puntaje_heuristico(borrador))

Este script es solo un heurístico casero, no reproduce el modelo propietario de Pangram, pero sirve como primer filtro: cuenta frases muletilla comunes y mide la densidad de guion largo antes de publicar un borrador.
Pangram 4 redujo tanto falsos positivos como falsos negativos frente a Pangram 3.

Cómo probarlo en tu propio texto

No hace falta pagar por un detector para hacer una primera auditoría. Cantrill sugiere, medio en broma, que la prueba definitiva es leer el texto en voz alta: si el autor no soporta escuchar su propio borrador, tampoco debería pedirle a un lector que lo haga.

Para equipos que publican contenido técnico en blogs o proyectos open source, un chequeo simple es agregar un hook de pre-commit que avise si el borrador contiene frases muletilla típicas antes de que llegue a producción.

#!/bin/sh
# .git/hooks/pre-commit
archivo="$1"
patrones="lo que sabemos|te contamos|todo lo que necesitas saber|esto cambia todo"

if grep -inE "$patrones" "$archivo"; then
  echo "Revisa el borrador: se encontraron muletillas tipicas de escritura generada por IA."
  exit 1
fi
exit 0

El hook no reemplaza a un detector real como Pangram, pero atrapa gratis los tics más obvios antes de que un lector los encuentre primero.

💡 Tip: si vas a usar un LLM para acelerar la redacción, usalo para investigar o reordenar ideas, no para generar la prosa final: la voz debe seguir siendo tuya.

Impacto y análisis

La consecuencia práctica, según Cantrill, es que escribir con IA sin editar deja de ser neutral: activa un mecanismo de rechazo. Su hipótesis es que el cerebro de un lector entrenado en leer mucho reacciona a las marcas de un LLM como una alarma de autopreservación, y abandona la lectura a mitad de oración.

flowchart TD
    A["Lector empieza a leer el texto"] --> B{"Detecta tics de escritura generada por ia?"}
    B -- "No" --> C["Sigue leyendo y confia en el autor"]
    B -- "Si" --> D["Abandona la lectura de inmediato"]
    D --> E["Evita al autor en publicaciones futuras"]

Esto tiene implicaciones directas para canales técnicos, newsletters y documentación de proyectos open source: perder la confianza de un lector frecuente no cuesta una sola lectura, cuesta todas las futuras. La encuesta de Dunlop lo confirma con el dato del 71% de abandono permanente del autor, y Cantrill agrega que quienes leen y comparten activamente en redes (justamente los early adopters que dan visibilidad a un texto) son los primeros en aplicar ese castigo.

⚠️ Ojo: un heurístico agresivo también puede acusar en falso a autores con estilos particulares, como quienes escriben en un segundo idioma o editan mucho su propia prosa; ningún detector, ni Pangram 4, es infalible.

Qué sigue

Cantrill anticipa que la disponibilidad de detectores confiables cambia la ecuación de costo-beneficio de escribir con IA en público. Su argumento no es moral, es de efectividad: si el objetivo de publicar es que alguien lea y confíe en lo que dice, usar un LLM sin editar deja de servir a ese objetivo en la medida en que los lectores lo detecten y penalicen.

El paralelo con el spam sugiere un camino: así como hoy ninguna empresa seria arriesga su dominio por una campaña de correo masivo mal dirigida, es esperable que medios, blogs corporativos y comunidades open source empiecen a tratar la escritura de IA no revisada como un riesgo reputacional, no solo como un atajo de productividad.

📖 Resumen en Telegram: Ver resumen

Probalo vos: leé el ensayo completo de Cantrill en bcantrill.dtrace.org y corré tu último borrador por un chequeo rápido de muletillas antes de publicarlo.

Preguntas frecuentes

¿Qué es Pangram y quién lo hace?

Pangram Labs es la empresa que desarrolla los modelos Pangram 3 y Pangram 4, herramientas dedicadas a distinguir si un texto fue escrito por un humano o por un modelo de lenguaje.

¿Por qué fallan los detectores basados en el guion largo?

Porque penalizan un signo de puntuación que también usan escritores humanos por costumbre, como el propio Cantrill reconoce sobre su estilo; eso produce falsos positivos.

¿Qué es la RFD 576 que menciona el ensayo?

Es un documento interno de discusión técnica de Oxide Computer, la empresa que Cantrill cofundó, donde desarrolló por primera vez la idea de que escribir con IA rompe el contrato social entre autor y lector.

¿Cuántos developers participaron en la encuesta que cita Cantrill?

La encuesta de Cynthia Dunlop reunió respuestas de 668 developers sobre cómo reaccionan al detectar escritura generada por ia.

¿Esto significa que nunca hay que usar IA al escribir?

El ensayo no pide prohibir el uso de IA como herramienta de apoyo, apunta específicamente a publicar prosa generada por un modelo sin revisión ni voz propia del autor.

¿Cuándo se lanzó Pangram 4?

Según el ensayo, Pangram 4 se presentó poco más de un mes antes de la publicación del artículo del 5 de septiembre de 2026, es decir hacia fines de julio de ese año.

Referencias

The revolt of the reader: el ensayo original de Bryan Cantrill, fuente principal de esta nota.- Oxide Computer Company: la empresa que Cantrill cofundó y donde surgió la RFD 576 citada en el ensayo.- Email spam en Wikipedia: contexto histórico sobre la crisis del spam de correo electrónico de los 2000 usada como analogía.

Count-Min Sketch: contar millones de eventos con kilobytes de RAM

lu1tr0n — Sat, 05 Sep 2026 16:10:29 +0000

Un firewall que ve millones de paquetes por segundo no puede abrir una entrada en una tabla hash por cada IP distinta que procesa: se queda sin memoria en minutos. Necesita contar sin guardar cada evento, y ahí entra el count-min sketch, una estructura de datos probabilística que estima cuántas veces ocurrió algo usando apenas unos kilobytes.

El count-min sketch resuelve ese problema con una matriz pequeña y varias funciones hash: cambia certeza absoluta por una estimación con error acotado y memoria constante. Es la misma idea detrás de cómo Redis, Apache Flink y los sistemas de detección de anomalías de red cuentan eventos a gran escala sin que la memoria crezca con la cantidad de claves distintas.

TL;DR

Vas a entender cómo el count-min sketch estima frecuencias sin guardar cada evento individual.- Vas a poder calcular el ancho y la profundidad de la matriz según el error que estés dispuesto a tolerar.- Vas a implementar un count-min sketch básico en JavaScript en menos de 30 líneas.- Vas a saber usar CMS.INITBYDIM, CMS.INCRBY y CMS.QUERY del módulo RedisBloom en Redis.- Vas a distinguir cuándo conviene un count-min sketch frente a un Bloom filter o un HyperLogLog.- Vas a conocer el 'conservative update', la técnica que reduce la sobreestimación del conteo.- Vas a identificar los errores más comunes al elegir los parámetros epsilon y delta.

Qué es el count-min sketch y por qué importa

Un mapa hash exacto guarda una entrada por cada clave distinta: si hay diez millones de IPs únicas, la memoria crece con esas diez millones de entradas. El count-min sketch rompe esa relación: su tamaño depende solo del error que tolerás, no de cuántas claves distintas aparezcan en el stream.

Graham Cormode y S. Muthukrishnan publicaron el algoritmo en 2005 como respuesta a un problema concreto: contar frecuencias en flujos de datos demasiado grandes para caber en memoria. Desde entonces se volvió una pieza estándar en sistemas de streaming, bases de datos analíticas y monitoreo de redes.

El canal ya cubrió otras estructuras probabilísticas con propósitos distintos: los filtros de Bloom responden 'existe este elemento', HyperLogLog responde 'cuántos elementos distintos hay'. El count-min sketch responde una tercera pregunta, 'cuántas veces apareció este elemento', y esa diferencia importa porque cada una resuelve un problema que las otras dos no pueden.

Cómo funciona por dentro

La estructura es una matriz de w columnas por d filas, todas inicializadas en cero. Cada fila tiene asociada una función hash independiente que mapea cualquier elemento a una columna dentro de esa fila.

Para incrementar un elemento, el algoritmo calcula sus d posiciones (una por fila) y suma el conteo en cada una de esas celdas. Para consultar la frecuencia estimada, vuelve a calcular esas mismas d posiciones y devuelve el mínimo de los valores encontrados.

El mínimo importa porque cada fila puede sufrir colisiones: dos elementos distintos que caen en la misma celda inflan su valor. Tomar el mínimo entre varias filas independientes reduce ese ruido. La garantía matemática es que la estimación nunca es menor al conteo real, pero puede ser mayor.

Cormode y Muthukrishnan demostraron que con un ancho w = ⌈e/ε⌉ y una profundidad d = ⌈ln(1/δ)⌉ (donde e es el número de Euler), la estimación se mantiene dentro de un error de ε·N respecto al conteo real, con probabilidad de al menos 1-δ, siendo N la suma total de todos los conteos.
Una matriz de w columnas por d filas resume millones de eventos distintos.

flowchart TD
    A["Evento: IP 203.0.113.7"] --> B["Hash 1"]
    A --> C["Hash 2"]
    A --> D["Hash 3"]
    B --> E["Fila 1, columna h1"]
    C --> F["Fila 2, columna h2"]
    D --> G["Fila 3, columna h3"]
    subgraph Matriz
    E
    F
    G
    end

Ejemplos prácticos con código

El primer ejemplo implementa un count-min sketch desde cero, sin dependencias, para ver la mecánica interna sin la capa de un motor externo.

class CountMinSketch {
  constructor(width, depth) {
    this.width = width;
    this.depth = depth;
    this.matrix = Array.from({ length: depth }, () => new Uint32Array(width));
    this.seeds = Array.from({ length: depth }, (_, i) => i * 2654435761);
  }

  hash(item, seed) {
    let h = seed;
    for (let i = 0; i >> 0;
    }
    return h % this.width;
  }

  add(item, count = 1) {
    for (let row = 0; row >R: CMS.INCRBY ip_counter 203.0.113.7 1
    R-->>C: OK
    C->>R: CMS.QUERY ip_counter 203.0.113.7
    R-->>C: estimacion aproximada
    Note over C,R: la estimacion nunca es menor al conteo real

Cómo empezar paso a paso

Para probarlo hoy mismo sin instalar nada en tu sistema, levantá Redis Stack en Docker:

docker run -d --name redis-stack -p 6379:6379 redis/redis-stack:latest

Con el contenedor corriendo, creá el sketch y probá los tres comandos básicos:

redis-cli CMS.INITBYDIM visitas_por_pagina 2000 5
redis-cli CMS.INCRBY visitas_por_pagina /blog/count-min-sketch 1
redis-cli CMS.QUERY visitas_por_pagina /blog/count-min-sketch

Para confirmar que la estructura está activa y con los parámetros esperados, usá CMS.INFO, que devuelve el ancho, la profundidad y la suma total de conteos registrados:

redis-cli CMS.INFO visitas_por_pagina
# 1) width
# 2) (integer) 2000
# 3) depth
# 4) (integer) 5
# 5) count
# 6) (integer) 1

Si el ancho o la profundidad no coinciden con los que esperabas, el sketch fue creado con otros parámetros y hay que recrearlo: no se puede redimensionar una vez inicializado.

Casos de uso reales

La detección de heavy hitters en tráfico de red es el caso clásico: identificar qué IPs o qué flujos concentran el grueso del tráfico sin mantener una tabla de flujo completa, algo inviable cuando hay millones de conexiones simultáneas.

Twitter usó una estructura equivalente en su biblioteca Algebird para contar apariciones de hashtags y términos en streams de tweets, donde guardar un contador exacto por cada palabra distinta habría sido impracticable a esa escala.
Twitter usó una estructura similar en su biblioteca Algebird para contar en streams.
Motores de bases de datos analíticas usan sketches parecidos para estimar la selectividad de una columna antes de elegir un plan de ejecución, sin necesidad de escanear la tabla completa. Proyectos como Apache DataSketches empaquetan el count-min sketch junto a otras estructuras probabilísticas para pipelines de datos a gran escala.

💡 Tip: si tu objetivo es limitar peticiones por usuario (rate limiting), un count-min sketch con ventana temporal (reiniciando la matriz cada cierto intervalo) suele consumir muchísima menos memoria que un contador exacto por usuario.

Errores comunes y buenas prácticas

El error más frecuente es tratar la estimación como un número exacto. El count-min sketch nunca subestima, pero sí puede sobreestimar, así que no es apto para decisiones donde un falso positivo por sobreconteo sea inaceptable, como facturación exacta por evento.

Otro error es elegir un ancho o una profundidad arbitrarios. Si el error tolerado ε es muy pequeño, el ancho w crece proporcionalmente, y si la probabilidad de fallo δ es muy exigente, la profundidad d crece con ella: conviene calcular ambos valores en función del presupuesto de memoria real disponible, no adivinarlos.

Las distribuciones muy sesgadas (unos pocos elementos con conteos enormes, el resto con conteos bajos) son las que más sufren: un elemento con millones de ocurrencias puede inflar la estimación de elementos que colisionan en su misma celda. Aumentar la profundidad o aplicar conservative update mitiga ese efecto.

⚠️ Ojo: un count-min sketch básico no soporta eliminar o decrementar elementos de forma confiable; si tu caso de uso necesita eso, mirá la variante Count Sketch antes de forzar la estructura básica.

Comparativa con alternativas

EstructuraQué respondeMemoriaCuándo usarlaHash map exactoFrecuencia exactaCrece con claves distintasPocos elementos o memoria abundanteBloom filter¿Existe el elemento?Fija (bits)Verificar membresía, no frecuenciaHyperLogLog¿Cuántos elementos distintos hay?Fija (unos KB)Cardinalidad aproximada (COUNT DISTINCT)Count-Min Sketch¿Cuántas veces apareció?Fija (w × d)Frecuencias aproximadas en streams masivosCount SketchFrecuencia con menor sesgoFija, similar a CMSCuando la sobreestimación sistemática es un problema

Profundizando: conservative update y variantes avanzadas

El conservative update es una optimización simple pero efectiva: en vez de sumar el conteo completo a las d celdas, primero calculá cuál sería el nuevo valor mínimo entre esas celdas y subí cada una solo hasta ese valor, nunca más allá. Esto reduce la sobreestimación acumulada sin cambiar la lógica de consulta.

La variante Count Sketch agrega un signo aleatorio (+1 o -1) por cada función hash, y en la consulta devuelve la mediana en lugar del mínimo. El resultado es un estimador sin sesgo sistemático, aunque a diferencia del count-min sketch, sí puede subestimar el conteo real.

Cuando el problema es identificar los k elementos más frecuentes (top-k) en lugar de estimar frecuencias individuales, el algoritmo Space-Saving de Misra-Gries suele ser más preciso con memoria similar, porque mantiene explícitamente los candidatos más pesados en vez de una matriz genérica.

Una propiedad clave para sistemas distribuidos es la mergeabilidad: dos count-min sketches con el mismo ancho, profundidad y funciones hash se pueden combinar sumando sus matrices celda por celda. Esto permite que cada nodo de un cluster cuente su porción del stream por separado y se agreguen los resultados al final, sin coordinación previa.

flowchart TD
    Q["Que necesitas saber?"] --> M["Existe el elemento?"]
    Q --> D["Cuantos distintos hay?"]
    Q --> F["Cuantas veces aparecio?"]
    M --> BF["Bloom filter"]
    D --> HLL["HyperLogLog"]
    F --> CMS["Count-Min Sketch"]

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: levantá Redis Stack con el comando de Docker de este artículo, corré CMS.INCRBY sobre un archivo de logs real y comparalo contra un conteo exacto con awk o uniq -c para ver el margen de error en la práctica.

Preguntas frecuentes

¿El count-min sketch puede dar un resultado menor al conteo real?

No. La estructura solo puede sobreestimar, nunca subestimar, porque toma el mínimo entre varias filas que solo suman valores positivos.

¿Cómo elijo el ancho y la profundidad de la matriz?

El ancho w se calcula como ⌈e/ε⌉ y la profundidad d como ⌈ln(1/δ)⌉, donde ε es el error tolerado y δ la probabilidad de fallo aceptada. Menor error exige más ancho; menor probabilidad de fallo exige más filas.

¿Un count-min sketch se puede fusionar con otro?

Sí, siempre que ambos usen el mismo ancho, profundidad y funciones hash. Fusionarlos es sumar sus matrices celda por celda, lo que lo hace ideal para conteos distribuidos entre varios nodos.

¿Sirve para contar elementos que después quiero eliminar?

La versión básica no soporta decrementos de forma confiable. Para eso existe el Count Sketch, una variante con signos aleatorios que permite estimaciones sin sesgo, aunque puede subestimar.

¿Qué diferencia hay con un Bloom filter?

Un Bloom filter responde si un elemento existe o no; el count-min sketch responde cuántas veces apareció. Resuelven preguntas distintas y suelen combinarse en el mismo sistema.

¿Qué es el conservative update?

Es una optimización donde, al incrementar un elemento, cada celda solo sube hasta el nuevo valor mínimo necesario en vez de sumarle el conteo completo, lo que reduce la sobreestimación acumulada.

Referencias

Wikipedia: Count-min sketch: descripción formal del algoritmo, autores originales y garantías matemáticas.- GitHub: RedisBloom: implementación open source del módulo que expone CMS.INITBYDIM, CMS.INCRBY y CMS.QUERY en Redis.- Apache DataSketches: biblioteca de estructuras probabilísticas, incluido el count-min sketch, usada en pipelines de datos a gran escala.- Redis: documentación oficial del proyecto y de sus módulos de estructuras probabilísticas.