Liberada DMDc-3.0-IL (Testing)

Bueno, pues ya esta aquí, cuatro meses después de su versión 2.0 y de intenso trabajo os presento su versión 3.0. Esta versión 3.0 se acerca mucho a lo que yo quería realizar desde un primer momento. Las versiones 1.x y 2.0 me han servido (y de qué forma) para llegar a esta. Tras mucho trabajo y quebraderos de cabeza (todo hay que decirlo) aquí está DMDc 3.0-IL- 64 bit.

Trabajo y mucho es el que me ha dado sobre todo el instalador. Aunque el sistema de instalación me gustaba, no me convencía en absoluto. Era algo que pensé en retocar desde un principio, pero siempre a la espera del resultado de la acogida de DMDc. ¿Para qué molestarme si no la utiliza nadie?.
Por suerte esto no es así, y me ha sorprendido mucho la descargas habidas de la versión 2.0. Pero sobre todo me ha sorprendido que el número de descargas de la versión 64 bit casi ha cuadriplicado a la de 32 bit..¿.?.

El caso, es que como decía, quería modificar algo el instalador. Pero como me pasa muy a menudo...empiezo a meter un poquito la mano y termino metiéndola toda. Si es que mi mujer dice que las tengo muy largas...jeje. Por cierto mi mujer odia los ordenadores...¿os imagináis por qué?.
Siguiendo con lo nuestro, vamos que he terminado por reescribirlo por completo. Y no se a vosotros, pero a mi me encanta como ha quedado.

Nota: Esta vez las traducciones del instalador tan solo se han hecho al Ingles y español. Quien quiera aportar su granito de arena (conociendo suficientemente el idioma) que traduzca el que le competa y me lo pase.


Esto ha hecho que se alargara un poco más la cosa, pero ciertamente que me ha venido la mar de bien para poder afrontar la transición de Debian Estable a Testing con más tranquilidad y serenidad. Quien piense que estan simple como actualizar a dicha rama va pero que muy mal encaminado. El subir de versión (y más ahora que han habido tantos cambios) es bastante complicado ya que hay que ir seleccionado las actualizaciones paso a paso y asegurarse de que ninguna de ellas lleva al trate al sistema o elimina o imposibilita cosas propias de la distro. Así que pasar de una rama a otra y dejar el sistema estable es bastante jodidillo de realizar.

Otro verdadero hándicap era...¿y después qué?. Me refiero a que una vez llegado aquí, ¿cómo mantenemos la distro más o menos estable?. ¿Lo dejamos en las manos de los buenos de Debian y que con suerte no nos metan en lo sucesivos días, algunos paquetes que nos lleven al traste el sistema?.
Una solución era crear nuestros propios repositorios a tan efecto, junto al que ya existe de DMDc. Pero tras una primera valoración vi que me era imposible mantenerlos. Es mucho trabajo el llevar esto a cabo por un equipo tan reducido. Con deciros que a duras penas puedo mantener el repositorio actual de DMDc. Gracias a José Mejías que me ayuda en ello y del quien "abuso" más de lo debido....Pero Dios se le sabrá pagar,..jeje por que lo que es yo ni una perra gorda que tengo para darle.

Este era un problema que también me tenía bastante bloqueado. Pero al final he encontrado un a solución que puede ser muy factible. Se trata de utilizar los repositorios de una distro basada en Debian llamada Tanglu.
Esta distribución se caracteriza en gran medida por utilizar los repositorios de Debian Testing pero de forma controlada. Es decir que le dan paso a todos aquellos paquetes que ellos consideran prácticamente estables, o que no dan problemas. Por otra parte, cuando hay paquetes que son necesarios o popularmente solicitados y no están lo suficientemente testados para su inclusión, entonces lo someten a criterio y a votación de sus usuarios, para actuar en consecuencia. Así que este es el repositorio que utiliza DMDc 3.0.
Hay que decir que el repositorio de Debian Jessie también se encuentra incluido, pero deshabilitado.

