Gemma 4 de Google: análisis real de los mejores modelos de IA local en 2026 — velocidad, calidad y recomendaciones

Los benchmarks publicados por los fabricantes de modelos de IA suelen mostrar sus versiones más grandes corriendo en hardware de servidor. Pero, ¿qué pasa cuando los pruebas en tu propio equipo, con una GPU de consumo y condiciones reales de uso?

Esto es exactamente lo que hice: tomé ocho de los modelos más relevantes disponibles hoy en Ollama, los corrí en el mismo hardware, con las mismas preguntas, y medí no solo la velocidad de generación sino también el retraso por pensamiento, el consumo de VRAM, el overflow a RAM y el uso de CPU. Los resultados me obligaron a revisar mis opiniones más de una vez — este artículo refleja la tercera y definitiva ronda de evaluación.

El foco especial está en Gemma 4 de Google DeepMind, un modelo que en las comparativas publicadas aparece por debajo de otros competidores, pero que en mis pruebas reales demostró ser consistentemente el mejor para uso cotidiano en hardware de 12 GB.


Hardware usado para las pruebas

  • CPU: AMD Ryzen 7 5700G (8 núcleos, arquitectura Zen 3)
  • RAM: 32 GB DDR4 a 3200 MHz
  • GPU: Gigabyte GeForce RTX 3060 12 GB GDDR6
  • Almacenamiento de modelos: HDD 1.8 TB
  • Sistema operativo: Debian 12 Bookworm
  • Motor de inferencia: Ollama en Docker con CUDA

La RTX 3060 de 12 GB representa el punto de entrada más sensato para IA local en 2026: suficiente VRAM para correr modelos de 14B parámetros completamente en GPU, con una relación precio/rendimiento difícil de superar en el mercado de segunda mano.


Una métrica que nadie menciona: el retraso por pensamiento

Antes de entrar en los datos, hay una métrica que define la experiencia de uso más que cualquier otra y que rara vez aparece en las comparativas: el retraso por pensamiento.

Los modelos modernos con capacidad de razonamiento generan un proceso interno de análisis antes de producir la respuesta visible. Durante ese tiempo, el usuario ve una pantalla en blanco o un indicador de carga. Dependiendo del modelo y la complejidad de la pregunta, ese retraso puede ir de segundos a más de un minuto.

En la práctica, un modelo que genera a 45 tokens por segundo pero tarda 60 segundos en empezar puede sentirse más lento que uno que genera a 30 t/s con 6 segundos de retraso. Evaluar modelos únicamente por velocidad de generación es engañoso.


Tabla comparativa completa

ModeloVelocidad (t/s)VRAM usadaOverflow RAMCPUArranque fríoRetraso thinking
gemma4:e4b73.06~10 GB0 GB~0%~90 seg~6 seg
qwen3.5:9b45.228.8 GB0 GB~0%~60 seghasta 60 seg
qwen3.5:9b (/nothink)45.228.8 GB0 GB~0%~60 seg~10 seg
phi4-reasoning:14b21.28~12 GB~2 GB~3%~90 seg~120 seg
mistral-nemo:12b46.127.7 GB0 GB~0%~30 seg0 seg
deepseek-r1:14b33.54~10 GB0 GB~0%~60 seg~20 seg
qwen3:14b32.5810 GB0 GB~0%~20 seg~13 seg
mistral-small3.2:24b6.58~12 GB~5 GB31%~170 seg0 seg
gemma4:26b1812 GB8 GB41%~240 seg~50 seg

Ranking final por calidad de respuesta

  1. 🥇 gemma4:e4b — Mejor calidad general, más rápido, multimodal
  2. 🥈 qwen3.5:9b — Buen contenido, excelente formato, thinking lento
  3. 🥉 phi4-reasoning:14b — Contenido similar a Qwen3.5, formato menos pulido
  4. 4️⃣ mistral-nemo:12b — Sólido, rápido, sin esperas
  5. 5️⃣ deepseek-r1:14b — Razonamiento profundo y visible
  6. 6️⃣ qwen3:14b — Competente pero superado por la nueva generación
  7. 7️⃣ mistral-small3.2:24b — No escala bien en 12 GB de VRAM
  8. 8️⃣ gemma4:26b — Descartado en este hardware

Análisis detallado por modelo

1. Gemma 4 E4B — El mejor modelo para hardware de 12 GB

Gemma 4 es la familia de modelos open source más reciente de Google DeepMind, lanzada en abril de 2026. La variante E4B es el punto dulce de la familia para GPUs de 12 GB: cabe completamente en VRAM, no toca la RAM del sistema y no genera carga en el CPU.

¿Qué tiene de especial Gemma 4?

  • Multimodal nativo: procesa texto, imágenes y audio en el mismo modelo, sin herramientas adicionales
  • Thinking mode con mínimo retraso: solo 6 segundos antes de la primera respuesta — el más bajo del grupo
  • 128K tokens de contexto: suficiente para proyectos de código extensos o documentos largos
  • Arquitectura MoE eficiente: 4.5B parámetros efectivos en un paquete de 9.6 GB

Datos reales medidos

  • Velocidad: 73.06 tokens por segundo
  • VRAM: ~10 GB, sin overflow
  • CPU: ~0% durante generación
  • Arranque en frío: ~90 segundos
  • Retraso por thinking: ~6 segundos

A 73 tokens por segundo, el modelo genera texto mucho más rápido de lo que puedes leerlo. Es la experiencia de uso más fluida que he tenido con un modelo local en hardware de consumo.

En las comparativas publicadas, Gemma4 aparece un poco por debajo de modelos como Qwen3.5 en los rankings generales. Sin embargo, en mis pruebas reales la calidad percibida de las respuestas supera a todos los demás del grupo. Hay una brecha clara entre los benchmarks de laboratorio con versiones cloud y la experiencia de uso real con versiones locales en hardware de consumo.

La capacidad multimodal añade una dimensión completamente nueva: pasar una captura de pantalla de un error, un diagrama de arquitectura o un documento y recibir análisis inmediato es algo que ningún otro modelo de esta comparativa ofrece de forma tan integrada.

Veredicto: primer lugar en calidad de respuesta y primer lugar en velocidad. La mejor opción para hardware de 12 GB sin discusión.


2. Qwen 3.5 9B — Buen formato, contenido sobrevalorado por los benchmarks

Qwen3.5 es la familia más reciente de Alibaba. En las comparativas de su versión cloud (Qwen3.5-Plus) aparece al nivel de GPT-5.2 o Claude Opus 4.5. La versión local de 9B es una historia diferente.

