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.
30 de septiembre de 2010
Azure: Un pasito adelante y un pasito hacia atrás
Desde que Steve Ballmer anunció que Microsoft se lo jugaba todo a la carta de la computación en forma de 'nubes' (si, todos odiamos el término, pero no merece la pena rebelarse) no se han oido muchas cosas sobre el tema. Sin embargo, en el breve espacio de dos días se han producido dos noticias muy reveladoras.
En una de ellas, Microsoft acaba de convencer al Estado de Minnesota para que migre a 30.000 de sus usuarios a Azure. Que yo sepa, este es uno de los primeros grandes casos de migración masiva a una nube, y tal vez advertencia de lo que se viene encima a los sysadmins en los años venideros. Las compañías o instituciones que adopten este modelo no quieren tener un departamento de IT, del mismo modo que no quieren tener un taller de reparación de coches propio. Prefieren "subcontratar" todo lo que puedan a la nube, hacer que los clientes se autentifiquen y comuniquen con una instancia Azure ubicada en servidores de Microsoft en lugar de hacerlo en un servidor local. Como plantilla de IT se mantiene a los programadores que desarrollen aplicaciones para la nube (o se subcontrata a una consultora), y poco más. Las empresas se ahorran complejidad y parece ser que también dinero.
Pero no nos vayamos por las nubes (¿Lo han pillado? Ja. Ja.): Cuando hablamos de movimientos de IT en instituciones, es inevitable hablar de lobbing. ¿Cuánto dinero se ha gastado Microsoft en intentar convencer a Minessota? ¿Qué generosas ofertas les ha hecho, con cargo a las deudas de Microsoft, solo por conseguir un cliente que puede funcionar como marketing -"miren lo que hicieron en Minessota"- para abrirle la puerta de muchos otros? Que conste que no pretendo acusar a nadie de malas prácticas, esto es algo normal en cualquier negocio. Pero solo el tiempo nos aclarará lo verdaderamente efectivo, sencillo y costoso que puede llegar a ser la idea esta de deslocalizar departamentos de IT a un cluster.
Por otro lado, Microsoft ha anunciado que Live Spaces, su plataforma de blogs, pasa a mejor vida, y se pasa a Wordpress. Lo cual es completamente alucinante. A ver, Microsoft tuvo un déficit de 696$ millones en su división online en el último trimestre, eso son 6$ millones perdidos al día (gastar, gastan aun más). ¿Y no son capaces de desarrollar una plataforma de blogs decente? Dicen que van a "apostar todo en la nube", que quieren convertirse en los reyes de internet. ¿Merece dominar Internet una empresa que tiene que "deslocalizar" algo tan esencial como los blogs? ¿Con qué argumentos va a vender la moto de Windows+IIS+ASP.Net+SQL Server una compañía que tiene que deslocalizar su plataforma de blogging a otra basada en LAMP? Si Azure es tan potente...¿por qué no reconvertir Live Spaces, Hotmail, y los demás servicios gratuitos de Live para funcionar en una especie de instancia gratuita Azure independiente para cada usuario?
Resumiéndolo en una pregunta: ¿Puede fiarse Minessota de mover toda su infraestructura a Azure, cuando el propio creador de Azure no es capaz de desarrollar una plataforma de blogs exitosa sobre su propio invento?
En una de ellas, Microsoft acaba de convencer al Estado de Minnesota para que migre a 30.000 de sus usuarios a Azure. Que yo sepa, este es uno de los primeros grandes casos de migración masiva a una nube, y tal vez advertencia de lo que se viene encima a los sysadmins en los años venideros. Las compañías o instituciones que adopten este modelo no quieren tener un departamento de IT, del mismo modo que no quieren tener un taller de reparación de coches propio. Prefieren "subcontratar" todo lo que puedan a la nube, hacer que los clientes se autentifiquen y comuniquen con una instancia Azure ubicada en servidores de Microsoft en lugar de hacerlo en un servidor local. Como plantilla de IT se mantiene a los programadores que desarrollen aplicaciones para la nube (o se subcontrata a una consultora), y poco más. Las empresas se ahorran complejidad y parece ser que también dinero.
Pero no nos vayamos por las nubes (¿Lo han pillado? Ja. Ja.): Cuando hablamos de movimientos de IT en instituciones, es inevitable hablar de lobbing. ¿Cuánto dinero se ha gastado Microsoft en intentar convencer a Minessota? ¿Qué generosas ofertas les ha hecho, con cargo a las deudas de Microsoft, solo por conseguir un cliente que puede funcionar como marketing -"miren lo que hicieron en Minessota"- para abrirle la puerta de muchos otros? Que conste que no pretendo acusar a nadie de malas prácticas, esto es algo normal en cualquier negocio. Pero solo el tiempo nos aclarará lo verdaderamente efectivo, sencillo y costoso que puede llegar a ser la idea esta de deslocalizar departamentos de IT a un cluster.
Por otro lado, Microsoft ha anunciado que Live Spaces, su plataforma de blogs, pasa a mejor vida, y se pasa a Wordpress. Lo cual es completamente alucinante. A ver, Microsoft tuvo un déficit de 696$ millones en su división online en el último trimestre, eso son 6$ millones perdidos al día (gastar, gastan aun más). ¿Y no son capaces de desarrollar una plataforma de blogs decente? Dicen que van a "apostar todo en la nube", que quieren convertirse en los reyes de internet. ¿Merece dominar Internet una empresa que tiene que "deslocalizar" algo tan esencial como los blogs? ¿Con qué argumentos va a vender la moto de Windows+IIS+ASP.Net+SQL Server una compañía que tiene que deslocalizar su plataforma de blogging a otra basada en LAMP? Si Azure es tan potente...¿por qué no reconvertir Live Spaces, Hotmail, y los demás servicios gratuitos de Live para funcionar en una especie de instancia gratuita Azure independiente para cada usuario?
Resumiéndolo en una pregunta: ¿Puede fiarse Minessota de mover toda su infraestructura a Azure, cuando el propio creador de Azure no es capaz de desarrollar una plataforma de blogs exitosa sobre su propio invento?
Suscribirse a:
Entradas (Atom)