Tropezando - Parte 24 bib bis bis... y lo que te rondaré - Kubuntu 26.04 con PulseAudio

Parecía que PipeWire funcionaba en Kubuntu, pero al poco tiempo empecé a notar cosas raras otra vez: bloqueos de unas décimas de segundo del sistema completo cada vez que se quedaba el búfer vacío, ruidos extraños... La gota que colmó el vaso fue al conectar la tele por HDMI y no conseguir más que chirridos por esa salida, a pesar de que en mi escritorio también saco el sonido por HDMI y funciona bien.

Al final he conseguido un entorno estable con Wayland, Plasma y PulseAudio. Ésta es la cuarta y (espero) última entrada sobre esta migración.

Pataleando - Si funciona, no lo toques. Wayland, PipeWire, Snap, y GTK 3+.

Llevo algo más de 10 años sin quejarme de nada y se me han acumulado unas cuantas cosas que no me gustan, así que las he metido todas aquí, juntas y resumidas. Todas tienen algo en común: algún "corbata" decide que, por lo que sea, no le gusta lo que hay, otro "corbata" propone una alternativa muy bonita en teoría pero terrible en la práctica, un comité de "corbatas" decide que ése es el nuevo estándar y lo impone, las distros mayoritarias lo adoptan, las webs especializadas lo ensalzan (destacando sus supuestas ventajas y minimizando sus problemas) y de repente no se puede escapar de la nueva moda, te guste o no.

Tropezando - Parte 24 bis bis - Kubuntu 26.04

En las entradas anteriores (parte 24 y 24 bis) expliqué mis intentos de usar Wayland en mi equipo, incluyendo algunas concesiones (pasar de Cinnamon a Plasma, de Mint a KDE Neon) y no pocos problemas (Snap, PipeWire, dependencias...). No conseguí un sistema estable, así que he dado un paso atrás y he probado con otra distribución: Kubuntu 26.04.

Ésta será una entrada fea y aburrida. Solucionar un problema que no debería existir, causando otros problemas que tampoco deberían existir, hasta dar con una solución equivalente a derribar un edificio y construir otro nuevo porque el desagüe de la cocina se atasca. No hay interfaces bonitas, ni líneas de comandos, ni soluciones elegantes. No obstante, he conseguido que todo funcione por fin, y este blog es el sitio adecuado para explicarlo.

Tropezando - Parte 24 bis - PipeWire en KDE Neon

En la entrada anterior expliqué cómo y por qué instalar PulseAudio y dejar PipeWire anulado. Con PipeWire estaba sufriendo problemas con el sonido en varias aplicaciones: cortes, chasquidos, ruidos....
Al parecer, se debe a que por defecto se establece un búfer de audio muy pequeño para evitar latencias, y cuando el sistema está bajo una carga intensa, aunque sea puntual, ese búfer no puede mantenerse alimentado a tiempo, se queda temporalmente sin datos y empiezan los problemas. La solución es aumentar el tamaño de ese búfer creando un archivo de configuración con valores más conservadores.

Actualización: Después de unos días de uso, el sistema de audio seguía petardeando. Lo he resuelto usando otra distribución: https://nuevopinguino.blogspot.com/2026/07/tropezando-parte-24-bis-bis-kubuntu-2604.html

Tropezando - Parte 24 - Experimentos con KDE Plasma 6 y Wayland

 

Wayland ha roto muchas cosas. Todos los entornos de escritorio tiene que resignarse a cambiar o morir; algunos están tardando años, otros sufren muchos problemas, y demasiados no podrán hacer el cambio y desaparecerán. Por otro lado, Xorg está siendo abandonado por la industria: drivers pochos, gráficas que no rinden, distribuciones que ya ni lo incluyen... Es inevitable, y hay que adaptarse.

En mi caso, con mi hardware y mis manías personales, he tenido que hacer auténticos malabares para tenerlo funcionando, pero lo conseguí, sin problemas evidentes y con muy buen rendimiento. Pasen y vean mi primera aventura linuxera que publico en más de 9 años.

Ésta será una entrada larga, porque hay mucha tela que cortar. Aparte, contrariamente a mi filosofía habitual, usaré algunos comandos de consola.

 GNU/Linux 98, con tecnología de 2026.

Entrando en bucle 3 - Monitorización 1 - Log de temperaturas

