Bolly

Al buscar un texto en Firefox mediante Ctrl+F si no encuentra el texto buscado, Firefox reproduce un sonido bastante desagradable. Vamos a modificar eso para que reproduzca uno de nuestro sistema

En el navegador Firefox, mediante la combinación de teclas Ctrl+F nos abre una caja de búsqueda en la parte inferior, donde podemos introducir un texto y el navegador encontrará todas las ocurrencias que existan en la página web que esté mostrando, una herramienta que utilizo mucho y es muy útil.

Solo tengo un pero, cuando haces una búsqueda de un texto que no encuentra en la página web, además de una alerta visual en la propia caja de búsqueda, emite un ruido bastante desagradable y que suele pegarme unos sustos tremendos si tengo el equipo conectado al equipo de música.

Siempre había querido cambiar ese comportamiento, pero nunca me había puesto en serio a hacerlo. Hasta hoy. Así que si a ti también te molesta ese desagradable sonido, te cuento cómo lo cambié yo y si a ti también te puede servir.

En primer lugar aclarar que estoy en openSUSE Tumbleweed con Plasma de KDE como entorno de escritorio, por tanto si estás en otro escritorio u otra distribución de GNU/Linux u otro sistema, quizás tengas que adaptarlo a tus propias circunstancias. Te cuento…

Eliminar el sonido del efecto

Como muchas cosas en Firefox, se pueden configurar entrando en el apartado de about:config y modificando la variable adecuada. En este caso podemos eliminar ese molesto sonido poniendo a false la siguiente variable:

accessibility.typeaheadfind.enablesound

Ale, con eso ya no sonará nada, si es lo que quieres.

Modificar el sonido en Plasma de KDE

Pero en mi caso, no quería eliminar el sonido, simplemente cambiarlo por otro menos desagradable y en conjunción con mi escritorio.

En mi Plasma utilizo los efectos de sonido de ocean. Si vas a Preferencias del sistema de Plasma y a la sección sonidos del sistema, podrás configurar o comprobar cual utilizas.

Quiero modificar el sonido actual por otro que sea del propio sistema. La ruta donde se encuentran los sonidos es la siguiente:

/usr/share/sounds/ocean/stereo

De entre todos ellos he escogido el sonido dialog-information.oga. Así que entro en Firefox about:config y busco lo siguiente:

accessibility.typeaheadfind.soundURL

Y ahí le digo que utilice el archivo y la ruta que deseo, poniendo lo siguiente:

file:///usr/share/sounds/ocean/stereo/dialog-information.oga

Acepto y ya está cambiada dicha sonido, reproduciendo ahora un sonido que se integra con el escritorio y desde luego es menos desagradable que el anterior.

Si a ti también te molesta ese ruido predeterminado y lo quieres cambiar, sigue el tutorial adaptándolo a tu sistema y lo conseguirás. Esto es algo que quería hacer desde hace años y hoy me he puesto manos a la obra.

Enlaces de interés

• https://support.mozilla.org/en-US/questions/1310139

La entrada Tareas se publicó primero en Linux Hispano.

Cómo solucionar que Firefox muestre los caracteres en idioma japonés y también chinos y koreanos

Al navegar por la red con mi navegador Firefox, ya sea en la Wikipedia u otras páginas, que tengan caracteres o kanjis en japonés (y supongo que también en chino y koreano, aunque estos últimos no lo he comprobado), no se mostraban los propios caracteres y se mostraban unos pequeños cuadritos.

No es que si se muestran los caracteres, entendería lo que dicen, pero sí podría copiarlos y traducirlos con un traductor. Además de ser poco estético y dar la impresión de haber algo roto. Veamos cómo lo solucioné.

Cabe decir aquí que el problema no era de Firefox, el navegador simplemente no puede mostrar esos caracteres, porque no hay una fuente en el sistema que los proporcione, así que se muestran esos cuadritos que sustituyen los kanjis.

Buscando por la red, encontré un hilo en Reddit (he perdido el enlace) en el que mencionaban que el problema es de Plasma, y es que faltan las fuentes necesarias. En mi Tumbleweed con Plasma utilizo la fuente Noto Sans, no sé si con otras fuentes pasará lo mismo.

Para solucionar el problema tenía que instalar Noto Sans cjk (chinese, japanese, korean). Así que busqué en los repositorios algo con cjk y dio resultado. Tuve que instalar el siguiente paquete:

sudo zypper in google-noto-sans-cjk-fonts     

