DEV Community: lu1tr0n

DeepSeek lanza DSpark: inferencia de V4 hasta 400% más rápida

lu1tr0n — Sat, 27 Jun 2026 14:18:12 +0000

DSpark de DeepSeek volvió a sacudir el ecosistema de modelos abiertos. La compañía china publicó un módulo de decodificación especulativa que acelera la inferencia de sus modelos DeepSeek-V4 Flash y Pro entre un 51% y un 400% según la carga, sin modificar los pesos del modelo base. Junto al módulo liberó DeepSpec, un codebase completo en GitHub para entrenar y evaluar modelos draft.

El paper que lo describe lleva la firma de Liang Wenfeng y llega poco después de la primera ronda de financiación de la empresa. Acá te explicamos qué es, cómo funciona y por qué importa para cualquiera que sirva modelos de lenguaje en producción.

TL;DR

DeepSeek liberó DSpark, decodificación especulativa semi-autorregresiva para DeepSeek-V4 Flash y Pro.
El rendimiento sube entre 51% y 400% con menor latencia, según la tarea y el tamaño de lote.
DSpark combina una cabeza paralela pesada (estilo DFlash) con una cabeza secuencial ligera (estilo Eagle).
La longitud de aceptación crece entre 16,3% y 30,9% frente a Eagle3 y DFlash.
DeepSpec, el codebase de entrenamiento y evaluación, es open source con licencia MIT.
Incluye tres modelos draft: DSpark, DFlash y Eagle3, y soporta como objetivo Qwen3 y Gemma.
Preparar el caché del modelo objetivo puede pesar ~38 TB con la configuración por defecto.
El checkpoint V4-Pro-DSpark es el mismo modelo con el módulo especulativo adjunto, no uno nuevo.

Qué pasó

DeepSeek anunció el lanzamiento de DSpark, descrito en su reporte técnico como "Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation". No se trata de un modelo nuevo: es un módulo que se acopla a los checkpoints existentes de DeepSeek-V4 para que generen texto más rápido. La propia ficha del modelo en Hugging Face lo aclara sin rodeos: "DeepSeek-V4-Pro-DSpark no es un modelo nuevo. Es el mismo checkpoint con un módulo de decodificación especulativa adjunto."

El gesto que más resonó en la comunidad fue el segundo: además de publicar los checkpoints mejorados, DeepSeek abrió DeepSpec, descrito por sus autores como "un codebase full-stack para entrenar y evaluar algoritmos de decodificación especulativa". Es decir, no solo entregaron el resultado, sino la fábrica para reproducirlo y construir el tuyo. El repositorio está bajo licencia MIT, la más permisiva del ecosistema.

Para entender por qué DSpark de DeepSeek genera tanto ruido conviene primero repasar el problema que ataca: la lentitud inherente a cómo generan texto los grandes modelos de lenguaje.

La inferencia secuencial token a token es el cuello de botella que DSpark ataca.

Qué es la decodificación especulativa

Un modelo de lenguaje genera texto un token a la vez. Para producir cada palabra necesita ejecutar una pasada completa por la red neuronal, leer todo el contexto anterior y recién entonces predecir el siguiente token. Ese proceso es estrictamente secuencial: el token número 50 no puede calcularse antes que el 49. En la práctica, esto significa que una GPU carísima pasa la mayor parte del tiempo esperando, limitada por el ancho de banda de memoria más que por su capacidad de cómputo.

La decodificación especulativa (speculative decoding) es un truco elegante para romper ese límite sin cambiar el resultado final. La idea: usar un modelo pequeño y veloz, llamado modelo draft o borrador, para adivinar varios tokens de golpe. Después, el modelo grande y caro, el modelo objetivo, verifica todas esas adivinanzas en una sola pasada paralela. Como verificar es mucho más barato que generar de a uno, si las adivinanzas son buenas obtenés varios tokens por el precio de una pasada.

💭 Clave: La decodificación especulativa nunca cambia la salida del modelo grande. Si el borrador acierta, ganás velocidad; si falla, simplemente descartás la propuesta y seguís. La calidad del texto es idéntica a la generación normal.

La metáfora que mejor funciona: imaginá un escritor experto (el modelo objetivo) y un aprendiz rápido (el modelo draft). El aprendiz escribe a borrador las próximas cinco palabras de un golpe. El experto las lee todas juntas y marca dónde se equivocó el aprendiz. Acepta el prefijo correcto y corrige a partir del primer error. En lugar de dictar palabra por palabra, el experto valida bloques. El cuello de botella deja de ser la generación y pasa a ser cuántas palabras acierta el aprendiz seguidas: eso se mide con la longitud de aceptación.

Cómo funciona DSpark de DeepSeek

El estado del arte previo tenía dos familias de modelos draft. Por un lado, los métodos tipo Eagle, que generan el borrador de forma secuencial (autorregresiva): predicen un token, lo realimentan, predicen el siguiente. Eso da borradores muy coherentes pero lentos de producir. Por el otro, los métodos tipo DFlash y la predicción multi-token (MTP), que disparan varios tokens en paralelo de una sola vez: son rapidísimos generando el borrador, pero como cada token se predice sin ver a sus vecinos, el borrador es menos consistente y el modelo objetivo rechaza más.

DSpark de DeepSeek propone un punto intermedio que los autores llaman generación semi-autorregresiva: combina una cabeza paralela pesada (al estilo DFlash, que propone varios tokens de golpe) seguida de una pequeña cabeza secuencial markoviana (al estilo Eagle, que pule la secuencia mirando dependencias locales). El resultado es un borrador que se genera casi tan rápido como el método paralelo pero con la coherencia del secuencial, lo que dispara la tasa de aceptación.

graph LR
  A["Modelo draft DSpark"] -->|"propone k tokens"| B["Modelo objetivo V4"]
  B -->|"verifica en paralelo"| C{"acepta prefijo?"}
  C -->|"sí"| D["emite tokens aceptados"]
  C -->|"no"| E["corrige desde el error"]
  D --> A
  E --> A

La segunda innovación es la validación con agenda de confianza (confidence-scheduled validation). En lugar de proponer siempre la misma cantidad de tokens, DSpark ajusta cuán agresivo es el borrador según la confianza del modelo: cuando el texto es predecible arriesga más tokens, y cuando es incierto se vuelve conservador. Esto reduce los stalls de la GPU, esos huecos en los que el hardware queda ocioso esperando una verificación.

Para fijar la intuición, así se ve un bucle de decodificación especulativa simplificado en Python:

def decodificacion_especulativa(draft, objetivo, prompt, k=5):
    tokens = list(prompt)
    while not termino(tokens):
        # 1. El modelo draft propone k tokens de un golpe
        propuesta = draft.generar(tokens, n=k)

        # 2. El modelo objetivo verifica los k+1 en UNA pasada paralela
        logits = objetivo.forward(tokens + propuesta)

        # 3. Aceptamos el prefijo donde draft y objetivo coinciden
        aceptados = 0
        for i, tok in enumerate(propuesta):
            if objetivo.acepta(logits[i], tok):
                aceptados += 1
            else:
                break

        # 4. Emitimos los aceptados + 1 corregido por el objetivo
        tokens += propuesta[:aceptados]
        tokens.append(objetivo.muestrear(logits[aceptados]))
    return tokens

El número mágico es aceptados: cuanto más alto en promedio, más rápido va todo. Ahí es donde DSpark mete la diferencia frente a sus competidores.

DSpark sube la longitud de aceptación, y con ella el rendimiento total.

Datos y cifras

Los números que reporta DeepSeek son los que justifican el revuelo. Según la empresa, el rendimiento de inferencia sube entre un 51% y un 400% dependiendo de la tarea y del tamaño de lote, con reducción de latencia. Distintas coberturas redondearon la mejora típica en torno al 80%–85% para casos de uso comunes, mientras que los picos del 400% aparecen en escenarios particularmente favorables a la especulación.

Frente a sus rivales directos, DSpark eleva la longitud de aceptación entre un 16,3% y un 30,9% comparado con Eagle3 y DFlash. Esa métrica es la que realmente importa: un 20% más de tokens aceptados por verificación se traduce casi linealmente en menos pasadas del modelo objetivo y, por lo tanto, en menos costo por token generado.

📌 Nota: El modelo base DeepSeek-V4 ya era eficiente de por sí: su atención híbrida y contexto de 1 millón de tokens requieren, según DeepSeek, solo el 27% de los FLOPs de inferencia por token y el 10% del caché KV respecto de V3.2. DSpark se monta sobre esa base para exprimir aún más velocidad.

La contracara está en los requisitos de entrenamiento. Preparar el caché del modelo objetivo, el paso previo a entrenar un modelo draft, puede ocupar aproximadamente 38 TB de almacenamiento con la configuración por defecto para Qwen3-4B. La configuración estándar también asume un nodo con 8 GPUs. No es un proyecto para entrenar en una laptop, aunque usar los checkpoints ya entrenados sí está al alcance de cualquiera con una GPU decente.

DeepSpec: el codebase abierto

DeepSpec es el aporte que más va a perdurar. Es un framework completo que cubre las tres etapas del ciclo de vida de un modelo draft: preparación de datos (descargar prompts, regenerar respuestas del modelo objetivo y construir el caché), entrenamiento del modelo draft contra esas salidas, y evaluación sobre benchmarks. Incluye implementaciones de los tres algoritmos —DSpark, DFlash y Eagle3— para que puedas compararlos cara a cara.

La evaluación cubre nueve datasets que abarcan razonamiento matemático y generación de código: gsm8k, math500, aime25, humaneval, mbpp, livecodebench, mt-bench, alpaca y arena-hard-v2. Como modelos objetivo soportados de fábrica están las familias Qwen3 y Gemma, lo que confirma que la técnica no está atada a los modelos de DeepSeek.

Clonar y preparar el entorno es directo. Acá los comandos para los tres sistemas operativos:

# Linux y macOS
git clone https://github.com/deepseek-ai/DeepSpec.git
cd DeepSpec
python3 -m venv .venv && source .venv/bin/activate
python -m pip install -r requirements.txt

# Windows (PowerShell)
git clone https://github.com/deepseek-ai/DeepSpec.git
cd DeepSpec
py -m venv .venv; .\.venv\Scripts\Activate.ps1
py -m pip install -r requirements.txt

Una vez instalado, el flujo de trabajo sigue tres scripts en orden. Primero la preparación de datos (necesitás un motor de inferencia sirviendo el modelo objetivo), luego el entrenamiento y por último la evaluación:

# 1. Preparar datos y caché del modelo objetivo (¡ojo con el disco!)
#    Ver el README de data para servir el modelo objetivo

# 2. Entrenar el modelo draft
bash scripts/train/train.sh

# 3. Evaluar contra los benchmarks
bash scripts/eval/eval.sh

⚠️ Ojo: Antes de lanzar la preparación de datos, verificá el espacio en disco. Esos ~38 TB del caché por defecto pueden llenar tu almacenamiento en minutos. Para experimentar, reducí la cantidad de prompts en la configuración o usá un modelo objetivo más chico.

DeepSpec acredita su deuda con el trabajo previo: está construido sobre proyectos como SpecForge (Apache-2.0) y la implementación original de DFlash (MIT), con la atribución documentada en el archivo NOTICE del repositorio. Es un ejemplo de cómo el ecosistema open source de IA avanza por acumulación.

Impacto y análisis

Para quien opera modelos en producción, DSpark de DeepSeek ataca directamente la métrica que más duele: el costo por token y la latencia de respuesta. Una mejora del 50% al 80% en rendimiento significa servir el doble de usuarios con la misma flota de GPUs, o cortar a la mitad la factura de inferencia. En un contexto donde el cómputo de IA es escaso y caro, eso pesa más que un par de puntos en un benchmark de calidad.

Para LATAM, donde el acceso a hardware de punta es limitado y los presupuestos en dólares aprietan, la decodificación especulativa es especialmente relevante. Permite exprimir más de cada GPU rentada en la nube y hace viable correr modelos grandes con latencias aceptables sin duplicar la infraestructura. Y como DSpark no toca los pesos del modelo, no hay que renunciar a calidad para ganar velocidad.

El movimiento estratégico de DeepSeek también merece atención. Al abrir DeepSpec con licencia MIT y demostrar la técnica sobre Qwen y Gemma, la empresa no solo acelera sus propios modelos: empuja a todo el ecosistema open source y consolida su reputación como actor que entrega herramientas, no solo pesos. Es una jugada de credibilidad técnica en un momento en que muchos lanzamientos de IA son más anuncio que sustancia.

Qué sigue

El próximo paso natural es la integración de DSpark en los motores de inferencia populares como vLLM, SGLang y TensorRT-LLM, donde la decodificación especulativa ya es ciudadana de primera clase. A medida que esas integraciones maduren, activar DSpark será cuestión de un flag de configuración para muchos equipos.

También habrá que ver cómo se comporta la técnica con modelos objetivo más grandes y con cargas reales de producción, donde el tamaño de lote variable y los prompts heterogéneos pueden alterar las tasas de aceptación medidas en laboratorio. La comunidad ya empezó a reproducir los resultados sobre Qwen y Gemma, y esos reportes independientes serán la verdadera prueba de fuego. Por ahora, DSpark de DeepSeek se perfila como una de las contribuciones más prácticas del año para abaratar la inferencia de modelos de lenguaje.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿DSpark cambia la calidad del texto que genera el modelo?

No. La decodificación especulativa está diseñada para producir exactamente la misma salida que la generación normal del modelo objetivo. El modelo draft solo propone candidatos; el modelo grande verifica y tiene la última palabra. Si el borrador se equivoca, su propuesta se descarta. Solo ganás velocidad, nunca perdés calidad.

¿Necesito reentrenar mi modelo para usar DSpark?

No reentrenás el modelo base. DSpark es un módulo de decodificación especulativa que se acopla al checkpoint existente. Lo que sí hay que entrenar es el modelo draft, un componente pequeño, contra las salidas de tu modelo objetivo. DeepSpec provee todo el pipeline para hacerlo, aunque también podés usar los checkpoints V4-Pro-DSpark ya listos.

¿En qué se diferencia DSpark de Eagle3 y DFlash?

Eagle genera el borrador de forma secuencial (coherente pero lento) y DFlash lo genera en paralelo (rápido pero menos consistente). DSpark combina ambos con su enfoque semi-autorregresivo: una cabeza paralela seguida de una secuencial ligera. Eso eleva la longitud de aceptación entre 16,3% y 30,9% frente a esos métodos.

¿Funciona DSpark solo con modelos de DeepSeek?

El módulo DSpark se distribuye para DeepSeek-V4 Flash y Pro, pero el codebase DeepSpec soporta como modelos objetivo a las familias Qwen3 y Gemma. La técnica es general; podés entrenar tus propios modelos draft para otros modelos objetivo siguiendo el pipeline del repositorio.

¿Cuánto hardware necesito para entrenar un modelo draft?

La configuración por defecto asume un nodo con 8 GPUs y, lo más exigente, hasta unos 38 TB de almacenamiento para el caché del modelo objetivo con Qwen3-4B. Para usar checkpoints ya entrenados los requisitos son mucho menores: alcanza con una GPU capaz de correr el modelo base.

¿Es DeepSpec realmente open source?

Sí. DeepSpec se publicó bajo licencia MIT, una de las más permisivas, lo que permite uso comercial, modificación y redistribución. Reutiliza código de proyectos previos como SpecForge (Apache-2.0) y DFlash (MIT), con la atribución correspondiente documentada en el archivo NOTICE.

Referencias

DeepSpec en GitHub — codebase full-stack para entrenar y evaluar modelos draft (DSpark, DFlash, Eagle3), licencia MIT.
DSpark paper (PDF) — reporte técnico oficial de la decodificación especulativa semi-autorregresiva con agenda de confianza.
DeepSeek-V4-Pro-DSpark en Hugging Face — ficha del checkpoint con el módulo DSpark adjunto y detalles del modelo base.

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

OpenTTD 16.0-beta1 ya permite conducir trenes en reversa

lu1tr0n — Sat, 27 Jun 2026 08:16:40 +0000

OpenTTD, el veterano simulador de transporte de código abierto, acaba de liberar la primera beta de su versión 16. Entre las novedades destaca algo que la comunidad pedía desde hace años: los trenes por fin pueden circular en reversa, sin necesidad de construir una vía de retorno ni recurrir a trucos de señalización.

La beta, publicada el 25 de junio de 2026, llega para que los jugadores prueben las funciones nuevas antes del lanzamiento estable. OpenTTD 16 reúne cambios en jugabilidad, multijugador, generación de mapas y la interfaz, además de abrir la competencia comunitaria para elegir la pantalla de inicio de la nueva versión.

TL;DR

OpenTTD 16.0-beta1 se publicó el 25 de junio de 2026 para pruebas de la comunidad.
Los trenes ahora pueden conducir en reversa, eliminando la necesidad de bucles de retorno.
Las empresas multijugador pueden configurarse para que cualquiera se una sin invitación.
La generación de mapas mejora: rocas en desierto, mejores costas y nuevas reglas para faros y transmisores.
Las subvenciones ahora funcionan con cargos que usan el sistema CargoDist.
Se pueden guardar colecciones propias de NewGRF: objetos, estaciones y casas.
Abrió la competencia comunitaria para diseñar el 'title game' de la versión 16.

Qué pasó

El equipo de desarrollo de OpenTTD anunció la disponibilidad de OpenTTD 16 en su primera versión beta. Como es habitual en el proyecto, la beta no es un lanzamiento final: es una invitación abierta a que la comunidad descargue, juegue y reporte fallos antes de que llegue la versión estable. El ciclo de pruebas es parte esencial de cómo este proyecto open source mantiene la calidad sin un equipo comercial detrás.

La función más comentada es la capacidad de los trenes de conducir en reversa. Durante décadas, mover un tren hacia atrás en Transport Tycoon y sus sucesores exigía construir bucles de retorno, estaciones pasantes o depósitos estratégicos. Ahora el motor del juego permite invertir la marcha de forma nativa, lo que simplifica enormemente el diseño de redes ferroviarias en espacios reducidos, como terminales industriales o estaciones de cabecera.

💭 Clave: que un tren pueda ir en reversa parece menor, pero cambia por completo la forma de diseñar ramales cortos, patios de maniobra y estaciones terminales sin desperdiciar espacio en bucles.

Contexto e historia

OpenTTD nació como una reimplementación libre de Transport Tycoon Deluxe, el clásico de simulación de transporte publicado por Chris Sawyer en 1995. El proyecto comenzó a principios de los 2000 cuando un grupo de desarrolladores hizo ingeniería inversa del motor original y lo reescribió en C++, permitiendo que el juego corriera en sistemas modernos y, con el tiempo, superara con creces al original.

Hoy OpenTTD es uno de los proyectos de videojuegos open source más longevos y activos. Está licenciado bajo GPL v2, corre en Windows, macOS, Linux e incluso en consolas y dispositivos poco convencionales gracias a su código portable. Su sistema de extensiones NewGRF permite a la comunidad crear gráficos, vehículos, industrias y mecánicas completas, lo que ha generado un ecosistema enorme de contenido creado por fans.

