La tregua

sept 6, 2026 13:35 • 109 visitas

Hoy recibo el libro con el que espero llegar a jugar bien al ajedrez, después de leerlo y estudiarlo con detenimiento, claro está. Y precisamente hoy, es el día en que su autor, Miguel Illescas, en una entrevista de podcast del año 2024, nos hace saber que abandonó la alta competición porque su cuerpo no aguantaba el estrés provocado por el juego después de quince años de dedicación en cuerpo y alma. Según cuenta, a partir de cierto momento, el ajedrez le empezó a pasar factura. Poco a poco comprendió que no podía sostener ese nivel de exigencia y se vio obligado a reorientar su carrera hacia el entrenamiento y la divulgación.

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.

No problem

sept 1, 2026 9:30 • 149 visitas

Me desanimé un poco al comprobar cómo las lecciones de Open Studio parecían más fáciles sobre la pantalla que sobre el teclado, así que -por un momento- decidí volver a los pequeños preludios de J. S. Bach. Concretamente, al BWV 935 y al BWV 937. Sin embargo, mi verdadero propósito era el jazz y, como todavía me sentía superado por el nivel de las lecciones de Open Studio, decidí darle una oportunidad al primer y al segundo volumen de Exploring Jazz Piano, de Tim Richards. Ahí comprobé que Richards propone un avance más progresivo y más asequible.

Richards plantea el aprendizaje desde una perspectiva muy práctica. En lugar de introducir desde el principio armonías complejas o improvisaciones difíciles, nos reta con pequeñas piezas que sirven para trabajar uno o dos conceptos concretos: un acompañamiento, un patrón rítmico, una progresión armónica o una escala. Este enfoque recuerda al de muchos métodos clásicos, donde la dificultad técnica aumenta de manera gradual sin perder nunca de vista el aspecto musical. Para quien llega al jazz desde el piano clásico, esa progresión resulta especialmente tranquilizadora.

No Problem es uno de los primeros temas del libro. Un tema sencillo y alegre, con estructura AABA, una de las formas más habituales en el jazz y en la canción popular norteamericana durante buena parte del siglo XX. La melodía se construye sobre la escala pentatónica mayor, una escala de cinco notas que evita casi todas las tensiones y permite improvisar con libertad. Precisamente por eso, a menudo se dice que constituye la puerta de entrada a la improvisación.

El ejercicio no consiste únicamente en interpretar la pieza, sino en transportarla a las doce tonalidades. Ese trabajo de transposición obliga a no depender de la memoria muscular y a comprender de verdad la relación entre las notas y los acordes. Una práctica exigente, pero provechosa: el teclado deja de ser un conjunto de teclas blancas y negras para convertirse en un mapa coherente. Posiblemente a usted no le impresione, pero créame si le digo que esta pieza tiene un gran valor pedagógico. Así que, ahí va mi interpretación, casi a primera vista. Disfruten.

La calibración

ago 21, 2026 15:20 • 250 visitas

Calibrar un controlador MIDI exige dedicar tiempo a examinar y corregir la respuesta del software de modelado en relación a la señal con que lo alimentamos, pero ese tiempo invertido merece la pena, porque garantiza una respuesta fiel. Cuando conectas el controlador a la computadora y percibes que las notas quedan especialmente atenuadas en pulsaciones de intensidad intermedia, es hora de determinar un valor $\gamma$ que amplifique en su justa medida la señal de salida para ese nivel de pulsación, que se encuentra entre $63$ y $64$ en una escala de ocho bits.

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) = ax^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.

El cascabel y el gato

ago 7, 2026 22:25 • 455 visitas

Los hábitos del internauta han cambiado. Durante los años noventa navegábamos por la red con palabras clave que servían para alimentar nuestras búsquedas en Altavista, Yahoo o Google. Y dentro de los resultados de búsqueda, después de seleccionar y filtrar todo el contenido, encontrábamos lo que necesitábamos. Así eran las cosas, pero por suerte o por desgracia esos días de web elaborada y consumida por seres humanos han llegado a su fin.

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?

Dos controladores

ago 6, 2026 16:40 • 464 visitas

Los fabricantes de instrumentos musicales rara vez publican datos técnicos sobre sus productos, por eso los músicos -en la mayoría de casos- se ven abocados a desplazarse a la tienda de música a probar instrumentos en exposición antes de realizar una compra. En particular, no conozco ningún fabricante de controladores ni de pianos digitales que publique el recorrido vertical de la tecla de ninguno de sus modelos, ni tampoco su resistencia media a la pulsación. Pero esa información es vital, ya que pasada por alto nos llevará -sin duda- a tomar una decisión equivocada.

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.

Satin Doll

jul 13, 2026 19:35 • 824 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 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 a pensar varios movimientos por delante. Bajo su apariencia de conversación relajada esconde una lección permanente sobre armonía, ritmo y buen gusto. No es una pieza que pretenda impresionar. En su lugar, prefiere enseñar que el jazz no consiste en tocar muchas notas, sino en encontrar exactamente las que merecen ser escuchadas.

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. 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. Y precisamente por eso, me parecía más honesto compartir el proceso antes que el resultado. Aquí está. Disfruten.

Ropa prestada

jun 26, 2026 16:30 • 1.1K 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 9:15 • 1.2K 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 16:15 • 1.6K 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 13:00 • 2.7K 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 17:45 • 4.1K 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 14:45 • 3.2K visitas

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.

Seguridad básica

feb 5, 2026 18:45 • 2.4K 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 15:15 • 2.3K 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!

La fragmentación

ene 15, 2026 18:30 • 2.0K visitas

Llevo poco más de dos meses ocupado en casa con Fedora Silverblue y hoy toca hablar de los cambios que he notado respecto a otras distribuciones. Son solo dos pequeños detalles, uno de los cuales ya ha sido tratado en este diario, así que me centraré en el segundo, que es el que está relacionado con la gestión de paquetes. Parece poco creíble que una familia de sistemas operativos como GNU/Linux rinda más y provea una mejor experiencia de uso que otros sistemas y que -aún así- no haya conseguido alcanzar una cuota mayoritaria en entornos de escritorio. Poco creíble, pero es así.

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!