Atareao con Linux

Llevo varias semanas construyendo un grafo de conocimiento con GraphRAG sobre SQLite, y en ese día a día me he topado con sqlite-utils, una herramienta que se ha convertido en mi navaja suiza para trabajar con bases de datos SQLite sin complicarme la vida. Es de esas utilidades que no sabías que necesitabas hasta que la pruebas. Te preguntarás por qué SQLite y no PostgreSQL o cualquier solución más seria. La respuesta es sencilla, porque necesito algo que quepa en mi equipo, que sea portátil y que pueda llevarme en un USB sin montar un servidor. Todo tu conocimiento, en un solo archivo que abres donde quieras. El problema de siempre ha sido inspeccionar esas bases. Abrir DBeaver o tirar de Python solo para mirar qué hay dentro da una pereza enorme, y al final acabas dejándolo. sqlite-utils, creada por Simon Willison, resuelve justo eso, y te permite consultar, filtrar, transformar y exportar sin escribir una línea de SQL ni de Python. Para que te hagas una idea, aquí hay dos cosas en una sola herramienta, una utilidad de línea de comandos y una librería de Python que no pretende ser un ORM. Nació dentro del ecosistema de Datasette, y busca que crear una base desde cero y poblarla con datos sea rápido y sin fricción. En mi caso ha acabado sustituyendo a los comandos sueltos de sqlite3 que tenía repartidos por las notas. Otro terreno donde se nota la mano es la ingesta. Con insert metes un JSON que llega por la tubería, un CSV de los que exportas de cualquier sitio, o la respuesta de una API con un curl delante. Con upsert y bulk actualizas registros que ya existían o metes miles de filas de golpe, y todo eso se encadena con jq en una sola tubería. Luego está la parte de cambiar las cosas sin dolor, renombrar una columna, borrar la que sobra o cambiar un tipo de dato. En SQL puro eso es un baile de create table, copiar los datos y borrar la tabla vieja, con el riesgo de liarla a mitad de camino. Aquí es un transform, se ejecuta dentro de una transacción y el esquema queda reescrito como si lo hubieras diseñado así desde el principio. En este episodio te cuento cómo instalarla con uv, cómo explorar tablas y esquemas, cómo navegar los datos con rows, cómo filtrar de forma segura con parámetros con nombre y cómo montar consultas complejas con joins. Además verás el combo que más me ha enganchado, sqlite-utils encadenado con jq y con llm para pasar el contexto de tu base directamente a un modelo de lenguaje. Y de propina, los detalles de mantenimiento que marcan la diferencia, como WAL, Vacuum, Optimize y la búsqueda full-text. Si tienes una base SQLite por ahí y nunca te has atrevido a mirar dentro, este es tu episodio 👍 Capítulos 0:00 - Presentación: sqlite-utils, la navaja suiza de SQLite 2:20 - Por qué SQLite: GraphRAG, portabilidad y contexto de la serie 4:20 - El problema de DBeaver y qué resuelve sqlite-utils 6:00 - Instalación con UV y primeros pasos 8:30 - Explorar tablas, columnas y esquemas 11:30 - Navegar los datos con rows 14:00 - Filtrar con where, ordenar y evitar inyección SQL 16:30 - Consultas complejas, joins y selects a medida 18:30 - El combo killer: sqlite-utils + jq + LLM 20:30 - Escribir y transformar: insertar, crear, exportar y renombrar 23:00 - El módulo Python y los consejos: WAL, Vacuum, Optimize y FTS 25:20 - Conclusiones y lo que viene en el 841 Más información y enlaces en las notas del episodio: https://atareao.es/podcast/840 🌐 Todo en https://atareao.es · ✈️ Telegram https://t.me/atareao_con_linux · 🦣 Mastodon https://mastodon.social/@atareao · 🐦 Twitter https://twitter.com/atareao · 🐙 GitHub https://github.com/atareao

Llevo más de 6.000 notas en Markdown acumuladas desde 2008, y siempre he estado convencido de que ahí estaba todo lo que he aprendido. Hasta que busco y no encuentro. Busco particiones y no aparece nada sobre redimensionar un volumen. Busco monitorización de red y mis notas hablan de ntopng e iftop sin usar esas palabras. El conocimiento estaba ahí, pero yo no sabía que estaba. En el episodio 837 te conté la teoría del GraphRAG. En este 839 vamos a lo práctico, a convertir esas 6.000 notas en un grafo de conocimiento con IA 100 % local, sin nube, sin claves API y sin que ninguna nota salga de tu equipo. Lo primero es el chunking, trocear cada nota en ideas autónomas. Y no se trocea por número de caracteres, sino por estructura. Cada sección o subcapítulo es un fragmento, el frontmatter se separa como metadatos, los bloques de código viajan enteros y lo que baja de 50 caracteres se descarta. Trocear por caracteres solo rompe un bloque de código o una lista justo por la mitad. Después viene el NER (Named Entity Recognition), que convierte texto libre en entidades con etiqueta, tipo y confianza. Uso llama3.2:3b con Ollama y solo conservo lo que supera 0,5 de confianza. Prefiero perder una entidad dudosa antes que llenar el grafo de ruido, porque un grafo con ruido no te sirve. Con eso se construyen nodos y aristas. La nota es el documento entero, la entidad puede ser Nginx, Certbot o SSL, y las etiquetas salen de las carpetas y del frontmatter. Hay cuatro tipos de arista y cada una lleva su peso. La co-ocurrencia usa el mínimo de las dos confianzas, no la media. Para construir todo esto ejecutas graphrag build. No empieza de cero, cada nota guarda un hash SHA256 y solo reprocesa lo que ha cambiado. En mi caso encontró 6.333 archivos y le faltaban 81, unos seis minutos, con cuatro hilos y un único escritor sobre SQLite. Y luego están las comunidades, la visión global. El algoritmo Leiden agrupa los conceptos muy conectados entre sí, porque los amigos de mis amigos tienden a formar un grupo. Todo esto es graphrag-search, un único binario en Rust que instalas con cargo install graphrag-search. Ni Python, ni NPM, ni servidores. Con dos modelos pequeños de Ollama, bge-m3 para embeddings y llama3.2:3b para el NER, tienes tu propio cerebro conectado para encontrar episodios y conceptos relacionados. Capítulos del episodio: 0:00 - Introducción: convertir 6.000 notas en un cerebro conectado 2:45 - Qué veremos hoy y la trilogía GraphRAG 4:20 - Chunking: trocear las notas en ideas autónomas 7:50 - NER: extraer entidades con un modelo local 7:50 - NER: extraer entidades con un modelo local 11:20 - Etiqueta, tipo y confianza: qué guardamos de cada entidad 13:50 - Nodos y aristas: conectar tus notas con semántica 17:10 - Construir el grafo con graphrag build 20:20 - SQLite e incrementalidad: el grafo que se actualiza solo 24:10 - Comunidades con el algoritmo Leiden 27:00 - Cierre y avance del siguiente episodio Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Los metadatos de tus notas son puro oro, y me da la sensación de que todavía no lo sabes. Tienes títulos, fechas de creación, etiquetas... toda esa información del front matter de cada Markdown que, la mayoría de las veces, se queda ahí muerta de risa sin que le saques partido. En los episodios 819 y 821 te conté cómo la extraía con Python para montar un grafo de conocimiento. Funcionaba, pero para cualquier consulta rápida tenías que abrir el script, tocar el código y volver a ejecutarlo. Eso no es ágil. En este episodio te presento al dúo dinámico: jq y yq. Dos herramientas que hacen una sola cosa y la hacen de maravilla, esa vieja filosofía UNIX que tanto nos gusta. jq es el procesador de JSON de referencia desde 2012, escrito en C y presente en casi todas las distribuciones. yq es el mismo concepto para YAML, XML, INI, TOML y CSV, escrito en Go por Mike Farah y distribuido como un binario único sin dependencias. Con las dos, y sin escribir ni una línea de Python, vas a extraer, filtrar y conectar los metadatos de tus notas. Arrancamos con lo básico de jq, sus filtros y sus cuatro funciones estrella, select, unique, map y group_by. Son las que vas a reutilizar una y otra vez. Después pasamos a yq y a su joya de la corona, el soporte nativo de front matter. Con una línea tipo yq --front-matter=extract '.tags' nota.md sacas las etiquetas de una nota, y con -i la editas in place, algo que jq no permite. Actualizar la fecha de modificación, añadir un tag nuevo o convertir de YAML a JSON y al revés sin salir de la terminal. Y luego llega la parte divertida, los pipelines. Encadenando fd, yq y jq consigues una lista limpia de los tags de tu vault, un informe con cuántos documentos usan cada etiqueta o el grafo de conocimiento completo en JSON, con nodos y aristas, sin Python y sin IA. También te enseño a detectar esas notas viudas que no tienen etiqueta y a cerrar el círculo pasando ese JSON a un modelo local con Ollama, para que te clasifique las notas y te diga qué conexiones hay entre ellas. Terminamos con los errores más habituales, que ya me he encontrado de todo. Que yq solo procesa el primer documento si le pasas varios ficheros, que un front matter sin los delimitadores --- no lo reconoce nadie, o que jq no tiene edición in place. Pequeños tropiezos que te ahorro para que no pierdas media tarde peleándote con la terminal. Si tienes un vault de notas, aunque sean solo diez archivos, este episodio te va a cambiar la forma de trabajar con ellos. Y si te gusta domar tus datos con herramientas pequeñas y afiladas, más todavía. Suscríbete al podcast, déjame una valoración y compártelo con quien todavía escriba un script de Python para leer un YAML. La semana que viene, en el 839, seguimos con el grafo de conocimiento y la IA local. Capítulos: 0:00 - Introducción: yq y jq, el dúo dinámico 3:15 - Filosofía UNIX: domar datos sin escribir Python 5:45 - Qué es jq y qué es yq 8:00 - Filtros básicos con jq 10:45 - Funciones clave de jq: select, unique, map y group_by 13:15 - yq y Front Matter: extraer metadatos 16:00 - Edición in-place y conversión YAML ↔ JSON 18:30 - Pipelines: fd + yq + jq para extraer tags 21:00 - Del Front Matter al grafo de conocimiento 22:45 - Notas viudas y pipeline con IA local 24:30 - Errores comunes, conclusiones y despedida Encontrarás todos los comandos y las notas del episodio en atareao.es, y si quieres participar en la comunidad, tenemos el grupo de Telegram en t.me/atareao_con_linux, además de la red de podcast Sospechosos Habituales en feedpress.me/sospechososhabituales. Un saludo y nos escuchamos el próximo lunes 🐧 Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hay algo que me pasa desde hace años y que seguro que a ti también te suena. Voy tomando notas en Markdown, las organizo por temas y por proyectos, les pongo etiquetas, y en mi cabeza todo tiene sentido. Hasta que un día busco algo con grep y no aparece. No es que la nota no exista, es que mi yo del pasado usó otras palabras y la búsqueda clásica no compara significados, compara letras. Tienes el conocimiento, pero no tienes el mapa. En este episodio te hablo de GraphRAG, esa evolución del RAG que une vectores y grafos de conocimiento para que tus notas dejen de ser ficheros aislados. Primero te cuento por qué la búsqueda literal falla justo cuando tu cerebro digital crece, con esos tres ejemplos de siempre. Buscas particiones y la nota se llama Redimensionar LVM. Buscas monitorización de red y tienes guardadas ntopng e iftop. Buscas alta disponibilidad y aparecen keepalived, Nginx y certificados sin que se vean como un mismo sistema. Después repasamos los tres límites del RAG clásico. El fragmento pierde el contexto, no entiende relaciones y no tiene visión global. Y ahí entran los grafos, con sus nodos, sus aristas y sus pesos, que no escribes a mano, sino que genera el sistema leyendo tus propios .md. Con la idea de fondo bien clara: los vectores te dicen a qué se parece algo, el grafo te dice cómo se conecta. Luego lo ves funcionar de verdad, con un único binario en Rust, SQLite embebido y Ollama para los embeddings y el reconocimiento de entidades. Todo local, sin Python ni contenedores, y lo puedes llevar en un pendrive. Te enseño cómo se crea el grafo, cómo se exploran las estadísticas, la diferencia entre la búsqueda semántica y la literal, cómo se trazan rutas entre dos conceptos que nunca aparecen juntos en una nota, el mapa en la terminal y la integración con Neovim para que te sugiera notas relacionadas mientras escribes. De fondo hay toda una familia de soluciones. Microsoft GraphRAG formalizó la idea con su pipeline de comunidades, LightRAG la hizo más ligera e incremental, y aquí tienes una versión utilitaria, personal y offline que cabe en un único binario. No es un clon de nada, es la misma idea llevada a mi terreno. Un aviso honesto, porque me gusta contar las cosas como son. Sin Ollama no hay magia, la búsqueda vectorial necesita el modelo vivo. Es el precio de tenerlo todo en casa y bajo tu control, que para mí vale la pena. Esto es solo la primera parte de una serie. Hoy entendemos qué es GraphRAG, en el episodio 839 construimos el grafo con tus notas y en el 841 aprendemos a interrogarle. Si llevas tiempo tomando notas y sientes que tu buscador te falla, este episodio es para ti. Capítulos: 0:00 - Introducción: notas, Zettelkasten y el cerebro digital 3:56 - Por qué la búsqueda clásica (grep) falla 7:05 - Qué es GraphRAG: embeddings y vectores 10:45 - Los tres límites del RAG clásico 13:40 - Grafos de conocimiento: nodos, aristas y pesos 17:50 - La herramienta en Rust con Ollama 20:20 - Demo: crear el grafo y explorar estadísticas en SQLite 23:00 - Búsqueda semántica (search) frente a búsqueda literal (FTS) 25:40 - Rutas y relaciones: path y graph 28:10 - El mapa en la terminal (TUI) 29:40 - Conclusiones y cierre Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Si tienes un VPS con los puertos 80 y 443 abiertos, este episodio te interesa. Cada día, bots de todas partes del mundo escanean tu servidor buscando una rendija por la que colarse. La solución no es cerrar las puertas, sino poner un portero que sepa quién entra y quién se queda fuera. Ese portero se llama Shuul, y es el WAF casero del que te hablo en este episodio. Las cifras hablan solas. En las últimas 24 horas, mi VPS recibió 921.000 peticiones. De ellas, bloqueé 650.000. Eso es un 70% de tráfico no deseado. Y no solo hablo de bots escaneando puertos, también de intentos de acceso a rutas de WordPress, phpMyAdmin y vulnerabilidades conocidas. Shuul se encarga de filtrar todo eso antes de que llegue a tus servicios. En el episodio te cuento cómo funciona Shuul por dentro. Tiene dos pipelines independientes. El primero es el WAF, que actúa como forward auth de Traefik: cuando llega una petición, Traefik le pregunta a Shuul si la deja pasar. Aquí se evalúan reglas por IP, país, user-agent, URI y método HTTP, con pesos para decidir si se permite o se deniega. El segundo pipeline es el Jail, un sistema de rate limiting que actúa después de que el backend responde: si alguien acumula demasiados 401, 403 o 404, se le banea la IP con ventanas deslizantes y tiempos de ban que escalan. La arquitectura es ligera. Backend en Rust con Axum, frontend en React con TypeScript y shadcn/ui, y un pequeño plugin en Go que hace de reportero para Traefik. Todo montado en Docker con un binario estático de unos 20 megas. La base de datos es SQLite — no necesitas PostgreSQL para esto. La autenticación del panel la hago con OIDC a través de PocketID, nada de usuario y contraseña tradicionales. También te explico por qué descarté fail2ban. No me gusta porque es un proceso en Python que parsea logs. Shuul obtiene los datos directamente de Traefik, sin escrituras a disco, y trabaja a nivel HTTP, no a nivel de firewall de red. Además puedes crear reglas muy granulares: desde permitir una URL concreta para todo el mundo mientras bloqueas por país en el resto, hasta templates preconfigurados para SQL injection, escáneres de directorios o protección contra vulnerabilidades web. Y todo esto acompañado de un dashboard con gráficos en tiempo real, rankings por países bloqueados y logs en directo. Vamos, que no le falta detalle. Si tienes un servidor en casa o un VPS y estás harto de los bots, este episodio te va a venir como anillo al dedo. Shuul es código abierto, está en GitHub, y lo puedes desplegar en minutos con Docker Compose. Capítulos del episodio: 0:00 - Introducción: Shuul, el guardián de tus datos 2:30 - El problema: bots de Rusia, China y Vietnam escaneando tu VPS 3:50 - Cifras impactantes: 921.000 peticiones, 650.000 bloqueadas en 24h 5:30 - Por qué Traefik no basta y cómo nace Shuul 6:30 - Arquitectura: backend en Rust, frontend en React y un módulo en Go 8:30 - Pipeline WAF: forward auth, geolocalización cacheada y reglas regex 10:40 - Pipeline Jail: Shuul Reporter y bloqueo por intentos fallidos 13:00 - Configuración, variables de entorno e integración con Traefik 16:00 - Reglas, pesos, templates: Allow, Deny, ubicaciones y nodos Tor 18:30 - Dashboard, logs en tiempo real y reflexión final Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Este episodio no va de escribir código. Va de lo que pasa cuando te construyes tu propio asistente con inteligencia artificial, te lo metes en la mochila y te vas de viaje 10 días al sur de Italia. Spoiler: funciona, cuesta menos de 2€ en APIs, y tu pareja no técnica acaba preguntándole a tu bot dónde comer antes que a Google Maps. Te cuento la historia de Minerva, un asistente de viaje que escribí en Rust durante las dos semanas antes de irme a Puglia. La interface es Matrix — le escribes desde el móvil como si fuera un contacto más. Por detrás lleva OpenRouter con DeepSeek V4 Flash, Google Places para buscar restaurantes y monumentos, Brave Search para consultar horarios y precios, y SQLite para guardarlo todo. El binario pesa 12 megas, no necesita Docker, no necesita servidor. Solo un archivo de base de datos que cabe en un pendrive. Te cuento cómo planificó el viaje día a día, cómo nos buscaba sitios para comer (mención especial a la Osteria degli Spiriti en Lecce, el mejor restaurante del viaje), cómo consultábamos el tiempo cada mañana, y cómo cada noche escribía !diario y Minerva me generaba el resumen del día. Al final del viaje tenía los 10 días documentados sin haber abierto una sola pestaña del navegador. Y lo mejor: Ana, mi pareja, que no tiene perfil técnico, pasó de "¿esto qué es?" a "pregúntale a Minerva" en tres días. Ese fue el momento en que supe que no era un juguete. También te cuento lo que falló. Porque falló. Las alucinaciones del modelo (los Sassi de Matera no cuestan 15€ de entrada, son gratis). El tool calling de DeepSeek que a veces escribe XML en vez de invocar la función. La dependencia de internet en carreteras perdidas. El contexto que se satura después de varios días de uso. Y cómo solucioné cada problema — con retries, con resúmenes automáticos, con comandos directos tipo !gasto 45 Cena para cuando el lenguaje natural se vuelve ambiguo. Este episodio es para ti si alguna vez has pensado "me construyo una herramienta yo mismo" pero no te has lanzado. No necesitas un producto perfecto. Necesitas algo que funcione lo suficientemente bien para un caso de uso concreto. Minerva no era perfecta, pero era suficientemente buena. Y suficiente buena es mucho mejor que no existe. Capítulos del episodio: 0:00 - Introducción: vuelta de vacaciones y la idea de Minerva 2:30 - Feedback: el caos de organizar un viaje 5:30 - La pila tecnológica de Minerva 9:00 - Arquitectura: bot de Matrix en Rust 12:30 - Herramientas: Google Places, Brave Search y Wikipedia 16:00 - El prompt y la personalidad del asistente 19:00 - Datos en bruto frente a datos parseados 22:00 - Planificación de viajes con Minerva 25:00 - Minerva en acción: ejemplos reales en Puglia 28:30 - Alucinaciones, errores y lecciones aprendidas 32:00 - Limitaciones de Matrix y el futuro del proyecto 34:30 - Conclusiones: más allá de escribir código Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