Para quienes desarrollan en LATAM, OpenTTD es además un caso de estudio interesante: un proyecto sostenido durante más de veinte años por voluntarios, con releases regulares, un sistema de scripting (con IA de empresas programables en Squirrel) y un flujo de contribución abierto en GitHub. Es un buen lugar para aprender C++ moderno, diseño de motores de juego y trabajo colaborativo a gran escala.

OpenTTD 16 simplifica el diseño de estaciones terminales.

Las novedades de OpenTTD 16

Más allá de los trenes en reversa, OpenTTD 16 trae un paquete amplio de mejoras que tocan casi todas las áreas del juego. Estas son las más relevantes:

Trenes en reversa — Los convoyes pueden invertir su sentido de marcha sin infraestructura adicional, algo que reduce la complejidad de las redes pequeñas.
Empresas multijugador abiertas — Ahora una compañía puede configurarse para que cualquier jugador se una sin necesidad de invitación, bajando la fricción para partidas cooperativas.
Mejor generación de mapas — Aparecen rocas en las casillas de desierto, las costas cerca de los bordes del mapa se ven más naturales, los faros se generan mejor en mapas grandes, los transmisores solo aparecen después de 1920 y se añade control sobre la altura promedio del terreno.
Subvenciones con CargoDist — Las subvenciones se habilitan para cargos que usan el sistema de distribución de carga CargoDist, integrando dos mecánicas que antes no convivían bien.
Colecciones de NewGRF — Puedes crear tus propias colecciones de elementos guardados en las ventanas de selección: objetos, estaciones y casas.
Escalado del pago de carga por envejecimiento — Se puede ajustar la tasa a la que envejece la carga, de modo que los vehículos lentos en mapas grandes sigan siendo rentables.
Filtros de texto en menús desplegables — Las listas desplegables ahora incluyen un filtro para encontrar opciones más rápido.
Ventana única de vehículos en oferta — Las ofertas de vista previa de vehículos se agrupan en una sola ventana en lugar de abrir muchas a la vez.

El cambio en las subvenciones merece una nota aparte. CargoDist es el sistema que reparte automáticamente la carga entre estaciones según la demanda, simulando flujos logísticos realistas. Hasta ahora las subvenciones (los incentivos económicos que el juego ofrece por conectar dos puntos) no se activaban para esos cargos. Con OpenTTD 16, ambos sistemas se combinan:

graph LR
  A["Origen: industria"] --> B["CargoDist enruta la carga"]
  B --> C["Estacion destino"]
  C --> D["Subvencion activa"]
  D --> E["Pago extra al transportista"]

Datos y cifras: cómo instalar la beta

OpenTTD 16.0-beta1 está disponible para descarga directa desde el sitio oficial. Al ser una beta, conviene mantenerla separada de tu instalación estable para no mezclar partidas guardadas. Estas son las formas de instalarla según tu sistema operativo:

Windows (con winget):

winget install OpenTTD.OpenTTD
# O descargar el instalador/portable desde:
# https://www.openttd.org/downloads/openttd-releases/latest

macOS (con Homebrew):

brew install --cask openttd
# O descargar el .dmg desde el sitio oficial

Linux (Flatpak, recomendado para probar betas sin tocar el sistema):

flatpak install flathub org.openttd.OpenTTD
flatpak run org.openttd.OpenTTD

# Alternativa: compilar desde el código fuente
git clone https://github.com/OpenTTD/OpenTTD.git
cd OpenTTD
mkdir build && cd build
cmake ..
cmake --build . -j$(nproc)

💡 Tip: si compilás desde el código fuente, asegurate de tener instaladas las dependencias (SDL2, zlib, liblzma, libpng). El repositorio de GitHub documenta los requisitos por plataforma en su archivo de compilación.

Si encontrás algún fallo, el proyecto pide que lo reportes en su bug tracker oficial. Cada reporte de la comunidad durante la fase beta es lo que permite que la versión estable llegue pulida.

La pantalla de inicio se elige por votación comunitaria.

Impacto y análisis

Las novedades de OpenTTD 16 apuntan a dos públicos distintos. Por un lado, los jugadores veteranos reciben mejoras de calidad de vida —filtros en menús, ventana única de vehículos, control fino de la generación de mapas— que reducen la fricción acumulada de años. Por otro, los cambios en jugabilidad como los trenes en reversa y la integración de subvenciones con CargoDist abren posibilidades de diseño que antes requerían trucos o no eran viables.

El aspecto multijugador también es estratégico. Permitir que las empresas se configuren como abiertas baja la barrera de entrada para partidas cooperativas, algo importante para una comunidad que se sostiene en parte por servidores públicos donde desconocidos colaboran en la misma compañía. Menos fricción para unirse significa más partidas activas y más retención de nuevos jugadores.

📌 Nota: esta es una beta. No se recomienda usarla para partidas serias o de torneo todavía, ya que el formato de guardado puede cambiar antes del lanzamiento estable y algunas funciones pueden ajustarse según el feedback.

Para el ecosistema open source, cada release de OpenTTD es un recordatorio de que un proyecto comunitario bien organizado puede mantener un ritmo de desarrollo envidiable durante décadas. No hay presión comercial, no hay microtransacciones, no hay deadlines de marketing: solo un ciclo de mejora continua impulsado por voluntarios.

Qué sigue

El equipo también lanzó la competencia del Title Game de OpenTTD 16 en los foros de TT-Forums. El "title game" es la partida que se reproduce de fondo en el menú principal, y la tradición del proyecto es que la comunidad la diseñe y la elija por votación. El actual escenario de Toyland, por ejemplo, fue creado y elegido por los propios jugadores.

A partir de aquí, el camino habitual es publicar más betas si surgen fallos importantes, luego una o varias release candidates, y finalmente la versión 16.0 estable. El tiempo exacto depende del volumen de bugs reportados durante esta fase. Mientras tanto, la mejor forma de ayudar al proyecto es descargar la beta, jugar y reportar cualquier problema en el bug tracker.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es OpenTTD?

OpenTTD es un simulador de transporte de código abierto, reimplementación libre de Transport Tycoon Deluxe (1995). Permite construir redes de trenes, camiones, barcos y aviones para transportar carga y pasajeros. Es gratuito, multiplataforma y se distribuye bajo licencia GPL v2.

¿Cuál es la novedad más importante de OpenTTD 16?

La capacidad de que los trenes conduzcan en reversa sin necesidad de bucles de retorno. Es una función que la comunidad pedía desde hace años y que simplifica mucho el diseño de estaciones terminales y patios de maniobra.

¿Puedo usar la beta para mis partidas actuales?

No se recomienda. Al ser una beta, el formato de guardado puede cambiar antes de la versión estable. Conviene mantenerla en una instalación separada y usarla solo para probar y reportar fallos.

¿Cómo instalo OpenTTD 16 en Linux?

La forma más sencilla es con Flatpak: flatpak install flathub org.openttd.OpenTTD. También podés descargar el binario desde el sitio oficial o compilar desde el código fuente del repositorio de GitHub.

¿Qué es CargoDist y por qué importa el cambio en subvenciones?

CargoDist es el sistema que distribuye automáticamente la carga entre estaciones según la demanda, simulando flujos logísticos realistas. En OpenTTD 16, las subvenciones —incentivos económicos por conectar dos puntos— por fin se activan para cargos que usan CargoDist, integrando dos mecánicas que antes no convivían.

¿Dónde reporto un bug de la beta?

En el bug tracker oficial del proyecto, enlazado desde el anuncio de la versión. Cada reporte durante la fase beta ayuda a que la versión estable llegue más pulida.

Referencias

OpenTTD News — OpenTTD 16.0-beta1 — anuncio oficial con el listado completo de novedades.
OpenTTD Downloads — descargas oficiales para Windows, macOS y Linux.
OpenTTD en GitHub — código fuente, instrucciones de compilación y bug tracker.
Wiki de OpenTTD — documentación de mecánicas, NewGRF y CargoDist.
TT-Forums — foros de la comunidad y competencia del Title Game.

Terence Tao y la 'Big Mathematics': IA que demuestra teoremas

lu1tr0n — Sat, 27 Jun 2026 02:19:14 +0000

La inteligencia artificial ya no solo escribe código: ahora demuestra teoremas, resuelve problemas de olimpiada y verifica pruebas que antes tomaban años de trabajo humano. La IA en matemáticas dejó de ser una curiosidad de laboratorio para convertirse en una herramienta de investigación real, usada por algunos de los mejores matemáticos del mundo.

Un reportaje de IEEE Spectrum publicado el 25 de junio de 2026 recoge el debate que esto abre entre los propios protagonistas: si una máquina puede hallar la demostración, ¿qué significa hoy ser matemático?

TL;DR

IEEE Spectrum publicó el 25 de junio de 2026 un reportaje de Benjamin Skuse sobre el papel del matemático en la era de la IA.
Terence Tao (UCLA) plantea una era de Big Mathematics: humanos y máquinas colaborando en problemas complejos.
AlphaProof y AlphaGeometry2 de DeepMind alcanzaron nivel de medalla de plata en la IMO 2024 con 28 de 42 puntos.
El asistente de pruebas Lean y su librería Mathlib superan el millón de líneas de matemática formalizada y verificada.
Tao y colaboradores formalizaron la conjetura PFR en Lean en unas tres semanas a fines de 2023.
En el benchmark FrontierMath los mejores modelos resolvían menos del 2% de los problemas al lanzarse en 2024.
El debate de fondo no es técnico sino humano: la motivación, el sentido y la belleza de entender una demostración.

Qué pasó: la IA en matemáticas reabre una vieja pregunta

El reportaje de IEEE Spectrum, firmado por el divulgador y exdoctorando en matemática aplicada Benjamin Skuse, no anuncia un nuevo récord ni un teorema resuelto por sorpresa. Hace algo menos llamativo pero más profundo: pregunta a matemáticos en activo qué sienten ahora que parte de su trabajo puede automatizarse. La pieza enfrenta dos miradas que conviven en la comunidad. Por un lado, el optimismo de quienes ven a la IA en matemáticas como un multiplicador de capacidades. Por el otro, la cautela de quienes temen que el oficio pierda lo que lo hacía valioso.

La figura central es Terence Tao, matemático de la Universidad de California en Los Ángeles y ganador de la Medalla Fields, quizá el matemático vivo más influyente. Tao describe la llegada de una era de Big Mathematics (matemática a gran escala), por analogía con la big science: grandes colaboraciones donde humanos y máquinas atacan juntos problemas que antes requerían comunidades enteras durante décadas. En su visión, la máquina no expulsa al matemático del problema; lo libera de la parte mecánica para que se concentre en las ideas, las conjeturas y la estrategia.

Frente a ese entusiasmo, el reportaje da espacio a una reflexión más íntima de Jeremy Avigad, matemático y lógico de la Universidad Carnegie Mellon. Avigad recuerda que el motor de la matemática nunca fue solo resolver: fue entender. "A veces, la comprensión simplemente te golpea como algo muy hermoso", dice. "A veces es una sensación de logro, como terminar un maratón. Pero no es exactamente ninguna de las dos: es una sensación maravillosa cuando llevas mucho tiempo pensando en algo complejo y difícil y, de repente, todo encaja". Esa frase resume la tensión del artículo: si la IA entrega el resultado sin el viaje, ¿se pierde también el sentido?

La demostración como proceso humano, no solo como resultado.

Contexto e historia: de las cuatro colores a Lean

La idea de una máquina ayudando a probar teoremas no es nueva. En 1976, el teorema de los cuatro colores se convirtió en el primer gran resultado demostrado con ayuda esencial de una computadora, que verificó cientos de casos imposibles de revisar a mano. Aquello generó un debate filosófico que todavía resuena: ¿es una demostración "real" si ningún humano puede leerla completa? Décadas después, el proyecto Flyspeck formalizó por completo la prueba de la conjetura de Kepler sobre el empaquetamiento de esferas, sellando con verificación mecánica un resultado que muchos dudaban en aceptar.

Lo que cambió en los últimos años es la madurez de los asistentes de pruebas y la irrupción de los modelos de lenguaje. Un asistente de pruebas como Lean es, en esencia, un lenguaje de programación donde cada paso de un argumento matemático se escribe como código que el sistema verifica de forma rigurosa. Si la prueba tiene un hueco, el programa no compila. Sobre Lean se construyó Mathlib, una biblioteca colaborativa que ya supera el millón de líneas de matemática formalizada: desde aritmética básica hasta análisis funcional y teoría de categorías.

Aquí entra la IA generativa. Los modelos modernos pueden proponer borradores de pruebas en lenguaje natural, traducirlos a Lean y corregir los errores que el verificador señala, en un ciclo de prueba y error mucho más rápido que el humano. La IA en matemáticas no reemplaza al verificador formal: lo alimenta. La máquina conjetura y redacta; Lean dice si está bien.

📌 Nota: Un asistente de pruebas no "confía" en la IA. Aunque un modelo genere una demostración convincente pero falsa, Lean la rechaza si un solo paso no se sostiene. Esa es su garantía clave.

Datos y cifras: lo que las máquinas ya resuelven

Los números ayudan a dimensionar el salto. En julio de 2024, los sistemas AlphaProof y AlphaGeometry2 de Google DeepMind resolvieron cuatro de los seis problemas de la Olimpiada Internacional de Matemáticas (IMO), sumando 28 de 42 puntos: nivel de medalla de plata, a un solo punto del oro. Era la primera vez que una IA alcanzaba ese rendimiento en la competencia matemática preuniversitaria más exigente del mundo. AlphaProof trabajaba precisamente formalizando los problemas en Lean y buscando demostraciones verificables.

En el terreno de la investigación, el propio Tao lideró a fines de 2023 la formalización en Lean de la conjetura polinomial de Freiman-Ruzsa (PFR), recién demostrada en papel. Lo que en otra época habría tomado meses se completó, con una comunidad coordinada, en alrededor de tres semanas. Fue una demostración de que la formalización asistida ya es práctica, no solo teórica.

Al mismo tiempo, los límites siguen siendo claros. El benchmark FrontierMath, presentado por Epoch AI a fines de 2024 con problemas originales de nivel investigación, mostró que los mejores modelos del momento resolvían menos del 2% de los ejercicios. La matemática de frontera, la que realmente importa, todavía está mayormente fuera del alcance autónomo de la IA.

De la conjetura humana a la verificación formal en Lean.

Impacto y análisis: ¿reemplazo o copiloto?

Para entender por qué la IA en matemáticas entusiasma a investigadores como Tao, conviene ver cómo luce una demostración formal. Tomemos algo elemental: probar que la suma de números naturales es conmutativa. En Lean 4 se escribe así, y el sistema verifica cada paso:

-- Lean 4: demostración formal de que la suma es conmutativa
theorem suma_conmutativa (a b : Nat) : a + b = b + a := by
  induction b with
  | zero => simp
  | succ n ih => rw [Nat.add_succ, ih, Nat.succ_add]

Cada línea es un paso lógico que la máquina valida sin margen de error. Ahora imaginemos miles de teoremas encadenados: ese es Mathlib. Y la IA puede aprender de ese corpus para sugerir el siguiente paso, igual que un copiloto de código sugiere la siguiente línea. El flujo de trabajo se parece cada vez más al desarrollo de software:

graph LR
  A["Matemático: conjetura"] --> B["IA: genera demostración"]
  B --> C["Lean: verifica paso a paso"]
  C -->|"falla"| B
  C -->|"válida"| D["Teorema certificado"]

Para un desarrollador en LATAM, la analogía es directa: la IA en matemáticas funciona como un test runner combinado con un asistente de autocompletado. El humano define qué quiere probar (la especificación), la IA propone una implementación (la demostración) y el verificador actúa como una suite de tests que no acepta atajos. Quien programe con TDD reconocerá el patrón de inmediato.

💭 Clave: El miedo de Avigad no es que la IA se equivoque, sino que acierte demasiado. Si la máquina entrega el resultado sin el esfuerzo, desaparece el aprendizaje que forma matemáticos. Es el mismo debate que hoy enfrenta el desarrollo de software con los asistentes de código.

Ese paralelo no es casual. El propio reportaje conecta con una discusión que la industria tech ya conoce: cuando una herramienta resuelve la parte difícil, los novatos pierden la oportunidad de tropezar, batallar y aprender. En programación se discute si los asistentes de IA degradan la comprensión profunda del código; en matemática, la pregunta es si las nuevas generaciones desarrollarán la intuición que solo nace de pasarse años atascados en un problema.

Qué sigue: la era de la "Big Mathematics"

El escenario que dibuja Tao apunta a una colaboración masiva. Con asistentes de pruebas, miles de matemáticos pueden trabajar sobre una misma demostración formal sin temor a que un error se cuele, porque el sistema garantiza la consistencia. La IA actúa como pegamento: rellena pasos rutinarios, traduce entre el lenguaje informal y el formal, y busca contraejemplos. El resultado podría ser un ritmo de descubrimiento inédito, con proyectos colaborativos a escala que hoy serían inmanejables.

Para la comunidad hispanohablante, esto abre una puerta concreta. Aprender Lean ya no es un ejercicio académico aislado: es una habilidad puente entre matemática, verificación formal y desarrollo de software seguro, un área donde LATAM tiene talento de sobra y poca representación. Las mismas técnicas de verificación formal que validan teoremas se usan para certificar que un microkernel, un contrato inteligente o un protocolo criptográfico no tienen fallos.

💡 Tip: Si querés experimentar, Lean 4 es gratuito y open source. Empezá por el tutorial interactivo Natural Number Game, que enseña a demostrar teoremas como si fuera un videojuego, sin necesidad de instalar nada.

Lo que ninguna de las dos posturas niega es que el oficio cambiará. La discusión real, la que plantea IEEE Spectrum, no es si la IA en matemáticas será útil —ya lo es— sino qué parte del trabajo seguirá teniendo sentido hacer a mano. Y esa pregunta, paradójicamente, es de las pocas que ninguna máquina puede responder por nosotros.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿La IA ya puede demostrar teoremas por sí sola?

Parcialmente. Sistemas como AlphaProof resuelven problemas de olimpiada a nivel de medalla de plata y la IA ayuda a formalizar demostraciones reales en Lean. Pero en matemática de frontera, los mejores modelos resolvían menos del 2% del benchmark FrontierMath en 2024. La IA es hoy un asistente potente, no un sustituto autónomo.

¿Qué es un asistente de pruebas como Lean?

Es un lenguaje de programación donde cada paso de una demostración matemática se escribe como código que el sistema verifica con rigor absoluto. Si un paso no se sostiene, no compila. Eso garantiza que una prueba aceptada por Lean es lógicamente correcta, incluso si fue redactada por una IA.

¿Qué significa la "Big Mathematics" de Terence Tao?

Es la visión de una matemática a gran escala, por analogía con la big science: grandes colaboraciones entre humanos y máquinas atacando problemas complejos. La IA y los asistentes de pruebas permiten coordinar a muchos matemáticos sobre una misma demostración sin que se acumulen errores.

