0818 | Incidente en GitHub, recorte del 50% en GPT-5.6 Sol y Wiz Red Agent

Clara Vega: Bienvenidos a Hacker News diario, en Bri Radio. Soy Clara Vega.

Mateo Ruiz: Y yo soy Mateo Ruiz. Hoy arrancamos con un incidente que afectó a Github.com, y después hablamos de modelos de lenguaje, de seguridad informática y de cómo deshacerse de la inteligencia artificial más invasiva.

Clara Vega: También analizamos cambios en las reglas de Apple, una nueva versión esperada de DuckDB y una herramienta que promete acelerar el uso de tarjetas gráficas en Rust.

Mateo Ruiz: Y no faltará el lado curioso: una edición del Quake original en CD-ROM que se quedó sin espacio, y cómo Bluesky dibuja su logo en las capturas de pantalla. Todo eso, adelante.

Clara Vega: Un desarrollador difundió en Hacker News el mensaje que GitHub mostró durante un episodio de sobrecarga: "ningún servidor está disponible para atender la solicitud", y señaló que en ese momento no había un incidente registrado en el estado oficial del servicio, que apareció después. Ese apagón puntual no fue lo único que se discutió: otro usuario afirmó que GitHub ha estado cayéndose de forma intermitente durante los últimos meses y preguntó si ya tiene sentido migrar a alternativas, abriendo la conversación hacia qué opciones podrían ser viables ante una fiabilidad que percibe como en declive constante.

Mateo Ruiz: Y esa pregunta generó respuestas interesantes. Uno de los comentarios más destacados promovía una opción de integración continua llamada Deadsimple CI, que se describe como un binario único en Go, con su propia ejecución de contenedores, y que evita el caos de escribir pipelines en YAML usando en su lugar lenguajes de programación generales. Es decir, una alternativa mucho más liviana para quienes buscan salirse del ecosistema de GitHub.

Clara Vega: Lo que queda claro de la discusión es que el incidente en sí quizá no era lo más importante. La preocupación de fondo era la confiabilidad: si la plataforma se cae una vez y otra, los equipos empiezan a preguntarse si no conviene tener opciones de respaldo. Los comentarios muestran que para muchos la migración ya no es una idea descabellada, sino una posibilidad real que se está evaluando con herramientas concretas.

Mateo Ruiz: Y por eso este tipo de discusiones importan tanto. Cada caída de GitHub reabre el mismo debate sobre concentración y dependencia: cuando toda una comunidad depende de una sola plataforma, un mal día de infraestructura se siente como una interrupción global. La conversación dejó en el aire esa pregunta incómoda, si conviene poner todos los huevos en una sola canasta de desarrollo.

Clara Vega: La investigación de 404 Media sostiene que Amazon está comprando grandes cantidades de libros raros, cortándoles los lomos y escaneándolos para entrenar sus modelos de inteligencia artificial, y el equipo colocó un dispositivo de rastreo en un ejemplar que terminó en la instalación de la empresa en Las Vegas conocida como VGT3, identificada con un dinosaurio sosteniendo un libro. Ante la consulta, Amazon dijo comprar libros por canales comerciales para mejorar productos y servicios, y la discusión en Hacker News giró en torno a si esto puede ser legal: un usuario preguntó si las leyes de copyright lo permiten, y otro respondió que una copia sigue siendo una copia aunque se destruya el original, mientras se especulaba con que quizá Amazon simplemente actúa primero y enfrenta las consecuencias después.

Mateo Ruiz: Cuando los consultaron, Amazon respondió a 404 Media que compra libros a través de canales comerciales para mejorar los productos y servicios que usan los clientes. Pero el contexto del artículo importa mucho: las grandes empresas necesitan cantidades inimaginables de texto para entrenar sus modelos de lenguaje, y ya agotaron lo que hay disponible en internet. Se menciona incluso que Anthropic, en su caso, pirateó libros de forma ilegal para conseguir ese material.

Clara Vega: Y ahí es donde entran los libros raros, sobre todo los descatalogados o imposibles de encontrar en la red. Son una nueva fuente de datos muy codiciada porque casi todo lo publicado antes de dos mil veintidós no pudo haber sido escrito por un modelo de IA. Y eso importa, porque entrenar con texto generado por inteligencia artificial arriesga el llamado colapso de modelo, donde la calidad de las respuestas se degrada poco a poco.

