sábado, 1 de agosto de 2026

Autocompletado con IA local en Neovim: cómo saqué a Ollama del error de la API key

Desde hace un tiempo tengo montado un flujo de trabajo con Neovim para programar en Python, C/C++ y para el desarrollo de firmware en microcontroladores de 8 bits (PIC, AVR) y en plataformas de 32 bits como STM32 y el ESP32 con MicroPython. Quería sumarle autocompletado inteligente, pero sin depender de servicios en la nube: todo corriendo local, en mi propia laptop.

El punto de partida

El hardware con el que trabajo no es una bestia de IA, pero da para lo que necesito:

  • GPU dedicada NVIDIA GTX 1650
  • CPU Intel i5 de 10ma generación
  • 16 GB de RAM
  • Ubuntu 26.04 LTS con drivers NVIDIA al día

Sobre eso tengo Ollama corriendo dos modelos locales: qwen2.5-coder:7b para código y minicpm-v:8b para tareas con visión. Para conectar Ollama con Neovim elegí el plugin minuet-ai.nvim, usando el motor FIM (Fill-In-The-Middle), pensado justo para autocompletar código a mitad de una línea o función, no solo al final del archivo.

El error que no me dejaba avanzar

Al abrir Neovim con un archivo .py me aparecía este mensaje:

"The API key has not been provided as an environment variable..."

Lo curioso es que el autocompletado sí funcionaba, aunque de forma breve e inconsistente — lo cual hacía más confuso el diagnóstico.

La causa resultó ser un detalle fácil de pasar por alto en la configuración del plugin:

provider_options = {
  openai_fim_compatible = {
    api_key = "OLLAMA", -- esto NO es lo que Minuet espera
    ...
  },
},

minuet-ai.nvim no toma ese campo como el valor de la clave, sino como el nombre de una variable de entorno que va a buscar con os.getenv(). Como en mi sistema no existía ninguna variable llamada OLLAMA, el plugin fallaba al intentar leerla — aunque Ollama, de por sí, no valida ninguna clave real.

La solución

  1. Crear una variable de entorno placeholder en ~/.bashrc:
    export OLLAMA_API_KEY="ollama"
  2. Recargar la shell:
    source ~/.bashrc
  3. Apuntar el plugin al nombre de la variable, no a un valor literal:
    provider_options = {
      openai_fim_compatible = {
        api_key = "OLLAMA_API_KEY", -- nombre de la variable de entorno
        name = "Ollama",
        end_point = "http://127.0.0.1:11434/v1/completions",
        model = "qwen2.5-coder:7b",
        optional = {
          max_tokens = 128,
          top_p = 0.9,
        },
      },
    },
  4. Abrir Neovim desde una terminal que haya cargado esa variable. Si Neovim se lanza desde un acceso directo gráfico o una shell distinta, nunca va a heredar la variable y el error va a reaparecer. Confirmar con:
    echo $OLLAMA_API_KEY

Sobre el tamaño del modelo y el hardware

Un detalle que vale la pena tener presente: una GTX 1650 típicamente trae 4 GB de VRAM, y qwen2.5-coder:7b en su versión cuantizada ya pesa 4.7 GB solo en los pesos del modelo. Es muy probable que Ollama esté descargando parte del procesamiento a la CPU, lo que explicaría respuestas lentas o cortadas.

Para autocompletado tipo FIM —que necesita ser rápido más que profundo— probablemente convenga bajar a una versión más ligera:

ollama pull qwen2.5-coder:1.5b-base
# o
ollama pull qwen2.5-coder:3b-base

La pérdida de calidad para completar líneas en Python o C/C++ es mínima, pero la latencia baja notablemente, que es justo lo que uno busca cuando el autocompletado tiene que aparecer mientras se sigue escribiendo.

Configuración final

return {
  "milanglacier/minuet-ai.nvim",
  dependencies = {
    "nvim-lua/plenary.nvim",
  },
  config = function()
    require("minuet").setup({
      provider = "openai_fim_compatible",
      n_completions = 1,
      context_window = 1024,
      provider_options = {
        openai_fim_compatible = {
          api_key = "OLLAMA_API_KEY",
          name = "Ollama",
          end_point = "http://127.0.0.1:11434/v1/completions",
          model = "qwen2.5-coder:7b",
          optional = {
            max_tokens = 128,
            top_p = 0.9,
            stop = { "\n\n" },
          },
        },
      },
      virtualtext = {
        auto_trigger_ft = { "c", "cpp", "python", "lua" },
        keymap = {
          accept = "<A-y>",
          accept_line = "<A-l>",
          prev = "<A-[>",
          next = "<A-]>",
          dismiss = "<A-e>",
        },
      },
    })
  end,
}

Cierre

Al final, el problema no era de Ollama ni de la GPU, sino de una confusión de conceptos en la configuración del plugin: nombre de variable de entorno vs. valor de la clave. Con esto resuelto, el flujo de autocompletado local en Neovim queda funcionando para el trabajo diario en Python, C/C++ y embebidos — sin mandar una sola línea de código a la nube.

Próximo paso: confirmar que Ollama esté usando realmente la GPU (nvidia-smi mientras genera completions) y afinar el tamaño de modelo según la latencia real que se sienta al escribir.