¿Por qué algunos matemáticos están preocupados?

Porque el valor del oficio nunca fue solo el resultado, sino la comprensión que nace del proceso. Jeremy Avigad teme que, si la máquina entrega la respuesta sin el esfuerzo, las nuevas generaciones pierdan la intuición y el sentido que solo se desarrollan batallando con un problema durante años.

¿Sirve aprender Lean si soy desarrollador y no matemático?

Sí. Las técnicas de verificación formal de Lean se aplican a software crítico: kernels, contratos inteligentes y protocolos criptográficos. Aprenderlo conecta matemática, lógica y desarrollo seguro, un perfil muy demandado y escaso en LATAM.

Referencias

IEEE Spectrum — Reportaje original de Benjamin Skuse sobre el rol del matemático cuando la IA hace el cálculo.
Lean 4 (GitHub) — Repositorio oficial del asistente de pruebas Lean.
Blog de Terence Tao — Notas del matemático sobre formalización en Lean y el proyecto PFR.
Google DeepMind — Anuncio de AlphaProof y AlphaGeometry2 en la IMO 2024.
FrontierMath (arXiv) — Benchmark de problemas matemáticos de nivel investigación.

Qualcomm compra Modular por casi $4.000M para retar a CUDA

lu1tr0n — Fri, 26 Jun 2026 16:10:01 +0000

Qualcomm compra Modular y, con ese movimiento, entra de lleno en la guerra por el software que mueve la inteligencia artificial. El fabricante de chips anunció el 24 de junio de 2026 la adquisición de la startup fundada por Chris Lattner, el ingeniero detrás de LLVM, Clang y Swift, en una operación valuada en cerca de $3.900 millones en acciones.

El objetivo no es un chip nuevo: es el stack de software que permite correr modelos de IA en cualquier hardware sin depender de CUDA, la plataforma que hoy ata a millones de desarrolladores al ecosistema de Nvidia.

TL;DR

Qualcomm anunció el 24 de junio de 2026 la compra de Modular por unos $3.900 millones en acciones.
Modular fue fundada en 2022 por Chris Lattner (creador de LLVM, Clang y Swift) y Tim Davis tras salir de Google.
El cierre se espera para el segundo semestre de 2026, sujeto a aprobación regulatoria.
Modular aporta el lenguaje Mojo y el motor de inferencia MAX, que corre sin cambios en GPU de Nvidia, AMD, Apple, ARM e Intel.
La meta estratégica es romper el lock-in de CUDA, la verdadera ventaja competitiva de Nvidia.
Modular levantó $250 millones a una valuación de $1.600 millones en septiembre de 2025: el premio de compra es de más de 2x.
Los ~150 empleados, incluidos ambos fundadores, se integran a Qualcomm para potenciar sus aceleradores de IA.

Qué pasó

El 24 de junio de 2026, Qualcomm anunció un acuerdo definitivo para adquirir Modular, una compañía de software de IA con sede en Silicon Valley. Aunque Qualcomm no reveló oficialmente el monto, Reuters calculó la operación en aproximadamente $3.920 millones, una transacción que se pagaría en acciones de Qualcomm. La empresa espera cerrar la compra en el segundo semestre de 2026, una vez que pase las aprobaciones regulatorias y se cumplan las condiciones habituales de cierre.

El trato incorpora al equipo completo de Modular, unas 150 personas, incluidos sus dos cofundadores: Chris Lattner y Tim Davis. Ambos llegaron a Modular tras pasar por Google, donde trabajaron en la infraestructura de TensorFlow y en MLIR, el framework de compiladores que hoy sostiene buena parte del tooling moderno de machine learning. Que Qualcomm compra Modular con todo su talento intacto es, según los analistas, tan importante como la tecnología misma: en software de IA, la gente que entiende los compiladores de bajo nivel es escasa.

💭 Clave: Qualcomm no compró un acelerador. Compró la capa de software que decide en qué hardware puede correr un modelo de IA, que es justo donde Nvidia tiene su foso defensivo.

Cristiano Amon, CEO de Qualcomm, resumió la apuesta así: "We believe the future belongs to developer-friendly, horizontal platforms that can run across diverse compute environments". Chris Lattner, por su parte, declaró que "joining Qualcomm gives us the scale and platform reach to accelerate that mission", subrayando que la misión de Modular —soportar hardware de todos los fabricantes— no cambia con la compra.

Qualcomm quiere su software de IA en el centro de datos, no solo en el móvil.

Contexto e historia: quién es Modular y por qué importa

Para entender por qué Qualcomm compra Modular hay que entender a su fundador. Chris Lattner es uno de los ingenieros de software más influyentes de las últimas dos décadas. Creó LLVM, la infraestructura de compiladores que hoy está debajo de Swift, Rust, Julia y decenas de lenguajes más. Construyó Clang, el compilador de C/C++ que reemplazó a buena parte de GCC en el mundo Apple. Diseñó Swift, el lenguaje de iOS. Y en Google lideró MLIR, una pieza central de la infraestructura de IA. Cuando alguien con ese historial funda una empresa en 2022 para arreglar el software de IA, la industria presta atención.

La tesis de Modular es directa: el verdadero cuello de botella de la IA no es el silicio, es el software que lo programa. Entrenar e inferir modelos hoy implica enredarse con CUDA, ROCm, librerías propietarias y kernels escritos a mano para cada chip. Esa fragmentación encadena a los equipos a un solo proveedor. Modular nació para construir una capa de abstracción que permita escribir una vez y ejecutar en cualquier procesador.

La compañía no llegó barata. En septiembre de 2025, Modular levantó $250 millones en una ronda que la valuó en $1.600 millones. Que Qualcomm pague cerca de $3.900 millones apenas nueve meses después implica un premio de más del doble sobre esa valuación, una señal de cuánto vale hoy el software que desacopla los modelos del hardware.

Las dos piezas técnicas: Mojo y MAX

Modular aporta dos productos centrales. El primero es Mojo, un lenguaje de programación diseñado como superset de Python: el código Python existente debería correr, pero con la posibilidad de alcanzar rendimiento de nivel C++ y aprovechar GPU directamente. Mojo apunta a su versión 1.0 para el verano de 2026, con el compromiso de abrir el código del compilador en ese hito. La promesa es seductora para cualquier desarrollador de ML: la productividad de Python con la velocidad del metal.

El segundo es MAX, un motor de inferencia agnóstico al hardware. La idea es que un mismo modelo, sin modificaciones, corra sobre Nvidia Blackwell, AMD MI300X, Apple Silicon, CPU ARM e Intel, sin necesidad de librerías específicas del fabricante como CUDA, ROCm o incluso PyTorch optimizado por vendor. Es exactamente el tipo de portabilidad que Qualcomm necesita para que sus propios aceleradores de centro de datos sean una opción creíble.

# Mojo: sintaxis familiar de Python, con tipos opcionales
# para liberar rendimiento de nivel C++ sobre CPU/GPU
fn suma_vectores(a: Tensor[DType.float32],
                 b: Tensor[DType.float32]) -> Tensor[DType.float32]:
    var salida = Tensor[DType.float32](a.shape())
    for i in range(a.num_elements()):
        salida[i] = a[i] + b[i]   # se vectoriza en el hardware disponible
    return salida

El ejemplo es ilustrativo, pero captura la idea: escribir algo que se siente como Python y dejar que el compilador lo mapee al hardware que tengas enfrente, ya sea una GPU de Nvidia o un NPU de Qualcomm.

Datos y cifras

Los números de la operación ayudan a dimensionar la apuesta. La adquisición ronda los $3.900 millones, pagados en acciones de Qualcomm. El equipo que se transfiere es de aproximadamente 150 empleados. Modular fue fundada en 2022 y, en su última ronda de septiembre de 2025, fue valuada en $1.600 millones tras levantar $250 millones. El cierre está previsto para la segunda mitad de 2026.

El contexto financiero de Qualcomm explica la urgencia. La compañía construyó su imperio sobre los módems y los SoC Snapdragon de teléfonos, un mercado maduro y dependiente de Apple como cliente clave. El centro de datos de IA, en cambio, es el segmento de mayor crecimiento de la industria, hoy dominado por Nvidia. Qualcomm ha empezado a empujar sus aceleradores de IA para servidores, y un stack de software portable es la pieza que le faltaba para competir.

Un mismo modelo corriendo en distintos chips gracias a una capa de software común.

Impacto y análisis: el ataque al foso de CUDA

La razón de fondo por la que Qualcomm compra Modular se resume en una sigla: CUDA. La ventaja competitiva más profunda de Nvidia no son sus chips H100 o B200, sino el ecosistema de software construido sobre CUDA durante casi dos décadas. Millones de desarrolladores, frameworks enteros y años de optimizaciones viven dentro de CUDA. Comprar una GPU de la competencia significa, en la práctica, abandonar todo ese tooling. Ese es el lock-in que sostiene los márgenes de Nvidia.

Modular ataca exactamente ese punto. Si MAX permite correr un modelo sin tocar el código sobre cualquier acelerador, el costo de cambiar de proveedor se desploma. Para Qualcomm, que necesita convencer a clientes de centros de datos de probar su hardware, ese desacople es estratégico. La compañía ha vinculado la adquisición al desarrollo de sus aceleradores de IA de próxima generación, posicionándolos como una alternativa abierta frente al jardín amurallado de CUDA.

📌 Nota: La portabilidad de Modular es agnóstica por diseño: seguirá soportando hardware de Nvidia, AMD, Apple e Intel. La compra no la convierte en exclusiva de Qualcomm, lo que mantiene su valor para todo el ecosistema.

El diagrama siguiente resume el flujo que Modular habilita y por qué amenaza el lock-in:

graph LR
  M["Modelo de IA"] --> MAX["Motor MAX"]
  MAX --> N["GPU Nvidia"]
  MAX --> A["GPU AMD"]
  MAX --> Q["Acelerador Qualcomm"]
  MAX --> ARM["CPU ARM / Apple"]

Hay un matiz competitivo interesante. Qualcomm hereda no solo tecnología, sino credibilidad. Lattner es una figura respetada por la comunidad de compiladores y sistemas; su presencia da a Qualcomm una legitimidad en software de IA que el dinero por sí solo no compra. El riesgo, claro, es de integración: las grandes adquisiciones de talento suelen perder a sus fundadores en pocos años, y el valor de Modular depende justamente de que Lattner y su equipo permanezcan.

Qué sigue

En el corto plazo, la atención estará en el cierre regulatorio durante el segundo semestre de 2026 y en si Mojo cumple su promesa de llegar a la versión 1.0 con compilador open source este verano. Ese hito será una prueba de fuego: la comunidad de desarrolladores juzgará si el lenguaje realmente entrega rendimiento de C++ con ergonomía de Python.

A mediano plazo, la pregunta es si Qualcomm logra integrar el stack de Modular bajo sus aceleradores sin diluir el carácter abierto y multiproveedor que le da valor. Si lo consigue, tendrá una de las pocas plataformas de software capaces de competir con CUDA de igual a igual. Si falla, habrá pagado casi $4.000 millones por talento que podría dispersarse. El movimiento confirma una tendencia más amplia: en la era de la IA, la batalla decisiva ya no se libra solo en el silicio, sino en el software que decide dónde y cómo corre cada modelo.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Cuánto pagó Qualcomm por Modular?

Qualcomm no reveló oficialmente el monto, pero Reuters lo calculó en aproximadamente $3.920 millones, pagados en acciones de Qualcomm. El cierre se espera para el segundo semestre de 2026, sujeto a aprobaciones regulatorias.

¿Quién es Chris Lattner y por qué importa?

Chris Lattner es el ingeniero que creó LLVM, Clang y el lenguaje Swift, y luego lideró MLIR en Google. Cofundó Modular en 2022 junto a Tim Davis. Su experiencia en compiladores es central para construir software de IA que abstraiga el hardware.

¿Qué son Mojo y MAX?

Mojo es un lenguaje de programación superset de Python que apunta a rendimiento de nivel C++ sobre CPU y GPU, con su versión 1.0 prevista para el verano de 2026. MAX es un motor de inferencia agnóstico al hardware que corre modelos sin cambios sobre chips de Nvidia, AMD, Apple, ARM e Intel.

¿Por qué esto amenaza a Nvidia?

La ventaja más fuerte de Nvidia es CUDA, el ecosistema de software que ata a los desarrolladores a sus GPU. El motor MAX de Modular permite correr modelos en cualquier acelerador sin depender de CUDA, lo que reduce el costo de cambiar de proveedor y debilita ese lock-in.

¿Modular dejará de soportar otro hardware al ser de Qualcomm?

Según Chris Lattner, no. La misión de soportar hardware de todos los fabricantes se mantiene; la compra busca acelerarla, no convertirla en exclusiva de Qualcomm.

¿Cuándo se cierra la operación?

Qualcomm espera completar la adquisición durante el segundo semestre de 2026, una vez superadas las aprobaciones regulatorias y las condiciones habituales de cierre.

Referencias

Qualcomm Investor Relations — anuncio oficial de la adquisición de Modular.
Techzine — detalles del valor (~$3.900M), valuación previa y enfoque en centro de datos.
ByteIota — análisis de Mojo, MAX y el posicionamiento frente a CUDA.
Modular — sitio oficial del proyecto con documentación de Mojo y MAX.

Aleph captura la vasculatura del cerebro vivo con ultrasonido: 100x sobre CT

lu1tr0n — Fri, 26 Jun 2026 14:18:34 +0000

El 24 de junio de 2026, la empresa Aleph presentó lo que describe como la imagen vascular más detallada de un cerebro humano vivo jamás captada con ultrasonido cerebral a través del cráneo intacto. El logro no necesitó taladrar el hueso ni insertar electrodos: bastaron ondas de sonido y microburbujas inyectadas en la sangre.

La promesa de fondo es una interfaz cerebro-máquina con el detalle de una resonancia magnética, pero en un formato del tamaño de un smartphone. Y esta vez, además, viene con el código y los datos abiertos.

TL;DR

Aleph publicó el 24 de junio de 2026 la imagen vascular más detallada de un cerebro humano vivo captada con ultrasonido transcraneal.- La técnica logra 100 veces más resolución volumétrica que un CT comparable, con detalle submilimétrico cercano al de una resonancia.- Se apoya en el acoplamiento neurovascular: cuando las neuronas disparan llega más sangre, y el ultrasonido mide ese flujo.- Usa microburbujas de hexafluoruro de azufre (SF6), un agente de contraste aprobado por la FDA, infundidas durante 4 minutos.- ULM supera el límite de difracción ajustando el centro de cada microburbuja con precisión sub-pixel, por debajo de la longitud de onda.- Aleph liberó como open source todo el pipeline de procesamiento y el dataset, pensando en ictus, Alzheimer y traumatismo craneal.- El siguiente objetivo es la imagen neurovascular sin contraste, con machine learning end-to-end sobre el mayor dataset del rubro.

Qué pasó

Aleph, una empresa enfocada en interfaces cerebro-máquina, anunció un hito que el campo de la neuroimagen llevaba años persiguiendo: reconstruir en tres dimensiones la red de vasos sanguíneos de un cerebro humano vivo usando únicamente ultrasonido, y hacerlo sin retirar el cráneo. En la imagen que publicaron se distinguen los vasos grandes, las arterias piales y hasta las arteriolas, las ramas más finas del árbol vascular.

Según la compañía, se trata de la primera imagen 3D de microscopía de localización por ultrasonido —ULM, por sus siglas en inglés— obtenida en un cerebro humano a través del hueso, y alcanza una resolución volumétrica cien veces mayor que la de una tomografía computarizada (CT) comparable.

El punto clave es ese «a través del cráneo». La técnica ya había dado resultados espectaculares en animales y cuando se retira una porción del hueso, porque el cráneo dispersa y atenúa el sonido de forma severa. Lograrlo con el cráneo intacto es la diferencia entre un experimento de laboratorio y algo que algún día podría usarse en una clínica o, incluso, llevarse puesto.
El volumen vascular reconstruido a través del cráneo intacto.

Contexto e historia: los dos extremos de leer el cerebro

Para entender por qué esto importa, conviene mirar cómo leemos hoy la actividad cerebral. Existen dos extremos. En uno están los electrodos invasivos: se perfora el cráneo y se insertan sensores directamente en el tejido. Dan una señal limpísima y son ideales para tareas concretas —mover un cursor, controlar un brazo robótico—, pero incluso con mil electrodos se captura, a lo sumo, el 0,001 % del cerebro. Los pensamientos, en cambio, están distribuidos por todo el órgano.

En el otro extremo está el electroencefalograma (EEG): barato, no invasivo, con buena cobertura, pero borroso. Esa falta de nitidez no se arregla agregando sensores; es física pura, por la forma en que los campos eléctricos y magnéticos se propagan a través del cráneo y el cuero cabelludo. El EEG y el MEG ven mucho, pero lo ven mal.

La resonancia magnética funcional (fMRI) resuelve ambos problemas —campo de visión amplio y buen detalle— y es la tecnología detrás de demostraciones que parecen ciencia ficción, como reconstruir la imagen que alguien está mirando a partir de su actividad cerebral. El problema es evidente: una máquina de resonancia pesa toneladas, cuesta millones y no se puede usar como un casco. El ultrasonido neurovascular promete el detalle de la resonancia en un formato infinitamente más práctico.

Cómo funciona el ultrasonido cerebral: microburbujas contra el límite de difracción

El ultrasonido cerebral de Aleph no mide directamente las neuronas, sino la sangre. Se apoya en un fenómeno bien conocido: el acoplamiento neurovascular. Cuando un grupo de neuronas se activa, el cuerpo les envía más sangre para alimentarlas. Si uno puede mapear con precisión el flujo y el volumen sanguíneo en cada rincón del cerebro, obtiene un proxy muy fino de qué zonas están trabajando.

Para mapear esa sangre se envían ondas de ultrasonido a través del cráneo; las ondas rebotan en los glóbulos rojos y en las burbujas inyectadas, y con los ecos se reconstruyen mapas de flujo. Aquí aparece el obstáculo físico central: el límite de difracción. Un equipo de ultrasonido normal no puede separar dos objetos que estén más cerca que, aproximadamente, una longitud de onda; cualquier detalle más fino colapsa en un único borrón.

💭 Clave: el límite de difracción no es un problema de hardware barato, es física. La solución no es un sensor mejor, sino un truco estadístico: localizar muchas fuentes puntuales aisladas, una por una.

La solución son las microburbujas. Si se inyectan lo bastante diluidas como para que sus borrones no se solapen, es posible estimar el centro de cada burbuja con muchísima más precisión que la propia longitud de onda. A medida que las burbujas fluyen por la vasculatura, se acumulan millones de esas posiciones y se apilan en una sola imagen con detalle más fino que la longitud de onda. Ese es el corazón de ULM.

graph LR
  A["Microburbujas SF6 (4 min)"] --> B["Ultrasonido transcraneal"]
  B --> C["Ecos crudos: TB por hora"]
  C --> D["Localización sub-pixel"]
  D --> E["Millones de centros acumulados"]
  E --> F["Mapa vascular 3D submilimétrico"]