Mateo Ruiz: En Hacker News la discusión giró en torno a la legalidad. Alguien preguntó si esto es lo que dictan las leyes de copyright, y un usuario respondió con una frase contundente: una copia sigue siendo una copia aunque destruyas el original. Otros especularon con que quizá hay un área gris si no se publicaran los escaneos, y que Amazon podría estar simplemente actuando primero y enfrentando las consecuencias después. Un debate donde el valor de esos libros raros choca de frente con la necesidad insaciable de datos de entrenamiento.

Clara Vega: OpenAI recortó a la mitad el precio de GPT-5.6 Sol, y en Hacker News se preguntan hasta dónde llegará esa estrategia. En OpenRouter, un usuario apuntó que el modelo Luna dio un salto enorme tras su propia rebaja de precio y ahora es de los más competitivos en su nuevo rango, lo que sugiere que quizá OpenAI quiere medir cuánto mercado puede capturar con Sol a ese precio, aunque el mismo comentario advirtió que ya hay modelos más baratos con una inteligencia comparable, citando a Grok 4.6 a seis dólares al mes como una competencia que hace más dura la apuesta.

Mateo Ruiz: Pero la comparación no fue tan limpia para OpenAI. En la discusión se destacó que ya hay modelos más baratos con una inteligencia comparable a la de Sol, y el ejemplo más mencionado fue Grok 4.6, a un precio que lo hace una alternativa seria. Es decir, la rebaja de Sol la pone más competitiva, pero todavía queda por ver si basta para diferenciarse frente a rivales que ya estaban posicionados en ese rango de precio.

Clara Vega: Y más allá del precio, hay otra discusión en curso sobre qué hace especial a Sol: sus capacidades de visión. Un comentario destacaba que GPT es realmente bueno mirando imágenes, y que esa es una de sus mayores fortalezas, mientras que los modelos de Claude pueden ser muy buenos en lenguaje pero se degradan bastante cuando necesitan analizar una imagen, juzgar si un diseño es bueno o señalar qué partes requieren mejora.

Mateo Ruiz: Entonces hay dos batallas en juego con este recorte de precio. Una es la guerra frontal por cuota de mercado, donde Sol intenta ganar clientes que hoy se van a opciones más baratas de similar capacidad. Y la otra es su apuesta por la visión, donde se posiciona como el modelo de visión más sólido que OpenAI haya lanzado. Si ambas estrategias funcionan, el recorte de precio podría ser una jugada doble bastante inteligente. Y con esto cerramos el panorama de las novedades de la semana. Gracias por acompañarnos hasta aquí, y nos escuchamos en la próxima.

Clara Vega: Alibaba ha lanzado el modelo Qwen 3.8 en su versión de 27 mil millones de parámetros, de pesos abiertos, y según el análisis de Artificial Analysis alcanza 52 puntos en su Índice de Inteligencia, lo que lo sitúa entre los modelos líderes en inteligencia y bien posicionado en precio frente a otros modelos abiertos de tamaño similar. En Hacker News, un comentarista lo coloca a la par de GLM 5.2 y GPT 5.6 Luna, modelos mucho más grandes, y otro apunta que iguala la puntuación del último DeepSeek Flash 0731, de 284 mil millones de parámetros, siendo el segundo mejor modelo Qwen por detrás de la versión Max. La discusión técnica matiza los benchmarks: cuando alguien pregunta si el recuento de parámetros activos importa más que el total, otro usuario responde que en realidad no se sabe el tamaño real de esos modelos, mientras un tercero replica que el tamaño del GLM 5.2 se conoce con exactitud y que hay datos suficientes para concluir algo sobre Luna, a lo que otro responde que eso dice bastante de lo útiles que son estos indicadores. El análisis apunta además que la 3.8 rinde ligeramente peor que la 3.6 en precisión AA-Omniscience, lo que podría implicar que Alibaba intercambió conocimiento del mundo por capacidad en otras áreas, y que produce casi el doble de tokens por tarea que la 3.6, un posible coste necesario para lograr corrección a este tamaño de parámetros. Otra voz añade que Qwen 3.8 consume alrededor de 2,3 veces más tokens que Luna, lo que perjudica el despliegue local, mientras otro usuario defiende la tendencia hacia modelos pequeños y enfocados.

Mateo Ruiz: Y ese matiz es interesante, porque como dice otro comentarista, la 3.8 iguala la puntuación del último DeepSeek Flash 0731, que tiene 284 mil millones de parámetros, eso sí, con solo 13 mil millones activos. Es decir, el Qwen 3.8 se convierte en el segundo mejor modelo de su propia familia: muy por delante del Qwen 3.7 Max, pero claramente por debajo del Qwen 3.8 Max.