Las respuestas tienen muy buen formato y presentación: estructura clara, uso apropiado de listas y encabezados, organización visual cuidada. Sin embargo, el contenido en sí no está a la altura de lo que sugieren los benchmarks de sus versiones cloud. La apariencia de calidad que da el formato puede crear una primera impresión mejor de la que merece el fondo de las respuestas.

El thinking mode introduce el mayor retraso del grupo: hasta 60 segundos antes de la primera respuesta en preguntas complejas. Desactivarlo con /nothink reduce ese tiempo a unos 10 segundos, haciendo el modelo mucho más usable en el día a día, aunque sacrificando parte de su capacidad de razonamiento.

Veredicto: segundo lugar en calidad. Mejor con /nothink para uso cotidiano. Los benchmarks de su versión cloud no reflejan el rendimiento real de la versión local de 9B.


3. Phi4 Reasoning 14B — Potencial sin pulir

Phi4-reasoning es el modelo de razonamiento de Microsoft, parte de la familia Phi4. Con 14B parámetros genera a 21.28 t/s con un ligero overflow de 2 GB a RAM y apenas 3% de uso de CPU.

La calidad del contenido es comparable a Qwen3.5:9b — buen nivel de análisis técnico y respuestas bien razonadas. La diferencia está en el formato: donde Qwen3.5 presenta respuestas visualmente organizadas, Phi4-reasoning tiende a entregar el mismo nivel de contenido de forma más cruda, sin la estructuración visual que facilita la lectura.

Es un modelo prometedor que probablemente mejore con versiones futuras. Para quien prioriza el contenido sobre la presentación, es una alternativa válida en el rango de 14B.

Veredicto: tercer lugar en calidad. Mismo nivel de contenido que Qwen3.5:9b, presentación menos cuidada.


4. Mistral Nemo 12B — El equilibrado que nadie menciona

Mistral Nemo es un modelo que suele quedar fuera de los titulares pero que en las pruebas resulta ser una opción muy práctica. Con solo 7.7 GB de VRAM cabe en GPUs de 8 GB, genera a 46.12 t/s sin ningún retraso por thinking y sin overflow a RAM.

Su valor principal es la consistencia: el arranque más rápido del grupo (~30 segundos), respuesta inmediata sin pausa de pensamiento y compatibilidad con hardware más modesto. La calidad de sus respuestas es competente aunque no destaca especialmente frente a los primeros tres modelos del ranking.

Veredicto: cuarto lugar. La mejor opción para GPUs de 8 GB y para quien necesita respuesta inmediata sin ninguna configuración adicional.


5. DeepSeek R1 14B — El especialista en razonamiento visible

DeepSeek R1 está diseñado específicamente para razonamiento profundo y transparente. Su proceso de pensamiento es visible paso a paso, lo que permite entender no solo la respuesta sino el camino para llegar a ella. Esto tiene valor real en debugging complejo, análisis de sistemas o decisiones arquitectónicas donde el proceso importa tanto como el resultado.

A 33.54 t/s sin overflow a RAM, el rendimiento es sólido. El retraso de ~20 segundos por thinking es aceptable dado el nivel de análisis que produce. Quinto lugar en calidad de respuesta del grupo.

Veredicto: quinto lugar en calidad general. Recomendado cuando el razonamiento visible y trazable es un requisito.


6. Qwen3 14B — Superado por la nueva generación

Qwen3:14b fue durante meses una referencia sólida para tareas de código y arquitectura. A 32.58 t/s sin overflow, sigue siendo competente, y el modo /think activa razonamiento paso a paso cuando se necesita.

El problema es que modelos más nuevos y en algunos casos más pequeños lo superan en calidad. Qwen3.5:9b entrega mejor resultado siendo más pequeño. Phi4-reasoning ofrece análisis comparable con reasoning más explicado. Qwen3:14b ya no es la primera opción en ninguna categoría de esta comparativa.

Veredicto: sexto lugar. Todavía funcional pero sin ventaja frente al resto del grupo.


7. Mistral Small 3.2 24B — No escala bien en 12 GB de VRAM

Mistral Small 3.2 tiene buenas credenciales: 24B parámetros, arquitectura MoE, sin retraso por thinking. En hardware con 24 GB de VRAM probablemente brillaría. En una GPU de 12 GB los números son difíciles de defender.

6.58 t/s de generación, 5 GB de overflow a RAM, 31% de CPU constante y casi 3 minutos de arranque en frío. Para obtener una respuesta comparable a la de los modelos del top 3, el tiempo de espera total es varias veces mayor. La ausencia de retraso por thinking no compensa la lentitud general del modelo en este hardware.

Veredicto: séptimo lugar. Necesita 24 GB de VRAM para ser competitivo. No recomendado en 12 GB.


8. Gemma4 26B — La versión grande que decepciona en este hardware

Con 8 GB de overflow a RAM, 41% de CPU constante, 4 minutos de arranque y ~50 segundos de retraso por thinking, el Gemma4:26b ofrece la peor experiencia de uso del grupo en este hardware. Su versión pequeña, el E4B, es superior en todos los aspectos prácticos cuando la VRAM disponible es de 12 GB.

La mejora de calidad frente al E4B no justifica en ningún caso la penalización de rendimiento. Para este modelo se necesita idealmente una GPU de 24 GB donde pueda correr completamente en VRAM.

Veredicto: último lugar. Usar gemma4:e4b en su lugar para este nivel de hardware.


¿Cuándo usar cada modelo?

Para el día a día y consultas cotidianas: gemma4:e4b. Velocidad, calidad y soporte multimodal. Sin competencia en este hardware.

Para análisis de imágenes, diagramas o documentos: gemma4:e4b. Es el único modelo del grupo con soporte multimodal real integrado.

Para análisis técnico con buen formato: qwen3.5:9b con /nothink. Respuestas bien estructuradas visualmente para documentación o explicaciones.

Para razonamiento trazable paso a paso: deepseek-r1:14b. Cuando el proceso importa tanto como la respuesta.

Para GPUs de 8 GB o menos: mistral-nemo:12b. Cabe cómodo, responde sin esperas y no requiere configuración.

Para autocomplete en el editor: deepcoder:1.5b o phi4-mini:3.8b. Modelos ultraligeros que se quedan cargados en background sin impactar el rendimiento de los modelos principales.


