
1011 | Código, datos y decisiones: la semana en tecnología
Show notes
Un recorrido por la semana en tecnología y sociedad: IA y responsabilidad, software abierto y alternativas, grandes datos y brechas, y salud, vivienda y rarezas cultas.
Línea de tiempo
- 00:00:04 Apertura
- 00:00:40 IA y responsabilidad: decidir no es de las máquinas
- 00:03:31 Open source en disputa: licencias y alternativas
- 00:06:19 Rendimiento y sistemas: DuckDB y macOS UNIX
- 00:08:34 Datos y salud: fallas humanas, efectos reales
- 00:11:10 Vivienda: impuestos y peleas locales
- 00:13:31 Computación reimaginada: unikernels y bombilla IA
- 00:16:12 Cierre: ciencia abierta y cheques de Knuth
- 00:18:26 Cierre
Enlaces relacionados
- Computers Cannot Make Decisions
- Build your own decision model
- Nvidia in talks to acquire US 'open' model startup Reflection AI
- WallHop – 12ft.io is gone, so I built a replacement
- Talorys – A self-hosted personal AI agent on Cloudflare's free tier
- Bitwarden Dual License Model
- Why DuckDB 2.0 is faster
- Apple/macOS removed from official Unix registry
- Food processing influences metabolism and brain activity
- `123456' password used in Danish CPR data breach
- A city-building game in which the city would prefer you didn't
- I would like the value of my home to rise, while my property taxes fall
- Unikernels were hard. key word: were
- The Lightbulb Computer
- PVX-001: open-source Covid-19 vaccine starts Phase 1 trial
- Knuth reward check
Este episodio es producido por Bri. Bri usa tecnología avanzada de IA para convertir los feeds que te importan en podcasts pensados para escuchar. Puedes escribirnos a hi@bri.so.
Transcript
Clara Vega: ¡Hola y bienvenidos a otro episodio del podcast! Soy Clara Vega.
Mateo Ruiz: Y yo soy Mateo Ruiz. Y hoy tenemos un programa con un hilo muy claro que conecta casi todas las historias: la pregunta de quién responde cuando la tecnología toma el protagonismo. Hablaremos de IA y responsabilidad, de licencias open source en disputa, de rendimiento de sistemas, de datos y salud, de vivienda, de computación reimaginada y, al final, de ciencia abierta.
Clara Vega: Pero no como una lista de titulares. Vamos a entrar en los debates, a lo que la gente discutía en los comentarios: los puntos de vista, las experiencias de primera mano, los desacuerdos y las preguntas que quedan abiertas.
Mateo Ruiz: Empecemos fuerte, con el tema que más discusión generó: programas y decisiones. La tesis central de uno de los textos es demoledora: los programas no toman decisiones. Culpar a un LLM es, en realidad, blanqueo de decisiones. La responsabilidad siempre recae en personas.
Clara Vega: Es una frase que suena obvia y a la vez incómoda. Porque cuando algo sale mal, la excusa más cómoda es "fue la IA". El argumento dice: no, eso es blanqueo. Un modelo de lenguaje no firma nada, no aprueba nada, no decide nada. Alguien eligió desplegarlo, alguien eligió confiar en su salida, alguien diseñó el flujo donde su respuesta tiene consecuencias.
Mateo Ruiz: Y eso encaja perfectamente con otra historia de las últimas horas, la de Jev. Como comentaban varios lectores, se puede emular un modelo de decisión en un LLM restringiendo los tokens de opción, y Jev hace exactamente eso: salidas calibradas. Es decir, en vez de dejar que el modelo "decida" libremente, se le encierra en un conjunto de opciones predefinidas.
Clara Vega: Y aquí había dos lecturas en el hilo. Una optimista: si el modelo solo puede elegir entre opciones acotadas y calibradas, el "problema de la decisión autónoma" se dispara en falso, porque en el fondo el diseño humano sigue definiendo el espacio de decisiones. Es como decir que el modelo es el dedo que pulsa el botón, pero el botón lo puso una persona.
Mateo Ruiz: La lectura crítica era otra: aunque restrinjas los tokens de opción, alguien tiene que decidir qué opciones están disponibles y qué significa "calibrado". Así que el argumento de fondo no cambia, simplemente se mueve un nivel más arriba del código. Y de hecho algunos comentaristas decían que Jev es la mejor prueba del argumento de origen: si necesitas diseñar cuidadosamente el espacio de opciones para que el sistema sea útil y seguro, entonces la decisión importante nunca fue del modelo.
Clara Vega: Añádele la tercera pieza: Reflection AI, la startup de modelos abiertos con la que Nvidia habría negociado su compra. Y aquí la discusión no era sobre el modelo en sí, sino sobre la consolidación vertical. Nvidia fabrica los chips, desarrolla el software de cómputo y, si compra la startup, también controla quién hace los modelos que corren en esos chips.
Mateo Ruiz: Y conectando con el hilo de responsabilidad: si cada capa del stack la posee el mismo actor, ¿a quién culpas cuando algo falla? Hay gente en los comentarios que veía en la posible compra una señal de mercado sana, inversiones que llegan a startups de modelos abiertos. Otros señalaban que "abierto" y "controlado verticalmente" son cosas que pueden convivir en el discurso y no en la práctica.
Mateo Ruiz: Y otros directamente preguntaban si la noción de "decisión de la IA" sobrevivirá si los actores que la despliegan son cada vez más grandes y más responsables de cada capa.
Clara Vega: Lo que sigue abierto, y valga la pena decirlo, es quién responde legalmente. La discusión es ética y estructural, pero los marcos legales de responsabilidad humana sobre IA siguen en construcción. Nadie en los comentarios tenía una respuesta cerrada, y eso es lo interesante: el consenso era en el diagnóstico, el blanqueo de decisiones existe, pero no en el remedio.
Mateo Ruiz: Bueno, y justo esa palabra, "abierto", nos lleva al siguiente bloque, porque también andaba en disputa. Tres historias, una pregunta: ¿qué significa realmente "open source" hoy?
Clara Vega: La primera es WallHop. Es gratuito, sin registro, y se presenta como sustituto de 12ft.io, el servicio para leer artículos sin paywall. Para lograrlo bifurca ladder, que está bajo licencia GPL-3.0. Pero hay un detalle: WallHop en sí aún no es open source.
Mateo Ruiz: Y ahí se armó la discusión clásica. Unos decían: si bifurcas un proyecto GPL y no publicas tu código, estás al borde de violar la licencia, o al menos traicionando el espíritu de lo que estás reutilizando. Otros mataban el matiz: "aún no es open source" sugiere que puede llegar a serlo, y mientras tanto el proyecto funciona y la gente lo usa.
Mateo Ruiz: Pero había quien veía el patrón conocido: publicar la herramienta, cerrar el código, y dejar que la comunidad descubra más tarde si había obligaciones de licencia.
Clara Vega: Y como contraste, el segundo caso: Bitwarden, el gestor de contraseñas. Anunció que publicará las apps de las tiendas de aplicaciones como builds con licencia comercial, mientras mantiene la versión GPLv3 en GitHub.
Mateo Ruiz: Esta fue quizá la discusión más matizada del día. Porque hay precedentes reales de este esquema: proyectos que mantienen la licencia libre en el repositorio principal y al mismo tiempo distribuyen binarios con licencias más restrictivas. Los defensores decían: es la forma sostenible de financiar desarrollo sin traicionar la licencia, el código sigue ahí, puedes bifurcar si no te gusta.
Mateo Ruiz: Los críticos respondían: la experiencia real del usuario pasa por los builds de las tiendas, no por GitHub, así que en la práctica la mayoría usa la versión con licencia comercial, y la GPL se convierte en una licencia para contribuidores, no para usuarios.
Clara Vega: Otro punto que salió: la palabra "build". No es el mismo código con otra etiqueta; son compilaciones oficiales con licencia distinta según el canal de distribución. Y eso genera una pregunta que quedó abierta: ¿importa la licencia si el canal de distribución la hace irrelevante para el 95% de los usuarios?
Mateo Ruiz: Y la tercera pieza del bloque, más tranquila: Talorys. Un agente de IA personal que puedes autohospedar con un solo comando en tu cuenta de Cloudflare. Licencia MIT, sin telemetría.
Clara Vega: Aquí el comentario mayoritario era positivo, casi de alivio. En un momento en que Bitwarden comercializa builds y WallHop no publica código, un proyecto que dice "aquí tienes el comando, aquí tienes MIT, aquí tienes cero telemetría" se lee como la encarnación del ideal que los otros dos proyectos desdibujan. Y había quien lo señalaba explícitamente: "esto es lo que open source debería significar".
Clara Vega: También surgía el matiz práctico de autohospedar en Cloudflare: no es exactamente tu servidor, es la infraestructura de un tercero, aunque el código sea tuyo. Pero en general, la comparación entre las tres historias dejaba claro que "abierto" hoy es un espectro, no una etiqueta binaria.
Mateo Ruiz: Y de espectros pasamos a sistemas, que es un tema más técnico pero con la misma pregunta de fondo: ¿qué pasa cuando la interfaz esconde el motor? Dos historias aquí.
Clara Vega: La primera es DuckDB 2.0 y su nueva E/S asíncrona. La idea es elegante: un grupo dedicado se encarga de descargar datos mientras otros hilos decodifican lo que ya llegó. Con ese cambio, las lecturas desde S3 bajaron de 18,8 segundos a 7,7.
Mateo Ruiz: Y eso en los comentarios generó una discusión técnica muy rica. Los que sabían del tema explicaban por qué esto importa: leer desde S3 es lento por latencia de red, y si todo el pipeline espera a que lleguen los datos antes de decodificar, estás desperdiciando tiempo de cómputo. Al superponer descarga y decodificación, conviertes dos tiempos secuenciales en uno solapado. Un factor de mejora de más de dos veces no es magia, es pipelining bien hecho.
Clara Vega: Había experiencias de primera mano en el hilo, gente que decía que sus cargas de trabajo analíticas sobre objetos remotos eran el cuello de botella exacto que esto resuelve. Otros hacían la pregunta obvia: ¿esto acelera también el caso local o solo el remoto? Y la respuesta que se deducía del diseño es que el beneficio principal está donde la descarga domina, es decir, en almacenamiento remoto como S3.
Mateo Ruiz: Y el otro punto de discusión, más conceptual: varios comentaristas señalaban que esto es un recordatorio de que la arquitectura de bases de datos no está "terminada". Cada cambio en la infraestructura subyacente, en este caso el almacenamiento de objetos como estándar, exige rediseñar las capas internas. La I/O asíncrona no es una optimización menor, es una reestructuración de cómo el motor piensa sobre el tiempo.
Clara Vega: Y la segunda historia del bloque, más curiosa: macOS sigue certificado UNIX 03. Su ausencia aparente del registro del Open Group parece ser simplemente un fallo de renderizado del sitio.
Mateo Ruiz: Esta historia es corta pero los comentarios se extendieron. Porque lo interesante no es el certificado en sí, sino lo que revela: el registro oficial puede fallar en mostrarte el estado real, y todos asumimos que lo que se ve en pantalla del organismo certificador es la verdad. Un fallo de renderizado, literal, casi genera un mito: "macOS ya no es UNIX". Gente en el hilo confesaba haberlo creído al ver el registro vacío.
Mateo Ruiz: Y el argumento de fondo era: los sistemas que dependemos para establecer hechos técnicos también tienen bugs.
Clara Vega: Y ya que hablamos de fallas que revelan mucho más de lo que parece, pasemos a datos y salud, donde lo aparentemente simple esconde consecuencias grandes. Dos casos.
Mateo Ruiz: El primero es escandaloso por lo básico: la masiva brecha de datos de los registros CPR daneses ocurrió porque la contraseña era '123456'.
Clara Vega: Literalmente '123456'. Y la reacción en los comentarios fue de dos tipos. El primero, incredulidad: un sistema con datos tan sensibles como los registros civiles de un país entero, protegido por la contraseña más usada del mundo. El segundo tipo de reacción, más reflexivo, decía: esto no es un caso raro, es el estado natural de la seguridad en sistemas grandes.
Clara Vega: El eslabón débil no es el cifrado ni la arquitectura, es el proceso humano: quién elige las credenciales, quién las revisa, quién exige políticas básicas.
Mateo Ruiz: Y ahí se cruzaba con la discusión de responsabilidad del principio del programa: si una brecha de este tamaño ocurre por '123456', ¿culpa del programa que aceptó esa contraseña o de la persona que la eligió? Los comentaristas no llegaron a un acuerdo, pero la pregunta sola ya dice mucho de lo que hablamos al inicio.
Clara Vega: El segundo caso es del campo de la salud: el estudio de Virginia Tech comparó comidas ultraprocesadas frente a no-ultraprocesadas con nutrientes equiparados, y encontró que producen respuestas metabólicas y cerebrales distintas.
Mateo Ruiz: Y este fue, para mucha gente, el hallazgo más importante del día. Porque durante años la discusión sobre comida ultraprocesada se ha movido en dos campos: los que dicen "es solo comida con mucha sal, azúcar y grasa", y los que dicen "hay algo en el procesamiento en sí".
Mateo Ruiz: Este estudio apunta a la segunda: si equiparas los nutrientes, igualas macro y micronutrientes, y aun así las respuestas del metabolismo y del cerebro son distintas, entonces la forma de la comida importa más que su etiqueta nutricional.
Clara Vega: Los comentarios ahí eran muy interesantes. Algunos con experiencia en nutrición explicaban que esto confirma lo que la industria lleva décadas explotando: puedes hacer que un producto cumpla la tabla nutricional y aun así sea otro animal biológicamente. Otros pedían cautela: un estudio no cierra el debate, falta saber qué mecanismo lo explica, si es la matriz del alimento, los aditivos, la velocidad de ingesta. Esa pregunta quedó explícitamente abierta en el hilo.
Mateo Ruiz: Y había una conexión que varios hicieron y que a mí me gustó: igual que la brecha danesa, aquí lo simple, "comer menos ultraprocesados", esconde una pregunta grande: ¿qué define exactamente "ultraprocesado"? La clasificación existe, pero los mecanismos biológicos detrás de por qué importan son precisamente lo que este estudio ayuda a desentrañar y a la vez a abrir.
Clara Vega: Pasemos ahora a vivienda, otro territorio donde reglas formales configuran algo muy cotidiano: dónde y cómo puedes vivir. Dos historias.
Mateo Ruiz: La primera es estructural: las reformas fiscales en Estados Unidos han reducido impuestos a propietarios de vivienda y los han trasladado a las propiedades comerciales. El efecto documentado es que suben los costos de vivienda.
Clara Vega: Y aquí la discusión en los comentarios fue de economía política. La cadena causal es la clave: si bajas impuestos a los residenciales y compensas subiendo impuestos a los comerciales, los propietarios de locales comerciales trasladan ese costo a sus inquilinos, que son negocios, y esos negocios trasladan sus costos a los precios... y el costo de la vida sube, incluyendo, irónicamente, la vivienda. Es un impuesto que dijo apuntar a un lado y aterriza en el otro.
Mateo Ruiz: Varios comentaristas señalaban que esto es el ejemplo de libro de texto de por qué los debates fiscales simplificados, "bajar impuestos a X es bueno", fracasan: los impuestos no recaen donde se colocan, recaen donde puede trasladarse. Y otros discutían si el efecto es siempre igual de fuerte o depende del mercado, si en zonas con mucho vacante comercial el propietario no puede trasladar tanto. Ese matiz, la elasticidad de cada mercado, era el punto de desacuerdo real en el hilo.
Clara Vega: Y la segunda historia es una forma preciosa de hacer tangible todo esto: Discretionary Review, un simulador de vivienda de San Francisco donde cada sitio es una pelea real, con leyes y casos del registro público.
Mateo Ruiz: Sí, y esto conecta directo con lo anterior. El simulador te pone en el proceso real: usar la ley para pelear por un sitio, con casos reales como material. La reacción en los comentarios era doble. Por un lado, entusiasmo: por fin una forma de entender, jugando, lo complejo y lento que es construir o acceder a vivienda en una ciudad como San Francisco.
Mateo Ruiz: Por otro, la lectura política: el simulador demuestra que el cuello de botella de la vivienda no es técnico ni económico en primer término, es procedimental. Cada decisión pasa por peleas legales, y esas peleas están hechas de reglas formales, las mismas reglas formales que las reformas fiscales del otro hilo.
Clara Vega: Y de nuevo, la misma idea que atraviesa el episodio: las reglas, los procesos, los tokens de opción que definimos, son los que determinan el resultado. La vivienda no es distinta a la IA en ese sentido: detrás de cada resultado hay un diseño humano de reglas, y preguntarse "quién decidió" es la pregunta correcta en ambos casos.
Mateo Ruiz: Muy bien dicho. Y justamente, del diseño de reglas pasemos al diseño desde cero, que es el tema del siguiente bloque: computación reimaginada. Dos proyectos que no mejoran lo existente, lo reemplazan.
Clara Vega: El primero es la vuelta de los unikernels. Un texto argumenta que vuelven porque la IA elimina la fricción de crearlos. La tesis: los unikernels reducen la superficie de ataque, y el sistema operativo completo es, en realidad, deuda técnica.
Mateo Ruiz: Este hilo fue muy técnico y muy Bueno. La idea del unikernel, para quien no la conozca, es que en lugar de correr tu aplicación sobre un sistema operativo general con todo su catálogo de drivers, servicios y superficies de ataque, compilas tu aplicación junto con el mínimo absoluto de sistema operativo que necesita. Nada más. El resultado es un binario único, pequeño, difícil de atacar porque casi no hay superficie donde atacar.
Clara Vega: Y el argumento de "el SO es deuda técnica" fue el que más resonó. La lógica: tu aplicación no necesita todo Linux. Necesita un puñado de syscalls, un stack de red, un disco. Todo lo demás, décadas de código heredado, parches de seguridad, CVEs, es deuda que pagas en mantenimiento y en riesgo. Durante años los unikernels fracasaron no por el concepto sino por la fricción: era demasiado difícil construirlos, depurarlos, mantenerlos.
Clara Vega: Y la apuesta del argumento es que la IA cambia esa ecuación: ahora generar y mantener un unikernel a medida es viable.
Mateo Ruiz: Los escépticos en el hilo pedían pruebas: la fricción no era solo escribir código, era el ecosistema, la observabilidad, las herramientas. ¿La IA resuelve eso también? Los entusiastas respondían que las herramientas de desarrollo asistido atacan exactamente ese tipo de fricción acumulada. Quedó abierto, pero era una de las discusiones donde más claramente se veía que la pregunta no es si la idea es buena, sino si el momento es el correcto.
Clara Vega: Y el segundo proyecto del bloque, más experimental y visual: Lightbulb Computer. Un dispositivo con forma de bombilla que integra un proyector y visión computarizada. Hay una demo real, aunque el dispositivo es voluminoso.
Mateo Ruiz: Lo fascinante de este proyecto para los comentaristas no era tanto la utilidad inmediata, que es limitada, sino lo que implica: proyectar una interfaz sobre cualquier superficie y usar la cámara para que esa superficie se convierta en interactiva. Es repensar la computación sin pantalla, sin teclado, sin monitor. La bombilla es el ordenador.
Clara Vega: Y aquí había una comparación natural con los unikernels que varios hicieron: ambos rechazan las convenciones. Uno rechaza la convención del sistema operativo completo; el otro rechaza la convención del factor de forma. Y en ambos casos, el demo funciona pero el camino a algo práctico es incierto. La bombilla es voluminosa; el unikernel carece de ecosistema. Los comentarios coincidían en que son las apuestas que hay que seguir, no las que hay que adoptar hoy.
Mateo Ruiz: Y para cerrar, dos historias que juntan apertura y tradición en la ciencia. Empecemos por PopVax.
Clara Vega: PopVax dosificó PVX-001 en fase I. Es una vacuna contra el COVID de amplio espectro, y estable a temperatura de refrigerador, entre 2 y 8 grados. Y lo más notable: será open source al concluir el desarrollo.
Mateo Ruiz: Este anuncio dejó a la comunidad muy satisfecha, y con razón. Pensa en lo que significa cada pieza: amplio espectro significa que apunta a variantes, no a una sola; estable a 2-8 grados significa que no necesita ultracongelación, lo que en la pandemia fue uno de los mayores cuellos de botella de distribución global; y open source al concluir significa que la receta, el diseño, estará disponible. Es ciencia abierta en práctica, no en discurso.
Clara Vega: Los comentarios conectaban con el bloque de licencias del principio: aquí hay un caso donde "abierto" no es una etiqueta de repositorio de código sino un compromiso sobre un producto sanitario. Y surgía la pregunta natural: ¿cómo se financia un modelo así? Es una de las preguntas abiertas del hilo. Pero nadie discutía el valor del objetivo.
Mateo Ruiz: Y para el cierre, la historia más entrañable del día: Donald Knuth sigue enviando cheques de recompensa por errores encontrados en sus libros. Hoy, los cheques son certificados ficticios del Banco de San Serriffe.
Clara Vega: Para quien no conozca la historia: Knuth, el legendario informático, lleva décadas pagando recompensas a quien encuentre errores en sus libros, como The Art of Computer Programming. Los cheques reales dejaron de cobrarse hace mucho, pero el honor de recibir uno es enorme en la comunidad. Así que ahora emite certificados "del Banco de San Serriffe", que es una ficción geográfica clásica, un país ficticio inventado para un April Fool's Day de The Guardian en los años setenta.
Clara Vega: Es un guiño dentro de un guiño.
Mateo Ruiz: Y para cerrar el programa, la conexión con lo que venimos diciendo: Knuth lleva décadas haciendo algo que hoy llamamos "responsabilidad activa". No dice "los libros ya están publicados, si hay errores fue el proceso". Dice: yo los escribí, yo respondo, y cada error que encuentres me hace el libro mejor. Es lo contrario exacto del blanqueo de decisiones del que hablamos al principio del episodio.
Clara Vega: Precioso lugar para terminar. Entre la vacuna open source de PopVax y los cheques de Knuth, el episodio cierra con la misma nota que lo abrió: la responsabilidad y la apertura son cosas que hacen las personas, no los programas.
Mateo Ruiz: Gracias por acompañarnos, nos vemos en el próximo episodio.
Clara Vega: ¡Hasta la próxima!