Supongo que es esa la primera lección que deberían enseñar en cualquier escuela de ajedrez. La excelencia que se prodiga en la mayor parte de empresas e instituciones, lleva veneno. Y el veneno, mata. Antes de jugar al ajedrez, planifique el momento de su retirada, porque quien está dispuesto a ganar a cualquier precio, corre el riesgo de perderse en sus ambiciones. El ajedrez tiene la mala costumbre de disfrazarse de diversión. Desde fuera parece una actividad reposada: dos personas sentadas frente a un tablero moviendo piezas de madera. Pero, en la élite, es un deporte de resistencia. Horas de concentración absoluta, preparación obsesiva de aperturas, estudio constante de rivales, presión competitiva y un desgaste psicológico que no sale en las retransmisiones. La partida termina cuando cae el rey. La competición -en cambio- continúa dentro de su cabeza.

Resulta curioso que una disciplina cuyo fin es tomar las mejores decisiones posibles, acabe castigando nuestra capacidad para decidir. El mismo cálculo que sirve para encontrar la mejor jugada puede convertirse en una cárcel, porque siempre existe una variante más, una preparación adicional, otro torneo... y la retirada suena a rey caído. Una caída como remedio para una actividad que no da tregua. Una tregua que se niegan unos a otros. Quizá por eso el ajedrez debería plantearse más como un arte de pensamiento que como un deporte de competición. Si alguna vez llego a jugar razonablemente bien, me gustaría conservar la capacidad de cerrar el tablero con dignidad, como quien gana por haber sabido abandonar a tiempo.

Supongamos que el valor de gamma es $\gamma =11.5$. Eso significa que si el intérprete pulsara la tecla del controlador con un nivel de $63.5$, la salida debería sonar a $75$. No olvidemos las condiciones de contorno: si la entrada vale $0$, la salida debe valer $0$. Y si la entrada vale $127$, la salida tiene que valer también $127$.

Con esto, ya tenemos tres puntos de funcionamiento conocidos. Podríamos buscar alguno más, pero solo serviría para complicar las cosas, ya que el teorema fundamental de la interpolación polinómica nos dice que solo se necesitan $n+1$ puntos para describir una función polinómica de grado $n$, y es obvio que lo que se busca es una función exclusivamente convexa. Ahora vamos a entrar en el detalle: la función polinómica de grado 2 tiene la forma $f(x)=a{x}^2+bx+c$. Si para $x=0$, $f(x)=0$, entonces $c=0$. Conocido $c$, falta plantear el siguiente sistema de ecuaciones con los otros dos puntos:

Que tiene como solución $a=\frac{-46}{16129}$ y $b=\frac{173}{127}$. La función que relaciona la entrada y la salida MIDI queda pues como sigue:

Puesto que la mayor parte de software de modelado físico se limita a unir con lineas rectas un conjunto de puntos dados de antemano, de esta ecuación podemos sacar un total de nueve puntos equiespaciados en el dominio, que servirán como aproximación a la función anterior. Y con eso, ya solo queda disfrutar la experiencia de un sonido fiel a la pulsación.

Ahora lo que se lleva es preguntarle a ChatGPT. Y se lleva, porque los LLMs dan una respuesta que afronta y resuelve de lleno la pregunta que les hacemos: no hay necesidad de buscar entre páginas, filtrar el contenido de las menos relevantes y resumir. ChatGPT busca, filtra y resume por ti. Y el verdadero drama surge cuando tomamos conciencia de que la IA generativa nos puede ayudar porque ha sido alimentada con el contenido que los seres humanos hemos generado durante décadas, antes incluso del nacimiento de internet.

¿Es eso malo? Un grupo de expertos en IA se apropió indebidamente de medio millón de obras protegidas por derechos de autor para alimentar el modelo de lenguaje que mañana te dará una receta de pollo al pesto y te explicará la diferencia entre el perejil y el cilantro. La cuestión es que los autores de las obras que alimentaron la IA, se convierten así en víctimas de un lucro cesante porque Anthropic ha vulnerado sus derechos y usted prefiere consultar a la IA antes que comprar su trabajo: la misma tecnología que lleva una receta de pollo a la interfaz del chat LLM, sustituye al ser humano que se ganaba la vida compartiendo con usted una receta de pollo.

Y ¿qué podemos hacer? Muchas personas perciben el paro tecnológico como una amenaza, por eso los chicos de Cloudflare han puesto en marcha una funcionalidad llamada pay-per-crawl, que permite abonar pequeñas cantidades de dinero a los creadores de contenido que alimentan a ChatGTP, Claude, Gemini, DeepSeek, etc. Parece justo: usted paga por tokens de IA y la IA paga por una receta de pollo. Pero... ¡ojo! Si alguien puede cobrar por su contenido y ese contenido es público, ¿quién garantiza que no lo vayan a copiar y revender a un precio menor? Señores, lo que se pone en entredicho es la esencia de internet. Y ahora, ¿quién le pone el cascabel al gato?