Que decir de DMDc 3.0. Pues que el primer sorprendido de lo bien que me ha quedado soy yo mismo. La verdad que funciona de fábula con su MATE 1.8. Eso sí, trampeadillo que lo tengo para evitar problemas (alguno muy grave) conocidos pero no propiamente de MATE. Tampoco quería liberarla sin haber solucionado esto tal y como expliqué en el artículo anterior. La verdad que el resultado es estupendo y el rendimiento excelente tras haberle metido el parchecito que le metí.
Otra cosa es el nuevo arranque con Systemd...menuda flipada!!. Pues nada ahí lo tenéis también. De cualquier modo quien quiera seguir utilizando el anterior arranque puede seguir haciendo ya que los dos son coexistentes. Tan solo tiene que cambiar la línea correspondiente en el GRUB.
Así que investigarla vosotros mismo para ver todo lo nuevo y valorarla en su buena medida.

Respecto al Live-CD. Como decía he rescrito el instalador y aprovechando ya que estaba liado, he añadido nuevas opciones a nivel de usuario, como son el sudo o el autologin. Por otra parte en el Live he añadido soporte para el uso de la contraseña root, que es la misma que la del usuario: live


Nota: El gestor de actualizaciones no se encuentra instalado. El motivo pues que en su rama testing el gestor que utilizamos habitualmente nos obliga a instalar paquetería y dependencias de gnome-packagekit (Nautilus incluido) nada interesante y menos aun necesaria en MATE. Lo peor es que aún instalando todo lo necesario, éste, el gestor de actualizaciones no funciona con MATE, es decir, no recibimos notificaciones de actualizaciones en ningún momento. Así que pensé... ¿Para que instalar algo que no funciona? y más aún si puede ser suplido fácilmente. Como esto no es realmente un problema tampoco he profundizado en el tema.
Podemos ver dos ventajas si se quiere en ello. Una que no tenemos un proceso corriendo continuamente en segundo nivel buscando actualizaciones. Y dos, que lo haremos cuando nosotros decidamos sin los constantes avisos de actualizaciones.

Para esto tan solo tenemos que abrir un terminal.
Primero comprobamos si hay paquetes obsoletos:

sudo apt-get autoremove

Antes de confirmar la eliminación de los paquetes que se muestren, comprobaremos si hay entre ellos paquetes que sí necesitamos, ya que un paquete marcado como obsoleto no quiere decir que no nos sea necesario. Si vemos que si hay paquetes que estamos utilizando, corremos este otro comando:

sudo aptitude keep-all

Luego ya podemos realizar la actualización:

sudo aptitude update

sudo aptitude safe-upgrade

Lo anterior realizará una actualización de los paquetes ya instalados.
Si se quiere hacer una actualización algo menos invasiva ya que aptitude si puede quitarnos e instalarnos algún que otro paquete utilizaremos:

sudo apt-get update

sudo apt-get upgrade

Los dos puntos anteriores, tanto aptitude como apt-get, unicamente actualizarán los paquetes que ya tengamos instalados, nada más.

Si por otra parte, lo que queremos es hacer una actualización completa:

sudo aptitude update

sudo aptitude full-upgrade

Esta última sí eliminará y añadirá paquetes nuevos. Y eliminará los paquetes que sean necesario para añadir y cumplir las dependencias de los actualizados o los nuevos.
Así, que para ir sobre seguro, el 1º y 2º opción, son los más adecuados. También son los que utilizamos normalmente, cuando se hace gráficamente.
Para simplificar y sobre todo para facilitarnos este proceso, podemos crear un simple lanzador en el escritorio o en cualquiera de los paneles con la siguiente orden:

• mate-terminal -e 'su -c "aptitude update && aptitude upgrade"'

Características

• Nuevo DMDc installer (con soporte para discos GPT)-Beta
• Basada por completo en Debian Testing 64 bit
• Kernel 3.13-1 x86_64 Bit
• System start: Systemd (un arranque mucho más rápido y eficiente)
• Escritorio MATE 1.8
• Repositorios DMDc y Debian-Tanglu (Testing)
• Soporte Plymouth
• mdm 1.4.8 (New support HTML5)
• dmdc-mdm-html5-themes (package Themes)
• LibreOffice
• Dropbox
• Adeskbar (Dock)
• Apwal (Launcher)
• Soporte Compiz+Emerald
• Skype, Jitsi (for DMDc 32 Bit)
• Jitsi (for DMDc 64 Bit)
• Aplicaciones de inicio designadas para MATE
• Interesante herramientas propias
• Soporte para diferente apariencia para Caja-Root, Terminal-Root y Pluma-Root
• Soporte Abrir un Terminal y Abrir como Administrador en el menú contextual de Caja
• Soporte Alt + F2 o F2 abre ventana ejecutar (cuando se usa Marco)
• Soporte F2 abre ventana ejecutar (cuando se usa Compiz)
• Gran selección de Software
• y mucho más...

