No es que las relaciones entre Canonical/Ubuntu y Gnome fueran tan perfectas como se cree, pero en una sola semana han surgido un par de asuntos que ha disparado y seguirá disparando la tensión entre ellos. El primero y más comentado es la adopción del shell Unity no ya como alternativa a Gnome Shell, sino al gnome-panel de toda la vida. Teniendo en cuenta que la novedad más importante de Gnome 3 es el cambio de shell -también lo fue en KDE4, no nos engañemos-, esto representa una divergencia de mentalidades de difícil solución.
Por lo que se puede leer por ahí, que muchos Gnomeros no están nada contentos con esta decisión. Como se trata de software libre y lo único que pueden hacer es fastidiarse, las críticas se han dirigido al lugar previsible: acusar a Canonical de no tener espíritu de comunidad. Pero, como ha explicado Shuttleworth, el problema se debe a divergencias técnicas. Ellos quieren una barra de menús global -al estilo OS X-, y la gente de Gnome no. Ellos consideran que Mutter (el gestor de ventanas de Gnome Shell) es lento y prefieren Compiz, Gnome no. Asi que Canonical ha desarrollado Unity, y despues de probar con Mutter se han pasado a Compiz, que por lo visto es más rápido.
Y yo me pregunto: ¿Por qué Canonical es aquí el malo? La barra de menús global es una idea aceptable, pero ante todo es una idea puesta en práctica y muy trillada. ¿Por qué debería Canonical renunciar a ello sólo porque a otras personas de Gnome no les guste? Este problema -dos requisitos que chocan entre sí- es una situación crítica que ha destruido no pocos proyectos de software libre, y que en el kernel Linux se ha resuelto tradicionalmente con pragmatismo: Permitir ambas opciones. Está claro que la solución óptima es que Gnome Shell pueda configurarse para utilizar menús globales o individuales, o que al menos pueda personalizarse fácilmente la UI para permitir una opción u otra. No conozco los detalles de los flames entre la gente de Canonical y Gnome/GTK, pero si Canonical no tenía otra salida, hizo bien creando Unity. Por otro lado, Unity tiene un lado muy negativo, y es que Canonical requiere asignación de copyright a las contribuciones de sus proyectos (mal, muy mal).
Además de esto, hay otro punto de fricción entre Gnome y Canonical. Le ha causado Matt Zimmerman, Chief Technological Officer de Canonical, o sea, el tipo que en última instancia toma decisiones tecnológicas y organiza a los desarrolladores. Este señor ha dicho en su blog que QT -si, la QT que usa KDE- es un gran toolkit, que es una gran plataforma para los desarrolladores y que Ubuntu la tendrá en cuenta como alternativa. Pero no sólo él piensa que QT es un buen toolkit, el propio Shuttleworth dice, mientras habla de un asunto de licencias, que Gtk "se ha estancado", mientras que QT no. Que los líderes de la principal distro Gnome digan algo así tiene su cosa...
27 de octubre de 2010
20 de octubre de 2010
Las novedades de Linux 2.6.36
Ya se ha anunciado la versión final de Linux 2.6.36. Las principales novedades de esta versión son: Soporte de la arquitectura Tilera,
un nuevo sistema de notificación de archivos que reemplaza a inotify, un rediseño de las workqueues para aprovechar mejor la concurrencia, cacheo local de CIFS, soporte para la "gestión energética inteligente" de Intel, integración del depurador del kernel con KMS, inclusión del sistema de seguridad AppArmor, varios nuevos drivers y pequeñas mejoras.
· Soporte para la arquitectura Tilera: El procesador Tile, de Tilera Corporation, es una nueva arquitectura diseñada para ser multicore y soportar cientos de cores en un solo chip. El objetivo es conseguir una CPU de gran rendimiento y energéticamente eficiente, con más flexibilidad que los chips de propósito específico como DSPs. El chip consiste de una red mesh de 64 "tiles", en la que cada "tile" contiene un procesador de propósito general, caché, y un router que se utiliza para comunicarse con otros tiles.
· Inclusión preliminar de fanotify, una nueva interfaz de notificación de archivos: Las APIs para la notificación de eventos sucedidos sobre archivos definitivamente no han sido el punto fuerte de Linux. La cosa empezó con dnotify, que era una basura. Robert Love lo sustituyó con inotify como parte del en su día famoso "Proyecto Utopía". Sin embargo, los autores de inotify se conformaron con hacer una interfaz que les sirviera a ellos y que fuera mejor que dnotify (no muy difícil). Fnotify solventa las condiciones de carrera y problemas de escalabilidad de inotify y dnotify e incluso permite notificación con bloqueo previo. Las APIs de dnotify y inotify siguen existiendo, pero su código interno ha sido reescrito para basarse en el motor de fanotify. Se puede encontrar un ejemplo de uso de fanotify en este repositorio. Nótese que las llamadas al sistema de fanotify se encuentran desactivadas en esta versión hasta que los desarrolladores acuerden una API adecuada.
· Integración KMS+KDB: Gracias a las bondades de KMS, en esta versión será posible activar el depurador del kernel KDB estando en la misma sesión X. Presionando Sysrq-g mostrará la consola KDB, y al salir (usando el comando KDB) se volverá al escritorio. De momento, esta integración solamente está disponiblepara chips Intel. Las instrucciones para compilar y activar esta funcionalidad pueden encontrarse aquí.
· Workqueues optimizadas para la concurrencia: Las workqueues son una especie de pool de threads que permiten añadir a una cola trabajo que hacer. Sin embargo, el sistema actual permitía crear varias workqueues, las cuales podrían competir entre ellas por la CPU. En esta versión, y tal como ya se trató en este blog, se ha implementado una solución análoga al GCD de Apple: Existe un mecanismo que regula la cantidad de threads disponibles para ejecutar workqueues y encargado de distribuir los trabajos entre ellos, de modo que se optimizan los recursos.
· Soporte de la "gestión inteligente de energía" de Intel: En las plataformas con chips Intel i3/5 y gráficos integrados, existe la capacidad de sincronizar las variaciones de frecuencia de la CPU y la GPU simultáneamente para alcanzar un consumo y rendimiento concretos. En esta versión, Linux añade un driver que implementa esta funcionalidad.
· Cacheo local en CIFS: FS-Cache es una capa de cacheo que permite que los sistemas de archivos de red implementen un caché local. FS-Cache fue incluido en Linux 2.6.30 con soporte de NFS y AFS; en esta versión se ha añadido soporte para CIFS.
· Mejorar la respuesta del escritorio en casos raros: Existen algunos casos en los que un escritorio se puede volver verdaderamente inusable al utilizar un dispositivo de almacenamiento USB bajo cierta presión de memoria. En esta versión, se han corregido esos casos.
· Inclusión de AppArmor: AppArmor es un sistema de seguridad MAC que fue desarrollado inicialmente por Immunix en 1998 y ha sido utilizado por algunas distros como alternativa a SELinux. La diferencia fundamental entre ambos es que SELinux aplica políticas de seguridad a "etiquetas" que se asignan a archivos, y AppArmor aplica las políticas a las rutas de archivo.
Esto viene a ser todo. Como siempre, aquí está la lista completa.
· Soporte para la arquitectura Tilera: El procesador Tile, de Tilera Corporation, es una nueva arquitectura diseñada para ser multicore y soportar cientos de cores en un solo chip. El objetivo es conseguir una CPU de gran rendimiento y energéticamente eficiente, con más flexibilidad que los chips de propósito específico como DSPs. El chip consiste de una red mesh de 64 "tiles", en la que cada "tile" contiene un procesador de propósito general, caché, y un router que se utiliza para comunicarse con otros tiles.
· Inclusión preliminar de fanotify, una nueva interfaz de notificación de archivos: Las APIs para la notificación de eventos sucedidos sobre archivos definitivamente no han sido el punto fuerte de Linux. La cosa empezó con dnotify, que era una basura. Robert Love lo sustituyó con inotify como parte del en su día famoso "Proyecto Utopía". Sin embargo, los autores de inotify se conformaron con hacer una interfaz que les sirviera a ellos y que fuera mejor que dnotify (no muy difícil). Fnotify solventa las condiciones de carrera y problemas de escalabilidad de inotify y dnotify e incluso permite notificación con bloqueo previo. Las APIs de dnotify y inotify siguen existiendo, pero su código interno ha sido reescrito para basarse en el motor de fanotify. Se puede encontrar un ejemplo de uso de fanotify en este repositorio. Nótese que las llamadas al sistema de fanotify se encuentran desactivadas en esta versión hasta que los desarrolladores acuerden una API adecuada.
· Integración KMS+KDB: Gracias a las bondades de KMS, en esta versión será posible activar el depurador del kernel KDB estando en la misma sesión X. Presionando Sysrq-g mostrará la consola KDB, y al salir (usando el comando KDB) se volverá al escritorio. De momento, esta integración solamente está disponiblepara chips Intel. Las instrucciones para compilar y activar esta funcionalidad pueden encontrarse aquí.
· Workqueues optimizadas para la concurrencia: Las workqueues son una especie de pool de threads que permiten añadir a una cola trabajo que hacer. Sin embargo, el sistema actual permitía crear varias workqueues, las cuales podrían competir entre ellas por la CPU. En esta versión, y tal como ya se trató en este blog, se ha implementado una solución análoga al GCD de Apple: Existe un mecanismo que regula la cantidad de threads disponibles para ejecutar workqueues y encargado de distribuir los trabajos entre ellos, de modo que se optimizan los recursos.
· Soporte de la "gestión inteligente de energía" de Intel: En las plataformas con chips Intel i3/5 y gráficos integrados, existe la capacidad de sincronizar las variaciones de frecuencia de la CPU y la GPU simultáneamente para alcanzar un consumo y rendimiento concretos. En esta versión, Linux añade un driver que implementa esta funcionalidad.
· Cacheo local en CIFS: FS-Cache es una capa de cacheo que permite que los sistemas de archivos de red implementen un caché local. FS-Cache fue incluido en Linux 2.6.30 con soporte de NFS y AFS; en esta versión se ha añadido soporte para CIFS.
· Mejorar la respuesta del escritorio en casos raros: Existen algunos casos en los que un escritorio se puede volver verdaderamente inusable al utilizar un dispositivo de almacenamiento USB bajo cierta presión de memoria. En esta versión, se han corregido esos casos.
· Inclusión de AppArmor: AppArmor es un sistema de seguridad MAC que fue desarrollado inicialmente por Immunix en 1998 y ha sido utilizado por algunas distros como alternativa a SELinux. La diferencia fundamental entre ambos es que SELinux aplica políticas de seguridad a "etiquetas" que se asignan a archivos, y AppArmor aplica las políticas a las rutas de archivo.
Esto viene a ser todo. Como siempre, aquí está la lista completa.
Suscribirse a:
Entradas (Atom)