Clara Vega: Claro, y eso abrió el debate de si lo que importa es el recuento de parámetros activos o el total, y si este Qwen es un modelo denso. La respuesta técnica fue que en realidad no se sabe con certeza el tamaño de muchos de estos modelos, aunque un comentarista replicó que el de GLM 5.2 sí se conoce con exactitud y que hay datos suficientes para sacar conclusiones sobre Luna. Otro comentarista cerró esa parte con una buena observación: eso dice bastante de lo útiles que resultan estos benchmarks.

Mateo Ruiz: Porque no todo son buenas noticias para el rendimiento. Un comentarista notó que la 3.8 rinde ligeramente peor que la 3.6 en precisión en la prueba AA-Omniscience, lo que podría indicar que Alibaba intercambió conocimiento del mundo por capacidad en otras áreas. Y además produce casi el doble de tokens por tarea que la 3.6, un posible coste necesario para lograr corrección a este tamaño de parámetros.

Clara Vega: Y ese coste en tokens también pesa para quienes quieren ejecutarlo localmente. Otro comentarista señala que el Qwen 3.8 consume alrededor de 2,3 veces más tokens que el Luna, lo que perjudica el despliegue local. Aun así, hay quien defiende esta tendencia hacia modelos pequeños y enfocados: un comentarista cuenta que usa un modelo de lenguaje para trabajo técnico el 99% del tiempo, y para él modelos así son la dirección correcta.

Clara Vega: Wiz Research, la división de seguridad de Wiz, ha presentado un caso en el que su herramienta autónoma de investigación impulsada por IA, llamada Red Agent, descubrió y explotó por sí sola una vulnerabilidad de inyección de scripts en un flujo de trabajo de GitHub Actions del repositorio público snowflakedb/snowflake-connector-net, todo dentro del programa de divulgación de vulnerabilidades HackerOne de Snowflake. La falla permitía a un usuario no autenticado ejecutar comandos arbitrarios dentro de un runner de GitHub Actions simplemente abriendo un issue con un título especialmente diseñado. Se introdujo el 18 de junio de 2026, cinco días antes del descubrimiento, mediante el PR 1218 coautoreado por Copilot Autofix impulsado por IA, que eliminó el patrón seguro existente de pasar el título por una variable de entorno y construir el payload JSON con jq, y lo reemplazó por interpolación directa en un script de shell. El workflow se activaba con issues abiertos, de modo que cualquier usuario de GitHub podía dispararlo, y la condición que parecía protectora comparaba datos que en eventos de issues siempre son nulos, así que todo el mundo superaba el filtro. La explotación aprovechaba que una comilla simple en el título rompe el comando de bash y permite ejecución arbitraria. En el primer intento, un carácter de comentario estándar produjo un error de sintaxis; Red Agent analizó el error de forma autónoma, ajustó el payload para cerrar el bloque y completó la explotación sin intervención humana.

Mateo Ruiz: Y la historia de esa vulnerabilidad cuenta mucho sobre los riesgos de las herramientas de IA que escriben código. La falla era una inyección de scripts que permitía a un usuario no autenticado ejecutar comandos arbitrarios dentro del runner de GitHub Actions, con un simple título de issue cuidadosamente diseñado. Lo notable es cómo se introdujo: se agregó el 18 de junio de 2026, apenas cinco días antes de que Red Agent lo descubriera.

Clara Vega: Y aquí viene lo revelador del caso. El cambio llegó a través de un pull request para actualizar los flujos de trabajo de Jira, y fue coautoreado por Copilot Autofix, la herramienta de IA de GitHub. El asistente eliminó el patrón seguro que ya existía —que pasaba el título del issue por una variable de entorno y construía el payload JSON con jq— y lo reemplazó por interpolación directa del título del issue directamente en un script de shell.

Mateo Ruiz: O sea, la propia IA sustituyó una práctica segura por una vulnerable, y la redacción del flujo no protegió nada: se activaba con cualquier issue abierto, así que cualquier usuario de GitHub podía dispararlo. Había una condición que parecía protectora, pero comparaba el login del autor de un pull request, y en eventos de issues esa variable siempre es nula, así que todo el mundo pasaba el filtro.

Clara Vega: Y en la explotación tampoco fue un camino recto. El ataque aprovechaba que una comilla simple en el título rompe el comando de shell y permite ejecución arbitraria. Pero en el primer intento, un carácter de comentario estándar produjo un error de sintaxis de bash. Lo impresionante es que Red Agent analizó ese error de forma autónoma, ajustó su payload para cerrar el bloque correctamente, y terminó explotando la vulnerabilidad con éxito.

Mateo Ruiz: Un ejemplo real de cómo un agente de IA puede adaptarse y resolver un fallo en su propio intento de explotación, y al mismo tiempo un recordatorio de que revisar el código que generan las herramientas de IA no es opcional, incluso cuando el cambio parece menor y viene firmado por un asistente.

