Atareao con Linux

atareao
  • 0.0 (0)
  • Tecnología
  • Dos veces a la semana

Disfruta conmigo de Linux y del Open Source. Aquí encontrarás como sacarle el máximo partido a tu entorno de escritorio Linux, hasta como montar un servidor web, un WordPress, un proxy inverso, una base de datos o cualquier otro servicio que puedas imaginar. Y todo ello, lo puedes montar en una Raspberry Pi, en un VPS, en tu propio ordenador o en cualquier servidor. Vamos, cualquier cosa que quieras hacer con Linux, seguro, seguro, que la encontrarás aquí.

  1. hace 2 días

    ATA 832 Watchbit, el monitor de uptime ultraligero hecho en Rust

    ¿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 web1:54 - Uptime Kuma: características y panel de control4:45 - Ventajas e inconvenientes de Uptime Kuma5:36 - El problema del consumo: CPU, RAM y disco7:05 - Watchbit: OIDC, dashboard y diseño por tarjetas8:43 - Comparativa de consumo: Watchbit vs Uptime Kuma10:53 - Heartbeats y monitores en Watchbit12:37 - Configuración de monitores, notificadores y plantillas14: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

    ATA 832 Watchbit, el monitor de uptime ultraligero hecho en Rust

  2. hace 5 días

    ATA 831 Esto es lo que le faltaba a tu IA para ser útil de verdad

    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 útil2:30 - ¿Qué es MCP? Arquitectura host-cliente-servidor y JSON RPC 2.05:30 - Cinco razones para adoptar MCPs8:00 - MCP Filesystem: leer, buscar y crear archivos11:00 - MCP SQLite: consultar bases de datos y el no-determinismo14:00 - MCP GitHub: issues, pull requests y repositorios17:00 - MCP Web Fetch: búsquedas en internet con ahorro de tokens19:30 - MCP Time: la hora en cualquier huso horario21:30 - MCP Memory: grafo de conocimiento persistente23:30 - MCP Sequential Thinking: razonamiento paso a paso25:30 - Configuración en OpenCode, consumo de tokens y RAM27:30 - Crear tu propio MCP: Python SDK vs Rust28: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

    ATA 831 Esto es lo que le faltaba a tu IA para ser útil de verdad

  3. 10 sep

    ATA 830 Popuplatrs, publica en redes desde tu propio RSS

    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 sociales1:45 - Alternativas existentes y sus limitaciones3:00 - Qué es Popuplatrs: origen, nombre y características principales4:15 - Arquitectura técnica: Rust, Axum, SQLite y Pocket ID5:45 - Fuentes soportadas: RSS, Atom y YouTube7:00 - Publicadores: hasta nueve plataformas sociales8:30 - Panel web: dashboard, logs y republicación de errores10:30 - Programación, reintentos y control anti-spam12:00 - Motor de plantillas y personalización por plataforma13: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

    ATA 830 Popuplatrs, publica en redes desde tu propio RSS

  4. 7 sep

    ATA 829 Skills imprescindibles para tu agente IA

    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

    ATA 829 Skills imprescindibles para tu agente IA

  5. 3 sep

    ATA 828 De Docker a tu Cerebro Digital, el roadmap de IA para Linuxeros

    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 901:47 — Balance T08: de Docker y Selfhosting al boom de la IA04:37 — El momento adecuado para cada tecnología06:46 — El gran objetivo: tu cerebro digital08:44 — Roadmap T09: 30 episodios ya guionizados11:28 — Skills y MCPs imprescindibles12:43 — GraphRAG: de RAG a grafos de conocimiento14:01 — RAG vs GraphRAG: el mapa de tu conocimiento17:28 — Herramientas del ecosistema: alloy, populater, watchbeat20:08 — ¿Para quién es esto? De veteranos a escépticos22:08 — No es hype: es un cambio de paradigma24: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

    ATA 828 De Docker a tu Cerebro Digital, el roadmap de IA para Linuxeros

  6. 31 ago

    ATA 827 No Necesitas una GPU de 3000€ para IA Local

    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 replanteamiento2:30 - Hardware mínimo: 8-16 GB RAM + SSD obligatorio5:00 - Software base: instalar Ollama en tu distribución7:30 - Contenedores: Docker vs Podman para el laboratorio10:00 - Modelos pequeños: Phi 3.5, Qwen 1.5B y cuantización13:00 - Herramientas complementarias: SQLite Vec, Whisper, TTS16:00 - Organización del laboratorio: script y estructura de directorios19:00 - Demo: probando Ollama en local con modelos ligeros22:00 - Combinación local + nube: lo mejor de ambos mundos24: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

    ATA 827 No Necesitas una GPU de 3000€ para IA Local

  7. 27 ago

    ATA 826 Nushell, la shell que entiende tus datos y tu IA

    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 shells2:30 — El problema del texto plano: por qué Nushell es diferente5:00 — La trifecta: ls, where y select, SQL en tu terminal7:30 — Tipos reales: la shell entiende fechas, tamaños y números10:00 — Open: abrir JSON, CSV, YAML y SQLite sin herramientas externas13:00 — Procesamiento avanzado: $in, save, append y par-each15:30 — HTTP GET: APIs de GitHub y meteorología desde la shell18:00 — Comparativa de shells: Bash vs ZSH vs Fish vs Nushell21:00 — Nushell e IA: integración nativa con Ollama sin Python24: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

    ATA 826 Nushell, la shell que entiende tus datos y tu IA

  8. 24 ago

    ATA 825 Qué hay en el motor de un agente de IA

    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 IA2:19 - El viaje de un mensaje: del prompt al modelo de lenguaje3:49 - Arquitectura de agentes: coordinador, subagentes y la TUI en Rust6:11 - El motor como director de orquesta: roles system, user, assistant y tool8:27 - System prompt y optimización: delegación en subagentes especializados11:13 - Streaming y server-sent events: cómo se construye la respuesta token a token14:20 - Razonamiento y tool calls: el modelo predice, no piensa, pero actúa17:59 - El bucle de herramientas: el problema de la delegación infinita en Anacleto20:56 - Skills, subagentes desechables y sistema de permisos25:16 - Demostración práctica de Anacleto: tiempo, chistes y noticias29: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

    ATA 825 Qué hay en el motor de un agente de IA
Ver todo (832)

Acerca de

Disfruta conmigo de Linux y del Open Source. Aquí encontrarás como sacarle el máximo partido a tu entorno de escritorio Linux, hasta como montar un servidor web, un WordPress, un proxy inverso, una base de datos o cualquier otro servicio que puedas imaginar. Y todo ello, lo puedes montar en una Raspberry Pi, en un VPS, en tu propio ordenador o en cualquier servidor. Vamos, cualquier cosa que quieras hacer con Linux, seguro, seguro, que la encontrarás aquí.

Información

  • Creador
    atareao
  • Años de actividad
    2018 - 2026
  • Episodios
    832
  • Clasificación
    Apto
  • Copyright
    © atareao
  • Mostrar sitio web
    Atareao con Linux

También te podría interesar