3 Power Tips + 1 Power Link I4

Resumen: Tips para curl, ollama y KDE Plasma. Y un link acerca de cómo las organizaciones están usando el open source y el upskilling para responder a las demandas laborales impulsadas por IA

Power Tip #1

Obtener un json con información de diagnóstico a partir de curl. Por ejemplo: una solicitud que devuelva el código de respuesta http, la versión del protocolo http`, la dirección ip, el tiempo de transferencia hasta el primer byte recibido y el tiempo total de la operación completa*:

curl -Ls -o /dev/null -w '{"code":%{response_code},"http":"%{http_version}","ip":"%{remote_ip}","ttfb":%{time_starttransfer},"total":%{time_total}}\n'   https://fast.com | jq

Ejemplo de curl obteniendo json con información de diagnóstico

Power Tip #2

En el PT 2 anterior mostramos como usar un LLM offline. Aquí tenemos un script para bajar e instalar ollama:

#! /usr/bin/bash
cd /tmp || exit 1
curl -LO https://ollama.com/download/ollama-linux-amd64.tgz
sudo tar -C /usr/local -xzf ollama-linux-amd64.tgz
sudo useradd -r -s /bin/false -U -m -d /usr/local/share/ollama ollama
sudo usermod -a -G ollama "$(whoami)"
sudo tee  /etc/systemd/system/ollama.service << 'EOF'
[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=$PATH

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now ollama

Y ya está listo ollama para usar. 😉

Power Tip #3

Configurar klipper en Plasma para que al copiar una url llame a una acción. A diferencia de lo que ocurre en otros entornos o sistemas operativos, el Portapapeles de Plasma no sirve solamente para cortar/copiar y pegar. Sino que puede realizar tareas que hacen más sencillas las tareas tanto para usuarios finales como para usuarios administradores y/o desarrolladores. Los fundamentos de este Power Tip son:

  1. Una expresión regular, por ejemplo: ^(https?://[^ \t\r\n"'<>]+)$
  2. Una acción comando, por ejemplo: konsole --new-tab -e bash -lc 'curl -I -L -- "%1"; exec "${SHELL:-/bin/bash}" -i'

Dentro de la configuración del Portapapeles (klipper), se pueden realizar esos y otros ajustes.

Configurar una acción en Klipper

Luego al copiar una URL, podemos usar un menú emergente que dispare la acción (en este de acuerdo al ejemplo arriba mencionado el comando curl en konsole). 💪

Configurar una acción en Klipper

2025 State of Tech Talent Report

3 Power Tips + 1 Power Link I3

En esta edición, tips para bash scripting, gestión de paquetes con dnf, y LLM en tu máquina. 😉 Y un link sobre como se refieren los medios de comunicación a la IA.

Power Tip #1

Self-logging script con exec (script con logging incorporado)

#!/bin/bash
LOG_DIR="$HOME/logs"
mkdir -p "$LOG_DIR"
LOG="$LOG_DIR/$(basename "$0")_$(date +%Y%m%d-%H%M%S)_$$.log"
exec > >(tee -a "$LOG") 2>&1
ping -c10 9.9.9.9

La línea exec > >(tee -a "$LOG") 2>&1 sirve para que toda la salida del script también vaya el archivo determinado por la variable $LOG. Comentario: En general 2>&1 es reemplazado por &>, en versiones de bash bastante recientes. ¿Y por qué no usarlo? Porque ese atajo solamente sirve para redireccionar a archivos regulares. Por lo tanto, hay que usar la manera clásica de redireccionamiento de stdin y stderr.

Power Tip #2

Reemplazar un paquete por otro con dnf. Por ejemplo, reemplazar pipewire-pulseaudio, por pulseaudio, en caso de problemas de compatibilidad.

dnf swap pipewire-pulseaudio pulseaudio --allowerasing

Power Tip #3

Usar ollama, para ejecutar y gestionar modelos de AI especializados en lenguaje en tu propia máquina, por ejemplo para explicar el contenido de un archivo:

ollama run gemma3 "Explicar sintéticamente, lo que hace este archivo de reglas de polkit  $(cat /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules)" 

Ollama, LLM en tu propia máquina

Stop Pretending Chatbots Have Feelings: Media's Dangerous AI Anthropomorphism Problem

3 Power Tips + 1 Power Link I2

En esta edición: 3 poderosos consejos para bash, advirtiéndo sobre la letra chica de ellas y una noticia importante sobre certificados SSL/TLS.

Power Tip #1

Agregar de manera inteligente y selectiva la opción pipefail en bash con set -o pipefail a los scripts de bash.

De esta manera, bastará con que un solo comando tenga un estado de salida distinto de 0 para que el resultado final también de distinto de 0. Hay muchas publicaciones e incluso GPTs que aconsejan el uso de pipefail.

Esto puede ser valioso cuando cualquier comando unido por | tiene que terminar sin errores para que tenga sentido continuar con la ejecución del script.

Sin embargo, acá van algunas recomendaciones:

  • Evitar set -o pipefail globalmente al usar comandos como:

    • grep -q
    • head
    • awk 'exit'
    • sed 'q'
  • Activar pipefail solo donde realmente sea necesaria:

(set -o pipefail; comando1 | comando2)
  • O desactivar luego de usarla:
set -o pipefail
comando1 | comando2
set +o pipefail

Power Tip #2

Realizá tus propios tests para decidir si un script tiene que terminar al ocurrir un error

Se puede leer en el Debian Policy Manual que recomienda fuertemente el uso set -e. Esa opción le dice a bash que cuando un comando termina en un estado de salida de distinto de 0 el script debe termina inmediatamente. La cuestión es que esa opción tiene muchas de excepciones (algo que se puede verificar al leer la manpage de bash), lo cual hace el uso de esta configuración poco confiable en scripts de gran complejidad. Tenemos que comprender que bash sabe poco de la semántica. Por ejemplo, considerar este sencillo script:

#! /bin/bash
set -e

cd /home/admin/download
curl -O https://example.com/project.zip
unzip project.zip

El comando curl no tiene exit status distinto de 0 si obtiene http code 404, bash no sabe como cada herramienta externa maneja el exit status. Si el archivo projec.zip ya existe, el comando unzip estará operando sobre el la versión del archivo que probablemente no queremos.

Lo correcto que nosotros mismos le agreguemos la lógica necesaria de acuerdo a lo que estamos necesitando.

Probablemente alguien puede estar tentado a agregarle la opción -f sin embargo la propia manpage de curl dice que no es 100% segura. Además puede haber casos en los que necesitamos saber exactamente el tipo de problema que hubo. En tal caso lo mejor será obtener el http code con curl y evaluar dicho código con bash, es decir hacemos que cada herramienta haga lo mejor que sabe hacer.

Power Tip #3

Usar set -u para forzar a que el script termine con error si hay hay variables no definidas. En general, esta opción tiene menos tiene contraindicaciones que las dos anteriores. Es altamente conveniente combinarla con la herramienta shellcheck. Por ejemplo, en el siguiente script:

#!/bin/bash
set -u
[[ "$DEBUG" == "yes" ]] && echo "Modo debug"
echo "$somevar"
someanothervar="example"
  • No tiene definida la variable DEBUG
  • No tiene definida la variable somevar
  • La variable someanothervar si bien está definida no se usa nunca. No es un error grave, pero al no utilizarse probablemente sea inncesaria, pero es algo que no es detectado por set -u.

ShellCheck

¿Certificados SSL/TLS para direcciones IP?: We've Issued Our First IP Address Certificate

Comparación de systemd-run con nohup, tmux y screen

systemd-run
Si estamos conectados por ssh y sufrimos una desconexión mientras ejecutamos un comandos, puede representar un problema, desde la interrupción del proceso o la pérdida del acceso a la salida estándar/error del mismo. Existen comandos como nohup que de alguna manera nos ayudan a mitigar esas situaciones, tales como nohup, o multiplexores de terminal como screen y tmux.

Al usar systemd, contamos con una herramienta tan sencilla como poderosa: el comando systemd-run que permite ejecutar un comando muy sencillo como el siguiente en un servicio. O para ser más exactos en una service unit:

systemd-run --user ping 8.8.8.8

Comparación con nohup, tmux/screen

Característica systemd-run nohup tmux / screen
Supervisión del estado Sí, vía systemctl status y journalctl No, se debe usar ps o pgrep Parcial, requiere inspección manual de la sesión
Control del ciclo de vida Completo: iniciar, detener, reiniciar con políticas de reinicio Nulo: solo iniciar, sin reinicio automático Manual: requiere interacción del usuario
Manejo de logs Centralizado en journal, con metadata y timestamps Básico: redirige a nohup.out sin rotación Opcional: solo si se configura logging explícitamente
Integración con el sistema Alta: como unidad de systemd, con cgroup, slices, y logs centralizados Nula: proceso genérico del usuario Baja: proceso de usuario sin integración con systemd
Persistencia tras logout Alta: configurable vía lingering o como unidad del sistema Limitada: depende de configuración de logind Alta (tradicional), pero afectada por KillUserProcesses
Persistencia tras reinicio Posible mediante conversión a unidad persistente o uso de systemd-timer No, se requiere cron, scripts externos No, sesión se pierde tras reboot
Políticas de recursos/aislamiento Completa: límites CPU, memoria, I/O, namespaces, privilegios, etc. Nula: se requiere uso externo de ulimit o nice Nula: requiere herramientas externas
Facilidad de uso interactivo Baja: orientado a ejecución no interactiva Nula: no interactivo Alta: diseñado para interacción, múltiples ventanas/sesiones
Ideal para Tareas ad-hoc, servicios temporales, pruebas controladas Procesos simples que deben continuar tras logout Tareas interactivas largas o sesiones remotas persistentes

Más Ejemplos

Ansible

Advertencia: Los siguiente comandos no son para copiar y pegar sin analizarlos, deben ser ajustados al entorno en los cuales se los desea utiizar. El propósito principal es mostrar la potencia práctica de la herramienta systemd-run.

Objetivo: Ejecutar playbooks críticos en entornos controlados, como servicios temporales autoreiniciables.

systemd-run -p Restart=on-failure -p PrivateTmp=yes -p Description="Provisionar servidores" \
  -p SuccessExitStatus=0 \ 
  -p RestartSec=5 \ 
  -p TimeoutStopSec=30   \ 
  --unit=ansible-run ansible-playbook site.yml -i inventory/prod

Ventajas:

  • Crea un entorno temporal (/tmp aislado).
  • Si falla, se reinicia automáticamente.
  • El log de toda la ejecución queda en journal.

mysqldump

Objetivo: Realizar dumps de bases de datos con límites de memoria y sin cargar el sistema.

systemd-run \
  -p MemoryMax=750M \
  -p MemorySwapMax=150M \
  -p Nice=10 \
  -p Description="Backup de MySQL sin afectar el sistema" \
  --unit=mysql-dump \
  bash -c 'mysqldump --all-databases > /tmp/backup.sql'

Ventajas:

  • Protege al sistema de un uso excesivo de memoria
  • Baja prioridad de batch (Nice=10).
  • Log y control vía systemd.

Azure CLI

Objetivo: Apagar/desasignar todas las VMs del grupo "GrupoDesarrollo" en segundo plano

systemd-run --unit=apagar_vms \
    --service-type=oneshot \
    -p WorkingDirectory=/tmp \
    bash -c 'az login --identity && az vm list -g GrupoDesarrollo --query "[].id" -o tsv | xargs -r az vm deallocate --ids'

Ventajas:

  • Ejecución desacoplada de la terminal.
  • Se puede usar journalctl para auditar el comando.
  • Control sobre el entorno de ejecución

Conclusión

El comando systemd-run es una alternativa más robusta que otros comandos legacy o multiplexores de terminal, ya que permite, no solamente desacoplar el proceso de la terminal sino también poder gestionarlo perfectamente dentro de systend.

Fuentes y más recursos