Un mantenedor de paquetes de varios terminales en Fedora ha contado en su blog una historia que resume muy bien la forma de pensar de los desarrolladores de GNOME. El sujeto en cuestión quería, simple y llanamente, que los usuarios de GNOME pudieran escoger en las preferencias, de entre todos los terminales que él empaqueta, el que los usuarios quieren que sea el terminal por defecto. Escueta respuesta por parte de un desarrollador de GNOME: "No estamos diseñando un escritorio para gente a la que le gusta escoger su terminal". Con un par.
La paradoja es que GNOME 3 ya tiene una interfaz para configurar las aplicaciones por defecto en el caso del navegador o el cliente de email (bajo el icono de "información del sistema", es decir, un lugar donde el usuario no esperaría encontrarlo), y hay sitio de sobra para añadir opción de escoger el terminal por defecto. Pero a pesar de ello los desarrolladores no quieren ver cosas tan técnicas ni de lejos. El post también enumera varias de las limitaciones que los desarrolladores de GNOME han decidido prohibir por-que-si (o porque OS X hace algo parecido):
. No permiten que haya una interfaz gráfica que permita cambiar de theme, los colores o los iconos.
· Si un usuario quiere utilizar en GDM una lengua diferente en el teclado o la
interfaz no podrá hacerlo en el propio GDM. Tendrá que
entrar en su sesión, configurarlo allí, salir de la sesión y volver a
entrar.
· Si un usuario quiere apagar el ordenador no puede hacerlo directamente: tiene que salir de su sesión y usar la opción de apagar en GDM (se puede utilizar la tecla ALT para mostrar la opción, pero en los tablets no se puede hacer eso).
· Si un usuario quiere configurar las acciones a tomar en los diferentes eventos de gestión de energía (por ejemplo, desactivar la suspensión del sistema al cerrar la pantalla del portátil) habrá de hacerlo con gconf, no hay opción para ello en la interfaz.
Respecto a las varias limitaciones de GNOME Shell, existe un mecanismo de extensiones para cambiar los comportamientos por defecto del Shell. Eso quiere decir que para hacer algo tan simple como eliminar el icono de accesibilidad o mover el reloj de sitio (o utilizar para algo todo el enorme hueco vacío del panel superior en el caso de pantallas extremadamente grandes), hay que instalar una extensión. Lo más gracioso es que tendré que oir críticas a la usabilidad de KDE y loas a la de GNOME por parte de personas que, para deshabilitar un puñetero icono de accesibilidad del panel, tendrán que googlear la manera de hacerlo.
26 de junio de 2011
21 de junio de 2011
Nokia N9, alegría y decepción
¿Era MeeGo la mejor plataforma móvil del mundo? Definitivamente no. Su desarrollo e incorporación a móviles había sido lento, lentísimo. Apenas tenían aplicaciones. Internamente, no supieron poner orden y tuvieron a la gente de Symbian y GTK perdiendo enormes cantidades de dinero y tiempo intentando competir QML: Si, Nokia se liaba en guerras internas de departamentos mientras Apple y Google se hartaban de comerles el desayuno en el sector de los smartphones.
Sin embargo, y a pesar de todos los fallos arrastrados, Nokia podía haberse tirado a la piscina, haberlo dado todo por MeeGo, y habrían tenido como punto de partida de su recuperación el Nokia N9, anunciado hoy. Con este 1.0 en la calle, podían dedicarse a apretar las tuercas, sacar actualizaciones frecuentes para refinarlo, ponerse a la altura de sus competidores e incluso mejorarlos. Todas, o casi todas las aplicaciones diseñadas para él serían válidas para millones de móviles Symbian existentes en el mercado. Podrían haberse centrado en la integración de QT con Android e iPhone para venderlo como el mejor toolkit multiplataforma para móviles, toolkit del que sus competidores se beneficiarían pero que los finlandeses controlarían en la práctica. Habrían gozado de gran apoyo por parte de los desarrolladores pro-software libre, que tienen su peso en todos los rincones de Internet. Sus competidores tendrían mucha ventaja, pero al menos Nokia estaría de vuelta en la carrera.
Pero nada de eso va a ocurrir. En lugar de eso seguirán con su apuesta por Windows Phone, la única gran plataforma móvil que no puede ejecutar aplicaciones nativas QT procedentes de Symbian, y sólo porque a Microsoft no le da la gana permitirlo. Tendrán que enfrentarse a esa burocracia que hace que el ritmo de desarrollo de IE o Windows sea tan exasperantemente lento y poco sorprendente. No controlarán la plataforma de desarrollo .NET/Silverlight, ni la tienda de aplicaciones, estarán a merced de Redmond. Y tendrán que esperar a final de este año para ver el primer móvil con Windows Phone, y eso teniendo suerte.
A pesar de todo, muchos enfermos del software libre no muy afines a la mentalidad de diseño autista de Android tenemos, por fin, un teléfono moderno que nos gusta. Larga vida al Nokia N9.
Sin embargo, y a pesar de todos los fallos arrastrados, Nokia podía haberse tirado a la piscina, haberlo dado todo por MeeGo, y habrían tenido como punto de partida de su recuperación el Nokia N9, anunciado hoy. Con este 1.0 en la calle, podían dedicarse a apretar las tuercas, sacar actualizaciones frecuentes para refinarlo, ponerse a la altura de sus competidores e incluso mejorarlos. Todas, o casi todas las aplicaciones diseñadas para él serían válidas para millones de móviles Symbian existentes en el mercado. Podrían haberse centrado en la integración de QT con Android e iPhone para venderlo como el mejor toolkit multiplataforma para móviles, toolkit del que sus competidores se beneficiarían pero que los finlandeses controlarían en la práctica. Habrían gozado de gran apoyo por parte de los desarrolladores pro-software libre, que tienen su peso en todos los rincones de Internet. Sus competidores tendrían mucha ventaja, pero al menos Nokia estaría de vuelta en la carrera.
Pero nada de eso va a ocurrir. En lugar de eso seguirán con su apuesta por Windows Phone, la única gran plataforma móvil que no puede ejecutar aplicaciones nativas QT procedentes de Symbian, y sólo porque a Microsoft no le da la gana permitirlo. Tendrán que enfrentarse a esa burocracia que hace que el ritmo de desarrollo de IE o Windows sea tan exasperantemente lento y poco sorprendente. No controlarán la plataforma de desarrollo .NET/Silverlight, ni la tienda de aplicaciones, estarán a merced de Redmond. Y tendrán que esperar a final de este año para ver el primer móvil con Windows Phone, y eso teniendo suerte.
A pesar de todo, muchos enfermos del software libre no muy afines a la mentalidad de diseño autista de Android tenemos, por fin, un teléfono moderno que nos gusta. Larga vida al Nokia N9.
14 de junio de 2011
Error, procesador demasiado inteligente
En este artículo de LWN se cuenta una curiosa historia de microoptimizaciones que no sirven para nada. Resulta que en equipos modernos la diferencia de tiempo de acceso entre memoria y registro de procesador es enorme, el tiempo necesario para acceder a una dirección de memoria RAM no cacheada previamente es de cientos de ciclos de CPU.
Para ayudar a los programadores a sortear esta desventaja, las CPUs modernas tienen instrucciones de "prelectura" (prefetch). Se trata de instrucciones que por si solas no hacen nada, pero advierten al procesador de que se va a leer una dirección concreta de memoria en un futuro muy cercano, información que el procesador aprovecha para decir al controlador de memoria que vaya leyendo esa dirección de memoria y colocándola en el caché L1. Así, cuando se acabe leyendo de verdad, no habrá que esperar cientos de ciclos sin hacer nada. En el kernel Linux, se utilizan las instrucciones de "prefetch" en muchos sitios, por ejemplo al ir leyendo elementos de una lista enlazada se hace un "prefetch" del próximo elemento. Sin embargo, mediciones recientes han determinado que el efecto práctico de esta técnica es el enlentecimiento del kernel - concretamente, un 0.5% más lento en el tiempo empleado en compilar un kernel.
¿Qué ha pasado? Los procesadores modernos tienen una porción de la CPU dedicada al análisis heurístico del código que se ejecuta, con el propósito de adivinar qué rutas de código se van a tomar, que partes de la memoria se van a leer, optimizar el código y hacer "prefetchs" por su cuenta (pueden estar seguros que también intentan detectar si el programa en ejecución es algún famoso benchmark de CPUs). Resulta que el analizador de código de los procesadores Intel es capaz de adivinar los "prefetchs" necesarios con más eficiencia que los programadores del kernel y GCC - hasta el punto de que esas microoptimizaciones manuales le molestan y disminuyen el rendimiento. Resumiendo, que en la próxima versión se ha eliminado todo tipo de prefetching de Linux, y es más rápido.
Este tipo de cosas, por cierto, son las que han puesto su granito de arena para que x86 triunfe y cosas como Itanium fracasen. Itanium está diseñado para que el software y el compilador hagan casi todo el trabajo de optimización, de hecho es el compilador el que debe decidir cosas como si una instrucción depende de otra y si, por tanto, se pueden procesador ambas simultáneamente o si deben ser serializadas la una detrás de la otra. De ese modo, el complejo optimizador de código se hace teóricamente innecesario y el diseño de la CPU se simplifica. Pero en la práctica resultó que los compiladores no son (y probablemente nunca sean) tan buenos y exprimir la potencia de un Itanium requiere unos esfuerzos de optimización impresionantes. Mientras tanto, el académicamente horroroso y recargado analizador de código de los x86 es capaz de optimizar en tiempo de ejecución cualquier basura que le echen encima.
Para ayudar a los programadores a sortear esta desventaja, las CPUs modernas tienen instrucciones de "prelectura" (prefetch). Se trata de instrucciones que por si solas no hacen nada, pero advierten al procesador de que se va a leer una dirección concreta de memoria en un futuro muy cercano, información que el procesador aprovecha para decir al controlador de memoria que vaya leyendo esa dirección de memoria y colocándola en el caché L1. Así, cuando se acabe leyendo de verdad, no habrá que esperar cientos de ciclos sin hacer nada. En el kernel Linux, se utilizan las instrucciones de "prefetch" en muchos sitios, por ejemplo al ir leyendo elementos de una lista enlazada se hace un "prefetch" del próximo elemento. Sin embargo, mediciones recientes han determinado que el efecto práctico de esta técnica es el enlentecimiento del kernel - concretamente, un 0.5% más lento en el tiempo empleado en compilar un kernel.
¿Qué ha pasado? Los procesadores modernos tienen una porción de la CPU dedicada al análisis heurístico del código que se ejecuta, con el propósito de adivinar qué rutas de código se van a tomar, que partes de la memoria se van a leer, optimizar el código y hacer "prefetchs" por su cuenta (pueden estar seguros que también intentan detectar si el programa en ejecución es algún famoso benchmark de CPUs). Resulta que el analizador de código de los procesadores Intel es capaz de adivinar los "prefetchs" necesarios con más eficiencia que los programadores del kernel y GCC - hasta el punto de que esas microoptimizaciones manuales le molestan y disminuyen el rendimiento. Resumiendo, que en la próxima versión se ha eliminado todo tipo de prefetching de Linux, y es más rápido.
Este tipo de cosas, por cierto, son las que han puesto su granito de arena para que x86 triunfe y cosas como Itanium fracasen. Itanium está diseñado para que el software y el compilador hagan casi todo el trabajo de optimización, de hecho es el compilador el que debe decidir cosas como si una instrucción depende de otra y si, por tanto, se pueden procesador ambas simultáneamente o si deben ser serializadas la una detrás de la otra. De ese modo, el complejo optimizador de código se hace teóricamente innecesario y el diseño de la CPU se simplifica. Pero en la práctica resultó que los compiladores no son (y probablemente nunca sean) tan buenos y exprimir la potencia de un Itanium requiere unos esfuerzos de optimización impresionantes. Mientras tanto, el académicamente horroroso y recargado analizador de código de los x86 es capaz de optimizar en tiempo de ejecución cualquier basura que le echen encima.
7 de junio de 2011
QT 5
Ya hace un tiempo que fue noticia este post en el blog de QT, que nos ilumina sobre las direcciones que podría tomar QT 5. Nadie sabe cuál va a ser el nivel de inversión de Nokia en QT a largo plazo (viendo el panorama que tienen las cosas, poco), pero al menos el equipo de programación es tan ambicioso como siempre, y si no fíjense en esto:
"While the QWidget based classes [los widgets tradicionales] are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term" "Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph". Y, de este PDF con más detalles: "The core platforms will be Linux on Wayland and X11, Mac and Windows"
Espero que los gnomeros comprendan que esto me parezca bastante más interesante que la aburrida GTK. Para entendernos, lo que QT 5 pretende hacer sería equivalente a que GTK pasara a usar Clutter como pilar de todas sus GUIs. En cambio, en GTK 3.0, que acaba de salir, el pilar usado es Cairo.
Más interesante que los desfases de Gnome es preguntarse qué pasará con KDE. Una nueva versión de QT rompería la compatibilidad binaria, así que es de suponer que se necesitaría un KDE 5. Sin embargo, el cambio tecnológico no sería tan grande como lo fue de KDE3 a KDE4, por lo que más allá de experimentar con nuevas interfaces, no habría grandes novedades.
Un detalla interesante es que ya hay una nueva versión de Plasma, una especie de Plasma 2, que se basará completamente en QML (y no, no se trata de que son unos chapuceros que estén "reescribiendo" Plasma de nuevo, como se ha oído por ahí). Por esa razón, no será necesario esperar a un KDE 5 para utilizar interfaces basadas en QML, pero es que además cabría preguntarse por la influencia que tendrá Plasma en KDE 5. ¿Se imaginan que KDE declara Plasma como el framework fundamental para construir UIs? Parece demasiado radical, pero ahí está Amarok, utilizándolo.
"While the QWidget based classes [los widgets tradicionales] are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term" "Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph". Y, de este PDF con más detalles: "The core platforms will be Linux on Wayland and X11, Mac and Windows"
Espero que los gnomeros comprendan que esto me parezca bastante más interesante que la aburrida GTK. Para entendernos, lo que QT 5 pretende hacer sería equivalente a que GTK pasara a usar Clutter como pilar de todas sus GUIs. En cambio, en GTK 3.0, que acaba de salir, el pilar usado es Cairo.
Más interesante que los desfases de Gnome es preguntarse qué pasará con KDE. Una nueva versión de QT rompería la compatibilidad binaria, así que es de suponer que se necesitaría un KDE 5. Sin embargo, el cambio tecnológico no sería tan grande como lo fue de KDE3 a KDE4, por lo que más allá de experimentar con nuevas interfaces, no habría grandes novedades.
Un detalla interesante es que ya hay una nueva versión de Plasma, una especie de Plasma 2, que se basará completamente en QML (y no, no se trata de que son unos chapuceros que estén "reescribiendo" Plasma de nuevo, como se ha oído por ahí). Por esa razón, no será necesario esperar a un KDE 5 para utilizar interfaces basadas en QML, pero es que además cabría preguntarse por la influencia que tendrá Plasma en KDE 5. ¿Se imaginan que KDE declara Plasma como el framework fundamental para construir UIs? Parece demasiado radical, pero ahí está Amarok, utilizándolo.
Suscribirse a:
Entradas (Atom)