Impresiones sobre Mandriva One 2008 RC2

Al fin tuve tiempo de probar alguna de las versiones preliminares de Mandriva 2008, así que aquí (en un señor ladrillo :P ) dejo mis impresiones, bugs y demás. La versión en cuestión que probé es Mandriva One 2008 RC 2.

En general, he de decir que no me dejó muy buen sabor de boca. Pero no por problemas grandes, sino por "pequeñas" cuestiones (en su mayoría) que deslucen el resultado final. Y porque no estoy en absoluto de acuerdo con una de las principales novedades que Mandriva 2008 ofrece a simple vista (el cambio en la organización del menú).

El primer problema es que, pese a ser la versión One, no incluye los drivers propietarios de NVidia ni ATI. No es un problema muy grande, siempre y cuando se solucione para la versión final, aunque me impide verificar (al menos de entrada) que no hubiese ninguna regresión en la detección de la tarjeta, como le sucedió a Pealfa. El problema de la falta de drivers puede verse en el wiki, está reportado en Kernel modules for ATI and NVIDIA proprietary drivers missing from 2008 RC2 One y puede votarse en Votar bug 33992. Solucionado :)

La siguiente cuestión que no me parece acertada es no incluir el applet del paginador en Kicker por defecto, aún cuando existen 4 escritorios virtuales. Por supuesto el paginador puede añadirse manualmente, pero sería mejor que por defecto ya se pudiesen usar los 4 escritorios virtuales que trae configurados. Yo eliminaría el applet de los botones de bloqueo/salida e incluiría el del paginador, configurado para usar 2 filas de modo que ocupase poco espacio. El bug puede verse aquí Kicker should have pager applet added by default y votarse en Votar bug 34099. Solucionado :)

A continuación, pruebo la nueva funcionalidad (muy acertada) que permite cambiar el icono del menú entre el de Mandriva y el de KDE, y el tipo de menú entre el normal y Kickoff. Aparece un fallo no relacionado realmente con dicha funcionalidad, que por el número del bug ya viene de antiguo: al recargar Kicker, el icono de net_applet en la bandeja del sistema desaparece. El bug en cuestión es net_applet disappear from system tray when task bar is reloaded y puede votarse en Votar bug 11665.

El cambio entre el icono de Mandriva y el de KDE cuando se usa el menú estándar de KDE funciona bien, al menos que yo haya podido ver. Sin embargo, cuando Kickoff entra en juego aparecen algunos problemas.

Por un lado, el icono de KDE cuando se usa Kickoff tiene el mismo tamaño que el de Mandriva. La única diferencia es que no tiene el texto Menú, por lo que si lo que se busca al dar la opción de usar el botón de KDE es un icono más compacto, esto no sirve de nada.

El otro "problema" (meramente estético, pero que no causa una buena impresión), es que cuando se cambia entre un icono y otro, o se pasa el estilo de menú de KDE a Kickoff, el icono es, aproximadamente, un tercio de ancho y largo de su tamaño normal, y se encuentra centrado y alineado con la parte superior de la barra. Al pasar el ratón por encima, recobra su tamaño y posición adecuada.

Algo similar ocurre cuando se cambia el tamaño de Kicker, o cuando se cambia su orientación. La imagen aparece en un tamaño que no debe, y vuelve al tamaño normal cuando se pasa el ratón por encima.

Algunos problemas más se dan cuando Kicker está en los laterales del escritorio, como se describe en el comentario 25 de Mandriva start menu button for KDE is too long, takes up too much space.

Siguiendo con el menú, la nueva organización de las aplicaciones en él me parece nefasta. Nunca me gustó el estilo de menú Discovery, y me parecía una mala decisión ponerlo por defecto en lugar del de Mandriva, que siempre consideré mucho más claro y organizado. Pero es que éste es una especie de refrito del Discovery y el de KDE, ¡y encima no se puede poner el de Mandriva de toda la vida!.

Parece ser que la idea del cambio de organización era eliminar el anidamiento de los menús. Y eso es justamente lo que a mí me gustaba. Las aplicaciones estaban organizadas jerárquicamente según su categoría, y si querías encontrar algo era bastante intuitivo. Además, las aplicaciones estaban junto a otras de su misma clase, no te encontrabas juntos por ejemplo a Firefox y KMail que, sí, son aplicaciones para Internet, pero que no tienen nada que ver la una con la otra. Y eso Firefox y KMail, que al menos tienen algo relación. Pero que K3B y KAlarm estén en la misma categoría...

Y otro de los motivos por los que me gustaba es porque tengo muchísimas aplicaciones instaladas, y ya incluso con menús anidados había algunos bastante poblados. No me quiero imaginar qué pasaría si pusiese esta nueva organización de menús en mi sistema.

Independientemente de que no me guste la organización, otro problema que encuentro es que los elementos de menú sólo incluyen el nombre, pero no la descripción. Cierto es que por los nombres e iconos se podría sacar la funcionalidad de la mayoría de las aplicaciones, pero una "ayudita" junto al nombre que te diga qué es cada cosa tampoco viene mal.

