Solucionando problemas en Chakra

Con la última, ya enésima, re-instalación de mi sistema operativo GNU/Linux favorito me he topado con algunos problemillas, tanto ya conocidos como de nueva aparición. Los hay que son meras incomodidades, con las que se puede convivir sin más, mientras que otros te pueden dar al traste con la experiencia de uso del equipo. Sean de una clase o de otra, todas han encontrado solución con algo de paciencia y dedicación. Estas son las pequeñas cosas que, dependiendo de tu estado de ánimo y tu predisposición al aprendizaje en cada momento pueden hacer que te alejes de GNU/Linux si no dispones de tiempo o ganas. Cuando no es el caso, ocurre lo contrario y… habemus tutorial.

Partimos de un sistema Chakra GNU/Linux Curie recién instalado en mi archiconocido equipo doméstico de sobremesa. Tras los pasos de rigor en toda instalación, me dirijo a mi propio tutorial de puesta a punto e instalo todo lo necesario para mi desempeño informático diario. Cuando ya esta todo listo, comienza la resolución de problemas, que paso a desglosar punto por punto.

La impresora HP Laserjet 1018 no imprime
Hace unos meses que tuve que prescindir de mi vetusta Epson Stylus Color 680, pues la impresión dejaba ya mucho que desear (líneas por todas partes, letras y fotografías mal alineadas…), algo lógico al tratarse de un modelo con 14 años a sus espaldas. Recuperé para su uso en casa una HP Laserjet 1018, impresora láser monocromo, que solía utilizar en el negocio de hostelería de mi familia política y que últimamente no tenía ya apenas utilidad (sí, lo habéis adivinado, la crisis estafa haciendo estragos).

Ya sabía, por experiencia, que este tipo de impresora precisa de un «plugin» propietario de HP para funcionar en GNU/Linux, algo que se instala automáticamente en distros más amigables, como Ubuntu. También sabía que este «plugin» da problemas en Arch y derivadas, siendo la alternativa más simple la instalación de los controladores foo2zjs, disponibles en CCR para Chakra y en AUR para Arch, Manjaro y demás. Por desgracia, los turbulentos momentos por los que atraviesa Chakra tienen la desagradable consecuencia de que CCR no sea un prioridad, sobre todo cuando hablamos de paquetes mantenidos por usuarios que son, a la vez, desarrolladores importantes de la distribución, caso del que nos ocupa. La instalación desde CCR, como podéis suponer por lo ya comentado, falló estrepitosamente.

Dado que dicho desarrollador, responsable de la paquetería del repositorio [core], probablemente tendría cosas más importantes de las que ocuparse en este momento, decidí arreglar yo mismo el desaguisado, empleando para ello otro de mis tutoriales de cosecha propia: el de importación de paquetes de AUR a CCR. Eso sí, dichos paquetes se quedarían en mi equipo sin ser subidos, algo que no es posible hacer cuando ya existe el mismo paquete, para evitar la duplicidad de los programas.

La operación tampoco tuvo éxito, algún tipo de incompatibilidad impedía la instalación del paquete en mi sistema, de manera que hube de acudir a los creadores del controlador, quienes, curiosamente, en su página desaconsejan la instalación de los paquetes pre-compilados para la gran mayoría de distribuciones. Siguiendo las instrucciones que allí se dan conseguí instalar el controlador foo2zjs. Pero… Tras intentar instalar la impresora con el módulo correspondiente de KDE y con la interfaz web de CUPS, me encontré con que, efectivamente se instalaba, pero no imprimía. El mensaje de error «Filter failed» («falló el filtro») era lo único que obtenía.

Llegó entonces el turno de Duck Duck Go, logrando hallar, tras varios intentos, la raíz del problema en la madre de todas las wikis: la de Arch. Se trataba de un problema de permisos en el puerto USB, subsanado completamente gracias a la información allí encontrada. Uno, que ha sido usuario de Arch y de Chakra durante la mayor parte de su tiempo en GNU/Linux, siempre estará en deuda con esta wiki y su inconmensurable aportación al software libre. Gracias, Arch.

Mejorando el «scrolling» en Firefox
Lo mencionaba como uno de las diferencias más notables entre Windows y GNU/Linux en mi artículo de pseudo-despedida. Lo corroboraba el comentario de otro sufridor de AMD/ATI en GNU/Linux, INDX (Juan Martínez). Pero en lo que ambos estábamos equivocados era en atribuir el problema a los deficientes controladores gráficos de dicha empresa para GNU/Linux. O no… En mi actual instalación de Chakra uso los controladores propietarios Catalyst, por si alguien se lo estaba preguntando.

