DEV Community: lu1tr0n

USC crea un sistema neuromórfico que se alimenta de la señal que mide

lu1tr0n — Tue, 16 Jun 2026 16:12:51 +0000

Un equipo de la Universidad del Sur de California (USC) construyó un sistema neuromórfico del tamaño de una moneda que percibe el mundo, aprende de él y toma decisiones sin batería, sin procesador y sin conexión a la nube. El trabajo, portada de Nature Sensors el 2 de junio de 2026, propone una idea radical: que la propia señal física que el dispositivo mide sea también la energía que lo alimenta.

No es un chip más rápido ni un modelo más grande. Es una manera distinta de computar, inspirada en cómo el cerebro procesa la vista y el tacto a la vez, que podría llevar inteligencia a lugares donde hoy no llega ni un cable ni una pila.

TL;DR

La USC presentó un sistema neuromórfico del tamaño de una moneda que percibe, aprende y decide sin batería ni nube.
El trabajo fue portada de Nature Sensors el 2 de junio de 2026; lo lideran J. Joshua Yang y Seung Ju Kim.
Usa dos memristores: uno imita una neurona que dispara y otro una sinapsis que retiene lo aprendido.
Procesa luz, presión, calor y sonido de forma analógica, sin convertir nada a digital.
La propia señal medida alimenta el circuito: el dato es también la fuente de energía.
Una demostración detecta rayos midiendo el desfase entre la luz (instantánea) y el sonido (~3 s por kilómetro).
Posibles usos: sensores contra incendios, gafas inteligentes, sondas espaciales y submarinas autónomas.

Qué pasó

El laboratorio dirigido por el profesor J. Joshua Yang, del Ming Hsieh Department of Electrical and Computer Engineering de la USC, publicó un dispositivo que combina percepción, memoria y aprendizaje en un único circuito analógico. El primer autor del artículo es el investigador posdoctoral Seung Ju Kim. La revista Nature Sensors lo eligió como historia de portada en su edición del 2 de junio de 2026.

La pieza clave del anuncio no es la miniaturización en sí, sino la economía energética. En un computador convencional, sensar el mundo, digitalizar la señal, moverla a un procesador y ejecutar un modelo son cuatro etapas que consumen energía por separado. El sistema neuromórfico de la USC colapsa todas esas etapas en una sola y, además, se autoabastece: la energía no viene de una batería, sino de la misma señal física que se está midiendo. Como resume el equipo, "la señal no es solo la señal que se procesa; es también la fuente de energía que alimenta el sistema".

El resultado es un objeto que puede dejarse funcionando solo, sin mantenimiento, en lugares donde una pila se agotaría o un cable sería imposible. Esa autonomía es lo que convierte un experimento de laboratorio en una noticia con implicaciones prácticas reales.

Un circuito analógico que percibe y aprende sin batería externa.

Qué es un sistema neuromórfico

La computación neuromórfica es una rama de la ingeniería que intenta construir hardware que funcione como el cerebro, no como una calculadora. En un procesador clásico, la memoria y el cálculo viven separados: los datos van y vienen entre la RAM y la CPU por un bus, y ese trasiego constante es el llamado "cuello de botella de von Neumann". El cerebro no trabaja así. En él, las neuronas que computan y las sinapsis que recuerdan son la misma estructura física, y la información se procesa donde se almacena.

Un sistema neuromórfico persigue esa idea: en lugar de mover bits de un lado a otro, deja que el cálculo ocurra dentro de los propios elementos de memoria. Eso reduce drásticamente el consumo y permite responder a estímulos del mundo real en tiempo continuo, sin esperar a un reloj digital. Empresas y laboratorios llevan más de una década explorando este enfoque —Intel con su chip Loihi, IBM con TrueNorth—, pero la mayoría de esos diseños siguen siendo digitales y necesitan alimentación externa.

Lo que diferencia al trabajo de la USC es que es completamente analógico. No convierte la luz, la presión o el sonido en unos y ceros: opera directamente sobre el fenómeno físico continuo. Esa decisión de diseño elimina los conversores analógico-digitales, que suelen ser de las partes más caras en energía, y abre la puerta a que el dispositivo se alimente del propio entorno.

💭 Clave: en un sistema neuromórfico analógico, percibir, recordar y aprender no son tres pasos distintos sino propiedades físicas del mismo material. Ahí está el ahorro de energía.

Cómo funciona el dispositivo

El corazón del sistema son dos tipos de memristores, dispositivos nanoscópicos cuya resistencia eléctrica cambia según la corriente que han recibido y que conservan ese estado aunque se les quite la alimentación. Por eso se les considera un buen candidato para imitar a las sinapsis biológicas.

Memristor tipo neurona — dispara una señal cuyo instante depende de la intensidad del estímulo. Cuanto más fuerte es la entrada, antes se activa, igual que una neurona biológica que codifica información en el momento del disparo.
Memristor tipo sinapsis — retiene de forma indefinida el estado aprendido, sirviendo como memoria persistente del sistema sin necesidad de refrescarlo.

Ambos se conectan con componentes tan banales como resistencias y condensadores. No hay firmware, no hay sistema operativo, no hay software que actualizar. El aprendizaje es no supervisado y emerge solo de la física: según el equipo, "la memoria surge de la relación temporal entre las señales físicas, imitando la forma en que los sistemas biológicos aprenden de experiencias repetidas".

El ejemplo que mejor ilustra el principio es la detección de rayos. Un relámpago emite dos señales que viajan a velocidades muy distintas: la luz llega casi instantáneamente, mientras que el trueno avanza a unos 3 segundos por kilómetro. El sistema percibe ambas, y el desfase temporal entre ellas queda codificado directamente en la memoria del memristor, lo que permite estimar la distancia del rayo sin ningún servidor ni registrador de datos en medio.

graph LR
  A["Rayo"] --> B["Luz (instantanea)"]
  A --> C["Sonido (~3 s/km)"]
  B --> D["Memristor neurona: dispara"]
  C --> D
  D --> E["Memristor sinapsis: guarda el desfase"]
  E --> F["Distancia estimada"]

El flujo es íntegramente local: el sensor, la memoria y la "decisión" ocurren en el mismo punto. Lo que en un sistema tradicional requeriría un micrófono, un fotodiodo, un microcontrolador, un reloj y un algoritmo de correlación, aquí lo resuelve la física de un puñado de componentes pasivos.

💡 Tip: si querés entender por qué importa que sea analógico, pensá en cuántos joules se gastan solo en digitalizar audio a 44,1 kHz de forma continua durante días. El diseño de la USC simplemente nunca digitaliza.

Datos y cifras

Más allá de la elegancia conceptual, conviene ordenar los datos concretos que sostienen la noticia, porque la promesa de "computar con aire" exige precisión para no caer en exageración.

Tamaño — el circuito completo cabe en una placa del tamaño de una moneda.
Energía externa — cero. El sistema se alimenta de la señal física que sensa, no de una batería ni de la red eléctrica.
Componentes — dos tipos de memristores nanoscópicos más resistencias y condensadores convencionales.
Procesamiento — 100 % analógico, sin conversión a digital ni software.
Publicación — portada de Nature Sensors, 2 de junio de 2026.
Demostración — red simulada de detección de rayos basada en el desfase luz/sonido (~3 s/km).
Financiación — el centro CONCRETE (Center of Neuromorphic Computing under Extreme Environments), con apoyo de la Air Force Office of Scientific Research, el Air Force Research Laboratory, el Army Research Office y la National Science Foundation.

El nombre del centro financiador, CONCRETE, no es casual: el enfoque está pensado para entornos extremos donde no hay infraestructura. Esa es la frontera real del proyecto, y también explica el interés de agencias de defensa y ciencia básica de Estados Unidos.

Sensores que aprenden solos, pensados para terreno sin infraestructura.

Impacto y análisis

El contexto de esta noticia es la creciente angustia por el consumo energético de la inteligencia artificial. Mientras los grandes modelos de lenguaje empujan la demanda de centros de datos a niveles que preocupan a gobiernos y operadores eléctricos, una corriente de investigación va en sentido contrario: en vez de concentrar más cómputo en almacenes gigantes, repartir inteligencia mínima en el borde, donde nace el dato. Un sistema neuromórfico autoalimentado es la expresión más extrema de esa filosofía.

Conviene, sin embargo, ser objetivos sobre el alcance. Este dispositivo no compite con un modelo de IA generativa ni pretende hacerlo. No va a escribir código ni a clasificar imágenes complejas. Su valor está en tareas de percepción acotadas —detectar un patrón, medir un desfase, reaccionar a un umbral— donde hoy desplegar electrónica convencional es inviable por costo, mantenimiento o falta de energía. Compararlo con un chip de IA de centro de datos sería un error de categoría.

Las aplicaciones que el equipo plantea dan la medida del nicho. Un sensor que no necesita batería ni red podría esparcirse por terreno propenso a incendios para detectar la caída de rayos; podría integrarse en gafas inteligentes que procesan el entorno sin conectarse a un teléfono; o podría enviarse al espacio o dejarse caer en el océano profundo para aprender por su cuenta. Son escenarios en los que la autonomía energética no es un lujo, sino la condición que hace posible el despliegue.

⚠️ Ojo: que un prototipo de laboratorio funcione no garantiza que se fabrique a escala. Los memristores llevan más de una década prometiendo revolucionar el hardware y todavía no se producen en masa con la fiabilidad de un transistor CMOS.

Ese es el matiz periodístico honesto: estamos ante una prueba de concepto sólida y revisada por pares, no ante un producto. La fabricación reproducible de memristores, su variabilidad entre unidades y su integración con la electrónica existente siguen siendo problemas abiertos en toda la industria. La noticia es importante porque demuestra que el principio funciona y se publica en una revista de primer nivel, no porque mañana vayamos a comprar uno.

Qué sigue

El siguiente paso lógico es pasar de una red simulada a despliegues físicos más grandes y a tareas de percepción más ricas que combinen varias modalidades sensoriales a la vez —la "vista y tacto simultáneos" que inspiró el diseño—. También habrá que demostrar robustez: cómo se comportan estos dispositivos tras meses de funcionamiento autónomo, con ruido, temperatura variable y señales débiles.

En el plano industrial, la gran pregunta es la fabricación. Para que un sistema neuromórfico como este salga del laboratorio hace falta un proceso capaz de producir memristores consistentes a bajo costo. Mientras eso no exista, el impacto se medirá en nichos de investigación, defensa y exploración científica antes que en electrónica de consumo. Aun así, cada demostración que cierra la brecha entre percibir y computar empuja a toda la disciplina un paso más cerca de un cómputo que se parezca, de verdad, al cerebro.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es un sistema neuromórfico?

Es hardware diseñado para funcionar como el cerebro, donde el cálculo y la memoria conviven en la misma estructura física en lugar de estar separados como en una CPU y su RAM. Eso reduce el consumo y permite procesar señales del mundo real en tiempo continuo.

¿De verdad funciona sin batería?

Sí, según el trabajo publicado en Nature Sensors. No tiene fuente de energía externa: la propia señal física que mide —luz, presión, calor o sonido— es también la que alimenta el circuito. Por eso el equipo dice que el dato y la energía son lo mismo.

¿Qué es un memristor y por qué importa aquí?

Es un componente nanoscópico cuya resistencia depende de la corriente que ha pasado por él y que conserva ese estado sin alimentación. El dispositivo usa dos tipos: uno que dispara como una neurona y otro que retiene lo aprendido como una sinapsis.

¿Reemplaza a los chips de IA actuales?

No. No compite con los aceleradores de centros de datos ni con los modelos generativos. Está pensado para tareas de percepción acotadas en lugares sin energía ni red, no para entrenar o ejecutar grandes modelos.

¿Para qué sirve la demostración del rayo?

Ilustra el principio central: la luz llega casi instantánea y el sonido a unos 3 segundos por kilómetro, y el sistema codifica ese desfase directamente en su memoria para estimar la distancia, sin servidores ni registradores de datos.

¿Cuándo veremos esto en productos reales?

No hay fecha. Es una prueba de concepto revisada por pares; la fabricación masiva y fiable de memristores sigue siendo un reto abierto en toda la industria. Los primeros usos llegarán antes a investigación, defensa y exploración científica que a electrónica de consumo.

Referencias

USC Viterbi — anuncio oficial del sistema neuromórfico autoalimentado y portada de Nature Sensors.
USC Viterbi — trabajo previo del mismo grupo sobre neuronas artificiales basadas en memristores.
EurekAlert! — nota de prensa sobre las neuronas artificiales del equipo de la USC.
Interesting Engineering — cobertura sobre las neuronas artificiales basadas en iones para hardware de IA.

📱 ¿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.

Cómo funciona un reloj mecánico: los 7 componentes del movimiento

lu1tr0n — Tue, 16 Jun 2026 14:17:30 +0000

Un reloj mecánico mide el tiempo con notable precisión sin una sola batería ni chip. Detrás de esa hazaña hay un sistema de apenas siete piezas que convierten la tensión de un resorte en el tic-tac constante de la manecilla de los segundos.

Inspirados en el célebre explicador interactivo de Bartosz Ciechanowski, desarmamos el movimiento pieza por pieza y lo modelamos con código, porque para quien programa hay una analogía poderosa escondida en estos engranajes.

TL;DR

El movimiento de un reloj mecánico funciona sin batería: almacena energía en un resorte llamado muelle real.
El sistema de cronometraje se reduce a 7 piezas principales dispuestas casi en línea recta.
El muelle real se carga girando el árbol (arbor) y libera su energía empujando el tambor (barrel).
El tren de engranajes reduce la rotación para mover las manecillas de hora, minuto y segundo.
El escape (escapement) libera los engranajes diente por diente: de ahí nace el característico tic-tac.
El volante oscila a frecuencia fija (a menudo 4 Hz, 28.800 vibraciones por hora) y actúa como reloj patrón mecánico.
El explicador interactivo de Bartosz Ciechanowski (mayo de 2022) popularizó esta forma de enseñar ingeniería en la web.

¿Qué es el movimiento de un reloj mecánico?

Cuando hablamos de un reloj mecánico, la caja metálica que vemos es lo de menos. La verdadera estrella es el movimiento: la maquinaria interna que vive encerrada en esa caja. El movimiento contiene decenas de piezas, pero su función central —mantener el tiempo— recae en un puñado de componentes que, sorprendentemente, se pueden alinear casi en una sola fila.

El mundo de la relojería está lleno de jerga, y muchos componentes tienen nombres poco familiares. No hace falta memorizarlos: lo importante es entender el papel que cumple cada uno dentro de la cadena. Esa cadena va desde una fuente de energía hasta un oscilador que marca el ritmo, pasando por una serie de engranajes que reparten ese movimiento. Si has trabajado con señales de reloj en electrónica o con bucles de animación a 60 fps, el patrón te resultará familiar.

💭 Clave: todo reloj mecánico hace lo mismo que un cristal de cuarzo, pero sin electricidad: genera una oscilación estable y la cuenta. La diferencia es que aquí el oscilador es físico y la cuenta la hace un tren de engranajes.

La fuente de energía: el muelle real y el tambor

Los dispositivos puramente mecánicos necesitan almacenar energía de alguna forma, y uno de los métodos más simples es un resorte. En lugar del típico resorte de compresión que vemos en un bolígrafo, el reloj usa un resorte de torsión en espiral: se carga al enrollarlo y, al soltarlo, se desenrolla girando en sentido contrario hasta llegar a su estado natural. Como en un reloj queremos manecillas que giren, este movimiento rotatorio es justo lo que necesitamos.

Ese resorte se llama muelle real (mainspring) y es tan fuerte que, sin contención, se expandiría de golpe. Por eso vive dentro de una carcasa cilíndrica llamada tambor (barrel), cuyas paredes lo mantienen en su sitio. Para almacenar energía, enrollamos el muelle apretándolo con el árbol (arbor), un eje central con un gancho que se engancha a un orificio del resorte. Al girar el árbol —eso es darle cuerda— el muelle se tensa.

Aquí aparece el primer detalle ingenioso. Si soltáramos el árbol, el muelle simplemente lo haría girar hacia atrás y no obtendríamos trabajo útil. La solución es sostener el árbol y dejar que sea el tambor el que gire, transmitiendo así la energía al resto del mecanismo. Una tira metálica unida al extremo exterior del muelle roza contra la pared del tambor: esa fricción bloquea el extremo externo y, si se intenta dar demasiada cuerda, el muelle resbala dentro del tambor en lugar de romperse. Es, literalmente, un mecanismo de seguridad mecánico.

El muelle real almacena la energía; el tambor la libera de forma controlada.

El tren de engranajes: repartir y reducir la rotación

El tambor no mueve las manecillas directamente: gira demasiado despacio y con demasiada fuerza. Entre el tambor y el oscilador hay un tren de engranajes (gear train) formado por varias ruedas dentadas que reducen progresivamente la velocidad y reparten el movimiento. De ese tren salen las tomas para la manecilla de las horas, la de los minutos y la de los segundos.

La idea es la misma que un divisor de frecuencia: una rueda grande engrana con un piñón pequeño, y la relación entre el número de dientes determina cuánto se reduce la velocidad en cada etapa. Encadenando varias reducciones, una rotación rápida del lado del oscilador se convierte en el giro lento y exacto que necesita la manecilla de las horas.

📌 Nota: el tren de engranajes no decide a qué velocidad va el reloj; solo traduce. Quien fija el ritmo es el conjunto escape + volante que veremos a continuación. Cambiar un engranaje altera las relaciones, pero el latido base lo marca el oscilador.

Por eso un reloj que se adelanta o atrasa rara vez tiene un problema en los engranajes: el ajuste fino se hace sobre el oscilador, no sobre el tren. Para un desarrollador es la misma distinción entre la frecuencia base de un reloj de hardware y los contadores que dividen esa señal aguas abajo.

El escape y el volante: el corazón del tic-tac

Llegamos al componente más fascinante. Si dejáramos que el muelle real moviera el tren de engranajes libremente, todo se desenrollaría en segundos. Hace falta algo que libere la energía en porciones diminutas y regulares. Ese trabajo lo hace el escape (escapement), compuesto por la rueda de escape y el áncora (pallet fork), trabajando junto al volante (balance wheel) y su espiral.

El volante es una rueda que oscila de un lado a otro a una frecuencia fija, gobernada por una pequeña espiral (la espiral del volante) que actúa como el resorte de un péndulo. En cada media oscilación, el áncora libera un solo diente de la rueda de escape; ese diente, al escapar, da un pequeño empujón al volante que lo mantiene oscilando. Ese intercambio —liberar un diente, recibir un impulso— es el origen del tic-tac que escuchas.

La frecuencia típica de un reloj moderno es de 4 Hz, es decir, 8 medias oscilaciones por segundo, lo que equivale a 28.800 vibraciones por hora (vph). Esa cifra grabada en muchos movimientos no es marketing: es literalmente la frecuencia del oscilador que define la precisión del reloj.

El escape libera el tren diente por diente; el volante marca el ritmo.

El flujo completo de energía, de la fuente al oscilador, se puede ver así:

graph LR
  A["Muelle real"] --> B["Tambor (barrel)"]
  B --> C["Tren de engranajes"]
  C --> D["Rueda de escape"]
  D --> E["Áncora (pallet fork)"]
  E --> F["Volante + espiral"]
  F -. "libera un diente" .-> D

