Satin Doll

jul 13, 2026 17:35 • 38 visitas

Después de pasar los últimos seis meses entre algoritmos de inteligencia artificial, redes, sistemas operativos y demás mecanismos empeñados en obedecer estrictamente a la lógica, he decidido volver a entregarme voluntariamente a un lenguaje en el que las reglas existen, sí, pero únicamente para que alguien con suficiente talento las doble sin que se rompan. El primer estándar que ha caído sobre mi atril ha sido Satin Doll, y hoy, apenas veinticuatro horas después de convertirme en estudiante de jazz, ya me he atrevido a grabarlo. Una decisión que probablemente cualquier profesor sensato habría desaconsejado, pero que encaja bastante bien con mi conocida faceta de aprender en público y equivocarme con las luces encendidas.

No es una elección cualquiera. Satin Doll -compuesta por Duke Ellington y Billy Strayhorn, con letra posterior de Johnny Mercer- pertenece a esa reducida aristocracia de estándares que parecen haber existido siempre. Es una melodía elegante, sofisticada y engañosamente amable: sonríe mientras obliga al pianista a pensar varios movimientos por delante. Bajo esa apariencia de conversación relajada se esconde una lección permanente sobre armonía, ritmo y buen gusto. No es una pieza que pretenda impresionar. En su lugar, prefiere hacer algo más difícil: enseñar que el jazz no consiste en tocar muchas notas, sino en encontrar exactamente las que merecen ser escuchadas. Y eso, como suele ocurrir con las ideas verdaderamente importantes, resulta bastante más complicado de lo que parece.

La grabación que acompaña esta entrada está hecha exactamente como ha salido de mis manos. Sin trampa ni cartón. Sin preparación previa específica para la ocasión. Sin detener la grabación para corregir un pasaje. Sin una segunda toma. Lo que se escucha es mi primer encuentro con el tema, con sus inevitables pausas mientras el cerebro intenta convencer a los dedos de que colaboren, con algún pequeño atropello de notas por la falta de soltura y con algún voicing que todavía admite margen de negociación. Soy un principiante y sería ridículo fingir lo contrario. Precisamente por eso me parecía más honesto compartir el proceso antes que el resultado.

Dentro de unos años volveré sobre esta grabación y probablemente me preguntaré en qué estaba pensando al publicar algo así. Espero que ocurra. Significará que he aprendido. Mientras tanto, este audio queda como una fotografía de un instante muy concreto: el día en que dejé de estudiar el jazz únicamente con la cabeza y empecé, torpemente, a hablarlo con las manos. Todo viaje merece un primer paso. Incluso aquellos que, como este, empiezan tropezando ligeramente las teclas.

Ropa prestada

jun 26, 2026 14:30 • 287 visitas

Hay quien sigue creyendo que las aplicaciones de escritorio nacen en oscuros laboratorios de programadores con barba y problemas de sueño. Como si cada icono del menú fuese el fruto de una compleja alquimia de compiladores, bibliotecas y sacrificios rituales a los dioses del software. Pero la realidad, a veces, no es tan romántica.

Vivimos rodeados de servicios web que han terminado ocupando el lugar que antes pertenecía a las aplicaciones tradicionales. Correo, calendarios, gestores de tareas, editores de texto, etc. Todo sucede en una pestaña del navegador. Todo vive en una URL. Todo es efímero. Y, sin embargo, hay algo incómodamente humano en querer que ciertas herramientas tengan su propio espacio. Su propia ventana. Su propia silla en el salón de nuestra máquina. Para eso existe Nativefier. Primero instalamos la herramienta:

sudo npm install -g nativefier

Y con ella, convertimos cualquier servicio web en una aplicación de escritorio autónoma:

nativefier "https://direccion-del-servicio-web.com" --name "MiAplicacion"

Y entonces ocurre la pequeña magia: Nativefier genera una carpeta con todo lo necesario para ejecutar la aplicación como si hubiese existido allí desde siempre: un ejecutable, sus dependencias y la agradable ilusión de que internet y el escritorio siguen siendo mundos distintos. La carpeta generada puede vivir donde queramos dentro de nuestro directorio personal, aunque resulta razonable moverla a algún lugar civilizado, por ejemplo:

~/Aplicaciones/MiAplicacion-linux-x64/