Clara Vega: Una guía práctica de librarian.net, titulada cómo desactivar o evitar la IA intrusiva y compartida en Hacker News, recoge que una de las preguntas más frecuentes en el horario de atención de la biblioteca, junto con qué está ocupando todo mi almacenamiento en la nube, es cómo apagar o esquivar la IA cada vez más presente en el software. El artículo, dirigido a quien quiera menos IA en su entorno tecnológico, detalla pasos para Adobe Acrobat y Reader, Android y Gemini, Apple Intelligence y Siri —que según el artículo solo existe en iPhone 16 y Macs y iPads más nuevos—, Chrome y Edge, Firefox 148 o posterior con su bloqueo de mejoras de IA, la versión sin IA de DuckDuckGo y los smart features de Google Workspace. La discusión gira sobre si la gente quiere o no estas funciones: un comentarista dice que las empresas imponen funciones que nadie quiere y que además son caras de operar, y que el mercado puede seguir irracional mucho tiempo. Otro se pregunta si el mercado es en realidad irracional o si simplemente no vemos lo que hacen, y sospecha que muchos rechazan la IA pero la usan a regañadientes, y que la estrategia podría ser hacerla tan invasiva y tan cara de revertir que empresas y gobiernos no den marcha atrás. Un tercero responde que nadie quiere botones animados de pregunta a la IA ni que las funciones útiles sean reemplazadas por ellos, aunque hay contraejemplos: un usuario cuenta que amigos suyos planean sus vacaciones con ChatGPT sin usarlo a regañadientes, y otro señala que mucha gente usa estas herramientas.

Mateo Ruiz: Es un artículo pensado para quien quiera menos IA en su entorno tecnológico, y recorre los pasos en los principales jugadores: Adobe Acrobat y Reader, Android con Gemini, Apple Intelligence y Siri —que según la guía solo existe en iPhone 16 y en Macs y iPads más nuevos—, Chrome y Edge, Firefox 148 o posterior con su bloqueo de mejoras de IA, la versión sin IA de DuckDuckGo y los smart features de Google Workspace.

Clara Vega: La parte más jugosa viene en los comentarios, donde la discusión gira en torno a si la gente realmente quiere estas funciones. Un comentarista dice que las empresas imponen funciones que nadie quiere y que además son caras de operar, y recuerda que el mercado puede seguir siendo irracional durante mucho tiempo.

Mateo Ruiz: Y otro va más allá y se pregunta si el mercado es irracional o si simplemente no vemos lo que está haciendo la gente. Sospecha que muchos rechazan la IA en público pero la usan a regañadientes, y que la estrategia podría ser hacerla tan invasiva y tan cara de revertir que empresas y gobiernos no se echen atrás.

Clara Vega: A eso, otro comentarista responde con contundencia: nadie quiere botones arcoíris animados que dicen pregúntale a la IA, ni que las funciones útiles sean reemplazadas por ellos. Pero también hay contraejemplos: un comentarista cuenta que amigos suyos planean sus vacaciones completas con ChatGPT, sin usarlo a regañadientes, y otro señala que mucha gente sí usa estas herramientas a diario, con una adopción enorme. En definitiva, la guía es útil para quien quiere salirse de esa ola, pero el debate de fondo —si las empresas empujan solas o reflejan una demanda real— queda abierto.

Clara Vega: El regulador alemán de competencia, el Bundeskartellamt, anunció el 17 de agosto que los compromisos ofrecidos por Apple se han vuelto vinculantes, lo que obliga al fabricante a cambiar sus normas sobre cómo los proveedores de apps pueden usar los datos de los usuarios en iPhone y iPad para publicidad personalizada. La autoridad objetó la forma en que Apple diseñó solicitudes de consentimiento distintas para sus propias ofertas y para las apps de terceros. Su marco llamado Apple Tracking Transparency Framework, el ATTF, exige a los proveedores externos de apps que, para ciertas formas de uso de datos entre empresas, obtengan no solo el consentimiento de protección de datos, sino también un consentimiento adicional mediante un aviso predefinido por Apple. Esas reglas no se aplican a las ofertas propias de Apple, que usa datos de su propio ecosistema y su propio aviso para pedir consentimiento a la publicidad personalizada. Apple considera que sus reglas cumplen el derecho de la competencia, pero ofreció compromisos que el Bundeskartellamt declaró vinculantes, con lo que el procedimiento concluyó. El presidente del regulador, Andreas Mundt, señaló que es clave que los datos personales y la privacidad estén protegidos de forma efectiva. En la discusión de Hacker News, un comentarista lamentó que el regulador solo exigiera igualdad de trato entre las apps de primera y tercera parte sin especificar cómo, y criticó que Apple haya reducido la carga de los editores terceros para recoger datos personales en lugar de aumentar la suya propia; propuso que cuando se pide igualar estándares desiguales para garantizar la competencia, la equiparación debería elevar la carga que soporta la parte favorecida, no rebajar la del resto.