El stack que uso actualmente

  • gemma4:e4b — modelo principal para todo el trabajo cotidiano y análisis de imágenes
  • qwen3.5:9b — para cuando necesito respuestas bien formateadas o análisis con thinking activado
  • deepseek-r1:14b — para debugging complejo y razonamiento técnico profundo
  • mistral-nemo:12b — para consultas rápidas sin ninguna espera
  • deepcoder:1.5b — autocomplete permanente en VS Code y Visual Studio

Lo que viene en esta serie

Este análisis de modelos es el segundo artículo de una serie sobre IA local. Los próximos temas que planeo cubrir:

  • Integración con clientes de codificación: Claude Code, Codex y OpenCode — cómo conectarlos a tu servidor Ollama local y qué diferencias hay entre ellos para el trabajo diario de desarrollo
  • Compatibilidad con GitHub Copilot: ¿es posible usar tus modelos locales como backend de Copilot?
  • Implementación de un sistema RAG: cómo conectar tu propia base de documentos a los modelos para obtener respuestas basadas en tu conocimiento privado, sin que nada salga de tu red

Si quieres recibir notificación cuando salgan esos artículos, suscríbete al blog.


Conclusiones

Tres lecciones que me llevé de estas pruebas después de tres rondas de evaluación:

1. Los benchmarks de laboratorio no predicen la experiencia real en hardware de consumo. Gemma4 aparece por debajo de Qwen3.5 en muchas comparativas publicadas. En hardware real, Gemma4:e4b gana en calidad percibida, velocidad y experiencia de uso. La versión cloud de un modelo y su versión local de 9B son productos muy distintos.

2. El retraso por thinking puede arruinar un modelo perfectamente capaz. Qwen3.5:9b tiene buenas respuestas pero su retraso de hasta 60 segundos por thinking lo hace frustrante para uso cotidiano. Desactivarlo con /nothink es la solución práctica, aunque implica sacrificar parte de su capacidad de razonamiento.

3. Con una RTX 3060 de 12 GB ya se puede hacer trabajo serio con IA local. Gemma4:e4b a 73 t/s con soporte multimodal, completamente en local, sin suscripciones y sin que tus datos salgan de tu red. Eso habría parecido imposible hace dos años en hardware de consumo.

¿Has probado alguno de estos modelos? ¿Tu experiencia coincide con la mía o llegaste a conclusiones diferentes? Los comentarios están abiertos.

Cómo montar tu propio servidor de IA local con Ollama y Open WebUI en Linux — Guía completa 2026

¿Cansado de los límites de uso, las suscripciones mensuales y la preocupación de que tus conversaciones con una IA sean almacenadas en servidores de terceros? Existe una alternativa real: montar tu propio servidor de inteligencia artificial en casa, con hardware que probablemente ya tienes o puedes conseguir por una fracción del costo de una suscripción anual.

En este artículo te explico exactamente cómo lo hice, qué hardware usé, qué software necesitas y cómo dejarlo funcionando desde cualquier dispositivo de tu red local.


¿Por qué correr una IA localmente?

Antes de entrar al tutorial, vale la pena entender por qué tiene sentido hacer esto:

  • Privacidad total: tus conversaciones, tu código y tus documentos nunca salen de tu red. Nadie los lee, nadie los usa para entrenar modelos.
  • Sin costo por uso: una vez que tienes el hardware, el costo marginal de cada consulta es prácticamente cero (electricidad).
  • Sin límites de mensajes: no hay “has alcanzado tu límite diario” ni planes de pago por niveles.
  • Funciona offline: no dependes de internet ni de la disponibilidad de servidores externos.
  • Control total: tú decides qué modelos corres, con qué configuración y quién tiene acceso.

¿Qué es Ollama y qué es Open WebUI?

Ollama es una herramienta open source que permite descargar, gestionar y servir modelos de lenguaje grandes (LLMs) localmente. Funciona como un servidor con API REST, lo que significa que cualquier aplicación en tu red puede hacer consultas a tus modelos como si fuera una API de OpenAI.

Open WebUI es una interfaz web tipo ChatGPT que se conecta a Ollama. Te da una experiencia visual amigable desde cualquier navegador, sin necesidad de usar la terminal para interactuar con los modelos.

Juntos forman un stack completo: Ollama gestiona los modelos y la inferencia, Open WebUI le da la interfaz. Docker se encarga de que todo corra de forma aislada y reproducible.


Requerimientos de hardware

La clave para un servidor de IA funcional es la GPU. Los modelos de lenguaje corren dramáticamente más rápido en GPU que en CPU — hablamos de una diferencia de 10x a 15x en velocidad de generación.

Hardware mínimo recomendado

  • CPU: procesador x86-64 de 6 o más núcleos (AMD Ryzen o Intel Core de generación reciente)
  • RAM: 16 GB DDR4 mínimo, 32 GB recomendado. La RAM del sistema sirve como desbordamiento cuando los modelos no caben completamente en la VRAM de la GPU
  • GPU: NVIDIA con mínimo 8 GB de VRAM. La RTX 3060 de 12 GB es el punto dulce en relación precio/rendimiento para modelos locales
  • Almacenamiento: SSD de 256 GB para el sistema operativo y Docker. Un disco adicional (HDD o SSD) de al menos 500 GB para almacenar los modelos, ya que cada uno pesa entre 4 y 20 GB
  • Sistema operativo: Debian 12 (Bookworm) o Ubuntu 22.04/24.04 LTS

Hardware real usado en este tutorial

El servidor que uso como base para esta guía tiene las siguientes especificaciones:

  • Placa madre: MSI MPG B550 Gaming Plus
  • CPU: AMD Ryzen 7 5700G (8 núcleos)
  • RAM: 32 GB DDR4 a 3200 MHz
  • GPU: Gigabyte GeForce RTX 3060 12 GB
  • SSD: 256 GB M.2 NVMe PCIe 4.0 (sistema y Docker)
  • HDD: 1.8 TB (almacenamiento de modelos)
  • Sistema operativo: Debian 12 Bookworm

Con este hardware, modelos de 14B parámetros corren completamente en GPU a 25-35 tokens por segundo, y modelos más pequeños como Gemma4:e4b alcanzan 73 tokens por segundo, más rápido de lo que puedes leer.

Nota sobre GPU: aunque este tutorial usa una RTX 3060 de NVIDIA (que funciona con CUDA, el estándar de la industria), también es posible usar GPUs AMD con ROCm, aunque requiere configuración adicional. Si tu presupuesto es limitado, busca una RTX 3060 de 12 GB de segunda mano — es específicamente la versión de 12 GB, no la Ti que tiene 8 GB.


Software necesario

Antes de empezar, estos son los componentes de software que vamos a instalar:

  1. Docker + Docker Compose: para ejecutar Ollama y Open WebUI como contenedores
  2. Drivers NVIDIA: para que Linux reconozca y use la GPU
  3. NVIDIA Container Toolkit: para que Docker pueda acceder a la GPU
  4. Ollama (imagen Docker): el servidor de modelos
  5. Open WebUI (imagen Docker): la interfaz web

Instalación paso a paso

Paso 1: Instalar Docker en Debian

Primero agrega los repositorios oficiales de Docker para Debian:

# Instalar dependencias
apt update && apt install -y ca-certificates curl gnupg

# Agregar la clave GPG de Docker
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg

# Agregar el repositorio de Docker para Debian
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  tee /etc/apt/sources.list.d/docker.list > /dev/null

# Instalar Docker
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Verifica que Docker quedó instalado correctamente:

docker --version

Paso 2: Instalar drivers NVIDIA

Primero hay que agregar los repositorios non-free de Debian. Edita el archivo de fuentes:

nano /etc/apt/sources.list

Asegúrate de que cada línea incluya contrib non-free non-free-firmware:

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

Luego instala el driver:

apt update
apt install -y nvidia-driver firmware-misc-nonfree

# Deshabilitar el driver genérico nouveau
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist-nouveau.conf
echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist-nouveau.conf
update-initramfs -u

reboot

Después del reinicio, verifica que el driver funciona:

nvidia-smi

Deberías ver tu GPU listada con el uso de VRAM y la versión del driver.

Paso 3: Instalar NVIDIA Container Toolkit

Este paquete permite que los contenedores Docker accedan a la GPU:

# Agregar el repositorio de NVIDIA
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

apt update
apt install -y nvidia-container-toolkit

# Configurar Docker para usar NVIDIA
nvidia-ctk runtime configure --runtime=docker
systemctl restart docker

Paso 4: Crear el docker-compose.yml

Crea un directorio de trabajo y el archivo de configuración:

mkdir -p ~/ollama
cd ~/ollama
nano docker-compose.yml

Pega el siguiente contenido:

services:
  ollama:
    image: ollama/ollama
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - /ruta/a/tu/disco/ollama:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0
      - OLLAMA_NUM_THREADS=8
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - /opt/open-webui:/app/backend/data
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama

Importante: en la línea de volumen de Ollama, sustituye /ruta/a/tu/disco/ollama por la ruta real donde quieres almacenar los modelos. Si tienes un disco secundario montado (recomendado), apunta ahí. Los modelos pueden ocupar desde 4 GB hasta 20 GB cada uno.

Paso 5: Levantar los servicios

cd ~/ollama
docker compose up -d

Verifica que ambos contenedores están corriendo:

docker ps

Deberías ver ollama y open-webui en estado Up.

Paso 6: Verificar que Ollama usa la GPU

# Verificar que el contenedor ve la GPU
docker exec -it ollama nvidia-smi

Si ves tu GPU listada, todo está funcionando correctamente.

Paso 7: Descargar tu primer modelo

# Descargar Gemma4:e4b (recomendado para empezar)
docker exec -it ollama ollama pull gemma4:e4b

# Verificar que se descargó
docker exec -it ollama ollama list

Paso 8: Acceder a Open WebUI

Desde cualquier dispositivo en tu red local, abre el navegador y ve a:

http://IP_DE_TU_SERVIDOR:8080

La primera vez te pedirá crear una cuenta de administrador. Es local, no sale a internet. Una vez dentro, selecciona el modelo que descargaste y empieza a chatear.


Modelos recomendados para empezar

Con una GPU de 12 GB de VRAM, estos son los modelos que mejor funcionan:

Para uso general y velocidad máxima

docker exec -it ollama ollama pull gemma4:e4b

El modelo estrella para hardware como el nuestro. Cabe completamente en los 12 GB de VRAM, genera a 73 tokens por segundo (más rápido de lo que puedes leer), soporta imágenes y audio, y tiene thinking mode. Es el punto de partida ideal.

Para razonamiento y código

docker exec -it ollama ollama pull qwen3:14b

Excelente para tareas que requieren más razonamiento: analizar arquitecturas de software, revisar código, resolver problemas complejos. Genera a unos 30 tokens por segundo con buena calidad de respuesta.

Para máxima calidad de respuesta

docker exec -it ollama ollama pull mistral-small3.2:24b

Este modelo de 24B parámetros usa arquitectura MoE (Mixture of Experts), lo que le permite ofrecer la calidad de un modelo grande con un consumo razonable. Ocupa algo más de VRAM y desborda un poco a RAM del sistema, pero la calidad de sus respuestas es notablemente superior para análisis complejos.

Para autocomplete en el editor de código

docker exec -it ollama ollama pull deepcoder:1.5b

Un modelo ultraligero especializado en código. Solo ocupa 2 GB de VRAM y se puede dejar cargado en background para autocomplete en tiempo real desde VS Code o Visual Studio.


Verificar que todo funciona

Para confirmar que un modelo está corriendo en GPU y no en CPU:

docker exec -it ollama ollama ps

En la columna PROCESSOR deberías ver 100% GPU. Si ves CPU, revisa que el NVIDIA Container Toolkit esté instalado y que el docker-compose tenga la sección de GPU correctamente.

También puedes monitorear el uso de GPU en tiempo real mientras el modelo genera:

watch -n 1 nvidia-smi

Acceder desde otros dispositivos de la red

Una vez que el servidor está funcionando, cualquier dispositivo en tu red WiFi o LAN puede usar la IA:

  • Desde el navegador: http://IP_DEL_SERVIDOR:8080 para la interfaz web
  • Desde VS Code: instala la extensión Continue.dev y apunta el modelo a http://IP_DEL_SERVIDOR:11434
  • Desde Visual Studio: instala EntwineLLM y configura la misma URL
  • Desde Claude Code: configura las variables de entorno para apuntar a tu servidor local

Conclusión

Montar un servidor de IA local no es tan complicado como parece, y los beneficios son inmediatos: privacidad total, sin límites de uso y sin costo recurrente. Con una GPU de 12 GB de VRAM como la RTX 3060, puedes correr modelos que compiten de tú a tú con herramientas de pago para tareas cotidianas de desarrollo.

En la próxima publicación de esta serie hago un análisis detallado de los diferentes modelos que probé en este mismo servidor, incluyendo datos reales de velocidad, consumo de VRAM y calidad de respuesta para cada uno.

¿Tienes preguntas sobre algún paso de la instalación o quieres saber si tu hardware es compatible? Déjame un comentario abajo.