No obstante, esto parece que ya se trató (aunque lo que se pedía era el formato Descripción (Nombre)) en el bug Menu : not understandable ! y no parece que surtiese mucho efecto, ya que fue marcado como OLD tras indicar que las entradas muestran el nombre de la aplicación... Pero como se puede ver en los comentarios, Pacho amablemente ya reabrió el bug :) Al menos no soy el único que piensa así, pues hay un bug similar (kde menu (beta 2)) abierto para Mandriva Corporate ;)

Y aquí hay otra inconsistencia en mi opinión. Si el menú muestra nombre y descripción, el formato es Nombre - Descripción. Si muestra descripción y nombre, el formato es Descripción (Nombre). Lo lógico sería que ambos formatos mostrasen la información adicional entre paréntesis, en lugar de uno entre paréntesis y otro con un guión. Pero esto no es algo de Mandriva, sino una cuestión propia de KDE, como puede verse en Error in displaying application's description in KMenu y kmenu does not show the description of an application in brackets anymore. En KDE 3.5.6 había un bug, primero dijeron que no lo harían, y luego lo "arreglaron", pero de la peor forma posible :)

Como puede verse en los comentarios, Pacho abrió un bug al respecto de esta cuestión en Mandriva, fix Kicker default behavior: restore parens for NameAndDescription format in Kicker, y se puede votar en Votar bug 34127.

Mientras probaba la RC 2 decidí ponerme algo de música de mi disco duro utilizando Amarok. Y cuál fue mi sorpresa cuando veo que Amarok considera la primera partición de mi disco duro como un dispositivo de medios extraíble (aunque no las demás). No tengo ni idea si es problema de Amarok, de HAL o de quién... ¿A alguien más le ocurrió algo similar? Porque espero equivocarme, pero me da la sensación de que es el típico bug difícil de reproducir que quedará abierto mucho tiempo...

Dado que th3n3k me confirma en los comentarios que a él también le sucede, cree el bug Amarok shows the first disk partition as a media device, que puede votarse en Votar bug 34205.

Me percaté de que mdkapplet no estaba en funcionamiento, así que intenté ponerlo... pero no hubo manera. De hecho, ni siquiera pude borrar el directorio de configuración, ya que al intentarlo se quedaba intentando borrarlo de por vida.

Ahora, mi siguiente objetivo era ver qué tal se comportaban los diversos drakes. Así que abrí drakconf para tenerlos todos a mano.

Respecto a drakconf, destacar la separación por categorías dentro de cada sección. Todo un acierto. Una pena que el hecho de que unos elementos estén en español y otros en inglés estropee esa primera buena impresión :( He aquí el bug Several unstranslated entries in drakconf in German, Spanish and Russian, y se puede votar en Votar bug 34106.

Un problema de Mandriva One RC2 es que los repositorios no pueden configurarse por las buenas. Al intentar añadir nuevos repositorios, falla, y además drakrpm se cierra sin mostrar un triste mensaje de error. Por consola, no obstante, sí muestra el error.

El problema parece ser que la base de datos de RPM que viene "de serie" está corrupta. Para solucionarlo, se eliminan los paquetes /var/lib/rpm/__db*, se ejecuta rpm --rebuilddb y al configurar de nuevo los repositorios funciona. Aunque, no comprendo por qué, sólo por cierto tiempo. Luego vuelve a corromperse... Hay varios bugs en Bugzilla sobre este tema, como drakxtools corrupt rpm database when run as user o 2008 beta 1: rpm database coruption, y como se puede ver ya está solucionado.

Una vez que pude ejecutar drakrpm-edit-media, me decepcionó comprobar que todavía no se permite elegir entre synthesis y hdlist completos, como se pide en el bug Allow choice between synthesis and full hdlists when configuring repos y que puede votarse en Votar bug 31032. Debería ser algo realmente fácil de implementar (al menos, si se sabe Perl y GTK, claro :) ).

En drakrpm me encontré de nuevo con textos sin traducir. Antes de que se solucionase el mencionado problema con la base de datos y su corrupción, cascaba cada poco. Eso sí, muy interesante el asistente que se muestra cuando casca para informar de un bug. Esperemos que su uso se propague a los demás drakes, si es que no lo usan ya.

Una vez actualizado el sistema, pude usarlo normalmente, y me encontré con textos que no se correspondían del todo con las acciones a realizar. Por ejemplo, si se eliminan e instalan paquetes en la misma tacada, el mensaje indica que tienen que quitarse unos paquetes para poder actualizar otros, lo cuál no es cierto. El bug es rpmdrake shows wrong message when installing and uninstalling packages at the same time y se puede votar en Votar bug 34121.

Además, si se libera espacio, no lo indica. Al eliminar paquetes, dice que se necesitan 0KB adicionales de espacio en disco, cuando debería decir cuánto espacio se libera. Igualmente, si se eliminan e instalan en la misma tacada varios paquetes, sólo indica cuánto espacio ocupan los paquetes a instalar, sin tener en cuenta que puedes estar liberando más espacio del necesario al borrar los otros paquetes. No obstante, actualizando al último Cooker este comportamiento ya está corregido, y sí muestra el espacio a liberar.