Fíjate en la flecha de retorno: el volante no solo recibe energía, también controla cuándo se libera el siguiente diente. Es un lazo de realimentación mecánico, equivalente a un oscilador que se autorregula.

Modelando el reloj con código

Para quien viene del software, la mejor forma de fijar estos conceptos es escribir un modelo mínimo. El escape funciona como un divisor de reloj: el volante oscila a frecuencia fija y cada media oscilación deja avanzar el tren una unidad. Contar esas unidades es, en esencia, llevar la hora.



FRECUENCIA_HZ = 4          # 4 oscilaciones por segundo (28.800 vph)
DIENTES_ESCAPE = 15        # dientes de la rueda de escape

class Movimiento:
    def __init__(self):
        self.energia = 100.0      # carga del muelle real (%)
        self.segundos = 0.0

    def medio_ciclo(self):
        # Cada media oscilacion del volante libera un diente
        if self.energia  **💡 Tip:** si quieres ver el mecanismo en movimiento real, abre el artículo original de Ciechanowski en el escritorio: sus demostraciones 3D interactivas dejan arrastrar la cámara y mover un control deslizante para mirar dentro del movimiento. Ningún diagrama estático lo iguala.

## Por qué esto importa para quien programa

Un **reloj mecánico** es un curso intensivo de diseño de sistemas comprimido en un objeto que cabe en la muñeca. Hay separación de responsabilidades clara: la fuente de energía (muelle real), el transporte (tren de engranajes) y el control de ritmo (escape y volante) están desacoplados. Hay tolerancia a fallos: el muelle resbala antes de romperse. Y hay un lazo de realimentación que mantiene estable la frecuencia sin un cerebro central.

Más allá del reloj, el verdadero aporte de Bartosz Ciechanowski fue demostrar que conceptos densos de ingeniería se pueden enseñar con simulaciones interactivas en el navegador, sin vídeos ni libros de texto. Sus explicadores sobre GPS, motores, cámaras o el propio reloj se han convertido en referencia de lo que la web puede hacer como medio educativo, y en LATAM son un excelente recurso gratuito para estudiar física e ingeniería de sistemas desde el código.