SQL Server: Comandos de Administración más utilizados (Permisos, Seguridad y Monitoreo)

Si trabajas con SQL Server en entornos productivos, dominar la administración de permisos y el monitoreo es clave para mantener la seguridad, estabilidad y rendimiento del sistema.

En este artículo encontrarás desde comandos básicos hasta ejemplos más avanzados utilizados en escenarios reales.


🔐 Gestión de permisos (Nivel básico)

Dar permiso CONNECT en la base de datos

USE NombreBaseDatos;
GO
GRANT CONNECT TO NombreUsuario;

Permitir ver los Stored Procedures

GRANT VIEW DEFINITION ON DATABASE::TuBaseDeDatos TO TuUsuario;

Permitir ver el código de los SPs

GRANT VIEW DEFINITION TO TuUsuario;

Dar permiso EXECUTE sobre el esquema dbo o base de datos

GRANT EXECUTE ON SCHEMA::dbo TO NombreUsuario;
GRANT EXECUTE ON DATABASE::TuBaseDeDatos TO NombreUsuario;

Permisos sobre tablas o vistas específicas

GRANT SELECT ON dbo.MiTabla TO NombreUsuario;
GRANT INSERT, UPDATE, DELETE ON dbo.MiTabla TO NombreUsuario;
GRANT SELECT ON dbo.MiVista TO NombreUsuario;

Acceso completo sobre un esquema

GRANT SELECT ON SCHEMA::dbo TO NombreUsuario;
GRANT INSERT, UPDATE, DELETE ON SCHEMA::dbo TO NombreUsuario;

🔐 Gestión avanzada de seguridad

Crear Login (nivel servidor)

CREATE LOGIN MiLogin WITH PASSWORD = 'PasswordSeguro123!';

Crear Usuario en la base de datos

USE NombreBaseDatos;
CREATE USER MiUsuario FOR LOGIN MiLogin;

Asignar roles predefinidos

ALTER ROLE db_datareader ADD MEMBER MiUsuario;
ALTER ROLE db_datawriter ADD MEMBER MiUsuario;

Crear un rol personalizado

CREATE ROLE RolLecturaEscritura;

GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo TO RolLecturaEscritura;

ALTER ROLE RolLecturaEscritura ADD MEMBER MiUsuario;

Revocar permisos (REVOKE vs DENY)

-- Revoca el permiso (lo quita si existe)
REVOKE SELECT ON dbo.MiTabla FROM MiUsuario;

-- Deniega explícitamente (tiene mayor prioridad)
DENY SELECT ON dbo.MiTabla TO MiUsuario;

💡 Tip importante: DENY siempre tiene prioridad sobre GRANT.

Ejecutar como otro usuario (testing de seguridad)

EXECUTE AS USER = 'MiUsuario';

SELECT * FROM dbo.MiTabla;

REVERT;

📊 Monitoreo y diagnóstico

Que privilegios tiene un usuario

SELECT 
    dp.name AS Usuario,
    dp2.name AS Objeto,
    perm.permission_name,
    perm.state_desc
FROM sys.database_permissions perm
JOIN sys.database_principals dp 
    ON perm.grantee_principal_id = dp.principal_id
LEFT JOIN sys.objects dp2
    ON perm.major_id = dp2.object_id
WHERE dp.name = 'TuUsuario';

A que roles pertenece un usuario

SELECT 
    member.name AS Usuario,
    role.name AS Rol
FROM sys.database_role_members drm
JOIN sys.database_principals role 
    ON drm.role_principal_id = role.principal_id
JOIN sys.database_principals member 
    ON drm.member_principal_id = member.principal_id
WHERE member.name = 'TuUsuario';

Uso de índices y tablas

SELECT
    DB_NAME(database_id) AS BaseDeDatos,
    OBJECT_NAME(i.object_id) AS Objeto,
    last_user_seek,
    last_user_scan,
    last_user_lookup,
    last_user_update
FROM sys.dm_db_index_usage_stats s
JOIN sys.indexes i 
    ON s.object_id = i.object_id AND s.index_id = i.index_id
WHERE database_id = DB_ID('TuBaseDeDatos')
ORDER BY 
    COALESCE(last_user_seek, last_user_scan, last_user_lookup, last_user_update) DESC;

Consultas más costosas (performance tuning)

SELECT TOP 10
    qs.total_elapsed_time / qs.execution_count AS AvgElapsedTime,
    qs.execution_count,
    qs.total_logical_reads,
    qt.text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY AvgElapsedTime DESC;

Bloqueos activos

SELECT
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Sesiones activas

SELECT
    session_id,
    login_name,
    status,
    host_name,
    program_name
FROM sys.dm_exec_sessions
WHERE is_user_process = 1;

Actividad con Default Trace

SELECT *
FROM fn_trace_gettable(
    (SELECT TOP 1 path FROM sys.traces WHERE is_default = 1),
    DEFAULT
)
WHERE DatabaseName = 'TuBaseDeDatos'
ORDER BY StartTime DESC;

🧠 Buenas prácticas

  • Usa roles en lugar de permisos directos a usuarios
  • Evita usar dbo para todo, segmenta por esquemas
  • Aplica el principio de mínimos privilegios
  • Audita accesos periódicamente
  • Documenta cambios de seguridad

🚀 Conclusión

Estos comandos te permiten:

  • Administrar accesos de forma segura
  • Diagnosticar problemas de rendimiento
  • Identificar bloqueos y uso de recursos
  • Prepararte para escenarios reales en producción

Dominar estos scripts es clave para cualquier desarrollador backend o líder técnico que trabaje con SQL Server.


📌 Si te fue útil, considera guardar este artículo o compartirlo con tu equipo.



Envío de notificaciones push con Firebase Cloud Messaging (FCM) usando .NET Core 🚀

Firebase Cloud Messaging (FCM) de Google es un servicio que permite enviar notificaciones push a aplicaciones móviles, aplicaciones web y otros dispositivos conectados.

FCM ofrece una API HTTP que permite enviar mensajes desde servidores backend hacia dispositivos cliente de forma segura y escalable.

Las notificaciones pueden enviarse utilizando tres tipos principales de destino.


Tipos de destino de notificaciones en FCM

1️⃣ Token de dispositivo (Device Token)

Permite enviar una notificación directamente a un dispositivo específico.

Cada instalación de una aplicación genera un token único proporcionado por FCM. Este token identifica la instancia de la aplicación en ese dispositivo.

El backend puede almacenar este token para enviar notificaciones personalizadas.


2️⃣ Tema (Topic)