El paso decisivo del pipeline es la localización sub-pixel. Cada microburbuja aparece como una mancha del ancho de una longitud de onda, pero su centro real está muy por debajo de ese tamaño. Ajustando una función gaussiana al perfil de la mancha se recupera el centro con precisión muy superior a la del píxel. En pseudocódigo de Python, la idea se ve así:

import numpy as np
from scipy.optimize import curve_fit

# Ajusta una gaussiana 2D al parche de eco para hallar el
# centro de la microburbuja con precisión sub-pixel.
def gaussiana_2d(coords, amp, x0, y0, sigma, base):
    x, y = coords
    g = base + amp * np.exp(-((x - x0)**2 + (y - y0)**2) / (2 * sigma**2))
    return g.ravel()

def localizar_microburbuja(parche):
    h, w = parche.shape
    y, x = np.mgrid[0:h, 0:w]
    p0 = (parche.max(), w / 2, h / 2, 1.0, parche.min())
    popt, _ = curve_fit(gaussiana_2d, (x, y), parche.ravel(), p0=p0)
    amp, x0, y0, sigma, base = popt
    return x0, y0  # centro sub-pixel del eco de la burbuja

Las burbujas en sí son bolsas de hexafluoruro de azufre (SF6) encapsuladas en una cubierta lipídica. Son un agente de contraste aprobado por la FDA, se infunden de forma continua durante unos cuatro minutos y, como el gas tiene una impedancia acústica muy distinta a la del tejido, el sonido rebota con fuerza en cada superficie. Eso refuerza la señal y, a la vez, habilita la superresolución. Enlazando el centro de cada burbuja de un fotograma al siguiente se trazan además la dirección y la velocidad del flujo sanguíneo en la microvasculatura viva.
De borrones del ancho de la onda a vasos finos: el truco de ULM.

Datos y cifras

Más allá del titular, estos son los números que sostienen el anuncio y dan escala al logro:

Resolución: 100 veces mayor en términos volumétricos que un CT comparable, con detalle submilimétrico (menos de 1 mm).- Agente de contraste: microburbujas de SF6 en cubierta lipídica, aprobadas por la FDA.- Adquisición: infusión continua durante una ventana de 4 minutos.- Datos crudos: una sonda estándar recibe terabytes por hora, pero el pipeline tradicional comprime esa señal hasta apenas el 0,1 % del original.- Cobertura teórica: la física permite registrar hasta un millón de píxeles independientes en todo el cerebro, cada uno por debajo del milímetro.- Punto de comparación: incluso 1000 electrodos invasivos cubren solo cerca del 0,001 % del cerebro.

📌 Nota: ese 0,1 % es el dato más revelador. El 99,9 % de la información acústica se descarta con filtros diseñados a mano, algo que recuerda a la visión por computadora antes del deep learning. Ahí es donde Aleph apuesta su futuro.

Impacto del ultrasonido cerebral en clínica y neurotecnología

El impacto se reparte en dos frentes. El primero es clínico e inmediato. Condiciones como el ictus, el Alzheimer o el traumatismo craneoencefálico dejan firmas vasculares a escalas que ni el CT ni la resonancia magnética alcanzan a resolver. Una imagen vascular submilimétrica y portátil podría detectar esos cambios antes y con más detalle, y como el pipeline es open source, cualquier grupo de investigación o startup médica en LATAM puede tomarlo, validarlo sobre sus propios datos y adaptarlo sin pagar licencias.

El segundo frente es la neurotecnología de largo plazo. Una interfaz cerebro-máquina de propósito general necesita dos cosas: ver una gran parte del cerebro y verla con detalle. El ultrasonido neurovascular, como la resonancia, cumple ambos requisitos, pero en un hardware que se está volviendo barato y compacto. Aquí entra la segunda tendencia que da confianza a Aleph: empresas como Butterfly han reducido los equipos de ultrasonido de más de 100.000 dólares y un carro lleno de electrónica a algo del tamaño y precio de un teléfono. Cuando el hardware deja de ser el cuello de botella, el problema se vuelve de software y datos, justo el terreno donde la comunidad de desarrolladores puede aportar.

💡 Tip: si trabajás con visión por computadora o procesamiento de señales, el dataset abierto de ultrasonido neurovascular es una oportunidad poco común para entrenar modelos sobre datos biomédicos reales sin barreras de acceso.

Qué sigue: hacia la imagen neurovascular sin contraste

Los resultados actuales dependen de las microburbujas, y ese es justamente el límite que Aleph quiere cruzar. El destino final es la imagen neurovascular sin contraste: leer el flujo sanguíneo directamente, sin inyectar nada. El reto es que los glóbulos rojos dispersan mucho menos que las microburbujas, así que la señal es más débil. Pero esa señal no se pierde: simplemente, los métodos actuales no saben extraerla.

La hipótesis de la empresa es que el machine learning end-to-end, entrenado sobre datos suficientes, recuperará mucha más señal que las técnicas hechas a mano que hoy descartan el 99,9 % de la información. Por eso afirman estar reuniendo lo que creen que es el mayor dataset de ultrasonido neurovascular del mundo. Si la apuesta funciona, el costoso truco de superresolución con contraste dejaría de ser necesario, y la imagen de alta resolución del cerebro vivo pasaría de ser un evento de laboratorio a algo cotidiano.

Para los desarrolladores de la región, la lectura es clara: este es uno de esos momentos en que un campo médico se convierte en un problema de datos y modelos. El hardware se abarata, el pipeline está abierto y el cuello de botella se desplaza al software. Las próximas mejoras no vendrán solo de físicos e ingenieros biomédicos, sino también de quienes saben entrenar modelos sobre señales ruidosas.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es el ultrasonido cerebral neurovascular?

Es una técnica que mide la actividad del cerebro de forma indirecta, mapeando el flujo y el volumen de sangre. Aprovecha el acoplamiento neurovascular: cuando las neuronas se activan, reciben más sangre, y el ultrasonido detecta ese cambio enviando ondas de sonido que rebotan en los glóbulos rojos y en microburbujas inyectadas.

¿Necesita cirugía o perforar el cráneo?

No. Ese es precisamente el avance: la imagen se obtuvo a través del cráneo intacto, sin retirar hueso ni insertar electrodos. Hasta ahora, la microscopía de localización por ultrasonido en cerebro solía requerir abrir o adelgazar el cráneo.

¿Qué son las microburbujas y son seguras?

Son pequeñas burbujas de hexafluoruro de azufre (SF6) encapsuladas en una cubierta lipídica. Funcionan como agente de contraste y ya están aprobadas por la FDA para uso clínico. Se infunden de forma continua durante unos cuatro minutos y reflejan el sonido con fuerza por su impedancia acústica.

¿En qué se diferencia de una resonancia magnética?

Ambas ofrecen amplio campo de visión y buen detalle, pero la resonancia requiere una máquina enorme y carísima. El ultrasonido neurovascular apunta al mismo nivel de detalle en un equipo del tamaño y precio de un smartphone, lo que abre la puerta a usos portátiles e incluso vestibles.

¿Para qué sirve a nivel clínico?

Condiciones como el ictus, el Alzheimer y el traumatismo craneal dejan firmas vasculares finas que el CT y la resonancia no siempre resuelven. Imágenes con resolución submilimétrica podrían ayudar a detectarlas antes y con mayor precisión.

¿Está disponible el código?

Sí. Aleph liberó como open source el pipeline completo de procesamiento junto con el dataset, con la idea de que la comunidad lo use en múltiples aplicaciones de imagen cerebral.

Referencias

Aleph — Ultrasound imaging of the brain — anuncio original del hito y descripción del pipeline (fuente primaria).- Wikipedia — Functional ultrasound imaging — fundamentos de la imagen funcional por ultrasonido y el acoplamiento neurovascular.- Wikipedia — Sulfur hexafluoride — propiedades del gas usado en las microburbujas de contraste.- Butterfly Network — ejemplo de la miniaturización y abaratamiento del hardware de ultrasonido.

Libre Barcode: fuentes open source para generar códigos de barras Code 128

lu1tr0n — Fri, 26 Jun 2026 08:20:52 +0000

Generar un código de barras escaneable suele implicar una librería que produce una imagen o un SVG, y a veces hasta un servicio aparte. Libre Barcode propone algo distinto y elegante: que el código de barras sea, literalmente, una fuente tipográfica. Escribís un texto, le aplicás la fuente y el resultado se puede leer con cualquier lector.

El proyecto, mantenido por Lasse Fister bajo la licencia SIL Open Font License, cubre los tres estándares más usados —Code 39, Code 128 y EAN/UPC— y resuelve la parte difícil (checksums incluidos) con un encoder en el navegador. Veamos cómo funciona y cómo integrarlo en tus proyectos.

TL;DR

Libre Barcode es una familia de fuentes open source (licencia SIL OFL) que dibuja códigos de barras escaneables a partir de texto.- Soporta tres estándares: Code 39, Code 128 y EAN/UPC, con y sin texto legible debajo de las barras.- Code 39 se escribe directo: basta envolver el texto entre asteriscos (PROGRAMACION) y aplicar la fuente.- Code 128 es más compacto pero exige un encoder que calcule el checksum y los códigos de inicio/parada.- Está disponible en Google Fonts, GitHub y como paquete npm, así que se integra con un @import de CSS.- No necesita librerías de generación de imágenes ni servidores: el render ocurre en el motor de fuentes del navegador.- Ideal para etiquetas, entradas, inventario y prototipos; para impresión crítica conviene validar DPI y quiet zone.

Qué es Libre Barcode

Libre Barcode es un conjunto de fuentes OpenType pensadas para una sola tarea: transformar texto en barras que un escáner puede interpretar. En lugar de calcular píxeles, el proyecto delega el dibujo en el motor de fuentes del sistema operativo o del navegador, el mismo que renderiza cualquier letra que estás leyendo ahora. La diferencia es que sus glifos no son letras: son las franjas negras y blancas que componen un símbolo de código de barras.

Esta idea tiene una ventaja enorme para desarrolladores. No hay que instalar generadores de imágenes, no hay dependencias binarias que compilar, ni un endpoint que devuelva un PNG. Una fuente pesa pocas decenas de kilobytes, se cachea como cualquier recurso estático y el render es vectorial, así que escala sin perder nitidez. Para LATAM, donde muchos equipos despliegan en hosting compartido o en planes gratuitos con recursos limitados, eliminar una librería pesada del lado del servidor es una ganancia concreta.

El proyecto se publica bajo la SIL Open Font License, la misma que usan fuentes como Roboto o Source Sans. Eso significa que podés usarla en proyectos comerciales, redistribuirla e incluso modificarla, siempre que respetes las condiciones de la licencia (básicamente, no vender la fuente por separado y conservar el aviso de licencia).
Las barras son glifos de una fuente, no una imagen generada.

Los tres formatos: Code 39, Code 128 y EAN/UPC

No todos los códigos de barras son iguales. Cada estándar tiene un propósito, un conjunto de caracteres soportados y reglas de validación propias. Libre Barcode cubre los tres más habituales y, en varias variantes, ofrece versiones con el texto legible impreso debajo de las barras (las que terminan en Text).

Code 39 — El más simple. Codifica letras mayúsculas (A-Z), dígitos (0-9) y unos pocos símbolos. No requiere checksum obligatorio y delimita el contenido con asteriscos. Es perfecto para inventario interno, etiquetas de almacén y prototipos rápidos.- Code 128 — Mucho más denso y capaz de codificar todo el ASCII. A cambio, exige un dígito de control (checksum) y códigos de inicio y parada. Es el estándar para logística, paquetería y etiquetas de envío.- EAN/UPC — El código de los productos de supermercado. EAN-13 maneja 13 dígitos con un dígito verificador final. Su estructura es fija, pensada para puntos de venta.

💡 Tip: Si solo necesitás algo que funcione hoy para inventario interno, empezá con Code 39. Al no requerir checksum, lo escribís a mano y lo ves funcionar en segundos.

Cómo funciona Libre Barcode: tipografía que se vuelve barras

La magia detrás de Libre Barcode está en las características de OpenType. Una fuente moderna no se limita a mapear un carácter a un glifo: puede aplicar ligaduras, alternativas contextuales y sustituciones. Estas fuentes aprovechan ese mecanismo para que cada carácter o secuencia de caracteres se reemplace por el patrón exacto de barras anchas y angostas que define el estándar.

En Code 39 la relación es casi uno a uno: cada letra o dígito tiene su propio glifo de barras, y los asteriscos de apertura y cierre le dicen al lector dónde empieza y termina el símbolo. Por eso podés escribir el texto directamente. En Code 128 el proceso tiene un paso extra: antes de aplicar la fuente, hay que pasar el texto por un encoder que añade el código de inicio, calcula el checksum y agrega el código de parada. El sitio oficial incluye ese encoder funcionando en el navegador.

graph LR
A["Texto: PROGRAMACION"] --> B{"Estandar?"}
B -->|"Code 39"| C["Envolver en *...*"]
B -->|"Code 128"| D["Encoder + checksum"]
C --> E["Aplicar fuente Libre Barcode"]
D --> E
E --> F["Codigo de barras escaneable"]

Lo interesante de este enfoque es que separa la lógica (qué dice el código) de la presentación (cómo se dibuja). El navegador, que ya sabe renderizar fuentes con precisión subpíxel, se encarga del trabajo pesado. El desarrollador solo prepara la cadena correcta.

Manos a la obra: usar Libre Barcode en la web

La forma más rápida de probar Libre Barcode es a través de Google Fonts, que aloja toda la familia. Importás la fuente con una línea de CSS y la aplicás como cualquier otra. Para Code 39, además, escribís el texto entre asteriscos:

/* CSS */
@import url('https://fonts.googleapis.com/css2?family=Libre+Barcode+39+Text&display=swap');

.codigo-39 {
  font-family: 'Libre Barcode 39 Text', cursive;
  font-size: 48px;
}


*PROGRAMACION*

Ese span se renderiza como un código de barras escaneable. Si lo apuntás con la cámara de un lector o una app de escaneo, devolverá PROGRAMACION. La variante 39 Text imprime además el texto legible debajo de las barras; si querés solo las barras, usá Libre Barcode 39 a secas.

⚠️ Ojo: Con Code 128 no podés escribir el texto crudo y esperar que escanee. Necesitás pasarlo primero por el encoder para que incluya el checksum y los códigos de control. Sin ese paso, el símbolo será inválido.
Integrar la fuente toma una sola línea de @import.

El encoder de Code 128 y el checksum

El corazón técnico de Code 128 es su dígito de control. Cada símbolo del estándar tiene un valor numérico, y el checksum se calcula con una suma ponderada por posición, módulo 103. El encoder de Libre Barcode hace esto por vos en la web, pero entender el cálculo te permite generar códigos en el backend sin depender del navegador.

Veamos una implementación didáctica del checksum para Code 128 en su variante Code Set B (el conjunto que cubre ASCII imprimible), en Python:

# Python: checksum de Code 128 (Code Set B)
def code128b_checksum(texto: str) -> int:
    START_B = 104  # valor del codigo de inicio B
    # En Code Set B, cada caracter imprimible vale (ASCII - 32)
    valores = [ord(c) - 32 for c in texto]
    suma = START_B + sum((i + 1) * v for i, v in enumerate(valores))
    return suma % 103

# Ejemplo
print(code128b_checksum("PROG-2026"))  # imprime el valor de control

Con ese valor de control y los caracteres de inicio y parada, se arma la secuencia final de glifos que la fuente Libre Barcode 128 renderiza como barras. El encoder oficial encapsula toda esta lógica: pegás tu texto, copiás la cadena codificada y la usás con la fuente. Para producción a escala, replicar este algoritmo en el servidor evita render del lado cliente y permite, por ejemplo, generar miles de etiquetas en un job batch.

📌 Nota: El módulo 103 no es arbitrario: Code 128 define exactamente 103 símbolos de datos más los códigos de control. El checksum existe para que un escáner detecte lecturas corruptas antes de aceptar el dato.

Instalación local en Windows, macOS y Linux

Si preferís no depender del CDN de Google Fonts —por privacidad, por trabajar offline o por empaquetar la fuente en una app de escritorio— podés instalar los archivos TTF localmente. Descargá las fuentes desde el repositorio de GitHub o desde Google Fonts y seguí el procedimiento según tu sistema:

Windows — Doble clic en el archivo .ttf y pulsá Instalar, o copiá el archivo a C:\Windows\Fonts.- macOS — Doble clic en el .ttf para abrir Font Book y pulsá Instalar fuente.- Linux — Copiá los archivos a la carpeta de fuentes del usuario y actualizá la caché.

# Linux: instalar la fuente para el usuario actual
mkdir -p ~/.local/share/fonts
cp LibreBarcode128Text-Regular.ttf ~/.local/share/fonts/
fc-cache -f -v

Para proyectos web con bundler (Vite, webpack, etc.), también existe el paquete de Fontsource, que instala la fuente como dependencia npm y la sirve desde tu propio dominio:

# Cualquier SO: instalar via npm / pnpm / yarn
npm install @fontsource/libre-barcode-128-text
# luego en tu codigo:
# import '@fontsource/libre-barcode-128-text';

Casos de uso e implicaciones

El enfoque de Libre Barcode brilla cuando necesitás códigos de barras dinámicos sin sobrecargar la infraestructura. Algunos escenarios concretos: entradas para eventos con un identificador único por asistente, etiquetas de inventario impresas desde un panel web, comprobantes con número de seguimiento, o tableros internos donde cada fila muestra su propio código escaneable. Como el render es nativo del navegador, imprimir desde el propio HTML produce barras vectoriales nítidas.

Para equipos pequeños y startups de la región, la implicación es de costos y simplicidad. Eliminás una dependencia, reducís la superficie de mantenimiento y evitás llamadas a servicios externos que pueden caerse o cambiar de precio. Y al ser una fuente, funciona en cualquier contexto que sepa renderizar texto: PDF generados con motores que embeben fuentes, apps de escritorio con Electron, o documentos exportados desde un editor.

Limitaciones y cuándo no usarlo

No todo es ideal. La precisión de impresión depende del DPI y del tamaño de fuente: si las barras quedan demasiado pequeñas o el papel es de baja calidad, un escáner puede fallar. Conviene siempre dejar una quiet zone (margen blanco) alrededor del símbolo, algo que el estándar exige y que la fuente por sí sola no garantiza. Para aplicaciones críticas —retail con miles de lecturas diarias, farmacéutica, logística regulada— vale la pena probar con varios lectores físicos antes de producción.

Tampoco cubre formatos 2D como QR o Data Matrix, que requieren un enfoque distinto (matrices de módulos, no barras lineales). Y aunque EAN/UPC está soportado, generar un EAN-13 válido implica respetar su estructura de dígitos y el verificador; no basta con escribir trece números cualquiera. Para esos casos, calcular el dígito de control correctamente sigue siendo responsabilidad de tu código.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Los códigos de barras de Libre Barcode realmente se escanean?

