Un CPU x86 solo con CSS & Sanitizer API contra XSS - Noticias de Hacker News (24 feb 2026)

Empecemos por lo más llamativo: x86CSS, de Lyra Rebane. La idea es tan absurda como fascinante: un emulador de una CPU x86 de la era 8086 que “ejecuta” código máquina dentro del navegador usando únicamente mecanismos de CSS. Sí, CSS, el lenguaje de estilos. La demo muestra un programa en C compilado con GCC a instrucciones 8086, y ese binario corre dentro de esta especie de computadora hecha de reglas y estados visuales. El propio autor es honesto: no pretende que sea práctico, porque si te pones a escribir lógica directamente en CSS podrías “calcular” más rápido que emulando una CPU completa. Aun así, lo importante aquí es el truco: exprimir el modelo de renderizado y selectores para construir una máquina de estados. Hay un matiz: el sitio incluye un pequeño script para aportar un reloj y mejorar rendimiento/estabilidad, pero también ofrecen un reloj sin JavaScript, y el emulador sigue andando con scripts desactivados. La compatibilidad está enfocada en navegadores Chromium; en Firefox, aunque hay capacidades curiosas con CSS, esta demo en particular no termina de funcionar. También es incompleto a propósito: cubre “lo suficiente” del set de instrucciones para ejecutar los programas que han probado, y admite lagunas, por ejemplo en flags como CF/OF. Aun así, incluye tabla de opcodes soportados y herramientas para que tú metas tu propio program.bin, definas punto de entrada, e incluso compiles C con gcc-ia16. Es de esas piezas que te recuerdan que el navegador moderno es, para bien o para mal, un runtime enorme y muy maleable.

Siguiendo con navegador y seguridad: Mozilla insiste en algo incómodo pero realista. El cross-site scripting, XSS, sigue siendo de las vulnerabilidades más comunes y dañinas en la web. Y no solo por el “alert(1)”: hablamos de robo de sesión, manipulación del DOM, exfiltración de datos y acciones en nombre del usuario cuando se cuela HTML o JavaScript a través de contenido generado por usuarios. La novedad es que Firefox 148 se convierte, según Mozilla, en el primer navegador que envía de serie la Sanitizer API estandarizada. La promesa es simple: un camino integrado para sanear HTML no confiable antes de insertarlo en el DOM. La pieza clave que destacan es setHTML(): en vez de hacer document.body.innerHTML = ... y rezar, llamas a setHTML() y la API limpia lo peligroso por defecto. El ejemplo típico: si el HTML trae un <img> con un onclick malicioso, la sanitización lo elimina o lo neutraliza, dejando solo marcado seguro. Y esto está pensado para ser adoptable: muchos equipos pueden mejorar su postura de seguridad reemplazando asignaciones de innerHTML por setHTML con cambios relativamente pequeños. Además, si la política por defecto te queda corta —demasiado estricta o demasiado laxa— puedes pasar configuración para permitir o bloquear elementos y atributos específicos. Y si quieres ir más allá, Mozilla propone combinar Sanitizer API con Trusted Types, para centralizar “quién” puede inyectar HTML y con qué reglas, bloqueando sinks más peligrosos. El subtexto es claro: CSP fue y es muy potente, pero cuesta adoptarlo bien; Sanitizer API intenta ser una barrera base más accesible.

Más “taller en el navegador”, pero ahora de electrónica: Diode es una propuesta de banco de trabajo online para diseñar, programar y simular circuitos desde el browser, sin instalación local. La landing lo vende como “trae tu taller a la web”, y el enfoque es directo: dibujas el esquema en una cuadrícula, colocas componentes típicos —resistencias, capacitores, transistores NPN/PNP, LEDs, un temporizador 555, pulsadores— y cableas con herramientas de conexión. Lo interesante no es solo el editor, sino el énfasis en simular ahí mismo: un botón de “Simulate” sugiere interacción inmediata para comprobar comportamiento del circuito. También empujan a “Sign Up for Free”, así que hay un nivel gratuito o acceso inicial sin coste, y enlaces tipo Explore para descubrir proyectos. Mencionan una sección de “Featured Projects”, aunque en el texto recogido aparece como si estuviera cargando. Si te mueves entre prototipado rápido y docencia, este tipo de herramienta web reduce fricción: menos ‘setup’, más experimentar.