Los topics permiten enviar notificaciones a múltiples dispositivos usando un modelo publisher–subscriber.

Los dispositivos se suscriben a un topic y cualquier mensaje enviado a ese topic será recibido por todos los dispositivos suscritos.

Ejemplo de topics:

news
promotions
weather_alerts

3️⃣ Condicional

Las notificaciones condicionales permiten definir expresiones lógicas para enviar mensajes a múltiples topics.

Ejemplo:

'news' in topics && 'mexico' in topics

Esto enviará la notificación únicamente a dispositivos suscritos a ambos topics.


Autenticación con Firebase Cloud Messaging

Para enviar notificaciones usando la API HTTP v1 es necesario autenticarse usando OAuth2 mediante una cuenta de servicio de Google.

Crear la cuenta de servicio

  1. Ir a Firebase Console
  2. Abrir Project Settings
  3. Seleccionar Service Accounts
  4. Generar una nueva clave privada
  5. Descargar el archivo:
serviceAccount.json

Este archivo contiene las credenciales necesarias para autenticarse contra la API de FCM.


Obtener un Access Token usando Google CLI

Una forma sencilla de probar las notificaciones es obtener un Access Token temporal con la CLI de Google.

Activar la cuenta de servicio:

gcloud auth activate-service-account --key-file="tu-service-account.json"

Obtener el access token:

gcloud auth print-access-token

Este token se utiliza en las peticiones HTTP como un Bearer Token.


Enviar una notificación con curl o Postman

Ejemplo de petición usando curl:

curl --location --globoff 'https://fcm.googleapis.com/v1/projects/{{project_id}}/messages:send' \
--header 'Authorization: Bearer {{access_token}}' \
--header 'Content-Type: application/json' \
--data '{
"message": {
"token": "{{device_token}}",
"notification": {
"title": "Prueba desde Postman",
"body": "Prueba desde Postman"
},
"data": {
"accion": "test",
"id": "123"
},
"android": {
"priority": "HIGH"
},
"apns": {
"headers": {
"apns_priority": "10"
},
"payload": {
"aps": {
"sound": "default",
"contentAvailable": 1
}
}
}
}
}'

Campos importantes:

CampoDescripción
notificationInformación visible de la notificación
dataDatos personalizados enviados a la aplicación
tokenToken del dispositivo destino
topicTopic de destino
android / apnsConfiguración específica por plataforma

Enviar notificaciones desde .NET Core

En aplicaciones .NET Core / .NET 8 / .NET 9 podemos utilizar la API HTTP v1 de FCM usando las librerías de autenticación de Google.

Paquetes NuGet necesarios

--Requerido
Google.Apis.Auth

--Opcionales, para un cliente de alto nivel
FirebaseAdmin
FirebaseAdmin.Messaging

También se puede usar directamente HttpClient, como en el siguiente ejemplo.


Ejemplo: aplicación de consola en .NET

// Program.cs (.NET 8/9)using Google.Apis.Auth.OAuth2;
using System.Net.Http.Headers;
using System.Net.Http.Json;// Configuración
const string projectId = "TU_PROJECT_ID";
const string deviceToken = "TU_DEVICE_TOKEN";
const string topic = "news";// Obtener credenciales desde GOOGLE_APPLICATION_CREDENTIALS
GoogleCredential credential = await GoogleCredential
.GetApplicationDefaultAsync();credential = credential.CreateScoped(
"https://www.googleapis.com/auth/cloud-platform");// Obtener access token
var accessToken = await credential
.UnderlyingCredential
.GetAccessTokenForRequestAsync();using var http = new HttpClient();http.DefaultRequestHeaders.Authorization =
new AuthenticationHeaderValue("Bearer", accessToken);var url = $"https://fcm.googleapis.com/v1/projects/{projectId}/messages:send";// Ejemplo 1: enviar a un device token
var payloadToToken = new
{
message = new
{
token = deviceToken,
notification = new
{
title = "Hola desde .NET",
body = "Este es un mensaje de prueba vía FCM"
},
data = new
{
accion = "abrir_detalle",
id = "12345"
},
android = new
{
priority = "HIGH"
}
}
};// Ejemplo 2: enviar a un topic
var payloadToTopic = new
{
message = new
{
topic = topic,
notification = new
{
title = "Noticia",
body = "Nueva actualización disponible"
},
data = new
{
tipo = "update",
version = "2.0"
}
}
};// Elegir payload
var body = payloadToToken;var response = await http.PostAsJsonAsync(url, body);var responseText = await response.Content.ReadAsStringAsync();Console.WriteLine($"Status: {response.StatusCode}");
Console.WriteLine(responseText);

Ejecutar la aplicación

Primero configura la variable de entorno con el archivo de credenciales.

Windows

set GOOGLE_APPLICATION_CREDENTIALS=C:\ruta\clave.json

Linux / macOS

export GOOGLE_APPLICATION_CREDENTIALS=/ruta/clave.json

Luego ejecuta la aplicación:

dotnet run

Si todo está configurado correctamente, FCM devolverá una respuesta similar a:

{
"name":"projects/mi-proyecto/messages/0:1700000000000000%abcdef"
}

Esto indica que el mensaje fue aceptado por Firebase.


Conclusión

Firebase Cloud Messaging permite implementar fácilmente un sistema de notificaciones push escalable para aplicaciones móviles y web.

Utilizando la API HTTP v1 y OAuth2, es posible enviar notificaciones desde cualquier backend, incluyendo aplicaciones desarrolladas con .NET Core.

Esta integración es especialmente útil para:

  • Notificaciones en tiempo real
  • Alertas del sistema
  • Mensajes promocionales
  • Actualizaciones de aplicaciones

🖥️ Compendio de aplicaciones para Streaming de contenido multimedia

Mi primer acercamiento al streaming de contenido multimedia comenzó con Video Station, la aplicación nativa de los NAS Synology. Aunque en su momento fue una excelente solución, con el tiempo dejó de recibir soporte, lo que me llevó a buscar alternativas. En ese proceso descubrí un ecosistema de herramientas que hoy forman parte de este pequeño compendio de aplicaciones para streaming y automatización de bibliotecas multimedia.

🔤 Bazarr: el buscador automático de subtítulos

El primer problema que quise resolver fue la búsqueda manual de subtítulos. Así fue como encontré Bazarr, una aplicación que se encarga de buscar y descargar subtítulos automáticamente para películas y series, manteniendo la colección siempre actualizada.

Bazarr fue el punto de entrada que me llevó a descubrir otras herramientas, ya que depende de ellas para funcionar correctamente.