Finalizada la instalación ya se mostraban correctamente los caracteres. Para comprobarlo visité el siguiente enlace, que ahora se ve correctamente… (aunque siga sin entenderlo).

• https://blog.geeko.jp/

Veamos cómo podemos acceder al centro de control Cockpit en openSUSE desde otro equipo

Desde hace un tiempo estoy probando cockpit, el nuevo centro de control de openSUSE para gestionar el sistema. Aquí escribí cómo lo instalé:

• https://victorhckinthefreeworld.com/2026/04/22/probando-cockpit-el-sustituto-de-yast-en-opensuse-tumbleweed/

Uno de sus atractivos es el poder tener una interfaz gráfica para la gestión de servidores o equipos remotos directamente desde el navegador.

Cockpit de momento gestiona muchos aspectos del sistema en openSUSE, pero todavía no está preparado para sustituir por completo a YaST. Sin embargo algo atractivo es el poder acceder de manera remota mediante un navegador web al equipo en cuestión y gestionar mediante una interfaz gráfica ciertos aspectos del sistema remoto.

Veamos cómo poder acceder a cockpit en un equipo o servidor o servidor remoto.

Lo primero es habilitar en el cortafuegos el puerto 9090 por el que accedemos a cockpit. Vamos a habilitar el servicio desde el propio cockpit para ir familiarizándonos con la interfaz.

Habilitar el servicio cokpit en el cortafuegos

En el equipo accedemos a cockpit bien con el lanzador o en el navegador con localhost:9090, y nos registramos con acceso ilimitado.

Ahora en el menú de la izquierda seleccionamos el apartado Redes y ahora pulsamos sobre editar reglas y zonas. En la nueva pantalla pulsamos sobre el botón añadir servicios.

En la nueva pantalla en el cuadro de búsqueda introducimos el texto cockpit y lo seleccionamos y añadimos el servicio. También tenía abierto el puerto 22 de ssh y la clave de confianza. No sé si después es necesario reiniciar el equipo…

Esto también lo podemos hacer desde la terminal, tal como nos dice la documentación, ejecutando el siguiente comando:

sudo firewall-cmd --add-service=cockpit --permanent && sudo firewall-cmd --reload

Acceder en remoto

Ahora ya desde otro equipo en remoto podremos acceder al gestor cockpit introduciendo en el navegador la <dirección_IP>:9090. En mi caso, como está dentro de mi propia red local accedo mediante su IP local 192.168.1.42:9090 desde el navegador.

Al acceder me da una advertencia por el certificado de seguridad. Doy a avanzado y continuo aceptando el riesgo y ya tengo acceso a cockpit desde una máquina remota. Si el servidor estuviera fuera de nuestra red local estaría bien configurar un certificado válido para una conexión https.

Cuidado que teniendo acceso a cockpit en remoto hay acceso a muchas configuraciones. También tendremos acceso a un terminal dentro del propio cockpit, sin necesidad de acceder mediante ssh al equipo.

Cockpit facilita mucho la gestión remota de un sistema desde el navegador, algo especialmente útil para equipos en red local o pequeños servidores.

Eso sí, conviene no olvidar la seguridad: abrir el acceso implica exponer parte del sistema, por lo que es recomendable limitarlo a redes de confianza o reforzarlo con certificados y otras medidas adicionales.

Cockpit es la aplicación web que viene en openSUSE a reemplazar al veterano YaST. Veamos cómo gestionar los repositorios o instalar/desinstalar software con esta nueva herramienta.

Mediante cockpit, ahora en openSUSE desde un navegador web o una aplicación propia podrás gestionar y controlar todo tu sistema. Cockpit apunta a sustituir parte del uso de YaST, especialmente en administración remota y tareas comunes y desde hace un tiempo lo estoy probando y me gusta. Así lo instalé:

• https://victorhckinthefreeworld.com/2026/04/22/probando-cockpit-el-sustituto-de-yast-en-opensuse-tumbleweed/

Cockpit al igual que YaST es un software modular, es decir, tendrás diferentes módulos que se encarguen de diferentes áreas de tu sistema. Algunos serán comunes e imprescindibles y otros serán opcionales dependiendo de lo que controlen.

Algo imprescindible (bueno, no tanto, pero sí muy importante) son sus módulos para gestionar los repositorios y para instalar o desinstalar paquetes de software. Vamos a echarles un vistazo.

Cockpit forma parte de la nueva dirección de openSUSE para la administración del sistema, junto con Agama como instalador o Myrlyn como gestor específico de paquetes. Aunque YaST sigue disponible, su desarrollo es más limitado y progresivamente se están adoptando herramientas más modernas y especializadas.