sábado, 14 de febrero de 2026

Error 404 en APT cuando se instalan paquetes en Debian 12

Cómo solucionar error 404 en APT al instalar paquetes en Debian 12 (Bookworm)

Al intentar instalar o actualizar paquetes en Debian 12 (Bookworm), puede aparecer un error como el siguiente:

E: Fallo al obtener http://deb.debian.org/debian/...
404 Not Found
E: Internal Error, ordering was unable to handle the media swap

Este error suele presentarse al intentar instalar paquetes como LibreOffice y generalmente indica que el sistema está intentando descargar versiones que ya no existen en el repositorio.


¿Por qué ocurre este error?

En Debian 12, este problema ocurre comúnmente cuando:

  • La lista de paquetes (apt) está desactualizada.
  • El mirror cambió de versión (por ejemplo de deb12u9 a deb12u10).
  • Hay paquetes a medio instalar.
  • El sistema quedó en un estado inconsistente tras una actualización incompleta.

El mensaje 404 Not Found significa que la versión que el sistema intenta descargar ya no está disponible en el servidor.


Solución paso a paso

1. Limpiar la caché de paquetes

sudo apt clean

2. Eliminar listas antiguas

sudo rm -rf /var/lib/apt/lists/*

3. Actualizar listas nuevamente

sudo apt update

Si en este punto ya no aparecen errores 404, puedes continuar.

4. Reparar paquetes rotos

sudo apt --fix-broken install

5. Reconfigurar paquetes pendientes

sudo dpkg --configure -a

6. Actualizar el sistema completamente

sudo apt full-upgrade

Verificar archivo de repositorios

Si el error continúa, revisa tu archivo:

sudo nano /etc/apt/sources.list

Para Debian 12 Bookworm debería verse algo similar a:


deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware

Guarda los cambios y ejecuta nuevamente:

sudo apt update

Sobre el error: “ordering was unable to handle the media swap”

Este mensaje aparece cuando apt quedó en un estado inconsistente, normalmente después de una instalación interrumpida.

Se corrige en la mayoría de los casos con:

sudo dpkg --configure -a
sudo apt install -f

Resumen rápido

sudo apt clean
sudo rm -rf /var/lib/apt/lists/*
sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt full-upgrade

Conclusión

Este tipo de error no indica que Debian esté dañado, sino que el sistema de paquetes quedó desincronizado con el repositorio oficial.

La solución consiste en:

  • Limpiar caché
  • Actualizar listas
  • Reparar paquetes pendientes
  • Sincronizar completamente el sistema

Este procedimiento es especialmente útil en entornos educativos, servidores locales o Raspberry Pi utilizadas para automatización académica y desarrollo.


Publicado como parte de mi bitácora técnica sobre administración de sistemas Linux y automatización educativa.

sábado, 6 de diciembre de 2025

Octave Raspberry Pi y Bash [ Actualización]

Ya casi termina el año y no he escrito nada :-) 

La intención de esto es mostrar que se puede implementar un sistema de lógica difusa en una Raspberry Pi 1 B+ (en 2025) que haga uso de Octave, pero que sea invocada desde la consola.

Actualización:

Ya se encuentra disponible el nuevo vídeo donde ahora el valor PWM lo interpreta el microcontrolador PIC16F876A mostrando la salida por RC2 (CCP1) con un ajuste a 5kHz y el ciclo de trabajo definido por el RPi a través del sistema difuso implementado en Octave

 Adjunto algunos de los vídeos donde muestro esto:

 Parte 1


 

 

Parte 2 




 Parte 3

Parte 4


 

Parte 5

 
Parte final

 

 

jueves, 2 de enero de 2025

MariaDB en Raspberry Pi desde Heidi SQL en windows Conexion local

 Bueno, es prácticamente dos de enero y quise escribir lo siguiente:

Me puse a probar trabajar con el servidor MariaDB en una raspberry Pi 2B+ (Si, ya es viejita para estas fechas) y quiero verificar la conexión desde un entorno gráfico de Windows 11, en mi red local. para ello descargue HeidiSQL (MySQL Workbench no soporta la versión de MariaDB que está en mi Raspberry), y bueno, las pantallas de configuración quedaron de la siguiente manera:

 

Nótese que, la dirección IP de la Raspberry tiene terminación .local y esto es porque tiene además un servidor Avahi que me permite ubicarla dentro de mi red local, sin tener que buscar su dirección IP, además de que hay que configurar un archivo dentro de /etc/mysql/mariadb.conf.d/ el cual se llamará 90-local.cnf, donde se colocará la dirección 0.0.0.0 para que el servidor acceda desde cualquier lado (esto no es seguro y solo es para pruebas) si colocas dentro de este archivo algo como 192.168.0.0/24 para que solo acepte direcciones de tu red local, no funciona, debes dejarlo con 0.0.0.0 y luego con iptables restringir el acceso a una dirección ip particular o un rango dado.

 

Hecho esto, reinicia el servidor MariaDB con:


 y pues, ya te conectas, y comienzas a trabajar con tu base de datos:

 

Bueno, luego de algún tiempo sin escribir nada, dejo esto por aquí, espero que a alguien le sirva de mucho.