Pasamos a lenguajes y teoría aplicada, donde también hay movimiento: λProlog. Es un lenguaje de programación lógica basado en lógica intuicionista de orden superior, apoyado en la teoría de tipos simple de Church. Traducido a utilidad: es especialmente bueno para metaprogramación, para representar sintaxis con variables ligadas sin volverte loco —lo que se conoce como higher-order abstract syntax, HOAS—, y para construir especificaciones modulares con tipos. La página repasada recuerda que λProlog fue de los primeros en soportar HOAS de forma directa y que, pese a nacer a finales de los 80, sigue despertando interés. En implementaciones actuales, destaca ELPI, un intérprete embebible escrito en OCaml por Enrico Tassi y colaboradores. La versión mencionada es la 3.4.5, de diciembre de 2025, y además tiene una integración especialmente jugosa: Coq-ELPI, un plugin que permite ejecutar programas estilo λProlog dentro del entorno de Coq. Eso abre puertas a automatización y extensiones en pruebas formales. También está Teyjus, del grupo de Gopalan Nadathur, con características de ingeniería más “clásicas” como compilación separada y soporte de tipos en runtime, y con restricciones de unificación de orden superior en el estilo de “higher-order pattern unification”. Y se menciona Makam, un metalenguaje inspirado en λProlog, reimplementado desde cero también en OCaml. Para aprender, recomiendan el libro Programming with Higher-Order Logic (2012) y recursos históricos como tutoriales de los 90, además de Abella, un demostrador interactivo para razonar sobre especificaciones con binding, usando λ-tree syntax y el cuantificador ∇. Si te interesa escribir analizadores, transformadores de lenguajes, o herramientas de verificación que manipulan ASTs con variables ligadas, aquí hay mucho material.

En formación práctica, el MIT vuelve con The Missing Semester of Your CS Education, edición IAP 2026. La tesis es conocida, pero sigue siendo cierta: muchas carreras enseñan conceptos avanzados, pero no te enseñan con rigor las herramientas que vas a usar miles de horas. Este curso apunta a cubrir esa brecha: shell, entorno de línea de comandos, herramientas de desarrollo, debugging y profiling, Git más allá de lo básico, empaquetado y despliegue, calidad de código… La nota de 2026 es que integran técnicas relacionadas con IA en cada clase, en lugar de hacer “la clase de IA” aislada. Incluso incluyen algo que llaman agentic coding, que suena a flujos donde el asistente ejecuta pasos, propone cambios y encadena acciones. Las clases fueron del 12 al 23 de enero, con videos en YouTube y discusión por Discord (OSSU). Y como siempre, el impacto real es comunitario: traducciones, forks, y gente adaptándolo fuera del MIT.

Vamos a infraestructura: turbopuffer cuenta un rediseño de su cola interna para trabajos de indexación. Ojo al detalle: no está en el write path. Es decir, cuando se escribe a su write-ahead log, esta cola sirve solo para notificar y planificar trabajos asíncronos que construyen o actualizan índices. Aun así, si esa planificación se atasca, tu sistema “se siente” lento. El problema del diseño anterior era clásico: colas shardeadas por nodo indexador. Si un nodo iba lento, bloqueaba todos los trabajos que le tocaban, aunque otros nodos estuvieran libres. La solución nueva suena contraintuitiva por simple: una única cola como archivo en object storage, más un broker sin estado. Con eso obtienen FIFO, entrega “al menos una vez”, y —según el post— unas 10 veces menos latencia de cola en la cola de los peores casos. Lo explican por capas. Primero, un queue.json que se reescribe completo cada vez, usando compare-and-set (CAS) con escrituras condicionales para lograr actualizaciones atómicas sin locks. Los productores añaden trabajos, y los workers reclaman el primero no reclamado marcándolo en progreso; si el CAS falla por contención, reintentan. Pero object storage tiene límites: overwrites de hasta ~200 ms y, en algunos servicios, rate limits por objeto. Entonces meten group commit: se bufferizan múltiples peticiones y se vuelcan juntas en una sola escritura CAS. Y como aun así muchos clientes compiten, añaden el broker: el único que toca object storage, agrupando commits y confirmando a clientes solo cuando el cambio es duradero. Para alta disponibilidad, si un broker tarda, los clientes levantan otro; la dirección del broker activo vive dentro del propio queue.json, y el CAS evita corrupción aunque haya solapamiento momentáneo. Además, para tolerar workers caídos, incorporan heartbeats por trabajo: si el timestamp expira, otro worker puede reclamarlo. Es un buen ejemplo de “construir con primitivas simples” y aceptar el coste de reescritura, a cambio de predictibilidad operativa.