🎬 Radarr y Sonarr: automatización total para películas y series

  • Radarr se encarga de buscar, descargar y organizar películas.
  • Sonarr hace lo mismo, pero con series de televisión.

Ambas aplicaciones funcionan de manera muy similar y se integran fácilmente con distintos clientes de descarga. En mi caso, la primera configuración la realicé utilizando redes Usenet.

🌐 Usenet: la red detrás de la automatización

Usenet es una red originalmente creada para intercambio de discusiones, pero que hoy en día también se utiliza para compartir archivos. Para conectarte y aprovechar su potencial se necesitan tres componentes básicos:

  1. Un indexador: mantiene un registro de los archivos disponibles en la red. Existen gratuitos y de paga; yo utilicé NZBGeek.
  2. Un proveedor de Usenet: es el servicio que te da acceso a la red. Para obtener buena velocidad de descarga conviene contratar uno de pago; en mi caso, Usenet.farm.
  3. Un cliente de descargas: el encargado de recibir los archivos desde la red Usenet. Yo usé NZBGet, una opción ligera y eficiente.

En NZBGet configuré el proveedor de Usenet, mientras que en Radarr y Sonarr establecí la conexión tanto con el indexador como con el cliente de descargas. Una vez integrados, todo el sistema funcionaba de forma casi autónoma: buscaba, descargaba y organizaba el contenido de manera continua.

🎞️ Jellyfin: la evolución del streaming personal

Finalmente, cuando Video Station fue deprecado por Synology, opté por migrar a Jellyfin, una plataforma de código abierto que permite administrar, organizar y transmitir contenido multimedia desde cualquier dispositivo. Jellyfin se convirtió en el centro de todo mi ecosistema multimedia, reemplazando completamente a la solución original del NAS.

⚙️ Conclusión

Esta primera configuración funcionó de manera excelente. La integración entre Radarr, Sonarr, Bazarr y NZBGet permitió una automatización completa del flujo de descarga y organización de contenido, con Jellyfin como el punto final de consumo.

La única desventaja era la dependencia de servicios de pago (indexador y proveedor de Usenet), lo que me llevó a explorar alternativas basadas en torrents, de las cuales hablaré en mi siguiente publicación.


📌 En el siguiente post les platicaré sobre mi segunda configuración, esta vez utilizando torrents, y cómo logré mantener la automatización sin depender de servicios de pago.

Cómo monitorear un UPS desde Linux Debian usando NUT y un NAS Synology

En esta ocasión les explico cómo conectar un equipo con Linux Debian a un UPS (sistema de alimentación ininterrumpida) que está conectado a un NAS Synology, usando la herramienta NUT (Network UPS Tools).

Esto es útil para monitorear el estado de energía desde múltiples dispositivos en red y configurar apagados automáticos en caso de corte eléctrico prolongado.

🔌 Requisitos previos

  • NAS Synology con un UPS conectado y con la opción “Permitir que otros dispositivos de red se conecten al servidor UPS” activada.
  • Un equipo con Linux Debian en la misma red local.
  • Paquetes de NUT instalados en Debian (nut, nut-client).

🧰 Paso 1: Habilitar y configurar UPS de Red en NAS Synology

En el Panel de Control del NAS Synology, en la sección Hardware y Alimentación, en la pestaña UPS, seleccionar las opciones:

  • Habilitar compatibilidad con SAI
  • Habilitar servidor UPS de Red
Habilitar UPS NAS Synology

En la opción “Dispositivos Synology NAS permitidos”, agregar la ip del equipo con sistema operativo Linux

🖥️ Paso 2: Instalar NUT en Debian

Ejecuta los siguientes comandos en la consola de tu equipo Linux

sudo apt update
sudo apt install nut

⚙️ Paso 2: Configurar los archivos

Editar el archivo /etc/nut/nut.conf
Agregar la siguiente linea, define que el equipo Linux Debian actuará como cliente:

MODE=netclient

Editar el archivo /etc/nut/upsmon.conf
Agrega esta línea con la IP de tu NAS (y el nombre del UPS que suele ser ups):

MONITOR ups@<ip Nas Synology> 1 monuser secret slave
  • ups → nombre por defecto del UPS en Synology.
  • monuser secret → usuario/contraseña default.
  • slave → indica que esta máquina es un cliente del servidor UPS.

🧪 Paso 3: Verificar la conexión

Prueba si puedes obtener información del UPS desde Linux Debian:

upsc ups@<ip Nas Synology>

Deberías ver algo como:

battery.charge: 100
ups.status: OL
input.voltage: 230
...

🚀 Paso 4: Habilitar y arrancar el servicio

En el equipo linux, ejecuta los siguientes comandos de consola

sudo systemctl enable nut-client
sudo systemctl start nut-client

Para ver su estado:

systemctl status nut-client

🧠 Extras útiles

Comando para ver el nombre del UPS desde el NAS (vía SSH):

upsc -l
  • Estado OL = On Line (todo normal).
  • Estado OB = On Battery (corte de energía, funcionando con batería).
  • Estado LB = Low Battery (batería crítica, inicia apagado).

✅ Conclusión

Con esta configuración, puedes monitorear y proteger tu equipo Linux Debian ante cortes de energía, usando el UPS conectado a tu NAS Synology como fuente central de información. Es una solución simple y robusta para entornos caseros o de oficina que mejora la seguridad de tus datos y sistemas.

Levantar un contenedor de SQL Server en un NAS Synology

Después de varios intentos fallidos, por fin logre levantar un contenedor de SQL Server basado en Docker en mi NAS Synology.

Aquí les comento el paso a paso y los problemas que tuve al momento de levantar la instancia.

Primeramente, hay que verificar que nuestro NAS cumpla con los requerimientos mínimos, si es así, procedemos con la creación el contenedor dentro del Container Manager.

En la sección Contenedor, dar clic en el botón Crear.

En el campo Imagen, selecciona la opción Agregar Imagen.

En la configuración tendrás que agregar el registro de contenedores de Microsoft https://mcr.microsoft.com

Posteriormente, seleccionarlo como el contenedor de registro a utilizar

Después, buscar la imagen del contenedor de SQL Server mediante el buscador, ingresando el texto “mssql/server” en el buscador, y seleccionar la versión que se requiera.

Después, asignar un nombre y configurar los recursos a asignar a nuestro contenedor.

Para esto recomiendo utilizar prioridad de CPU media, ni alta ni baja ya que puede consumir todo nuestro CPU o puede no ser suficiente con configuración baja. Para el Limite de memoria asignar por lo menos un 30% mas de lo recomendado en los requerimientos mínimos, y muy importante, no habilitar el reinicio automático, ya que en caso de alguna falla puede entrar en un bucle de falla-reinicio infinito.