Pues bien, me atrevo a afirmar, por fin, que he equiparado la rapidez del «scrolling» de la rueda del ratón en Windows y en Chakra, con dos sencillos pasos:

1 – En el módulo de Configuración del sistema de KDE –> Dispositivos de entrada –> Ratón, pestaña Avanzado, apartado «La rueda del ratón desplaza». Ahí ponemos el valor máximo, que son 12 líneas.

2 – En Firefox, abrimos «about:config» y buscamos la expresión «mousewheel.min_line_scroll_amount», sustituyendo el valor asignado (creo que era 5), por un valor mucho mayor, sobre 50 ó 60, dependiendo de los gustos de cada cual.

Salimos y volvemos a entrar en Firefox y… voilá, el «scroll» es muchísimo más rápido, a la altura del de Windows. Ignoro el motivo, pero en la versión de Firefox para el sistema de Microsoft, el valor asignado a la expresión vista arriba es 5. Sin embargo, el «scrolling» va perfecto con ese valor en Windows. Misterios insondables, o tal vez, Juan y yo no íbamos tan desencaminados y el controlador gráfico tiene algo que ver… Si algún lector puede arrojar luz sobre el asunto, se lo agradecería.

Por cierto, la elección de la web de un conocido periódico para la demostración obedece únicamente a razones de «carga» de la misma, pues contiene gran cantidad de material en Flash y vídeos que suelen hacer más lenta la navegación.

Actualización (26/11/14): gracias al comentario del usuario Aguzth en otro artículo, sabemos que se puede mejorar aún más el «scrolling» cambiando el valor del parámetro «mousewheel.acceleration.start» de -1 a 0.

Acabando con las congelaciones de Plasma
Otro de mis caballos de batalla, que incluso un día me condujo a llegar tarde a recoger a mi hijo, como contaba en su momento, y finalmente a la decisión de dejar nuevamente de usar Chakra en favor de Ubuntu. En esta nueva instalación, el problema se seguía reproduciendo e incluso diría que era más frecuente su aparición: de buenas a primeras, sin estar haciendo nada especial, la barra de tareas y el espacio de trabajo de Plasma quedaban congelados. Podía abrir una sesión en terminal con CTRL+Fn, podía incluso cambiar de ventana con ALT+TAB, pero todo lo demás no funcionaba.

En aquel fatídico día en que el reloj de KDE me llevó a engaño, como suele ser habitual en mí, el cabreo me impedía pensar e investigar, y mi único objetivo era dejar atrás los errores y arramplar con todo lo que tuviese que ver con la distro y el escritorio en cuestión. Si hubiera contado hasta diez e indagado un poco, se me habría presentado la ocasión de acabar con el molesto problema, cuyo origen estaba en el plasmoide de NetworkManager. Llegué a esta conclusión tras encontrar varios hilos en foros diversos de varias distribuciones (openSUSE, Kubuntu, Arch, Debian) con errores similares que no encontraban solución. Alguien, en uno de dichos hilos, proponía a los plasmoides como fuente del problema y daba como remedio un ejercicio concreto: desactivarlos todos e ir activándolos uno por uno hasta dar con el que provocaba el comportamiento errático en KDE.

Y a la primera fue la vencida. Tras sustituir NetworkManager por Wicd, siguiendo las instrucciones de la wiki de Chakra, se acabaron las congelaciones de KDE de una vez por todas. Por fin puedo fiarme del reloj…

KDE lento al copiar archivos grandes a pendrive
Este problema no me lo había encontrado anteriormente, pues tenía costumbre de hacer «streaming» desde el equipo de sobremesa al portátil para ver los episodios de mis series favoritas en el salón. Recientemente cambié de proveedor de Internet, y el Livebox de Orange provocaba molestos cortes durante el «streaming», de modo que tuve que optar por pasar los ficheros a mi pendrive y de ahí llevarlos al portátil.

En Windows, todo hay que decirlo, cero problemas. Fue al intentar hacer la copia de archivos de casi 4 Gb de tamaño a mi pendrive en Chakra cuando noté que todo el escritorio se enlentecía (el ratón se movía como a saltos) y el uso del procesador se disparaba a casi el 100%. A la vez que esto ocurría, la tasa de transferencia decaía sin parar hasta hacerse inviable la copia (menos de 100 Kb por segundo). En los foros de Arch aportaban una solución que me sirvió una vez, pero no las sucesivas. Finalmente, con la calma que da disponer de una partición de Windows para hacer la copia (cualquiera se pone a buscar la solución a las tantas de la noche mientras la señora se impacienta en el salón…) y poder así investigar con tranquilidad en otro momento, encontré una causa y la forma de subsanarlo en el foro de PCLinuxOS. Deshabilitando el modo «USB Legacy» en la BIOS dije adiós al problema. Lo malo es que al deshabilitar dicho modo me quedé sin la posibilidad de usar el teclado antes de iniciar el sistema, lo cual se traduce en que no se puede entrar en la BIOS ni elegir nada en Grub. Por si a alguien le ocurre, se soluciona quitando la batería de la placa base durante un minuto más o menos, con el equipo desconectado de la corriente para resetear la BIOS. Si no sois muy duchos en esto de toquetear la BIOS, tened cuidado de no equivocaros en la elección.

Aparte del fastidio que supone no poder usar el teclado hasta haber entrado en el sistema, noté que el ahorro de energía del monitor no se activaba. Ni idea de qué tiene que ver esto con el USB Legacy, pero cuando reseteé la BIOS volvió a funcionar.

Total que, puestos a elegir, decidí seguir con la investigación.Y hete aquí que la sapiencia y el espíritu comunitario de Gregorio Espadas me dieron por fin la ansiada solución, en un artículo de su blog. Bastaba añadir al primer paso que yo describía (el mencionado en la wiki de Arch), un segundo (editando un fichero de configuración con parámetros del kernel). Mano de santo, oigan. No solo se estabilizó la velocidad de transferencia de principio a fin en torno a los 7 Mb por segundo, sino que desapareció completamente la lentitud y los «lags» de respuesta del ratón. Por segunda vez, gracias Arch. Y, por supuesto, gracias maestro Espadas.

Firefox no tematizado al abrir desde gmail-plasmoid
Si bien todo lo anteriormente relatado puede ser útil a usuarios de cualquier distribución con KDE, sospecho que esta última solución solamente se aplica a Chakra. Hace mucho que utilizo el plasmoide de Gmail de KDE para la notificación y apertura de correos electrónicos. Dentro de la configuración del plasmoide se puede elegir la acción a realizar cuando se hace clic con el ratón sobre él, que en mi caso se trata de abrir el navegador Firefox con la bandeja de entrada de mi cuenta, ya que no uso clientes de correo. Siempre me ocurría que, si no estaba abierto el navegador, al abrirlo a través del plasmoide aparecía sin el tema oxygen-gtk, con un horrible «look» a lo Windows 95. No era un problema molesto, bastaba abrir normalmente Firefox y luego hacer clic en el plasmoide para que la pestaña con la bandeja de entrada tuviera la apariencia normal.

La solución, hallada investigando por mi cuenta con los enlaces de KDE, pasa por sustituir la orden de apertura del navegador en la configuración del plasmoide: en lugar de «firefox %u», utilizar la expresión «xdg-open %u». De este modo, el plasmoide abre el navegador por defecto que hayamos indicado en las preferencias de KDE, y lo abre tematizado, como debe ser.

Resumiendo, que es gerundio
Para quienes no deseen tomarse la molestia de leer el tocho previo, hago un breve resumen de cada problema y su solución propuesta:

Problema: HP Laserjet 1018 no imprime, mensaje «Filter failed».
Solución: instalar los controladores foo2zjs y dar permisos al puerto USB.

Problema: «scrolling» lento en Firefox.
Solución: ampliar las líneas que desplaza la rueda del ratón en KDE y en el módulo de configuración de Firefox (about:config).

Problema: KDE se congela.
Solución: desinstalar el plasmoide NetworkManager y usar Wicd.

Problema: KDE lento al copiar archivos a pendrive o USB externo.
Solución:  el maestro Gregorio Espadas la cuenta aquí.

Problema: Firefox no tematizado si se abre desde gmail-plasmoid.
Solución: usar la expresión «xdg-open %u» en lugar de «firefox %u».

¿Qué he aprendido con todo esto? Que cuando algo falla en GNU/Linux tiene arreglo. Lo que no puede ser, y me ha pasado cientos de veces ya, es pretender que se arregle rápido, a lo loco, sin investigar ni documentarse, sin leer o preocuparse por preguntar. Las prisas no son buenas consejeras, y este es un ejemplo más. Mi recomendación, que cobra especial relevancia en el caso de que se use una distribución «rolling-release», es disponer de algún sistema estable en el equipo, donde todo funcione, para pasar el apuro que pueda surgir. Luego, con calma y ganas de aprender, todo – o casi todo – se puede solucionar. Que dicho sistema estable sea un Windows, un Mac o un Debian Stable, ya dependerá de cada cual.

Espero que este artículo pueda servir de ayuda a quien aquí llegue buscando arreglo a su problema. Un saludo para todos.