Sí. Como las fuentes reproducen los patrones de barras definidos por cada estándar, cualquier lector compatible con Code 39, Code 128 o EAN/UPC los interpreta correctamente, siempre que el tamaño y la impresión sean adecuados.

¿Necesito una librería de JavaScript para usarlas?

No para Code 39: se escribe el texto entre asteriscos y se aplica la fuente. Para Code 128 sí hace falta un paso de codificación (el encoder oficial o tu propia función de checksum), pero el render final no requiere librería alguna.

¿Puedo usar Libre Barcode en un proyecto comercial?

Sí. Está publicada bajo la licencia SIL Open Font License, que permite uso comercial, redistribución y modificación, conservando el aviso de licencia y sin vender la fuente por separado.

¿Qué diferencia hay entre Code 39 y Code 128?

Code 39 es simple y no exige checksum, pero ocupa más espacio y solo cubre un conjunto reducido de caracteres. Code 128 es más compacto, soporta todo el ASCII y requiere un dígito de control, lo que lo hace el estándar preferido en logística.

¿Sirve para generar códigos QR?

No. Libre Barcode genera códigos lineales (1D). Los QR y Data Matrix son códigos 2D con una estructura de matriz totalmente distinta que no se puede representar con una fuente de barras.

¿Dónde calculo el dígito verificador de un EAN-13?

El dígito verificador de EAN-13 sigue un algoritmo de suma ponderada propio; conviene calcularlo en tu backend antes de pasar la cadena a la fuente. La fuente dibuja las barras, pero no valida que el dígito sea correcto.

Referencias

Libre Barcode Project — sitio oficial con el encoder de Code 128 y las instrucciones de uso.- graphicore/librebarcode (GitHub) — código fuente, archivos de fuente y licencia del proyecto.- Libre Barcode en Google Fonts — todas las variantes alojadas para importar vía CSS.- Code 128 (Wikipedia) — especificación del estándar, conjuntos de caracteres y cálculo del checksum.- Code 39 (Wikipedia) — estructura y caracteres soportados del estándar más simple.

Vesuvius Challenge lee un papiro de Herculano entero sin abrirlo

lu1tr0n — Thu, 25 Jun 2026 20:18:30 +0000

Por primera vez en casi 2.000 años, un papiro de Herculano fue leído de principio a fin sin abrirlo. El equipo del Vesuvius Challenge anunció el 25 de junio de 2026 que logró desenrollar virtualmente el PHerc. 1667, un rollo carbonizado por la erupción del Vesubio en el año 79 d.C., combinando rayos X de alta resolución con aprendizaje automático.

Es el primer rollo completo de esa biblioteca antigua recuperado en su totalidad y puesto a disposición de los académicos para un estudio sostenido.

TL;DR

El Vesuvius Challenge leyó completo el papiro PHerc. 1667, sellado desde la erupción del Vesubio en el año 79 d.C., sin abrirlo físicamente.
Es el primer rollo de Herculano desenrollado virtualmente y leído de principio a fin: cerca de 1,4 m de papiro y unas 22 columnas de griego.
El texto es un tratado estoico de ética del siglo II a.C. que menciona a Aristocreón, sobrino del filósofo Crisipo.
Se escaneó con microtomografía de rayos X por contraste de fase en la línea BM18 del sincrotrón ESRF en Grenoble.
Un modelo de aprendizaje automático resalta los rastros de tinta invisibles al ojo humano sobre la superficie aplanada.
En un segundo rollo (PHerc. Paris 4) la tinta ya es visible en 3D y coincide 1 a 1 con la lectura premiada en 2023.
En un tercero (PHerc. 139) se recuperó el título y el autor: Filodemo, «Sobre los dioses», libro 8.
Los datos y el código son abiertos: scrollprize.org/data y el repositorio ScrollPrize/villa, con licencia MIT.

Qué pasó: un papiro de Herculano leído entero

Durante casi dos milenios, la biblioteca carbonizada de Herculano guardó un trato cruel: sus rollos sobrevivieron a la erupción del Vesubio, pero solo porque quedaron demasiado frágiles para abrirlos. Leer uno equivalía a destruirlo. El 25 de junio de 2026 ese trato se rompió. El Vesuvius Challenge —el concurso abierto que desde 2023 financia premios para descifrar estos rollos— anunció la lectura completa del PHerc. 1667, conocido en la comunidad como «Scroll 4».

A diferencia de los intentos anteriores, nadie desenrolló el papiro de Herculano físicamente. El rollo se escaneó con rayos X, se reconstruyó la hoja enrollada en su interior, se aplanó hasta convertirla en una superficie legible y un modelo de aprendizaje automático resaltó los tenues rastros de tinta antigua. El resultado: unas 22 columnas de griego, alrededor de 1,4 metros de papiro, transcritas y revisadas por papirólogos.

Lo que sobrevive del PHerc. 1667 es apenas el núcleo interno y compacto del rollo. Intentos de abrirlo a mano en el siglo XIX, y de nuevo en 1969 y en los años 80, destruyeron sus capas externas y dejaron unos 8 cm de una altura original de 19 a 24 cm. De esa porción se recuperó el texto por completo, en lugar de palabras sueltas o parches aislados como en lecturas previas.

💭 Clave: Varias frases pueden leerse con claridad por primera vez en dos mil años. Una de ellas dice: «...indagaremos algo, pero no lo alcanzaremos, si de algún modo nos apartamos de nosotros mismos y de nuestra propia naturaleza...».

Del objeto sellado al texto: el rollo, el corte tomográfico y la hoja desenrollada.

La biblioteca que sobrevivió al Vesubio

Herculano alberga la única biblioteca de la Antigüedad que se conserva entera. En la llamada Villa de los Papiros se hallaron más de 1.800 rollos, descubiertos por casualidad en 1752 durante las excavaciones borbónicas. La ceniza ardiente del Vesubio los carbonizó, pero también los conservó: en vez de pudrirse, se convirtieron en cilindros negros y quebradizos, imposibles de manipular sin romperlos.

Durante siglos, leerlos fue sinónimo de sacrificarlos. El padre Antonio Piaggio inventó hacia 1756 una máquina mecánica que separaba las capas milímetro a milímetro, una técnica lenta y destructiva. Muchos rollos quedaron reducidos a fragmentos. La colección guarda obras del filósofo epicúreo Filodemo de Gádara y referencias a Epicuro y a Crisipo, lo que la convierte en una fuente irreemplazable de filosofía helenística perdida.

El Vesuvius Challenge nació en 2023 con una idea distinta: en lugar de abrir los rollos, escanearlos en 3D y resolver la lectura como un problema de visión por computadora, con premios que superaron los 700.000 dólares para incentivar a la comunidad. En 2024 se leyeron las primeras palabras; ahora, por primera vez, un rollo entero.

Cómo se desenrolla un papiro de Herculano sin tocarlo

El proceso encadena física de partículas, geometría computacional y aprendizaje profundo. Los escaneos se obtuvieron con microtomografía de rayos X por contraste de fase en la línea BM18 del European Synchrotron Radiation Facility (ESRF) en Grenoble, un instrumento capaz de resolver las capas finísimas y densamente apretadas de un rollo de Herculano. El trabajo se hizo en colaboración con la Biblioteca Nacional de Nápoles «Vittorio Emanuele III», que custodia los papiros.

graph LR
  A["Rollo carbonizado"] --> B["Escaneo rayos X (sincrotron)"]
  B --> C["Reconstruccion 3D del volumen"]
  C --> D["Segmentacion de la hoja"]
  D --> E["Aplanado a superficie 2D"]
  E --> F["Modelo ML detecta tinta"]
  F --> G["Texto griego legible"]

El reto central es que la tinta antigua, hecha de carbón, tiene casi la misma densidad que el papiro carbonizado: a los rayos X, letra y soporte se parecen demasiado. Por eso el contraste de fase y la mayor resolución son decisivos, y por eso entra el aprendizaje automático: un modelo aprende a distinguir la textura sutil que deja la tinta sobre la fibra y la proyecta de vuelta sobre la página aplanada.

💡 Tip: Si querés explorar el proyecto, todo el código es abierto. Cloná el repositorio en cualquier sistema operativo:

# Linux / macOS
git clone https://github.com/ScrollPrize/villa.git
cd villa

# Windows (PowerShell)
git clone https://github.com/ScrollPrize/villa.git
Set-Location villa

La tinta segmentada en 3D y proyectada sobre la página desenrollada.

Tres rollos, tres hitos

El anuncio no se limita a un solo rollo: establece un método que resiste verificaciones independientes y escala a otros papiros.

PHerc. 1667: leído completo

El texto recuperado es un tratado filosófico de ética y la evidencia apunta a una obra estoica: gira en torno a la naturaleza humana, el impulso y el progreso moral. Su última columna conservada nombra a Aristocreón —sobrino y discípulo del gran estoico Crisipo—, lo que, junto con el lenguaje y los temas, lo sitúa en contexto estoico y lo data en el siglo II a.C. Por el daño del papiro, las lecturas son fragmentarias, con huecos donde la superficie se perdió.

PHerc. Paris 4: la tinta se vuelve visible

En un segundo rollo, conocido como «Scroll 1», una técnica de imagen de mayor resolución hace que la tinta sea directamente visible dentro del propio escaneo de rayos X en 3D, por primera vez. Segmentada en tres dimensiones y proyectada sobre la página, esa tinta coincide uno a uno con el texto leído en el Gran Premio de 2023: una confirmación independiente, con mejores datos, de que la lectura es real.

PHerc. 139: un título y un autor

En un tercer rollo se recuperaron el título y la atribución de autoría: la obra se identifica como Filodemo, «Sobre los dioses», libro 8. Leer el título de un rollo cerrado le dice a los académicos qué contiene antes de estudiar una sola columna de su cuerpo.

Por qué importa para quien programa

Más allá de la arqueología, este es un caso de manual sobre cómo el aprendizaje automático ataca un problema de señal débil. La detección de tinta se plantea como una tarea de segmentación: a partir de pequeños parches del volumen tomográfico, un modelo predice la probabilidad de que cada punto de la superficie aplanada contenga tinta. El esquema conceptual es sencillo, aunque la implementación real es exigente:

# Idea conceptual del detector de tinta (no es el codigo oficial)
import numpy as np

def detectar_tinta(volumen_3d, modelo, umbral=0.5):
    # 1. La hoja de papiro ya fue segmentada y aplanada
    superficie = aplanar(volumen_3d)        # (alto, ancho, profundidad)
    # 2. El modelo recibe parches volumetricos y predice tinta
    probabilidades = modelo.predict(superficie)
    # 3. Se umbraliza la senal debil para obtener el mapa de tinta
    mapa_tinta = probabilidades > umbral
    return mapa_tinta

Lo valioso para la comunidad técnica de LATAM es que todo es reproducible y abierto: los escaneos están en scrollprize.org/data y el código en GitHub bajo licencia MIT. No hace falta un sincrotrón para participar; con los datos publicados se puede entrenar modelos, mejorar la segmentación o validar lecturas. Es ciencia ciudadana de alto nivel donde un buen pipeline de visión por computadora vale tanto como un doctorado en papirología.

También es una lección sobre verificación: la coincidencia 1 a 1 entre la lectura de 2023 y la nueva segmentación 3D del PHerc. Paris 4 funciona como un test de regresión. Si dos métodos independientes, con datos distintos, llegan al mismo texto, la confianza en el resultado deja de depender de la fe en un único modelo.

Qué sigue

El verdadero salto no es un rollo, sino un método que escala. Con la tinta ahora visible directamente en los escaneos de mayor resolución, el cuello de botella se desplaza de «¿hay señal?» a «¿cuántos rollos podemos procesar?». Cientos de papiros siguen sellados, y leer sus títulos primero —como en el PHerc. 139— permitiría priorizar cuáles desenrollar virtualmente.

El equipo publicó un preprint con la transcripción columna por columna y mantiene una comunidad activa en torno al repositorio. La hoja de ruta apunta a automatizar más la segmentación, reducir el tiempo de cómputo y recuperar capas externas que hoy se pierden. Si el ritmo se sostiene, en los próximos años podríamos pasar de leer un rollo a leer una biblioteca entera.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es el PHerc. 1667?

Es un papiro de Herculano carbonizado por la erupción del Vesubio en el año 79 d.C., conocido en la comunidad del Vesuvius Challenge como «Scroll 4». Es el primer rollo de esa biblioteca leído por completo de principio a fin sin abrirlo físicamente.

¿Cómo se lee un rollo sin desenrollarlo?

Se escanea con microtomografía de rayos X por contraste de fase en un sincrotrón, se reconstruye la hoja enrollada en 3D, se aplana digitalmente a una superficie 2D y un modelo de aprendizaje automático resalta los rastros de tinta que son casi invisibles para el ojo humano.

¿De qué trata el texto recuperado?

Es un tratado de ética que la evidencia sitúa en contexto estoico, datado en el siglo II a.C. Habla de la naturaleza humana, el impulso y el progreso moral, y menciona a Aristocreón, sobrino del filósofo Crisipo.

¿Los datos y el código están disponibles?

Sí. Los escaneos y datos se publican en scrollprize.org/data y el código del proyecto está en el repositorio ScrollPrize/villa de GitHub bajo licencia MIT, además de un preprint con la transcripción completa.

¿Por qué importa para la informática y no solo para la historia?

Porque es un problema real de visión por computadora con señal débil: segmentación volumétrica, detección de tinta y validación cruzada entre métodos independientes. Cualquier persona con conocimientos de machine learning puede contribuir usando los datos abiertos.

Referencias

Vesuvius Challenge — anuncio oficial y detalles de la lectura del PHerc. 1667.
scrollprize.org/data — escaneos y datos abiertos de los rollos de Herculano.
ScrollPrize/villa (GitHub) — código del proyecto bajo licencia MIT.
Wikipedia: Herculaneum papyri — contexto histórico de la biblioteca de la Villa de los Papiros.

LuaJIT 3.0: Mike Pall abre el issue #1475 para las extensiones de sintaxis

lu1tr0n — Thu, 25 Jun 2026 02:18:42 +0000

El 22 de junio de 2026, Mike Pall —creador de LuaJIT— abrió el issue #1475 en GitHub como punto central para discutir las extensiones de sintaxis que llegarán con LuaJIT 3.0. No es un changelog ni una propuesta cerrada: es un hub donde la documentación del lenguaje extendido se irá consolidando y donde la comunidad puede debatir diseño y semántica.

La decisión importa porque LuaJIT mueve desde motores de videojuegos hasta OpenResty (el corazón de muchos balanceadores y APIs) y firmware embebido. Cualquier cambio en la sintaxis toca millones de líneas que hoy corren en producción.

TL;DR

El 22 de junio de 2026, Mike Pall abrió el issue #1475 en GitHub como hub de las extensiones de sintaxis de LuaJIT 3.0.- Cada propuesta debe cumplir cinco criterios: utilidad, estar probada, sin ambigüedades, sin rupturas y compatible con herramientas.- Pall descartó copiar la complejidad de Perl, Ruby, C++ o Rust; prioriza la conformidad con C, Lua y JavaScript.- Los issues relacionados #63 y #1379 se cerraron y se consolidan en el #1475.- LuaJIT ya incluye enteros de 64 bits con sufijo LL/ULL, FFI y la biblioteca bit fuera del estándar de Lua.- La documentación del lenguaje extendido se consolidará en el primer comentario del issue, etiquetada por versión.- No hay fecha de lanzamiento anunciada para LuaJIT 3.0.

Qué pasó: un hub para la sintaxis de LuaJIT 3.0

Mike Pall publicó el issue #1475 bajo las etiquetas 3.0, documentation y enhancement. En el cuerpo lo describe como un umbrella issue: un punto de encuentro donde la documentación del lenguaje extendido se redactará y actualizará en el primer comentario, y donde la comunidad puede debatir la elección, el diseño y la semántica de cada extensión. No es un anuncio de funcionalidades terminadas; es el lugar donde se decide qué entra y qué no.

Pall fue explícito con el tono que espera. Como las preferencias de sintaxis son en gran medida subjetivas, pidió que la retroalimentación se mantenga constructiva y que, si una propuesta se rechaza, se respete la decisión. También pidió evitar el clásico bike-shedding: discusiones interminables sobre la elección cosmética de símbolos para operadores de casos extremos. El foco, dijo, debe estar en la funcionalidad.

Otro detalle de gestión: los issues relacionados #63 y #1379 se cerraron en favor del #1475. La intención es dejar de tener documentación dispersa por todos lados y producir una referencia consolidada y autónoma del lenguaje completo, con cada extensión etiquetada según la versión en la que apareció por primera vez.
LuaJIT impulsa OpenResty, videojuegos y sistemas embebidos.

Contexto e historia: quién es Mike Pall y por qué LuaJIT importa

LuaJIT es una implementación de Lua con un compilador just-in-time escrito casi en su totalidad por Mike Pall, un desarrollador conocido por la calidad de ingeniería de su código. Durante años, LuaJIT fue referencia obligada cuando se hablaba de rendimiento en lenguajes dinámicos: su JIT traza rutas de ejecución calientes y genera código máquina competitivo con C en muchos benchmarks. Esa reputación explica por qué cada movimiento en su rama de desarrollo genera atención.

El estándar de referencia es Lua, mantenido por la PUC-Rio en Brasil, hoy en su versión 5.4. LuaJIT, sin embargo, nunca siguió ciegamente esa línea: se mantuvo cerca de Lua 5.1 con una larga lista de extensiones propias, retroportes selectivos de versiones más nuevas y bibliotecas exclusivas. Esa divergencia es precisamente la que el issue #1475 busca documentar de forma ordenada de cara a LuaJIT 3.0.

Para la comunidad hispana esto no es trivia académica. En LATAM, LuaJIT aparece en stacks de telecomunicaciones que usan OpenResty/NGINX, en estudios de videojuegos que embeben Lua como lenguaje de scripting, y en proyectos de IoT donde el tamaño y la velocidad del intérprete son críticos. Cualquiera que mantenga uno de esos sistemas querrá saber qué sintaxis nueva tendrá que aprender —y qué seguirá funcionando sin tocar una línea.

Datos y cifras: los cinco criterios que filtran cada propuesta

El núcleo del anuncio son las reglas. Pall enumeró que solo se agregarán extensiones de sintaxis que cumplan, en conjunto, cinco condiciones. Cada propuesta debe: (1) mejorar la calidad de vida del desarrollador; (2) estar probada, ya sea en otros lenguajes o en dialectos de Lua; (3) no crear ambigüedades sintácticas; (4) no romper la compatibilidad hacia atrás; y (5) no dificultar la vida de quienes construyen herramientas, como formateadores de sintaxis o servidores LSP.

graph TD
  P["Propuesta de sintaxis"] --> C1{"¿Mejora la calidad de vida?"}
  C1 -->|No| R["Rechazada"]
  C1 -->|Sí| C2{"¿Probada en otros lenguajes?"}
  C2 -->|No| R
  C2 -->|Sí| C3{"¿Sin ambigüedades ni rupturas?"}
  C3 -->|No| R
  C3 -->|Sí| A["Aceptada en LuaJIT 3.0"]

