Emulando - PSP parte 3: diez años después

Si en el pasado experimentamos con la emulación de PSP (nativo y bajo Wine), con no pocos problemas, a día de hoy las cosas han cambiado bastante, así que toca una entrada actualizada.

Vamos a emular PSP usando el mismo emulador, el excelente PPSSPP, pero en versión nativa y paquete AppImage, que debería funcionar en cualquier Linux moderno sin instalar nada.

 

En el pequeño Deimos, puedo disfrutar todo el catálogo de juegos en alta resolución a 60fps estables sin apenas generar calor, e incluso he metido texturas HD a algún juego y lo mueve como si nada.

Entrada de mantenimiento

Hace meses que no escribo porque no he tenido nada relevante que escribir. Esta entrada es sólo para no dejar el blog abandonado otra vez, y para recopilar las pequeñas cosas que he ido viendo pero que, a mi entender, no merecen una entrada propia.

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 tienen 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%.