Porque el orden no evita el desastre, pero al menos permite localizarlo. El siguiente paso consiste en enseñarle al sistema que nuestra criatura existe. Para ello creamos el fichero miaplicacion.desktop dentro de ~/.local/share/applications/. Allí definimos su nombre, el ejecutable que debe lanzar, el icono que utilizará y la categoría donde aparecerá en el menú de aplicaciones:

[Desktop Entry]
Name=MiAplicacion
Exec=/home/usuario/Aplicaciones/MiAplicacion-linux-x64/MiAplicacion
Icon=gnome-mail-send-receive
Type=Application
Categories=Network;Email;
Terminal=false

Después, guardamos el icono correspondiente en ~/.local/share/icons/. Y aquí llega uno de esos detalles absurdamente técnicos que explican por qué la informática sigue siendo una disciplina profundamente artesanal: la ventana que acabamos de crear tiene una identidad secreta. Un nombre interno. Una especie de alias clandestino que el gestor de ventanas utiliza para reconocerla. Para descubrirlo ejecutamos:

xprop WM_CLASS

El cursor se transforma en una cruz, como si estuviésemos a punto de realizar una autopsia digital. Seleccionamos la ventana de la aplicación y la terminal responderá con algo parecido a:

WM_CLASS(STRING) = "miaplicacion-nativefier-xxxxxx", "miaplicacion-nativefier-xxxxxx"

Ese identificador debe añadirse al fichero .desktop mediante la directiva StartupWMClass. Si nos saltamos este paso, durante la ejecución de la aplicación se generará un molesto segundo icono en el dock.

[Desktop Entry]
Name=MiAplicacion
Exec=/home/usuario/Aplicaciones/MiAplicacion-linux-x64/MiAplicacion
Icon=gnome-mail-send-receive
Type=Application
Categories=Network;Email;
Terminal=false
StartupWMClass=miaplicacion-nativefier-xxxxxx

Y entonces, por fin, todas las piezas encajan. El icono abre la ventana correcta. El sistema deja de confundir nuestra aplicación con un navegador disfrazado. La integración parece natural. Y nadie diría que detrás de esa apariencia impecable no hay más que una página web vestida con ropa prestada.

La exclusión financiera

jun 20, 2026 7:15 • 438 visitas

Hace apenas treinta años, vecinos de zonas rurales acudían a la sucursal bancaria para realizar operaciones rutinarias: transferencias, pagos, ingresos, consultas, etc. Recientemente, muchas sucursales de pueblos pequeños han sido sustituidas por oficinas itinerantes que únicamente prestan servicio un día a la semana. Mantener una oficina física en un pueblo pequeño puede costar decenas o cientos de miles de euros al año y las entidades bancarias han descubierto que, con la creciente digitalización de los servicios financieros, se puede prescindir de ellas. El problema viene cuando usted es una persona mayor que necesita efectivo y tiene dificultades para manejar un smartphone.

Mientras tanto, ahí afuera las fintech hacen el agosto: Revolut aspira a alcanzar los 100 millones de clientes activos diarios en 100 países en el plazo de dos años. A ese ritmo de crecimiento, no es de extrañar que las entidades tradicionales hayan cerrado oficinas físicas y hayan instado a sus clientes a utilizar una aplicación móvil para la operativa diaria. De esa manera consiguen reducir en mantenimiento de sucursales y compiten en mejores condiciones contra N26, Revolut y Wise, imitando un modelo de negocio que ha llegado para quedarse. Sí, para quedarse porque países como Suecia han dejado de aceptar el efectivo como forma de pago para el 90 % de las transacciones y porque el Banco Central Europeo ya está trabajando en la creación de una versión digital del euro. Así están las cosas.

De cualquier modo, no haga demasiado caso a la noticia sobre la marcha atrás de Suecia en el rechazo a los billetes, puesto que esa "marcha atrás" se circunscribe a escenarios de catástrofe o guerra, y se propone para afrontar eventualidades de una duración no superior a la semana. Dicho esto, la evolución de la prestación de servicios financieros al ciudadano se presenta de la siguiente manera:

• Escasas oficinas físicas.
• Más bancobuses y puntos de atención compartidos.
• Pagos con móvil y tarjeta universales.
• Uso creciente de fintech.
• Necesidad decreciente de atención personal en oficina física.