El criterio de compatibilidad es el más significativo en términos prácticos. Significa que el código LuaJIT existente debería seguir compilando y ejecutándose igual tras la actualización. Las extensiones son aditivas: amplían lo que el lenguaje acepta, no redefinen lo que ya hace. Para equipos con bases de código grandes, esa garantía vale más que cualquier azúcar sintáctica nueva.

💭 Clave: Pall dejó claro que algunas elecciones sintácticas ya las tomaron otros (C, Lua, JavaScript) y que no está contento con todas, pero que hay valor en la conformidad y la compatibilidad. La consistencia con lo conocido pesa más que la elegancia teórica.
Toda propuesta pasa por un filtro de cinco criterios antes de entrar.

Qué extensiones ya trae LuaJIT hoy

Para entender hacia dónde va LuaJIT 3.0 conviene ver de dónde parte. LuaJIT lleva años acumulando extensiones que no existen en el Lua estándar. Estas son algunas de las más usadas, que el issue #1475 también busca documentar de forma unificada:

-- Enteros de 64 bits nativos (extensión de LuaJIT)
local grande = 9223372036854775807LL   -- int64 con sufijo LL
local mascara = 0xFFFFULL               -- uint64 con sufijo ULL

-- FFI: llamar a C sin escribir bindings a mano
local ffi = require('ffi')
ffi.cdef[[
  int printf(const char *fmt, ...);
]]
ffi.C.printf('Hola desde C\n')

-- Operaciones de bits (biblioteca bit)
local bit = require('bit')
print(bit.bor(0x10, 0x01))   -- 17

A esto se suman utilidades como table.new y table.clear para preasignar y reusar tablas sin presionar al recolector de basura, el módulo string.buffer para construir cadenas de forma eficiente, y la biblioteca jit.* para inspeccionar y controlar el compilador. Ninguna de estas existe en Lua puro, y todas son parte del «dialecto LuaJIT» que el nuevo issue quiere describir en un solo lugar.

Impacto y análisis: qué proponen otros dialectos de Lua

El segundo criterio —que una extensión esté «probada»— apunta directamente al ecosistema de dialectos que creció alrededor de Lua. Luau, el dialecto de Roblox, agregó tipos opcionales, asignación compuesta y la sentencia continue. Teal incorporó un sistema de tipos estáticos. MoonScript reimaginó la sintaxis por completo. Estos proyectos funcionan como laboratorio: muestran qué ideas sobreviven al uso real antes de que LuaJIT las considere.

Un ejemplo recurrente en la comunidad son los operadores de asignación compuesta y el continue, ausentes en Lua estándar y presentes en varios dialectos:

-- Patrones que dialectos como Luau ya soportan
-- (NO confirmados para LuaJIT 3.0; sirven de referencia)
x += 1            -- asignación compuesta

local pares = {}
for i = 1, 10 do
  if i % 2 ~= 0 then continue end  -- 'continue' salta a la siguiente vuelta
  table.insert(pares, i)
end

⚠️ Ojo: Estos ejemplos ilustran qué se ha probado en otros dialectos, no qué entrará en LuaJIT 3.0. El issue #1475 es un espacio de discusión: nada está confirmado hasta que Pall lo documente y lo etiquete con su número de versión.

Para desarrolladores en LATAM, la lectura estratégica es doble. Por un lado, conviene seguir el issue para anticipar qué patrones podrían volverse idiomáticos. Por otro, el énfasis en herramientas (formateadores, LSP) sugiere que quienes mantienen plugins de editor, linters o pipelines de CI para Lua tendrán trabajo: cada extensión nueva debe reflejarse en esas herramientas para que el ecosistema no se fragmente.

Qué sigue

El issue permanecerá abierto como foro de diseño. La documentación viva crecerá en el primer comentario y, según Pall, terminará fusionándose en una referencia independiente del lenguaje completo. No hay fecha de lanzamiento pública para LuaJIT 3.0, ni una lista cerrada de extensiones aprobadas: el proceso es deliberadamente incremental y abierto a la crítica constructiva.

Lo más sensato para los equipos es no reescribir nada hoy. La promesa de compatibilidad hacia atrás significa que el código actual seguirá funcionando. Conviene, eso sí, suscribirse al hilo, revisar los dialectos que sirven de inspiración y preparar las herramientas internas para soportar sintaxis aditiva cuando llegue. La discusión sobre la sintaxis de LuaJIT 3.0 apenas comienza, y participar de forma temprana es la mejor manera de influir en ella.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es LuaJIT 3.0?

Es la próxima rama mayor de LuaJIT, el compilador just-in-time de Lua creado por Mike Pall. El issue #1475 centraliza la discusión y la documentación de las extensiones de sintaxis que incorporará.

¿LuaJIT 3.0 romperá mi código actual?

Según el criterio declarado por Pall, no. Las extensiones deben ser aditivas y no romper la compatibilidad hacia atrás, así que el código LuaJIT existente debería seguir compilando y ejecutándose sin cambios.

¿Qué diferencia a LuaJIT del Lua estándar?

LuaJIT añade un compilador JIT y extensiones propias: enteros de 64 bits con sufijo LL/ULL, la biblioteca FFI para llamar a C, el módulo bit, string.buffer y utilidades como table.new. Nada de eso existe en el Lua de referencia.

¿Dónde puedo proponer una extensión de sintaxis?

En el propio issue #1475 de GitHub. Pall pide que la discusión sea constructiva, se centre en la funcionalidad y evite debates cosméticos prolongados sobre la elección de símbolos.

¿LuaJIT 3.0 tendrá tipos estáticos?

No está confirmado. Dialectos como Teal y Luau sí ofrecen tipos, lo que cumple el criterio de «estar probado», pero el issue no garantiza ninguna extensión concreta hasta que se documente oficialmente.

¿Cuándo sale LuaJIT 3.0?

No hay fecha de lanzamiento anunciada. El issue #1475 es un proceso de diseño abierto e incremental, no un anuncio de versión con calendario.

Referencias

Issue #1475 en GitHub — el hub oficial de las extensiones de sintaxis de LuaJIT 3.0.- LuaJIT — Extensions — documentación oficial de las extensiones ya presentes en LuaJIT.- Repositorio LuaJIT en GitHub — código fuente y seguimiento de issues del proyecto.- Manual de referencia de Lua 5.4 — base del lenguaje sobre la que se construye LuaJIT.

Nessus Agent 11.1.3 corrige un fallo que daba SYSTEM en Windows

lu1tr0n — Wed, 24 Jun 2026 16:08:47 +0000

Tenable, la empresa detrás del popular escáner de vulnerabilidades Nessus, corrigió un fallo de alta gravedad en su Nessus Agent para Windows que permitía a un atacante local escalar privilegios hasta NT AUTHORITY\SYSTEM, el nivel más alto del sistema operativo. La ironía es difícil de ignorar: la herramienta diseñada para encontrar y reportar vulnerabilidades se convirtió, ella misma, en la vía de escalada.

El fallo, identificado como CVE-2026-33694, fue resuelto en la versión 11.1.3 del agente. No es un desbordamiento de memoria exótico, sino un patrón clásico de Windows: el abuso de junctions para engañar a un proceso privilegiado y hacerle borrar archivos que no debería tocar.

TL;DR

Tenable corrigió CVE-2026-33694 en Nessus Agent para Windows, una escalada de privilegios local a SYSTEM.- El fallo es un caso de 'link following' (CWE-59): un usuario crea una junction que engaña al agente.- El agente, que corre como SYSTEM, borra archivos arbitrarios siguiendo el enlace manipulado.- CVSSv3 base 8.2 (alto); CVSSv4 7.4. Vector local, baja complejidad, pocos privilegios previos.- Versiones afectadas: Nessus Agent 11.1.2 y anteriores. Corregido en 11.1.3.- Cronología: reportado el 29 dic 2025, aceptado el 18 feb 2026, parche el 23 abr 2026.- El irónico riesgo: la herramienta que escanea vulnerabilidades se volvió la vía de escalada.

Qué pasó

El 23 de abril de 2026, Tenable publicó el aviso de seguridad TNS-2026-12 y liberó Nessus Agent 11.1.3. El aviso describe una vulnerabilidad de improper link resolution before file access, catalogada bajo CWE-59 ("Link Following"). En cristiano: el agente, al hacer su trabajo normal, accede y elimina ciertos archivos en disco, y un atacante local puede manipular esas rutas para apuntarlas a destinos arbitrarios.

Como el Nessus Agent se ejecuta como un servicio de Windows con privilegios de SYSTEM, cualquier operación de borrado que realice hereda ese poder. Un usuario sin privilegios especiales que ya tenga acceso local a la máquina puede, sembrando una junction en el momento justo, lograr que el agente elimine archivos protegidos del sistema. Y un borrado arbitrario como SYSTEM, en Windows moderno, es una primitiva conocida que se puede encadenar hasta llegar a la ejecución de código completa.

Tenable calificó el fallo con un CVSSv3 base de 8.2 (alto) y un CVSSv4 de 7.4. El vector es local, la complejidad de ataque es baja y solo se requieren privilegios bajos previos, con impacto alto en confidencialidad, integridad y disponibilidad. Las versiones 11.1.2 y anteriores están afectadas; la 11.1.3 es la única segura.
El agente de escaneo corría como SYSTEM, heredando ese poder en cada borrado.

Cómo funciona el ataque con junctions

Para entender la mecánica hay que conocer las junctions de Windows. Una junction es un tipo de enlace del sistema de archivos NTFS que redirige un directorio hacia otro. Cuando un proceso intenta acceder a C:\ruta\carpeta y esa carpeta es en realidad una junction hacia C:\Windows\System32, el sistema sigue el enlace de forma transparente. El proceso cree que trabaja en un sitio cuando en realidad opera en otro.

Aquí está el problema central: un proceso privilegiado debe verificar que la ruta que va a tocar es realmente la que espera, justo antes de operar sobre ella. Si el Nessus Agent calcula una ruta, asume que es segura y luego la borra sin re-validar, deja una ventana abierta. El atacante explota esa ventana: planta su junction maliciosa en el instante entre la verificación (si existe) y el acceso real. Es la clásica condición de carrera TOCTOU (Time-Of-Check to Time-Of-Use) aplicada al sistema de archivos.

sequenceDiagram
    participant U as Usuario local
    participant FS as Sistema de archivos
    participant A as Nessus Agent (SYSTEM)
    U->>FS: Crea junction carpeta_temp -> C:\\Windows\\objetivo
    A->>FS: "Voy a limpiar carpeta_temp"
    FS-->>A: Resuelve junction silenciosamente
    A->>FS: Borra C:\\Windows\\objetivo como SYSTEM
    Note over A,FS: Borrado arbitrario con privilegios maximos

Una vez que un atacante consigue borrar archivos arbitrarios como SYSTEM, el siguiente paso para llegar a ejecución de código es territorio bien documentado. La técnica más conocida abusa del mecanismo de rollback del Windows Installer (MSI): se fuerza una instalación, se provoca un fallo controlado y, durante la reversión, se aprovecha el borrado para colocar un archivo malicioso (por ejemplo, una DLL) en una ruta que un proceso privilegiado cargará después. El resultado es código corriendo con el token de SYSTEM.

💭 Clave: El bug no está en "qué" borra el agente, sino en "dónde" termina borrando. Un enlace del sistema de archivos redirige la operación legítima hacia un objetivo elegido por el atacante.

Contexto: cuando el guardián es la puerta

Esta clase de fallos en software de seguridad no es nueva ni anecdótica. Antivirus, EDRs, agentes de backup y, sí, escáneres de vulnerabilidades comparten un rasgo peligroso: necesitan privilegios elevados para inspeccionar todo el sistema, y por eso corren como SYSTEM o root. Cada operación de archivo que realizan es una oportunidad potencial de abuso si no se valida con cuidado.

Los abusos de junction y de enlaces simbólicos en Windows han sido un terreno fértil para investigadores como James Forshaw de Google Project Zero, quien documentó durante años cómo los servicios privilegiados que tocan rutas controlables por el usuario terminan en escaladas locales. El patrón se repite: borrado arbitrario, escritura arbitraria o lectura arbitraria, todos potenciados por SYSTEM, todos disparados por un usuario sin privilegios.

El Nessus Agent es la versión ligera del escáner de Tenable: se instala en endpoints y servidores para reportar su postura de seguridad a un Nessus Manager o a Tenable.io central, en lugar de escanear la red desde fuera. Está pensado para desplegarse masivamente, en cientos o miles de máquinas dentro de una organización. Eso amplía la superficie: un único fallo de escalada local se multiplica por cada host donde el agente esté instalado.
Los agentes se despliegan en miles de equipos: un fallo local se multiplica por host.

Datos y cifras: la cronología del parche

La línea de tiempo del caso ilustra cómo funciona la divulgación coordinada en un proveedor grande, y también por qué a veces frustra a los investigadores:

29 de diciembre de 2025 — Reporte inicial del investigador a Tenable.- 18 de febrero de 2026 — Tenable acepta formalmente el reporte.- 23 de marzo de 2026 — Se solicita el identificador CVE y se completa el cálculo CVSS.- 23 de abril de 2026 — Se publica el aviso TNS-2026-12 y la versión corregida 11.1.3.

Entre el reporte y el parche transcurrieron aproximadamente cuatro meses. Para una escalada de privilegios local de gravedad alta, ese plazo está dentro de lo habitual en la industria (el estándar de facto ronda los 90 días), aunque algo por encima. La buena noticia para los defensores: por ser un vector estrictamente local, el riesgo de explotación masiva remota es nulo; el atacante necesita ya tener acceso a la máquina.

⚠️ Ojo: "Solo local" no significa "poco importante". En cadenas de ataque reales, conseguir un punto de apoyo con bajos privilegios es lo fácil; escalar a SYSTEM es lo que convierte una intrusión menor en compromiso total del host.

Impacto y análisis

El impacto práctico depende del contexto de cada despliegue. En un servidor compartido, una estación de trabajo multiusuario o cualquier entorno donde un atacante haya logrado ejecución con privilegios limitados (vía phishing, una credencial robada o una segunda vulnerabilidad), CVE-2026-33694 ofrece el salto final hasta el control total del sistema. SYSTEM puede desactivar defensas, instalar persistencia, leer cualquier archivo y pivotar dentro de la red.

Hay una capa adicional de incomodidad: el agente comprometido es, precisamente, el sensor de seguridad. Un atacante con SYSTEM en el host donde corre el Nessus Agent podría manipular o silenciar los reportes que ese agente envía a la consola central, ocultando su propia presencia ante el equipo de seguridad que confía en esos datos. El guardián deja de ser confiable.

Para las organizaciones, la lección operativa es clara: el software de seguridad también es software, y también necesita gestión de parches disciplinada. Es frecuente que los agentes de seguridad se desplieguen una vez y se olviden, asumiendo que "se actualizan solos" o que "son seguros por definición". Ninguna de las dos cosas es garantía.

💡 Tip: Trata a tus agentes de seguridad (EDR, antivirus, escáneres) como activos críticos en tu inventario de parches. Son los que corren con más privilegios en todos tus hosts.

Qué sigue: cómo protegerse

La acción es directa y no admite demora: actualizar a Nessus Agent 11.1.3 o posterior en todos los endpoints Windows. Los pasos recomendados:

Inventariar — Identificar todos los hosts Windows con Nessus Agent y su versión actual. Cualquier 11.1.2 o anterior es vulnerable.- Actualizar — Descargar la versión 11.1.3 desde el portal oficial de Tenable y desplegarla. Si usás actualizaciones gestionadas vía Nessus Manager o Tenable.io, verificá que el plan de actualización del agente esté apuntando a la versión parcheada.- Verificar — Confirmar la versión efectiva en los endpoints tras el despliegue, no asumir que la política se aplicó sola.- Monitorear — Vigilar la creación inusual de junctions y borrados de archivos de sistema por procesos privilegiados, una señal genérica de este tipo de abuso.

A nivel de diseño, este caso es un recordatorio para cualquier desarrollador de software privilegiado en Windows: nunca confíes en que una ruta es la que crees. Usá APIs que abren handles de forma segura, validá que el archivo no sea un reparse point cuando no debería serlo, y operá sobre handles ya abiertos en lugar de re-resolver rutas por nombre justo antes de un borrado o escritura sensibles.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué es exactamente CVE-2026-33694?

Es una vulnerabilidad de escalada de privilegios local en Nessus Agent para Windows, del tipo "link following" (CWE-59). Permite que un usuario con pocos privilegios abuse de junctions del sistema de archivos para que el agente, que corre como SYSTEM, borre archivos arbitrarios, lo que puede encadenarse hasta ejecución de código con privilegios máximos.

¿Puede explotarse de forma remota?

No. El vector es estrictamente local: el atacante necesita ya tener acceso y la capacidad de ejecutar código con privilegios bajos en la máquina afectada. No es una vulnerabilidad explotable directamente a través de la red.

¿Qué versiones de Nessus Agent están afectadas?

Todas las versiones 11.1.2 y anteriores en Windows. La versión 11.1.3 contiene la corrección. El aviso oficial de Tenable es el TNS-2026-12.

¿Qué gravedad tiene el fallo?

Tenable lo califica como alto, con un CVSSv3 base de 8.2 y un CVSSv4 de 7.4. La complejidad de ataque es baja y el impacto en confidencialidad, integridad y disponibilidad es alto.

¿Qué es una junction y por qué es peligrosa aquí?

Una junction es un enlace de directorio de NTFS que redirige el acceso de una carpeta hacia otra ubicación. Es peligrosa cuando un proceso privilegiado resuelve una ruta y opera sobre ella sin revalidar, porque un atacante puede plantar la junction para redirigir esa operación (en este caso, un borrado) hacia un objetivo protegido.

¿Hay evidencia de explotación activa?

Al momento de la publicación del aviso, Tenable no reportó explotación activa conocida. Aun así, dado que las técnicas de abuso de junction están bien documentadas, parchear sin demora es la recomendación estándar.

Referencias

Tenable — Aviso oficial TNS-2026-12 — Detalle de versiones afectadas y la corrección en Nessus Agent 11.1.3.- NVD — CVE-2026-33694 — Ficha oficial con puntuación CVSS y clasificación CWE-59.- GBHackers — Nessus Agent Windows Flaw Enables SYSTEM-Level Code Execution — Cobertura técnica del fallo y su mecánica.- eSecurity Planet — Nessus Agent Flaw Grants SYSTEM-Level Access on Windows — Análisis de impacto y cronología.

Minimus publica imágenes de contenedor con hasta 100% menos CVEs

lu1tr0n — Wed, 24 Jun 2026 14:17:44 +0000

El catálogo de imágenes endurecidas de Minimus llegó para disputar un mercado que Google y Chainguard ya habían empezado a calentar: contenedores mínimos, sin shell ni gestor de paquetes, que prometen recortar entre 75% y 100% los CVEs reportados frente a las imágenes base oficiales.

La promesa suena a marketing, pero el mecanismo es real y vale entenderlo. Acá repasamos qué publica Minimus, cómo funciona la reducción de vulnerabilidades, los datos del catálogo y cómo aplicar la idea en un pipeline de CI/CD en la región.