Ahora, seguridad práctica para el día a día de desarrollo: ENVeil. Es una herramienta en Rust diseñada para evitar filtraciones accidentales de secretos de .env hacia asistentes de código tipo Copilot, Cursor o Claude Code. El enfoque es radical pero sensato: que los secretos en texto plano no existan en disco. En lugar de DATABASE_URL=... tu .env pasa a tener DATABASE_URL=ev://database_url. El valor real vive en un almacén cifrado por proyecto dentro de .enveil/. Cuando ejecutas enveil run -- <comando>, ENVeil pide una contraseña maestra (sin eco y sin que quede en el historial), deriva una clave de 256 bits con Argon2id usando parámetros relativamente exigentes (64 MB de memoria, 3 iteraciones), y descifra con AES-256-GCM. Luego resuelve las referencias ev:// e inyecta las variables de entorno al proceso hijo. Importante: no hay comando “get” ni “export” para imprimir secretos, y tampoco permite pasar secretos por línea de comandos al hacer set, evitando fugas por historial o por listings de procesos. El blob cifrado usa nonce aleatorio de 12 bytes y genera uno nuevo en cada escritura para evitar reutilización peligrosa en GCM; y si hay manipulación, la autenticación falla y el programa se niega a descifrar. Incluyen tests automatizados alineados con esas promesas. Si en tu equipo ya asumís que cualquier cosa en el repo o en logs puede acabar en un modelo, esto es una respuesta concreta.

Hardware y firmware libre: un desarrollador cuenta que logró portar Coreboot/Libreboot a una ThinkPad X270 —modelo 20HM, plataforma Kaby Lake— en menos de una semana desde que se lo propuso. El relato es el típico “aprendí a golpes”, pero con detalles útiles: primero hicieron dump de la BIOS original como backup y para extraer regiones necesarias: Intel Management Engine, la región GbE para Ethernet, y el Intel Flash Descriptor, imprescindible para construir una imagen final funcional. Para leer y escribir la SPI ROM usaron un RP2040-zero con pico-serprog y flashprog, conectado con un clip SOIC-8. En el proceso, accidente: arrancaron un capacitor de la placa, lo perdieron, y tuvieron que identificarlo con serigrafía y esquemático. Era un 10 µF 0603 6.3V; lo repusieron… y encima se les volvió a despegar varias veces durante reflasheos. Una historia muy real. A nivel de software, partieron de variantes existentes —por ejemplo, el trabajo del X280— y ajustaron GPIOs y configuración por diferencias de hardware: el X270 no tiene Thunderbolt y sí tiene SODIMM. Llegaron a SeaBIOS y GRUB, pero fallaba el arranque NVMe y desaparecían NVMe y Wi‑Fi de lspci: señal de un problema en configuración de PCIe. Con ayuda en IRC (#libreboot) y Leah Rowe, iteraron ROMs de diagnóstico. El arreglo final fue fino: comparando esquemáticos X270 vs X280 vieron que en el X280 CLKREQ4 no se usaba, pero en el X270 el cableado WLAN requería otra asignación; tocó recalcular el mapeo de CLKREQ y, con eso, volvieron NVMe y Wi‑Fi. Terminan con Guix System cifrado, logs cbmem disponibles, y el autor ya subiendo cambios a deguard y coreboot para upstream. Es el tipo de progreso que hace que más hardware viejo siga siendo utilizable y auditable.

Y cierro con una pieza más humana: el paper de 1984 de M.A. (Ken) Clements sobre el desarrollo temprano de Terence Tao, basado en evaluaciones cuando tenía 7 y 8 años en Adelaide. Es un estudio de caso muy detallado: Tao logra 60/60 en una prueba ACER de operaciones, por encima de normas típicas de Year 12, resuelve problemas mentales complejos con razonamiento sorprendentemente maduro, y maneja lenguaje algebraico avanzado —hablando de leyes aritméticas y hasta definiciones tipo “grupo”— sin haber pasado por la ruta escolar estándar. El texto también subraya contexto familiar: su madre, con formación en física y matemáticas, más que “enseñar”, lo estimulaba y lo acompañaba; y Tao leía matemáticas durante horas y se autoenseñó programación en BASIC en un Commodore, escribiendo programas matemáticos desde muy pequeño. Hay datos llamativos: competir con estudiantes de Year 11 cuando él tenía 7 y quedar en el top 20 entre unos 2000; pruebas de visualización espacial por encima de medias de Year 12; y discusiones sobre el equilibrio entre evitar aburrimiento académico y cuidar el lado social y emocional. El apéndice incluye incluso una primera “publicación”: un programa en BASIC para generar números perfectos. Más allá del mito del prodigio, lo interesante es ver cómo se documenta, con instrumentos y observación, el tipo de capacidades y necesidades educativas que la escuela normal raramente sabe encajar.