Pero volviendo al tema central que nos ocupa, en pueblos pequeños, mercados, fiestas locales y entre personas mayores, el efectivo sigue teniendo una utilidad social y práctica difícil de sustituir, así que la verdadera cuestión para esos lugares, no es tanto si llegará el euro digital, sino si se garantizará que todos los vecinos sigan teniendo acceso a dinero y servicios financieros, independientemente de su nivel de digitalización. Esa es una de las preocupaciones centrales de las políticas de inclusión financiera en Europa sobre la que actualmente "se está trabajando". Por otra parte, se prevé que el euro digital se guarde en una cartera del Banco Central Europeo. Y surge entonces una duda más que razonable: si los ciudadanos trasladan sus ahorros de la banca comercial al BCE, ¿en qué queda la estabilidad financiera de la eurozona?

Algunos economistas sostienen que un euro digital amplio podría hacer el sistema más seguro, porque los ciudadanos tendrían acceso directo al dinero del banco central. Otros argumentan que podría debilitar el modelo bancario tradicional, obligando a los bancos a financiarse más en los mercados mayoristas y menos mediante depósitos de particulares. Por eso, el BCE está intentando encontrar un equilibrio: ofrecer una forma pública de dinero digital sin provocar una migración masiva de depósitos fuera de la banca comercial.

Pruebe con el cincel

may 27, 2026 14:15 • 844 visitas

Dentro de la ciberseguridad, existe una idea incómoda que muchos desarrolladores descubren tarde: no basta con revisar el código fuente. Aunque el código haya sido auditado por expertos y no exista una sola línea sospechosa, su trabajo podría estar comprometido. Imaginemos el siguiente escenario: alguien consigue modificar el compilador de C -pongamos GCC- para que se introduzca en el binario del compilador una instrucción maliciosa. El código fuente que usted ha revisado mil veces seguiría pareciendo limpio. Los repositorios permanecerían intactos. Sin embargo, su programa podría contener puertas traseras, vulnerabilidades deliberadas o mecanismos de espionaje.

No es ciencia ficción. La idea fue planteada en 1984 por Ken Thompson, en su célebre conferencia Reflections on Trusting Trust. Thompson describió cómo un compilador puede modificarse para insertar una puerta trasera al compilar el programa de autenticación de Unix. Pero lo más inquietante es que el compilador puede infectarse a sí mismo. ¿Cómo?

1. El compilador modificado introduce malware en programas concretos.
2. Cuando recompila su propio código fuente, vuelve a insertar la instrucción maliciosa.
3. Aunque los desarrolladores eliminen el código malicioso del código fuente del compilador, los binarios compilados siguen infectados.

De este modo, si no puedes confiar en el compilador, tampoco puedes confiar en sus binarios. Entonces aparece uno de los grandes problemas de la informática moderna: la tecnología se sostiene sobre una cadena de confianza imposible de verificar.

Cuando un desarrollador crea una pieza de software, los usuarios quedan a merced del código fuente, del compilador, del sistema operativo, de las bibliotecas, del firmware, de la BIOS / UEFI, del microcódigo del procesador, del hardware físico, de la cadena de suministro, de los fabricantes, de los certificados criptográficos, de las actualizaciones, de los repositorios y de los mantenedores. Todo organizado en una jerarquía de capas imposible de auditar. No porque la criptografía sea inutil. No porque las buenas prácticas sean malas, como usted comprenderá. Sino porque la complejidad tecnológica supera la capacidad humana de verificación.

A todo esto, agregar los problemas debidos a la naturaleza humana: ingeniería social, phishing, empleados descontentos, errores de configuración , contraseñas reutilizadas, actualizaciones comprometidas o un simple descuido. Por eso, los profesionales de la ciberseguridad no hablan de sistemas "invulnerables". Hablan de mitigación, resiliencia, segmentación, defensa en profundidad, detección, respuesta, hardening y gestión del riesgo. Así que, ya sabe... en el mundo de la informática -como en la vida misma- las cosas son seguras hasta que dejan de serlo. Si le parece mal, pruebe con el cincel.

El editor Vi

abr 5, 2026 11:00 • 1.9K visitas