Mateo Ruiz: Lo que molestaba al regulador era una asimetría clara. Apple tiene su marco llamado ATTF, el Apple Tracking Transparency Framework, que obliga a los desarrolladores externos de apps a pedir un consentimiento adicional, con un aviso predefinido por Apple, para ciertos usos de datos entre empresas. Pero esas mismas reglas no se aplicaban a las ofertas propias de Apple.

Clara Vega: Exacto. Apple usa los datos de su propio ecosistema y su propio aviso para pedir consentimiento cuando quiere hacer publicidad personalizada. O sea, una doble vara: exigencias distintas para ellas que para el resto. El presidente del Bundeskartellamt, Andreas Mundt, explicó en el anuncio que lo esencial aquí es que los datos personales y la privacidad queden protegidos de forma efectiva.

Mateo Ruiz: Apple insiste en que sus reglas cumplen con el derecho de la competencia, pero de todos modos ofrece igualar el trato. Y un detalle interesante que señaló un comentarista en el hilo de Hacker News, rad-b: el regulador exigió igualdad de trato entre apps de primera y tercera parte, pero sin especificar cómo lograr esa equiparación. Ese mismo comentarista criticó que Apple haya reducido la carga de los editores terceros para recoger datos personales, en lugar de aumentar la propia. Su propuesta era que, cuando se pide igualar estándares desiguales para garantizar la competencia, la equiparación debería subir el listón del que lo tenía más flexible, en lugar de bajar el más estricto.

Clara Vega: Y ese es el meollo del asunto. La discusión de fondo no es solo si pides permiso, sino si las reglas del juego son las mismas para todos los que compiten por la publicidad personalizada en el ecosistema de Apple. Con este compromiso vinculante, la autoridad alemana cierra el caso dejando sobre la mesa que la privacidad y la honradez competitiva tienen que ir de la mano.

Clara Vega: DuckDB acaba de levantar expectativa en Hacker News con la vista previa oficial de su versión 2.0, firmada por los creadores del proyecto, Mark Raasveldt y Hannes Mühleisen, que llegará este otoño con el nombre Cyanoptera, por el pato Anas cyanoptera. El salto de versión no es solo ceremonia: incluye un nuevo parser SQL, un nuevo formato de almacenamiento por defecto, una API de C rehecha y unos pocos cambios de ruptura, sobre más de 10.000 commits desde la v1.5 de marzo. Las novedades anunciadas incluyen DuckDB como servidor, triggers, el tipo VARIANT, I/O asíncrono y mejores métricas, registros y observabilidad. La extensión Quack, estable en v2.0, permite que cualquier proceso DuckDB sirva sus bases de datos por red y que otro DuckDB se conecte con la sentencia CONNECT; el nuevo optimizador de pushdown remoto envía SQL directamente a PostgreSQL y MySQL. Los triggers llegan en versiones BEFORE y AFTER, FOR EACH ROW y FOR EACH STATEMENT. VARIANT, estrenado en v1.5, se vuelve ciudadano de primera clase con ejecución fragmentada desde almacenamiento, pushdown de extracción y lectura y escritura de Parquet; más adelante, quizá poco después de v2.0, planean respaldar el tipo JSON con VARIANT. Varias funciones se anticiparon en la charla "State of the Duck" en DuckCon 7. En el hilo, un comentarista opina que el último año de mejoras se siente como el paso de un motor de ejecución in-process hacia la base de un data warehouse en la nube; cree que los fundadores eran reticentes a construir eso, pero sospecha que está en camino. Otro comenta que lleva tiempo usando MotherDuck como data warehouse y no se arrepiente.

Mateo Ruiz: Y no es solo un nombre bonito. Este salto de versión trae cambios profundos: un nuevo parser de SQL, un nuevo formato de almacenamiento por defecto, una API de C rehecha desde cero y unos pocos cambios que rompen compatibilidad. Todo eso por encima de más de diez mil commits desde la versión 1.5, lanzada en marzo.