TL;DR

Minimus publica un catálogo de imágenes de contenedor mínimas y endurecidas (hardened) para apps, bases de datos e infra.- Varias imágenes anuncian reducciones de CVEs de entre 75% y 100% frente a las imágenes base oficiales.- Ofrece variantes FIPS (cripto validada) y STIG (guías de endurecimiento del DoD) para entornos regulados.- El truco técnico: quitar shell, gestor de paquetes y librerías que la app nunca ejecuta reduce la superficie de ataque.- Compite con Google Distroless y Chainguard Images en el espacio de cadena de suministro de software.- El tier gratuito viene sin soporte ni SLA; los parches priorizan a las suscripciones de pago.- Para LATAM es relevante por cumplimiento (banca, gobierno) y por bajar ruido de escáneres en CI/CD.

Qué pasó: Minimus abre su catálogo de imágenes endurecidas

Minimus publicó un catálogo público de imágenes endurecidas y charts de Helm que cubre el stack típico de una empresa moderna: bases de datos (PostgreSQL, MariaDB, MongoDB, Redis, Elasticsearch), infraestructura de Kubernetes (cert-manager, Argo Rollouts, Kyverno, KEDA, external-dns), utilidades (Fluent Bit, Fluentd, Prometheus) y herramientas de desarrollo. Cada imagen aparece etiquetada con un porcentaje de reducción de vulnerabilidades; muchas marcan literalmente 100% reduction.

La propuesta no es nueva como categoría, pero sí en su amplitud. Junto a cada imagen estándar, Minimus ofrece variantes FIPS (con módulos criptográficos validados) y STIG (alineadas con las guías de endurecimiento del Departamento de Defensa de EE. UU.). Eso es exactamente lo que hoy una empresa regulada arma a mano, con semanas de trabajo y mantenimiento perpetuo.
Las imágenes mínimas quitan todo lo que la app no ejecuta en runtime.

Contexto e historia: de la imagen gorda al distroless

Durante años, el patrón por defecto fue arrancar un Dockerfile con FROM ubuntu o FROM node y empacar la aplicación encima. Cómodo, pero costoso: esas imágenes traen un sistema operativo casi completo — shell bash, apt o apk, compiladores, librerías de sistema, utilidades de red. Tu aplicación usa una fracción de eso; el resto es peso muerto y, peor, superficie de ataque.

En 2017 Google liberó Distroless, imágenes que contienen solo la aplicación y sus dependencias de runtime: sin shell, sin gestor de paquetes, sin nada que un atacante pueda aprovechar para moverse lateralmente. En 2022, ex-ingenieros de Google fundaron Chainguard y llevaron la idea a producto comercial con reconstrucciones diarias y SBOM (Software Bill of Materials) firmados. Minimus es el siguiente capítulo de esa misma historia.

El telón de fondo es la seguridad de la cadena de suministro de software. Ataques como SolarWinds, las vulnerabilidades de Log4j y los typosquatting en npm y PyPI dejaron claro que el contenedor que corre en producción es tan seguro como su eslabón más débil. Marcos como SLSA empujaron a tratar la procedencia y la minimización como requisitos, no como lujo.

💭 Clave: Una vulnerabilidad en un paquete que tu app nunca ejecuta sigue apareciendo en el escáner y sigue exigiendo respuesta del equipo. Quitar el paquete elimina el hallazgo de raíz.

Por qué las imágenes endurecidas reducen los CVEs

Acá está el matiz que separa el marketing de la ingeniería. Cuando Minimus anuncia 100% menos CVEs, no quiere decir que parchó cien vulnerabilidades: quiere decir que eliminó los paquetes que las contenían. Un escáner como Trivy o Grype compara los paquetes instalados contra bases de datos de CVEs. Si la imagen no trae bash, openssl de sistema, curl ni glibc completa, esos CVEs simplemente no existen en tu superficie.

Las imágenes endurecidas aplican varias técnicas combinadas:

Minimización — solo la aplicación y sus dependencias directas de runtime. Nada de toolchains de compilación ni utilidades de depuración.- Sin shell — al no haber /bin/sh, un atacante que logre ejecución de comandos se queda sin intérprete para encadenar payloads.- Usuario no-root — el proceso corre con privilegios mínimos por defecto.- Reconstrucción frecuente — al rearmar la imagen seguido, los parches upstream entran rápido y la ventana de exposición se acorta.

El siguiente diagrama resume por qué dos imágenes con la misma app dan resultados de escaneo opuestos:

graph LR
  A["Imagen base completa"] --> B["Escaneo de CVEs"]
  B --> C["Cientos de paquetes sin usar"]
  D["Imagen minima endurecida"] --> E["Escaneo de CVEs"]
  E --> F["Superficie casi nula"]

Ejemplo práctico: multi-stage build y pull del catálogo

El patrón canónico para llegar a una imagen mínima es el multi-stage build: compilás en una imagen gorda con todas las herramientas y copiás solo el binario final a una imagen mínima. Veamos un ejemplo con Go:

# Etapa 1: build con toolchain completo
FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/api

# Etapa 2: runtime minimo y endurecido
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app /app
USER nonroot
ENTRYPOINT ["/app"]

La imagen final no tiene shell ni gestor de paquetes: solo tu binario. Para traer una imagen de un catálogo como el de Minimus, el comando es el mismo docker pull en cualquier sistema operativo. Lo que cambia es cómo abrís la terminal:

# Windows (PowerShell)
docker pull images.minimus.io/library/redis:latest

# macOS (Terminal / zsh)
docker pull images.minimus.io/library/redis:latest

# Linux (bash)
docker pull images.minimus.io/library/redis:latest

Una vez descargada, podés escanearla y comparar el conteo de hallazgos contra la imagen oficial:

# Escaneo comparativo con Trivy (mismo comando en Win/macOS/Linux)
trivy image redis:latest
trivy image images.minimus.io/library/redis:latest

⚠️ Ojo: sin shell no podés hacer docker exec -it contenedor sh para depurar. Tenés que depurar con contenedores efímeros, kubectl debug o logs estructurados. Es un compromiso real: ganás seguridad, perdés comodidad de diagnóstico en caliente.
Menos paquetes significa menos ruido en el escáner de CI/CD.

Datos y cifras del catálogo

El catálogo de Minimus es explícito con los números. Las reducciones publicadas no son uniformes: dependen de cuánto sobra en la imagen base original. Algunos ejemplos del propio catálogo:

Imágenes de infraestructura y bases de datos populares marcan 100% reduction, es decir, cero CVEs reportados al momento del build.- Herramientas de desarrollo y utilidades muestran rangos de 75% a 99% según las dependencias que arrastran.- Casos con stacks más pesados o dependencias nativas marcan reducciones menores, del orden de 40% a 80%.

Minimus es transparente con la letra chica: "hardened" describe la configuración de seguridad al momento del build y no garantiza ausencia de vulnerabilidades futuras. El tier gratuito viene sin soporte, sin SLA ni cadencia de parches garantizada, y las actualizaciones de seguridad pueden aplicarse a las suscripciones de pago antes que al tier libre. Es el mismo modelo de negocio que Chainguard popularizó.

Impacto y análisis para LATAM

Para los equipos de la región, las imágenes endurecidas tocan dos dolores concretos. El primero es el cumplimiento: banca, fintech, salud y gobierno enfrentan auditorías que exigen contenedores con superficie mínima, criptografía validada (FIPS) y configuración endurecida (STIG). Armar y mantener esas variantes a mano consume tiempo de equipos que en muchas organizaciones ya están cortos de personal.

El segundo es el ruido de los escáneres. Cualquiera que haya conectado Trivy o Snyk a un pipeline conoce la fatiga: cientos de CVEs "críticos" en paquetes del sistema operativo base que la aplicación nunca toca. Ese ruido entrena al equipo a ignorar los reportes, lo que es peor que no escanear. Una imagen mínima deja en el reporte solo lo que importa, y eso devuelve sentido al gate de seguridad en CI/CD.

💡 Tip: antes de migrar todo, elegí un servicio de bajo riesgo, cambiá su imagen base por una variante mínima, corré tu suite de tests y compará el conteo de CVEs. El número suele convencer más que cualquier presentación.

La contrapartida es la dependencia de un proveedor para los rebuilds y la pérdida de herramientas de depuración dentro del contenedor. La decisión sensata es híbrida: imágenes mínimas en producción, e imágenes con shell solo en entornos de desarrollo donde la comodidad de diagnóstico pesa más que el endurecimiento.

Qué sigue

El mercado de imágenes mínimas y endurecidas pasó de ser un proyecto open source de nicho a una categoría con varios competidores comerciales. La diferenciación ya no está en "tener menos CVEs" — eso lo logra cualquiera que minimice — sino en la cadencia de parches, la procedencia verificable, los SBOM firmados y la cobertura de variantes reguladas. La entrada de Minimus presiona los precios y empuja a Google y Chainguard a mejorar su catálogo libre.

Para el desarrollador, la señal es clara: la imagen base "gorda" por defecto está en retirada en cargas de producción serias. En los próximos años, partir de una imagen mínima endurecida será tan estándar como hoy lo es usar HTTPS.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Una imagen endurecida con 100% menos CVEs es realmente invulnerable?

No. Significa que, al momento del build, el escáner no encontró CVEs conocidos en los paquetes instalados, porque se eliminaron los componentes que solía marcar. Pueden aparecer vulnerabilidades nuevas después, o estar en tu propio código de aplicación, que el escáner de imagen no evalúa.

¿Qué diferencia a Minimus de Google Distroless o Chainguard?

La idea central es la misma: minimizar y endurecer. Las diferencias están en el catálogo cubierto, la amplitud de variantes FIPS y STIG, la cadencia de reconstrucción, el modelo de soporte y el precio. Distroless es totalmente gratuito pero más acotado; Chainguard y Minimus son productos comerciales con tier libre limitado.

¿Puedo depurar un contenedor sin shell?

Sí, pero cambia el método. Usás contenedores de depuración efímeros (por ejemplo kubectl debug), copiás un binario de shell temporal o dependés de logs estructurados y métricas. La ausencia de shell es justamente lo que reduce el riesgo si un atacante logra ejecución.

¿Qué significan FIPS y STIG en estas imágenes?

FIPS se refiere a módulos criptográficos validados bajo el estándar federal de EE. UU., requeridos en muchos contratos de gobierno y banca. STIG son las guías técnicas de endurecimiento del Departamento de Defensa. Tener variantes listas evita que cada equipo las arme y mantenga por su cuenta.

¿Sirven para reducir el tamaño de la imagen además de los CVEs?

Sí. Al quitar el sistema operativo casi completo, las imágenes mínimas suelen pesar megabytes en lugar de cientos de megabytes. Eso acelera los pulls, reduce el uso de registro y mejora los tiempos de arranque en escalado automático.

Referencias

Images & Charts — Minimus — catálogo público de imágenes endurecidas con porcentajes de reducción de CVEs.- Google Distroless — proyecto open source que popularizó las imágenes de contenedor sin shell ni gestor de paquetes.- Chainguard Images — repositorio de imágenes mínimas con reconstrucción diaria y SBOM firmados.- SLSA — Supply-chain Levels for Software Artifacts — marco para procedencia y seguridad de la cadena de suministro.- Docker: Multi-stage builds — documentación oficial del patrón para construir imágenes finales mínimas.

pico-usb-wifi convierte una Pico W de $6 en adaptador WiFi USB

lu1tr0n — Wed, 24 Jun 2026 08:18:14 +0000

Un desarrollador conocido como 白一百 (baiyibai) publicó el 21 de junio de 2026 pico-usb-wifi, un firmware de código abierto que convierte una Raspberry Pi Pico W de unos seis dólares en un adaptador WiFi USB sin drivers. La placa se conecta por USB, se enumera como un dispositivo de red estándar y puentea el tráfico entre tu red inalámbrica y la computadora sin instalar absolutamente nada.

Para quien necesita WiFi en una máquina sin tarjeta inalámbrica —un PC de escritorio, un servidor headless o una Raspberry Pi corriendo Windows ARM— la propuesta es directa: hardware barato, código bajo licencia MIT y cero configuración de red. Acá explicamos cómo funciona, qué lo diferencia de proyectos previos y cómo compilarlo en Windows, macOS y Linux.

TL;DR

pico-usb-wifi convierte una Raspberry Pi Pico W de ~$6 en un adaptador WiFi USB sin drivers; se publicó el 21 de junio de 2026.
Se enumera como dispositivo USB CDC-NCM y usa los drivers estándar ya presentes en Windows, macOS y Linux, sin instalar nada.
Hace bridging de capa 2: reenvía tramas Ethernet entre el WiFi y el USB sin NAT, sin subredes privadas ni port-forwarding.
El host adopta la MAC de la estación WiFi (identidad única), sorteando el límite de que un cliente WiFi no puede puentear varias MAC.
Soporta IPv4 e IPv6, autenticación WPA2-PSK y alcanza unos 4,75 Mbit/s de rendimiento.
Se configura por consola serie CDC-ACM (/dev/ttyACM0) con comandos SET ssid, SET pass y SAVE; las credenciales persisten entre flasheos.
Licencia MIT; se compila con pico-sdk 2.2.0 y arm-none-eabi-gcc, y se flashea copiando el .uf2 al volumen RPI-RP2.

Qué pasó: un adaptador WiFi USB que cabe en un llavero

El microcontrolador Raspberry Pi Pico W cuesta alrededor de seis dólares e incluye un chip inalámbrico (el Infineon CYW43439) conectado por SPI. Hasta ahora ese WiFi servía sobre todo para que el propio microcontrolador hablara con la red en proyectos de IoT. Lo que hace pico-usb-wifi es darle la vuelta a la idea: en lugar de que la Pico use el WiFi para sí misma, lo presta a la computadora a la que está enchufada por USB. El resultado es un adaptador WiFi USB completo, construido con una placa que cualquiera puede comprar en una tienda de electrónica.

La gracia no está solo en el precio, sino en que es driverless: no hay que instalar software propietario, ni firmware adicional, ni paquetes en el sistema operativo. Cuando conectás la Pico W flasheada con este firmware, Windows, macOS o Linux la reconocen como una tarjeta de red más, igual que reconocerían un adaptador Ethernet USB comercial. Eso elimina el dolor de cabeza clásico de los dongles WiFi baratos: el chipset sin soporte, el driver que solo existe para una versión vieja del kernel, o el blob binario que nadie audita.

La Pico W se enchufa por USB y aparece como tarjeta de red estándar.

Cómo funciona: un bridge de capa 2 y una sola MAC

La clave técnica del proyecto es que opera en la capa 2 del modelo de red, la de las tramas Ethernet, y no en la capa 3 (IP). El firmware no corre una pila TCP/IP propia: se limita a reenviar tramas Ethernet textualmente entre dos interfaces, la del WiFi y la del USB. Es, en esencia, un puente transparente. Tu computadora cree que tiene una conexión cableada directa a la red, y el router de tu casa cree que está hablando con un cliente WiFi normal.

Acá aparece el problema que el proyecto resuelve con elegancia. Un cliente WiFi (una estación, en jerga 802.11) normalmente no puede puentear varias direcciones MAC a la vez: el modo que lo permitiría —las tramas de cuatro direcciones, o WDS— no está habilitado en la mayoría de los puntos de acceso domésticos. Si la Pico tuviera una MAC para su WiFi y la computadora otra distinta para su USB, el router vería dos identidades detrás de una sola estación y descartaría el tráfico. La solución de pico-usb-wifi es unificar ambas bajo una única identidad MAC: la interfaz USB del host adopta la dirección MAC de la estación WiFi de la Pico. Para la red existe un solo dispositivo, y por eso no hace falta NAT, ni subredes privadas, ni reenvío de puertos.

graph LR
  W["Router WiFi"] -->|"tramas 802.11"| P["Pico W"]
  P -->|"bridge capa 2"| U["USB CDC-NCM"]
  U -->|"misma MAC"| H["Host (PC o servidor)"]

Como no hay traducción de direcciones, tu computadora recibe una IP directamente del router, tanto en IPv4 como en IPv6. Eso significa que es accesible desde la red local sin trucos, algo que los adaptadores que hacen NAT no permiten. La concurrencia interna se maneja con cuidado: el servicio del WiFi corre en segundo plano mientras las operaciones de USB quedan confinadas al bucle principal, y un anillo de transmisión diferido evita los bloqueos. El firmware además habilita la recepción de multicast automáticamente y filtra las tramas que la propia placa reflejaría sobre sí misma.

💭 Clave: al no correr una pila IP propia, la Pico no es un router en miniatura sino un cable invisible. Esa decisión de diseño es lo que elimina la configuración de red y hace que el dispositivo sea verdaderamente transparente.

CDC-NCM: por qué no necesita drivers

El otro pilar del proyecto es el protocolo con el que la Pico se presenta ante el sistema operativo. pico-usb-wifi se enumera como un dispositivo USB CDC-NCM (Communications Device Class — Network Control Model), un estándar de la USB Implementers Forum para transportar tramas Ethernet sobre USB. Windows 10/11, macOS y las distribuciones modernas de Linux ya traen el driver CDC-NCM de fábrica, así que el reconocimiento es inmediato y multiplataforma.

Esto marca una diferencia importante con el proyecto que inspiró buena parte de esta categoría, PicoPiFi, de Sidd Kishan. PicoPiFi usa RNDIS, una especificación de Microsoft que funciona muy bien en Windows —fue pensada justamente para llevar WiFi a equipos Windows on ARM como la Raspberry Pi 4— pero que en Linux y macOS tiene un soporte más irregular y, en el caso de Windows, históricamente arrastra problemas de seguridad por la complejidad del driver. Al elegir CDC-NCM, pico-usb-wifi apuesta por el estándar abierto y por una compatibilidad pareja en los tres sistemas operativos mayoritarios.

📌 Nota: CDC-NCM es el sucesor de CDC-ECM y agrupa varias tramas Ethernet en un mismo bloque USB para mejorar el rendimiento. Es el mismo mecanismo que usan muchos módems y teléfonos al compartir internet por cable.

Contexto: de PicoPiFi a pico-usb-wifi

La idea de convertir una Pico W en un puente WiFi-a-USB no nació hoy. PicoPiFi popularizó el concepto con el objetivo concreto de habilitar WiFi en plataformas ARM64 donde los drivers escasean: Windows on Raspberry Pi, equipos con SoC de Qualcomm, Nvidia o Samsung. Su enfoque RNDIS reportaba un enlace USB de hasta 12 Mbps y conexiones WiFi de hasta 54 Mbps desde el punto de acceso hacia la placa.

pico-usb-wifi se ubica en ese mismo linaje pero con decisiones de ingeniería distintas. Donde PicoPiFi prioriza Windows on ARM con RNDIS, el nuevo proyecto prioriza el estándar y la portabilidad con CDC-NCM y el bridging de capa 2. Ninguno reemplaza al otro: representan dos filosofías sobre cómo resolver el mismo problema —dar conectividad inalámbrica a un equipo que no la tiene— usando el hardware más barato disponible. Que ambos sean de código abierto permite además auditar exactamente qué hace el firmware, algo impensable con la mayoría de los dongles comerciales.