Como estamos en pascua y nadie quiere arder en el infierno de los torpes, vamos a redimir nuestros pecados aprendiendo a manejar Vi, el legendario editor de texto basado en línea de comandos que trae de cabeza a los profanos de la informática. Habrá quienes digan que no hace falta complicarse la vida, que para eso ya tenemos a Nano. Claro, que también se le podría pedir a la vida que no duela, pero es que resulta que Vi -el áspero mesías de la terminal- no está para gustar, sino para salvarte. Imagina: servidor recién instalado, red sin configurar, acceso mínimo, sudor frío. No hay entorno gráfico. No hay internet. No hay Nano. Solo tú, la pantalla negra... y Vi mirándote a los ojos como un gato que sabe que no estás preparado para el asalto. Ahí solo tienes dos opciones: rezas o aprendes.

Primera revelación: Vi no es un editor, es un estado mental. Funciona en dos modos, como las personas que sonríen en público y se rompen en privado: el modo comando y el modo inserción. En uno das órdenes, te mueves, borras, deshaces, huyes, colaboras. En el otro escribes, como en cualquier editor civilizado, como si el mundo aún tuviera sentido. Confundir ambos modos es como declarar tu amor en mitad de una discusión: técnicamente posible, pero profundamente inconveniente. Y ahora, vamos con el catecismo mínimo, para no hacer el ridículo:

# Abrir o crear un documento
vi ruta/nombre-del-documento.ext
# Activar el modo de comando
Esc
# Abrir una nueva línea
o
# Borrar un caracter
x
# Borrar una línea
dd
# Deshacer la última acción
u
# Navegar izquierda, abajo, arriba y derecha
h, j, k, l
# Ir al principio o al final de la línea
0, $
# Ir a la primera o a la última línea
gg, G
# Activar el modo de inserción antes o después del cursor
i, a
# Escribir texto
Texto a escribir
# Guardar y cerrar
:wq Enter
# Cerrar sin guardar
:q! Enter

Con eso y un bizcocho, hasta mañana a las ocho. Ahora ya eres es un entusiasta acreditado de la edición de texto plano en Vi. No te olvides de pasturar la mona esta tarde ni de salir a caminar con los amigos. Eso sí, recuerda: cuando todo se rompa -porque se romperá- Vi seguirá ahí. No para ayudarte, sino para ponerte a prueba.

Mi nube

mar 12, 2026 16:45 • 3.3K visitas

He abandonado mi cuenta de Exchange, sincronizada con Thunderbird a través de Aluco, porque Aluco no gestiona el spam en el lado del usuario. Así que, he vuelto a mi cuenta IMAP + CalDAV + CardDAV + WebDAV -ahora sí- con ActiveSync, para la sincronización entre dispositivos. Para mí, esto supone recuperar el control sobre la gestión del spam, disponer de un espacio extra para el almacenamiento cloud y disfrutar de una reducción en el precio de la factura del groupware.

Sin embargo, me he dado cuenta de que mi proveedor no facilita un espacio de almacenamiento accesible por davs, sino por https, lo que significa que no puedo acceder a ese espacio fuera del navegador. Y por eso, me he puesto manos a la obra y he recuperado mi viejo proyecto de una nube propia, completamente integrada con el sistema operativo.

Antes de continuar, quiero explicar las mejoras que he introducido. En primer lugar, la sincronización se resuelve con sync --delete-during, lo que significa que cuando se actualiza un fichero local, se borra la versión anterior en el contenedor. O si en el contenedor está activado el versioning, se coloca una marca de borrado. En este último caso, el archivo deja de ocupar espacio en la lista de objetos actuales, pero se guarda en el historial de versiones, por si necesitamos recuperarlo después. Y para finalizar, la sincronización con el contenedor es directa, desde la carpeta Documentos. Empezamos definiendo los tipos de ficheros que no queremos guardar con sudo nano ~/.config/rclone/rclone-excludes.txt:

# Carpetas inútiles
- **/.git/**
- **/node_modules/**
- **/.cache/**
- **/.npm/**
- **/target/**
- **/dist/**
- **/build/**

# Archivos temporales
- **/*.tmp
- **/*.swp
- **/*~
- **/.DS_Store
- **/Thumbs.db
- **/._*