WatchTower lleva tiempo sin mantenimiento. Y si tienes 60 stacks de Docker Compose con casi 100 imágenes, actualizarlas una a una es un infierno. Así que me puse manos a la obra y creé Alloy, un dashboard Docker escrito en Rust que me permite tenerlo todo controlado de un vistazo. En este episodio te cuento por qué dejé WatchTower y cómo Alloy resuelve los problemas que WatchTower nunca llegó a cubrir. Porque no solo se trata de actualizar imágenes: también necesitas saber qué ha pasado, cuándo, si ha ido bien, y enterarte si algo falla a las 3 de la mañana. Con Alloy eso cambia por completo. ¿Qué tiene Alloy que WatchTower no tenía? Historial completo de actualizaciones con la imagen anterior y la nueva, duración del proceso y estado final. Notificaciones integradas en Telegram y Matrix para enterarte de todo al instante. Políticas de actualización configurables por contenedor: puedes dejar que unos se actualicen solos, que otros solo descarguen la imagen sin reiniciar, o que ni siquiera se toquen. Logs en tiempo real con buscador integrado. Posibilidad de inspeccionar cada contenedor para ver puertos, volúmenes, redes, variables de entorno y etiquetas de Traefik. Y un dashboard adaptativo que funciona tanto en el ordenador como en el móvil. Y todo con autenticación OIDC a través de PocketID, sin necesidad de PostgreSQL, Redis ni bases de datos externas. Solo un binario con SQLite embebido. Nada de nada. Lo más sencillo posible. El backend está escrito en Rust con Axum y el crate Bollard para conectar con el socket de Docker. El frontend usa React con Mantine UI. Corre en una Raspberry Pi con 2 GB de RAM y consume un 0,5% de CPU y 60 MB de RAM. Vamos, un mecherito. Y lo mejor: soporta tanto Docker como Podman, de ahí el nombre Alloy, por la aleación entre los dos motores de contenedores. Te cuento también cómo gestiona los stacks de Docker Compose, agrupando los contenedores por proyecto. Cómo define políticas distintas para cada contenedor: no hacer nada, solo descargar la imagen, descargar y reiniciar el contenedor, o descargar y reiniciar el stack completo. Cómo hace rollback automático si algo falla, borrando la imagen nueva y restaurando la anterior. Y cómo se integra con Traefik para acceder directamente a cada servicio desde el dashboard con un solo clic. Y sí, lo reconozco: todavía lo estoy probando. Llevo como un mes y medio y algún ajuste fino necesita. De hecho, he encontrado que a veces, al reiniciar un contenedor, no termina de montarse bien con el resto del compose. Pero las ventajas respecto a WatchTower son tantas que ya no concibo volver atrás. Notificaciones, historial, logs, dashboard móvil... es otro nivel. Si estás harto de WatchTower o simplemente quieres tener más control sobre tus contenedores, este episodio te va a interesar. Y si además te mola Rust, pues ya ni te cuento. Capítulos del episodio: 0:00 - Introducción: el problema de mantener 100 imágenes Docker actualizadas 1:30 - ¿Por qué WatchTower ya no es suficiente? 3:30 - Alloy: qué es y por qué está hecho en Rust 5:30 - Arquitectura: Axum, Bollard, SQLite y React 7:30 - Instalación y autenticación con OIDC y PocketID 9:30 - El dashboard: contenedores, stacks y estado de un vistazo 11:30 - Políticas de actualización por contenedor 13:30 - Notificaciones vía Telegram y Matrix 15:00 - Historial de actualizaciones (lo que WatchTower no tenía) 16:30 - Logs en tiempo real e inspección de contenedores 18:00 - Integración con Traefik 19:00 - Interfaz adaptativa para móvil 20:00 - Consumo de recursos: funciona en una Raspberry Pi 23:00 - Conclusiones: ¿merece la pena el cambio? Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hoy en el episodio 833 te traigo algo que llevaba tiempo queriendo hacer: montar workflows de IA que funcionen de verdad en tu Linux, sin depender de servicios externos, sin GPUs, y sobre todo, sin malgastar tokens en tonterías. Hasta ahora hemos hablado de piezas sueltas: Ollama, skills, MCPs, agentes... pero todo eso suelto no te sirve para nada. La gracia está en combinarlo. En este episodio te enseño 4 workflows completos implementados en Rust que he puesto a funcionar en mi propio equipo, y que puedes adaptar al tuyo sin necesidad de ser un experto. La base del sistema es sencilla: Llama 3.2 3B para generación de texto (~2 GB, funciona en CPU), bge-m3 para embeddings multilingües (~1.2 GB), y binarios Rust compilados estáticamente que no necesitan ninguna dependencia del sistema. Con 8 GB de RAM tienes de sobra. Workflow 1 — noticias-bot: un bot que monitoriza feeds RSS, los filtra por palabras clave, los resume con Llama 3.2 local, y los publica automáticamente en Telegram. Funciona como servicio persistente 24/7, no como un script que ejecutas a mano. Cada feed tiene su propio intervalo de actualización y sus propias keywords. Lleva deduplicación con SHA256 y SQLite para no repetir artículos. Workflow 2 — tareas-bot: un gestor de tareas GTD vía Telegram. Le escribes un mensaje al bot, y la IA lo clasifica al instante: decide si es una tarea, le asigna prioridad y categoría, lo guarda en SQLite, y te confirma en el chat. Sin abrir ninguna app de tareas, sin salir de Telegram. Workflow 3 — monitor-bot: un monitor de sistema inteligente con 5 tipos de chequeo: disco, servicios, memoria, logs del sistema y contenedores Docker. Y aquí viene lo interesante: solo usa la IA cuando realmente hace falta, para analizar logs. Los checks normales son deterministas, sin LLM. Así no malgastas recursos ni tokens. Incluye rate limiting y remediación automática. Workflow 4 — investigador RAG: un asistente de investigación con RAG local. Le haces una pregunta, genera consultas de búsqueda, las lanza contra SearXNG, descarga las páginas en paralelo con tokio, las procesa con embeddings de bge-m3, y te da una respuesta con sus fuentes. Todo en un solo binario Rust, sin Python, sin dependencias del sistema. Todo esto desplegado con systemd o Docker, como servicios que arrancan solos y se mantienen funcionando. Y lo mejor: con modelos que caben en cualquier máquina con 8 GB de RAM y sin GPU. Capítulos del episodio: 0:00 — Introducción: del caos de herramientas a los workflows IA 2:30 — ¿Qué es un workflow de IA? Skills, MCPs y prompts combinados 5:00 — Arquitectura: Rust, Ollama y Docker como base del sistema 8:00 — Ejemplo 1: noticias-bot — RSS filtrado a Telegram 11:30 — Demo del noticias-bot: publicación automática de noticias 14:30 — Ejemplo 2: tareas-bot — clasificación GTD vía Telegram 17:30 — Demo del tareas-bot: "hola" vs "comprar ciruelas" 20:00 — Ejemplo 3: monitor-bot — alertas de sistema con IA 22:30 — Ejemplo 4: investigación asistida con RAG local 26:00 — Demo del investigador: consulta sobre Podman 6 29:00 — Ventajas, conclusiones y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