A largo plazo, Cockpit está llamado a cubrir gran parte del uso cotidiano que tradicionalmente se hacía con YaST, especialmente en entornos de servidor. Y para gestión remota de equipos. Podremos acceder via mediante el navegador conociendo la IP a la configuración del equipo remoto con una interfaz web.

Una vez instalado cockpit, accedemos bien mediante la aplicación o directamente en el navegador mediante la url localhost:9090. Accedemos con nuestra cuenta root y le damos en la esquina superior derecha acceso ilimitado si no lo hemos hecho antes.

En la parte izquierda tendremos todos los módulos instalados de cockpit. Bajo la sección de Herramientas encontramos paquetes y repositorios.

Gestión de paquetes mediante cockpit

En la parte superior encontramos un campo de búsqueda y a la derecha un par de botones con las opciones Desinstalar / Instalar.

En el cuadro de búsqueda podremos meter un texto y buscar cierto paquete en concreto.

Si está seleccionada la opción Desinstalar, nos mostrará todos los paquetes que tenemos en nuestro sistema y que podremos seleccionar para eliminar del equipo. O si tiene actualizaciones disponibles.

Si seleccionamos instalar, podremos buscar un paquete en concreto e instalarlo mediante cockpit. Si tiene dependencias se mostrarán, junto con el tamaño total de lo que va a instalar y una opción de instalar lo seleccionado o de cancelar la acción.

Según tengo entendido cockpit, no utiliza directamente libzypp, si no que se apoya en PakageKit: Cockpit → PackageKit → libzypp → repositorios (RPM). Yo personalmente preferiría que detrás estuviera directamente libzypp.

Para un control más profundo de paquetes de software (marcar como tabú algún paquete, etc) zypper o Myrlyn siguen siendo las herramientas que hay que utilizar. Pero para una gestión básica con cockpit es suficiente.

Gestión de repositorios mediante cockpit

Mediante cockpit podremos añadir nuevos repositorios, o editar (parte) los que ya tenemos configurados.

En la lista de repositorios, podremos hacer clic sobre los tres puntos verticales de la derecha de cada repositorio para editar sus características o eliminarlo.

Podremos editar todos sus campos, excepto la url. Para eso último de nuevo deberemos hacerlo mediante zypper o Myrlyn.

También podremos añadir nuevos repositorios desde la interfaz web de cockpit.

Desde cockpit tendremos un control con una interfaz más moderna y accesible en remoto desde un navegador web a otros equipos o servidores. Para una gestión básica de ciertos aspectos, será suficiente. Pero cabe señalar que hay ciertos aspectos que todavía no están accesibles y que se deberá hacer mediante otras herramientas.

Y quizás te estés preguntando ¿Cuándo usar Cockpit?

• Cockpit: Para una gestión rápida y remota (aunque también se puede utilizar en una máquina local)
• zypper: Para un control total, que requiere el uso de la terminal, lo que puede «asustar» a usuarios recién llegados.
• Myrlyn: Una alternativa gráfica moderna más familiar a lo ya conocido con YaST y que sigue ofreciento bastante control al usuario.

PiApps es un script para instalar aplicaciones en Raspberry Pi OS adaptadas específicamente para este tipo de placas.

Es un buen complemento para completar la terna de instaladores con synaptic, para instalar software genérico de la familia Debian y RetroMultiInstaller, la colección de scripts para hacer triviales instalaciones complejas.

Si no lo tienes instalado lo puedes instalar desde el propio RetroMultiInstaller o manualmente tecleando estos comandos desde la consola de GNU/Linux:

sudo apt install curl
curl -fsSL https://raw.githubusercontent.com/Botspot/pi-apps/master/install | bash

Ahora tienes un nuevo acceso a PiApps en la categoría Accesorios del menú de aplicaciones.

También se crea un acceso en el escritorio, en este caso si hacemos doble clic nos aparece un aviso de que es una secuencia de órdenes, nosotros pulsamos ejecutar.

Cuando ejecutes el programa aparecerán las categorías en las que se clasifican, haciendo clic en cada una de ellas s aparecen los programas con una opción de 'Back' para volver al menú anterior.

Las aplicaciones instaladas aparecerán en un color verde, reconoce las que ya estaban instaladas con apt (todas las instaladas con synaptic y algunas con RMI)

Al hacer clic en un programa aparece la descripción del mismo ofreciendo la opción de instalarla o desinstalarla. 

Al pulsar Instalar se ejecuta el script personalizado de instalación. 

