domingo, 13 de abril de 2014

En breve DMDc 3.0 IL (testing)


Está al caer la versión 3.0 (testing). Por ahora tan solo en 64 bit. A ver que tal funciona.
No hace mucho comenté que iba a esperarme a la liberación de MATE 1.8. El motivo principal es la gran inestabilidad que se produce en algunos procesos en MATE como son con Caja y el Panel. Pensaba que en las sucesivas revisiones esto se iba a solucionar, pero no es así. Y lo suponía así ya que creía que el problema era de MATE. Pues nada mas lejos de la realidad.
Para que os hagáis una idea y para que veáis por vosotros mismo la gravedad de la situación, aquí os dejo un vídeo de un ejemplo practico.
El proceso a seguir para provocar esta situación es tan simple como abrir una carpeta como root (desde el menú contextual) y luego abrir un terminal como usuario normal, y el resultado es el que podéis ver:



Como podéis apreciar, Caja empieza abrir ventanas en un bucle infinito imposible de matar, ni tan siquiera cerrando la sesión. Si no se sabe donde tocar, nos vemos obligados sin remisión a reiniciar el sistema para salir de esta situación.
Pero cuando es el panel el que se queda pillado de este modo, la cosa aún es mucho peor ya consume toda la memoria física y virtual de nuestro sistema en pocos segundos dejándolo patitieso.

Llevo bastante tiempo dándole vueltas a este asunto (desde antes de la liberación 2.0), pero sin coger el toro por los cuernos ya que pensaba que el problema venía de MATE.
Systemd es desde luego una maravilla, el arranque del sistema con él es asombroso. Se reduce el tiempo en más de un 50%. Ya no quiero hablar del cierre del sistema. El Pc se apaga tan rápido que parece que se rompa!..¡Menudo susto!.

El problema en MATE vienen ya que Systemd utiliza la variable de entorno XDG_RUNTIME_DIR que es de obligado acceso tanto tanto para usuario normal como el usuario root. El acceso a esta variable desde gksu(root) a User no hay problema, pero sí los hay (como podemos ver en el vídeo) desde User a root. Este acceso se realiza a una copia del archivo de usuario dconf /user. En este caso lógicamente al ser creada por el usuario root, cualquier otro usuario no tiene acceso (por encontrarse con permisos root) y el sistema se colapsa intentando acceder a ella.

Reportes de ello he visto desde el 2012:
 /run/user/1000/dconf': Permission denied y soluciones ninguna.
Una solución fácil y obvia pero muy drástica, sería eliminar gksu del sistema para imposibilitar abrir aplicaciones gráficas con permisos de root. Pero muchos no estamos dispuestos a prescindir de esta practica utilidad, y por otro lado hay aplicaciones que utilizan gksu como dependencia, con lo cual tampoco podremos utilizar éstas.
No se hasta que punto el problema es de Systemd o más bien que sería necesario una revisión-adaptación de gksu. Hasta lo que yo se, si no utilizamos Systemd todo funciona con normalidad, pero si utilizamos Systemd y eliminamos gksu todo también parece ir con normalidad, así que...

Lo que tenía muy claro, es que para esta versión 3.0 no quería prescindir de Systemd y ya puesto tampoco de mi queridísimo gksu.
Llevo varias semanas dándole vueltas al asunto en busca de alguna solución.
La liberación de la 3.0 con este problema a sido hasta ahora un verdadero quebradero de cabeza, ya que no instalar gksu tan solo sería una solución muy temporal, pues los usuarios (la mayoría), tardarían bien poco en instalarlo al ver que no está y se encontrarían rápidamente con la desagradable sorpresa del que el sistema se les viene abajo a la primera de cambio.


A la espera de que surja algo mejor para solucionarlo definitivamente, al final se me ha ocurrido una pequeña solución (no muy limpia seamos sinceros) pero si lo suficientemente buena y a la vez fácil para evitar este tremendo problema, con lo cual poder disfrutar plenamente de nuestro DMDc 3.0, con todo a la última. Por lo tanto, una vez salvado este escoyo, no hay razón para demorar más la liberación de la 3.0 que tras unos pequeños ajustes será subida en breve. No creo que tarde más de una semana.


Lamentablemente la versión en 32 bit tardará bastante más. Los recursos en personal en dedicación son muy escasos y yo no doy para más. El pasar DMDc a la versión Testing (sin mencionar la reescritura por completo del instalador) me ha traído muchos quebraderos de cabeza y más de un problema como el expuesto anteriormente, pero el resultado al final parece ser mucho mejor de lo esperado...
Como escuché en una bonita película,...
..."Al final, todo saldrá bien... si no ha salido bien, es que entonces aún no es el final"

No hay comentarios:

Publicar un comentario