Clara Vega: Entre lo más llamativo de las novedades anunciadas está que DuckDB ahora funciona como servidor. La extensión Quack, que se vuelve estable en la 2.0, permite que cualquier proceso DuckDB sirva sus bases de datos por red y que otro DuckDB se conecte con la instrucción CONNECT. Y hay un nuevo optimizador de pushdown remoto que envía SQL directamente a PostgreSQL y a MySQL.

Mateo Ruiz: También llegan los triggers, algo muy esperado, en las variantes BEFORE y AFTER, y tanto FOR EACH ROW como FOR EACH STATEMENT. Y el tipo VARIANT, que se estrenó en la 1.5, se convierte ahora en un ciudadano de primera clase, con ejecución fragmentada desde almacenamiento y lectura y escritura de Parquet. De hecho, mencionan que más adelante, quizá poco después de la 2.0, planean respaldar el tipo JSON con VARIANT.

Clara Vega: En la comunidad, este salto se lee como un cambio de época. Un comentarista, c9cf35860db4, opinaba que el último año de mejoras se siente como el paso de un motor de ejecución dentro del proceso hacia la base de un data warehouse en la nube. Reconocía que los fundadores parecían reticentes a construir eso, pero sospecha que ya está en camino. Otro usuario, jbmsf, decía que lleva tiempo usando MotherDuck como data warehouse y no se arrepiente. Así que el debate está servido: DuckDB ya no es solo la base de datos que corre en tu propia máquina, sino que está apuntando claramente a convertirse en algo mucho más grande.

Clara Vega: Un artículo académico reciente promete hacer que la programación de GPUs en Rust sea portable, segura y rápida a la vez. El trabajo, publicado en el repositorio arXiv el pasado 13 de agosto dentro de la categoría de lenguajes de programación, está firmado por Manuel Drehwald, Marcelo Domínguez, Kevin Sala, Alán Aspuru-Guzik y Johannes Doerfert. Según el resumen, la programación GPU de alto rendimiento ha impuesto tradicionalmente un compromiso entre eficiencia de ejecución y seguridad de memoria. Rust garantiza seguridad de memoria en tiempo de compilación para la CPU host mediante su estricto modelo de propiedad, pero aplicar esas restricciones a entornos de ejecución GPU masivamente paralelos había obligado hasta ahora a usar lenguajes de dominio específico ligados al proveedor o a recurrir a punteros crudos unsafe explícitos. El artículo presenta un marco de compilación GPU multivendor, de sobrecarga cero, integrado nativamente en el compilador rustc y en los backends de LLVM; aprovecha el sistema de tipos, el sistema de propiedad y las garantías de aliasing estricto de Rust para gestionar y optimizar las transferencias de datos a través de la infraestructura Offload de LLVM. Expone los desafíos técnicos de las discrepancias de ABI entre los objetivos Host y Device e introduce un pipeline de compilación en dos pasadas capaz de manejar con seguridad movimientos de memoria tanto manuales como generados por el compilador. En la evaluación sobre RAJAPerf, la solución basada en rustc genera IR de LLVM competitivo para kernels GPU y logra un rendimiento sólido frente a las líneas base nativas de CUDA.

Mateo Ruiz: El problema de fondo es conocido. La programación GPU de alto rendimiento siempre forzaba un intercambio: o tenías eficiencia de ejecución, o tenías seguridad de memoria. Rust garantiza seguridad de memoria en tiempo de compilación para la CPU gracias a su estricto modelo de propiedad, pero aplicar esas mismas garantías a un entorno GPU masivamente paralelo había obligado hasta ahora a elegir entre lenguajes de dominio específico atados al fabricante o recurrir a punteros crudos y bloques marcados como unsafe.

Clara Vega: La propuesta de este grupo es un marco de compilación GPU de varios fabricantes, integrado nativamente en el compilador de Rust y en los backends de LLVM, que aprovecha el sistema de tipos, el de propiedad y las garantías de aliasing estricto de Rust para gestionar y optimizar las transferencias de datos. Todo eso sin coste de ejecución adicional. El trabajo también expone los retos técnicos de las diferencias entre cómo se manejan las llamadas entre el host y el dispositivo, e introduce un pipeline de compilación en dos pasadas capaz de manejar con seguridad los movimientos de memoria, tanto los manuales como los que genera el propio compilador.

Mateo Ruiz: Y a la hora de medir resultados, usaron la referencia RAJAPerf. La solución construida sobre Rust genera código de LLVM competitivo para los kernels de GPU y logra un rendimiento sólido frente a las líneas base nativas de CUDA. O sea, la promesa es poder escribir código seguro en Rust y llevarlo a GPUs de distintos fabricantes, sin pagar por ello en velocidad.