📖 Resumen en Telegram: [Ver resumen](#)

## Preguntas frecuentes

### ¿Un reloj mecánico necesita batería?

No. Toda su energía proviene del muelle real, un resorte que se enrolla al darle cuerda manualmente o, en los modelos automáticos, mediante el movimiento de la muñeca. No usa pilas ni componentes electrónicos.

### ¿Cada cuánto hay que darle cuerda?

Depende de la reserva de marcha del movimiento, que suele oscilar entre 38 y 80 horas en relojes modernos. Un reloj manual requiere cuerda diaria; uno automático se recarga solo mientras se usa.

### ¿Qué diferencia hay entre un reloj mecánico y uno de cuarzo?

Ambos cuentan oscilaciones, pero el de cuarzo usa un cristal vibrando a 32.768 Hz alimentado por una pila, mientras que el mecánico usa un volante físico que oscila a unos 4 Hz movido por un resorte. El de cuarzo es más preciso y barato; el mecánico es valorado por su ingeniería.

### ¿Qué significa 28.800 vph?

Es la frecuencia del oscilador: 28.800 vibraciones por hora equivalen a 4 Hz, es decir, 8 medias oscilaciones del volante por segundo. A mayor frecuencia, la manecilla de segundos se mueve de forma más fluida y el reloj suele ser más estable.

### ¿Qué es un reloj automático?

Es un reloj mecánico que añade un rotor que gira con el movimiento del brazo y va dando cuerda al muelle real de forma continua. Así evita la cuerda manual diaria mientras se lleva puesto.

### ¿Por qué el escape hace tic-tac?

El sonido proviene del áncora golpeando los dientes de la rueda de escape en cada media oscilación del volante. Cada liberación de un diente produce un clic; a 4 Hz se perciben como el clásico tic-tac.

## Referencias

- [Mechanical Watch — Bartosz Ciechanowski](https://ciechanow.ski/mechanical-watch/) — explicador interactivo original (mayo de 2022) que inspira este artículo.
- [Wikipedia: Mechanical watch](https://en.wikipedia.org/wiki/Mechanical_watch) — historia, componentes y funcionamiento general del reloj mecánico.
- [Wikipedia: Escapement](https://en.wikipedia.org/wiki/Escapement) — el mecanismo de escape, su historia y variantes.
- [Wikipedia: Mainspring](https://en.wikipedia.org/wiki/Mainspring) — el muelle real como fuente de energía y reserva de marcha.

📱 **¿Te gusta este contenido?** Únete a nuestro canal de Telegram [@programacion](https://t.me/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.

El emulador x86 de Windows reescribía 256 KB de código basura al vuelo

lu1tr0n — Tue, 16 Jun 2026 08:17:46 +0000

Durante un intercambio de anécdotas entre ingenieros veteranos de Microsoft, un colega de Raymond Chen contó una historia que resume el eterno duelo entre los compiladores y quienes ejecutan su salida. Un emulador x86 de Windows —de los que permitían correr binarios x86-32 sobre procesadores de otra arquitectura— se topó con código tan ineficiente que el equipo decidió arreglarlo en pleno proceso de traducción.

El detalle que hizo célebre la anécdota: ese programa gastaba 256 KB de instrucciones para inicializar apenas 64 KB de memoria. El código que ponía los ceros pesaba cuatro veces más que los datos que inicializaba.

TL;DR

Un emulador x86 de Windows usaba traducción binaria (JIT) para convertir código x86-32 en código nativo de otra arquitectura.
Un programa reservaba ~64 KB en la pila; el compilador desenrolló el bucle de inicialización en 65.536 instrucciones de 'escribir un byte'.
Cada instrucción ocupaba 4 bytes: 65.536 × 4 = 262.144 bytes, es decir 256 KB de código para inicializar 64 KB de datos.
El equipo del emulador agregó código al traductor para detectar ese patrón y reemplazarlo por un bucle compacto.
La anécdota la relató Raymond Chen en The Old New Thing el 15 de junio de 2026.
No se precisó qué procesador era; Windows incluyó emuladores x86 varias veces (Alpha, Itanium, ARM).
El caso ilustra los límites del loop unrolling: 'más rápido en teoría' no siempre significa mejor en la práctica.

Qué pasó

La escena no ocurrió en una sala de incidentes ni en un postmortem formal, sino en una charla informal entre ingenieros. Raymond Chen, autor del blog The Old New Thing, recogió la anécdota de un colega que trabajó en uno de los varios emuladores de x86 que Windows ha incluido a lo largo de su historia para correr binarios x86-32 sobre procesadores de otra arquitectura.

El emulador x86 en cuestión no interpretaba instrucción por instrucción. Empleaba traducción binaria: tomaba bloques de código x86-32 y generaba código nativo equivalente para el procesador anfitrión, una técnica que rinde mucho más que un intérprete clásico. Conviene pensarlo así: el x86-32 es un bytecode y el emulador es, en la práctica, un compilador JIT que produce código máquina al vuelo.

Al traducir cierto programa, el equipo se topó con una función que reservaba unos 64 KB en la pila y los inicializaba. Hasta ahí, pura rutina. El problema era cómo lo hacía el código que había generado el compilador original.

La traducción binaria convierte código x86-32 en instrucciones nativas del anfitrión.

El antipatrón: 256 KB para inicializar 64 KB

La forma estándar de reservar e inicializar un bloque grande en la pila tiene tres pasos: hacer un stack probe para garantizar que hay 64 KB disponibles, restar 65.536 al puntero de pila y, por último, inicializar la memoria con un bucle pequeño y apretado. Ese bucle suele caber en un puñado de instrucciones.

Pero el compilador que generó ese binario consideró que un bucle era demasiado mundano. En lugar de emitirlo, desenrolló por completo la inicialización: 65.536 instrucciones individuales de 'escribir un byte en memoria', una por cada byte del buffer. Cada una de esas instrucciones ocupaba 4 bytes.

La aritmética es demoledora: 65.536 instrucciones × 4 bytes = 262.144 bytes. Es decir, 256 KB de código para inicializar 64 KB de datos. Una desproporción que ofende a cualquiera que haya mirado un perfilador de cerca.

💭 Clave: No es que el bucle desenrollado fuera lento por byte. El problema es el tamaño del propio código: 256 KB de instrucciones arrasan con la caché de instrucciones y, en un emulador, también con el tiempo de traducción.

Veamos el contraste a nivel de ensamblador. Así se veía, en esencia, el código 'optimizado' por el compilador:

; Inicializar 64 KB en la pila — version desenrollada por el compilador
mov byte ptr [esp+0], 0
mov byte ptr [esp+1], 0
mov byte ptr [esp+2], 0
; ... 65.533 instrucciones mas, una por cada byte ...
mov byte ptr [esp+65535], 0
; total: 65.536 instrucciones x 4 bytes = 256 KB de codigo

Y así de compacto puede expresarse exactamente lo mismo con un bucle apretado, usando la instrucción de relleno de cadenas del x86:

; Equivalente compacto — pocas instrucciones, 64 KB inicializados
xor    eax, eax        ; valor a escribir = 0
mov    ecx, 65536      ; cantidad de bytes
lea    edi, [esp]      ; destino = base del buffer en la pila
rep    stosb           ; rellena ECX bytes con AL desde EDI

Cómo el emulador x86 detectó el patrón

Lo que el equipo hizo fue elegante en su pragmatismo. En vez de tragarse la traducción literal de 65.536 instrucciones —que habría inflado el código nativo generado y castigado tanto la memoria como el tiempo de arranque—, agregaron código especial al traductor para reconocer esa función concreta y reemplazarla por su equivalente compacto. El emulador, al detectar la firma del antipatrón, emitía un bucle apretado en lugar de la avalancha de escrituras byte a byte.

Es la clase de decisión que solo tiene sentido cuando controlás el motor de ejecución. Un compilador JIT no está obligado a reproducir el código fuente instrucción por instrucción: está obligado a reproducir su comportamiento observable. Y rellenar 64 KB con ceros es exactamente igual de correcto con 5 instrucciones que con 65.536.

graph LR
  A["Codigo x86-32"] --> B["Traductor JIT"]
  B --> C{"Patron basura?"}
  C -->|"Si"| D["Emitir bucle compacto"]
  C -->|"No"| E["Traduccion normal"]
  D --> F["Codigo nativo"]
  E --> F

Desenrollar un bucle al extremo cambia velocidad teórica por peso de código.

Contexto e historia: emuladores y traducción binaria

La frase 'Windows incluyó un emulador de x86' no señala un único producto: ha pasado varias veces. Cuando Windows NT corría sobre el procesador Alpha de DEC, existía FX!32, un sistema híbrido que combinaba emulación y traducción binaria para ejecutar aplicaciones x86 con rendimiento sorprendente para la época. Más tarde, Windows sobre Itanium incluyó su propia capa de ejecución x86. Y en la era moderna, Windows on ARM trae un emulador x86/x64 que permite correr aplicaciones de escritorio tradicionales sobre chips ARM, una pieza clave de los equipos con Snapdragon.

En todos los casos, la diferencia entre interpretar y traducir es enorme. Un intérprete lee cada instrucción del huésped y la simula en software, lo que multiplica el costo por instrucción. La traducción binaria compila bloques completos a código nativo una sola vez y luego los reutiliza, igual que un JIT de Java o de .NET reaprovecha el código generado. El precio que se paga es la complejidad del traductor y el riesgo de que el código generado crezca demasiado, justo lo que ocurrió aquí.

Apple recorrió un camino parecido con Rosetta 2 en la transición de Intel a Apple Silicon: traducción binaria anticipada (AOT) más un componente JIT para código generado en tiempo de ejecución. El patrón se repite porque funciona.

Por qué un compilador genera código así

El loop unrolling (desenrollado de bucles) es una optimización legítima y antigua. La idea: replicar el cuerpo del bucle varias veces para reducir el costo del salto y la comprobación de la condición en cada iteración, y de paso exponer más paralelismo a nivel de instrucción para que el procesador llene mejor su pipeline. Desenrollar por un factor de 4 u 8 suele ser razonable.

El problema es el extremo. Desenrollar por un factor de 65.536 deja de ser una optimización y se convierte en una patología. El cuerpo del bucle era una sola escritura de byte; el 'ahorro' de eliminar el contador y el salto es minúsculo frente al costo de generar un cuarto de megabyte de instrucciones que destrozan la caché de instrucciones y, en un binario, inflan el tamaño del ejecutable.

⚠️ Ojo: Más instrucciones nunca es gratis. Un bucle desenrollado al extremo puede ser más lento que el compacto si expulsa código útil de la caché L1 de instrucciones. La microoptimización a ciegas suele ser contraproducente.

Como apuntó un lector del blog original, los procesadores modernos ya hacen una forma de desenrollado en su pipeline de prefetch, y hay quien diseña su código deliberadamente para aprovecharlo. Existe el viejo compromiso entre código rápido pero glotón de memoria y código compacto pero más lento. Pero usar 256 KB para inicializar 64 KB no cae en ninguna zona sensata de ese compromiso: es, simplemente, un error de criterio del compilador.

Impacto y análisis para desarrolladores en LATAM

Más allá de la anécdota, hay lecciones concretas para quien escribe o ejecuta código en producción. La primera: medir antes de optimizar. Ninguna intuición sustituye a un perfilador. El compilador 'creyó' que desenrollar era mejor; un benchmark real habría mostrado lo contrario en segundos.

La segunda: cuando controlás la capa de ejecución —un intérprete propio, un transpilador, un motor de plantillas, un JIT— tenés libertad para reescribir patrones a algo equivalente y mejor. Muchos motores de bases de datos y runtimes de lenguajes hacen exactamente esto: reconocen patrones comunes y los sustituyen por implementaciones optimizadas. No es trampa; es ingeniería.

La tercera: el tamaño del código importa tanto como la cantidad de operaciones. En entornos con recursos ajustados —desde un microcontrolador hasta un contenedor con límites estrictos de memoria— un binario hinchado puede ser peor que uno con un bucle 'lento'. La caché de instrucciones es un recurso finito y caro.

💡 Tip: Antes de desenrollar a mano, confiá en intrínsecos como memset o en las instrucciones de cadena del CPU (rep stosb). El compilador y la microarquitectura suelen elegir mejor que vos para el hardware concreto.

Qué sigue

La historia es vieja, pero el problema es perfectamente actual. La transición de la industria hacia ARM —en servidores, portátiles y la nube— ha vuelto a poner la traducción binaria en el centro: Windows on ARM, Rosetta 2 de Apple, QEMU y proyectos como FEX o Box64 en Linux dependen de traductores que deben tomar decisiones inteligentes sobre el código que reciben, sin poder confiar en que venga limpio.

Esos traductores enfrentan a diario binarios generados por compiladores de décadas distintas, con heurísticas que ya no tienen sentido en el hardware actual. La capacidad de detectar antipatrones y reescribirlos —como hizo aquel equipo del emulador x86— seguirá siendo una ventaja competitiva. La anécdota de Raymond Chen no es nostalgia: es un recordatorio de que el código que escribimos hoy puede terminar ejecutándose en máquinas que ni imaginamos, traducido por sistemas que juzgarán nuestras decisiones.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es un emulador x86 con traducción binaria?

Es un sistema que ejecuta binarios x86 sobre un procesador de otra arquitectura compilando bloques de código x86 a instrucciones nativas del anfitrión, en lugar de interpretarlos una por una. Funciona como un compilador JIT y rinde mucho más que un intérprete clásico.

¿Por qué 256 KB de código para inicializar 64 KB?

El compilador desenrolló completamente el bucle de inicialización en 65.536 instrucciones de 'escribir un byte', cada una de 4 bytes. 65.536 × 4 = 262.144 bytes ≈ 256 KB, contra los 64 KB de datos que rellenaba.

¿El loop unrolling es malo entonces?

No en general. Desenrollar por un factor moderado (4 u 8) reduce el costo de saltos y mejora el paralelismo a nivel de instrucción. El problema es el extremo: un factor de 65.536 infla el código y castiga la caché de instrucciones, anulando cualquier ahorro.

¿Cómo arregló el problema el equipo del emulador?

Agregaron código al traductor binario para reconocer ese patrón concreto y reemplazarlo por un bucle compacto equivalente, del tipo rep stosb. Como un JIT solo debe preservar el comportamiento observable, la sustitución es totalmente correcta.

¿Qué procesador era?

Raymond Chen no lo precisó. Windows ha incluido emuladores de x86 en varias plataformas: Alpha (con FX!32), Itanium y, hoy, ARM. La anécdota podría aplicar a cualquiera de ellas.

¿Sigue siendo relevante esto en 2026?

Sí. La migración hacia ARM en escritorio, portátiles y nube ha revitalizado la traducción binaria (Windows on ARM, Rosetta 2, QEMU, FEX, Box64). Detectar y reescribir antipatrones en código heredado sigue siendo una capacidad valiosa.

Referencias

The Old New Thing — Raymond Chen — relato original del caso del emulador x86 y el código basura.
Wikipedia: Binary translation — explicación de la traducción binaria estática y dinámica.
Wikipedia: Loop unrolling — la optimización de desenrollado de bucles y sus compromisos.

Iroh 1.0: conexiones P2P por llave y soporte Python, Node, Swift y Kotlin

lu1tr0n — Mon, 15 Jun 2026 20:26:36 +0000

El equipo detrás de Iroh 1.0 publicó la primera versión estable de su librería de red con una premisa que suena a herejía para quien creció con TCP/IP: dejar de marcar direcciones IP y empezar a marcar llaves criptográficas. La idea es que tu dispositivo sea direccionable de forma segura sin importar dónde esté, detrás de cuántos firewalls o tras cuántos cambios de red.

Tras más de cuatro años de desarrollo abierto y 65 versiones previas, este lanzamiento congela el protocolo y las APIs. La pregunta para quien construye apps en LATAM es directa: ¿vale la pena cambiar la dirección IP por una llave? Veamos qué cambió y por qué importa.

TL;DR

Iroh 1.0 es la primera versión estable tras 4 años de desarrollo abierto y 65 versiones previas.
La idea central: marcar (dial) una llave criptográfica en lugar de una IP, que el dispositivo controla y conserva al moverse.
Los relays públicos del proyecto vieron más de 200 millones de endpoints creados en los últimos 30 días.
Implementa QUIC multipath y NAT traversal sobre QUIC para abrir conexiones directas y cambiar de ruta en caliente.
Suma soporte oficial para Python, Node.js, Swift y Kotlin, además del crate de Rust.
Iroh asegura estabilidad del protocolo de cable: un endpoint v1 habla con otro v1 sin importar versión menor ni lenguaje.
Es común que el 95% de los datos viajen directo entre dispositivos, reduciendo saltos por la nube y la factura de egress.
El soporte de relays públicos para la rama 0.35x continúa hasta el 31 de diciembre de 2026.

Qué pasó: Iroh llega a su versión 1.0

Iroh 1.0 marca el primer lanzamiento mayor del proyecto y, con él, un compromiso de estabilidad que antes no existía. La librería describe a sí misma como una capa de red que "simplemente funciona": uno le entrega la llave pública del dispositivo con el que quiere hablar y la librería se encarga del resto: descubrir rutas, atravesar NATs, abrir una conexión directa y cifrarla. Donde antes había que pausar funcionalidades por el costo de mantenimiento de las APIs, ahora hay una promesa explícita de compatibilidad.

El proyecto no nace hoy. Según el anuncio oficial, Iroh ya corre en millones de dispositivos y se usa para transmitir video, entrenar modelos de lenguaje, hablar con agentes, asegurar chats, jugar en línea y enviar archivos. La novedad de la versión 1.0 no es la capacidad técnica, que venía madurando, sino la garantía de que lo que construyas hoy seguirá funcionando mañana.

Iroh marca una llave pública en lugar de una dirección IP.

Marcar llaves, no IPs: la idea central de Iroh 1.0

El argumento de fondo es sencillo y, a la vez, profundo. Una dirección IP puede romperse sin aviso y está fuera del control de tu dispositivo: cambia cuando saltas de la red móvil al WiFi, cuando el proveedor reasigna el bloque, o cuando un firewall corporativo te deja inalcanzable. Una llave, en cambio, la creas y la controlas tú. Permanece igual aunque el dispositivo se mueva, y es tuya para conservar o desechar.

Sobre esa llave se construye todo lo demás. Se usa para asegurar la conexión, y como todos los datos que llegan por esa conexión quedan protegidos por la misma llave, encima de ella se levantan identidad, permisos y atribución. Esa misma llave funciona además como dirección para marcar al dispositivo, sin importar en qué parte del mundo esté. En palabras del propio equipo, convierte a internet en un localhost seguro.

💭 Clave: separar la identidad (la llave, estable y tuya) de la ubicación (la IP, volátil y ajena) es el cambio conceptual que sostiene a Iroh 1.0. Es la misma lógica que hace robusto a un sistema cuando la red por debajo es caótica.

Contexto e historia: 4 años y 65 versiones

Iroh 1.0 es la culminación de un camino largo. Durante el desarrollo, el equipo migró hacia estándares abiertos, prefiriendo borradores del IETF siempre que fue posible. Esa decisión es relevante: en vez de inventar un protocolo propietario, Iroh apuesta por interoperar con un ecosistema más amplio y por no quedar atrapado en una solución cerrada.

El proyecto también pasó por decisiones difíciles. En algún momento pausaron el soporte de FFI (la interfaz para usar Iroh desde otros lenguajes) por el costo de mantenerlo al día con una API que aún cambiaba mucho, y prometieron retomarlo con una API estable en la 1.0. Este lanzamiento cumple esa promesa. La historia de 65 versiones previas no es anecdótica: explica por qué el equipo se siente cómodo congelando el protocolo ahora y no antes.

Cómo funciona Iroh 1.0: QUIC multipath y NAT traversal

Debajo de la abstracción de "marcar una llave" hay ingeniería de red densa. El equipo construyó su propia implementación de QUIC multipath, lo que permite a Iroh administrar varias rutas dentro de una misma conexión e intercambiarlas en caliente conforme cambian las condiciones de red. Si te mueves de una red a otra, la conexión no se cae: cambia de camino sin que la aplicación se entere.

A eso se suma una implementación de NAT traversal sobre QUIC, que abre conexiones directas entre dispositivos manteniendo cifrados los detalles de la conexión. Iroh agrega configuraciones local-first para encontrar y conectar dispositivos en la red local sin acceso a internet, se compila a WebAssembly para correr en el navegador, y admite transportes personalizados como Bluetooth Low-Energy, LoRa (en construcción), WiFi Aware o incluso Tor, todos bajo la misma abstracción de marcar por llave.

graph LR
  A["Dispositivo A (llave pública)"] -->|"marca la llave"| R["Relay n0"]
  R -.->|"NAT traversal"| B["Dispositivo B (llave pública)"]
  A ==>|"conexión directa cifrada (95%)"| B

El flujo típico es el del diagrama: el relay ayuda a que dos dispositivos se descubran y atraviesen sus NATs, pero una vez establecida la ruta directa, la mayor parte del tráfico deja de pasar por la nube.

El relay solo ayuda a establecer la conexión; los datos van directos.

Datos y cifras del lanzamiento

Las cifras que acompañan el anuncio dan escala al proyecto. Los relays públicos que opera el equipo vieron más de 200 millones de endpoints creados en los últimos 30 días. Y en cuanto a eficiencia, es normal observar que el 95% de los datos de una conexión viajan directamente entre dispositivos. Ir directo significa menos saltos por la nube, lo que reduce tu factura de egress, y menos saltos por routers, lo que hace a internet más eficiente en conjunto.

💡 Tip: el ahorro de egress no es teórico. Si hoy pagas por mover datos entre usuarios a través de tu backend en la nube, una arquitectura donde el 95% del tráfico va directo entre clientes recorta esa partida de forma directa.

Soporte para Python, Node.js, Swift y Kotlin

Una de las novedades más prácticas de Iroh 1.0 es el regreso del soporte multilenguaje. Además del crate de Rust, ahora hay bindings oficiales para Python, Node.js, Swift y Kotlin. Esto cambia el panorama: puedes incrustar Iroh en una app de iOS en Swift o en una app de Android en Kotlin, o prototipar rápido desde Python o Node.js sin tocar Rust.

Un ejemplo conceptual en Python de cómo se vería crear un endpoint y conectar por llave (consultá la documentación oficial para la API exacta de tu versión):

import iroh

# Crear un endpoint con su propia llave (node id)
endpoint = iroh.Endpoint.builder().bind()
mi_llave = endpoint.node_id()
print(f"Mi node id (llave): {mi_llave}")

# Conectar a otro dispositivo usando SU llave, no su IP
llave_destino = ""
conn = endpoint.connect(llave_destino, alpn=b"mi-protocolo/0")
print("Conexion directa establecida")

Instalación de Iroh 1.0 en Windows, macOS y Linux

La instalación depende del lenguaje. Para el crate de Rust necesitás el toolchain instalado. Acá los comandos según tu sistema operativo:

# --- Instalar Rust ---
# Windows (PowerShell): descargar rustup-init.exe desde https://rustup.rs
#   o con winget:
winget install Rustlang.Rustup

# macOS / Linux:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# --- Agregar iroh al proyecto (igual en los 3 SO) ---
cargo add iroh

Para los lenguajes de scripting, los gestores de paquetes hacen el trabajo y son idénticos entre plataformas:

# Python (Windows / macOS / Linux)
pip install iroh

# Node.js (Windows / macOS / Linux)
npm install @number0/iroh

⚠️ Ojo: los nombres exactos de paquete y la firma de la API pueden variar entre versiones de los bindings. Antes de fijar versiones en producción, verificá la documentación generada de la API para el lenguaje que uses.

Estabilidad del protocolo y política de versiones

Iroh 1.0 afirma estabilidad tanto del protocolo de cable como de las APIs de cada lenguaje: un endpoint v1 podrá comunicarse con otro endpoint v1 sin importar la versión menor ni el lenguaje. En el futuro podrían versionar ambos aspectos de forma independiente —por ejemplo, sacar una versión 2 de la API de un lenguaje manteniendo compatibilidad en el cable—, pero cualquier cambio que afecte la estabilidad del protocolo coincidirá siempre con un lanzamiento mayor.

Sobre soporte, el equipo publicó un calendario. Las versiones mayores y menores posteriores a la 1.0 se soportan según ese cronograma. La rama menor 0.35 no recibirá más releases, aunque el soporte de relays públicos para 0.35x continúa hasta el 31 de diciembre de 2026. Las versiones canary (0.9x) y los release candidates (1.0.0-rcX) dejan de soportarse, con relays públicos operativos hasta el 30 de septiembre de 2026. Un detalle de operación: el equipo actualiza los relays públicos a la última versión poco después de cada release, normalmente en 24 horas, y los cambios que rompan compatibilidad de cable estrenan URLs nuevas para que los clientes viejos sigan funcionando.

Impacto y análisis para desarrolladores en LATAM

Para el contexto latinoamericano, donde el NAT de operador (CGNAT) es la norma y muchos usuarios nunca tienen una IP pública estable, el modelo de Iroh 1.0 resuelve un dolor real. Las apps peer-to-peer —transferencia de archivos, juegos, sincronización, llamadas— suelen sufrir aquí porque establecer conexión directa entre dos clientes detrás de CGNAT es difícil. Iroh hace de ese problema su especialidad.

El ahorro de egress también pesa más en mercados sensibles al costo. Si tu producto mueve datos entre usuarios a través de servidores en la nube y cobrás en moneda local mientras pagás infraestructura en dólares, mover el 95% del tráfico a conexiones directas mejora márgenes de forma tangible. Sumado a los bindings para Swift y Kotlin, Iroh 1.0 se vuelve una opción concreta para apps móviles regionales que quieran funciones colaborativas sin levantar y pagar una flota de servidores intermediarios.

Qué sigue

El mensaje del equipo es que el momento de construir es ahora: con la 1.0 hay un stack de red maduro que se puede integrar con confianza. Las piezas en desarrollo, como el transporte sobre LoRa, apuntan a escenarios de conectividad extrema —IoT rural, redes mesh, zonas sin internet—, justo donde la abstracción de "marcar una llave" en lugar de una IP brilla más. Habrá que ver cómo evoluciona la adopción ahora que la barrera de la inestabilidad de API quedó atrás y el soporte multilenguaje abre la puerta a comunidades fuera de Rust.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué significa "marcar llaves, no IPs" en Iroh 1.0?

Significa que identificás y conectás a un dispositivo por su llave criptográfica pública (su node id) en lugar de por una dirección IP. La llave es estable y la controla el dispositivo; la IP es volátil y depende de la red. Iroh se encarga de encontrar la ruta real por debajo.

¿Necesito saber Rust para usar Iroh?

No. Aunque Iroh está escrito en Rust, la versión 1.0 ofrece bindings oficiales para Python, Node.js, Swift y Kotlin, así que podés integrarlo desde esos lenguajes sin escribir Rust.

¿Los datos pasan siempre por un servidor relay?

No necesariamente. El relay ayuda a que dos dispositivos se descubran y atraviesen sus NATs, pero una vez establecida la conexión directa es común que el 95% de los datos viajen directamente entre los dispositivos, sin pasar por la nube.

¿Iroh 1.0 garantiza compatibilidad hacia el futuro?

Sí dentro de la versión mayor 1: un endpoint v1 puede comunicarse con otro v1 sin importar la versión menor ni el lenguaje. Cualquier cambio que rompa la compatibilidad del protocolo de cable coincidirá con un lanzamiento mayor.

¿Hasta cuándo funcionan los relays de versiones viejas?

Los relays públicos para la rama 0.35x operan hasta el 31 de diciembre de 2026, mientras que los de versiones canary (0.9x) y los release candidates (1.0.0-rcX) lo hacen hasta el 30 de septiembre de 2026.

¿Para qué casos de uso sirve Iroh?

Según el equipo, ya se usa para transmitir video, entrenar modelos de lenguaje, hablar con agentes, asegurar chats, jugar, sincronizar y enviar archivos. Brilla especialmente en escenarios peer-to-peer detrás de NAT, comunes en redes móviles y CGNAT.

Referencias

Iroh 1.0 - Dial Keys, not IPs — anuncio oficial del lanzamiento.
n0-computer/iroh en GitHub — código fuente, issues y releases del proyecto.
Documentación oficial de Iroh — guías, quickstart y referencia de API.
Draft IETF: QUIC Multipath — borrador del estándar en que se inspira el multipath de Iroh.

Llama 3.1 405B consume 0,39 Wh por consulta, según ML.ENERGY

lu1tr0n — Mon, 15 Jun 2026 16:10:57 +0000

El consumo energético de la IA dejó de ser una estimación de servilleta. Investigadores de la Universidad de Michigan publicaron ML.ENERGY, un benchmark abierto que mide cuánta energía gasta realmente cada modelo de inteligencia artificial al responder, modelo por modelo y token por token.

El dato que rompe el consenso: las cifras que circulan, casi todas derivadas del TDP de la GPU, exageran el gasto real hasta 4,1 veces. La medición directa cuenta otra historia, y por primera vez está disponible en una tabla pública y reproducible.

TL;DR

ML.ENERGY, de la Universidad de Michigan, mide el consumo energético real de más de 40 modelos de IA por consulta.
Llama 3.1 405B gasta una mediana de 0,39 Wh por consulta; Mixtral 8x22B baja a 0,06 Wh y Llama 3.1 8B a 0,02 Wh.
La herramienta Zeus mide la energía directa de la GPU, que supone el 50-70% de la potencia del centro de datos.
Estimar por TDP exagera el consumo: hasta 4,1 veces más para CodeGemma 2B frente a la medición real.
El batching amortiza energía: a mayor lote, menor gasto por consulta en la fase de generación de tokens.
Optimizar sin cambiar el cómputo ahorra más del 40%: un 44% en Llama 3.1 8B al relajar la latencia.
La generación de texto tiene baja intensidad de cómputo; la difusión de imágenes se acerca al tope de la GPU.

Qué pasó

Un equipo del grupo SymbioticLab de la Universidad de Michigan, liderado por el profesor Mosharaf Chowdhury y con Jae-Won Chung como primer autor, actualizó en febrero de 2026 el ML.ENERGY Leaderboard, una tabla clasificatoria que ordena modelos generativos según la energía que consumen al ejecutar inferencia. No es una proyección teórica: cada cifra proviene de medir el gasto eléctrico real de las GPU mientras los modelos responden.

El proyecto se apoya en Zeus, una biblioteca de código abierto desarrollada por el mismo grupo que lee los contadores de energía de la GPU por software, sin necesidad de instrumentación física. La tabla, su código y el conjunto de datos están publicados, de modo que cualquiera puede reproducir las mediciones o añadir modelos nuevos. El acompañamiento académico es el artículo The ML.ENERGY Benchmark, que detalla la metodología y los resultados sobre unas 40 arquitecturas distintas.

Las GPU concentran el 50-70% de la potencia provisionada en un centro de datos de IA.

Contexto e historia

La pregunta "¿cuánta energía gasta una consulta a un modelo de IA?" se volvió central a medida que los centros de datos crecían. El problema es que casi todas las respuestas públicas se calculaban de la misma forma poco fiable: tomar el TDP (la potencia máxima de diseño) de la GPU, multiplicarlo por un tiempo estimado y repartirlo entre las consultas. Es cómodo, pero parte de un supuesto falso, que el chip trabaja siempre a tope.

En la práctica, generar texto rara vez exige el máximo de la GPU. La fase de decodificación —producir un token tras otro— es un proceso limitado por la memoria, no por el cálculo: el acelerador pasa buena parte del tiempo esperando datos en lugar de quemando vatios. Por eso el TDP es un mal estimador. ML.ENERGY nació justamente para sustituir ese atajo por una medición directa y comparable, y para mostrar que la conversación sobre el consumo energético de la IA estaba apoyada en números inflados.

💭 Clave: El TDP mide cuánto podría consumir una GPU, no cuánto consume de verdad al generar texto. Confundir ambos infla las estimaciones hasta varias veces.

Datos y cifras: el consumo energético de la IA medido por consulta

Las mediciones se hicieron sobre GPU NVIDIA A100 (40 GB) y H100 (80 GB) en instancias de AWS, midiendo en estado estacionario, es decir, cuando el servidor está saturado de peticiones tal como ocurre en producción. La energía por consulta se calcula como la energía total del lote dividida entre el número de peticiones, multiplicada por la longitud media de salida. Estos son algunos resultados representativos:

Llama 3.1 405B — mediana de unos 0,39 Wh por consulta, de los más altos entre los modelos densos grandes.
Mixtral 8x22B — alrededor de 0,06 Wh por consulta gracias a su arquitectura de mezcla de expertos (MoE), que solo activa una fracción de sus parámetros.
Llama 3.1 8B — en torno a 0,02 Wh por consulta.
Mistral 7B — cerca de 0,01 Wh en una tarea de chat típica.

La diferencia entre el modelo más pesado y el más ligero supera un factor de 30. También aparece el hallazgo que más matiza el discurso público: estimar por TDP exagera el gasto hasta 4,1 veces en el caso de CodeGemma 2B frente a la medición real. Otro contraste interesante es entre tareas: la generación de imágenes con modelos de difusión se acerca al límite de potencia de la GPU, mientras que la generación de texto se queda muy por debajo.

El flujo de medición es conceptualmente sencillo:

graph LR
  A["Consulta del usuario"] --> B["Servidor de inferencia (lote)"]
  B --> C["GPU genera tokens"]
  C --> D["Zeus mide la energia de la GPU"]
  D --> E["Energia por consulta = energia del lote / numero de consultas"]

Medir con Zeus dentro del propio servicio de inferencia es directo. Un esquema simplificado del patrón:

from zeus.monitor import ZeusMonitor

monitor = ZeusMonitor(gpu_indices=[0])
monitor.begin_window("inferencia")

# El modelo genera la respuesta para todo el lote
salida = modelo.generate(lote_de_prompts)

medida = monitor.end_window("inferencia")
print(f"Energia del lote: {medida.total_energy} J")
print(f"Por consulta: {medida.total_energy / len(lote_de_prompts)} J")

El detalle decisivo es el batching. En producción, decenas de consultas se procesan juntas en un mismo lote, y la energía se reparte entre todas. Cuanto mayor es el lote, menor es el gasto por consulta, porque el coste fijo de cargar los pesos del modelo en memoria se amortiza entre más peticiones. Por eso medir un modelo respondiendo a un único prompt aislado sobreestima brutalmente el consumo: nadie sirve un modelo así.

El gasto por consulta varía más de 30 veces entre el modelo más pesado y el más ligero.

💡 Tip: Si necesitás reducir el consumo energético de la IA en tu propio despliegue, lo primero no es cambiar de modelo, sino aumentar el tamaño de lote y relajar la latencia donde el caso de uso lo permita.

Impacto y análisis

La consecuencia práctica es doble. Por un lado, ML.ENERGY ofrece a quien despliega modelos una base empírica para elegir: un MoE como Mixtral puede dar calidad comparable a un denso grande con una fracción del gasto, y un modelo de 8B resuelve muchas tareas con la vigésima parte de la energía de uno de 405B. Por otro, el benchmark desmonta titulares alarmistas construidos sobre estimaciones de TDP: el consumo energético de la IA es real y crece, pero los números que circulaban estaban, en muchos casos, varias veces inflados.

El trabajo también muestra que se puede ahorrar mucho sin tocar el resultado del modelo. Aplicando recomendaciones de optimización automática —ajustar la frecuencia de la GPU, el tamaño de lote o los límites de latencia— el equipo logró reducciones de más del 40%, con un caso concreto del 44% en Llama 3.1 8B al relajar las restricciones de latencia. Es energía que hoy se desperdicia simplemente por servir los modelos con la configuración de fábrica.

Para periodistas, reguladores y responsables de sostenibilidad, el mensaje es que la medición importa: apoyar políticas o promesas de eficiencia en cifras de TDP produce conclusiones engañosas. Una tabla abierta y reproducible es una herramienta mucho más sólida para discutir el coste ambiental de esta tecnología con datos en la mano.

Qué sigue

El ML.ENERGY Leaderboard es un proyecto vivo: se actualiza con nuevos modelos y hardware, y su naturaleza abierta invita a que otros laboratorios contribuyan mediciones. La frontera más interesante por cubrir es la del razonamiento. Esta edición se centra en cargas de inferencia clásicas (chat, código, texto a imagen), pero los modelos que "piensan" mediante test-time scaling generan cadenas largas de tokens internos antes de responder, lo que puede multiplicar la energía por consulta. Medir ese coste con el mismo rigor será el siguiente capítulo.

A más largo plazo, la propuesta del grupo es que la eficiencia energética se trate como una métrica de primera clase, junto a la precisión y la latencia, en cada decisión de diseño del stack de IA. Si esa idea cuaja, el consumo energético de la IA dejará de ser una nota al pie para convertirse en un número que se reporta y se optimiza de serie.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es ML.ENERGY?

Es un benchmark y una tabla clasificatoria abiertos, creados por la Universidad de Michigan, que miden cuánta energía consumen los modelos generativos de IA al ejecutar inferencia. Ordena más de 40 arquitecturas por gasto energético por consulta.

¿Cuánta energía gasta una consulta a un modelo grande?

Según las mediciones, un modelo denso grande como Llama 3.1 405B consume una mediana cercana a 0,39 Wh por consulta. Modelos más pequeños como Llama 3.1 8B bajan a unos 0,02 Wh, una diferencia de más de un orden de magnitud.

¿Por qué las estimaciones por TDP son inexactas?

El TDP es la potencia máxima de diseño de la GPU, pero la generación de texto está limitada por la memoria y rara vez exige ese máximo. Calcular el gasto por TDP exagera el consumo: hasta 4,1 veces para CodeGemma 2B frente a la medición real.

¿Qué es Zeus?

Zeus es la biblioteca de código abierto que usa ML.ENERGY para medir la energía de la GPU directamente por software, leyendo sus contadores durante la inferencia. Es la base técnica que permite obtener cifras reales en lugar de estimadas.

¿Cómo se puede reducir el consumo energético de la IA al servir modelos?

El batching es clave: agrupar consultas en lotes grandes reparte el coste fijo y baja el gasto por consulta. Ajustar la frecuencia de la GPU y relajar la latencia logró ahorros de más del 40% sin cambiar el resultado del modelo.

¿Los modelos de mezcla de expertos consumen menos?

Tienden a ser más eficientes por consulta porque solo activan una fracción de sus parámetros. Mixtral 8x22B gasta unos 0,06 Wh, muy por debajo de un modelo denso de tamaño comparable en parámetros totales.

Referencias

ML.ENERGY Leaderboard (GitHub) — código abierto del benchmark y la tabla de consumo energético.
The ML.ENERGY Benchmark (arXiv) — artículo con la metodología, Zeus y resultados sobre 40 modelos.
ML.ENERGY Leaderboard (Hugging Face) — tabla interactiva con la energía por consulta de cada modelo.
Power-hungry AI (Michigan CSE) — nota oficial de la universidad sobre el estudio.
Per-query energy consumption of LLMs (Muxup) — análisis independiente de las cifras por consulta.

Una línea de CSS válido vuelve "corrupto" tu EPUB en Kobo

lu1tr0n — Mon, 15 Jun 2026 02:17:33 +0000

Un EPUB en Kobo puede aparecer como "archivo corrupto" aunque haya pasado epubcheck sin un solo error. Eso fue exactamente lo que descubrió un autor independiente: su nuevo libro, validado al 100% contra la versión 3.3 del estándar, funcionaba en Kindle, Apple Books y Thorium, pero se negaba a abrir en cualquier lector Kobo, de cualquier generación.

El responsable no era un manifest mal armado ni una imagen rota. Era una sola línea de CSS perfectamente válido. La historia es un recordatorio incómodo de que validar contra el estándar no garantiza que tu libro funcione en el mundo real.

TL;DR

Un EPUB que pasó epubcheck 3.3 sin errores aparecía como "archivo corrupto" en todos los lectores Kobo del autor.
El mismo libro abría sin problemas en Kindle, Apple Books y Thorium; solo Kobo lo rechazaba.
La causa: Kobo usa RMSDK, el motor de Adobe que también mueve Adobe Digital Editions.
RMSDK nació hacia 2010 y su parser de CSS quedó congelado alrededor de 2013: sin flexbox, grid, variables ni funciones matemáticas.
El detonante fue una sola línea: max-width: min(150px, 30vw), CSS válido que RMSDK no reconoce.
Al ver CSS desconocido, RMSDK no degrada ni avisa: descarta el libro completo en silencio.
epubcheck no puede atrapar el problema porque valida contra el estándar, no contra un motor roto.
Cambiar la línea a max-width: 150px resolvió el fallo por completo.

Qué pasó: un libro válido que Kobo rechaza

El autor distribuye sus libros como archivos EPUB libres de DRM, algo poco común y que se agradece. Antes de publicar, cada archivo pasa por una batería de procesos hasta que aprueba epubcheck, la herramienta de referencia para validar libros electrónicos bien formados. Es exigente hasta la obsesión: si tu manifest no declara cada fragmento e imagen, si usas elementos HTML fuera de orden o te desvías mínimamente de las reglas del estándar EPUB, no pasa.

Tras meses de trabajo, el libro aprobó epubcheck con la versión 3.3 del estándar sin un solo aviso. Y aun así, un lector escribió para reportar que el archivo estaba "corrupto". El autor probó entregarle también una versión EPUB2, igualmente conforme a las reglas, pensando en compatibilidad hacia atrás. Mismo resultado: el libro no abría en ninguno de sus dispositivos Kobo.

La pregunta es la que cualquier desarrollador se haría: ¿qué haces cuando el patrón de oro dice que tu archivo está bien, funciona en todas partes, pero un lector específico insiste en que está roto?

El mismo EPUB funcionaba en Kindle y Apple Books, pero no en Kobo.

Por qué un EPUB en Kobo termina como "corrupto"

La pista clave aparece al investigar qué motor usa Kobo por dentro. La respuesta es RMSDK, las siglas de "Reader Mobile Software Development Kit", el motor de renderizado propietario de Adobe. Es el mismo corazón que late dentro de Adobe Digital Editions, esa aplicación que muchos recordamos más por su gestión de DRM que por la experiencia de lectura, y también el motor presente en varios dispositivos Kobo y en antiguos Sony y Nook.

RMSDK fue construido alrededor de 2010, pensado para EPUB2. Recibió actualizaciones ligeras para soportar EPUB3, pero nunca fue modernizado de verdad. El problema no es solo que esté viejo: es cómo reacciona ante lo que no entiende. En lugar de ignorar una propiedad CSS desconocida, como manda el propio estándar para garantizar compatibilidad hacia adelante, RMSDK simplemente descarta el libro entero. Sin mensaje de error, sin pantalla de fallback, sin un solo indicio de qué salió mal.

graph LR
  A["EPUB valido"] --> B["epubcheck 3.3: OK"]
  B --> C{"Que motor lo abre"}
  C -->|"Kindle / Apple Books"| D["Renderiza bien"]
  C -->|"Kobo con RMSDK"| E["CSS min() no reconocido"]
  E --> F["Libro descartado: archivo corrupto"]

Para depurarlo, el autor cargó el libro en Adobe Digital Editions, esperando un mensaje útil. Como era de esperar, falló al cargar. Pero lo hizo en el peor estilo posible: sin error, sin queja, solo una pantalla en blanco. El único rastro de que lo había intentado fue que, al reintentar, ADE respondía "no puedes importar ese libro, ya lo agregaste". Clásico.

Contexto: RMSDK, un motor congelado en 2013

Identificar a RMSDK como sospechoso no resolvía el caso, pero daba un camino. El autor empezó a desarmar su libro, creando una docena de variantes mientras se aseguraba de que cada una siguiera pasando epubcheck. Reorganizó carpetas, vació metadatos, eliminó atributos de idioma, generó UUID nuevos, aplanó directorios, renombró extensiones y reconstruyó el ZIP desde cero varias veces. Y falló. Y falló. Y volvió a fallar.

Cuando estaba a punto de rendirse, se le ocurrió desactivar la hoja de estilos. De golpe, el libro abrió. Con el CSS identificado como origen del problema, fue cuestión de bisección: crear subconjuntos del stylesheet hasta aislar la línea culpable. Resultó ser esta:

.copyright img {
  max-width: min(150px, 30vw);
}

Al cambiarla por la versión clásica, todo funcionó:

.copyright img {
  max-width: 150px;
}

¿Cuál es el problema con la primera versión? Ninguno, desde el punto de vista del estándar. min() es una función matemática de CSS perfectamente válida y ampliamente soportada en navegadores. El problema es que el parser de CSS de RMSDK quedó congelado aproximadamente en 2013: sin flexbox, sin grid, sin funciones matemáticas, sin propiedades personalizadas (variables). Solo float de la vieja escuela, manejo deficiente de fuentes y caídas silenciosas cuando ve algo que no reconoce.

RMSDK descarta el libro entero ante una sola propiedad CSS desconocida.

⚠️ Ojo: RMSDK no ignora la propiedad que no entiende, como exige el modelo de compatibilidad hacia adelante de CSS. Descarta el archivo completo. Una línea inválida para el motor equivale a un libro inservible.

Datos y cifras del caso

No estamos ante un bug aislado de versión: hablamos de un motor con unos 16 años de antigüedad que sigue en producción. RMSDK se diseñó hacia 2010 para EPUB2 y su soporte de CSS se detuvo alrededor de 2013. En la práctica, eso significa que toda la familia de CSS moderna que damos por sentada en la web queda fuera: display: flex, display: grid, las variables --mi-color, y las funciones min(), max(), clamp() y calc() con unidades mixtas.

El detalle más revelador es el contraste de comportamientos. El mismo archivo, byte por byte, abría sin problemas en Kindle, Apple Books y Thorium. Tres motores distintos lo aceptaban; uno lo rechazaba. Y la diferencia entre "libro perfecto" y "archivo corrupto" era exactamente una línea de CSS y dos palabras: min(150px, 30vw) contra 150px.

¿Por qué epubcheck no lo detectó? Porque hace una validación básica de CSS, pero no puede validar tu hoja de estilos contra un motor que está fundamentalmente roto. epubcheck comprueba conformidad con el estándar, no compatibilidad con cada lector real del mercado. Es, como lo describe el autor, lo más parecido a un "type-linter" o suite de pruebas que tienen quienes publican libros, pero su garantía termina donde empieza un renderizador que ignora el estándar.

Impacto y análisis para autores y devs en LATAM

Para quien publica de forma independiente en español —y el ecosistema de autopublicación en LATAM no para de crecer— esta clase de fallo es especialmente dañina. Un lector que paga por tu libro, lo descarga y obtiene un mensaje de "archivo corrupto" rara vez sospecha del motor de Adobe. Sospecha de ti. La percepción es que el autor entregó un producto defectuoso, cuando en realidad el archivo es impecable según el estándar.

El problema escala. Kobo tiene presencia fuerte fuera del ecosistema Amazon, y es una de las pocas plataformas que respeta formatos abiertos y DRM-free. Que su motor de renderizado se atragante con CSS moderno castiga precisamente a quienes apuestan por la portabilidad y los archivos abiertos. Un EPUB en Kobo debería ser un terreno seguro para el formato libre, y termina siendo el más frágil.

💭 Clave: Pasar epubcheck es necesario pero no suficiente. La validación contra el estándar y la compatibilidad con motores reales son dos cosas distintas, y el segundo es el que ve tu lector.

Hay una lección de ingeniería más amplia aquí, válida más allá de los ebooks: el manejo de errores importa tanto como la funcionalidad. Un motor que ante una propiedad desconocida la ignora y sigue, degrada con gracia. Un motor que descarta todo el documento sin avisar convierte un detalle cosmético en una falla total. Es la diferencia entre fail open con un fallback y fail closed en silencio.

Cómo evitar que tu EPUB falle en Kobo

La conclusión amarga es que confiar solo en epubcheck no alcanza si te importan los lectores Kobo. Estas son las prácticas que reducen el riesgo:

Escribe CSS conservador — Evita min(), max(), clamp(), variables, flexbox y grid en las hojas de estilo del EPUB. Prefiere float, anchos en píxeles o porcentajes simples y propiedades soportadas desde hace una década.
Usa valores estáticos para imágenes — En lugar de max-width: min(150px, 30vw), opta por max-width: 150px o, si necesitas adaptabilidad, un porcentaje sencillo como max-width: 30%.
Prueba en un motor RMSDK — Carga el archivo en Adobe Digital Editions o en un Kobo real antes de publicar. Es la única forma de ver lo que verá ese lector.
Mantén epubcheck igualmente — Sigue siendo tu primera línea de defensa contra errores reales del estándar; solo no lo tomes como garantía total.

Para validar localmente, epubcheck se instala en cualquier sistema. Aquí los tres entornos:

# macOS (Homebrew)
brew install epubcheck
epubcheck mi-libro.epub

# Linux (Debian/Ubuntu)
sudo apt install epubcheck
epubcheck mi-libro.epub

# Windows (Scoop) o multiplataforma con el JAR
scoop install epubcheck
# o descarga el .jar desde github.com/w3c/epubcheck y corre:
java -jar epubcheck.jar mi-libro.epub

💡 Tip: Si necesitas un ancho adaptable y no quieres romper RMSDK, una regla simple como max-width: 30%; max-height: 150px; suele cubrir el caso sin recurrir a funciones matemáticas que el motor de Adobe no entiende.

Qué sigue

En un mundo ideal, RMSDK dejaría la edad de piedra del CSS o, al menos, manejaría los errores en vez de descartar el libro entero. Pero el motor lleva más de una década sin modernizarse y poco indica que eso vaya a cambiar pronto, probablemente porque su valor para la plataforma está más en el DRM que en la experiencia de lectura. La industria de la publicación digital sigue más obsesionada con restringir el acceso que con dar la mejor experiencia posible.

Mientras eso no cambie, la responsabilidad recae en quien publica. Si quieres asegurarte de que tu libro sea compatible con Kobo, vas a tener que probarlo contra un motor RMSDK y escribir tu CSS pensando en lo que un parser de 2013 puede entender. No es justo, pero es el terreno real donde aterrizan tus lectores.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Por qué mi EPUB pasa epubcheck pero falla en Kobo?

Porque epubcheck valida tu archivo contra el estándar EPUB, no contra el motor real de cada lector. Kobo usa RMSDK, de Adobe, cuyo parser de CSS quedó congelado hacia 2013. Si tu hoja de estilos usa CSS moderno como min() o flexbox, RMSDK puede descartar el libro completo aunque epubcheck lo apruebe.

¿Qué es RMSDK y por qué importa?

RMSDK (Reader Mobile Software Development Kit) es el motor de renderizado propietario de Adobe que está dentro de Adobe Digital Editions y de varios dispositivos Kobo, Sony y Nook. Importa porque define qué CSS funciona realmente en esos lectores, y su soporte se detuvo hace más de una década.

¿Qué CSS debo evitar para que mi libro funcione en Kobo?

Evita funciones matemáticas como min(), max(), clamp() y calc() con unidades mixtas, además de flexbox, grid y variables CSS. Prefiere float, anchos en píxeles o porcentajes simples, soportados desde hace muchos años.

¿Cómo aislo qué línea de CSS rompe el libro?

Desactiva primero toda la hoja de estilos y confirma que el libro abre. Luego reincorpora el CSS por subconjuntos (bisección) hasta encontrar la regla concreta que provoca el fallo, validando con epubcheck en cada paso para no introducir errores reales.

¿Sirve de algo seguir usando epubcheck?

Sí. epubcheck sigue siendo la mejor defensa contra errores reales de conformidad con el estándar: manifests incompletos, HTML mal ordenado o metadatos faltantes. Solo no debe tomarse como garantía de que el libro funcionará en todos los lectores; complementa con pruebas en un motor RMSDK.

Referencias

André Klein — "Your EPUB Is Fine. Kobo Disagrees. Blame Adobe" — relato original del caso y la depuración línea por línea.
w3c/epubcheck en GitHub — validador oficial de EPUB, mantenido por el W3C.
MDN — función CSS min() — documentación de la función matemática que detonó el fallo.
W3C — EPUB 3.3 — especificación del estándar contra el que valida epubcheck.

Chaosnet: la red del MIT de 1975 que sigue viva en el DNS

lu1tr0n — Sun, 14 Jun 2026 20:19:29 +0000

En 1975, mucho antes de que internet fuera lo que conocemos hoy, el laboratorio de Inteligencia Artificial del MIT construyó Chaosnet, una red local pensada para conectar sus máquinas Lisp. Medio siglo después esa red está oficialmente muerta, salvo por un detalle incómodo: una de sus piezas sigue viva dentro de prácticamente cada servidor DNS del planeta.

Este artículo reconstruye qué fue Chaosnet, cómo funcionaba su diseño deliberadamente simple y por qué su legado todavía aparece cuando ejecutás dig CH TXT version.bind contra un servidor de nombres cualquiera.

TL;DR

Chaosnet nació en 1975 en el MIT AI Lab para conectar máquinas Lisp, inspirada en el Ethernet experimental de Xerox PARC.
Usaba cable coaxial de 75 ohmios, rondaba los 4 Mbit/s y soportaba unas pocas docenas de nodos en hasta 1 km.
No tenía control centralizado: de ahí el nombre 'Chaos', no existía un nodo maestro que coordinara la red.
Su legado vivo es la clase CHAOS (CH) del DNS, usada hoy para fingerprinting con version.bind.
El comando dig CH TXT version.bind @servidor revela la versión de BIND de muchos resolutores DNS.
IANA mantiene la clase CH con el valor 3 en su registro oficial de clases DNS, junto a IN (Internet).

Qué es Chaosnet

Chaosnet es el nombre de una red de área local diseñada en el MIT a mediados de los años setenta. La palabra describe una idea concreta: la ausencia de cualquier elemento de control centralizado. En Chaosnet no hay un nodo maestro, ni un servidor que reparta turnos, ni una autoridad que decida quién transmite. Todos los nodos contienden por el medio en igualdad de condiciones, y esa decisión de diseño —que en su momento parecía arriesgada— fue justamente la que la hizo confiable.

El objetivo original era resolver un problema muy específico. El sistema de máquinas Lisp del MIT le asignaba a cada usuario activo una computadora personal: un procesador de escala media, memoria suficiente y un disco de intercambio. Pero los archivos vivían en un sistema central, y ese sistema de archivos compartido se accedía a través de Chaosnet. En la práctica, Chaosnet ocupaba el lugar del disco de archivos en un sistema convencional. Eso le imponía tres requisitos no negociables: tenía que ser rápida tanto en latencia como en rendimiento, tenía que ser confiable, y tenía que permitir conectar varias docenas de máquinas.

Lo interesante es cómo lograron esa velocidad: no con algoritmos ingeniosos, sino con un medio de transmisión muy rápido operado de la forma más simple posible. La filosofía completa de Chaosnet se puede resumir en una frase: empezá con un canal veloz y no le agregues complejidad innecesaria encima.

Chaosnet conectaba las máquinas Lisp del MIT a través de un cable coaxial compartido.

Contexto e historia: el MIT, las máquinas Lisp y Xerox PARC

Para entender por qué Chaosnet importa hay que ubicarse en la época. En 1975 no existía una pila de protocolos universal. ARPANET funcionaba, TCP estaba en pañales y el concepto mismo de red local apenas se estaba inventando. El trabajo pionero venía de Xerox PARC, donde Robert Metcalfe y David Boggs habían diseñado el Ethernet experimental: un cable compartido sobre el que las máquinas competían por transmitir paquetes. Chaosnet reconoce abiertamente esa deuda; su hardware ofrece una estructura de acceso múltiple con detección de portadora muy parecida a aquel Ethernet de PARC.

La diferencia es de propósito. El MIT no quería una red de propósito general capaz de cruzar el continente. Quería algo que reemplazara al disco de un sistema de tiempo compartido para un puñado de máquinas Lisp dentro de uno o dos kilómetros. Esa restricción fue una bendición de diseño: los ingenieros simplemente ignoraron todos los problemas que no aplicaban. Chaosnet no tiene previsiones especiales para enlaces lentos, enlaces ruidosos con alta tasa de error, múltiples caminos, ni enlaces de larga distancia con tiempo de tránsito significativo. Tampoco intenta ofrecer múltiples niveles de servicio ni comunicación segura más allá del cifrado de extremo a extremo.

El software, por su parte, tomó ideas prestadas de Ethernet, de TCP y de ARPANET, sumándoles modificaciones propias. Esa mezcla pragmática —agarrar lo que funcionaba de cada fuente sin atarse a ninguna— es muy reconocible para cualquier desarrollador que haya construido un sistema bajo presión de tiempo. Chaosnet no buscaba ser elegante en el papel; buscaba andar rápido y no romperse.

Cómo funcionaba: hardware simple, software sin jefe

El medio físico de Chaosnet se llamaba, sin rodeos, el ether. Era un cable coaxial semirrígido de media pulgada y baja pérdida, del tipo que se usaba para televisión por cable, con terminación de 75 ohmios en ambos extremos. En cada nodo, un transceptor se conectaba al cable. Un cable plano de diez metros unía ese transceptor con una interfaz enchufada al bus de entrada/salida de la computadora. Y dentro de la computadora corría un programa llamado NCP (Network Control Program) que gestionaba toda la red además de la aplicación que justificaba la existencia del nodo.

La regla de operación era brutalmente simple: un solo nodo a la vez podía tomar el ether y transmitir un paquete, que llegaba a todos los demás nodos. Cada nodo decidía en hardware si ignorar el paquete o recibirlo. El cable tenía que ser una línea recta: sin ramas, sin derivaciones, sin formar un círculo. Para extender el alcance más allá de un kilómetro se usaban bridges (puentes), nodos que retransmitían paquetes entre dos tramos de cable distintos.

graph LR
  N1["Nodo: maquina Lisp"] --> T1[Transceptor]
  T1 --> E["Ether: cable coaxial 75 ohmios"]
  N2["Nodo: file server"] --> T2[Transceptor]
  T2 --> E
  E --> B[Bridge]
  B --> E2["Otro ether"]

La contención por el cable seguía un esquema de detección de portadora: antes de transmitir, un nodo escuchaba si el ether estaba libre. Si dos nodos transmitían a la vez, había colisión y reintentaban. Es el mismo principio que hizo famoso a Ethernet, pero llevado a su mínima expresión. La clave estaba en no caer en algoritmos tan simples que dejaran de funcionar o desperdiciaran el canal.

💭 Clave: Quitar el control centralizado no fue un capricho: era la forma de hacer la red confiable. Sin un nodo maestro, no había un único punto de falla que pudiera tumbar toda la comunicación.

Esa simplicidad también pagaba en mantenimiento. Chaosnet conectaba máquinas muy distintas, así que existían varias implementaciones del mismo protocolo, y cada implementación requería mantenimiento en proporción a su complejidad. Mantener el diseño chico permitía aislar rápido una falla: saber si el problema estaba en el cable, en el hardware de un host o en su software. En una red usada por grupos diversos dentro de una sola institución, esa capacidad de diagnóstico valía oro.

Datos y cifras

Año de origen: 1975, en el MIT Artificial Intelligence Laboratory.
Medio físico: cable coaxial de 1/2 pulgada, 75 ohmios, terminado en ambos extremos.
Alcance: aproximadamente 1 km por tramo de ether, limitado por dispersión y atenuación.
Capacidad: unas pocas docenas de nodos por cable antes de degradar las propiedades eléctricas.
Velocidad: del orden de 4 Mbit/s, alta para los estándares de mediados de los setenta.
Clase DNS heredada: CHAOS, valor numérico 3 en el registro oficial de IANA.

La clase CHAOS de Chaosnet todavía se consulta con herramientas DNS modernas.

El legado vivo: la clase CHAOS en el DNS

Acá está el giro que hace que Chaosnet siga importando en 2026. Cuando se diseñó el sistema de nombres de dominio, sus autores —varios con raíces en el mundo MIT— previeron que el DNS pudiera servir nombres para más de una familia de redes. Por eso cada registro DNS tiene un campo de clase. La clase que todos usamos es IN (Internet). Pero el estándar definió también la clase CH, que significa exactamente CHAOS, en homenaje directo a la red del MIT.

Esa clase nunca se usó masivamente para resolver nombres, pero encontró un nicho inesperado: el servidor BIND, el software DNS más extendido del mundo, expone información de diagnóstico a través de registros TXT bajo la clase CHAOS. El más conocido es version.bind, que devuelve la versión del servidor. Desde la línea de comandos, esto se traduce en un truco clásico de reconocimiento de redes.

En Linux y macOS, con las herramientas de BIND instaladas, la consulta es directa:

# Linux
dig @ns1.ejemplo.com CH TXT version.bind +short

# macOS (dig viene preinstalado)
dig @ns1.ejemplo.com CH TXT version.bind +short

En Windows, donde dig no viene de fábrica, se puede usar nslookup en modo interactivo especificando la clase y el tipo:

# Windows (PowerShell o CMD)
nslookup -class=CHAOS -type=TXT version.bind ns1.ejemplo.com

Si el servidor no oculta esa información, la respuesta es una cadena como "9.18.24" o similar. Otros nombres clásicos bajo la misma clase son hostname.bind y authors.bind. Para quien hace auditoría de infraestructura, esto es valioso porque permite identificar versiones potencialmente vulnerables sin tocar nada más que el resolutor de nombres.

⚠️ Ojo: Exponer version.bind facilita el trabajo de un atacante que busca versiones con vulnerabilidades conocidas. La buena práctica es ocultar o falsear esa cadena. En BIND se hace con la directiva version "oculto"; dentro del bloque options del archivo de configuración.

Impacto y análisis

El caso de Chaosnet ilustra algo que la industria redescubre cada década: las decisiones de diseño nunca mueren del todo. Una red local pensada para un puñado de máquinas Lisp en un edificio del MIT terminó dejando una huella permanente en el protocolo que sostiene toda la web. Nadie planeó que la clase CHAOS sobreviviera a la red CHAOS; simplemente quedó reservada en el estándar y un día alguien le encontró un uso operativo.

También es una lección sobre la virtud de lo simple. Chaosnet ganó velocidad y confiabilidad no por ser sofisticada, sino por negarse a resolver problemas que no tenía. Ese principio sigue siendo tan válido hoy como en 1975: muchos sistemas modernos cargan complejidad para escenarios que jamás van a enfrentar, pagando el costo en latencia, en superficie de ataque y en horas de mantenimiento. La restricción explícita —saber qué problemas ignorar— fue una ventaja competitiva.

Para desarrolladores en LATAM, hay un valor práctico adicional. Entender que el DNS tiene clases más allá de IN abre la puerta a leer y depurar configuraciones de servidores de nombres con más profundidad. Y el truco de version.bind es parte del repertorio básico de cualquiera que administre infraestructura o haga pruebas de seguridad autorizadas sobre sus propios sistemas.

Qué sigue

Chaosnet no va a volver: las máquinas Lisp son piezas de museo y el coaxial de 75 ohmios cedió su lugar hace décadas. Pero su clase seguirá viviendo mientras el DNS exista, porque eliminar una clase reservada de un estándar tan central no aporta nada y rompería herramientas existentes. La recomendación concreta para quien administra servidores es revisar si su BIND expone la versión y, si lo hace, ocultarla. Más allá de eso, vale la pena leer la memoria técnica original: es uno de esos documentos donde se ve cómo se pensaban las redes cuando todo estaba por inventarse.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Por qué se llama Chaosnet?

El nombre hace referencia a la ausencia de cualquier elemento de control centralizado en la red. No hay un nodo maestro ni una autoridad que coordine las transmisiones: todos los nodos compiten por el cable en igualdad de condiciones, y ese diseño descentralizado es lo que inspiró el nombre.

¿Chaosnet todavía se usa para conectar computadoras?

No. Como red física dejó de tener uso práctico hace décadas, junto con las máquinas Lisp para las que fue creada. Lo único que sobrevive es su clase CHAOS dentro del protocolo DNS, que persiste por compatibilidad y por un uso operativo de diagnóstico.

¿Qué es la clase CHAOS en el DNS?

Es una de las clases de registro que define el estándar DNS, con el valor numérico 3, en homenaje a Chaosnet. La clase que todos usamos para resolver dominios es IN (Internet); la clase CH quedó reservada y hoy BIND la usa para exponer registros de diagnóstico como version.bind.

¿Cómo consulto version.bind desde mi terminal?

En Linux y macOS usás dig @servidor CH TXT version.bind +short. En Windows, nslookup -class=CHAOS -type=TXT version.bind servidor. Si el servidor no oculta la información, devuelve la versión de BIND como una cadena de texto.

¿Es peligroso que mi servidor exponga version.bind?

No es una vulnerabilidad en sí misma, pero facilita el reconocimiento: un atacante puede mapear versiones con fallas conocidas sin esfuerzo. La práctica recomendada es ocultar o falsear esa cadena con la directiva version en el bloque options de la configuración de BIND.

¿Qué relación tiene Chaosnet con Ethernet?

Chaosnet se inspiró directamente en el Ethernet experimental de Xerox PARC. Compartían la idea de un cable compartido donde los nodos contienden por transmitir paquetes con detección de portadora, aunque Chaosnet llevó esa idea a una versión más simple y enfocada en redes locales cortas.

Referencias

Chaosnet (memoria técnica original del MIT AI Lab) — documento fuente que describe el hardware, el software y los objetivos de diseño de la red.
Chaosnet — Wikipedia — resumen histórico de la red, su origen en 1975 y su legado en el DNS.
DNS Parameters — IANA — registro oficial que lista la clase CH (CHAOS) con valor 3 entre las clases DNS.
Lisp machine — Wikipedia — contexto sobre las máquinas Lisp del MIT que Chaosnet fue diseñada para conectar.

Atari imprimía el arte de sus arcades con serigrafía, color por color

lu1tr0n — Sun, 14 Jun 2026 14:18:31 +0000

En 1982, una cámara filmó algo que hoy parece magia industrial: paneles de madera entrando bajo una prensa y saliendo con el arte vibrante de una cabina arcade de Atari. No era una calcomanía gigante ni un adhesivo. Era serigrafía, una técnica de impresión que aplicaba el color directamente sobre la madera, una capa a la vez.

Detrás de cada cabina de Missile Command o Centipede había un proceso de producción tan riguroso como una pipeline de software: separación de capas, alineación milimétrica y control de calidad en cada paso.

TL;DR

En 1982 se filmó el proceso de serigrafía de Atari imprimiendo paneles de la cabina Quantum, con una tirada de solo 500 unidades.
El arte no era un adhesivo: se imprimía directamente sobre la madera, un color a la vez.
Cada color requería su propia pantalla y un film positivo en acetato con el arte en negro opaco.
Missile Command tuvo una tirada de 14.000 cabinas, lo que implicó imprimir 28.000 paneles.
El registro (alineación exacta de cada pantalla) era el secreto para evitar colores corridos.
Atari usaba una prensa serigráfica plana semiautomática, no un sistema manual, para escalar.
La serigrafía deposita una capa de tinta gruesa y opaca, por eso el arte sigue vibrante hoy.

Qué es la serigrafía y por qué Atari la usaba

La serigrafía (también llamada impresión por pantalla o silkscreen) es una técnica que existe desde hace más de un siglo y que poco tiene que ver con las impresoras digitales de gran formato que usamos hoy. La idea es sencilla pero poderosa: se hace pasar tinta a través de una malla tensada en la que solo ciertas zonas dejan pasar el color. Esas zonas forman un esténcil, y la tinta que atraviesa la malla queda depositada sobre la superficie de abajo.

En la edad dorada de los arcades, a comienzos de los años 80, Atari decoraba todas sus cabinas con ilustraciones llamativas. Esos dibujos no se imprimían en papel para luego pegarlos: se imprimían directamente sobre los paneles de madera de la cabina. Y aquí está la clave que sorprende a casi todos: se hacía un color a la vez.

💭 Clave: Lo que parece una calcomanía gigante en realidad es tinta aplicada capa por capa sobre la madera. No hay adhesivo: el color forma parte del panel.

Qué se ve en el video de 1982

El metraje que dio origen a esta historia fue filmado en 1982 y muestra la impresión de los paneles laterales de la cabina Quantum, un título con una tirada relativamente baja de apenas 500 unidades. En las imágenes se observa un panel de madera colocado bajo un gran cabezal de impresión.

El proceso es metódico. Una pantalla desciende sobre el panel y un operario extiende la tinta sobre la malla con una espátula de goma (el famoso squeegee). La presión empuja la tinta a través de las zonas abiertas del esténcil y la deposita sobre la madera. Cuando la pantalla se levanta, queda impreso un solo bloque de color. El panel avanza entonces a la siguiente estación, donde otra pantalla agrega el color siguiente. El ciclo se repite varias veces hasta completar la ilustración.

Paneles recién impresos, listos para el ensamblaje.

Separación de color: pensar el arte como capas

Para que la serigrafía funcione, los artistas de Atari tenían que hacer algo que a cualquier desarrollador le resultará familiar: descomponer el problema en capas. El arte completo se separaba en capas de color individuales, y cada color necesitaba su propia pantalla de impresión.

Si un diseño contenía azul claro, azul oscuro, rojo, amarillo y negro, se fabricaban cinco pantallas distintas. Cada una contenía únicamente las áreas correspondientes a ese color. Al imprimir todos los colores en secuencia, una capa sobre otra, se combinaban para formar la ilustración final. Con el tiempo Atari se volvió más astuta: imprimía, por ejemplo, un amarillo sobre un azul para obtener verde, ahorrándose una pantalla.

Ese concepto de separar una imagen en canales de color es exactamente lo que hace cualquier librería de procesamiento de imágenes moderna. Podemos reproducir la idea en pocas líneas con Python y Pillow:

from PIL import Image

# Cargar el arte original de la cabina
arte = Image.open("arte_cabina.png").convert("RGB")

# Separar en canales de color (cada canal = una "pantalla")
rojo, verde, azul = arte.split()

# Guardar cada capa por separado, como un film positivo
for nombre, capa in (("rojo", rojo), ("verde", verde), ("azul", azul)):
    capa.save(f"pantalla_{nombre}.png")

print("Arte separado en 3 capas de color listas para imprimir")

Para ejecutarlo solo necesitás instalar Pillow. La instalación cambia ligeramente según tu sistema operativo:

# Windows (PowerShell)
py -m pip install Pillow

# macOS
python3 -m pip install Pillow

# Linux (Debian/Ubuntu)
sudo apt install python3-pip && pip3 install Pillow

💡 Tip: La separación por canales RGB es solo una analogía. La serigrafía real usa tintas de pigmento (CMYK o colores planos), no luz aditiva, así que el verde de pantalla no equivale al verde de tinta. La idea que importa es la misma: cada color, su propia capa.

El secreto del registro: alineación milimétrica

El reto más difícil de imprimir varios colores por separado no es aplicar la tinta, sino lograr que cada capa quede perfectamente alineada con las anteriores. Los impresores llaman a esto registro. Si una pantalla se desplazaba apenas un milímetro, los contornos se veían borrosos y los colores se superponían mal.

Para evitarlo, las mesas de impresión usaban pasadores de posicionamiento, topes y guías de alineación que garantizaban que cada panel volviera exactamente a la misma posición en cada pasada. Considerando la velocidad de producción, el nivel de precisión que lograban los operarios era notable.

El flujo completo, de principio a fin, se parece bastante a una pipeline de procesamiento por etapas:

graph LR
  A["Arte original"] --> B["Separacion de color"]
  B --> C["Films positivos"]
  C --> D["Pantallas con emulsion"]
  D --> E["Impresion capa por capa"]
  E --> F["Registro y alineacion"]
  F --> G["Panel terminado"]

Antes de llegar a la pantalla, cada color pasaba por un film positivo: una lámina de acetato transparente con el arte en negro opaco, que representaba las zonas que se imprimirían. Ese film se colocaba sobre una pantalla recubierta de emulsión sensible a la luz y se exponía a una luz intensa. La emulsión expuesta se endurecía, mientras que las zonas tapadas por el arte negro quedaban blandas y se lavaban después con agua. El resultado era un esténcil en la malla que dejaba pasar la tinta solo donde hacía falta ese color.

Un film positivo define qué zonas reciben cada color.

Datos y cifras de la producción

La escala explica por qué Atari no podía hacer esto a mano. Missile Command, uno de sus grandes éxitos, tuvo una tirada de 14.000 cabinas. Como cada cabina lleva dos paneles laterales, eso significó imprimir 28.000 paneles. Multiplicá eso por las cinco o más pasadas de color que requería cada panel y entenderás por qué la automatización era indispensable.

Por eso Atari no usaba un sistema completamente manual, sino una prensa serigráfica plana semiautomática. La maquinaria se encargaba de buena parte del movimiento, pero los operarios entrenados seguían siendo esenciales para la puesta a punto, el control del color y la inspección de calidad.

La línea de producción incluía marcos de impresión grandes, films de separación de color, emulsiones fotosensibles, fijaciones de registro, tintas serigráficas, mecanismos de espátula industrial y estaciones de secado o curado entre pasadas. Cada estación tenía una función específica y el panel solo avanzaba cuando la capa anterior estaba lista.

Por qué el arte sigue vibrante 40 años después

Una de las razones por las que el arte original de las cabinas de Atari todavía luce tan intenso es que la serigrafía deposita una capa de tinta relativamente gruesa y opaca. A diferencia de la impresión por inyección moderna, los colores no se construyen a partir de diminutos puntos: cada color se aplica como una capa sólida, lo que le da a la ilustración una riqueza y profundidad difíciles de replicar.

Cuando ves una cabina de Missile Command con azules brillantes, rojos vivos y gráficos nítidos, estás mirando el resultado de múltiples pasadas de impresión cuidadosamente alineadas, cada una sumando otra capa a la imagen final. Esa solidez también explica por qué tantos coleccionistas prefieren restaurar el arte original antes que reemplazarlo con reproducciones digitales.

Qué nos enseña hoy a quienes escribimos software

Mirar este proceso hoy es un recordatorio de que las cabinas arcade no eran simples cajas de madera con un videojuego adentro: eran obras de arte gráfico producidas industrialmente, pensadas para destacar en salones repletos de máquinas de la competencia.

Para quienes desarrollamos software en LATAM hay lecciones que trascienden la madera y la tinta. La serigrafía de Atari es, en esencia, un pipeline: descomponer un problema complejo (el arte) en unidades manejables (las capas de color), procesarlas en etapas bien definidas y garantizar la consistencia entre pasadas (el registro). Cambiá tinta por commits y pantallas por etapas de CI y la analogía casi se escribe sola. La buena ingeniería —de procesos o de código— casi siempre se trata de separar, alinear y repetir con precisión.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿El arte de las cabinas de Atari era un adhesivo?

No. Era tinta aplicada directamente sobre la madera mediante serigrafía, un color a la vez. No había calcomanías ni adhesivos gigantes.

¿Por qué cada color necesitaba su propia pantalla?

Porque cada pantalla funciona como un esténcil que solo deja pasar la tinta en las zonas de un color específico. Cinco colores implicaban, en general, cinco pantallas, aunque Atari aprendió a superponer tintas para crear colores adicionales.

¿Qué es el registro en serigrafía?

Es la alineación exacta de cada pantalla con las capas ya impresas. Sin un buen registro, los contornos quedan borrosos y los colores se superponen mal. Se lograba con pasadores, topes y guías de posicionamiento.

¿Por qué los colores siguen tan vivos décadas después?

Porque la serigrafía deposita una capa de tinta gruesa y opaca, en lugar de construir el color con puntos diminutos como la inyección de tinta. Esa capa sólida da profundidad y resistencia al desgaste.

¿Cuántos paneles imprimió Atari para Missile Command?

Con una tirada de 14.000 cabinas y dos paneles por cabina, Atari imprimió alrededor de 28.000 paneles, cada uno con varias pasadas de color.

Referencias

The Arcade Blogger — artículo original con el video de 1982 del proceso de serigrafía de Atari.
Wikipedia: Serigrafía — fundamentos de la técnica de impresión por pantalla.
Wikipedia: Missile Command — datos sobre el arcade y su producción.
Wikipedia: Atari, Inc. — historia de la compañía durante la edad dorada de los arcades.

Phoenix LiveView 1.2 trae CSS colocado en plantillas HEEx

lu1tr0n — Sun, 14 Jun 2026 08:17:22 +0000

Phoenix LiveView 1.2 llegó el 10 de junio de 2026 con una característica que muchos desarrolladores de Elixir venían esperando: CSS colocado dentro de las plantillas HEEx. Ahora podés escribir los estilos justo al lado del componente que los usa, sin saltar a un archivo aparte.

Pero hay un giro interesante. El equipo construyó toda la infraestructura necesaria para hacer scoping de CSS y, aun así, decidió no activarlo por defecto. En este artículo vemos qué trae Phoenix LiveView 1.2, cómo funciona el CSS colocado por dentro y por qué esa decisión tiene mucho sentido.

TL;DR

Phoenix LiveView 1.2 se publicó el 10 de junio de 2026, anunciado por Steffen Deusch.- Introduce CSS colocado en plantillas HEEx mediante <style :type={Modulo.ColocatedCSS}>.- El CSS se extrae en tiempo de compilación a la carpeta phoenix-colocated dentro de _build.- Usa la regla @scope de CSS y un atributo phx-r para acotar los estilos a un componente.- El scoping NO viene activado por defecto: @scope aún no tiene buen soporte en navegadores en junio de 2026.- La compilación de HEEx se dividió en tokenización y parsing separados para soportar macro-componentes.- Actualizar es tan simple como cambiar {:phoenix_live_view, "~> 1.2.0"} en mix.exs.

Qué trae Phoenix LiveView 1.2

Phoenix LiveView 1.2 es una versión incremental sobre la rama 1.1, pero el cambio principal toca un punto sensible del desarrollo web: dónde viven los estilos. En la versión 1.1, el equipo había introducido los Colocated Hooks y el Colocated JavaScript, que permiten escribir hooks de JavaScript directamente dentro de cualquier plantilla HEEx. La versión 1.2 extiende ese mismo trabajo de base, hecho sobre Phoenix.LiveView.ColocatedJS, para que ahora también puedas colocar CSS dentro de HEEx.

La idea de fondo es simple y poderosa: si un componente define su estructura (HTML), su comportamiento (JS) y su apariencia (CSS) en el mismo lugar, el componente se vuelve autocontenido. No hay que cazar la hoja de estilos correcta en otra carpeta, ni adivinar qué clases globales lo afectan. Para quien viene de React con CSS Modules, styled-components o Vue con <style scoped>, el concepto va a sonar familiar; lo nuevo es cómo Phoenix LiveView 1.2 lo resuelve aprovechando que controla la compilación de HEEx a HTML.
El CSS vive junto al componente que lo usa.

CSS colocado: estilos junto al componente

El uso básico es directo. Dentro de tu plantilla HEEx agregás una etiqueta <style> con un atributo especial :type que apunta a un módulo de CSS colocado. Veamos un ejemplo de un componente de tabla:

def table(assigns) do
  ~H"""

    thead {
      color: var(--brand);
    }
    tbody tr:hover {
      background: #f5f5f5;
    }

  ...
  """
end

Igual que con el JavaScript colocado, el atributo :type le dice a LiveView que extraiga el contenido de la etiqueta en tiempo de compilación. Ese CSS no se queda inline en el HTML: se vuelca a una carpeta especial llamada phoenix-colocated dentro de tu directorio _build. Desde ahí lo recoge tu bundler habitual —normalmente Tailwind o Esbuild— y lo procesa como parte de tu pipeline de CSS de siempre. En otras palabras, no hay magia en tiempo de ejecución ni un sistema de estilos paralelo: todo termina pasando por las mismas herramientas que ya usás.

💭 Clave: el CSS colocado no agrega peso en runtime. Se extrae al compilar y entra a tu bundler estándar, así que el resultado final es el mismo CSS optimizado que ya generabas.

Hasta acá la parte fácil. El problema real aparece cuando querés que esos estilos no se escapen y afecten a otros elementos de la página que vienen de componentes distintos. Eso es el scoping, y es donde Phoenix LiveView 1.2 hace algo elegante.

La regla @scope y el atributo phx-r

El CSS moderno trae una regla relativamente nueva, @scope, que permite limitar el alcance de un conjunto de reglas a una porción concreta del árbol del DOM. Su forma general es así:

@scope (raiz del scope) to (limite del scope) {
  /* reglas que solo aplican dentro de ese rango */
}

La regla acepta un selector raíz y un selector límite opcional. Si pudiéramos anotar el HTML renderizado con un atributo único que identifique la raíz de una plantilla y otro que marque dónde termina, podríamos escribir reglas que apliquen solo a esa plantilla. Y como LiveView controla cómo se compila HEEx a HTML, puede hacer exactamente eso.

Para lograrlo, LiveView marca los elementos más externos de cada plantilla con un atributo especial phx-r, que sirve como selector límite en la regla @scope. Cuando un componente usa CSS colocado con scope, sus elementos raíz reciben además un atributo único del tipo phx-css-*. Hay un detalle fino con los slots: el contenido que pasa el componente que llama (por ejemplo, un <p> dentro de un slot) no pertenece a la plantilla del componente sino a quien lo invoca, así que también se considera una raíz y recibe su propio phx-r. Esto evita que los estilos del componente se filtren hacia el contenido que el usuario inyecta.

Con esas anotaciones, el CSS scoped se ve así:

@scope ([phx-css-foo]) to ([phx-r]) {
  p {
    font-weight: bold;
  }
}

Con esa regla, solo los <p> que pertenecen a la plantilla del componente se renderizan en negrita; cualquier otro <p> de la página queda intacto. LiveView no inyecta el atributo phx-r de forma automática: es opt-in mediante una nueva configuración de compilación.

config :phoenix_live_view,
  # atributo que se pone en todos los tags raiz.
  # Lo usa Phoenix.LiveView.ColocatedCSS.
  root_tag_attribute: "phx-r"

La regla @scope acota los estilos entre la raíz y el límite del componente.

Por qué no activan el scoping por defecto

Acá viene la decisión que sorprende. Después de todo ese esfuerzo para hacer posible el CSS colocado y el scoping, Phoenix LiveView 1.2 no envía el scoping activado por defecto. La razón es honesta y pragmática: la regla @scope todavía no tiene buen soporte en todos los navegadores al momento de escribir esto, en junio de 2026. Activarla por defecto rompería estilos en una parte de los usuarios finales, algo inaceptable para un framework que prioriza la estabilidad.

En lugar de imponer una solución que aún no es universal, el equipo expone un @behaviour que podés implementar para hacer scoping con la estrategia que prefieras. Esto deja la puerta abierta a varias técnicas —desde @scope nativo hasta prefijos de clase generados o atributos de datos— sin atar el framework a una sola. Quien quiera ser early adopter de @scope tiene la implementación documentada y lista para copiar.

⚠️ Ojo: si activás el scoping con @scope hoy, verificá la compatibilidad con los navegadores de tu audiencia. En junio de 2026 el soporte todavía es parcial, sobre todo en versiones antiguas.

Esta filosofía —dar la herramienta sin forzar la opinión— es muy del estilo de Phoenix. El framework prefiere que el desarrollador decida cuándo el soporte de una feature web es suficiente para su caso, en vez de tomar esa decisión por todos.

Cómo cambió la compilación de HEEx

Implementar el CSS colocado obligó al equipo a revisar cómo se compilan las plantillas HEEx. El resumen es que dividieron la compilación en dos pasos separados: una etapa de tokenización y otra de parsing. Esa separación les permitió manejar los macro-componentes —el CSS y el JS colocados— sin volver más complejo el resto del proceso de compilación. Como bonus, pudieron reutilizar código que antes estaba duplicado entre la compilación de plantillas y el formateo.

graph LR
  A["Plantilla HEEx"] --> B["Tokenizacion"]
  B --> C["Parsing"]
  C --> D["Extraccion de macro-componentes"]
  D --> E["Carpeta phoenix-colocated"]
  E --> F["Bundler (Tailwind / Esbuild)"]

Este tipo de refactor interno rara vez es visible para quien usa el framework, pero es la clase de inversión que paga dividendos a largo plazo: una arquitectura de compilación más limpia facilita agregar nuevas features colocadas en el futuro sin acumular deuda técnica. El equipo publicó además un análisis técnico aparte para quien quiera entrar en el detalle de este rediseño.

Contexto e historia

Phoenix es el framework web por excelencia del ecosistema Elixir, y LiveView es su pieza más distintiva: permite construir interfaces interactivas en tiempo real renderizadas en el servidor, con muy poco JavaScript escrito a mano. La comunicación entre el servidor y el navegador va por WebSocket, y LiveView envía solo los diffs mínimos del HTML cuando el estado cambia. Esto le dio a Elixir una ventaja particular para apps reactivas sin el peso de un framework de frontend completo.

La línea de trabajo de la "colocación" —tener HTML, JS y CSS juntos— viene madurando hace varias versiones. Primero fueron los hooks y el JavaScript colocados en la 1.1, y ahora el CSS en la 1.2. Es una respuesta directa a una tensión clásica del desarrollo web: la separación de responsabilidades por tipo de archivo (todo el CSS en un lado, todo el JS en otro) suena ordenada en teoría, pero en la práctica obliga a saltar entre archivos para entender un solo componente. La tendencia de los últimos años, vista en React, Svelte y Vue, fue agrupar por componente en lugar de por tipo de archivo. Phoenix LiveView 1.2 trae esa misma comodidad al mundo de HEEx, pero con una diferencia técnica importante: la extracción ocurre en compilación y se apoya en estándares CSS nativos, no en una capa de runtime propietaria.

Cómo actualizar

Pasar de LiveView 1.1 a 1.2 es trivial. Solo tenés que actualizar el requisito de versión en tu archivo mix.exs y volver a bajar las dependencias:

# En mix.exs
{:phoenix_live_view, "~> 1.2.0"}

Los comandos de Mix son idénticos en los tres sistemas operativos. Una vez editado mix.exs, ejecutá:

# Windows (PowerShell o CMD), macOS y Linux: mismo comando
mix deps.get

# O para forzar la actualización de ese paquete puntual:
mix deps.update phoenix_live_view

💡 Tip: si usás Elixir vía asdf o mise en macOS/Linux, o el instalador oficial en Windows, no necesitás nada extra: mix ya viene con la toolchain. El CSS colocado no requiere cambios en tu bundler más allá de que Tailwind/Esbuild lean la carpeta generada.

Entre las mejoras menores que también trae la 1.2 está la posibilidad de implementar un Phoenix.LiveView.HTMLFormatter.TagFormatter para formatear etiquetas <script> y <style> en HEEx con la herramienta que prefieras —la documentación muestra un ejemplo con prettier—, y que las estructuras Phoenix.LiveView.JS ahora se codifican automáticamente al enviarse.

Impacto para desarrolladores en LATAM

Para los equipos hispanohablantes que ya apostaron por Elixir y Phoenix, esta versión reduce una fricción cotidiana. El CSS colocado significa que un componente compartido —pensá en un design system interno de una startup o una agencia— puede empaquetar su estructura, comportamiento y estilo en un solo módulo, más fácil de versionar, revisar y reutilizar entre proyectos. Eso baja el costo de mantener consistencia visual cuando varios desarrolladores tocan el mismo código.

El consejo práctico para nuestra región es el mismo que para todos: aprovechá el CSS colocado desde ya, porque la extracción en compilación es estable y no depende del navegador. Pero respecto al scoping con @scope, medí primero qué navegadores usa tu base de usuarios. En mercados donde todavía hay dispositivos viejos o navegadores desactualizados, activar @scope hoy puede traer sorpresas; en cambio, una estrategia de scoping basada en clases generadas mediante el @behaviour que provee LiveView te da compatibilidad amplia sin renunciar al aislamiento.

Qué sigue

El camino parece claro: a medida que el soporte de @scope se generalice en los navegadores, es razonable esperar que el scoping nativo pase de opt-in a una recomendación más fuerte, e incluso al comportamiento por defecto en una versión futura. Mientras tanto, la infraestructura ya está lista y el @behaviour permite que cada equipo elija su momento. La separación de la compilación de HEEx en tokenización y parsing, además, deja el terreno preparado para futuras features colocadas sin tener que volver a tocar el núcleo del compilador.

Para seguir el avance, lo mejor es vigilar el repositorio oficial de phoenix_live_view en GitHub y el blog de Phoenix, donde el equipo suele publicar análisis técnicos detallados de cada cambio relevante.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es el CSS colocado en Phoenix LiveView 1.2?

Es la posibilidad de escribir bloques <style :type={Modulo.ColocatedCSS}> directamente dentro de una plantilla HEEx. LiveView extrae ese CSS en tiempo de compilación a la carpeta phoenix-colocated y tu bundler (Tailwind o Esbuild) lo procesa como parte del pipeline normal.

¿El scoping de CSS viene activado por defecto?

No. Aunque Phoenix LiveView 1.2 incluye toda la infraestructura para hacer scoping con la regla @scope y el atributo phx-r, no lo activa por defecto porque @scope aún no tiene buen soporte en todos los navegadores a junio de 2026. Se expone un @behaviour para implementar la estrategia que prefieras.

¿Cómo actualizo de LiveView 1.1 a 1.2?

Cambiá la dependencia a {:phoenix_live_view, "~> 1.2.0"} en mix.exs y ejecutá mix deps.get. El comando es el mismo en Windows, macOS y Linux.

¿Para qué sirve el atributo phx-r?

Es un atributo que LiveView agrega a los elementos raíz de cada plantilla y que sirve como selector límite en la regla @scope. Combinado con un atributo único phx-css-*, permite que los estilos de un componente apliquen solo dentro de ese componente y no se filtren al resto de la página.

¿Necesito cambiar mi bundler para usar CSS colocado?

No hace falta un bundler nuevo. El CSS extraído se deposita en una carpeta dentro de _build que tu Tailwind o Esbuild existente puede leer como parte de su flujo habitual. No hay procesamiento en tiempo de ejecución.

¿Por qué cambiaron la compilación de HEEx?

Para soportar los macro-componentes (CSS y JS colocados) sin complicar el resto del compilador, dividieron la compilación en dos pasos: tokenización y parsing. Esto también permitió reutilizar código que antes estaba duplicado entre la compilación de plantillas y el formateo.

Referencias

Phoenix Blog — Anuncio oficial de Phoenix LiveView 1.2 (10 de junio de 2026).- GitHub: phoenix_live_view — Repositorio oficial con código fuente, changelog e issues.- HexDocs: Phoenix.LiveView — Documentación de la API, incluido el módulo ColocatedCSS.- MDN: @scope — Referencia de la regla CSS @scope y su compatibilidad con navegadores.

La FDA aprueba el bemotrizinol, primer filtro UV nuevo en 20 años

lu1tr0n — Sun, 14 Jun 2026 02:18:56 +0000

La Administración de Alimentos y Medicamentos de Estados Unidos (FDA) aprobó el bemotrizinol, el primer filtro ultravioleta químico nuevo que llega a los protectores solares estadounidenses en casi dos décadas. El ingrediente, presente en productos de Europa y Asia desde hace años, bloquea rayos UVA y UVB por sí solo y resiste la degradación bajo el sol.

Detrás del anuncio hay una historia de regulación, química y más de 18 millones de dólares invertidos a lo largo de veinte años. Acá explicamos qué es, cómo funciona y qué cambia para quienes vivimos bajo el sol intenso de Latinoamérica.

TL;DR

La FDA aprobó el bemotrizinol, el primer filtro UV químico nuevo para protectores solares en EE.UU. en casi 20 años.
Bloquea rayos UVA y UVB por sí solo y es fotoestable: se degrada lento, así que protege más tiempo entre aplicaciones.
Su nombre comercial más conocido es Tinosorb S; se usa en Europa y Asia desde hace décadas.
EE.UU. regula los protectores como medicamentos de venta libre, no como cosméticos: por eso la aprobación tardó tanto.
DSM-Firmenich invirtió al menos US$18 millones durante más de 20 años para lograr la aprobación.
Su molécula es grande, por lo que casi no se absorbe en el torrente sanguíneo, a diferencia de otros filtros químicos.
En gran parte de LATAM, que sigue la regulación cosmética europea, el bemotrizinol ya estaba disponible.

Qué pasó: la FDA aprueba el bemotrizinol

Por primera vez en casi tres décadas, la FDA dio luz verde a un nuevo filtro ultravioleta químico para los protectores solares que se venden en Estados Unidos. La noticia, reportada por NPR el 13 de junio de 2026, fue recibida con entusiasmo poco habitual por parte de la comunidad dermatológica. "Esto es un gran asunto", resumió la doctora Heather Rogers, dermatóloga en Seattle y miembro de la Academia Estadounidense de Dermatología.

El bemotrizinol no es un desconocido: es el mismo compuesto que la industria comercializa bajo el nombre Tinosorb S y que, en la nomenclatura internacional de ingredientes cosméticos (INCI), aparece como bis-ethylhexyloxyphenol methoxyphenyl triazine. Lo nuevo no es la molécula, sino el permiso para usarla en un mercado que llevaba años atascado en una lista cerrada de filtros aprobados.

Para entender por qué un ingrediente común en la góndola de cualquier farmacia europea tardó tanto en cruzar el Atlántico, hay que mirar cómo cada región clasifica al protector solar. Y ahí está la clave de toda la historia del bemotrizinol.

Los filtros UV son la primera barrera contra el daño solar.

Contexto e historia: por qué la FDA tardó 20 años

En Estados Unidos, los protectores solares se regulan como medicamentos de venta libre (OTC, por over-the-counter), no como cosméticos. Esa distinción, que parece burocrática, define todo lo demás. Un medicamento debe pasar por pruebas rigurosas de seguridad y eficacia antes de llegar al mercado. "Es realmente caro y consume mucho tiempo", explicó Kelly Dobos, química cosmética que enseña en la Universidad de Cincinnati.

En Europa, en cambio, los protectores solares se tratan como cosméticos. El umbral regulatorio es más liviano y permite incorporar filtros nuevos con mucha más agilidad. El resultado: durante 20 años, el consumidor europeo y asiático tuvo acceso a filtros de última generación que el estadounidense no podía comprar legalmente.

La empresa europea DSM-Firmenich gastó al menos 18 millones de dólares a lo largo de más de dos décadas empujando el expediente de aprobación del bemotrizinol ante la FDA. Esa cifra ilustra el costo real de la divergencia regulatoria: no es que la ciencia faltara, sino que el camino administrativo era largo y caro.

💭 Clave: La diferencia no estuvo en la molécula, sino en cómo cada región la clasifica. Cosmético en Europa, medicamento en EE.UU.: la misma sustancia, dos velocidades regulatorias completamente distintas.

El siguiente diagrama resume por qué un mismo ingrediente siguió caminos tan distintos según el continente:

graph LR
  A["Nuevo filtro UV"] --> B{"Como se regula?"}
  B -->|"Europa: cosmetico"| C["Aprobacion agil"]
  B -->|"EE.UU.: medicamento OTC"| D["Pruebas de seguridad y eficacia"]
  D --> E["20+ anos y mas de US$18M"]
  E --> F["Aprobacion 2026"]

Cómo funciona el bemotrizinol: UVA, UVB y fotoestabilidad

Para apreciar por qué los dermatólogos celebran, conviene repasar dos conceptos. La radiación solar que nos preocupa se divide en rayos UVB, los de longitud de onda más corta que provocan quemaduras, y rayos UVA, de longitud más larga, responsables del envejecimiento prematuro y las arrugas. Ambos pueden causar cáncer de piel. Un buen protector debe ser de amplio espectro: cubrir los dos.

Históricamente, los protectores estadounidenses eran excelentes frenando UVB, pero flojos contra UVA. El filtro que usaban para los UVA, el avobenzona, tiene un problema: no es fotoestable. Su capacidad de protección empieza a romperse rápido al exponerse al sol. Según datos recopilados en su ficha técnica, la avobenzona puede perder cerca de un 36% de su absorbancia tras una sola hora de sol, y al degradarse libera moléculas que pueden irritar la piel. Por eso suele combinarse con estabilizantes como la octocrilena.

El bemotrizinol resuelve las dos cosas a la vez. Es de amplio espectro por sí solo —tiene dos picos de absorción, alrededor de 310 nm (UVB) y 340 nm (UVA)— y es notablemente fotoestable. Distintos estudios citados en la literatura técnica indican que conserva más del 98% de su estructura incluso tras dosis altas de radiación. "Si pasás un poco más de las dos horas para reaplicar el protector, todavía quedará más protección", señaló Rogers. (Aun así, recomienda reaplicar cada dos horas: la mejora no es excusa para descuidarse.)

Hay un beneficio adicional clave para la confianza del público. La molécula del bemotrizinol es grande, lo que dificulta que la piel la absorba y llegue al torrente sanguíneo. Esto importa porque estudios previos mostraron que algunos filtros químicos vendidos en EE.UU. sí se absorbían en la sangre, lo que disparó pedidos de más datos de seguridad y alimentó una ola de desinformación contra el protector solar en redes sociales.

El bemotrizinol cubre UVA y UVB con un solo filtro fotoestable.

Datos y cifras del bemotrizinol

Resumamos los números que definen esta aprobación. Es el primer filtro UV químico nuevo aprobado por la FDA en cerca de 20 años (y, según algunas cuentas, en casi tres décadas). La empresa DSM-Firmenich invirtió al menos US$18 millones en el proceso, sostenido por más de 20 años de trabajo regulatorio.

En el terreno técnico, el bemotrizinol (fórmula molecular C₃₈H₄₉N₃O₅, masa molar cercana a 628 g/mol) ofrece protección de amplio espectro con dos máximos de absorción en torno a 310 y 340 nanómetros. Según la documentación disponible, retiene alrededor del 98% de su integridad tras decenas de dosis eritémicas mínimas de radiación, una cifra que contrasta de forma dramática con la caída de la avobenzona.

Alexa Friedman, científica sénior del Environmental Working Group (EWG), subraya un punto importante: por haber pasado todo ese proceso de testeo, el bemotrizinol llega con más datos de seguridad que cualquier otro filtro químico actualmente aprobado en EE.UU. Las pruebas en animales no mostraron daños reproductivos, y los ensayos clínicos en humanos indicaron que no irrita la piel incluso tras aplicaciones repetidas en el tiempo.

📌 Nota: Hasta ahora, el único ingrediente disponible en EE.UU. que combinaba fotoestabilidad, baja absorción y buena cobertura UVA/UVB era el óxido de zinc, un filtro mineral. El bemotrizinol ofrece ese paquete pero como filtro químico, con mejor cosmética.

Impacto y análisis: qué cambia, y qué significa para LATAM

El cuarto gran atractivo del bemotrizinol es estético, y no es un detalle menor. Los filtros minerales como el óxido de zinc y el dióxido de titanio se asientan sobre la superficie de la piel y suelen dejar ese residuo blanquecino tan conocido, poco favorecedor en pieles más oscuras. Los filtros químicos, en cambio, se integran mejor y resultan más cosméticos. Un protector que la gente quiera usar termina protegiendo más que uno técnicamente perfecto que queda olvidado en el cajón.

Y ahí está el argumento de salud pública que repiten los dermatólogos. "Solo necesitamos tener un protector solar que la gente use, en el que confíe", dijo Rogers. "Y este ingrediente va a permitir que eso suceda". El cáncer de piel es el tipo de cáncer más común, así que la adherencia —que la gente efectivamente se ponga el producto— pesa tanto como la fórmula.

¿Y qué pasa con Latinoamérica? Acá hay una ironía interesante. Buena parte de los países de la región siguen, de forma total o parcial, el marco regulatorio europeo que trata al protector solar como cosmético. Eso significa que en muchos mercados de LATAM el bemotrizinol (Tinosorb S) y otros filtros modernos como el Tinosorb M ya estaban disponibles desde hace años, mientras el consumidor estadounidense esperaba. La noticia de la FDA, vista desde la región, es menos un estreno y más una confirmación: el mercado más exigente del mundo en regulación de medicamentos validó un ingrediente que muchos latinoamericanos ya usaban.

Para quienes trabajan en tecnología, ciencia de datos o salud digital, el caso del bemotrizinol es además un recordatorio de cómo los marcos regulatorios moldean la innovación tanto como la ciencia misma. La molécula existía, los datos existían; lo que faltaba era recorrer un proceso de aprobación diseñado para fármacos. Es el mismo tipo de fricción regulatoria que vemos en dispositivos médicos, software clínico y herramientas de diagnóstico asistido por IA: la barrera no siempre es técnica.

💡 Tip: Al elegir un protector solar, fijate en la etiqueta si dice "amplio espectro" (UVA + UVB) y revisá los ingredientes activos. Si vivís en LATAM, es probable que ya encuentres bemotrizinol o Tinosorb S sin necesidad de importarlo.

Qué sigue

La aprobación abre la puerta a que los fabricantes estadounidenses reformulen sus protectores con bemotrizinol, aunque eso no ocurre de un día para el otro: hay que rediseñar fórmulas, hacer pruebas de estabilidad y pasar controles antes de que los nuevos productos lleguen a las estanterías. En los próximos meses y años se espera una nueva generación de protectores estadounidenses con mejor cobertura UVA y mejor cosmética.

El otro frente es la confianza pública. La desinformación contra los protectores solares —impulsada en parte por estudios sobre absorción de filtros químicos y amplificada en redes— sigue siendo un problema. Que el bemotrizinol llegue respaldado por dos décadas de datos y con baja absorción cutánea les da a dermatólogos y divulgadores un argumento sólido para recuperar esa confianza. Para los expertos, el mensaje es simple: el mejor protector solar es el que efectivamente te aplicás.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es el bemotrizinol?

Es un filtro ultravioleta químico de amplio espectro que protege contra rayos UVA y UVB. Se comercializa principalmente como Tinosorb S y su nombre INCI es bis-ethylhexyloxyphenol methoxyphenyl triazine. La FDA lo aprobó para protectores solares en EE.UU. en junio de 2026.

¿Por qué la FDA tardó casi 20 años en aprobarlo?

Porque en Estados Unidos los protectores solares se regulan como medicamentos de venta libre, no como cosméticos. Eso exige pruebas rigurosas y costosas de seguridad y eficacia. DSM-Firmenich invirtió al menos US$18 millones a lo largo de más de 20 años para completar el expediente.

¿Es seguro el bemotrizinol?

Según el EWG, llega con más datos de seguridad que cualquier otro filtro químico aprobado en EE.UU. Las pruebas no mostraron daños reproductivos en animales ni irritación cutánea en humanos, y su molécula grande casi no se absorbe en el torrente sanguíneo.

¿En qué se diferencia de la avobenzona?

La avobenzona, el filtro UVA tradicional en EE.UU., no es fotoestable: pierde cerca del 36% de su absorbancia tras una hora de sol y necesita estabilizantes. El bemotrizinol cubre UVA y UVB por sí solo y conserva más del 98% de su estructura tras radiación intensa.

¿Ya está disponible el bemotrizinol en Latinoamérica?

En buena parte de LATAM, donde la regulación sigue el modelo cosmético europeo, el bemotrizinol (Tinosorb S) ya estaba disponible desde hace años en protectores importados o formulados localmente. La aprobación de la FDA principalmente abre el mercado estadounidense.

¿Tengo que reaplicar el protector con menos frecuencia?

No. Aunque el bemotrizinol se degrada más lento y deja más protección residual, los dermatólogos siguen recomendando reaplicar cada dos horas, sobre todo después de nadar o sudar.

Referencias

NPR — Cobertura original de la aprobación del bemotrizinol por la FDA, con declaraciones de dermatólogos y expertos.
Wikipedia: Bemotrizinol — Ficha técnica del compuesto: espectro de absorción, fotoestabilidad, nombre IUPAC y fórmula molecular.
Wikipedia: Avobenzone — Datos sobre la avobenzona, su protección UVA y su degradación bajo luz solar.

La ROM del WorkBoy, la PDA del Game Boy de 1992, apareció en el Gigaleak

lu1tr0n — Sat, 13 Jun 2026 20:18:32 +0000

En 1992, una pequeña empresa llamada Montague-Weston diseñó un accesorio que prometía convertir el Game Boy en una computadora de bolsillo: el WorkBoy. Traía un teclado físico, agenda de contactos, calculadora, conversor de monedas y temperaturas, y traducción de palabras entre cinco idiomas. Nintendo lo licenció, las revistas de la época lo anunciaron... y nunca llegó a las tiendas.

Durante 28 años se dio por perdido, tanto el cartucho como el teclado. Hasta que en 2020 una filtración masiva de Nintendo destapó su ROM y un historiador logró hacerlo funcionar de verdad. Esta es la historia del WorkBoy y de cómo se preserva el software que estuvo a punto de desaparecer.

TL;DR

El WorkBoy (1992) era un teclado físico que convertía el Game Boy en una PDA: agenda, contactos, calculadora y conversor de monedas.
Lo diseñó Montague-Weston, lo licenció Nintendo y lo iba a distribuir Fabtek, pero nunca llegó a las tiendas pese a anuncios en revistas.
Su ROM apareció en el lote de Game Boy filtrado en septiembre de 2020, parte del llamado Nintendo Gigaleak.
En diciembre de 2020, Liam Robertson (DidYouKnowGaming?) mostró un prototipo del teclado funcionando con la ROM filtrada.
La pantalla muestra la versión 8.87, pero las cadenas internas dicen 5.74: el código sobrescribe el número en RAM al arrancar.
La ROM guarda la pantalla de título en cinco idiomas (inglés, español, italiano, alemán y francés) en offsets fijos.
El caso es un ejemplo claro de preservación de software y de ingeniería inversa sobre hardware retro.

Qué fue el WorkBoy

El WorkBoy no era un juego. Era un periférico que se conectaba al puerto del cartucho del Game Boy y le añadía un teclado completo, transformando la consola portátil más popular de su época en una agenda electrónica. La idea era ambiciosa para 1992: con la pantalla monocromática del Game Boy y un teclado de membrana, podías guardar citas, direcciones, números de teléfono, llevar el balance de tu cuenta bancaria y hasta convertir temperaturas y divisas. En un mundo previo a las Palm y mucho antes del primer smartphone, era una propuesta adelantada.

El reparto detrás del proyecto explica buena parte de la historia. El diseño y el software venían de Montague-Weston; la licencia, de Nintendo; y la distribución estaba a cargo de Fabtek, Inc., la misma compañía que más tarde se haría conocida por publicar el arcade Raiden en Norteamérica. Esa cadena de actores aparece, literalmente, en la pantalla de título del propio software, como veremos más abajo cuando leamos la ROM byte por byte.

El Game Boy de 1992, la base sobre la que el WorkBoy quería construir una PDA.

El problema es que, pese a los anuncios pagados en revistas de videojuegos de la época, el WorkBoy nunca se lanzó comercialmente. No hubo unidades a la venta, no hubo cartuchos en estanterías, y con los años quedó como una de esas leyendas del hardware perdido: un accesorio del que existían fotos publicitarias pero ninguna prueba de que funcionara realmente. Para coleccionistas e historiadores, era una pieza fantasma.

Contexto e historia: del olvido a la filtración

El giro llega en 2020. Ese año, Nintendo sufrió una de las filtraciones de datos más grandes de su historia, conocida popularmente como el Gigaleak. Se trató de una serie de volcados de información interna de la compañía publicados de forma anónima en imageboards. El nombre "Gigaleak" se asoció sobre todo a la segunda tanda, de julio de 2020, de unos tres gigabytes, pero hubo varias oleadas a lo largo del año.

La que nos interesa es la de septiembre de 2020. En la segunda semana de ese mes apareció un conjunto enorme de material que incluía documentación interna de Wii Sports, el código fuente del bootrom de la Nintendo DSi y, crucialmente, un lote de ROMs de Game Boy y Game Boy Color con juegos publicados y sin publicar. Entre esos volcados estaba el cartucho del WorkBoy. Después de casi tres décadas, el software perdido reaparecía, no en un mercado de pulgas, sino en un archivo filtrado en internet.

📌 Nota: El WorkBoy figura en la categoría de "Nintendo Leaks" de The Cutting Room Floor (TCRF), el wiki dedicado a documentar contenido oculto y sin usar dentro de videojuegos.

El segundo acto lo puso el historiador Liam Robertson. En diciembre de 2020, el canal de YouTube DidYouKnowGaming? publicó un video en el que Robertson aparecía usando un prototipo del teclado del WorkBoy junto con la ROM filtrada, sobre un Game Boy real. Robertson había rastreado durante años el hardware hasta dar con Frank Ballouz, fundador de Fabtek, dueño de uno de los pocos prototipos conocidos. Lo que le faltaba era el software: el teclado no servía de nada sin el cartucho. La ROM del Gigaleak fue exactamente la pieza que faltaba. Grabada en un cartucho regrabable, hizo que el prototipo funcionara tal como se diseñó en 1992.

Datos y cifras del WorkBoy

Más allá de la anécdota, lo interesante para quien programa es que hoy podemos abrir la ROM y examinarla. The Cutting Room Floor documentó varios detalles técnicos verificables que vale la pena desglosar, porque muestran cómo se construía software comercial para hardware de 8 bits.

Año y créditos — La pantalla de título declara (c) 1992 Montague-Weston, con licencia exclusiva a Fabtek, Inc. y "Licensed by Nintendo".
Cinco idiomas — El cartucho incluye la pantalla de título localizada en inglés, español, italiano, alemán y francés, cada una almacenada en un offset distinto de la ROM.
Dos números de versión — La pantalla muestra Version 5.74 en su forma final renderizada, pero las cadenas crudas en la ROM dicen una cosa y el arranque las modifica. Ese detalle es la joya técnica del caso.

Los offsets concretos de cada localización están documentados. Si tuvieras el archivo workboy.gb, podrías extraer cada cadena con unas pocas líneas de Python, sin emulador ni herramientas especiales:

OFFSETS = {
    "ingles":   (0x08072, 0x080D6),
    "espanol":  (0x08E9A, 0x08F09),
    "italiano": (0x10075, 0x100E2),
    "aleman":   (0x14078, 0x140E1),
    "frances":  (0x1C077, 0x1C0DC),
}

with open("workboy.gb", "rb") as f:
    rom = f.read()

for idioma, (inicio, fin) in OFFSETS.items():
    texto = rom[inicio:fin].decode("ascii", errors="replace")
    print(f"== {idioma} ==")
    print(texto)

Una ROM no es magia: es un arreglo de bytes con un mapa de memoria conocido. Cada idioma vive en una región fija y el programa salta al offset correcto según la configuración. Esta es exactamente la clase de estructura que hace posible la preservación: si conocés el offset, conocés el dato.

Una ROM es un arreglo de bytes con un mapa de memoria conocido.

El truco de la versión: 5.74 que se vuelve 8.87

Aquí está el detalle que más disfrutan los aficionados a la ingeniería inversa. La descubridora WaluigiBSOD documentó que la pantalla de título del WorkBoy muestra el número de versión 8.87, pero las cadenas almacenadas en el código indican 5.74. ¿Por qué dos números distintos para lo mismo?

La respuesta es un parche en tiempo de ejecución. Antes de dibujar la pantalla de título, el programa copia la cadena correspondiente a la RAM y, una vez ahí, reemplaza el texto "5.74" por "8.87", leyendo esos cuatro caracteres desde la ROM en los offsets 0x00FEA-0x00FED. Es decir: el número "real" que ve el usuario no está pegado a la cadena de cada idioma, sino guardado una sola vez y estampado sobre la plantilla en el momento de pintar.

# La ROM guarda "5.74" en las cadenas, pero muestra "8.87".
# Antes de pintar la pantalla, copia la cadena a RAM y sobrescribe
# "5.74" con "8.87", leido de la ROM en 0x00FEA-0x00FED.
version_mostrada = rom[0x00FEA:0x00FEE].decode("ascii")
print("Version real en pantalla:", version_mostrada)  # 8.87

¿Por qué hacerlo así? Es un patrón clásico de la programación de la época, cuando cada byte contaba. En lugar de repetir el número de versión cinco veces (una por idioma) y tener que editar cinco lugares en cada compilación, guardás la versión una sola vez y la inyectás en una plantilla compartida. Reduce duplicación y errores. Hoy lo resolveríamos con una variable o una interpolación de cadena; en 1992, con un Game Boy de 8 KB de RAM, lo resolvías sobrescribiendo bytes en memoria.

flowchart LR
  A["ROM: cadena con 5.74"] --> B["Copia a RAM"]
  B --> C["Lee 8.87 de 0x00FEA"]
  C --> D["Sobrescribe 5.74 por 8.87"]
  D --> E["Pinta la pantalla de titulo"]

💭 Clave: El número de versión que ve el usuario no estaba en las cadenas: se estampaba en RAM al arrancar. Una micro-optimización de memoria que hoy delata cómo se construyó el software.

Cómo se preserva una ROM perdida

El caso del WorkBoy ilustra por qué la preservación de software importa, y por qué la comunidad técnica le dedica tanto esfuerzo. Sin esa ROM filtrada, el prototipo de teclado de Robertson sería un pisapapeles: hardware sin software no hace nada. La filtración, por dudosa que sea su procedencia, terminó siendo el único registro funcional de un producto que de otra forma estaría perdido para siempre.

Para quien quiera meterse en este mundo desde LATAM, el ecosistema de herramientas de Game Boy es sorprendentemente accesible y gratuito. Una de las más usadas es RGBDS (Rednex Game Boy Development System), el toolkit que ensambla y desensambla código de Game Boy. Instalarlo es directo en los tres sistemas operativos:

# Windows (Scoop)
scoop install rgbds

# macOS (Homebrew)
brew install rgbds

# Linux (Debian/Ubuntu)
sudo apt install rgbds

Con un toolkit así más un emulador como mGBA, podés cargar una ROM, inspeccionar su mapa de memoria, seguir el flujo de ejecución y reconstruir cómo se comporta el programa. Es exactamente el tipo de trabajo que permitió documentar el parche de versión del WorkBoy: alguien abrió la ROM, encontró la cadena "5.74", notó que la pantalla decía "8.87" y siguió el rastro hasta el código que hacía la sustitución.

💡 Tip: Si querés practicar ingeniería inversa sin riesgos legales, empezá con ROMs homebrew de dominio público o con tus propios cartuchos volcados. El Game Boy es la plataforma ideal para aprender: arquitectura simple, documentación abundante y herramientas libres.

Impacto y análisis

Más allá de la nostalgia, el WorkBoy deja varias lecciones para desarrolladores. La primera es histórica: las PDA y los asistentes personales no nacieron con Palm ni con el iPhone. Hubo intentos tempranos, muchos fallidos, de meter productividad en dispositivos de consumo. El WorkBoy fue uno de ellos, y su fracaso comercial no le quita valor como antecedente conceptual.

La segunda lección es técnica. Leer una ROma de 8 bits hoy es trivial con Python, pero entender por qué está escrita así requiere ponerse en el lugar de quien programaba con restricciones brutales de memoria y procesamiento. El truco del número de versión no es un bug ni una rareza: es una decisión de diseño razonable bajo esas limitaciones. Estudiar código antiguo es estudiar restricciones, y eso entrena el criterio de cualquier ingeniero moderno.

La tercera es ética y práctica a la vez: la preservación digital depende, demasiadas veces, de filtraciones y de fans. No existe un archivo oficial y abierto de buena parte del software comercial de los 80 y 90. Cuando una empresa decide no relanzar ni archivar un producto, el conocimiento queda en manos de coleccionistas, dumpers y comunidades como TCRF. El WorkBoy sobrevivió de milagro; muchísimos títulos y accesorios no tuvieron esa suerte.

Qué sigue

El WorkBoy ya está documentado, su ROM circula entre quienes estudian hardware retro y su funcionamiento quedó registrado en video. Lo que sigue es lo de siempre en este campo: que más gente abra esos archivos, los analice y publique sus hallazgos. Cada offset documentado, cada cadena traducida y cada rutina explicada hace que la próxima persona que se acerque al tema tenga un punto de partida.

Para la comunidad de desarrollo en español, casos como este son una invitación. La barrera de entrada a la ingeniería inversa de consolas retro es baja, las herramientas son libres y multiplataforma, y el material para practicar abunda. El WorkBoy es, en ese sentido, un recordatorio de que la tecnología "vieja" sigue teniendo mucho que enseñar.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué era exactamente el WorkBoy?

Un accesorio de 1992 que conectaba un teclado físico al Game Boy y lo convertía en una PDA: permitía guardar citas, contactos, números de teléfono y balance bancario, además de convertir temperaturas, monedas y traducir palabras entre cinco idiomas.

¿Por qué nunca se lanzó?

Pese a tener licencia de Nintendo, distribución prevista por Fabtek y anuncios en revistas de la época, el WorkBoy nunca llegó al mercado. No hubo unidades a la venta y tanto el cartucho como el teclado se consideraron perdidos durante casi tres décadas.

¿Cómo reapareció su software?

La ROM del WorkBoy apareció en el lote de Game Boy filtrado en septiembre de 2020, parte de la gran filtración de datos de Nintendo conocida como Gigaleak. En diciembre de 2020, Liam Robertson la usó para hacer funcionar un prototipo del teclado.

¿Por qué la versión es 5.74 y 8.87 al mismo tiempo?

Las cadenas internas de la ROM dicen "5.74", pero al arrancar el programa copia la cadena a RAM y sobrescribe ese texto con "8.87", leído desde la ROM en los offsets 0x00FEA-0x00FED. El usuario ve 8.87; el dato base es 5.74.

¿Es legal estudiar la ROM del WorkBoy?

El análisis y la documentación de software para fines de investigación y preservación son prácticas comunes, pero la ROM proviene de una filtración no autorizada. Para aprender ingeniería inversa sin riesgos, conviene usar ROMs homebrew de dominio público o volcados de cartuchos propios.

¿Con qué herramientas puedo analizar ROMs de Game Boy?

RGBDS para ensamblar y desensamblar, emuladores como mGBA con depurador integrado, y editores hexadecimales para inspeccionar bytes. Todas son gratuitas y funcionan en Windows, macOS y Linux.

Referencias

The Cutting Room Floor — Workboy — documentación técnica: offsets de idiomas y el truco de la versión 5.74/8.87.
Wikipedia — Nintendo data leak — cronología del Gigaleak y de las filtraciones de septiembre de 2020.
Inverse — Meet the WorkBoy — contexto sobre el accesorio y su recuperación por Liam Robertson.
Siliconera — WorkBoy prototype demonstrated — cobertura del prototipo funcionando con la ROM filtrada.

TensorZero movía el 1% del gasto global en LLMs y archivó su repositorio

lu1tr0n — Sat, 13 Jun 2026 14:17:35 +0000

El 12 de junio de 2026, sin comunicado ni explicación visible, el repositorio de TensorZero en GitHub amaneció con un aviso seco: "This repository was archived by the owner. It is now read-only." Hablamos de una de las plataformas LLMOps de código abierto más populares del momento: 11.500 estrellas, 850 forks y, según su propia documentación, infraestructura que canalizaba cerca del 1% del gasto mundial en APIs de modelos de lenguaje.

Que un proyecto de este tamaño pase a solo lectura de un día para otro es noticia. Acá explicamos qué es TensorZero, por qué importaba para quienes construyen aplicaciones con LLMs y qué significa, en la práctica, que su repositorio quede congelado.

TL;DR

GitHub archivó el repositorio de TensorZero el 12 de junio de 2026: quedó en modo solo lectura, sin nuevos commits ni issues.
Era una plataforma LLMOps de código abierto que unificaba gateway, observabilidad, evaluación, optimización y experimentación.
Acumulaba 11.500 estrellas, 850 forks y 4.100 commits en su rama principal.
Su gateway estaba escrito en Rust y prometía menos de 1 ms de latencia p99 a más de 10.000 consultas por segundo.
Según su documentación, canalizaba cerca del 1% del gasto mundial en APIs de LLM, con clientes desde startups hasta empresas Fortune 10.
La compañía levantó una ronda seed de 7,3 millones de dólares y tenía unos 18 meses de vida.
GitHub no publicó motivo del archivado; el código sigue clonable bajo su licencia, pero el desarrollo abierto se detuvo.

Qué pasó

El cambio es técnico y, a la vez, contundente. Cuando una persona u organización archiva un repositorio en GitHub, este pasa a modo read-only: nadie puede abrir issues, enviar pull requests, hacer push de nuevos commits ni modificar la configuración. El historial completo permanece visible y el código sigue siendo clonable, pero el proyecto deja de recibir mantenimiento activo desde su origen. En el caso de TensorZero, el aviso apareció fechado el 12 de junio de 2026 y, hasta el momento de escribir esta nota, sin una declaración pública que explique el porqué.

La página del repositorio conserva todas las cifras que lo convirtieron en un caso de estudio: 11.500 estrellas, 850 forks y 4.100 commits. Para dimensionar el crecimiento, meses atrás había llegado a ser el repositorio número uno en tendencia de la semana a nivel global, saltando de alrededor de 3.000 a más de 9.700 estrellas en poco tiempo. Pasar de ese ritmo a un estado congelado es, justamente, lo que hace que el archivado llame la atención.

Conviene ser claro y objetivo: archivar no es lo mismo que borrar. El código de TensorZero no desapareció. Quien lo tenía en producción puede seguir clonándolo, ejecutándolo y hasta crear un fork para continuar el desarrollo por su cuenta, siempre dentro de los términos de su licencia. Lo que cambia es la garantía de futuro: ya no habrá parches de seguridad, correcciones de bugs ni nuevas funciones provenientes del equipo original a través de ese repositorio.

El aviso de archivado deja el proyecto en modo solo lectura.

Qué es TensorZero y por qué importaba

TensorZero se presentaba como una plataforma LLMOps de código abierto. El término LLMOps es la versión para modelos de lenguaje de lo que MLOps fue para el machine learning clásico: el conjunto de herramientas y prácticas para llevar un modelo de un experimento en un cuaderno a un servicio confiable en producción. Donde MLOps se preocupaba por entrenar y desplegar modelos propios, LLMOps se enfoca en orquestar llamadas a modelos de terceros (OpenAI, Anthropic, Google) o autoalojados, medir su calidad y costo, y mejorarlos de forma sistemática.

La propuesta de TensorZero era unificar cinco piezas que normalmente se resuelven con productos separados:

Gateway — un único punto de entrada para acceder a cualquier proveedor de LLM a través de una API unificada, con enrutamiento, reintentos, fallbacks y balanceo de carga.
Observabilidad — almacenar cada inferencia y su feedback (métricas, ediciones humanas) en tu propia base de datos, consultable desde una interfaz o de forma programática.
Evaluación — comparar inferencias individuales o flujos completos usando heurísticas y jueces basados en LLM.
Optimización — recolectar métricas y retroalimentación humana para mejorar prompts, modelos y estrategias de inferencia.
Experimentación — pruebas A/B, enrutamiento y fallbacks integrados para desplegar cambios con confianza.

El argumento de venta que repetía la documentación de TensorZero era la adopción incremental: podías tomar solo el gateway y dejar el resto, o sumar la observabilidad más adelante. Esa modularidad, junto con su compatibilidad con el SDK de OpenAI, OpenTelemetry y prácticamente todos los proveedores grandes, explicaba buena parte de su tracción entre equipos hispanos y de todo el mundo que querían evitar el lock-in con un único proveedor de modelos.

💭 Clave: LLMOps no busca entrenar el modelo perfecto, sino convertir llamadas impredecibles a un LLM en un servicio medible, barato y reproducible. Ese es el problema que TensorZero atacaba.

Contexto e historia

TensorZero era una empresa joven: rondaba los 18 meses de vida y había levantado una ronda seed de 7,3 millones de dólares para construir, en sus palabras, un stack de código abierto para aplicaciones de LLM de "grado industrial". Ese respaldo financiero y su crecimiento explosivo en GitHub la pusieron en el radar de medios tecnológicos y de la comunidad de desarrolladores.

La pieza que más distinguía al proyecto era una decisión de ingeniería poco común en el ecosistema de IA, dominado por Python: el gateway estaba escrito en Rust. La razón es de rendimiento. Un gateway se sienta en el camino crítico de cada llamada a un modelo, así que cualquier sobrecarga que agregue se paga en todas y cada una de las inferencias. TensorZero presumía menos de 1 ms de latencia p99 incluso a más de 10.000 consultas por segundo, un nivel que es difícil de sostener con runtimes de lenguajes de mayor abstracción y recolección de basura.

El otro pilar era la compatibilidad. En lugar de imponer un SDK propio, TensorZero hablaba el protocolo de la API de OpenAI. En la práctica, eso significaba que un equipo podía colocarlo delante de su aplicación cambiando una sola línea —la base_url— y empezar a enrutar hacia Anthropic, AWS Bedrock, Azure, Google Vertex AI, Mistral, Together, Groq, DeepSeek o cualquier endpoint compatible con OpenAI, como Ollama.

Datos y cifras

Más allá del archivado, vale la pena fijar los números que definían a TensorZero, porque ayudan a entender por qué su congelamiento genera conversación:

11.500 estrellas y 850 forks en GitHub al momento del archivado.
4.100 commits en la rama principal, señal de un desarrollo intenso y sostenido.
<1 ms de latencia p99 de sobrecarga del gateway a 10.000+ QPS, según sus benchmarks.
~1% del gasto global en APIs de LLM canalizado a través de la plataforma, de acuerdo con su documentación.
Clientes que iban desde startups de IA de frontera hasta empresas Fortune 10.
7,3 millones de dólares de financiación seed para una empresa de ~18 meses.

Ese 1% del gasto mundial es la cifra más llamativa: aunque sea una estimación de la propia compañía y no un dato auditado por un tercero, sugiere que TensorZero no era un experimento de fin de semana, sino infraestructura que tocaba un volumen real de tráfico productivo.

Un gateway unifica el acceso a varios proveedores de LLM.

Cómo se usaba TensorZero

Para entender qué pierden quienes lo adoptaron, conviene ver lo simple que era empezar. El despliegue base era un único contenedor de Docker. Estos son los comandos para levantarlo en las tres plataformas más comunes:

# Linux / macOS (terminal)
docker run -p 3000:3000 \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  tensorzero/gateway

# Windows (PowerShell)
docker run -p 3000:3000 `
  -e OPENAI_API_KEY=$env:OPENAI_API_KEY `
  tensorzero/gateway

Con el gateway corriendo, el cambio en el código de la aplicación era mínimo. Cualquier cliente del SDK de OpenAI —Python, Node, Go— funcionaba apuntando la base_url al gateway local:

from openai import OpenAI

# Apuntar el cliente al gateway de TensorZero
client = OpenAI(
    base_url="http://localhost:3000/openai/v1",
    api_key="not-used",
)

respuesta = client.chat.completions.create(
    # Llamar a cualquier proveedor a través del gateway
    model="tensorzero::model_name::anthropic::claude-sonnet-4-6",
    messages=[
        {
            "role": "user",
            "content": "Comparte un dato curioso sobre TensorZero.",
        }
    ],
)

print(respuesta.choices[0].message.content)

Ese mismo gateway registraba la inferencia, su costo y su latencia, y permitía después reproducir llamadas históricas con un prompt o un modelo distinto para comparar resultados. El diagrama siguiente resume la arquitectura conceptual:

graph LR
  App["Tu aplicacion (SDK OpenAI)"] --> GW["TensorZero Gateway (Rust)"]
  GW --> P1["OpenAI"]
  GW --> P2["Anthropic"]
  GW --> P3["Bedrock / Vertex AI"]
  GW --> DB["Base de datos: inferencias y feedback"]
  DB --> UI["TensorZero UI"]

💡 Tip: Si dependés de un proyecto de código abierto en producción, fijá (pin) una versión exacta y guardá una copia del repositorio. Un archivado no rompe lo que ya tenés desplegado, pero sí corta el flujo de actualizaciones futuras.

Impacto y análisis

El archivado de TensorZero deja varias lecturas para quienes construyen con LLMs en LATAM y en el resto del mundo hispano. La primera es práctica: si tu stack dependía de este gateway, hoy seguís funcionando, pero estás efectivamente sobre un artefacto congelado. Eso obliga a una decisión: mantener un fork propio, migrar a una alternativa o aceptar el riesgo de quedarte sin parches de seguridad.

La segunda lectura es sobre el riesgo de cadena de suministro en infraestructura de IA. La explosión de herramientas LLMOps en 2025 y 2026 hizo que muchos equipos adoptaran proyectos jóvenes, con un solo respaldo corporativo, en posiciones críticas de su arquitectura. Cuando ese respaldo cambia de rumbo —por una adquisición, un giro de producto o el cierre de una línea—, el proyecto puede congelarse de un día para otro. No es exclusivo de TensorZero; es un patrón estructural del ecosistema.

La tercera es más matizada y favorable al código abierto: precisamente porque TensorZero era open source, su archivado no es un apagón. El historial de 4.100 commits, las crates de Rust, la interfaz y la documentación siguen disponibles. La comunidad tiene, al menos en teoría, todo lo necesario para tomar la posta con un fork si la demanda lo justifica. Es la diferencia exacta entre depender de un SaaS cerrado que se apaga y depender de un proyecto abierto que se congela.

⚠️ Ojo: Un repositorio archivado deja de recibir parches de seguridad. Si lo tenés expuesto en un gateway de producción, esa es la dimensión a vigilar primero, no las nuevas funciones.

Qué sigue

Por ahora, la pregunta del millón —el porqué del archivado— no tiene respuesta pública. Las hipótesis razonables van desde una adquisición que mueva el desarrollo a un repositorio privado, hasta un cambio de licencia o de modelo de negocio que separe el núcleo abierto de una oferta comercial. Es importante remarcar que, hasta el momento de esta publicación, ninguna de esas hipótesis está confirmada: lo único verificable es el estado de solo lectura con fecha del 12 de junio de 2026.

Para los equipos hispanos que evalúan su stack de LLMOps, el episodio es un buen recordatorio para auditar dependencias: identificar qué piezas son críticas, cuáles tienen un único mantenedor y qué plan de contingencia existe si una de ellas se congela. TensorZero seguirá funcionando para quien ya lo tiene, pero su historia abierta, por ahora, cierra capítulo.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿TensorZero dejó de funcionar?

No. Archivar un repositorio en GitHub no borra el código ni apaga los servicios desplegados. TensorZero sigue siendo clonable y ejecutable; lo que se detuvo es el desarrollo activo, los nuevos commits, las issues y los pull requests a través de ese repositorio.

¿Qué significa que un repositorio esté archivado?

Significa que pasa a modo de solo lectura. El historial y el código permanecen visibles, pero nadie puede modificar el repositorio: ni el equipo original ni la comunidad. Para seguir el desarrollo habría que crear un fork bajo los términos de la licencia del proyecto.

¿Por qué TensorZero archivó su repositorio?

No hay una explicación pública oficial al momento de escribir esta nota. El único dato verificable es la fecha del archivado, el 12 de junio de 2026. Cualquier motivo concreto —adquisición, cambio de licencia o de estrategia— sería especulación hasta que haya una declaración formal.

¿Qué es una plataforma LLMOps como TensorZero?

Es el conjunto de herramientas para llevar aplicaciones basadas en modelos de lenguaje a producción: un gateway que unifica el acceso a varios proveedores, observabilidad para medir costos y calidad, evaluación, optimización de prompts y modelos, y experimentación con pruebas A/B.

¿Por qué TensorZero usaba Rust en su gateway?

Por rendimiento. El gateway está en el camino crítico de cada llamada a un modelo, así que su sobrecarga se paga en todas las inferencias. Rust permitía sostener menos de 1 ms de latencia p99 a más de 10.000 consultas por segundo sin recolección de basura que introdujera picos.

¿Qué alternativas existen si dependía de TensorZero?

Las opciones son mantener un fork propio del proyecto, migrar a otro gateway o capa de observabilidad de LLM compatible con el SDK de OpenAI, o seguir usando la versión actual de forma controlada mientras se planifica la transición. La decisión depende de qué tan crítico sea el componente en tu arquitectura.

Referencias

GitHub — tensorzero/tensorzero — repositorio oficial, ahora archivado y de solo lectura.
TensorZero Blog — anuncio de la ronda seed de 7,3 millones de dólares.
VentureBeat — cobertura del financiamiento y el contexto del proyecto.