# IDEs
- **/.idea/**
- **/.vscode/**

Instalamos rclone con sudo dnf install rclone y nos aseguramos de configurarlo, bien con rclone config, bien almacenando el fichero de configuración en la carpeta ~/.config/rclone. Para probar la conexión, ejecutamos rclone ls storage:usuario-storage. Después creamos el servicio: con sudo nano ~/.config/systemd/user/cloud.service:

[Unit]
Description=Sincronización Mirror a S3
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/rclone sync "/home/usuario/Documentos" storage:usuario-storage \
    --delete-during \
    --checksum \
    --fast-list \
    --transfers 4 \
    --bwlimit 1M \
    --filter-from /home/usuario/.config/rclone/rclone-excludes.txt \
    --log-level INFO

StandardOutput=journal
StandardError=journal

Podemos consultar los logs emitidos con journalctl --user -u cloud.service -f. Creamos el timer que activa la sincronización cada cinco minutos con sudo nano ~/.config/systemd/user/cloud.timer:

[Unit]
Description=Run sync every 5 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min
Unit=cloud.service
Persistent=true

[Install]
WantedBy=timers.target

Reiniciamos los demonios y activamos el timer:

systemctl --user daemon-reload
systemctl --user enable --now cloud.timer
systemctl --user restart cloud.timer

Para comprobar que todo está en orden y que no hay sorpresas, podemos introducir los comandos systemctl --user list-timers y systemctl --user status cloud.service que listarán los timers de usuario activos y el estado de la sincronización, respectivamente.

Ahora ya tenemos nuestra propia nube, hecha de software libre, infraestructura de primer nivel e integración absoluta con el sistema operativo, lista para ser usada. Pero ¿qué pasa si se apaga la máquina mientras el sistema está sincronizando? Si la máquina se apaga mientras rclone sync está en curso:

• La operación se interrumpe abruptamente.
• Los archivos que ya se copiaron al servidor siguen allí.
• Los archivos que faltaban no se subirán.
• rclone no corromperá los archivos en el contenedor, porque solo escribe temporalmente y renombra al final.

Los archivos parcialmente subidos podrán quedar incompletos, pero rclone los detectará y reintentará la sincronización en otro momento. Y para finalizar -en caso de accidente- si queremos restaurar los archivos en la carpeta local, basta con:

rclone sync storage:usuario-storage /home/usuario/carpeta-restaurada-en-local \
  --progress \
  --fast-list \
  --transfers 4 \
  --checkers 8 \
  --bwlimit 1M \
  --filter-from /home/usuario/.config/rclone/rclone-excludes.txt

Actualización: Si queremos una capa extra de seguridad, podemos activar el versioning, lo que nos permitirá guardar versiones diferentes de los ficheros, que incluyan los cambios que vamos introduciendo. También podemos controlar el ciclo de vida de nuestro contenedor, limpiando el disco de archivos incompletos y borrando automáticamente versiones de cierta antigüedad. Para ello, creamos el archivo lifecycle.json en ~/.config/rclone:

{
  "Rules": [
    {
      "ID": "regla-1",
      "Status": "Enabled",
      "Filter": { },
      "Expiration": {
        "Days": 20
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 10
      }
    },
    {
      "ID": "regla-2",
      "Status": "Enabled",
      "Filter": { },
      "Expiration": {
        "ExpiredObjectDeleteMarker": true
      }
    },
    {
      "ID": "regla-3",
      "Status": "Enabled",
      "Filter": { },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 10
      }
    }
  ]
}

Instalamos el CLI de AWS con sudo dnf install awscli y lo configuramos con aws configure, introduciendo el access key, el secret key, la region por defecto y el output por defecto. Después aplicamos el lifecycle rule:

aws --endpoint-url url-del-endpoint \
    s3api put-bucket-lifecycle-configuration \
    --bucket usuario-storage \
    --lifecycle-configuration file:///home/usuario/.config/rclone/lifecycle.json

Y verificamos que se ha aplicado:

aws --endpoint-url url-del-endpoint \
    s3api get-bucket-lifecycle-configuration \
    --bucket usuario-storage

Para finalizar, si queremos recuperar todas las versiones con 10 días de antigüedad, empezamos listando y guardando una lista de todas las versiones disponibles:

aws --endpoint-url url-del-endpoint \
  s3api list-object-versions --bucket usuario-storage \
  > ~/.config/rclone/versions.json

Y después mostramos qué se copiará al directorio local:

TARGET_DATE=$(date -u -d "10 days ago" +%s)

jq -r --argjson target "$TARGET_DATE" '
  .Versions[]
  | select((.LastModified | sub("\\+00:00$";"Z") | strptime("%Y-%m-%dT%H:%M:%SZ") | mktime) <= $target)
  | "\(.Key) \(.VersionId)"' ~/.config/rclone/versions.json

Lo que dará un listado del tipo:

recetas/boquerones-en-vinagre.md 1769932289.488867
recetas/costillas-al-horno.md 1769932289.491374
recetas/pure-de-calabacin.md 1769932291.014892

Ahora sí, para terminar, copiamos al directorio local los ficheros que queremos recuperar, es decir los que tienen más de 10 días de antigüedad:

TARGET_DATE=$(date -u -d "10 days ago" +%s)

jq -r --argjson target "$TARGET_DATE" '
  .Versions[]
  | select((.LastModified
            | sub("\\+00:00$"; "Z")
            | strptime("%Y-%m-%dT%H:%M:%SZ")
            | mktime) <= $target)
  | "\(.Key) \(.VersionId)"' ~/.config/rclone/versions.json |
while read key version; do
  DEST="/home/usuario/restauracion-10-dias-antiguedad/$key"
  mkdir -p "$(dirname "$DEST")"
  echo "Descargando $key (versión $version)"
  aws --endpoint-url url-del-endpoint \
    s3api get-object \
    --bucket usuario-storage \
    --key "$key" \
    --version-id "$version" \
    "$DEST"
done

El tostón

mar 4, 2026 13:45 • 2.5K visitas

Instalas CentOS Stream en un MeLe Cyber X1 y el sistema, nada más despertar, te susurra al oído como oráculo resfriado: wifi firmware missing. Traducción del informático romance: aquí falta algo y no voy a decírtelo con cariño. ¿Se dejaron los chicos de IBM el wifi en la lavadora? No. No son descuidados, son poetas del comprimido. El firmware está ahí, sí, pero empaquetado al vacío, como el jamón. Y el kernel, que es muy suyo, se niega a morderlo en esas condiciones. Primer acto: ir a la despensa y abrir el envase:

cd /lib/firmware
sudo unxz -f iwlwifi-so-a0-gf-a0-*.xz

Descomprimir ahora es un gesto político que consiste en liberar los bits oprimidos por el .xz. Pero la cosa no acaba ahí. El sistema también se pone existencialista con unos avisos sobre iSCSI, esa tecnología que sirve para conectar discos lejanos como si fueran propios, en una especie de relación a distancia entre bloques:

Warning: Unmantained driver is detected cnic
Warning: Unmantained driver is detected cnic_init
Warning: Unmantained driver is detected bnx2i
Warning: Unmantained driver is detected bnx2i_mod_init

Lo que viene a decirnos -con voz de notario cansado- es que esos controladores existen, pero han sido abandonados en la cuneta digital. Nadie los mantiene. Nadie los cuida. Son perros viejos del kernel: muerden si pueden, pero ya no aprenden trucos nuevos.

Así que, si no vas a montar una red SAN -y va a ser que no-, puedes silenciar el coro de plañideras angustiadas desactivando los módulos. Se hace así: editas la profecía de dracut, escribes la lista negra y regeneras con initramfs:

sudo nano /etc/dracut.conf.d/kernel-module.conf
omit_drivers+=" bnx2i cnic "

sudo dracut -f

El conjuro queda guardado en /etc, ese lugar donde viven las decisiones que no quieres repetir. Resultado final: wifi despierto, kernel en paz, iSCSI desterrado. La máquina ya no se queja, arranca con dignidad y funciona como debe: en silencio, que para dar el tostón ya estoy yo.

Para el día a día

feb 21, 2026 16:25 • 1.8K visitas

De un tiempo a esta parte he estado trasteando en mis equipos, sin acabar de decidirme entre las distribuciones de GNU/Linux que voy a usar para el día a día. Sin embargo, hoy he llegado a una conclusión más o menos clara. No entro a valorar Ubuntu y sus derivados, porque -dejando de lado la estética del escritorio- veo en él una clara intención de facilitar las cosas en exceso. Por otra parte, Debian parece estable... y por su condición paternal sobre otras distros, se ha convertido en estándar. Pero, ¿cuál es el problema de Debian?

El problema es el tiempo que tarda en incorporar paquetes actualizados. Ya que con Debian no disfruto de los últimos paquetes, parece razonable valorar a Red Hat Enterprise Linux que, sin incluir software de última generación, es más estable que Debian. Pero, nuevamente... ¿cuál es el problema de Red Hat?

Poco tiempo después de la adquisición de RHEL por parte de IBM, se retiraron algunas aplicaciones de sus repositorios oficiales, a la vez que se facilitaba el acceso a suscriptores de pago. Esta polémica decisión ha generado cierto revuelo en la comunidad y muchos usuarios se han pasado a Alma Linux y a Rocky Linux, que vienen a ser clones del anterior. En el caso de Alma, tenemos un sistema compatible con Red Hat mantenido por una organización sin ánimo de lucro. Y en el caso de Rocky, tenemos otro sistema compatible mantenido por una organización para el bien común. Cabe citar también a Oracle, que actualmente desarrolla su distro con núcleo propio: Unbreakable Enterprise Kernel.

En cualquier caso, ni Red Hat, ni Rocky, ni Oracle, dejan clara la intención de mantener sus proyectos en el dominio público. Por la forma legal que ha adoptado y por su enorme comunidad de contribuidores, parece que Alma está más comprometida con la causa, pero... ¡vaya por dios! No puedo trabajar a una tasa de refresco de 120 Hz si instalo Alma en mi PC, así que al final me toca morir a Fedora, que es la distribución cutting edge por antonomasia, el upstream de Red Hat... la niña bonita, vamos.

Ahora usted me dirá que Fedora no es tan estable como todo lo mencionado anteriormente, pero quiero aclarar que esa merma de estabilidad se atribuye al ciclo de vida, de apenas 13 meses, y que los problemas que tiene se deben a bugs menores, fácilmente reparables. Así, ya tiene usted mi veredicto: para el día a día, Fedora.

Seguridad básica

feb 5, 2026 17:45 • 1.6K visitas

La seguridad en un servidor no es importante. Es vital. Como el oxígeno. Como el café. Como evitar que entren por la ventana mientras duermes y te cambien los muebles de sitio. Un servidor sin seguridad es un local abierto a las tres de la mañana: cualquiera entra, nadie paga y todos dejan huella, por eso, cuando un sysadmin levanta una máquina, lo primero que debería hacer no es celebrar el evento, sino cerrar con llave.

Empezamos el ritual conectándonos vía ssh y pidiéndole al sistema que recuerde quién es, porque suele olvidarlo:

ssh username@IP_SERVER_ADDR
sudo apt update
sudo apt upgrade

Después, el primer acto de camuflaje: cambiar el puerto por defecto. No es que esto convierta tu servidor en invisible, pero al menos deja de llevar el cartel luminoso de "Hola, soy el 22, pégame". Abrimos el confesionario con sudo nano /etc/ssh/sshd_config:

Port 23
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::

Reiniciamos el servicio con sudo systemctl restart sshd. Ahora toca levantar un muro. Un cortafuegos. Un portero con cara de pocos amigos. Uno ligero, educado y con porra: Uncomplicated Firewall (ufw):

sudo apt install ufw
sudo export PATH=$PATH:/usr/sbin # Add route to PATH
uwf --version
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 23/tcp    # SSH/SFTP
sudo ufw allow 25/tcp    # SMTP
sudo ufw allow 587/tcp   # SMTPS
sudo ufw allow 993/tcp   # IMAPS
sudo ufw allow 80/tcp    # HTTP
sudo ufw allow 443/tcp   # HTTPS
sudo ufw enable

Aquí el servidor aprende una palabra nueva: "no". No a lo que no conoce. No a lo que no toca. No a los que llaman a las tres de la mañana. Pero aún queda la fauna persistente: los que prueban contraseñas como quien mete monedas en una tragaperras esperando premio. Para ellos existe fail2ban: la memoria rencorosa del sistema.

sudo apt install fail2ban
fail2ban --version
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
sudo systemctl enable --now fail2ban

Una configuración sencilla para sshd sería la que se indica más abajo, seguida de un reinicio del servicio y de la comprobación de su estado:

[sshd]
enabled = true
mode    = normal
port    = 23
logpath = %(sshd_log)s
maxretry= 10
bantime = 1d
backend = %(sshd_backend)s
action = ufw

sudo systemctl restart fail2ban
sudo systemctl status fail2ban
sudo systemctl status fail2ban sshd

Y cuando el servidor ya sabe decir "no" en varios idiomas, le damos un nombre propio: apuntamos el dominio a su IP y lo vestimos con un certificado SSL, que viene a ser como ponerle traje y corbata criptográfica:

sudo apt update
sudo apt install certbot
certbot --version
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d your_domain

Certbot, eso sí, exige silencio por el puerto :80 durante el ritual. Como un sacerdote en plena ceremonia dominical. Después editamos la configuración del sitio en Nginx: /etc/nginx/sites-available/your_domain.conf:

server {
    listen 443 ssl;
    server_name your_domain;

    ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;

    # Additional security parameters
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # HTTP Redirection versus HTTPS
    location / {
        try_files $uri $uri/ =404;
    }
}

server {
    listen 80;
    server_name your_domain;
    return 301 https://$host$request_uri;
}

Y reiniciamos:

sudo nginx -t
sudo systemctl reload nginx

Y con esto, el servidor deja de ser un adolescente ingenuo y pasa a ser un adulto desconfiado. No es invulnerable -nadie lo es-, pero ya no abre la puerta en bata ni contesta a desconocidos. Porque la seguridad no es una opción avanzada del menú. Es el menú. No es un "ya lo miraré". Es un "si no lo hago hoy, otro lo hará mañana... pero desde fuera". Un servidor sin defensa es una promesa sin cifrar, una puerta sin cerrojo y una confianza sin memoria. Así que endurecerlo no es un mero cumplimiento: es un acto moral. Es una forma de decirle al mundo: aquí se entra con permiso, o no se entra. Y eso, en la red, es casi un poema.

Organizarse

ene 20, 2026 14:15 • 1.5K visitas

Abandoné mi cuaderno digital como quien deja un amor tóxico: no por falta de cariño, sino por pura supervivencia. Ocurrió tras un ingreso hospitalario a finales del año pasado, cuando descubrí -en bata y con suero- que no podía acceder a mi agenda desde la web. La modernidad, ya saben: es muy inteligente, pero solo cuando le apetece. Descarté también la agenda de papel por motivos higiénico-existenciales: se ensucia, se arruga, se moja y acaba oliendo a derrota. Así que hice lo que haría cualquier adulto responsable con conexión a internet: pagar. Contraté el servicio Pro de OVH, que resultó ser tan "Pro" como una bicicleta sin pedales. El calendario, eso sí, podía leerse. De tocarlo, ni hablar.

Entonces tomé una decisión drástica, casi dramática: contraté una cuenta de Exchange alojada en Francia, porque todo parece más serio si pasa por Francia. Correo, calendario, tareas y contactos funcionando... digamos que razonablemente bien, esa expresión que usamos cuando algo no falla lo suficiente como para devolverlo. Aunque tampoco se podía devolver.

Durante unas semanas me sentí organizado. No feliz, pero organizado, que es una especie de felicidad de baja intensidad. Sin embargo, empezó a crecer en mí una tristeza extraña, una pena tecnológica: la pena de estar usando software privativo para hacer peor lo que los estándares abiertos -IMAP, CalDAV, CardDAV- llevan años haciendo mejor, más rápido y sin pedirte el alma. A esa pena se sumó algo de vergüenza. Y la vergüenza, cuando madura, se convierte en decisión.

No me arrepiento de haber contratado Exchange. Para saber si te gustan las lentejas, tienes que comerlas. Ahora bien: Exchange no hace nada esencialmente distinto a lo que ya ofrece el software libre, salvo ponerte la zancadilla con complementos obligatorios, importaciones capadas y carpetas infernales como "Historial de conversaciones" o "Tareas", que viven en la bandeja de entrada como okupas conceptuales. Las tareas, por cierto, deberían estar en el calendario, aunque quizá eso sería demasiado sensato. Y luego está la licencia: unos sesenta euros anuales para un servicio que los estándares abiertos te dan por menos de seis. Diez veces más caro, diez veces menos libre. Una ecuación impecable... si vendes jaulas.

Es cierto que muchos de esos problemas desaparecen si usas Outlook, el hábitat natural de Exchange. Pero ahí surge el verdadero problema: la retención deliberada del usuario en un ecosistema cerrado que convierte tus datos en materia prima y tu dependencia en modelo de negocio. Entiendo que la gente quiera ganarse la vida, ¡pero no así, recórcholis!