Clara Vega: Y eso es lo relevante para cualquier persona que trabaje con cómputo científico o machine learning: poder quedarse dentro del modelo de seguridad de Rust sin tener que saltarse las garantías cuando llegas al mundo, mucho más salvaje, de la ejecución paralela en tarjetas gráficas. Un avance bienvenido si cumple lo que promete.

Clara Vega: El Fairphone 6 ha conseguido que su cámara principal funcione plenamente con PostmarketOS, el sistema operativo libre basado en Linux orientado a alargar la vida útil de los teléfonos, y el logro es relevante porque el soporte de cámaras ha sido históricamente uno de los puntos más débiles en los proyectos de reutilización de hardware. El avance se comunicó en una entrada publicada en catcrafts.net y llegó a la portada de Hacker News, donde la discusión no tardó en aflorar escepticismo y comparaciones con precedentes. En los comentarios, un usuario recordó que esto evoca a Pinephone Pro, un dispositivo que en su momento ni siquiera podía cumplir plenamente la función telefónica y que sufría de hardware no funcional porque sus creadores ensamblaron componentes sueltos sin un soporte de software sólido. Ese paralelismo sirve de perspectiva sobre cuánto camino queda todavía para que estos sistemas alternativos sean un reemplazo práctico del día a día. El caso del Fairphone 6, aunque señala un avance concreto en el ecosistema PostmarketOS, también subraya hasta qué punto la utilidad real de un teléfono libre depende de mucho más que de arrancar un kernel o encender la pantalla: los componentes como la cámara, el módem o los sensores son los que determinan si un dispositivo puede usarse en serio. La comunidad sabe que el soporte de cámaras ha sido tradicionalmente esquivo en estos proyectos de reutilización, así que cada paso que acerca la paridad de funciones con el sistema operativo original se recibe con interés. Desde la perspectiva del comprador o del aficionado a la tecnología, la pregunta práctica es si ese logro concreto abre la puerta a usar el Fairphone 6 como teléfono principal con software libre, o si todavía quedan demasiados cabos sueltos para que valga la pena el cambio. La respuesta, como suele pasar en este terreno, depende de las prioridades de cada usuario y de la velocidad con la que el proyecto siga madurando componente a componente.

Mateo Ruiz: Y de hecho, no todo el mundo lo recibe con entusiasmo. En el hilo de Hacker News un comentarista lo comparaba con la experiencia del PinePhone, recordando que ese dispositivo a duras penas cumplía la función de teléfono y que mucho hardware quedaba inoperante por falta de soporte de software.

Clara Vega: Esa comparación no es casual. La promesa de PostmarketOS y de proyectos similares siempre ha sido dar una segunda vida al hardware, pero el camino hasta que cada componente responde correctamente suele ser largo y lleno de complicaciones técnicas.

Mateo Ruiz: La gracia aquí es justamente que la cámara principal, que suele ser el componente más difícil de domar en estos esfuerzos, ya está funcionando. Eso marca un punto de inflexión para que el Fairphone 6 se vuelva una opción seria para quien quiera alejarse de los sistemas propietarios sin sacrificar lo esencial.

Clara Vega: Queda la duda de hasta qué punto un logro como este se traslada al resto del teléfono. La referencia al PinePhone nos recuerda que un elemento funcionando no garantiza que la experiencia completa esté lista para el uso diario.

Clara Vega: El CD de Quake Shareware pasó a la historia por una curiosidad técnica: estaba tan repleto que los desarrolladores tuvieron que recurrir a trucos para que todo cupiera en el límite físico del soporte, un caso clásico de cómo la restricción de capacidad obliga a soluciones ingeniosas. La historia, documentada por Fabien Sanglard, llegó a Hacker News y generó una discusión que se desvió rápidamente hacia el terreno del cifrado y de qué se considera realmente seguridad por oscuridad. En los comentarios, un usuario cuestionó si es justo calificar este tipo de algoritmos como "seguridad por oscuridad", argumentando que si se aplicara esa misma lógica, la criptografía simétrica real también encajaría en la categoría, puesto que al fin y al cabo es matemática que intercambia datos con otros bytes basándose en una contraseña o clave que permanece oculta. Ese debate invita a pensar sobre la frontera entre la ofuscación como obstáculo deliberado y los mecanismos criptográficos formales cuya fortaleza se sustenta en supuestos matemáticos y no en mantener secreto el algoritmo. En el contexto del CD de Quake, el ingenio no buscaba proteger nada, sino simplemente exprimir cada megabyte disponible para que la demo cupiera en el disco sin sacrificar contenido. Los trucos empleados suelen despertar fascinación entre quienes aprecian el límite del hardware como un acicate para la creatividad, una época muy distinta a la actual, donde el almacenamiento barato eliminó casi por completo ese tipo de constricciones. Más allá de la nostalgia, la historia sigue siendo un buen ejemplo de cómo la ingeniería se adapta a las restricciones del soporte físico, y de cómo incluso el software de entretenimiento de ese entonces llevaba dentro decisiones de bajo nivel dignas de estudio.

Mateo Ruiz: Y en el hilo de Hacker News, la discusión derivó hacia una pregunta interesante: ¿es justo llamar a estos métodos "seguridad por oscuridad"? Un comentarista señalaba que, con esa lógica, la criptografía simétrica de verdad también podría considerarse lo mismo, porque al final sigue siendo una matemática que intercambia bytes usando una clave que se mantiene oculta.

Clara Vega: Es un buen punto para reflexionar. La diferencia parece estar en la intención y en la solidez del método, más que en el simple acto de ocultar información. Un truco para que un archivo entre en un CD no tiene por qué compartir la misma categoría que un mecanismo de cifrado diseñado para proteger datos.

Mateo Ruiz: Y esa distinción importa porque ambos casos se resuelven literalmente con bytes intercambiados, pero uno depende de mantener secreto el cómo, mientras que el otro puede ser examinado públicamente y seguir siendo seguro.

Clara Vega: Al final, el caso de Quake Shareware queda como un recordatorio de que la creatividad técnica nace muchas veces de la escasez de espacio, y de que las etiquetas que usamos para describir esos trucos merecen un análisis más cuidadoso.

Mateo Ruiz: Bluesky ha adoptado un truco de interfaz para que su logo aparezca en las capturas de pantalla, y según el artículo "How Bluesky draws its logo on screenshots", publicado por Tim Marinin el domingo 16 de agosto de 2026, el secreto es un humilde UITextField. Al capturar un post, el logo se ve en la esquina superior derecha, aunque durante el uso normal esa zona muestra un botón "Follow". Marinin comprobó que el logo no aparece en una captura tomada a mitad del gesto de cambiar de app, cuando el botón "Follow" sí se ve. Como Bluesky es de código abierto o al menos tiene el código disponible, encontró la respuesta en un archivo llamado GrowthHack.tsx, introducido en enero de 2026 por mozzius, que depende del paquete expo-privacy-sensitive, también de mozzius. El paquete crea un UITextField con la propiedad isSecureTextEntry activada y renderiza el contenido del botón en la capa de ese campo; al capturar pantalla, iOS enmascara el UITextField y deja ver el logo oculto debajo. En otras plataformas el contenido se renderiza sin enmascarado. Marinin, que se declara no desarrollador de iOS, especula que al cambiar de app iOS toma una instantánea al inicio del gesto sin activar el enmascarado, así que no hay una instancia viva del UITextField que reaccione. El autor considera el truco "cute", señala que la gente en el hilo mayormente no lo apoyaba antes de que el hilo se bloqueara, y apunta que la técnica es conocida, ya que Telegram implementó algo similar para sus chats secretos y Signal también, por lo que no espera que Apple la parchee pronto.

Clara Vega: ¿Y cómo es que puede pasar eso? La explicación está en que Bluesky, al ser de código abierto, deja ver la respuesta en un archivo llamado GrowthHack. Ese código crea un campo de texto con una propiedad de seguridad activada que hace que iOS lo enmascare automáticamente al momento de capturar la pantalla.

Mateo Ruiz: O sea, el truco juega con cómo funciona el sistema. Al tomar una captura, iOS oculta el contenido de ese campo por seguridad —igual que hace con las contraseñas— y lo que queda visible debajo es el logo que estaba oculto. Marinin, que se confiesa no desarrollador de iOS, notó que en pleno gesto de cambiar de app la captura muestra el botón de seguir y no el logo, algo que atribuye a la forma en que el sistema toma la instantánea al inicio del gesto.

Clara Vega: Y aunque suene a algo nuevo, la técnica es más vieja de lo que parece. Telegram ya implementó algo parecido para sus chats secretos y Signal también lo hizo. El autor cree que es un truco simpático y no espera que Apple lo corrija pronto, justamente porque tiene precedentes en apps conocidas.

Mateo Ruiz: Queda entonces la duda de si veremos más marcas copiando la idea, pero lo claro es que este tipo de detalles creativos son los que hacen que una app destaque en las capturas que la gente comparte todos los días.

Clara Vega: Y con esto cerramos el episodio de hoy. Gracias por acompañarnos hasta el final.

Mateo Ruiz: Nos escuchamos en la próxima entrega. Que tengan un gran día, y hasta entonces.