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.
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.
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.
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.
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.
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
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.
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.
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.
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%.
Esta entrada es más una anécdota recurrente, un toque de experiencia real, que una explicación técnica de nada.
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.
Volvemos con más material para Doom 3. Hoy, Classic Doom, la adaptación de Doom 1 (shareware) para el motor de Doom 3, además de algunos añadidos para acercarlo más a la experiencia del primer Doom.
En la entrada sobre Doom 3 vimos cómo instalar el juego base y la primera expansión ("Resurrection of Evil", RoE), además de hacer un par de mejoras gráficas.
Para los que, como yo, os quedasteis con ganas de más, aquí voy a explicar cómo instalar la expansión "The Lost Mission", originalmente sólo para la edición BFG del juego, ahora portada por unos modders al motor original.
Hoy toca una entrada de las que me gustan: Instalar, configurar y mejorar uno de mis juegos favoritos. El grandérrimo Doom 3.

Es una entrega muy diferente al resto de la saga, menos frenético y más orientado a la tensión y el horror.
En esta entrada veremos cómo instalarlo en Linux con las mejores prestaciones posibles.
Me he comprado un portátil de 8 pulgadas y es una pasada. Es como un libro de bolsillo, pero también es un PC completo que rinde sorprendentemente bien. Llevo un par de meses usándolo, le he "tomado las medidas" y quiero compartir la experiencia.
Le he llamado Deimos. El MiniPC del comedor es Phobos, y el día que me compre un equipo potente para juegos (si algún día lo hago) será Marte. Sí, soy un friki del Doom, qué le vamos a hacer. XD
Aquí estamos, casi 9 años después de la última entrada. Es lo que tiene dejar las cosas "para mañana". Pongámonos al día.
Pues que el grado de ASIR (Administración de Sistemas Informáticos en Red, un grado superior de formación profesional) me tuvo muy absorbido, terminando éste mi madre enfermó y murió, entré en depresión, tuve que ponerme a estudiar inglés (que no me gusta nada), lo que me llevó a una depresión más profunda, luego volví a mi antigua carrera (curso puente de Arquitectura Técnica a Grado en Edificación), lo que aún me sumió más en la depresión, terminando este curso mi padre también enfermó y murió, mientras le cuidaba empecé a sufrir graves ataques de ansiedad (desmayos incluidos), los papeles de la herencia fueron un caos, heredé más deudas que dinero, seguía sin trabajo, se juntó todo con el confinamiento por el covid, el estrés me llevó a problemas de convivencia con mi pareja, mi perro enfermó gravemente varias veces, uno de mis mejores amigos acabó en prisión... Vamos, una historia digna de un culebrón o de una novela existencialista.