Dentro de los controladores de piano, cabe destacar el vetusto Kawai VPC1 (2013), de acción similar al aclamado Kawai MP-11. Su recorrido de tecla es idéntico al de los pianos acústicos y su resistencia a la pulsación se reparte entre los 53 gramos iniciales hasta los 78 g de fondo en la zona central. Su longitud de pivote alcanza los 25 cm, permitiendo al interprete tocar cerca del fondo sin fatiga apreciable. Un lujo de controlador que imita con pleno acierto el auténtico mecanismo de acción de los pianos de cola Kawai. Eso sí, con un peso que ronda los 30 kg y unas dimensiones superiores a las de la mayoría de alternativas del mercado.

Por una tercera parte de lo que cuesta el VPC1 y una tercera parte de lo que pesa, el StudioLogic SL88 MKII ofrece una experiencia similar a los pianos de escenario Nord y Yamaha. Tecla Fatar con recorrido estándar entre 10 y 11 mm, y longitud de pivote de 22 cm compensada con una reducción del peso inicial y el fondo que se situan en torno a los 48 y los 63 g respectivamente, también en la zona central. Un equilibrio entre precio, prestaciones y peso más que interesante, aderezado por una reducción de dimensiones que facilita mucho su transporte.

Si tu plan es usar la aplicación Numa Player para reproducir como sonido la señal MIDI procedente de alguno de estos controladores, no esperes milagros. Numa Player no modela la resonancia de sus pianos. En su lugar, yo recomiendo Modartt Pianoteq 9 en una máquina capaz de responder con una latencia inferior a los 10 ms. Así no vas a tener problemas y todo irá como la seda. Ya verás que bien.

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.

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.

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.

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.

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

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.

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.

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!

Una de las razones por las que GNU/Linux no ha conseguido imponerse en el mercado doméstico es la que se atribuye a la fragmentación: GNU/Linux no es un sistema operativo, sino un conjunto de sistemas operativos que se derivan unos de otros y que están hechos de innumerables contribuciones de pequeños y grandes grupos de desarrolladores. Cuando un desarrollador prepara una aplicación, debe compilar versiones distintas de esa misma aplicación para todas y cada una de las distintas distribuciones de GNU/Linux que existen en el mundo. ¡Y se cuentan por centenares!

Esta situación provoca la huida de instituciones y empresas que reniegan de desarrollar nuevo software para GNU/Linux. Y así, cuando compras un GPS para tu automóvil -por poner un ejemplo- verás que la actualización de los mapas se puede realizar desde macOS y desde Windows... ¡pero no desde GNU/Linux! Dejamos para otro momento la consideración de quienes ven a GNU/Linux como un competidor desleal, dado que la mayor parte de distribuciones son gratuitas.

Pero volviendo al tema de la fragmentación, a día de hoy, GNU/Linux está tratando de resolver la situación distribuyendo sus aplicaciones en contenedores. Para que usted me entienda, un contenedor contiene las partes imprescindibles de un sistema operativo necesarias para ejecutar la aplicación contenerizada, virtualizada dentro de GNU/Linux. Esto hace que dicha aplicación pueda funcionar correctamente en cualquier distribución y quede así solventado el problema de la fragmentación.

¿Y qué tiene esto que ver con los cambios que he detectado en Fedora Silverblue durante los dos meses que llevo usándolo? Pues que al instalar la versión contenerizada de LibreOffice en Silverblue, me he encontrado con que no se guarda la fuente necesaria para la inserción de fórmulas matemáticas. ¿Por qué no? Por que Silverblue es inmutable. ¿Tiene solución? ¿Es grave? Para nada. Vamos a ver cómo se soluciona.

Lo primero que necesitamos es descargar la fuente OpenSymbol y extraerla del RPM como fichero .ttf:

curl -O https://dl.fedoraproject.org/pub/fedora/linux/updates/43/Everything/x86_64/Packages/l/libreoffice-opensymbol-fonts-25.8.3.2-2.fc43.noarch.rpm

rpm2cpio libreoffice-opensymbol-fonts*.rpm | cpio -idmv

Después, creamos una carpeta de fuentes en el directorio local -que en Fedora Silverblue sí es mutable- y la copiamos al directorio que hemos creado anteriormente:

mkdir -p ~/.local/share/fonts

cp usr/share/fonts/opensymbol/OpenSymbol.ttf ~/.local/share/fonts/

Actualizamos la caché de fuentes con fc-cache -f -v, et voilà! Ya tenemos la fuente disponible para su uso en la aplicación de LibreOffice (Flatpak) y en cualquier otra aplicación. No ha sido difícil, ¿verdad? ¿Crees que en el futuro -con la contenerización de aplicaciones- veremos llegar GNU/Linux a entornos de escritorio de uso masivo? ¿O piensas que hemos llegado tarde? ¡Haz tu apuesta ahora!