¿Cansado de que tu monitor de uptime consuma más recursos que los propios servicios que monitoriza? Llevaba años usando Uptime Kuma, una herramienta fantástica, potente y muy fácil de configurar. Pero cuando miras el docker stats y ves 150 MB de RAM, 900 MB de disco y un 2% de CPU para monitorizar solo seis páginas, algo no cuadra. Sobre todo cuando lo único que quieres es que te llegue una notificación si algo falla, no tener un mini-Netflix corriendo en tu servidor. Por eso creé Watchbit: un monitor de uptime escrito en Rust con frontend en React, base de datos SQLite embebida y autenticación OIDC con Pocket ID. El resultado: 7 MB de RAM, 20 MB de disco y 0,2% de CPU. Sí, has leído bien. Estamos hablando de reducir el consumo de memoria a una vigésima parte, el de disco a una cuadragésima parte y el de CPU a una décima parte. Y todo esto sin perder funcionalidad: monitores HTTP, TCP, Ping, heartbeats, notificadores vía Telegram, Matrix, NTFY, Gotify, Discord, Email, y páginas de estado públicas. En este episodio te cuento cómo migré de Uptime Kuma a Watchbit, te enseño el dashboard por tarjetas, los heartbeats, los monitores, los notificadores y las 7 razones por las que no pienso volver atrás. También te explico el stack técnico: Rust con Axum y Tokio en el backend, React con TypeScript en el frontend, SQLite como base de datos embebida (adiós a PostgreSQL y MariaDB), y OIDC con Pocket ID para olvidarte de gestionar usuarios y contraseñas. Todo en un solo binario, sin dependencias externas, con una imagen Docker que apenas ocupa 20 MB. Además te muestro cómo configurar los monitores con intervalos personalizados, las plantillas de notificación para eventos de down, up, latencia y expiración de certificados, y el sistema de backup integrado que te permite exportar e importar toda la configuración en un solo clic. También te cuento el proceso de optimización que seguí: inicialmente hacía un bucle que recorría todos los monitores, pero después los separé en tareas independientes con Tokio para maximizar la eficiencia. Si tienes un VPS ajustado, una Raspberry Pi Zero, o simplemente quieres ser racional con los recursos de tu servidor, este episodio te interesa. Porque al final, de esto va el self-hosting: de tener herramientas que hagan su trabajo sin que el servidor se resienta. Como siempre, te dejo el docker-compose, las variables de entorno y las instrucciones en las notas del episodio para que puedas probarlo tú mismo en cinco minutos. Capítulos: 0:00 - Introducción: la necesidad de monitorizar páginas web 1:54 - Uptime Kuma: características y panel de control 4:45 - Ventajas e inconvenientes de Uptime Kuma 5:36 - El problema del consumo: CPU, RAM y disco 7:05 - Watchbit: OIDC, dashboard y diseño por tarjetas 8:43 - Comparativa de consumo: Watchbit vs Uptime Kuma 10:53 - Heartbeats y monitores en Watchbit 12:37 - Configuración de monitores, notificadores y plantillas 14:31 - Ajustes, backup y stack técnico (Rust + React + SQLite) 17:26 - 7 razones para migrar e instalación Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hoy te traigo un episodio que llevaba tiempo queriendo grabar. En el episodio 829 te hablé sobre skills, pero me quedé con la sensación de haberme enrollado sin mostrar nada concreto. Así que le he dado la vuelta a la tortilla y en esta ocasión te traigo siete MCPs que he seleccionado uno a uno para que veas de qué va esto del Model Context Protocol y, sobre todo, para que compruebes cómo transforman lo que puede hacer tu inteligencia artificial. Porque hay que decirlo claro: la IA es tonta. Literalmente. No sabe qué hora es, no sabe leer un archivo, no sabe si tienes issues abiertos en GitHub, no sabe cómo te llamas. Cada vez que empiezas una conversación con cualquier modelo de lenguaje, empiezas de cero. Y aquí es donde entran los MCPs, que no son ni más ni menos que herramientas: manos, ojos y oídos para que la IA pueda hacer cosas útiles de verdad. El Model Context Protocol es un estándar abierto creado por Anthropic que funciona como un *USB-C para la IA*. Un conector universal que permite que cualquier aplicación de IA se conecte con cualquier fuente de datos o herramienta externa. Y lo mejor es que no es propietario, al contrario que los plugins de ChatGPT. Cualquiera puede crear un MCP, y de hecho te cuento cómo hacerlo con Python o Rust. En este episodio repaso siete MCPs que uso en mi día a día. Empiezo por el Filesystem, que permite a la IA leer, escribir, buscar y editar archivos en tu sistema, con control de acceso para que no haga tonterías. Sigo con el SQLite, ideal para consultar bases de datos locales de agenda, finanzas o cualquier aplicación que uses. Después llega el GitHub, el servidor oficial de GitHub escrito en Go, que te permite gestionar issues, pull requests, repositorios y mucho más sin salir del chat. También te hablo del Web Fetch, que permite a la IA leer páginas web y convertirlas a Markdown ahorrando una barbaridad de tokens. Y del Time, que es una tontería pero imprescindible: la IA puede saber la hora en cualquier huso horario del mundo. Luego está el Memory, que construye un grafo de conocimiento persistente para que la IA recuerde quién eres, qué prefieres y qué proyectos tienes entre manos, incluso entre sesiones. Y por último, el Sequential Thinking, una herramienta de razonamiento paso a paso que obliga a la IA a pensar de forma estructurada cuando se enfrenta a problemas complejos. También hablo de cómo configurar estos MCPs en OpenCode, Claude Desktop y VS Code, y cuánto consumen de RAM y tokens. Porque no es lo mismo activar veinte servidores que tener solo los que necesitas. Y para rematar, comparo MCPs con skills: las skills le dicen a la IA cómo comportarse, los MCPs le dan capacidades para actuar. Y si te pica la curiosidad por crear tu propio MCP, también te cuento las diferencias entre usar el SDK de Python (súper rápido de prototipar) y el de Rust (más rendimiento, menos consumo de RAM). Capítulos del episodio: 0:00 - Introducción: la IA necesita herramientas para ser útil 2:30 - ¿Qué es MCP? Arquitectura host-cliente-servidor y JSON RPC 2.0 5:30 - Cinco razones para adoptar MCPs 8:00 - MCP Filesystem: leer, buscar y crear archivos 11:00 - MCP SQLite: consultar bases de datos y el no-determinismo 14:00 - MCP GitHub: issues, pull requests y repositorios 17:00 - MCP Web Fetch: búsquedas en internet con ahorro de tokens 19:30 - MCP Time: la hora en cualquier huso horario 21:30 - MCP Memory: grafo de conocimiento persistente 23:30 - MCP Sequential Thinking: razonamiento paso a paso 25:30 - Configuración en OpenCode, consumo de tokens y RAM 27:30 - Crear tu propio MCP: Python SDK vs Rust 28:30 - Cierre y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Este es el primer episodio de una serie de cuatro que voy a dedicar a herramientas que he implementado y que uso en mi día a día. Las cuatro comparten stack: Rust en el backend y React con TypeScript en el frontend. Y la primera es, sin duda, una de las que más me facilitan la vida: Popuplatrs. ¿Te suena el ritual de publicar un artículo y tener que abrir Telegram, luego Mastodon, luego X, luego LinkedIn, luego Bluesky, y encima personalizar el texto para cada plataforma? Pues eso es exactamente lo que Popuplatrs elimina de tu día a día. Le das uno o varios feeds RSS, Atom o YouTube, y él se encarga de leer las novedades y publicarlas automáticamente en las redes que le configures. Con plantillas personalizables, programación de horarios, reintentos automáticos y un panel web desde el que controlarlo todo. En este episodio te cuento por qué me decidí a crear esta herramienta, qué alternativas existen (Buffer, Hootsuite, IFTTT, Zapier) y por qué ninguna me convencía al ser SaaS o no estar pensadas para funcionar a partir de feeds. También te explico la arquitectura técnica: Rust con Axum, SQLite en modo WAL, autenticación OIDC con Pocket ID, y un sistema de plantillas con MiniJinja que te permite personalizar el mensaje para cada red social. Popuplatrs soporta hasta nueve publicadores diferentes: Telegram, X (Twitter), Mastodon, Bluesky, LinkedIn, Threads, Discord, Matrix y OpenObserve para logging. Cada uno con su propia configuración de autenticación y límites de caracteres. Por ejemplo, en Bluesky publica respetando el límite de 300 caracteres, en X primero lanza el título y luego un reply con el enlace para aprovechar mejor el espacio, y en Discord usa webhooks que se configuran en segundos. El sistema de plantillas es una de las partes que más me gustan. Usa MiniJinja, un motor compatible con Jinja2, y te permite definir plantillas distintas para cada plataforma. Puedes truncar el texto a un número de caracteres, limitar las palabras, eliminar HTML, y combinar el título con la descripción como más te convenga. Todo desde el panel web, sin tocar código. Y por supuesto, te cuento cómo tenerlo corriendo en tu servidor en cinco minutos con Docker. Porque si algo me gusta es que las herramientas sean fáciles de desplegar. Capítulos: 0:00 - Introducción: el problema de publicar en redes sociales 1:45 - Alternativas existentes y sus limitaciones 3:00 - Qué es Popuplatrs: origen, nombre y características principales 4:15 - Arquitectura técnica: Rust, Axum, SQLite y Pocket ID 5:45 - Fuentes soportadas: RSS, Atom y YouTube 7:00 - Publicadores: hasta nueve plataformas sociales 8:30 - Panel web: dashboard, logs y republicación de errores 10:30 - Programación, reintentos y control anti-spam 12:00 - Motor de plantillas y personalización por plataforma 13:30 - Despliegue con Docker Compose, Pocket ID y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hoy te traigo un episodio que llevaba tiempo queriendo grabar. Y es que muchos estáis usando agentes de IA, pero los tenéis desnudos. Sin skills. Y un agente sin skills es como un Linux sin comandos: técnicamente funciona, tienes el kernel, tienes la shell, pero sin ls, sin grep, sin systemctl, no puedes hacer nada útil. El mejor modelo del mundo sin herramientas solamente es texto bonito. En este episodio te cuento qué son exactamente las skills, por qué transforman un modelo de lenguaje en un asistente que hace cosas, y cuáles son las tres skills imprescindibles que todo agente debería tener. Una skill no es ni más ni menos que un prompt. Un conjunto de instrucciones que le dice a tu agente cómo tiene que hacer algo. No es un programa ni un script, es una receta de comportamiento. Y no necesitas ser programador para crearlas. Te hablo de skills del sistema: leer archivos, ejecutar comandos, navegar por tu equipo. Skills de búsqueda: búsqueda web con SearXNG (que tengo montado en un Slimbook One y devuelve resultados en JSON que es una maravilla), búsqueda local con RipGrep que es increíblemente rápida, y búsqueda semántica con SQLite. Y skills de automatización: tareas programadas, webhooks que responden a eventos como un git push, o scripts orquestados que pueden hacer casi cualquier cosa. Pero no me quedo ahí. Te doy las tres reglas de oro para crear tus propias skills. Porque los mejores skills son los que escribes para ti mismo. Primera regla: no digas "revisa el sistema", sino "ejecuta systemctl status --failed". Cuanto más específico, mejor. Segunda: define los límites. Qué puede hacer y qué no. Lo que no puede hacer es casi tan importante como lo que puede hacer. Tercera: ponle ejemplos. Cómo tiene que quedar el resultado, qué formato tiene que usar. Con estas tres cosas todo rueda mucho mejor. También te cuento cómo organizar tus skills. Cada agente guarda los skills donde le da la gana: OpenCode en .config/opencode/skills, Hermes en .hermes/skills. Yo cada vez los guardo más en .agents/skills porque la mayoría de los agentes ya saben encontrarlos ahí. Y te hablo de los hubs de skills, donde puedes instalar skills creados por la comunidad con un solo comando. Si usas OpenCode, Hermes Agent u Open Web y sientes que tu agente responde preguntas pero no hace cosas, este episodio te va a cambiar el día a día. Vamos directos al turrón. Capítulos del episodio: 0:00 - Introducción: tu agente está desnudo 1:45 - ¿Qué es una skill? De un prompt a un asistente que hace cosas 4:15 - Skills del sistema: leer archivos, ejecutar comandos, navegar 7:30 - Skills de búsqueda: web con SearXNG, local con RipGrep, semántica con SQLite 11:00 - Skills de automatización: tareas programadas, webhooks, scripts orquestados 13:45 - Las 3 reglas de oro para crear tus propias skills 18:30 - El ecosistema de skills: dónde guardarlas y cómo organizarlas 21:00 - Ejemplo práctico: la skill del tiempo meteorológico 23:15 - Conclusión: un agente sin skills es Linux sin comandos Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Este episodio 828 es la carta de presentación de la Temporada 9 de atareao con Linux. Treinta y cuatro episodios ya guionizados, siete etapas, y un objetivo claro: construir tu cerebro digital sobre Linux con herramientas locales, sin depender de nubes ni suscripciones. Pero antes de mirar adelante, toca hacer balance. La T08 empezó prometiendo Docker, selfhosting y Android, y sí, hablé de todo eso. Pero en abril de 2025 la IA local irrumpió con fuerza y la temporada viró hacia Ollama, modelos locales, RAG, MCP. Fue un giro desordenado, lo reconozco. Pero también fue el germen de todo lo que viene ahora. De eso va esta T09: de poner orden al caos. Siete etapas, de menos a más, para que sigas el hilo hagas el nivel que hagas. Etapa 1 — Recursos básicos: los cimientos de tu laboratorio de IA. Skills para tu agente, herramientas de publicación, el botiquín del explorador. Etapa 2 — Skills y MCPs: el pegamento. El Model Context Protocol ha madurado hasta ser un estándar abierto — lo soportan Claude, ChatGPT, VS Code, Cursor. Ya no es un experimento, es el USB-C de la IA. Y de paso, herramientas del ecosistema atareao como watchbeat (monitor de uptime en Rust) y alloy (dashboard Docker con OIDC). Etapa 3 — GraphRAG, el gran hito: de RAG vectorial a grafos de conocimiento. Mientras el RAG clásico devuelve fragmentos sueltos y tú unes los puntos, GraphRAG construye un grafo con entidades y relaciones. Preguntas como "qué contenedores están detrás de Traefik" pasan a ser una consulta directa a tu mapa de conocimiento. Usaremos LightRAG, que con 39.000 estrellas ya superó al Microsoft GraphRAG original. Esto ocupa tres episodios. Etapa 4 — Multimedia: Whisper para speech-to-text, TTS local, ffmpeg, visión artificial, y el pipeline de YouTube a conocimiento con yt-dlp. Rematamos con RAG multimodal. Etapa 5 — Orquestación: systemd timers, asyncio, just, y CrewAI para montar equipos de agentes. Etapa 6 — Proyecto final: dos episodios para construir El Asistente que te Conoce y ponerlo en producción con Quadlets. Etapa 7 — El futuro: mantenimiento de tu cerebro digital y hacia dónde va todo esto. Entre medias, herramientas Linux: shuul, sqlite-utils, yq + jq, Rust en el kernel, Wayland vs X11, la guerra de los filesystems. No necesitas una GPU de 3000 euros ni un doctorado. Con 16 GB de RAM y un CPU decente ejecutas modelos de 7B a 14B. Esto es IA local, en tu máquina, con tus datos. Capítulos del episodio: 00:00 — Introducción y bienvenida a la Temporada 9 01:47 — Balance T08: de Docker y Selfhosting al boom de la IA 04:37 — El momento adecuado para cada tecnología 06:46 — El gran objetivo: tu cerebro digital 08:44 — Roadmap T09: 30 episodios ya guionizados 11:28 — Skills y MCPs imprescindibles 12:43 — GraphRAG: de RAG a grafos de conocimiento 14:01 — RAG vs GraphRAG: el mapa de tu conocimiento 17:28 — Herramientas del ecosistema: alloy, populater, watchbeat 20:08 — ¿Para quién es esto? De veteranos a escépticos 22:08 — No es hype: es un cambio de paradigma 24:30 — El momento perfecto para el linuxero Toda la info y el roadmap completo en atareao.es/828. Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Cerramos la octava temporada con un episodio que me apetecía grabar desde hace meses. Igual te ha pasado como a mí: empecé hablando de un laboratorio de IA para cualquiera, y terminé recomendando GPUs de 3000 euros. Me fui creciendo, pero no hace falta. Te cuento cómo montar un laboratorio de IA local con el equipo que ya tienes. Da igual si tienes 8 GB de RAM o 16, CPU modesta o sin GPU. La clave está en elegir los modelos adecuados. Muchas veces nos perdemos buscando el modelo más grande, cuando con uno pequeño y bien cuantizado tenemos de sobra para el 80% de las tareas. Te hablo de Ollama, el gestor de modelos estándar para ejecutar modelos locales. Más de 180.000 estrellas en GitHub, API compatible con OpenAI, modelos para todos los presupuestos: desde Phi 3.5 con 3.8B parámetros hasta Qwen 1.5B que ocupa 1 GB. También la cuantización: reduces la precisión numérica de los pesos para que ocupen menos y vayan más rápido. El punto dulce es Q4_K_M, que reduce el tamaño a menos de un tercio. Para 8 GB de RAM, Q3_K_S puede ser tu salvación. También te hablo de Open WebUI, la interfaz que le da mil vueltas a ChatGPT. No solo chateas: tiene RAG local, Whisper integrado para transcribir voz (75 MB en CPU), TTS con Kokoro-82M para que el modelo te hable en tiempo real, búsqueda web, plugins y memoria persistente. Todo en un contenedor Docker que levantas con un solo comando. Y de SQLite Vec, extensión de SQLite sponsorizada por Mozilla para búsqueda semántica sin servidores vectoriales. Ni ChromaDB, ni Qdrant, ni Milvus. C puro que funciona hasta en Raspberry Pi. Creas tablas virtuales para vectores de 768 dimensiones, generas embeddings con nomic-embed-text, y buscas por similitud coseno en milisegundos. RAG local sin complicaciones. Y te explico cómo organizarlo todo con Docker o Podman. Un docker-compose.yml que levanta Ollama y Open WebUI en segundos, con healthchecks, redes separadas y volúmenes persistentes. También a limitar recursos con --memory y --cpus. He preparado scripts: inicialización que comprueba requisitos, crea directorios y descarga modelos; otro para descargar por niveles según tu hardware (nivel 1 para 8 GB, nivel 2 para 16 GB, nivel 3 para 32 GB); y uno de respaldo. Y la estrategia híbrida local + nube, que es lo que realmente tiene sentido. El enfoque Minions del Stanford Hazy Research Lab: el modelo local hace el trabajo pesado, y solo consulta al grande en la nube para tareas complejas. El 90% de las consultas se resuelven localmente. Ahorras dinero, mantienes privacidad de tus datos, y cuando necesitas potencia, la tienes. Con 16 GB de RAM y un SSD te sobra para el 80% de las tareas: traducciones, resúmenes, código, asistentes, RAG, transcripción de audio, texto a voz... Todo en tu máquina, sin enviar datos a servidores, sin suscripciones, sin depender de internet. Con 8 GB también puedes, con modelos más pequeños. Cerramos temporada, la novena arranca en el episodio 828. Capítulos del episodio: 0:00 - Introducción — cierre de temporada 8 y replanteamiento 2:30 - Hardware mínimo: 8-16 GB RAM + SSD obligatorio 5:00 - Software base: instalar Ollama en tu distribución 7:30 - Contenedores: Docker vs Podman para el laboratorio 10:00 - Modelos pequeños: Phi 3.5, Qwen 1.5B y cuantización 13:00 - Herramientas complementarias: SQLite Vec, Whisper, TTS 16:00 - Organización del laboratorio: script y estructura de directorios 19:00 - Demo: probando Ollama en local con modelos ligeros 22:00 - Combinación local + nube: lo mejor de ambos mundos 24:30 - Cierre, avance temporada 9 y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Si llevas años usando Bash, Zsh o Fish y piensas que los pipes de Unix son lo más parecido a la perfección, este episodio te va a hacer tambalear los cimientos. Porque existe un shell que no pasa texto entre comandos: pasa estructuras de datos. Tablas, listas, registros, fechas, tamaños de archivo con tipo real. Y encima habla con Ollama sin que tengas que escribir ni una línea de Python. Ese shell es Nushell. Está escrito en Rust, tiene más de 40.000 estrellas en GitHub, y su filosofía es sencilla: los pipes deberían transportar datos con tipo, no texto que luego parseas con awk, sed o jq. En este episodio te cuento mi experiencia pasando de Fish a Nushell con ejemplos reales. Cuando escribes ls no obtienes texto: obtienes una tabla con columnas tipadas. Puedes hacer ls | where size > 1mb | sort-by size sin recurrir a awk ni números mágicos. El shell entiende qué es un filesize, qué es una fecha, qué es un número. Y luego está open, que entiende el formato por la extensión: JSON, YAML, TOML, CSV, SQLite... todo se convierte en datos estructurados. Abres un SQLite y ejecutas consultas con query db. Y todo combinable: http get a una API, filtrar con where y guardar con save — en un solo pipeline, sin archivos temporales. La guinda es la integración con IA. Como Nushell entiende JSON y Ollama habla JSON, se entienden a la perfección. Te enseño un pipeline que lista procesos, filtra los que consumen más de 100MB de RAM, se los manda a un modelo local, y mata el que más memoria usa. Todo en una línea. También te hablo de ai.nu, un módulo que envuelve Ollama, OpenAI y DeepSeek, con function calling desde el shell. También hago una comparativa: Bash, Zsh, Fish y Nushell cara a cara. Bash funciona en cualquier sitio pero el manejo de datos es arcaico. Zsh es Bash con esteroides pero los pipes siguen siendo texto. Fish es moderno pero no entiende de tipos. Nu es el único con estructuras de datos de verdad. PowerShell fue el primero en pasar objetos, pero Nu es lo que PowerShell debería haber sido. Capítulos del episodio: 0:00 — Introducción: de Bash a Fish, la evolución de las shells 2:30 — El problema del texto plano: por qué Nushell es diferente 5:00 — La trifecta: ls, where y select, SQL en tu terminal 7:30 — Tipos reales: la shell entiende fechas, tamaños y números 10:00 — Open: abrir JSON, CSV, YAML y SQLite sin herramientas externas 13:00 — Procesamiento avanzado: $in, save, append y par-each 15:30 — HTTP GET: APIs de GitHub y meteorología desde la shell 18:00 — Comparativa de shells: Bash vs ZSH vs Fish vs Nushell 21:00 — Nushell e IA: integración nativa con Ollama sin Python 24:00 — Instalación, casos de uso y conclusiones finales Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hoy te voy a contar una historia que empieza con una idea brillante y termina con una buena dosis de frustración. Resulta que se me ocurrió construir mi propio agente de inteligencia artificial. Lo llamé Anacleto, está escrito en Rust, y la idea era tener un coordinador de agentes que delegara tareas según lo que le pidieras. El tiempo, el tiempo, y un puñado de bugs después, me he encontrado con que estoy aprendiendo mucho más de lo que pasa entre bambalinas que de lo que el agente realmente llega a hacer. Y es que cuando le das una instrucción a un agente de IA —ya sea OpenCode, Claude, Hermes o el que tú quieras— no hay magia. Lo que hay es una coreografía compleja de mensajes que van y vienen, eventos que se disparan, herramientas que se invocan y un modelo de lenguaje que procesa todo después de que el agente lo haya pretratado. En este episodio abro la caja negra y te cuento exactamente qué hay dentro. Te explico el viaje completo de un mensaje: desde que escribes el prompt hasta que obtienes la respuesta. Cómo funciona el streaming, cómo el modelo "piensa en voz alta" con los reasoning events, cómo decide qué herramientas usar con las tool calls, y cómo todo se monta en una batidora que reconstruye la información antes de enviarla al modelo. Y sí, el modelo no razona, simplemente predice. Pero la gracia está en que ahora no solo habla, también actúa. El modelo recibe una lista de herramientas disponibles y decide por sí mismo cuál usar según el contexto. No es programación tradicional de "si pasa A, usa la herramienta A". Es el modelo el que, basándose en su entrenamiento, predice qué herramienta le dará la mejor respuesta. Y luego está el problema. El bucle. El modelo devuelve tool calls, el agente ejecuta las herramientas, vuelve a llamar al modelo, y así una y otra vez hasta que se alcanza el máximo de pasos y todo se para. No sé si es un problema de cómo he definido las llamadas, del motor o de las skills. Llevo días toqueteando, probando, cambiando cosas, y todavía no tengo claro dónde está el fallo. Lo que sí tengo claro es que unas skills bien preparadas dan mejores resultados que un modelo más potente. Y esa lección, por sí sola, ya ha valido la pena. Porque al final, la calidad de las instrucciones que le das al agente importa más que el modelo que uses por debajo. Te cuento también por qué elegí Rust y Ratatui para la interfaz, en lugar de lo típico en Python o TypeScript. Spoiler: me lié más con el lenguaje que con el objetivo final, como suele pasar. Y te presento a los subagentes de Anacleto: uno para el tiempo, otro para noticias, otro para chistes, otro para investigar... cada uno con su propia personalidad y herramientas. Capítulos del episodio: Capítulos del episodio: 0:00 - Introducción: abriendo la caja negra de los agentes de IA 2:19 - El viaje de un mensaje: del prompt al modelo de lenguaje 3:49 - Arquitectura de agentes: coordinador, subagentes y la TUI en Rust 6:11 - El motor como director de orquesta: roles system, user, assistant y tool 8:27 - System prompt y optimización: delegación en subagentes especializados 11:13 - Streaming y server-sent events: cómo se construye la respuesta token a token 14:20 - Razonamiento y tool calls: el modelo predice, no piensa, pero actúa 17:59 - El bucle de herramientas: el problema de la delegación infinita en Anacleto 20:56 - Skills, subagentes desechables y sistema de permisos 25:16 - Demostración práctica de Anacleto: tiempo, chistes y noticias 29:22 - Conclusiones, redes y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