El problema de dobles escrituras

Vamos a plantear un escenario para ver el problema y conseguir una solución correcta que optimice tiempos y recursos.

Supongamos que hay un servidor en el que hay que extraer unos datos, generar un log especial o incluso un dump de memoria para depurar algo de ese servidor.

Puede ser que esos ficheros generados ocupen bastante o que incluso haya que llevarlos a otro sitio desde el que procesarlos o analizarlos, al que llamaremos destino

La primera idea que se nos puede ocurrir es crear los ficheros en el servidor y luego copiarlos al destino sin embargo esto no es una buena idea ya que hay varias cosas que nos van a ralentizar:

• Hay que esperar a que terminen de generarse los ficheros para luego copiar.
• Cuando se copian los ficheros se crea I/O de lectura local y de escritura en el destino.
• Estamos escribiendo 2 veces: la primera e local y la segunda en el destino.

El problema de los montajes y las latencias

Quizás la siguiente opción que podamos valorar es escribir en un recurso del servidor destino usando algun recursos compartido o algun tipo de montaje.

De nuevo tenemos un problema y es que los recursos compartidos (Samba/CIFS) o el montar un recurso remoto (nfs, sshfs) tienen una latencia.
Además de que necesitamos instalar y configurar un servicio, asegurarndonos de que está bien configurado.

Tunel SSH: una solución simple

Si nos vamos a llevar los ficheros a un equipo, podemos hacerlo mediante scp (copia sobre ssh), pero tenemos otra opción que es crear un tunel ssh y la transferencia se realiza en modo raw y ocupando el ancho de banda disponible de nuestra conexión.

La idea es que el servidor abre una conexión directa via SSH con el destino y en este servidor con los datos en crudo que le llegan los escribimos en un fichero.

Para la escritura de lo recibido por el tunel ssh, el servidor destino usará el comando dd para crear los ficheros finales.

comando (stdout) → túnel SSH → dd → fichero final en destino

a. Sintaxis básica:

comando | ssh usuario@destino "ssh of=/ruta/fichero"

La salida estandar ó stdout de la ejecución del comando se mete en una tubería (pipe) y mediante ssh lo llevamos al servidor destino. Allí mediante el programa dd lo escribimos mediante el parametro of al fichero de destino que queremos.

b. Sintaxis mejorada:

comando | ssh -o Compression=no usuario@destino "ssh of=/ruta/fichero bs=8M status=progress"

Ejemplo sencillo:

cat fichero.zip | ssh -o Compression=no usuario@destino "ssh of=/tmp/fichero.zip bs=8M status=progress"

Lo que estamos haciendo es lo siguiente:
Volcamos el contenido de fichero.zip a la pantalla (stdout) pero con el pipe lo capturamos y lo enviamos con ssh al servidor destino, en el servidor destino se ejecut el comando que tenemos entre comillas. En el comando dd indicamos la ruta y nombre del fichero a escribir y ademas incluimos el parámetro bs para volcar y escribir los bloques recibidos de 8 en 8 Mb, y además con status vemos el progreso y tiempos de escritura.

Este proceso se realiza facilmente para cualquier comando que pueda sacar a "pantalla" su ejecución o usar un parámetro que permita redirigir a pantalla su salida.

Programas sin uso de stdout

Hay programas que por su construcción no tienen la opción de sacar su salida por pantalla y solo permiten escribir a un fichero.

Por suerte en Linux todo se maneja como ficheros y podemos hacer que todo termine en donde deseemos.

En nuestro caso hay un fichero especial en el sistema: /proc/self/fd/1 que es la salidad estandard que usaremos si nos solicitan el nombre de fichero.

Prueba el siguiente comando en tu equipo GNU/Linux para comprobar que funciona:

echo "Escribiendo en la pantalla" > /proc/self/fd/1

Verás que se muestra el mensaje directamente en pantalla.

El comando que necesites ejecutar y que no pueda escribir en pantalla habría que indicarle que use como fichero /proc/self/fd/1 para que funcione el tunel ssh.

Sistema de ficheros virtual

Para este truco es utiliza el sistema de archivos virtual /proc que apunta a los ficheros actules en ejecución self y a los descriptores de ficheros.
Los descriptores de ficheros disponibles son el 0, 1 y 2 y se corresponden con los que use tu terminal o terminal virtual actual.

• /proc/self/fd/0 Entrada estándar ó stdin
• /proc/self/fd/1 Salida estándar o stdout
• /proc/self/fd/2 Salida de error ó stderr