Hay formas de conseguir que un servicio web se vea como una aplicación de escritorio, pero más que servicios web disfrazados de aplicación, algunas personas preferimos aplicaciones nativas. Y en el contexto de los modelos de lenguaje, cabe destacar Newelle. Con Newelle se puede acceder -desde una única aplicación- a multitud de modelos: los de OpenAI, Anthropic, Google o Mistral por ejemplo, así como a aquellos que se instalan localmente en nuestra computadora.
Cada proveedor tiene su propia oferta, con sus propios límites, políticas de datos y tarifas. En relación al precio, para la facturación sobre uso por API, GPT-6 Astra cuesta 10 euros por millón de tokens de entrada y 50 euros por millón de tokens de salida, por GPT-6 Sol OpenAI cobra 2 euros por millón de tokens de entrada y 10 por millón de salida... y por GPT-6 Luna se pagan apenas 10 céntimos por millón de tokens de entrada y 50 céntimos por millón de tokens salientes, datos referidos a contexto corto de modelos en tarifa estándar para desarrolladores.
Si usted opta por un modelo en instalación local, ha de saber que el coste de uso atribuido a las respuestas del modelo se reduce al precio del consumo eléctrico de su computadora y a la amortización de su equipo. Debo señalar aquí que los modelos locales, bien tienen capacidades limitadas o consumen desmesuradamente recursos de hardware. Así es. Usted puede disfrutar de un buen modelo de lenguaje ejecutado localmente en su máquina, pero necesita un equipo extremadamente sofisticado. Para hardware de prestaciones modestas, recomiendo usar LLMs de proveedores externos.
Para la pregunta sobre cómo de bueno es un modelo, no hay una respuesta única. Existen diversas métricas: MMLU mide conocimientos y resolución de preguntas en distintas materias, GPQA evalúa preguntas científicas difíciles, HumanEval prueba tareas de programación acotadas, mientras SWE‑bench mide la bondad en la resolución de problemas reales de desarrollo de software. Pero al final es usted quien tiene la última palabra, ya que nada puede sustituir a la experiencia personal de un usuario con el modelo de lenguaje de su proveedor.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
Me lancé a la aventura de instalar un sistema operativo estable, que estuviera bien actualizado y que diera pie al bricolaje. Elegí Arch Linux, pero me llevé una desagradable sorpresa al iniciarlo, pues durante el arranque, el sistema mostró un error: "Failed to start TPM MvPCR Product ID Measurement". Para quien todavía no lo sepa, el Trusted Platform Module (TPM) es una especie de "caja fuerte" donde se almacenan huellas digitales de lo que ocurre en el ordenador. Esa caja fuerte puede estar implementada como chip físico o como parte del firmware.
Dentro del TPM tenemos el Platform Configuration Register (PCR) y su versión no volátil, el NvPCR, donde se almacena una huella de algo que se midió, generalmente parte del arranque. Al iniciar la sesión, los PCRs usados para el arranque vuelven a empezar con las mediciones de esa sesión, casi siempre con la operación extend:
nuevovalor = hash(previovalor + nuevovalor)
Para empezar a investigar el problema, tenemos que consultar el estado del servicio systemd-pcrproduct.service y sus logs emitidos:
[user@localhost ~]$ systemctl status systemd-pcrproduct.service --no-pager
journalctl -b -u systemd-pcrproduct.service --no-pager
ls -l /dev/tpm*
× systemd-pcrproduct.service - TPM NvPCR Product ID Measurement
Loaded: loaded (/usr/lib/systemd/system/systemd-pcrproduct.service; static)
Active: failed (Result: exit-code) since Mon 2026-10-19 09:18:27 CEST; 25min ago
Invocation: d39c13610eed5e42bb5a3fd3dd50c97a
Docs: man:systemd-pcrproduct.service(8)
Process: 477 ExecStart=/usr/lib/systemd/systemd-pcrextend --graceful --product-id (code=exited, status=1/FAILURE)
Main PID: 477 (code=exited, status=1/FAILURE)
Mem peak: 2.2M
CPU: 13ms
localhost systemd[1]: Starting TPM NvPCR Product ID Measurement...
localhost systemd-pcrextend[477]: Could not extend NvPCR: No such file or directory
localhost systemd[1]: systemd-pcrproduct.service: Main process exited, code=exited, status=1/FAILURE
localhost systemd[1]: systemd-pcrproduct.service: Failed with result 'exit-code'.
localhost systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
localhost systemd[1]: Starting TPM NvPCR Product ID Measurement...
localhost systemd-pcrextend[321]: Could not extend NvPCR: No such file or directory
localhost systemd[1]: systemd-pcrproduct.service: Main process exited, code=exited, status=1/FAILURE
localhost systemd[1]: systemd-pcrproduct.service: Failed with result 'exit-code'.
localhost systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
localhost systemd[1]: Starting TPM NvPCR Product ID Measurement...
localhost systemd-pcrextend[477]: Could not extend NvPCR: No such file or directory
localhost systemd[1]: systemd-pcrproduct.service: Main process exited, code=exited, status=1/FAILURE
localhost systemd[1]: systemd-pcrproduct.service: Failed with result 'exit-code'.
localhost systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
crw-rw---- 1 tss root 10, 224 oct 19 09:18 /dev/tpm0
crw-rw---- 1 root tss 252, 65536 oct 19 09:18 /dev/tpmrm0
Revisando la información del cargador de arranque con sudo bootctl status, queda descartado cualquier problema relacionado con el arranque systemd-boot o la configuración de las imágenes UKI. El problema -como queda de manifiesto- es que systemd-pcrextend no encuentra el recurso o índice NvPCR que necesita para registrar el ID del producto. Este mensaje no significa que el TPM esté ausente, sino que no puede completar la medición del NvPCR:
Could not extend NvPCR: No such file or directory
Más adelante, los registros también muestran fallos relacionados con las mediciones NvPCR de usuarios y con la inicialización de índices NvPCR. El SRK -la clave raíz del almacenamiento TPM- ya está guardado, lo que falla es la inicialización de los NvPCRs, así que ya podemos empezar. Instalamos los paquetes que permiten consultar el TPM y generar imágenes UKI con utilidades de systemd:
sudo pacman -S tpm2-tools systemd-ukify
Creamos el archivo /etc/kernel/uki.conf con esta configuración:
Después, generamos el par de claves y reconstruimos las imágenes del kernel, con cuidado de mantener protegida la clave privada y no compartirla públicamente:
bootctl status indica que el TPM está disponible y está midiendo el UKI y el sistema operativo. Secure Boot sigue desactivado, pues la configuración de firma PCR del initrd no lo habilita automáticamente. El error de arranque queda resuelto en el sentido más práctico: el servicio funciona y systemd no muestra unidades fallidas. Sin embargo, NvPCR sigue sin inicializarse. La diferencia es que systemd ahora lo omite de forma controlada, en lugar de terminar con un error. Las claves UKI no crearon ni activaron el NvPCR. Configurar y firmar las mediciones PCR del initrd es una cosa, e inicializar el NvPCR es otra. La salida final confirma el comportamiento correcto del servicio, no que el NvPCR se haya provisionado.
Si ve el error "Failed to start TPM NvPCR Product ID Measurement" al arrancar su máquina, compruebe primero el servicio y las unidades fallidas. En mi equipo, después de configurar la firma PCR del initrd, regenerar el UKI, actualizar Arch y reiniciar, el servicio pasa a terminar con éxito y systemd deja de marcar unidades como fallidas. El NvPCR no queda inicializado, pero su ausencia no interrumpe el arranque, ni produce fallos en el servicio.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
En el día de tu cumpleaños, como tantas otras veces, quiero decirte que te quiero y que no sé vivir sin ti. Este año hemos tenido alegrías y preocupaciones. Con tus ánimos en los momentos difíciles hemos conseguido que Lara obtenga su plaza como anestesióloga en el Hospital de la Ribera a la vez que Susana daba un paso en su trabajo, pasando del Colegio de Turís al Instituto de Buñol. Detrás de esos logros hay esfuerzo, pero también una presencia que no podemos pasar por alto: la tuya. Gracias por tu apoyo. Gracias por creer en tus hij@s.
Mientras mis hermanas cristalizaban sus mayores sueños, tú has cuidado de Papá… como siempre. Y lo has hecho como solo tú sabes: con el cariño, la generosidad y la bondad que nos hace sentir querid@s. Y por si fuera poco, después de dos ictus y varias secuelas, sigues luchando por recuperarte y estar bien. Ojalá te mejores pronto. Mereces una temporada de tranquilidad y hoy queremos que disfrutes sin tener de qué preocuparte. Yo también he tenido que enfrentarme a mis propios problemas: dos tumores que me hacen llorar a diario y me recuerdan el tiempo que hemos pasado junt@s. Y sigo con los estudios de informática. Quedan cosas por resolver, pero hay motivos para la esperanza porque la esperanza eres tú y tú estás con nosotr@s. Alegre, afable, cariñosa, generosa, diligente y simpática. Tu sonrisa ilumina nuestros corazones. Así que en este día tan especial quiero decirte que esta casa no sería la misma sin ti.
Te he preparado unos regalos con los que te verás aún más guapa, más cómoda y más calentita. Pero el mejor regalo que te puedo hacer es nuestro tiempo compartido, así que ármate de paciencia porque voy a estar a tu lado siempre. ¡Siempre!Te quiero, Mamá.
Mamá en la Plaza Rodrigo Botet (Valencia). Elaboración propia (fotografía tomada en el año 2024).
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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.
No problem. Tim Richards. Interpretado por José Vicente del Valle Fayos.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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 γ 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 γ=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)=ax2+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:
63.52a+63.5b1272a+127b=75=127}
Que tiene como solución a=16129−46 y b=127173. La función que relaciona la entrada y la salida MIDI queda pues como sigue:
f(x)=−1612946x2+127173x
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.
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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?
En relación a la pregunta sobre quién pone el cascabel al gato, ruego no nos quedemos ahí. Preguntémonos también si poner cascabeles a los gatos está bien o si realmente queremos hacerlo y a qué precio.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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.
ago 12, 2026 12:35
Uno de los temas imprescindibles en el uso de controladores para la alimentación de software de modelado físico es la calibración. Durante las pruebas que he realizado personalmente a lo largo de la última semana con el StudioLogic SL88 MKII conectado a Modartt Pianoteq 9, he determinado nueve puntos que pertenecen a una curva polinomial de orden 2 bien ajustada. Esos nueve puntos, marcados en Pianoteq 9 y probados concienzudamente con el sonido del Steinway D New York, son los siguientes: {(0.000, 0.000), (15.875, 20.906), (31.750, 40.375), (47.625, 58.406), (63.500, 75.000), (79.375, 90.156), (95.250, 103.875), (111.125, 116.156), (127.000, 127.000)}.
En la práctica, deben definirse en un dominio e imagen discretos de 8 bits, lo que significa que es necesario redondearlos a sus valores enteros más cercanos. También quiero añadir que -para conseguir los resultados deseados- el controlador SL88 MKII debe tener su propia curva en modo "normal".
ago 12, 2026 13:35
La curva de velocidad estimada para ajustar el controlador SL88 MKII en modo normal cuando se conecta a Modartt Pianoteq 9 es:
f(x)=−1612946x2+127173x
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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.
Satin Doll. Duke Ellington y Billy Strayhorn. Interpretado por José Vicente del Valle Fayos.
jul 14, 2026 19:20
Hoy he sustituido la grabación de ayer por otra ligeramente mejor. Sin embargo, la ausencia de bajo y batería, así como la duración excesiva de algunas pausas, hacen que la interpretación no se perciba tan fluida como sería deseable. Además de eso, hubiera sido interesante incluir una improvisación y una coda.
A excepción de los instrumentos faltantes, estos días trabajaré en mejorar esos aspectos. Mi plan consiste en ensayar más y evitar así las pausas excesivas. También quiero desarrollar habilidades de improvisación basadas en el alcance -a través de cercamientos y pivotes- a las notas objetivo propias de la pieza, según su armonía. Podría, además, combinar esa técnica con el compado.
Una vez lo haya conseguido, el paso siguiente será la transposición de la pieza a todos los tonos y la inclusión de instrumentos faltantes con ayuda de la aplicación iReal Pro.
jul 17, 2026 19:45
La grabación está hecha con un Korg D1 conectado a un ordenador con un cable MIDI-USB. El sonido ha sido generado y grabado con el software Modartt Pianoteq 9.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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:
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:
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:
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.
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.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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.
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.
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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?
El compilador modificado introduce malware en programas concretos.
Cuando recompila su propio código fuente, vuelve a insertar la instrucción maliciosa.
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.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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íneadd# 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.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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:
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:
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:
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:
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:
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:
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:
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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:
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.
sept 26, 2026 19:15
Para corregir el error: Bluetooth: hci0: No support for _PRR ACPI method podemos descomprimir también el driver ibt-0040-2120.ddc con sudo unxz -f /usr/lib/firmware/intel/ibt-0040-2120.ddc.xz.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme:
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:
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):
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 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:
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 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.
Antes de continuar...
Detrás de cada artículo de Bitácora hay tiempo, investigación y desarrollo continuo. Si quiere ayudar a mantener este proyecto libre e independiente, apóyeme: