Un año y medio en informática es muchísimo tiempo y, más si cabe, si hablamos de la evolución de escritorio de las distribuciones Linux. Desde mediados del año 2007, en el que me instalé
Fedora Core 7, tan sólo había renovado el sistema con las actualizaciones de seguridad de la versión. Por fin, estas navidades, aprovechando el tiempo libre, me decidí a hacer un
upgrade de la distribución.
Primera desilusión
Fedora, que está basada en
Red Hat, tiene
yum como gestor de paquetes. Podríamos decir que
yum es a Fedora como
apt es a
Debian: la herramienta que permite instalar lo que necesitas sin preocuparte por las (odiosas, en algunos casos) dependencias.
Una de las opciones que tiene
yum, es actualizar el sistema entero a través del modificador
upgrade. Al menos, eso era lo que creía. Siempre que ejecutaba el comando en cuestión, llegaba al mismo problema irresoluble de dependencias conflictivas. ¿No se suponía que esta herramienta era, precisamente, la indicada para no tratar nunca más con semejantes problemas? Pues no hubo manera, aún cuando, en un intento desesperado, le cambié las direcciones de los repositorios para apuntar a las versiones más modernas (e inestables) de dichos repositorios.
El único camino posible
La única alternativa viable era iniciar una instalación/actualización desde un
CD de la nueva versión. Para ello, aprovechando la
magnífica
banda ancha de la que disponemos en España, me descargué la
ISO más pequeña, que instala todos los componentes desde los repositorios de Internet.
Para que este método funcione, por precaución, siempre es conveniente seguir estas 2 normas:
- Tener los datos de los usuarios (
/home) en una partición diferente a la del sistema. (Actualmente, casi todas las distribuciones Linux respetan esta norma y no hay que preocuparse por ello.) - Hacer una copia de seguridad de los datos, en otro disco duro independiente al del sistema (o en un DVD, si cabe).
Primer arranque tras la instalación
Antes de comenzar con los
problemillas
que encontré tras la actualización de Fedora, un comentario sobre el proceso de instalación: el asistente de instalación a través de red es verdaderamente simple, pero casi demasiado escueto en información sobre el proceso (cada vez se parece más a la filosofía de Windows, ocultando el máximo de información...).
Ahora, empecemos con lo bueno. El proceso de arranque de esta versión 10 es muchísimo más simplista que el de la 7 (está visto que hay que parecerse al sistema de
ventanas como sea...). Mi anterior sistema estaba preparado para
entrar en modo gráfico tras el arranque, pero tras el
upgrade... este último paso, falló. Al menos tenía acceso al sistema desde la consola de texto. También tenía acceso a Internet para buscar soluciones, pero... sin modo gráfico... ¿cómo continuar?
Había una alternativa de primeros auxilios, y otra un poco más... ¿cómo decirlo?, de chico con recursos. La primera consistía en instalar (en modo texto) un navegador en modo texto, como
lynx o
links. La segunda, por la que opté, era utilizar otro ordenador para conectarme a Internet en busca de información. Para ello, me agencié un
Acer Aspire One con Linux preinstalado (una distro llamada
Linpus que está basada en Fedora) y procedí a solventar mi contratiempo.
En uno de los foros donde recalé, indicaban que buscara más detalles sobre el problema en el fichero
/var/log/Xorg.0.log. Editándolo, pude ver al final del mismo, estas líneas:
(EE) No devices detected
Fatal server error:
No screens found
Increible, pero cierto. Hasta hace unos minutos había tenido mi
servidor X funcionando a la perfección, pero el proceso de actualización había sido incapaz de reconocer mi tarjeta gráfica (pese a que todo el procedimiento se había llevado a a cabo en modo gráfico).
Por suerte, existía una solución: ejecutar en modo root el siguiente comando (habiendo realizado antes una copia del fichero
/etc/X11/xorg.conf, por si acaso):
# system-config-display
Tras reiniciar el equipo, la secuencia de arranque se completó hasta el final correctamente, pero... siguieron las sorpresas.
Nueva versión de KDE
Una especie de
déjà vu recorrió mi mente la primera vez que vi arrancar el escritorio
KDE. Parecía que estaba viendo el escritorio de
XP: limpio como una patena, sin ningún icono ni documento a la vista. ¿Quién se había llevado mis
lanzadores de aplicaciones y archivos?
Hasta entonces, KDE (versión 3.5), siempre me había parecido un entorno muy amigable (aunque tal vez, demasiado parecido al de Windows), pero la desaparición de iconos del escritorio (en esta versión 4.1) ya me parecía un toque de mimetismo demasiado... cruel. Así pues empecé a investigar por el nuevo sistema, por si era una opción de configuración (como en su
alter ego). Después de un rato de no encontrar nada, pasé la búsqueda al ámbito de Internet. Tan sólo extraje como conclusiones que
KDE reinventaba el escritorio y que la documentación oficial sobre
Plasma (que así se llama ahora la aplicación que lo controla) está un
poco verde todavía.
Lo que parecía claro, es que el directorio
/home/mi_usuario/Escritorio no era lo que estaba viendo en pantalla y que, ahora, no se creaban lanzadores, sino
applets (incluso se pueden utilizar los de Mac OS X),
widgets y
plasmoids.
¿Dónde estaba el explorador de archivos?
Eso es lo que me pregunté cuando intenté ver el contenido del disco duro. Ni rastro de
Konqueror, ni de su sustituto en esta versión:
Dolphin. Tampoco encontré el programa de terminal de KDE:
Konsole. Ni siquiera estaba el editor de textos sencillo, el programa
KWrite.
Una vez más, eché mano de Internet a través de mi flamante nueva versión de Firefox (¡por fin podía disfrutar de la versión 3!). Llegué a una página donde podía buscar programas de Fedora, y me devolvía
información sobre el desarrollo (código fuente) de la herramienta. De esta forma, pude encontrar la clave de la cuestión: todos los programas que echaba en falta, estaban dentro de un paquete llamado
kdebase. Cuando busqué ese paquete en mi sistema (
rpm -qa | grep kdebase), comprobé que, efectivamente, no estaba... el de la versión 4. Sí que seguía estando el correspodiente paquete para la versión 3. Entonces, ¿por qué no se había actualizado?
La herramienta
yum, cuando actualiza paquetes, se fija en el nombre de los mismos. El formato de los nombres de los paquetes es como sigue:
nombre-versión-release.arquitectura.rpm
Resumiendo, que si el nombre no coincide,
yum no actualiza. Eso es lo que había pasado en mi caso. El paquete, para KDE 3.5, se llamaba
kdebase3, y, para la versión 4, el nombre había cambiado a, simplemente,
kdebase.
Instalando manualmente el paquete (
yum install kdebase), tuve de nuevo todos mis programas.
Inconvenientes con las codificaciones de archivos
Ni la nueva versión de Konqueror, ni el nuevo Dolphin, entendían algunos de los nombres de mis antiguos archivos: aquellos que estaban en una codificación distinta a
UTF-8. Ni siquiera me dejaban, ninguno de los 2 exploradores de archivos, renombrar los ficheros de la discordia. Solución: hacerlo manualmente desde la línea de comando.
Esto, en cuanto a nombres se refiere. Pero el contenido de mis archivos de texto (abiertos con KWrite), en
codificación ISO-8859-1, tampoco se salvaba de la quema. Como ya he dicho, ahora todos los programas en Linux, trabajan con UTF-8 por defecto, y cada vez va siendo más complicado cambiar este comportamiento. En KWrite, versión para KDE 3.5, existía un menú de la aplicación, donde se podía cambiar fácilmente el modo de la codificación, pero en la nueva versión, está algo más escondido. Más exáctamente, está en:
Settings,
Configure editor...,
Open/save,
General, opción
Encoding autodetection. Es necesario poner el valor
western european para ver correctamente el contenido de los archivos generados en
ISO Latin 1.
Los nombres de las opciones de la aplicación los pongo en inglés, porque el instalador no me puso el paquete de español para KDE. Tal vez pase algo parecido que en el caso del paquete
kdebase, pero la verdad es que el cambio de idioma no me afecta tanto como el perder programas.
Conclusiones
Seguro que me dejo de comentar más pequeñas pegas pero, por el momento, tan sólo comentaré una más: el directorio
/sbin ya no está en el
PATH del usuario
root. Aunque solucionarlo es sencillo (añadirlo en el archivo
.bash_profile del usuario, por ejemplo), no dejó de resultarme curioso que antes estuviera y ahora no.
La pregunta que me hago es si los problemillas que me han surgido en la actualización, también hubieran ocurrido en una instalación limpia. Por lo demás, con la nueva versión, el ordenador ha mejorado en rendimiento y la respuesta al usuario de los programas es más ligera que antes. Así que, pese a todo, el cambio ha sido para mejor.
En todo cambio, mudanza, innovación... hay pérdidas. Unas veces reales y tangibles, otras veces en comodidad. Pero si hay una cosa que he aprendido en este año que termina es que si no te atreves a cambiar, no hay posibilidad de mejorar y de aprender cosas nuevas.
Actualización (2009-01-14):Como me temía, que KDE 4 estuviera en inglés en lugar de en español, era debido al cambio de nombre del paquete de internacionalización. En la versión 3.5 se llama
kde-i18n-Spanish y, en la versión 4.1, pasa a ser
kde-l10n-Spanish. Instalando el nuevo paquete y configurando el idioma en las preferencias del sistema (
Systems Settings,
Country & Language), el tema queda solucionado.