En la siguiente sección de configuración hay que asignar el puerto para nuestro contenedor, podría ser el puerto por defecto de SQL Server (1433) o algún otro.

Es importante configurar algún volumen físico de nuestro NAS a la ruta “/var/opt/mssql” del contenedor, para almacenar nuestras bases de datos fuera del contenedor y no se pierdan al apagar o reiniciar nuestro NAS.

Hay que agregar las siguientes variables de ambiente mínimas requeridas y asignar privilegios de ejecución al contenedor

Del resto de la configuración, pueden dejar las opciones por defecto y dar clic en Finalizar.

Con esto ya estaría listo nuestro contenedor de SQL Server, ya solo restaría crear alguna base de datos de ejemplo como la de AdventureWorks

Espero les sea de utilidad.

Referencias:

Prerequisites

Inicio rápido: Ejecución de imágenes de contenedor de SQL Server para Linux con Docker

Variables de ejecución del contenedor

Deploy and connect to SQL Server Linux containers

Montaje de un directorio host como volumen de datos

Restauración de una base de datos de SQL Server en un contenedor para Linux

AdventureWorks sample databases

Mover o respaldar archivos en un NAS Synology con script personalizado

En esta ocasión les comparto una opcion personalizada para mover o respaldar archivos en un NAS Synology mediante un script definido por el usuario, ejecutado de forma recursiva mediante el programador de tareas.

Esto puede ser util para ejecutar cualquier tipo de script, no solo para mover o respaldar archivos.

Lo primero que realice fue montar una carpeta remota, para esto abrir File Station

Ingrese al menú Herramientas / Montar carpeta remota / Carpeta compartida de CIFS e incluí las configuraciones de la carpeta remota

Posteriormente se tendría que crear el script a ejecutar y almacenarlo en algún directorio dentro del NAS

Para el script utilice comandos muy básicos de Linux, los comandos cp y rm

El script quedo de la siguiente forma:

cd /volume1/directorioorigen/
cp -uvr /volume1/directorioorigen/ /volume1/directoriodestino/
rm -rv /volume1/directorioorigen/*

El comando cp sirve para copiar archivos y el rm sirve para eliminar archivos en el sistema operativo Linux, les incluyo una descripción de las opciones que maneje:

-u copia solo si el archivo es mas nuevo que el archivo destino o en el destino no existe
-v–verbose explain what is being done
-r–recursive copy directories recursively

Pienso en un futuro actualizar el script utilizando el comando rsync.

Por ultimo, para crear la tarea programada tienen que ingresar a Panel de Control / Programador de Tareas

Posteriormente, al menú Crear / Tareas Programadas / Script definido por el usuario

Ahí definirás el nombre de la tarea, periodicidad de ejecución y la ruta del script a ejecutar

También les recomiendo seguir las recomendaciones para guardar los resultados de la ejecución del script

Por el momento es todo, espero les sea de utilidad

Referencias:

Sugerencias para crear tareas y escribir scripts en el Programador de tareas

Montar carpetas remotas

Comandos linux que debes conocer

rsync: Delete Source File After Transfer

Configurar proxy http a Nuget

En alguna ocasión, en una empresa que trabajaba, tuve problemas para acceder a las librerías de Nuget, me marcaba algunos errores de autenticación como los siguientes:

C:\Program Files\dotnet\sdk\3.1.300\NuGet.targets(128,5): error : Unable to get repository signature information for source https://api.nuget.org/v3-index/re
pository-signatures/5.0.0/index.json.

C:\Users\MiUsuario\AppData\Local\Temp\fhlnaoru.gdt\restore.csproj]
C:\Program Files\dotnet\sdk\3.1.300\NuGet.targets(128,5): error : Response status code does not indicate success: 407 (authenticationrequired). [C:\Users\MiUsuario\AppData\Local\Temp\fhlnaoru.gdt\restore.csproj]

En esa empresa, el navegador tenia configurado un proxy http, por lo tanto me di a la tarea de buscar como configurar dicho proxy a el componente de Nuget.

Pude identificar que el componente Nuget tiene un archivo de configuración donde se puede indicar que se conecte a internet mediante un proxy, por el momento no recuerdo cual es esa ruta, sin embargo, no creo que sea difícil ubicarla preguntando le al señor Google o a alguna IA.

Es posible configurar manualmente el proxy, editando el archivo con cualquier editor de texto, o se puede usar la consola de comandos y utilizar los siguientes comandos:
nuget.exe config -set http_proxy=http://urlproxy:puerto
nuget.exe config -set http_proxy.user=dominioRed\Usuario
nuget.exe config -set http_proxy.password=contraseña


Posterior a esto solo es necesario cerrar y volver a abrir el Visual Studio y el componente Nuget ya tendrá acceso a los repositorios de Microsoft.

Espero les sea de utilidad.

Cambiar estéreo Jeep Cherokee 98-01 (XJ)

Hace algunos días me encontré unos apuntes de cuando cambie por primera vez el estéreo de mi Jeep Cherokee modelo 2000, y pues, para no perder esta información, la comparto aquí.

Son los códigos de colores de los arneses del estéreo de fabrica para una Jeep Cherokee modelo 98-01 y su correlación con los códigos de colores ISO estándar de cualquier estéreo comercial.

Les paso mas en limpio la información.

Terminal Negra (7 cables)

FuncionalidadCherokeeEstéreo
Right Rear (-)Azul-NaranjaMorado-Negro
Left Rear (-)Café-AzulVerde-Negro
Right Front (+)MoradoGris
Left Front (+)VerdeBlanco
Right Rear (+)Azul-BlancoMorado
Left Rear (+)Café-AmarilloVerde
Power AntenaVerde-RojoAzul

Terminal Gris (6 cables)

FuncionalidadCherokeeEstéreo
Volt Battery (12v +)RosaAmarillo
Switched (12v +)Rojo-BlancoRojo
DimmerNaranjaNaranja-Blanco
Ilumination / Dash LightNegro AmarilloNaranja
Right Front (-)VerdeGris-Negro
Left Front (-)Café-RojoBlanco-Negro

Terminal Negra (1 cable)

FuncionalidadCherokeeEstéreo
GroundNegroNegro

Les debo las fotos de las terminales, en una oportunidad que tenga les saco una foto.

Referencias:

https://mundotuerca.cl/factory-wiring-harness-stereo-hyundai-radio-wiring-color-codes/