Si se selecciona un paquete de tamaño X para instalar, se aplica, se cancela el diálogo de confirmación, se deselecciona el primer paquete, se selecciona otro paquete para instalar de tamaño Y y se aplica de nuevo, el diálogo indicará que se necesita un tamaño de X+Y para llevar a cabo la operación. Igualmente, si se seleccionan por ejemplo 2 paquetes para instalar, se aplica, se cancela, se deselecciona uno de ellos y se aplica de nuevo, el tamaño que indicará el diálogo la segunda vez seguirá siendo el mismo que indicaba en la primera. Es un poco lioso, lo sé ;)

Es decir, el tamaño que indica el diálogo es la suma de todos los paquetes que se seleccionaron previamente para instalar, incluso si fueron deseleccionados. Es más, incluso si se reinicia la selección, el tamaño mostrado en el diálogo de confirmación sigue siendo la suma del tamaño de los paquetes seleccionados previamente. El bug es rpmdrake shows wrong additional disk space y se puede votar en Votar bug 34122.

Para terminar con drakrpm, añadir que cuando se instala un paquete con dependencias, el tamaño de las dependencias debería mostrarse en el diálogo de confirmación. El bug es rpmdrake should show the needed size to install dependencies y se puede votar en Votar bug 34123.

Cambiando a drakx11, éste pide instalar el paquete task-x11. Pero sólo lo pide cuando la base de datos está corrupta. Si la base de datos está bien, funciona sin problemas (ya que el paquete viene instalado de serie). Ya fue reportado (2008.0 RC2 "ONE" wants to install task-x11, and fails.) y marcado como duplicado del mencionado anteriormente drakxtools corrupt rpm database when run as user.

Por lo demás, no tuve problemas. Pero, como ya dije, para mí unos pequeños problemas pueden deslucir tremendamente el resultado final. La mayoría de los problemas mencionados imagino (espero...) que podrán arreglarlos para la versión definitiva. Pero lo que realmente deseo con fervor es que vuelvan a incluir el menú clásico de Mandriva.

Cuando en su día eliminaron mdkkdm (el gestor de entrada de Mandriva) me pareció una mala decisión. No el hecho en sí de eliminar la aplicación, sino el que el gestor de entrada que lo sustituyó (kdm), aún cuando podía mostrar listas de usuarios, no lo hiciese por defecto, o al menos fácilmente.

E incluso siendo KDEro, yo ahora utilizo gdm porque es el único de los dos que incluye un paquete de temas en el que pueda escoger uno con lista de usuarios (y en la 2008 no veo que haya cambiado este aspecto).

De hecho, el argumento que se usó en su día para eliminar mdkkdm fue que tanto kdm como gdm podían hacer las mismas cosas que mdkkdm. Y lo cierto es que yo aún no vi que ninguno de los dos notificase al usuario que introdujo una contraseña incorrecta como hacía mdkkdm (la lista de usuarios temblabla a modo de queja).

Puede parecer una chorrada, pero recuerdo que mi padre un día me mencionó que le había llamado la atención cómo indicaba que la contraseña estaba mal introducida. Era una forma sencilla y clara de indicarlo, y mucho más llamativa que un mensaje de error. Me atrevería a decir que era más usable.

Y la ordenación de menús parece que va a seguir el mismo camino. La eliminaron, no se puede poner ni siquiera de modo opcional, y creo que es, simple y llanamente, un paso atrás. Yo sé cómo mantener dicha ordenación, y es lo que haré.

Pero mantener la ordenación de menús por parte de Mandriva no sería complicado, al contrario que con mdkkdm (problemas de seguridad, cambios en el sistema base, etc). La definición de los menús ocupa unos pocos Kb, y no influye en absoluto en los demás menús (por ejemplo, antes podían convivir en el mismo sistema el menú de KDE/GNOME, el Discovery y el de Mandriva y no había problemas).

Además, no requiere mucho mantenimiento: la organización ya está hecha e internacionalizada, es buena, y las únicas actualizaciones necesarias serían cuando cambiasen las categorías de la especificación de menús de Freedesktop.org, algo que no es probable que ocurra muy a menudo. Bueno, quizás hiciesen falta unos pequeños ajustes ahora que las categorías X-MandrivaLinux ya no se usan, pero no creo que mucho más.

Finalmente, y para redondearlo, drakmenustyle podría mostrar una lista de las organizaciones de menú disponibles basándose en los subdirectorios de /etc/xdg, por ejemplo. Lo más apropiado quizás sería extender la especificación de menús de Freedesktop.org para poder poner una descripción a cada organización (si es que ya no se puede más), y mostrar dicha descripción en drakmenustyle.

Por todo ello, cree el siguiente bug Classic Mandriva menu layout shouldn't be dropped, que puede votarse en Votar bug 34119.

Eso es todo lo que tengo que decir sobre Mandriva One 2008 RC2 :) Y ahora toca irse a dormir, que ya empieza a faltar poco para que amanezca, así que va siendo hora de visitar mi cama ;)