En Linux, hay muchos parámetros del sistema que se pueden consultar tanto desde la terminal como desde aplicaciones gráficas: Temperaturas, memoria disponible, velocidad de la CPU, conexiones de red... Normalmente, cuando lo necesitamos, lo miramos en alguna aplicación y listo: Un monitor de recursos, un complemento en la barra de tareas o lo que sea. Casi nunca es necesario recurrir a la terminal para estas cosas.
Sin embargo, es muy útil poder hacerlo desde terminal para automatizarlo: Un comando personalizado que va creando un log a petición, un script en segundo plano que almacena cambios relevantes (P.Ej: un corte de red, un pico de temperatura...) con hora y fecha, uno que almacene periódicamente el valor de un sensor para crear una gráfica de temperaturas...
Hoy veremos cómo construir un script para monitorizar temperaturas en segundo plano mediante un archivo de log. Nos servirá para entender cómo se construye un script paso a paso, partiendo de comandos de consola y añadiendo funcionalidades poco a poco.
Se van a utilizar comandos como echo, sensors, grep, awk, sort, head, tail, while, if, getopts, tee, wc... además de algunos operadores y redirecciones, sin profundizar demasiado en ninguno.

Emulando - Dreamcast VMU con DreamPotato

Ah, la Dreamcast, el último sueño de Sega, mi querida blanquita... y su inseparables compañeras, las Visual Memory Unit, o VMU.

Hoy voy a tratar el emulador DreamPotato, que permite jugar, por ejemplo, al Pinta Quest del Skies of Arcadia, al Chao Adventure del Sonic Adventure y a cualquier otro minijuego, entre otras funciones.

 

Entrando en bucle 2 - Limitar el uso de CPU de un programa

NOTA: Ésta es la primera entrada "útil" de la serie. La he organizado con cada script partido en tres secciones: El script en sí para copiar y pegar, unas instrucciones de uso y, para los más curiosos, una explicación sobre cómo funcionan sus tripas. Al que no le interese la programación de scripts, puede saltarse la tercera sección. De todas formas, no es muy detallada: esto no es un curso de programación, ni pretende serlo.

Actualización a 2 de junio de 2026: Corregido un fallo en limitador.sh que impedía cargar un programa con parámetros (por ejemplo, el nombre de un archivo). Ahora funciona el "abrir con..." al seleccionar un archivo y que el programa lo cargue.

Hoy veremos dos pequeños scripts que sirven para lanzar un programa con el uso de CPU limitado a nuestra voluntad. Todo empezó porque estoy recodificando algunos vídeos para que ocupen menos espacio en mis discos. Es un proceso pesado que usa la CPU al 100% durante horas, dejando el ordenador prácticamente inutilizable mientras tanto. Se me ocurrió limitar la capacidad de proceso del programa de codificación para dejar recursos disponibles para poder navegar por Internet, ver una película o incluso jugar a algo ligero (ahora estoy repitiendo con el primer Half-Life) mientras va comprimiendo sin prisa pero sin pausa.

Handbrake limitado al 35% de CPU, dejando recursos disponibles para el resto del sistema, en un modesto N100. El porcentaje de uso real varia entre el 32% y el 38%. 

Sobre el script para Doom 3

Estoy teniendo problemas con el script multiusos para instalar y lanzar Doom 3: lo infravaloré, lo estructuré como un launcher básico, ha ido creciendo y ahora es absolutamente inmanejable. Pensaba haberlo terminado en un par de semanas, han pasado varios meses y cada vez avanza más y más despacio.

Esta entrada es más una anécdota recurrente, un toque de experiencia real, que una explicación técnica de nada.

Entrando en bucle 1 - Introducción

Hoy estrenamos nueva serie, en la que hablaré sobre scripts en Bash.

Los scripts son sencillos programas interpretados (no requieren compilación) que hacen, básicamente, lo mismo que puede hacer un usuario real en consola: llamar a un comando o un programa y decirle qué hacer. Además, el lenguaje permite cosas como saltos condicionales (si ocurre esto, haz esto otro), almacenar información en variables, leer y escribir archivos... lo que lo hace muy potente para automatizar tareas de todo tipo.

No es un curso de scripting: yo no soy programador ni pretendo serlo, y no tengo el nivel para dar lecciones a nadie. La serie va a tratar sobre algunos scripts que utilizo, que he creado y para qué sirven.
La primera mitad de cada artículo estará orientada a usuarios a los que les pueda resultar útil un script, que ni saben ni tienen por qué saber cómo funcionan las tripas de un programa, pero sí cómo usarlo. Vendrá una explicación de lo que hace el script, un enlace de descarga y una pequeña guía de uso.
En la segunda mitad intentaré explicar cómo funciona el script y cómo usar a mano cada una de las herramientas utilizadas en el script.

En esta primera entrada aún no veremos nada útil, pero sí una guía básica de algunas funciones muy usadas.