¿Sigues usando find y grep como en los 90? Hace unas semanas me puse a buscar un archivo en un repositorio con git, lancé el find de toda la vida, y cuando volví de tomarme un café —literalmente— todavía seguía buscando. El problema es que find se mete en el .git, en los binarios, en sitios donde no debería. Y grep, pues lo mismo, sobre todo si trabajas con Unicode o con repositorios grandes. Así que llevo un tiempo usando fd y ripgrep, dos herramientas escritas en Rust que son órdenes de magnitud más rápidas. Pero lo mejor no es solo la velocidad: es que puedes combinarlas para crear pipelines que alimenten directamente a tu IA local. fd (44.1k estrellas en GitHub) es un reemplazo directo de find. En los benchmarks oficiales, buscar archivos con fd -u tarda 0.8 segundos donde find necesita 11 segundos con -iname y casi 20 segundos con -iregex. 23 veces más rápido. Y no solo es velocidad: fd respeta .gitignore por defecto, soporta expresiones regulares directamente, y tiene placeholders como {}, {.}, {/} y {//} que te permiten ejecutar comandos sobre cada resultado con -x o pasarlos en lote con -X. ripgrep (67.4k estrellas) es lo mismo pero para buscar texto. En el kernel de Linux, rg tarda 0.08 segundos donde grep tarda 2.67 segundos. 32 veces más rápido. Y tiene superpoderes que grep ni sueña: salida en JSON con --json, búsqueda en archivos comprimidos con -z, soporte PCRE2 con -P para lookaheads, y un flag --passthru que te muestra también las líneas que no coinciden. Desde la versión 15 también soporta hyperlinks OSC 8 y respeta repositorios de Jujutsu. Pero lo que realmente me tiene enganchado es combinarlos. El patrón es sencillo: fd encuentra los archivos que te interesan, ripgrep extrae el contexto relevante, y todo eso se lo pasas a Ollama para que lo procese. Te enseño la función aresumen que me he montado en Bash, y su equivalente en Fish, para preguntarle a mi documentación local sin salir de la terminal. Cosas como "resume todo lo que he escrito sobre Ollama en el último mes" se resuelven con un pipeline de tres comandos. Sin RAG, sin bases de datos vectoriales, sin complicaciones. Solo con un pipe bien puesto y el modelo adecuado. También te cuento cómo usar jq para procesar la salida JSON de ripgrep, cómo montar un buscador interactivo con fzf y bat, y los errores más comunes al construir estos pipelines. Si alguna vez has pensado "ojalá pudiera preguntarle a mis propias notas desde la terminal", este episodio te va a gustar. Y si todavía usas find y grep, te aseguro que después de oír los benchmarks no vuelves atrás. Capítulos del episodio: 0:00 — Introducción: fd y ripgrep para alimentar a tu IA 2:30 — El problema con find y grep tradicionales 5:00 — fd: el find que siempre quisiste tener 8:00 — Placeholders y expresiones regulares en fd 11:00 — ripgrep: el grep con superpoderes 14:00 — Salidas estructuradas con JSON y jq 16:30 — La combinación estrella: fd + ripgrep con -x 19:00 — Pipelines avanzados para filtrar archivos 21:30 — Integración con IA local: fd + rg + Ollama 24:30 — Alias, funciones y trucos del día a día 27:00 — Despedida y conclusiones Recursos mencionados: - fd (sharkdp/fd): https://github.com/sharkdp/fd - ripgrep (BurntSushi/ripgrep): https://github.com/BurntSushi/ripgrep - Ollama: https://ollama.com - jq: https://jqlang.github.io/jq/ - fzf: https://github.com/junegunn/fzf - bat: https://github.com/sharkdp/bat Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hoy toca dar un paso más. Hasta ahora usabas OpenCode como un asistente personal, le pedías algo y lo hacía. Pero, ¿y si necesitas algo más potente? ¿Alguien que investigue, alguien que escriba, alguien que lo optimice para SEO y alguien que lo revise todo? La respuesta no es un agente, es un equipo de agentes. En este episodio te cuento cómo he montado un sistema multi agente con OpenCode usando el patrón supervisor, y cómo coordino cinco agentes especializados sin que se pisen. Te explico el pipeline completo de cinco fases. Primero la planificación, donde el coordinador define la estructura y los pasos a seguir. Luego la investigación, que corre a cargo del bibliotecario, un agente que solo busca información, no escribe, no opina, solo trae datos con sus fuentes. Después viene el redactor, que coge esos datos y escribe el artículo en Markdown con el tono de la casa. La cuarta fase es el SEO, donde un agente especializado pone el título, la meta descripción y las etiquetas sin tocar el fondo del artículo. Y por último la revisión, donde el editor verifica que todo está correcto y, si algo falla, lo devuelve al coordinador para que repita la fase que haya fallado. Todo esto forma un bucle de retroalimentación que diferencia un sistema multi agente bien hecho de cualquier otro. Cada agente tiene su propio modelo, su propia temperatura y sus propios permisos. El investigador usa un modelo pequeño y barato porque solo necesita buscar. El redactor necesita un modelo más grande porque tiene que escribir con calidad. El revisor usa temperatura muy baja para ser lo más objetivo posible. También te cuento los errores que me he encontrado. El más común es que el coordinador no delega. Le pides algo y en lugar de llamar al investigador, investiga él. En lugar de llamar al redactor, escribe él. Y el resultado es lo peor, porque el coordinador no es especialista en nada. La solución pasa por describirlo muy claro, con exclusiones en mayúscula: NO PUEDES HACER NADA, SOLO PUEDES DELEGAR. Otro error es dar permisos de más. Si todos pueden invocar Task, el investigador llama al revisor, este al SEO y se monta un follón. Además hago una demo en vivo creando un artículo sobre FD, una herramienta en Rust que sustituye a find. Ves cómo el coordinador recibe la petición, planifica, lanza al investigador, luego al redactor, luego al SEO, luego al revisor, y en una sola iteración el artículo está aprobado. Con su título SEO, su meta descripción, sus etiquetas y su estructura en Markdown. Y todo esto no es programación. Es escribir artículos, preparar presentaciones o lo que se te ocurra. OpenCode no es solo un asistente para programar, es mucho más que eso. Y al final te cuento cuándo merece la pena usar multi agente y cuándo no. Porque para cambiar una bombilla no necesitas un equipo de cinco personas, necesitas un electricista. Capítulos del episodio: 0:00 - Introducción: de ChatGPT a los agentes multi-propósito 2:28 - De asistente personal a equipo de agentes especializados 3:52 - Patrón supervisor: el jefe de obra que coordina sin ejecutar 4:50 - Pipeline de 5 fases: planificación, investigación, redacción, SEO y revisión 6:37 - La herramienta Task: delegación, contexto aislado y ventajas9:17 - Demo en vivo: creando un artículo sobre FD con subagentes 13:07 - Agentes especializados: investigador, redactor y SEO 18:56 - Control de calidad: el revisor y el bucle de retroalimentación 23:22 - El coordinador: la no ejecución como clave del éxito 24:58 - Errores comunes, cuándo usar multi-agente y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hace unos meses empecé a usar presentaciones para grabar el podcast, y enseguida me di cuenta de que el verdadero problema no es pensar el contenido, sino maquetarlo. Pasaba más tiempo ajustando fuentes, colores y transiciones que preparando lo que realmente quería contar. Así que me puse a buscar una solución, y lo que encontré me ha cambiado el flujo de trabajo por completo. En este episodio te cuento cómo he montado typst-ia, un script en Python que genera presentaciones completas en segundos. Le dices un tema, la inteligencia artificial se encarga del contenido, y Typst lo convierte en un PDF impecable. Todo desde la terminal, sin abrir PowerPoint ni Google Slides, sin suscripciones mensuales, y con un control total sobre el resultado. Typst es un sistema de composición moderno escrito en Rust que compila en milisegundos. Sí, has leído bien, milisegundos. Comparado con LaTeX Beamer, que tarda 5 o 10 segundos en compilar, Typst es un antes y un después. Además, su sintaxis es mucho más limpia y fácil de aprender. En el episodio lo comparo con LaTeX y con Markdown, y te cuento por qué creo que Typst se está convirtiendo en el estándar para presentaciones técnicas. La clave del proceso está en el system prompt. Incrusto el template real de la presentación dentro del prompt que le envío a OpenRouter, y la IA genera código Typst válido sin necesidad de retoques. Uso DeepSeek Chat por defecto —cuesta unos 14 céntimos por millón de tokens de entrada, que vienen a ser cientos de presentaciones por menos de un euro—, pero también puedes usar Claude Sonnet, Gemini Flash o Llama 3.3 si necesitas más calidad o prefieres un modelo concreto. El script completo son unas 200 líneas de Python sin frameworks, solo con la librería requests. Te explico paso a paso cómo funciona el pipeline: lee el template, construye el prompt, llama a OpenRouter, limpia la respuesta, escribe el archivo .typ, lo compila a PDF y lo abre en el visor. Y todo con flags para personalizar el número de diapositivas, el modelo, el nombre del archivo y hasta los reintentos si la compilación falla. Para rematar, hago una demo en vivo generando una presentación desde cero. Ves cómo en cuestión de segundos pasamos de una idea a un PDF listo para proyectar. Y lo mejor es que el resultado es texto plano, versionable con Git, editable con cualquier editor, y sin ningún tipo de lock-in. Si mañana quieres cambiar algo, abres el .typ y lo tocas. Si eres de los que hacen presentaciones técnicas, charlas, workshops, o simplemente quieres automatizar una tarea tediosa, este episodio te va a gustar. Y si nunca has oído hablar de Typst, te vas a llevar una sorpresa. Capítulos del episodio: 0:00 - Introducción: presentaciones con Typst e IA 2:52 - El problema de las presentaciones tradicionales 5:20 - Typst: el sistema de composición moderno 7:34 - Typst vs LaTeX vs Markdown 8:31 - Instalación de Typst 9:28 - Plantillas para presentaciones con Typst 12:52 - OpenRouter y el prompt para la IA 15:28 - El script Python: el pipeline completo 17:41 - Demo en vivo: generando una presentación 24:17 - Conclusiones y despedida

¿Alguna vez te has dado cuenta de que la búsqueda exacta se queda corta cuando tu base de conocimiento crece? Buscar por palabras exactas con grep o FTS5 es rápido y preciso, pero es literal y no entiende contexto ni sinónimos. Por otro lado, la búsqueda semántica pura con embeddings a veces falla con términos muy específicos como rutas de archivos o comandos exactos. En este episodio te muestro cómo solucionar este problema combinando lo mejor de ambos mundos mediante tres técnicas avanzadas de RAG: Búsqueda Híbrida (Hybrid Search): Cómo combinar FTS5 y embeddings semánticos utilizando un equilibrio ponderado (parámetro alpha). Re-ranking con Cross-Encoder: Refinamiento de resultados pasando de un bi-encoder rápido a un cross-encoder preciso para priorizar la máxima relevancia. HyDE (Hypothetical Document Embeddings): La técnica de generar un documento hipotético con un LLM local (Ollama) para encontrar notas mediante conceptos abstractos. Además, repasamos cómo integrar todo esto en tu flujo de trabajo diario mediante herramientas CLI creadas en Python y Rust, así como la integración en Neovim con sqlite.lua. Enlaces y recursos del episodio: Gist con los scripts en Python (Hybrid Search, Reranker y HyDE) Gist con la implementación del CLI en Rust (cerebro-cli) Notas completas del episodio en: atareao.es

Este episodio va de ser vago. Pero vago en el buen sentido, eh. De esos que prefieren que una herramienta haga el trabajo pesado mientras tú te quedas con lo divertido. Resulta que hay todo un ecosistema de herramientas TUI con el prefijo "lazy" que te evitan tener que memorizar cientos de flags y opciones de comandos como git, docker, rsync o SQL. Y no, no es cutrez: son interfaces de terminal que funcionan a golpe de tecla, sin ratón, sin salir de la terminal, y encima molan. Te cuento cómo nació todo esto, quién es Jesse Duffield (el creador de lazygit y lazydocker, con más de 80K y 52K estrellas en GitHub respectivamente) y por qué esta filosofía de "una tecla, una acción" ha enganchado a tanto linuxero. Y lo mejor: te hago demo de las cuatro herramientas principales para que veas cómo funcionan en vivo y en directo, con sus paneles, sus atajos y sus trucos. Empezamos con lazygit, el rey indiscutible del ecosistema. 80.900 estrellas en GitHub, escrito en Go, y con una comunidad que no para de crecer. Desde stage línea a línea hasta rebase interactivo, pasando por undo/redo vía reflog. Te enseño cómo hacer commits, gestionar ramas, stash y hasta cherry-pick sin tener que acordarte de los flags raros de git. Seguimos con lazysql, el gestor de bases de datos en terminal de Jorge Rojas. Soporta MySQL, PostgreSQL, SQLite, MongoDB, MSSQL y Oracle. Navegación por teclado, autocompletado de queries, exportación a CSV y configuración por proyecto. Ideal para cuando no te apetece abrir DataGrip o DBeaver solo para hacer una consulta rápida. Luego viene lazyrsync, escrito en Rust con ratatui, y con una filosofía muy clara: que no se te olvide el flag ese que evita que borres todo. Perfiles reutilizables, dry-run con previsualización, protección contra --delete accidentales y paths dinámicos con variables. Perfecto para backups sin sustos. Y cerramos con lazydocker, también de Jesse Duffield. Cuatro paneles: contenedores, métricas, imágenes y logs en vivo. Con un vistazo ves qué contenedor consume más CPU, entras en el terminal de uno con una tecla, o ejecutas docker-compose sin acordarte del comando. Y sí, también funciona con Podman. Además te menciono otras herramientas del ecosistema: lazyssh, lazyjj para Jujutsu, lazykube, lazyprune para limpiar node_modules olvidados... Vamos, que hay lazy para todo. Capítulos del episodio: 0:00 — Introducción: el problema de memorizar comandos 2:05 — La filosofía lazy: scripts, TUIs y el ecosistema lazy 4:30 — LazyGit: historia, filosofía "una tecla una acción" y +80K estrellas 6:45 — LazyGit: demo de paneles, stage, commits, ramas y stash 9:10 — LazySQL: Jorge Rojas, 4K estrellas y soporte multi-base de datos11:30 — LazySQL: demo con autocompletado, consultas y exportación CSV 14:00 — LazyRsync: dry-run, perfiles y protección contra errores 16:30 — LazyRsync: demo con columnas de estado y confirmación de borrado 19:10 — LazyDocker: Jesse Duffield, 52K estrellas y soporte para Podman 21:45 — Otras herramientas lazy: lazy-ssh, lazy-jj, lazy-kube, lazy-npm 23:15 — Cierre: sé un vago inteligente, valoración y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Llevo 15 años escribiendo notas, artículos y tutoriales. El resultado: unos 5000 archivos markdown repartidos por mi disco duro. Y, como te puedes imaginar, encontrar algo ahí dentro es como buscar una aguja en un pajar. Por eso en este episodio me he puesto manos a la obra para montar un sistema RAG (Retrieval-Augmented Generation) 100% local, sin depender de APIs externas, sin enviar tus datos a la nube, y con herramientas que ya conoces: SQLite, Ollama y Python. Este es el primero de dos episodios sobre RAG. Aquí nos centramos en construir la base de conocimiento: un pipeline que escanea tus documentos, los trocea en fragmentos manejables, extrae los metadatos del frontmatter YAML, genera embeddings con el modelo bge-m3 de Ollama, y lo guarda todo en una base de datos SQLite con búsqueda FTS5. Todo esto, además, con detección incremental de cambios: la primera ejecución tarda lo que tenga que tardar, pero las siguientes son cuestión de segundos porque solo reprocesa lo que ha cambiado. El stack es sencillo pero potente. SQLite con FTS5 para búsqueda textual, Ollama con bge-m3 para los embeddings, y seis scripts Python que suman unas 1300 líneas. Nada de LangChain, nada de frameworks pesados. Código limpio, comentado y que entiendes de un vistazo. El chunking respeta las cabeceras markdown, usa tiktoken para contar tokens con precisión, y los embeddings se almacenan como BLOBs en la propia SQLite. En el próximo episodio (el 821) usaremos esta base de conocimiento para hacer búsqueda semántica con similitud de coseno, búsqueda híbrida combinando FTS5 con embeddings, y hasta un plugin para Neovim. Puntos clave del episodio: - El problema: 15 años de notas, 5000 archivos, cero capacidad de búsqueda - La solución: RAG local con SQLite + FTS5 + Ollama, todo en tu máquina - Chunking híbrido que respeta cabeceras markdown y usa tiktoken - Pipeline incremental con detección de cambios mediante MD5 - Embeddings con bge-m3 (568M parámetros, 1024 dimensiones) - Búsqueda FTS5 con snippet(), colores ANSI y sintaxis avanzada - Errores comunes y cómo solucionarlos Si te gusta el contenido, ya sabes: dale a seguir, compártelo con quien creas que le puede interesar, y déjame un comentario si tienes dudas o sugerencias. La semana que viene, en el episodio 821, montamos la búsqueda semántica y el plugin para Neovim. No te lo pierdas. Capítulos del episodio: 0:00 - Introducción: RAG y base de conocimiento local 2:12 - El problema: 15 años de notas sin buscar 4:58 - La solución: SQLite + FTS5 + Ollama, 100% local 7:00 - Escaneo de archivos y extracción de front matter 10:20 - Preparación del entorno: Ollama, uv y dependencias 12:00 - Chunking: cómo trocear los documentos 15:45 - Estructura de la base de datos SQLite 17:46 - Pipeline incremental con detección de cambios 19:22 - Demo en vivo: consultas y resultados 22:44 - Errores comunes y cómo solucionarlos 24:10 - Resumen y adelanto del episodio 821 25:15 - Despedida y cierre Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

¿Tienes 5, 10 o 20 servidores SSH y no sabes cómo gestionarlos sin tener mil terminales abiertas? En este episodio te hablo de SSHub, una TUI open source escrita en Rust que unifica hosts, sesiones, túneles, SFTP y auditoría en una sola interfaz. Todo desde la terminal, sin salir de ella y sin necesidad de instalar nada más que un único binario compilado con cargo install de Rust. Te cuento cómo pasé de un script en Bash que usaba desde 2019 para conectarme a mis servidores, a esta herramienta moderna que lee tu ~/.ssh/config y lo combina con una base de datos SQLite propia. Sin migraciones, sin complicaciones, sin tener que cambiar nada de lo que ya tienes configurado. Además la comparo con Termius y MobaXterm, que son de pago y cerradas, frente a SSHub que es gratis, multiplataforma y con licencia AGPL-3.0. Voy paso a paso: instalación con cargo install sshub, navegación con atajos estilo Vim (teclas j/k), el cliente SFTP de doble panel con cola de transferencia y barra de progreso, la gestión de túneles con reconexión automática y backoff exponencial, el registro de auditoría que te salva de conectar al servidor equivocado, y hasta el modo broadcast para ejecutar comandos en varios servidores a la vez. También te explico cómo importar hosts desde Termius, PuTTY o mRemoteNG de forma sencilla. Lo mejor de todo es que SSHub respeta tu configuración SSH existente. No la sustituye, la complementa. Detecta cambios al vuelo con un file watcher, así que cualquier modificación que hagas en tu config aparece al instante en la interfaz. Y si eres de los que prefiere la línea de comandos, tiene modo headless: sshub list, sshub connect, sshub sftp get/put... todo sin abrir la interfaz. Si gestionas más de 10 servidores, usas túneles habitualmente o vienes de Termius buscando una alternativa open source, este episodio te va a interesar. Y si además te gusta hacer las cosas desde la terminal sin depender de aplicaciones gráficas, SSHub te va a encantar. Dale una oportunidad, que es gratis y no tienes nada que perder. Te espero dentro. Capítulos del episodio: 0:00 — Introducción: el problema de gestionar múltiples servidores SSH 1:50 — El script de 2019 y la necesidad de una herramienta moderna 3:40 — SSHub: la TUI open source que lo unifica todo 5:30 — Características principales: hosts, túneles, claves y auditoría 7:30 — Instalación de SSHub con Cargo 9:30 — Navegación y atajos de teclado 11:30 — SFTP de doble panel y transferencia de archivos 13:30 — Gestión de túneles y claves SSH 15:15 — Auditoría de conexiones 17:00 — Importación, exportación y personalización 18:45 — ¿Para quién es SSHub? Despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

¿Sabías que puedes convertir cualquier texto en coordenadas de 1024 dimensiones y hacer búsquedas inteligentes, clasificación automática o detección de duplicados sin depender de servicios en la nube? En este episodio te enseño a utilizar los embeddings con Ollama para potenciar tus documentos, correos y apuntes desde tu propio equipo Linux. Los embeddings son una de las tecnologías más fascinantes de la inteligencia artificial actual. Básicamente, convierten palabras, frases o párrafos enteros en vectores numéricos que capturan su significado. Esto permite que un ordenador entienda que "gato" está más cerca de "felino" que de "nevera", y mucho más: desde búsqueda semántica hasta clasificación sin entrenamiento, pasando por deduplicación de documentos y sistemas de recomendación. Lo mejor de todo es que no necesitas una GPU potente ni una cuenta en ningún servicio externo. Con Ollama ejecutándose en local y el modelo BGE-M3 (multilenguaje, con soporte para español), puedes generar embeddings desde la terminal con una simple llamada curl o con unas pocas líneas de Python. Y si necesitas escalar, ChromaDB te ofrece una base de datos vectorial completa con persistencia en disco y filtros por metadatos. Capítulos del episodio: 0:00 - Introducción y concepto de embeddings 2:42 - ¿Qué son los embeddings exactamente? 5:13 - Modelos de embeddings: BGE-M3, all-MiniLM-L6-v2 7:25 - Cómo generar embeddings con Ollama y curl 8:01 - Búsqueda semántica: más allá de grep 11:57 - Búsqueda semántica con Python y NumPy 14:29 - Bases de datos vectoriales para escalar 14:53 - Clasificación sin entrenar el modelo 18:20 - Clasificación de sentimientos y categorías 20:02 - Deduplicación de documentos con embeddings 24:50 - Sistema de recomendaciones con similitud semántica 27:15 - ChromaDB: base de datos vectorial persistente 29:02 - Casos de uso y próximos episodios sobre RAG Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

¿Todavía usando awk para extraer información de ps aux o df? En 2026 hay herramientas mucho mejores. En este episodio te presento tres herramientas que forman un tridente imbatible para trabajar con información del sistema en formato JSON: jc, jq y gron. jc es un conversor de comandos Linux a JSON. Se instala con pip y un simple pipe convierte la salida de ps, df, free, ss, systemctl, lsblk y hasta 60 comandos más en JSON estructurado. Olvídate de awk y de los scripts frágiles que se rompen cuando cambia el orden de las columnas. Con jc, el JSON no depende del formato de salida. Tiene parsers específicos para cada comando, incluyendo crontab, last, lsof, pip list, lsmod, date y más. Si no encuentra el parser que necesitas, puedes crear el tuyo. Está escrito en Python y tiene licencia MIT. jq es la navaja suiza de los JSON. Te permite filtrar, ordenar, agrupar, seleccionar y transformar cualquier JSON con una sintaxis potente. Está escrito en Go y es maduro, estable y rapidísimo. Combinado con jc, puedes listar los procesos que más RAM consumen, los discos por encima del 80% de ocupación o los servicios que han fallado, todo en una sola línea. Si la sintaxis te parece liosa, puedes pedirle a cualquier modelo de lenguaje que te genere la expresión que necesitas. gron es el menos conocido pero igual de útil. Aplana un JSON convirtiendo cada valor en una línea independiente con su ruta completa. ¿Para qué sirve? Para poder usar grep directamente sobre un JSON. Si alguna vez has hecho un curl a una API y has intentado hacer grep sobre el resultado, sabes que no funciona porque todo está en una línea. Con gron, cada valor tiene su propia línea y puedes buscar con grep. Además permite la operación inversa con --ungron: modificas el JSON aplanado con sed y lo reconstruyes. En el episodio presento sysreport.py, un script en Python que junta toda la información del sistema en un solo JSON usando jc y luego te permite hacer preguntas en lenguaje natural usando Llama 3.2 con Ollama. Le preguntas qué procesos consumen más RAM, qué servicios están caídos o si hay algún disco lleno, y él te responde en lenguaje natural. Todo corriendo en local, sin gastar un euro en APIs. El script se puede usar como API local, se combina con watch para monitorización en tiempo real y con notify-send para notificaciones en el escritorio. Además se integra directamente con el nightly-runner del episodio 815 para incluir el estado del sistema en el resumen matutino. Capítulos: 0:00 - Introducción: el problema de la salida en texto plano 2:30 - jc: convierte comandos Linux a JSON 5:00 - jq: la navaja suiza de los JSON 8:00 - gron: haz greppable cualquier JSON 10:30 - Combinando jc y jq para consultas del sistema 13:00 - sysreport.py: el script que lo junta todo 16:00 - Preguntando al sistema en lenguaje natural 19:00 - Monitorización con watch y notificaciones 21:00 - Ventajas: local, sin coste y sin dependencias 23:00 - Cierre: el tridente JSON Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

¿Cansado de perder 15 minutos cada mañana revisando el tiempo, las noticias, las ofertas y el estado de tu servidor? En este episodio te muestro cómo automatizar todo ese proceso con un script en Python, un timer de systemd y un modelo de lenguaje local. Sin n8n, sin agentes, sin servicios externos de pago. Mucha gente piensa que para automatizar cualquier cosa necesitas un agente con montones de herramientas MCP, skills y configuración. Pero la realidad es que para muchas tareas cotidianas, un agente es como usar un lanzamisiles para matar una mosca. Consume demasiado contexto, demasiados recursos y al final no es la solución más eficiente. En este episodio te presento el patrón de las tres capas: un script que hace el trabajo, un timer que lo ejecuta a una hora determinada y un sistema de notificaciones que te envía el resultado. Con esto puedes automatizar cualquier cosa de forma sencilla, eficiente y completamente bajo tu control. Te explico cómo he creado el nightly-runner, un script en Python que cada madrugada recopila información de cuatro fuentes distintas. Primero consulta el tiempo en wttr.in, que te devuelve un JSON con la temperatura, el viento, la humedad y los rayos ultravioleta. Luego hace scraping con IA de tus fuentes de noticias favoritas, extrayendo titulares y valorando su relevancia. Después busca ofertas de zapatillas de running en varias tiendas, comparando los precios con los del día anterior. Y por último recoge información del sistema con df, free, uptime y ps aux para saber si tu disco se está llenando o te estás quedando sin RAM. Toda esa información se guarda en archivos JSON y luego se pasa por un modelo de lenguaje local, Llama 3.2 con Ollama, que genera un resumen en lenguaje natural. El resultado es un mensaje de Telegram con un tono cercano que te da los buenos días, te cuenta el tiempo que va a hacer, te destaca las noticias importantes, te avisa si hay una oferta que no puedes dejar pasar y te informa del estado de tu servidor. Todo en un solo mensaje. El timer de systemd con Persistent=true se asegura de que si tu equipo estaba apagado a las 4 de la mañana, el script se ejecute en cuanto se encienda. Y cada capa es tolerante a fallos: si wttr.in está caído, el script simplemente omite el tiempo y el resumen dice que no hay información meteorológica disponible. Si no hay ofertas nuevas, no las menciona. Si Ollama no responde, envía el resumen sin procesar. Lo mejor de todo es que no necesitas saber Python para montar esto. Puedes usar Open Code o Gemini para que te genere el script con solo explicarle lo que quieres. Y para ejecutarlo, Llama 3.2 en local es más que suficiente. Sin gastar un euro en APIs. Capítulos: 0:00 - Crítica a los agentes como solución universal 2:00 - El problema: 15 minutos perdidos cada mañana 4:00 - La solución: tres capas (script, timer, notificación) 5:30 - wttr.in: el tiempo en JSON con un curl 7:30 - Noticias: scraping con IA para extraer titulares 9:30 - Zapatillas: comparativa de precios contra caché 11:00 - Sistema: df, free, uptime y ps aux 13:00 - El resumen: todos los JSONs pasan por Llama 3.2 16:00 - Systemd timer con Persistent=true 18:00 - Notificaciones a Telegram y notify-send 20:00 - Tolerancia a fallos en cada capa 21:30 - Genera el script con IA aunque no sepas Python 23:00 - Comparación con Hermes: menos es más Este podcast pertenece a la red de Sospechosos Habituales. Más información en atareao.es Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

En este episodio te enseño a combinar ImageMagick, Tesseract y Llama 3.2 para crear un pipeline de OCR inteligente en Linux. Olvídate de reescribir capturas de pantalla a mano. ¿Cuántas veces te ha pasado que alguien te envía una captura de pantalla con información que necesitas y tienes que copiarla a mano? O peor aún, tienes un PDF escaneado del que no puedes seleccionar texto. Hasta ahora la solución era pasar horas transcribiendo o conformarte con un OCR básico que devuelve texto lleno de errores. En este episodio te muestro cómo construir un pipeline completo que automatiza todo el proceso. Primero capturas la imagen o la recibes, luego la preprocesas con ImageMagick para mejorar el contraste y eliminar ruido, después aplicas Tesseract para el OCR y por último pasas el resultado por un modelo de lenguaje local, Llama 3.2, que corrige los errores y da formato al texto. Todo con herramientas de código abierto, sin enviar tus datos a servidores externos. El script ocr_ai.py que he creado es capaz de detectar automáticamente el tipo de contenido que estás procesando. Si es código fuente, aplica un pipeline de preprocesamiento más agresivo con threshold y sharpen intensivos, y un prompt de IA específico para restaurar la indentación y la sintaxis sin cambiar nombres de variables. Si es una tabla, preserva la estructura de filas y columnas, corrigiendo números mal reconocidos pero sin rellenar celdas vacías. Si es prosa, simplemente corrige acentos, puntuación y caracteres mal interpretados sin alterar el significado del texto. También te explico cómo monitorizar un directorio con inotifywait para que cualquier imagen que caiga en él se procese automáticamente, ideal para combinarlo con carpetas compartidas de Nextcloud o Syncthing y tener OCR automático desde el móvil. Y cómo combinar todo con wl-copy en Wayland o xclip en X11 para tener el texto directamente en el portapapeles con un solo atajo de teclado. Cubrimos Tesseract 5 y su motor LSTM, los modos de segmentación de página (PSM 3, 6, 7 y 11), los diccionarios personalizados con --user-words para dominios específicos, las operaciones de ImageMagick v7 como colorspace gray, normalize, threshold, deskew, sharpen, negate y morphology, y cómo ajustar cada parámetro según el tipo de imagen. Además hablamos de OCRmyPDF para añadir capa de texto a PDFs escaneados y convertir cualquier PDF en un documento seleccionable y buscable. El episodio incluye consejos prácticos para troubleshooting: cómo ajustar el threshold cuando el texto es borroso (valores entre 40% y 65%), cómo reducir el ruido con filtros de morfología, cómo redimensionar imágenes con texto muy pequeño usando -resize 200%, cómo manejar fotos de documentos con -median 3, y cómo crear diccionarios personalizados con --user-words para mejorar el reconocimiento en dominios específicos como facturas, logs o código fuente. Capítulos: 0:00 - El problema de las capturas de pantalla 2:00 - Motivación: running, Hermes y el pipeline completo 4:00 - Captura y preprocesamiento con ImageMagick 6:30 - Operaciones clave: normalize, threshold, deskew y sharpen 8:30 - Pipelines personalizados según el tipo de imagen 10:30 - Tesseract: instalación, modos y diccionarios 14:00 - ocr_ai.py: detección automática del contenido 18:00 - Corrección con Llama 3.2 y prompts específicos 23:00 - Monitorización de directorios y automatización 24:30 - Consejos prácticos y cierre Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

En este episodio de Atareao con Linux nos vamos a remangar para hablar de una de esas tecnologías que, una vez las dominas, te cambian la vida por completo: el Web Scraping asistido por Inteligencia Artificial. Seguro que te ha pasado alguna vez. Quieres comprar un producto concreto, como unas zapatillas de running (yo las cambio cada 800 kilómetros y es un goteo constante), o quieres extraer todas las recetas de cocina de una web para montarte tu propio planificador semanal. Lo ideal sería que estas páginas tuvieran una API pública para descargar la información de forma limpia. Pero la cruda realidad es que casi ninguna te lo pone fácil. Ahí es donde entra el scraping: la técnica de extraer la información directamente de la página web. En este episodio te cuento por qué el scraping clásico (ese que utiliza Beautiful Soup en Python y depende de identificar las etiquetas HTML y las clases CSS) tiene los días contados para tareas complejas. Basta con que un desarrollador cambie el diseño de la web para que tu script se rompa por completo. Además, con la llegada de las webs dinámicas, los tests A/B y los sistemas anti-bloqueo como Cloudflare, mantener un scraper tradicional es un auténtico dolor de muelas. La gran alternativa: Inteligencia Artificial en local ¿Y si en lugar de pelearnos con el código fuente dejamos que un modelo de lenguaje (LLM) entienda la página exactamente igual que lo haría un humano? Un LLM comprende perfectamente qué es un "precio" o el "nombre de un producto", sin importar cómo esté maquetada la web ni el idioma en el que esté escrita. Y lo mejor de todo: ¡lo podemos hacer 100% gratis en local usando Ollama! Te detallo mis pruebas ejecutando modelos en mi Slimbook One utilizando únicamente la CPU (¡sin gastar un céntimo en nubes ni necesitar tarjetas gráficas carísimas!). Hablaremos de cómo rinden modelos como Llama 3.2, Qwen, Mistral y DeepSeek R1, y cuál es el punto de equilibrio perfecto para no eternizarnos esperando la respuesta. También te desvelo mi fórmula secreta para procesar la información. No podemos enviarle 2 Megabytes de HTML ruidoso a la IA. Te explico los 5 pasos que utilizo en Python para eliminar la basura (scripts, estilos, navegación) y reducir el HTML hasta en un 93%, permitiendo que el modelo extraiga los datos en segundos y nos devuelva un JSON estructurado impecable. Por último, vemos cómo montar un auténtico vigilante de ofertas automatizado en segundo plano. Un sistema que compare los precios de varias tiendas en paralelo. Capítulos del episodio: 00:00:00 Introducción al Web Scraping con Inteligencia Artificial 00:01:22 ¿Para qué sirve extraer datos? Ejemplos prácticos 00:02:42 El gran talón de Aquiles del scraping tradicional 00:04:31 La revolución de la IA: Entender la web sin saber HTML 00:07:36 Los problemas habituales: Selectores rotos y webs dinámicas 00:10:00 Cómo un modelo de lenguaje (LLM) procesa la información 00:13:17 Cuándo elegir scraping clásico vs. scraping con IA 00:15:28 Comparación de costes: Enfoque clásico, IA local e IA en la nube 00:17:19 ¿Qué modelos usar? Pruebas con Llama, Qwen, Mistral y DeepSeek 00:18:19 Detrás de escena: Mi script de Python y la limpieza del HTML 00:21:05 Creando el prompt perfecto para extraer un JSON estructurado 00:24:34 Ejemplo real: Comparativa paralela entre tiendas 00:28:38 Diseñando un vigilante de ofertas automatizado (24/7) 00:30:17 Casos de uso prácticos y mejoras para evitar bloqueos 00:32:02 Cierre y detalles del próximo tutorial de scraping Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Si alguna vez habías pensado que en el mundo de los emuladores de terminal ya estaba todo inventado y que no había margen para la sorpresa, déjame decirte que estás muy equivocado. Yo también lo pensaba, de verdad. Pero la innovación no descansa y en este episodio te voy a presentar una propuesta que cambia por completo las reglas del juego. En mi búsqueda constante de la herramienta ideal para mi día a día, he pasado por Alacritty, por WezTerm, por mi queridísima Kitty y, recientemente, estuve dándole una oportunidad de oro a Ghostty. Sin embargo, me topé con un pequeño pero molesto inconveniente con la escritura de acentos que me obligó a volver a los brazos de Kitty. Pero como soy incapaz de resistirme a probar cualquier terminal nueva que caiga en mis manos, hoy quiero hablarte a fondo de Wave. ¿Es una terminal? ¿Es un navegador? ¿Es un entorno de desarrollo? Te lo adelanto ya: es todo eso a la vez y estructurado de una manera que te va a volar la cabeza. Un nuevo paradigma: El espacio de trabajo por bloques Wave no es una terminal corriente como las que estás acostumbrado a usar. En el episodio de hoy te detallo cuáles son los cinco bloques fundamentales que incluye de serie y cómo cambian por completo la forma en que nos enfrentamos a la línea de comandos: Bloques de Terminal Bloques de Visor de Archivos Bloques Web Bloques de Editor Bloques de Inteligencia Artificial La magia de los Layouts y los espacios de trabajo Otro de los grandes aciertos de Wave es la posibilidad de guardar y gestionar tus disposiciones de pantalla o "Layouts". SSH Durable: Conexiones indestructibles para administradores Si trabajas habitualmente con servidores remotos, este superpoder te va a encantar. Las conexiones SSH convencionales son muy sensibles: si cambias de la red Wi-Fi de tu casa a los datos móviles, si se produce un microcorte o si simplemente cierras la tapa de tu portátil para cambiar de sitio, la conexión muere y pierdes todo lo que estabas haciendo. Inteligencia Artificial local para máxima privacidad La IA también está integrada de forma nativa en este entorno. Lo realmente interesante es que Wave te permite configurar tanto servicios en la nube (OpenAI, Anthropic) como modelos de lenguaje locales (por ejemplo, usando Llama). ¿Y por qué me sigo quedando con Kitty? Al final del episodio abordo este dilema. Aunque Wave me parece una de las propuestas más originales, potentes y visuales de los últimos años, sigo prefiriendo la ligereza de Kitty combinada con gestores de terminal rápidos como Yazi. Capítulos del episodio: 00:00:00 El dilema de las terminales: de Kitty a Ghostty y Wave 00:02:11 ¿Qué es Wave? ¿Hacía falta otra terminal Open Source?00:03:41 El concepto revolucionario de los bloques 00:06:07 Los 5 tipos de bloques: terminal, visor, web, editor e IA 00:08:43 Cómo moverte entre bloques como un profesional 00:09:43 Creando tus propios espacios de trabajo (Layouts) 00:13:20 Renderizado gráfico y el explorador de archivos integrado 00:16:30 Inteligencia Artificial nativa y modelos locales 00:18:00 Extendiendo la terminal con TypeScript y React 00:20:47 SSH durable: conexiones indestructibles que sobreviven a todo 00:22:13 Gestor de conexiones y contraseñas seguro 00:23:11 Trucos rápidos y por qué me sigo quedando con Kitty 00:25:24 Despedida y dónde encontrarnos para seguir cacharreando Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Si has estado siguiendo mis últimos episodios, sabrás que ando entusiasmado con Hermes, este increíble agente autónomo de Inteligencia Artificial que se ha convertido en mi mano derecha para automatizar todo tipo de tareas en mi servidor. Sin embargo, me he dado cuenta de que he pasado muy de puntillas sobre una de sus características más potentes y que de verdad marca la diferencia cuando queremos exprimir al máximo sus capacidades: los subagentes. 🧠 El gran problema del contexto: Por qué tu IA se vuelve lenta y cara Para entender la magia de los subagentes, primero tenemos que hablar del principal cuello de botella de los modelos de lenguaje: la ventana de contexto. I Si estás utilizando un modelo comercial muy potente con una ventana de contexto enorme, puede parecer que no hay problema. El problema es que en cuanto te descuidas, esa conversación ya ha consumido 20.000 o 30.000 tokens. Esto tiene tres consecuencias directas que te van a doler: Menor rendimiento Costes disparados Asfixia en local 🕵️ ¿Qué es un subagente y por qué es el ayudante ideal? Un subagente es, en esencia, un hilo de ejecución completamente nuevo y aislado que hereda una tarea hiperespecífica de su "padre" (el agente con el que estás chateando directamente). Piensa en él como en un ayudante temporal al que le asignas una misión muy concreta y que cuenta con una serie de ventajas diseñadas para la eficiencia: Aislamiento total Terminal independiente Herramientas restringidas (Toolsets) Modelos flexibles Cuando el subagente termina su labor, redacta un resumen escueto con el resultado final y se lo entrega al padre. 📏 La regla de oro: ¿Cuándo delegar y cuándo ejecutar directamente? ⏱️ Estructura temporal del episodio Si quieres saltar directamente a una sección concreta del programa, aquí tienes la guía de capítulos completa de este episodio: 00:00:00 Introducción a los subagentes de Hermes 00:01:10 ¿Qué es un subagente y por qué lo necesitas? 00:03:21 El problema del contexto y cómo solucionarlo 00:05:15 Los tres pilares: Objetivo, Contexto y Herramientas 00:06:19 La regla de oro: ¿Delegar o ejecutar código directamente? 00:08:19 Cómo definir tareas de forma específica y segura 00:11:12 Qué pasa dentro de un subagente (Aislamiento y límites) 00:12:05 Ejemplos prácticos: Búsquedas de ofertas y análisis de sistema en paralelo 00:16:30 Límites de configuración: Concurrencia y profundidad de agentes 00:19:40 El futuro de Hermes: Delegación síncrona vs. asíncrona 00:21:54 Casos de uso reales y errores comunes que debes evitar 00:24:02 Conclusiones y un adelanto sobre RAG y Ollama 00:25:58 Despedida y canales de la comunidad 🚀 Dos experimentos prácticos que vas a escuchar hoy En este episodio te detallo dos pruebas reales que he estado haciendo en mi laboratorio para que veas el potencial de trabajar de forma paralela: Por un lado, la búsqueda de ofertas multitarea. Por otro lado, la auditoría de recursos concurrentes. Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hoy dejamos a un lado por un momento los modelos de lenguaje y la inteligencia artificial para volver a los clásicos de este pódcast: la optimización y el disfrute de nuestra terminal de Linux. He decidido intercalar estos temas para no aburrir a nadie. Sé que la inteligencia artificial es fascinante, pero de vez en cuando viene muy bien un respiro técnico para centrarnos en lo que siempre nos ha apasionado: exprimir al máximo nuestro sistema operativo favorito. Por eso, hoy te traigo lo que yo llamo el tridente de la terminal, un trío de herramientas que, cuando se integran y empiezan a trabajar juntas, cambian por completo tu flujo de trabajo. Te aseguro que, una vez que las pruebas, ya no hay vuelta atrás. El buscador difuso interactivo: FZF La primera pieza de nuestro tridente es FZF (Fuzzy Finder). Imagina que tienes una lista gigante de archivos o de comandos y quieres encontrar algo específico. En lugar de escribir el término de búsqueda exacto, FZF te permite realizar una búsqueda difusa. Si buscas, por ejemplo, la palabra firefox, te bastará con teclear ffx. El programa entenderá de inmediato lo que estás intentando buscar y te filtrará los resultados en tiempo real. Ripgrep (rg): Búsquedas en milisegundos La segunda herramienta que forma nuestro tridente es Ripgrep, conocida en la terminal simplemente como rg. Si vienes usando el comando grep de toda la vida, Ripgrep va a ser una revelación para ti. Está programada en Rust y su velocidad de búsqueda dentro de archivos es, sencillamente, abrumadora. Bat: El clásico cat rediseñado con superpoderes La tercera punta del tridente es Bat (en algunos sistemas Debian y Ubuntu lo encontrarás como batcat). Todos hemos usado el comando cat para imprimir el contenido de un archivo en la terminal. Bat viene a sustituirlo ofreciendo una visualización muy superior. Cómo armar el tridente: La fusión definitiva Lo verdaderamente potente de estas herramientas no es solo usarlas por separado, sino conectarlas. Combinando Ripgrep con FZF y Bat, consigues un sistema de búsqueda en vivo increíble. Puedes hacer que Ripgrep busque un término en todos tus documentos, pasarle esa lista a FZF para que te permita filtrar de forma interactiva y, mientras te mueves por los resultados, abrir una pequeña ventana en el lateral donde Bat te previsualice en tiempo real el contenido del archivo con la sintaxis coloreada. En el episodio te explico cómo definir estas funciones en tu archivo de configuración (Bash, Zsh o Fish). De este modo, puedes construirte utilidades personalizadas con solo unas pocas líneas de código: desde un explorador de commits de Git muy visual hasta tu propio gestor de notas Markdown, rápido y sin distracciones, eliminando la necesidad de recurrir a pesados programas con interfaz gráfica. Capítulos de este episodio Aquí tienes la estructura del episodio para que puedas moverte cómodamente por el contenido: 00:00:00 Introducción y el tridente de la terminal 00:01:22 FZF: El buscador difuso interactivo 00:03:00 Atajos de teclado esenciales para FZF 00:08:16 El autocompletado mágico de FZF 00:09:09 Ripgrep (rg): Búsquedas a la velocidad de la luz 00:12:47 Combinando Ripgrep y FZF 00:14:26 Bat: El comando "cat" con superpoderes 00:18:07 Armando el tridente: Cómo combinar las tres herramientas 00:19:48 Casos prácticos: Explorar commits, matar procesos y gestionar notas 00:21:49 El ecosistema completo de 5 herramientas 00:23:19 Integración con IA, despedida y conclusiones Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Te traigo un tema que me tiene completamente entusiasmado: cómo exprimir todos tus documentos, notas, manuales o archivos locales sin tener que compartirlos con nadie. Te voy a dar una visión general de cómo puedes montar un sistema de recuperación de información para que una inteligencia artificial local se convierta en tu asistente personal definitivo. Todo esto sin salir de tu propia casa, sin APIs de pago y de forma completamente privada. ¿Reentrenar o buscar? El gran dilema Para solucionar esta tremenda limitación, el mundo de la tecnología nos ofrece dos caminos diferentes: hacer un reentrenamiento de un modelo ya existente (lo que conocemos como fine-tuning) o bien montar un sistema RAG (Retrieval-Augmented Generation), que podríamos traducir como generación aumentada por recuperación. En este episodio te desvelo por qué el fine-tuning no es la solución para el común de los mortales: requiere de tarjetas gráficas carísimas, es un proceso lento y estático, y además tus datos privados quedan incrustados dentro del propio modelo, por lo que si se lo entregas a un tercero, estarás regalando tu privacidad. En cambio, un RAG casero es infinitamente más barato, dinámico y respeta tus datos al cien por cien. Imagina que en lugar de obligar al modelo a memorizar toda la biblioteca (que es lo que hace el fine-tuning), le pones a su lado un bibliotecario listísimo que busca la página exacta de los apuntes que necesita antes de responderte. El modelo de lenguaje lee esa página en tiempo real y te contesta basándose únicamente en hechos reales, no en invenciones. La tubería de datos para tu cerebro artificial A lo largo del episodio te explico con todo detalle las piezas que componen esta tubería de datos (o pipeline) que permite hacer magia con tus archivos: La ingesta El troceado (o chunking) Los embeddings y vectores La base de datos La búsqueda híbrida Herramientas listas para usar y errores que debes evitar Si te da miedo el código, no te preocupes. Te hablo también de alternativas como OpenWeb UI. Y si te va la marcha del desarrollo, te cuento cómo con apenas diez líneas de Python y Streamlit puedes tener una aplicación web propia y completamente funcional. Además, repasamos los tropiezos más habituales que cometemos al empezar en este mundillo, como usar modelos de vectorización que solo entienden inglés para procesar textos en español, no limpiar las cabeceras y pies de página de los PDFs antes de procesarlos, o la importancia crucial de reindexar de forma automática para que tus nuevos documentos estén disponibles al instante. Capítulos del episodio 00:00:00 Introducción y de qué va este episodio 00:01:54 ¿A qué problema nos enfrentamos con los LLM? 00:05:08 Fine-tuning vs. RAG: ¿Cuál es mejor para tus datos? 00:08:29 El Pipeline del RAG: De la ingesta a la respuesta 00:10:45 ¿Qué es un "embedding" y qué modelos usar con Ollama? 00:12:02 El arte de trocear el texto (Chunking) 00:13:40 Búsqueda híbrida: Semántica frente a coincidencia exacta 00:14:50 Re-ranking: Ordenando los resultados por relevancia 00:15:53 El Stack: Ollama, PostgreSQL, pgvector y Podman 00:17:25 Alternativas vectoriales: ParadeDB, ChromaDB y Qdrant 00:18:36 Manos a la obra con Python y Streamlit 00:20:53 OpenWeb UI: La alternativa con RAG integrado y sin código 00:21:42 Cómo saber si funciona: El método de las 20 preguntas 00:22:51 Errores comunes que debes evitar al montar tu RAG 00:23:55 Lo que viene: GraphRAG y RAG agéntico 00:24:44 Resumen final y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

En este episodio vamos a hablar de una de esas herramientas míticas del ecosistema Linux y Unix que prácticamente todos hemos configurado alguna vez: Cron. Ese servicio fiel, un clásico entre los clásicos, que lleva décadas ejecutando nuestras copias de seguridad de madrugada o eliminando ficheros temporales. Sin embargo, las cosas cambian, la tecnología avanza y yo creo que ha llegado el momento de que todos jubilemos a Cron. Sí, como lo oyes. Ha llegado la hora de darle una merecida jubilación dorada y abrir los brazos a una alternativa mucho más moderna, integrada y potente: los Systemd Timers. ¿Por qué deberías jubilar a tu viejo Cron? Sé que puedes estar pensando: "Lorenzo, pero si a mí Cron me funciona de maravilla". Y es verdad, para un comando sencillo que se ejecute cada hora, Cron cumple. Pero a poco que intentes complicar la tarea, empiezan los problemas. El gran drama de Cron es que trabaja a ciegas y en absoluto silencio. Si tu script falla por falta de internet, por un error de permisos o porque un recurso no está disponible, no te vas a enterar a menos que te hayas tomado el trabajo de programar tus propios registros de log, gestionar lógicas de reintentos o configurar desvíos de errores dentro de tu script. El poder de los Systemd Timers Con los Systemd Timers todo esto se soluciona de forma completamente automática y sin añadir complejidad a tus scripts. Systemd se encarga de gestionar de manera integrada el estado de tu sistema y te ofrece superpoderes como: Logs centralizados automáticos Gestión inteligente de la persistencia Control de dependencias Aleatorización horaria La anatomía de una tarea en Systemd Para conseguir toda esta potencia, Systemd utiliza un enfoque muy limpio en el que dividimos la tarea en dos archivos de texto sencillos que se complementan a la perfección: El Servicio (.service) El Timer (.timer) Automatización sin root: Los timers de usuario Pero mi funcionalidad favorita, y la que utilizo en mi día a día para casi todo, es la posibilidad de ejecutar estos temporizadores en el espacio del usuario corriente, sin necesidad de tener privilegios de administrador ni usar el comando sudo. Estos temporizadores se guardan en tu propia carpeta de configuración personal de forma limpísima y se ejecutan dentro del contexto de tu sesión activa. Capítulos del audio 00:00:00 Introducción y el adiós definitivo a Cron 00:01:43 Los fallos silenciosos de Cron: Logs, reintentos y dependencias 00:03:06 Las grandes ventajas de usar Systemd Timers 00:05:21 La anatomía de la automatización: Timer y Servicio 00:06:48 Configuración de la sección [Timer], OnCalendar y persistencia 00:07:55 Tareas relativas: OnBootSec y aleatorización de tiempos 00:10:00 Comandos de systemctl para gestionar tus tareas programadas 00:10:33 Ejemplos prácticos en el sistema: Backups y limpiezas 00:12:13 Notificaciones de escritorio e integración con el entorno gráfico 00:14:11 Timers de usuario: Automatización segura sin usar root o sudo 00:15:25 El truco de Linger para mantener tareas activas en VPS 00:16:53 Sincronización continua de notas y cambio automático de fondo 00:20:07 Cómo ver los logs y depurar fallos de forma sencilla con journalctl 00:21:25 Evita estos errores típicos y valida con systemd-analyze 00:24:51 El futuro de la automatización, modelos de lenguaje y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Si has estado atento a los últimos episodios del podcast, ya te habrás dado cuenta de que estoy completamente enfocado en exprimir la inteligencia artificial local y el software libre. En concreto, hay dos herramientas que se han convertido en mis compañeras inseparables de fatigas en el día a día: OpenCode, que me ayuda a programar de una forma increíble, y Hermes Agent, un asistente digital del que hoy te lo quiero contar absolutamente todo. El dilema de la instalación: ¿Docker o en tu propia máquina? Como ya me conoces, sabes bien lo mucho que me gusta a mí levantar "al rico contenedor" y solucionar cualquier despliegue con Docker. Sin embargo, en mis pruebas con Hermes Agent he preferido dar un paso atrás y realizar una instalación directa sobre el sistema operativo, utilizando un entorno virtual de Python. El peligro de la ventana de contexto y la sangría de tokens Aquí está uno de los grandes secretos que casi nadie te explica al principio. Cuando ejecutas el asistente de configuración inicial de Hermes Agent, te entran ganas de activar absolutamente todas las características que te ofrece: herramientas de visión, utilidades del sistema, navegación web, traducción... ¡todo suena fantástico! Pero hay una trampa invisible en la que es muy fácil caer. El superpoder de los perfiles aislados (Profiles) La solución definitiva a este problema de consumo y rendimiento tiene un nombre: perfiles. Hermes Agent te permite crear tantos perfiles aislados como consideres oportuno. Modelando el Alma y la Memoria de tu Agente En el podcast te detallo cómo dar personalidad a tu agente a través del archivo de alma. A mi asistente personal, que he bautizado como Chloe, le he configurado un tono sarcástico, irónico y burlón. Me encanta interactuar con ella de esta manera porque rompe completamente con la clásica respuesta robótica y aburrida de otras inteligencias artificiales comerciales; se siente como hablar con un colega de verdad. Eso sí, te doy pautas para redactar este archivo con cuidado, ya que un "alma" demasiado extensa también te comerá espacio de contexto útil de forma innecesaria. Ampliando fronteras: MCP, Telegram y automatizaciones automáticas Por último, abordamos el fantástico protocolo MCP (Model Context Protocol), que nos permite dotar de "manos y ojos" a nuestro agente. Y para rematar la jugada, la integración con Telegram y Matrix. Es una auténtica delicia poder ir caminando, mandarle un audio desde el móvil a mi bot de Telegram, que este use Whisper en local para transcribir mi voz, procese lo que le pido y me conteste con otro audio sintetizado a la velocidad que yo le he configurado de antemano. Todo ello combinado con tareas programadas (Cron) y un tablero de Kanban interno con el que el propio agente se organiza y ejecuta flujos de trabajo de forma completamente autónoma. Te invito a que te prepares un buen café, te pongas los auriculares y disfrutes de este viaje de configuración avanzada de 0 a 100. CAPÍTULOS DEL AUDIO: 00:00:00 Introducción: Mi día a día con OpenCode y Hermes Agent 00:01:26 El problema de los tutoriales básicos e instalación 00:03:00 Configuración inicial y la sangría de tokens 00:04:47 Archivos clave y estructura interna de Hermes 00:05:56 Creando "Skills" personalizadas y configurando API Keys 00:08:15 Perfiles aislados (Profiles): Qué son y por qué los necesitas 00:11:00 Cómo clonar y gestionar tus perfiles sin romper nada 00:13:35 soul.md: Diseñando el "Alma" y el tono de tu asistente 00:15:28 memory.md: El gran desafío de la memoria y el RAG en Rust 00:17:38 Expandiendo capacidades con MCP y conversión de voz 00:20:47 Llevando tu agente a Telegram con Cron y Kanban integrado 00:27:18 Reglas de oro para optimizar tu contexto y despedida

Seguro que si eres de los míos, de los que disfrutan pasando el rato en la terminal o montando servicios en casa, te habrás dado cuenta de que acabamos haciendo tareas repetitivas casi sin querer. Para poner fin a este caos cotidiano te traigo una herramienta espectacular que se llama Just. Pero la verdadera razón por la que he querido dedicarle este pódcast a Just de nuevo es por una experiencia divertidísima que he tenido estos últimos días con mi asistente de inteligencia artificial local, al que cariñosamente llamo Hermes. Yo soy una persona bastante perezosa para ciertas tareas repetitivas y me gusta poner a trabajar a las máquinas por mí. Normalmente, al acabar mis entrenamientos de carrera, le dicto un audio a Hermes detallando la distancia, las pulsaciones y el ritmo para que él los registre. Pero el otro día, llevado por la vaguería máxima, decidí simplemente hacer una captura de pantalla de la aplicación del móvil y enviársela por Telegram. Hermes, que es una maravilla de asistente, aplicó un sistema de lectura de imágenes (OCR) llamado Tesseract, extrajo todos los datos de mi carrera y los guardó en un periquete. Yo me quedé encantado y pensé que la vida ya estaba resuelta. Sin embargo, al día siguiente repetí el proceso y... ¡sorpresa! Hermes se había olvidado por completo de cómo lo había hecho. Me preguntó qué quería que hiciese con la imagen y, cuando le recordé lo del día anterior, me soltó que no tenía la herramienta de lectura instalada en su entorno de trabajo. Tuve que guiarle de nuevo de la mano paso a paso. Ahí fue donde se me encendió la bombilla. Las inteligencias artificiales a veces se despistan y tienen una memoria muy volátil para los flujos de trabajo técnicos. La mejor forma de darles estabilidad es crearles un recetario claro, un archivo "justfile" donde tengan todas sus habilidades documentadas y listas para ejecutar con un simple comando. Así, Hermes nunca más olvidará cómo procesar una imagen o cómo gestionar un contenedor, porque solo tiene que invocar la receta correspondiente. En este episodio quiero animarte a que pruebes Just en tu propio día a día, uses o no inteligencia artificial. Capítulos del episodio: 00:00:00 Introducción: Olvídate de repetir comandos 00:01:33 El problema con Hermes: Por qué las IA también se despistan 00:03:04 ¿Qué es Just y cómo funciona? 00:04:59 Cómo instalar Just en Linux 00:05:31 Comparativa: Just contra Make y Task 00:06:42 Gestión de variables, argumentos y funciones 00:08:49 Atributos de receta para afinar su comportamiento 00:10:00 El comportamiento de las líneas y el poder del Shebang 00:11:00 Funciones integradas y ajustes globales 00:12:00 Operadores, expresiones y dependencias complejas 00:13:00 Usando intérpretes alternativos (Bash, Python, Node) en Just 00:14:18 Recetas normales frente a recetas Shebang y scripts 00:15:33 Módulos e importación de recetas externas 00:16:38 El selector interactivo con búsqueda difusa (just choose) 00:17:37 Alias, grupos y autocompletado en tu shell 00:18:09 Casos prácticos de uso real (Sysadmin, Docker, Backups) 00:19:18 Documentación viva y ejecutable para todo el mundo 00:20:17 Control de versiones con Git y límites de Just 00:21:10 Una historia de pereza, Hermes, deporte y OCR que se olvida 00:22:59 Conclusiones: Simplifica tu vida con este ejecutor de comandos 00:24:58 Cierre del episodio y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hoy en Atareao con Linux vamos a hablar largo y tendido sobre el Vibe Coding y cómo está cambiando por completo las reglas del juego en este 2026. Si estás escuchando esto mientras vas al trabajo, cocinas o das un paseo, y crees que esto no va contigo porque nunca has tocado una sola línea de código... ¡espera! No toques el botón de siguiente episodio. Este podcast es precisamente para ti. ¿Alguna vez has tenido esa pequeña idea en la cabeza de una aplicación sencilla que te solucionaría la vida, pero la has descartado porque no sabes programar o no tienes tiempo para aprender? El Vibe Coding es el puente que te va a permitir cruzar esa brecha y hacer realidad tus ideas explicándoselas a la tecnología igual que me las explicarías a mí, con tus propias palabras. El nacimiento de un nuevo paradigma: Del "Vibe" al Agentic Engineering Para entender esta auténtica locura nos tenemos que remontar a febrero de 2025. Andrej Karpathy, una de las mentes más brillantes en el mundo de la Inteligencia Artificial (ex OpenAI y ex Tesla), lanzó un tuit que corrió como la pólvora por todo internet. En ese mensaje acuñó el término Vibe Coding: una nueva forma de programar en la que te dejas llevar por las vibraciones, abrazas el crecimiento exponencial y te olvidas de que el código realmente existe. La idea caló de tal forma que se convirtió en la palabra del año para el diccionario Collins y hoy, un año después, el 84% de los programadores la integran en su rutina. Mi experimento en directo: Una aplicación a medida por dos céntimos A mí no me gusta hablar de oídas, así que al principio del episodio me he puesto manos a la obra. He abierto mi terminal de Linux, he lanzado una herramienta de código abierto maravillosa llamada OpenCode y le he pedido que crease una aplicación para la terminal en Rust para gestionar mis tareas (un TODO clásico) ¿Qué herramientas tenemos a nuestro alcance en 2026? • Cursor • Lovable • Claude Code Por otro lado, si eres de los míos y te apasiona el código abierto: • OpenCode. • Cline. • OpenHands • Aider El lado oscuro: Las trampas de la falsa seguridad No todo es perfecto y es de vital importancia hablar del lado oscuro de esta tecnología. Es una trampa cognitiva de falsa confianza de manual. La conclusión: La IA no te quitará el trabajo, pero sí cambiará el juego Capítulos del episodio: 00:00:00 Introducción al Vibe Coding y la revolución del desarrollo00:01:40 El origen del Vibe Coding y cómo empezar con un prompt00:05:50 ¿Qué es realmente el Vibe Coding y qué es el Agentic Engineering?00:08:20 ¿Para quién sirve el Vibe Coding? Productividad, MVPs y aprendizaje00:09:40 Herramientas privativas de Vibe Coding: Cursor, Lovable y Claude Code00:13:25 Alternativas de Código Abierto (Open Source): OpenCode, Cline, OpenHands y Aider00:17:05 Demostración en vivo: Ejecutando nuestra aplicación TODO en Rust por dos céntimos00:22:50 El lado oscuro del Vibe Coding: Seguridad, vulnerabilidades y deuda técnica00:26:30 Cómo aprovechar la Inteligencia Artificial sin arruinar tu código00:30:05 El futuro del desarrollo de software y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Si has estado escuchando los últimos capítulos, te habrás dado cuenta de que he estado sumergido de lleno en el fascinante (y a veces abrumador) mundo de la Inteligencia Artificial. De vez en cuando mi mente me pide a gritos un descanso. Y para mí, descansar significa volver a los orígenes: ponerme a cacharrear con la terminal y escribir código en Rust. En el episodio de hoy quiero cambiar completamente de tercio. Te voy a contar mi experiencia de las últimas semanas saliendo de mi zona de confort con un editor de texto modal que me tiene maravillado en los servidores, y te presentaré cuatro herramientas que he desarrollado en Rust para solucionar pequeños problemas del día a día directamente en la consola de comandos. Así que, ponte cómodo mientras cocinas, vas de camino al trabajo o das un paseo, ¡porque nos vamos directos al turrón! El gran dilema de la terminal: ¿Por qué uso Helix en mis servidores si soy fiel a NeoVim? Los que me seguís desde hace tiempo sabéis que mi editor de cabecera en mi equipo de trabajo habitual es NeoVim. Llevo muchísimos años puliendo mi configuración y, a día de hoy, tengo más de cien plugins instalados que hacen que mi entorno sea espectacular: autocompletado instantáneo, una barra de estado genial, un explorador lateral de archivos y un sistema de análisis de código brutal. Pero, ¿qué pasa cuando me conecto por SSH a mis servidores de producción? Normalmente, estos servidores corren distribuciones Ubuntu de soporte a largo plazo con paquetes más antiguos, por lo que mi configuración de NeoVim moderna empieza a fallar estrepitosamente. Instalar y mantener más de cien plugins en cada uno de los servidores que gestiono es un dolor de cabeza inmanejable. Para solucionar esto sin renunciar a la agilidad de un editor modal en terminal, decidí darle una oportunidad a Helix. Peleándome con la memoria muscular Tengo que confesarte que adaptarme a Helix ha sido un ejercicio duro para mis dedos. Cuando llevas años interiorizando los comandos de Vim, tu cerebro automatiza la edición. Mis herramientas caseras desarrolladas en Rust Aquí te hablo de ellas en detalle: 1. mkdr (Markdown Reader/Render): Como todos mis artículos de atareao.es y mis notas personales están guardados en formato Markdown, necesitaba un renderizador potente para leerlos cómodamente desde la consola de comandos. 2. id3cli: Automatizar los metadatos de los episodios de este podcast es crucial para mí. 3. rustled: Para que mi asistente de inteligencia artificial, Cloe, pudiera comunicarse conmigo por voz, necesitaba una herramienta de texto a voz (Text-to-Speech) flexible 4. ssrs: Si en algún momento no dispongo de conexión a internet o prefiero que los textos se procesen con absoluta privacidad, recurro a susurros. 00:00:00 Introducción y un descanso de la Inteligencia Artificial 00:00:56 ¿Qué es Helix y por qué me costó al principio? 00:02:27 El problema de llevar NeoVim (y sus plugins) a los servidores 00:06:23 Primeros pasos con Helix: el tutor y las diferencias con Vim 00:09:34 Pantalla dividida, multicursor y velocidad extrema 00:10:54 Temas, resaltado de sintaxis de serie y comandos 00:15:12 Mis propias herramientas: renderizar Markdown en terminal con mkdr 00:18:40 Navegación estilo Wiki y otras ventajas de mkdr 00:20:18 id3click: gestionando etiquetas MP3 sin depender de terceros 00:21:52 Dándole voz a Cloe: raslet y la API de Microsoft Edge TTS 00:24:35 susurros: generación de voz 100% en local con Rust 00:26:55 El futuro: ssrs (Whisper en Rust) y conclusiones 00:28:35 Recomendación de podcast: Legalmente Productivos y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Olvídate de hacerle preguntas genéricas a ChatGPT; hoy vamos a ver cómo sacarle partido real y práctico a la tecnología para solucionar problemas cotidianos y quitarnos de encima la fatiga de decisión diaria. Seguro que te suena la película: post-its en la nevera, hojas de cálculo que se quedan desactualizadas y el clásico "¿qué cenamos hoy?" que acaba en improvisación o en una compra desorganizada. Para evitar esto, he diseñado un ecosistema de agentes basados en cuatro cajas de herramientas que llamamos MCP (Model Context Protocol). Estos protocolos permiten que la IA no solo responda preguntas, sino que interactúe de forma directa con mis datos y aplicaciones externas. Te explico de forma muy sencilla las piezas que componen este sistema: El RAG Semántico para las recetas: Tengo una base de datos vectorial con unas 1.700 recetas cargadas en PostgreSQL mediante pgvector. La clave es que no busco platos por coincidencia exacta de palabras. Si le digo que quiero "algo rápido y ligero con verdura", el sistema realiza una búsqueda semántica, entiende lo que busco y me propone las mejores opciones. Todo esto se procesa de forma económica mediante OpenRouter sin necesidad de tener una potente GPU en local. Los Skills y SQLite: Los "Skills" definen los procesos exactos que debe seguir el modelo. Le he marcado unas pautas sencillas: platos únicos mediterráneos para comer y cenas ligeras. Toda esta información se gestiona en una base de datos SQLite muy ligera. Lógica difusa en la lista de la compra: El asistente es capaz de agrupar ingredientes similares. Si dos recetas piden tomates en formatos distintos (por ejemplo, "tomates a granel" y "100g de tomates"), la lógica difusa los unifica bajo un mismo concepto para evitar duplicados en la lista de la compra, organizando además los productos por pasillos o secciones (como frutería o carnicería). Typst para exportar a PDF: Para ver el menú en una tablet o imprimirlo para la nevera, utilizo Typst, una alternativa moderna a LaTeX que me genera unos documentos PDF impecables en cuestión de segundos. Además, te cuento cómo puedes montar todo esto en local de manera gratuita con Ollama, y aprovecho para actualizarte sobre mis andanzas de vuelta al "cacharreo" puro en Linux: desde mis experiencias recientes con el editor Helix y "mkdr" (mi renderizador de Markdown para terminal), hasta "podcli", una pequeña utilidad para exprimir los feeds de podcast desde la consola. Espero que disfrutes de este episodio tanto como yo montando todo este tinglado. ¡A cacharrear! Capítulos del episodio: 00:00:00 Agentes de IA que de verdad nos facilitan la vida 00:01:42 El ejemplo práctico: Automatizar nuestro menú semanal 00:03:51 La fatiga de decisión y por qué la disciplina humana falla 00:05:38 Mi caja de herramientas: 4 MCPs (Model Context Protocol) 00:06:58 Buscando comida con IA: El RAG semántico de 1700 recetas 00:08:45 Búsqueda híbrida y embeddings económicos sin usar GPU local 00:10:00 Simplificando las comidas: El papel de los "Skills" 00:11:58 Organizando la base de datos de manera sencilla con SQLite 00:13:31 Lógica difusa: Evitando duplicados en la lista de la compra 00:15:23 Creando PDFs bonitos con Typst (la alternativa moderna a LaTeX) 00:17:03 Demostración en directo: Generando el menú de la semana 00:19:12 Automatización total: Generación automática de menús con Cron 00:20:19 Revisión del menú, las recetas y la alternativa local con Ollama 00:23:12 De vuelta al "cacharrero" de Linux: Helix, mkdr y Podcli 00:24:51 Próximos episodios: Instalación desde cero a producción de Hermes 00:25:38 Despedida y cierre del episodio Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Si en el episodio anterior te hice una pequeña introducción de lo que es capaz de hacer este agente, hoy quiero bajar al barro contigo y contarte cómo le he dado ojos a nuestro modelo para que pueda explorar internet, documentarse y encontrar la mejor información de forma completamente soberana, libre de anuncios y con el máximo respeto por nuestra privacidad. En este episodio nos vamos a centrar en dos "conectores" brutales que he integrado en su arsenal: uno para realizar búsquedas en la web general y otro para realizar búsquedas avanzadas en YouTube. SearXNG: Tu propio Google privado y sin publicidad La primera pieza de este rompecabezas es SearXNG. Es una herramienta maravillosa que actúa como un buscador de buscadores. En lugar de ser un motor de búsqueda que rastrea la web entera por su cuenta, SearXNG lo que hace es consultar de forma simultánea a los grandes del sector: Google, Bing, Brave, DuckDuckGo y los que tú decidas. Recopila las respuestas de todos ellos, limpia los molestos rastreadores que intentan identificarte, elimina los anuncios y te devuelve una lista limpia de resultados. Invidious: Buscando en YouTube con total soberanía La segunda herramienta que le he dado a Hermes es Invidious, y tiene un propósito muy claro: facilitarle el acceso a la inmensa base de conocimientos que es YouTube. La magia de los subagentes paralelos Lo que me tiene entusiasmado de este sistema es la capacidad de Hermes de combinar ambas herramientas de forma autónoma gracias a los subagentes. Imagina que le pido a Hermes que me recomiende cómo aprender a programar en el lenguaje Rust. En lugar de darme una respuesta estática, Hermes decide de forma inteligente lanzar dos subagentes: uno se va a la web a través de SearXNG a buscar documentación oficial y artículos de referencia, mientras que el otro se va a YouTube a través de Invidious para buscar cursos en vídeo. Ambos asistentes virtuales regresan con sus hallazgos y Hermes hace un cruce de datos espectacular. El poder de los contenedores Docker Para montar todo esto sin complicarme la vida ni ensuciar el sistema operativo de mi equipo principal, he recurrido a mis queridos contenedores Docker. Cada herramienta corre en su propio compartimento aislado. Da igual que SearXNG use unas librerías de Python concretas o que Invidious requiera otras dependencias distintas; al estar encapsulados, nunca entran en conflicto. Si quiero actualizar algo, simplemente descargo la nueva versión del contenedor y listo. En la entrada del blog te dejaré las plantillas de Docker Compose preparadas para que tú también puedas desplegarlas en tu servidor y empezar a cacharrear hoy mismo. CAPÍTULOS DEL EPISODIO: 00:00:00 Presentación: El asistente de IA definitivo y la soberanía digital 00:01:40 ¿Qué es un MCP (Model Context Protocol)? 00:03:26 SearXNG: Tu propio motor de búsqueda privado y sin anuncios 00:05:53 Poniendo a prueba las búsquedas web con Hermes 00:07:32 Cómo está montada la infraestructura de búsqueda con Docker 00:08:48 Automatización real: Creación de documentos con información web 00:09:38 Invidious: YouTube sin publicidad y sin rastreo 00:11:43 Buscando y analizando vídeos de YouTube con Hermes 00:16:20 Superpoderes combinados: Búsqueda web + YouTube 00:20:40 Por qué autoalojar todo en contenedores Docker independientes 00:22:04 Analizando la recomendación razonada de la IA para aprender Rust 00:24:09 Próximo episodio: Planificación de menús y bases de datos vectoriales 00:25:09 Taller presencial en Linux Center de Slimbook (¡ven a cacharrear!) 00:26:00 Despedida y cierre del episodio Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

Hoy te traigo un episodio que se sale completamente de lo habitual y que ha supuesto un auténtico terremoto en mi forma de plantear los contenidos. Todo viene de un cambio de estrategia radical que decidí tomar tras pararme a analizar las estadísticas de los últimos programas. Me di cuenta de un detalle muy tonto pero crucial: te estaba hablando de herramientas increíbles, de los maravillosos conectores MCP y de bases de datos súper avanzadas... ¡pero no te había mostrado al verdadero protagonista de la película! Te estaba hablando de accesorios y complementos sin enseñarte el agente de Inteligencia Artificial que los gobierna a todos. Es como si te diera un manual de bujías sin mostrarte el motor del coche. Así que he decidido pausar el resto de temas técnicos y traerte directamente a Hermes Agent. Y para hacerlo de la manera más honesta y didáctica posible, hoy no te lo voy a contar yo solo: he dejado que mi propio agente de IA local tome el control del micrófono para demostrarte de lo que es capaz en tiempo real, sin nubes y sin cortes. El cerebro que vas a escuchar hablar a lo largo de este podcast se llama Lara. Es el agente que he configurado utilizando como cimiento el proyecto de código abierto Hermes Agent. Para demostrar que este tipo de tecnologías está al alcance de cualquiera y no requiere un hardware inalcanzable, he configurado a Lara para que funcione en un Slimbook One de lo más modesto. No cuenta con tarjeta gráfica (GPU) ni coprocesadores de IA (NPU); corre única y exclusivamente tirando de CPU, de procesador clásico. Para que podamos comunicarnos con ella y escucharla, utilizamos herramientas locales tanto para el reconocimiento de voz (Whisper) como para el paso de texto a voz (TTS). Al no disponer de un hardware de aceleración dedicado, notarás que la voz de Lara suena con ese puntito robótico clásico del software local y que a veces pronuncia de forma un tanto peculiar palabras en inglés como "YouTube" o "skills". Pero te aseguro que, en cuanto la escuchas interactuar un rato y negociar el guion del programa, le coges un cariño increíble. Especialmente porque Lara no tiene esa amabilidad artificial y empalagosa de los asistentes comerciales que te dicen "claro, con gusto te ayudo"; ella tiene su propia personalidad. En este programa vas a poder escuchar de primera mano cómo funciona este sistema a través de siete demostraciones reales y en tiempo real. Aunque preparamos un guion base inicial, las últimas pruebas las hicimos completamente al azar y sin red para ver hasta dónde podíamos exprimir la CPU del Slimbook: Demo 1: Lara realiza una búsqueda en vivo en Internet sobre las últimas tendencias y vídeos de agentes de IA locales Demo 3: Mi demostración favorita. Conectamos una base de datos local con más de 1600 recetas a nuestra lista de la compra inteligente. Demo 4: Accedemos a mi archivo personal de más de 3300 notas de texto y tareas pendientes integradas. Demo 5: Conectamos a Lara con mis datos de Strava del último mes. Demos 6 y 7: El experimento final sin red. Lara resume las noticias de tecnología más destacadas. Capítulos del episodio 00:00:00 Cambio de estrategia: ¿Por qué necesitas un agente? 00:03:36 Presentación de Lara y su cerebro local 00:05:32 Demo 1: Búsqueda y análisis de información en Internet 00:07:53 Demo 2: Multitarea paralela con subagentes 00:09:51 Demo 3: Recetas de cocina y compra inteligente 00:13:58 La importancia de la búsqueda semántica en tus notas 00:14:48 Demo 4: El sistema de notas y tareas conectadas 00:16:51 Demo 5: Controlando mis entrenamientos con Strava 00:19:14 De la teoría al caos: Demos aleatorias sin red 00:20:21 Demo 6: Noticias de tecnología e IA al día 00:22:29 Demo 7: Resumen inteligente de textos extensos 00:26:14 Taller presencial de Valencia: Trasteando con Hermes 00:28:51 Hermes vs OpenClaw: La experiencia real de Daniel Primo 00:29:52 Privacidad y hardware: Modelos ejecutados en CPU local 00:30:26 Cierre del episodio y comunidad Atareao

¡Episodio 800 de Atareao con Linux! Parece que fue ayer cuando empecé a grabar las primeras entregas compartiendo mis andanzas en el mundo de los servidores y el código abierto, y mirad hasta dónde hemos llegado. Muchísimas gracias de todo corazón por acompañarme en este viaje, por cada comentario, por cada descarga y por estar siempre ahí al otro lado del auricular trasteando y cacharreando conmigo. Para conmemorar este número tan redondo, hoy vamos a seguir explorando el apasionante mundo del Model Context Protocol (MCP), esa tecnología que está revolucionando la forma en la que interactuamos con la Inteligencia Artificial de forma local. Si en el episodio anterior nos centramos en una herramienta pasiva para consultar la previsión del tiempo, hoy vamos a dar un paso de gigante hacia la acción. Te voy a explicar en detalle cómo he diseñado e implementado un servidor MCP ToDo que dota a tu IA local de una memoria persistente a largo plazo. Sí, has escuchado bien: ¡vamos a curar de una vez por todas la amnesia de los modelos de lenguaje! Mi propuesta: Un gestor de tareas local programado en Rust Para atajar este problema, me puse manos a la obra y programé un servidor MCP específico para la gestión de tareas utilizando Rust. Poniéndolo a prueba en vivo y en directo Durante el episodio de hoy te cuento exactamente cómo tengo desplegada esta solución en mi servidor doméstico. Optimización de tokens: El arte de no saturar a la IA Un detalle técnico fundamental que abordo en este episodio es el control y optimización del contexto. Capítulos del episodio: 00:00:00 Intro: El hito del episodio 800 y el problema de la memoria en las IA 00:00:32 El consumo de tokens y los límites de la ventana de contexto 00:01:22 Herramientas externas para dotar de memoria a los modelos de lenguaje 00:03:26 Solucionando la "amnesia" de la IA con una base de datos local 00:04:44 Implementación técnica: Un servidor MCP rápido en Rust con Podman y Docker 00:06:14 Cómo configurar la integración del MCP ToDo en OpenWeb UI paso a paso 00:08:29 Demostración en vivo: Listar, añadir y consultar tareas pendientes 00:09:56 El reto del lenguaje natural, el formato de fechas y los logs internos 00:12:05 Gestión avanzada: Marcar tareas completadas y asignar etiquetas 00:14:52 ¿Cómo funciona bajo el capó? Operaciones CRUD y base de datos relacional 00:16:42 Por qué elegí SQLite frente a JSON (búsquedas rápidas con FTS5) 00:18:22 El truco para evitar que tu IA colapse: Paginación y control de tokens 00:20:20 Seguridad de archivos: El rol del MCP como intermediario seguro 00:22:16 El siguiente nivel: De la consulta pasiva de información a la escritura activa 00:23:21 El puente definitivo hacia las bases de datos vectoriales y RAG 00:23:58 Próximo Workshop presencial sobre IA local en Linux Center (Slimbook) 00:24:52 Código abierto en GitHub, infografías de Atareao y avance del próximo episodio 00:25:54 Despedida, comunidad y la red de podcasts de Sospechosos Habituales Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

En el episodio anterior te estuve hablando de tres pilares fundamentales que cambian por completo las reglas del juego cuando queremos ir un paso más allá de los modelos de lenguaje convencionales: el RAG (la memoria), las habilidades y las herramientas. Hoy no nos vamos a quedar en las nubes de la teoría. Hoy nos arremangamos y vamos directos al turrón con un ejemplo totalmente práctico, porque al final lo que queremos es ver cómo se hace, cómo se lleva a cabo en nuestro propio servidor y cómo podemos empezar a sacarle partido a estas tecnologías desde ya. ¿Por qué Rust es el rey del cacharreo con MCPs? Si buscas tutoriales en la red, verás que la inmensa mayoría de servidores MCP se desarrollan en Python. No me malinterpretes, Python es fantástico para escribir código rápido, pero en el mundo de los microservicios autohospedados y los contenedores tiene ciertos inconvenientes difíciles de ignorar. Python tarda más en arrancar y consume una cantidad considerable de memoria RAM por el simple hecho de existir. Por este motivo decidí programar todos mis MCPs utilizando Rust. Rust nos compila un binario nativo, limpio y directo. No hay intérpretes pesados de por medio. La latencia de respuesta es prácticamente cero, el consumo de memoria es insignificante y se ejecuta a una velocidad de vértigo. Además, gracias a editores modernos equipados con IA como OpenCode, una vez que logras pulir y estructurar tu primer MCP en Rust (por ejemplo, el del tiempo), crear el siguiente es sencillísimo. Solo tienes que proporcionarle a tu herramienta de código la estructura de tu primer desarrollo y pedirle que adapte esa misma lógica para conectar cualquier otra API o base de datos que necesites. ¡Es una delicia ver cómo escala el sistema! Bajo el capó: APIs públicas, Docker y Quadlets Para hacer realidad este MCP meteorológico, he combinado el poder de dos APIs públicas muy conocidas: Nominatim (OpenStreetMap): Como las APIs del tiempo necesitan coordenadas geográficas (latitud y longitud), Nominatim se encarga de traducir textos legibles como "Valencia" o "Tokio" en datos numéricos de localización. Open-Meteo: Recibe las coordenadas enviadas por el MCP y devuelve la previsión meteorológica actual, horaria o diaria sin necesidad de usar claves de API complejas ni registros restrictivos. Todo este flujo de datos se empaqueta de forma elegante en un contenedor de Docker y se gestiona mediante un Quadlet de Podman para garantizar que se inicie de forma nativa e integrada con el sistema operativo de nuestro servidor. Y más adelante nos sumergiremos en el fascinante universo del RAG local. Capítulos del episodio: 00:00:00 Introducción y repaso del episodio anterior 00:00:43 El problema de los modelos estáticos de IA 00:01:29 El ejemplo práctico: Preguntando el tiempo 00:03:20 Ahorro extremo de tokens con MCP 00:04:49 Taller de IA agéntica y automatización con Slimbook 00:06:22 Cacharreando con DeepSeek V4 Flash en OpenCode 00:07:33 ¿Qué es y cómo funciona un MCP? 00:09:13 Por qué desarrollo mis MCPs en Rust (y no en Python) 00:11:13 Limpieza de datos y gestión de errores 00:12:40 Cómo conectar un MCP a Open Web UI paso a paso 00:14:18 Probando la previsión meteorológica en vivo 00:15:37 El motor bajo el capó: Open-Meteo, Nominatim y Docker 00:17:25 Codegraph: Analizando código para ahorrar tokens 00:18:22 Próximo episodio: Guardar tareas persistentes con MCP To Do 00:19:48 Otros MCPs listos para el taller de IA 00:21:22 El futuro del podcast: RAG local, notas y más cacharreo 00:22:50 Despedida, enlaces de interés y cierre Más información, enlaces y notas en https://atareao.es/podcast/799🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux✈️ Telegram (el canal) 👉 https://t.me/canal_atareao🦣 Mastodon 👉 https://mastodon.social/@atareao🐦 Twitter 👉 https://twitter.com/atareao🐙 GitHub 👉 https://github.com/atareao

Este episodio nos vamos a meter de lleno en el barro del cacharreo del bueno para hablar de algo que me tiene completamente entusiasmado y sin dormir de la emoción en los últimos días: el maravilloso e increíble mundo del futuro agéntico. Sí, sí, has oído bien. Vamos a desgranar cómo dar el salto definitivo de esos chats de Inteligencia Artificial tan aburridos en los que solo escribes una pregunta y esperas una respuesta, a tener un auténtico colaborador activo que haga tareas reales por ti en tu propia máquina. Seguro que te ha pasado alguna vez. Estás usando un modelo de lenguaje, le pides ayuda para tu proyecto personal o para organizar tus notas de Linux, y de repente te das cuenta de que la IA se ha quedado congelada en el tiempo. Su conocimiento es completamente estático, no tiene ni la más remota idea de tus datos, de tus notas en Markdown, de tus contenedores ni de tus flujos de trabajo. Y lo peor de todo: cuando no sabe algo, en lugar de callarse, ¡se lo inventa con una tranquilidad que asusta! Básicamente, alucina. Las IAs de hoy en día, tal y como nos las venden de fábrica, están completamente aisladas del entorno, del tiempo y de tus propios procesos de trabajo. Son como un trozo de corcho flotando a la deriva en mitad del océano: muy ligeras y con potencial, pero incapaces de hacer nada útil de forma autónoma. ¿Y cuál es la solución para dejar de tener una IA "tonta" y aislada? No se trata de una única tecnología mágica, sino de combinar con cabeza tres piezas fundamentales que le darán superpoderes a tu asistente: el RAG (la memoria), los MCP (las manos) y las Skills (los manuales de instrucciones). Cuando consigues orquestar estas tres piezas en tu propio host local, la magia ocurre. Consigues crear un asistente de verdad, como mi querido Hermes, que es capaz de redactar los textos que necesito para este podcast, gestionar mis recordatorios y organizar mis notas de forma totalmente autónoma mientras yo me lo paso pipa programando. Capítulos del episodio: 00:00:00 ¡Bienvenidos al futuro agéntico! 00:01:21 Lo que se viene en este episodio (y en los próximos) 00:02:42 ¿Por qué las IAs hoy en día son "tontas" e inútiles? 00:04:36 La solución: Skills, RAG y MCP explicados fácil 00:06:14 La analogía del nuevo empleado en tu empresa 00:07:38 El agente de IA como el gran director de orquesta 00:08:21 ¿Qué es el RAG? (Conocimiento en tiempo real sin fine-tuning) 00:11:17 Mi RAG propio en Rust para archivos Markdown 00:12:39 ¿Qué es el MCP? (La revolución de Anthropic) 00:14:55 Cómo usar MCP para conectar tu IA con el mundo real 00:16:14 Mis servidores MCP: SearXNG, Invidious y listas de tareas 00:18:10 Skills: Ahorro de tokens y flujos de trabajo inteligentes 00:20:11 La matriz definitiva: Memoria, Manos y Manuales 00:22:04 De un chat reactivo a un colaborador activo (Mi asistente Hermes) 00:23:54 Próximos pasos, descargas de código y despedida Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao

¿Quieres usar agentes de IA para programar sin arruinarte? En este episodio de atareao con Linux comparo las dos opciones más interesantes para desarrolladores en 2026: OpenCode Go y OpenRouter. Durante las últimas semanas he estado completamente volcado con OpenCode, usándolo tanto para generar código como para revisar código existente. Y en el proceso me he encontrado con una pregunta clave: ¿cómo accedo a los modelos de IA sin arruinarme? La respuesta no es trivial. Tienes dos opciones clásicas: comprar hardware dedicado o pagar servicios en la nube como ChatGPT o Gemini. Pero hay una tercera vía: combinar herramientas open source con servicios de bajo coste. En este episodio te cuento: Qué es OpenCode Go y por qué $10/mes pueden ser suficiente Qué es OpenRouter y cómo usar 400+ modelos (algunos gratis) Comparativa directa de precios, modelos, ventajas y desventajas Cuál elegir según tu caso de uso Caso práctico: cómo mejoré mi herramienta Shul con skills de Rust y React Por qué las skills son el verdadero game-changer de los agentes de IA También te adelanto lo que viene en los próximos episodios: flujo de trabajo completo con skills, RAG, MCPs... la cosa se pone muy caliente. Capítulos: 00:00 — Introducción: el dilema de la IA y el dinero 02:30 — ¿Qué es OpenCode? 04:50 — OpenCode Go: la suscripción de $10/mes 08:20 — OpenRouter: el agregador de 400+ modelos 10:50 — Comparativa directa 13:00 — Caso práctico: mejorando Shul con Skills 16:00 — El poder de las Skills 19:00 — Conclusiones y cuál elegir 22:00 — Próximos episodios Más información y enlaces en las notas del episodio 🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es ✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux ✈️ Telegram (el canal) 👉 https://t.me/canal_atareao 🦣 Mastodon 👉 https://mastodon.social/@atareao 🐦 Twitter 👉 https://twitter.com/atareao 🐙 GitHub 👉 https://github.com/atareao Si te ha gustado, deja una reseña en Spotify y comparte el episodio con alguien que esté interesado en la IA aplicada al desarrollo. ¡Nos escuchamos el próximo jueves!

En el episodio de hoy, el número 796, vengo con muchas ganas de contarte algo que me tiene completamente fascinado. Pero vamos a lo importante: las Skills o habilidades. Si creías que la inteligencia artificial era solo un chat donde escribir preguntas y recibir respuestas, prepárate, porque hoy vamos a ver cómo dotar a nuestros modelos de lenguaje de auténticos "superpoderes" técnicos. ¿Qué son realmente las Skills? Imagina que en lugar de darle instrucciones genéricas a tu modelo (lo que conocemos como prompt), le proporcionas una estructura especializada. Una Skill es una herramienta transversal que le enseña al modelo a comportarse como un experto en una materia concreta. Lo maravilloso es que estas habilidades no dependen de un solo modelo; puedes usarlas con Claude, con OpenCode, con Hermes o con cualquier otro agente. Es una forma de democratizar el conocimiento técnico y hacerlo reutilizable. En este episodio te cuento mi experiencia personal utilizando estas habilidades para tareas que, de normal, nos llevarían bastante tiempo de configuración. Desde crear contenedores Docker optimizados hasta gestionar bases de datos complejas sin escribir una sola línea de SQL. Soberanía Digital y Potencia Local Ya sabes que me encanta el lema de "yo me lo guiso, yo me lo como". Aunque existen servicios externos muy económicos para correr estos modelos, nada supera la sensación de tener el control total. Te hablo de mi configuración actual: un Slimbook con una Nvidia GeForce RTX 4060 Ti de 16 GB de VRAM. Con este hardware estoy corriendo modelos como el Qwen de 35 billones de parámetros con una fluidez espectacular. Aquí es donde la soberanía digital cobra sentido: mis datos, mis reglas y mi hardware. Ejemplos prácticos: Docker y SQLite A lo largo del audio, te guío por dos ejemplos que me han dejado con la boca abierta: Docker Expert. SQLite Expert. La Anatomía de una Skill: Bajo el capó Menciono también el increíble trabajo de Daniel Primo en Web Reactiva, quien ha profundizado muchísimo en este tema de las Skills y cuya guía ha sido una fuente de inspiración fundamental para experimentar con todo esto. Conclusión: El futuro es el lenguaje natural Capítulos: 00:00:00 El troleo a David y la importancia del feedback 00:00:41 Introducción a las Skills: Dale "poderes" a tu IA 00:01:14 Repaso a OpenCode y el paso a la soberanía digital 00:02:11 Mi hardware: Slimbook, Nvidia RTX 4060 Ti y el modelo Qwen 00:02:55 ¿Qué son realmente las Skills y por qué usarlas? 00:04:18 Ejemplo práctico: Instalando una Skill para Docker 00:04:58 Recomendación: La guía de Skills de Daniel Primo 00:06:08 Generando un Dockerfile complejo para Rust en dos etapas 00:07:34 Anatomía de una Skill: Front Matter, YAML y Markdown 00:09:25 Cómo el agente gestiona los tokens y las habilidades 00:10:48 Verificación del Dockerfile generado por la IA 00:12:11 Trabajando con bases de datos: Skill de SQLite Expert 00:13:24 Experiencia real: Revisando código Backend y Frontend 00:15:38 Consultas en lenguaje natural sobre la base de datos 00:17:40 Tipos de Skills: Percepción, Acción y Pensamiento Complejo 00:19:47 Conclusiones: Programar sin programar y modelos locales 00:20:29 Despedida y red de sospechosos habituales Más información, enlaces y notas en https://atareao.es/podcast/796🌐 Aquí lo puedes encontrar todo 👉 https://atareao.es✈️ Telegram (el grupo) 👉 https://t.me/atareao_con_linux✈️ Telegram (el canal) 👉 https://t.me/canal_atareao🦣 Mastodon 👉 https://mastodon.social/@atareao🐦 Twitter 👉 https://twitter.com/atareao🐙 GitHub 👉 https://github.com/atareao