---- Themes (based Greybird) y iconos : -----

• Theme DMDc Themes
• Emerald DMDc Themes
• Mouse Theme DMDc
• Icons FaenzaWolfe
• Soporte root Themes
• Plymouth Theme

Nota Live-CD:
Nombre de usuario: dmdc
Contraseña de Usuario o Root: live

Nota graciosa:
Se me pasó cambiar el número 2.0 por 3.0 en la pantalla de selección de arranque del Live. Así que la versión es la 3.0 aunque veáis 2.0 al principio.

Si tienes dudas sobre la instalación de DMDc, aquí te dejo un estupendas indicaciones de un Bruto (blog amigo) de cómo hacerlo:

Cómo instalar DMDc 3.0

::::::::::Videos DMDc::::::::

Splash (DMDc)
Splash (DMDc+) 

MDM

Descargar DMDc-3.0-IL (Testing)-x86_64

Nuevo repositorio para la versión Testing. 

Remplazar la línea deb de DMDc por esta otra en el archivo /etc/apt/sources.list:

deb http://dmdcosillas.org/dmdc/ dmdc-testing main contrib non-free

¿Qué demonios está pasando?

Asisto perplejo a las recientes noticias sobre vulnerabilidades encontradas en las implementaciones SSL/TLS tanto de Linux como de iOS. Por si no estáis enterados, os pongo en antecedentes.

A principios de año se liberó una actualización para iOS6, iOS7 y Apple TV 6, y se sabe que también afectaba a OS X 10.9.x. El parche corregía una cagada de las históricas. En post anteriores, os he explicado el mecanismo de funcionamiento de los certificados digitales, su firma y verificación por parte de las CA’s. Pues bien, el problema consistía en el mal funcionamiento de una función, en concreto SSLVerifySignedServerKeyExchange, que, como su nombre bien indica, se encarga de verificar la firma de un mensaje. He aquí el código en cuestión: 

SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa,
                                 SSLBuffer signedParams, uint8_t *signature,
                                 UInt16 signatureLen)
{
            OSStatus            err;
            ...
            if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
                   goto fail;
            if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                   goto fail;
                   goto fail;
            if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
                   goto fail;
            ...
fail:
            SSLFreeBuffer(&signedHashes);
            SSLFreeBuffer(&hashCtx);
            return err;

No hay que ser programador avanzado para darse cuenta del error. Ese segundo goto fail; que os he resaltado, hace que se salga de la función sin haber terminado todas las verificaciones de la firma, dando un resultado válido, aunque el certificado utilizado para firmar sea falso o incluso no exista. Sorprendente, ¿verdad?

Pues ojiplático me quedé al comprobar, pocas semanas después, ya en Marzo, que GnuTLS padecía del mismo, o similar, fallo de programación. Y para no ser menos que nuestros amigos de Cupertino, esta cagada venía arrastrándose desde el 2005, sin que nadie se hubiera dado cuenta…o no es así, y entonces es para echarse a temblar.

Aquí el fallo venía dado por goto’s erróneos, haciendo que el código de error detectado en un certificado, fuera pasado a la instrucción cleanup, en vez de fail. Así, podía darse el caso de que nuestro sistema detectase un certificado erróneo (entiéndase por erróneo, falso o no verificado) y lo diese por válido. La verdad es que no sé qué cagada es peor. Pero no voy a entrar en la prolífica discusión de si es mas seguro Linux o iOS. Sinceramente, me da igual. Porque cuando ya creía haberlo visto todo, hace su aparición estelar….. TACHAN!!!.....Heartbleed.

Este “palabro” viene a describir el fallo de seguridad conocido más importante hasta la fecha (nótese que he subrayado la palabra “conocido”). Si bien los fallos anteriores eran corregidos rápidamente por una simple actualización o parche en nuestros sistemas, nuestro amigo Heartbleed nos tiene, a día de hoy, y perdonarme la expresión, cogidos por las pelotas. Y os voy a explicar porqué.

Los fallos anteriores afectaban a nuestro lado de la comunicación segura. Así, si era lanzada una web “falsa”, nuestros sistemas podían no darse cuenta del error. Pero no pasaba nada si nos conectábamos a nuestro banco, o comprábamos en nuestra tienda habitual de Internet, o accedíamos a nuestro correo web. Las páginas eran válidas y seguras, y no había posibilidad de robo de credenciales o datos de tarjetas, por poner un ejemplo.

Heartbleed hace que el fallo de seguridad resida en el servidor al que nos conectamos. Da igual que lo hagas con Linux, iOS, Windows, Android, señales de humo o tam tam. Los servidores han sido comprometidos, y gravemente.

En este caso, ha sido un teutón llamado Robin Seggelmann el artífice del caos. El pobre hombre debe estar pasando las de Caín y no estoy de acuerdo en realizar un linchamiento público, ya que, si bien es cierto que el error en el código ha sido suyo, no es menos cierto que el sistema de revisión de dicho código por parte de su supervisor ha fallado.

El fallo se encuentra en la implementación OpenSSL, software instalado en multitud de servidores de Internet, que proveen de acceso seguro a protocolos tales como HTTPs o FTPs, por poner un ejemplo. Vamos a destripar el fallo.

En post anteriores os he descrito el uso de certificados digitales. Vamos a repasarlo de nuevo. Estamos sentados en nuestra casita, tranquilos, y decidimos conectarnos para ver si Hacienda nos ha realizado ya la devolución de los impuestos. Cada vez me devuelven menos, por cierto. Gracias Montoro, ya mismo tendré que pagar por trabajar.

Que me voy, que me voy del tema… Si es que me tiráis de la lengua…

En el servidor del banco al que nos conectamos reside su certificado digital, expedido por una CA, con sus claves pública y privada. Al conectarnos, el servidor nos facilita su clave pública, con la que encriptamos la información que le enviamos al Banco. No estoy hablando de credenciales de acceso. Me refiero a que nuestro equipo encripta una serie de información para establecer una comunicación cifrada simétrica con el servidor (recordar que el cifrado simétrico es mucho más rápido que el asimétrico). Así, la información que ciframos con la clave pública del servidor, es descifrada con la clave privada del mismo y se establecen los parámetros para realizar una comunicación cifrada de manera simétrica, utilizando la misma clave de cifrado en ambos lados de la comunicación. Esto es el funcionamiento habitual en una conexión a un servidor seguro. Hasta ahora todo va bien. Y ahora viene la parte complicada. A ver si consigo que todos lo entendamos (yo incluído)

Vamos a hacer una abstracción e imaginar que estamos hablando Frannoe y yo mismo. A ver si así queda claro. Vamos a imaginar que estamos en una conversación telefónica y nos aseguramos de que nuestro interlocutor es realmente quien dice ser.

[Frannoe dixit]
Ya me cogió de conejillo de indias…

[Jose respondere]
Ah… se siente. Haber dedicado el Blog a la cría de gusanos de seda.


F: Hola Jose.
J: Hola Fran
F: La lluvia en Sevilla… (es la clave pública de Fran. Es que es de un poético...)
J: ...buena sombra le cobija (propuesta de clave simétrica, encriptada con la clave pública)
F: Aceptamos barco (aceptada y establecida clave simétrica)

(a partir de aquí va todo cifrado, pero lo dejo en plano)

J: ¿Para cuándo la DMDc 3 en x86, Fran?
F: ¿No has leído mi último post? Que no doy abasto…
J: Si es que te metes en unos berenjenales…
F: Tú tienes parte de culpa, te recuerdo.
J: Espérate Fran, que me hago de vientre…
F: Sin comentarios
.
.
J: Ya he vuelto.
F: Lo siento, ya no estoy seguro de que seas tú realmente. Así que…. La lluvia en Sevilla…
J: (mierda, a empezar de nuevo…)

Para evitar esto, que es una sobrecarga de trabajo enorme para un servidor, se establece un procedimiento por el que le decimos al servidor: “Oye, que soy yo, no me empieces de nuevo la comunicación”. Lógicamente, el procedimiento consiste en el envío de una cierta información desde el cliente, muy similar a un ping. En concreto, lo que se envía desde el cliente al servidor es una estructura de datos llamada TLS1_HB_REQUEST que consiste en dos partes: un mensaje o payload con datos aleatorios y el tamaño de dicho mensaje. Cuando el servidor recibe este mensaje, devuelve una estructura de datos llamada TLS1_HB_RESPONSE, que copia el mensaje recibido y lo envía de vuelta. A este procedimiento se le vino a llamar HEARTBEAT, o latido de corazón, para mantener viva la conexión con el servidor aunque no haya intercambio de datos.

El problema surge aquí. El error consiste en que el servidor no comprueba si los datos enviados en TLS1_HB_REQUEST tienen realmente la longitud indicada en el mensaje. Así que enviamos a nuestro servidor un TLS1_HB_REQUEST de 1 byte, pero indicándole que el tamaño del mismo es de 64 kb (65.535 bytes).

Como el servidor confía ciegamente en que el payload recibido es de 64 kb, procede a generar el TLS1_HB_RESPONSE, copiando el payload original, y completando hasta llenar los 64 kb del mensaje con los datos que en ese momento tiene la memoria RAM del servidor.

[Frannoe dixit]
¿Y qué hay en la memoria RAM del servidor?

[Jose respondere]
Todo, querido amigo. En la RAM del servidor se encuentra ejecutándose OpenSSL, así que tenemos código de OpenSSL, contraseñas, claves de cifrado… Claro, de 64 kb en 64 kb, se tarda en recopilar información, pero potencialmente es infinita.

Así que… ¿en qué situación nos encontramos? Pues para ponernos en el peor de los casos, podemos asumir que todas nuestras claves bancarias y contraseñas de servicios web están comprometidas.

[Frannoe dixit]
Pues las cambio todas y a correr

[Jose respondere]
Es lo mínimo que tienes que hacer...cuando sepas que el servidor al que te conectas ya está parcheado. Te recuerdo que las claves de los certificados de esos servidores pueden haber sido comprometidas. Así que los administradores deberían actualizar dichas claves y/o generar nuevas. Si han sido descubiertas, da igual que cambies tus claves de acceso. Van cifradas con las claves del servidor que han sido comprometidas, ¿recuerdas?.

[Frannoe dixit]
Pero eso ya estará hecho, ¿no? Ha pasado una semana desde que saltó la liebre…

[Jose respondere]
Yo no digo nada, que después todo se sabe… Aquí te dejo un enlace a una herramienta que puedes utilizar para comprobar si el servicio al que te conectas está parcheado o no. Sólo te diré que los que yo he probado (bancos inclusive), me dicen que ya está solucionado (es decir, que ya no se traga el payload de 64 kb), pero advierte que los certificados de los sitios no han sido actualizados….

Y así nos va...


Me parece que voy a dar de baja el Internet, la tele por cable, el móvil y el teléfono fijo… Y vuelta al cartero de toda la vida… y a las postales… qué tiempos...

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"

En preparación de DMDc 3.0

Tengo pensado subir la versión 3.0 tan pronto sea liberada la versión 1.8 de MATE. Como sabéis he estado muy liado reescribiendo el instalador de DMDc y ya creo tenerlo terminado:

También he pulido (a mi entender) bastante el tema del inicio gráfico de plymouth. Podréis elegir entre estos dos themes:

A parte del cambio estético, (pero guardando el mismo estilo) los temas se han aligerado mucho, con lo cual el impacto en el arranque es menor. Y por lo que veo se ha ganado en vistosidad, creo que ahora sí me han quedado bastante bien.

Otro tema también modificado sutilmente (o no) es el de la pantalla de login. Considero que el logo de DMDc en el Sol era demasiado ostentoso. Creo que de este modo gana bastante más, y el logo lo he situado abajo de forma más sutil, sustituyendo el anterior por un sol bastante más realista. También he eliminado el cartelito informativo que aparecía abajo a la derecha:

Por cierto, cualquiera de estos temas ya los tenéis disponibles en los repositorios de DMDc.

Por último comentar que esta versión 3.0 de DMDc estará orientada por completo a la rama Testing de Debia, pero de una forma muy controlada que espero explicar más adelante cuando lo tenga casi todo a punto.