La Pico W incluye el chip inalámbrico CYW43439 conectado por SPI.

Datos y cifras: rendimiento, precio y límites

Conviene ser honestos con las expectativas. El rendimiento ronda los 4,75 Mbit/s, una cifra modesta que está lejos del WiFi de una laptop moderna. El cuello de botella es doble: el chip CYW43439 va conectado por SPI a un máximo teórico limitado, y el RP2040 es un microcontrolador de dos núcleos Cortex-M0+ a 133 MHz, no un procesador de red dedicado. Para navegar, administrar un servidor por SSH, sincronizar archivos o mantener un equipo headless online, esa velocidad alcanza de sobra. Para descargar a máxima velocidad o ver streaming en 4K, no.

Precio del hardware — una Raspberry Pi Pico W cuesta alrededor de 6 dólares; la Pico 2 W, algo más.
Rendimiento — aproximadamente 4,75 Mbit/s en condiciones reales.
Seguridad inalámbrica — autenticación WPA2-PSK (redes domésticas con contraseña).
Protocolos de red — IPv4 e IPv6, ambos sin NAT.
Resiliencia — un watchdog por hardware reinicia el firmware si se cuelga.

Las limitaciones actuales son claras: no hay soporte documentado para WPA3 ni para redes empresariales (WPA2-Enterprise con 802.1X), y la velocidad lo descarta como reemplazo de un adaptador de gama alta. A cambio, ofrece algo que esos adaptadores no dan: transparencia total del código, costo marginal y compatibilidad inmediata sin instalar nada.

Cómo compilarlo y flashearlo

El proyecto se construye con el pico-sdk 2.2.0 y CMake. Necesitás el toolchain de ARM (arm-none-eabi-gcc), CMake, un generador como Ninja o Make, y Python 3. El flujo es el habitual del ecosistema Pico. Acá va el procedimiento para los tres sistemas operativos:

# --- Linux (Debian/Ubuntu) ---
sudo apt install cmake gcc-arm-none-eabi build-essential python3 ninja-build
git clone -b 2.2.0 https://github.com/raspberrypi/pico-sdk.git --recurse-submodules
export PICO_SDK_PATH=$PWD/pico-sdk
git clone https://gitlab.com/baiyibai/pico-usb-wifi.git
cd pico-usb-wifi
cmake -B build -G Ninja && cmake --build build

# --- macOS (Homebrew) ---
brew install cmake ninja python3
brew install --cask gcc-arm-embedded
git clone -b 2.2.0 https://github.com/raspberrypi/pico-sdk.git --recurse-submodules
export PICO_SDK_PATH=$PWD/pico-sdk
git clone https://gitlab.com/baiyibai/pico-usb-wifi.git
cd pico-usb-wifi && cmake -B build -G Ninja && cmake --build build

# --- Windows (PowerShell, con Ninja y ARM GNU Toolchain instalados) ---
git clone -b 2.2.0 https://github.com/raspberrypi/pico-sdk.git --recurse-submodules
$env:PICO_SDK_PATH = "$PWD\pico-sdk"
git clone https://gitlab.com/baiyibai/pico-usb-wifi.git
cd pico-usb-wifi
cmake -B build -G Ninja
cmake --build build

El resultado es un archivo pico-usb-wifi.uf2. Para flashearlo, mantené presionado el botón BOOTSEL mientras conectás la Pico W por USB: aparecerá como una unidad de almacenamiento llamada RPI-RP2. Copiá el .uf2 ahí y la placa se reinicia con el nuevo firmware. La configuración del WiFi se hace después por una consola serie de gestión (CDC-ACM), normalmente en /dev/ttyACM0 en Linux o el puerto COM correspondiente en Windows.

# Provisionar la red por la consola de gestion (ej. con minicom o screen)
SET ssid MiRedWiFi
SET pass MiContrasenaSecreta
SET country SV
SAVE

💡 Tip: las credenciales se guardan en la memoria flash de la placa y persisten entre actualizaciones de firmware. Podés re-flashear sin volver a configurar el WiFi, y el comando RESTORE deja todo en limpio si querés empezar de cero.

Impacto y análisis

Más allá del truco simpático, pico-usb-wifi señala una tendencia: usar microcontroladores genéricos y baratos para reemplazar periféricos que históricamente requerían silicio dedicado y drivers cerrados. Un adaptador WiFi USB de código abierto, auditable línea por línea, tiene valor real en contextos donde la confianza importa: laboratorios, equipos sensibles, hardware antiguo sin soporte de drivers, o simplemente para aprender cómo funciona el networking de bajo nivel.

Para la comunidad de desarrolladores en LATAM, donde el hardware importado es caro y conseguir un dongle WiFi con buen soporte en Linux puede ser una lotería, tener una opción de seis dólares construida con una placa fácil de conseguir es genuinamente útil. Y como todo el stack está expuesto —desde el bridging de capa 2 hasta la enumeración USB— el proyecto funciona también como material didáctico: es uno de los ejemplos más limpios para entender qué pasa realmente cuando un dispositivo de red se conecta a tu computadora.

Qué sigue

Al ser un proyecto recién publicado y bajo licencia MIT, su evolución dependerá de la comunidad. Los frentes naturales de mejora son el soporte de WPA3, mayor rendimiento aprovechando la Pico 2 W (con su RP2350 más potente) y herramientas de configuración más amigables que la consola serie. Si seguís el espacio de hardware abierto, vale la pena clonar el repositorio, compilarlo y reportar lo que encuentres: a esta escala de precio, experimentar cuesta literalmente unos pocos dólares.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué hardware necesito para usar pico-usb-wifi?

Una Raspberry Pi Pico W (la versión con WiFi, no la Pico estándar) y un cable USB. La Raspberry Pi Pico 2 W tiene compatibilidad esperada. La placa cuesta alrededor de seis dólares.

¿De verdad funciona sin instalar drivers?

Sí. La placa se presenta como un dispositivo USB CDC-NCM, un estándar que Windows, macOS y Linux ya soportan de fábrica. El sistema operativo la reconoce como una tarjeta de red más, sin software adicional.

¿Qué velocidad alcanza?

Alrededor de 4,75 Mbit/s. Es suficiente para navegar, administrar servidores por SSH o mantener un equipo headless online, pero no para descargas a máxima velocidad ni streaming en alta resolución.

¿En qué se diferencia de PicoPiFi?

PicoPiFi usa RNDIS, orientado sobre todo a Windows on ARM. pico-usb-wifi usa CDC-NCM y un bridge de capa 2 con una sola MAC, lo que le da compatibilidad pareja en Windows, macOS y Linux sin NAT.

¿Soporta IPv6 y redes seguras?

Soporta IPv4 e IPv6 sin NAT, y autenticación WPA2-PSK. Por ahora no hay soporte documentado para WPA3 ni para WPA2-Enterprise (802.1X).

¿Cómo configuro la red WiFi?

Mediante una consola serie de gestión (CDC-ACM) con comandos como SET ssid, SET pass y SAVE. Las credenciales persisten en la flash entre actualizaciones de firmware.

Referencias

pico-usb-wifi en GitLab — repositorio oficial del firmware, licencia MIT, publicado el 21 de junio de 2026.
PicoPiFi en GitHub — proyecto previo que usa RNDIS para llevar WiFi por USB a equipos Windows on ARM.
Raspberry Pi pico-sdk — SDK oficial en C/C++ necesario para compilar el firmware.
pico-examples — ejemplos oficiales del ecosistema Pico, incluidos los de red y USB.
Ethernet over USB (Wikipedia) — explicación de los protocolos CDC-NCM, CDC-ECM y RNDIS.

Valsorda: con LLMs, los reportes de vulnerabilidades ya no son especiales

lu1tr0n — Wed, 24 Jun 2026 02:17:46 +0000

Durante años, la regla no escrita del open source fue clara: podés ignorar casi cualquier issue o pull request, pero un reporte de seguridad es sagrado. Filippo Valsorda, ex líder del equipo de seguridad del lenguaje Go, acaba de poner esa regla en duda.

En un texto publicado el 23 de junio de 2026, sostiene que los reportes de vulnerabilidades ya no son especiales. El motivo: los modelos de lenguaje volvieron abundante lo que antes era escaso, y el verdadero trabajo se movió del hallazgo al triaje.

TL;DR

Filippo Valsorda, ex líder del equipo de seguridad de Go, publicó el 23 de junio de 2026 que los reportes de vulnerabilidades ya no son especiales.
El argumento clásico: los investigadores ofrecían insight escaso y confidencialidad a cambio de respuesta rápida y atribución.
En 2026 esas premisas se rompen: los LLM hallan bugs tan bien como casi cualquier investigador y los puede correr cualquiera.
El cuello de botella ya no es encontrar problemas potenciales, sino determinar cuáles son reales: el triaje.
La confidencialidad y los embargos pierden peso porque el atacante también puede preguntarle a su propio LLM.
La nueva prioridad del mantenedor: triaje, remediación rápida, prevención y análisis con LLM dentro del CI.
Para LATAM y el open source de la región, implica automatizar el análisis de seguridad en vez de depender del reporte externo.

Qué pasó

Valsorda no es un opinador cualquiera. Lideró el equipo de seguridad de Go en Google y hoy mantiene piezas críticas del lenguaje a través de Geomys, una organización de mantenedores profesionales de Go financiada por empresas como Datadog, Tailscale, Teleport, Sentry y Ava Labs. Cuando alguien con ese recorrido dice que un dogma de la industria caducó, vale la pena leerlo con atención.

Su punto de partida es una idea sana para cualquier mantenedor: cada issue, PR o comentario es un regalo, no una obligación. Podés aceptarlo, ignorarlo o usarlo a medias. Durante años, Valsorda le decía a la gente nueva del equipo que había una única excepción: los reportes de vulnerabilidades. Esos sí eran especiales, porque el investigador te estaba haciendo un favor al reportar en privado en lugar de hacer divulgación total.

El intercambio era explícito. El mantenedor ofrecía dos cosas: responsividad (acusar recibo rápido, investigar, mantener al reportante al tanto) y atribución (acreditar el descubrimiento). A cambio recibía dos cosas valiosas: el insight de haber encontrado la falla, y la confidencialidad necesaria para publicar el parche antes de que el atacante publicara el exploit.

La tesis de 2026 es que ninguna de esas premisas sigue en pie. Los LLM, dice, son tan buenos como casi cualquier investigador de seguridad, y cualquiera los puede correr: el mantenedor, el investigador externo y el atacante por igual.

El hallazgo de fallas dejó de ser un recurso escaso.

Contexto e historia

Para entender por qué esto es polémico hay que recordar de dónde viene la idea de la divulgación coordinada. En otra época, reportar una vulnerabilidad era literalmente peligroso: a investigadores bien intencionados se los recibía con amenazas legales o directamente con denuncias penales.

Hizo falta el movimiento de full disclosure (divulgación total) para que la industria internalizara lo contraproducente de esa actitud. Parte del trato de la divulgación coordinada —que Valsorda prefiere llamar así y no "responsable", por la carga moral del término— fue una promesa implícita: no perseguir a quien reporta. Ese miedo, afortunadamente, hoy es casi irrelevante en el open source: ningún investigador teme una demanda por reportar, y ningún proyecto debería siquiera insinuarla.

Sobre esa historia se construyó la idea de que el reportante presta un servicio. Y el corolario era duro pero justo: ignorar un reporte de seguridad comunicaba que no te importaba la seguridad de tus usuarios, y era —con razón— motivo de vergüenza. Esa lógica funcionó mientras el insight fue escaso. El cambio de 2026 es que dejó de serlo.

💭 Clave: El reportante nunca fue lo especial. Lo especial era el insight escaso y la confidencialidad. Cuando esos dos recursos se vuelven abundantes, la deuda de responsividad y atribución pierde su fundamento.

Datos y cifras

El argumento es cualitativo, pero se apoya en una observación medible sobre la economía del trabajo de seguridad. Tradicionalmente el embudo tenía un único cuello de botella escaso: encontrar el problema. Conseguir una persona capaz de hallar un bug explotable en una librería de criptografía era caro y raro.

Hoy ese paso se abarató casi a cero. Un LLM genera decenas de hallazgos candidatos en minutos. El cuello de botella se desplazó por completo hacia el otro extremo del embudo: el triaje, es decir, decidir cuáles de esos candidatos son reales y cuáles son ruido plausible pero falso.

Y acá está el detalle incómodo: salvo que ya exista una relación de confianza, un investigador externo no puede aportar gran cosa a ese triaje. Revisar la salida cruda de un LLM ajeno o revisar tu propia bandeja security@ tiene aproximadamente la misma relación señal/ruido. El reporte externo, que antes traía señal pura, ahora puede traer el mismo ruido que vos ya podrías generar solo.

flowchart LR
  A["Investigador o LLM"] --> B["Muchos hallazgos candidatos"]
  B --> C["Triaje: cual es real?"]
  C -->|"Real"| D["Remediacion rapida"]
  C -->|"Ruido"| E["Descartar"]
  D --> F["Prevencion en CI"]

La confidencialidad sufre el mismo destino. Los embargos y la coordinación importaban porque el atacante necesitaba leer la divulgación para aprender de la falla. Pero si el atacante puede correr su propio LLM sobre el mismo código, no necesita tu post: probablemente ya tiene el mismo embudo y el mismo cuello de botella de triaje que vos. El secreto deja de comprar la ventaja temporal que justificaba todo el ritual.

Impacto y análisis

Si la premisa es correcta, la consecuencia para los mantenedores —y muy especialmente para el open source de LATAM, donde los equipos suelen ser de una o dos personas sin presupuesto— es un cambio de rol. El trabajo deja de ser esperar y atender reportes y pasa a ser triaje, remediación rápida y, como siempre, prevención.

Esto tiene un lado liberador. Muchos mantenedores arrastraban una culpa difusa por no responder con la rapidez "debida" a cada correo de security@. Si el reporte externo ya no es un favor escaso sino una más de las miles de salidas posibles de un modelo, la presión moral asimétrica se diluye. El mantenedor recupera el derecho a tratar esos mensajes como lo que son hoy: insumos a triar, no obligaciones a honrar.

El lado complicado aparece en los bordes. Valsorda menciona un caso espinoso: ¿qué hacés si quien reporta una vulnerabilidad real también está violando el código de conducta del proyecto? ¿La ignorás? ¿La arreglás en silencio sin dar crédito? No hay forma limpia de cuadrar ese círculo; queda en un juicio caso por caso según la gravedad de la conducta y los recursos del equipo.

⚠️ Ojo: "Los LLM ya triajan solos" es la lectura fácil y equivocada. El modelo genera candidatos; la decisión de qué es real sigue necesitando criterio humano y contexto del proyecto. Lo que se abarató es el hallazgo, no el juicio.

El análisis de seguridad se corre solo, dentro del pipeline.

Qué sigue: análisis de seguridad en el CI

La conclusión práctica de Valsorda es directa: deberíamos descubrir cómo correr análisis con LLM dentro del CI. La idea es invertir el flujo. En lugar de esperar a que un tercero te avise, vos mismo corrés el análisis automatizado en cada pull request, junto a los linters y los tests.

En el ecosistema Go esto no parte de cero. Herramientas como govulncheck ya escanean dependencias contra una base de vulnerabilidades conocidas. El paso nuevo es sumar análisis generativo que busque patrones sospechosos en el código propio, no solo CVE ya catalogados. Veamos una integración mínima con GitHub Actions que combina ambos enfoques:

name: security-scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.24'
      # Escaneo de CVE conocidos en dependencias
      - name: govulncheck
        run: |
          go install golang.org/x/vuln/cmd/govulncheck@latest
          govulncheck ./...
      # Analisis generativo del diff sobre patrones sospechosos
      - name: llm-review
        run: ./scripts/security-llm.sh "$(git diff origin/main...HEAD)"

El script security-llm.sh envía el diff a un modelo con un prompt acotado ("buscá manejo inseguro de entrada, comparaciones de tiempo no constante, rutas de path traversal") y falla el build si la confianza supera un umbral. La clave es que esto se ejecuta antes de que cualquier atacante o reportante mire el código, y de forma reproducible.

Si querés instalar una CLI de LLM para experimentar localmente con este flujo, acá van los comandos para los tres sistemas más comunes en la región:

# Windows (PowerShell, con winget)
winget install Anthropic.ClaudeCode

# macOS (Homebrew)
brew install claude-code

# Linux (script oficial)
curl -fsSL https://claude.ai/install.sh | sh

El punto de fondo no es la herramienta específica, sino el cambio de mentalidad: la seguridad deja de ser un evento reactivo disparado por un correo y se vuelve una etapa más del pipeline, tan rutinaria como compilar. Para equipos pequeños de LATAM, automatizar este análisis puede ser la diferencia entre depender de la buena voluntad de un extraño y tener un piso de protección que corre solo en cada commit.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Valsorda dice que hay que ignorar los reportes de seguridad?

No exactamente. Dice que dejaron de ser una categoría sagrada con obligaciones asimétricas. Hay que triarlos como cualquier insumo, sin la culpa de "deberles" respuesta inmediata y atribución por defecto.

¿Por qué los LLM cambian la ecuación?

Porque vuelven abundante el hallazgo de fallas, que antes era escaso. Si cualquiera puede generar candidatos a vulnerabilidad, el reporte externo deja de aportar un recurso único y el valor se concentra en el triaje.

¿Significa que la divulgación coordinada ya no sirve?

Pierde parte de su sentido. El embargo protegía una ventaja temporal frente al atacante; si el atacante tiene el mismo análisis automatizado, esa ventaja se reduce. La coordinación sigue siendo útil entre partes con relación de confianza.

¿Qué debería hacer hoy un mantenedor de open source?

Priorizar triaje, remediación rápida y prevención. En concreto: automatizar análisis de seguridad en el CI, mantener dependencias escaneadas y tratar la bandeja security@ como una fuente más, no como una deuda moral.

¿Esto aplica a proyectos pequeños de LATAM?

Aplica especialmente. Los equipos chicos no pueden sostener una operación de respuesta a reportes 24/7, pero sí pueden poner un análisis automatizado en cada pull request a costo casi nulo, ganando un piso de seguridad reproducible.

¿Los modelos reemplazan a los investigadores de seguridad?

No al juicio. Generan candidatos, pero decidir qué es real, explotable y prioritario sigue requiriendo criterio humano y contexto del proyecto. Lo que se democratizó es el hallazgo, no la evaluación.

Referencias

words.filippo.io — "Vulnerability Reports Are Not Special Anymore", artículo original de Filippo Valsorda (23/06/2026).
go.dev/security/policy — Política de divulgación de vulnerabilidades del proyecto Go.
go.dev/blog/govulncheck — Anuncio de govulncheck, herramienta para detectar vulnerabilidades conocidas en proyectos Go.
Wikipedia — Divulgación coordinada de vulnerabilidades: definición e historia.