Soporte Multi-Touch desde Ubuntu Maverick Meerkat

Canonical acaba de anunciar el lanzamiento de uTouch 1.0, el stack para soporte multi-touch y de gestures para la distribución Ubuntu de GNU/Linux. Con Ubuntu 10.10 (Maverick Meerkat), los usuarios y desarrolladores tendrán a disposición un framework para touch-screen, directamente desde el kernel y disponible para todas las aplicaciones.

Para completar el stack, el equipo de Canonical ha creado un motor de reconocimiento de ‘gestures’ como también una API para gestures que provee los medios para que las aplicaciones puedan capturar y utilizar los eventos del motor uTouch.

Según Canonical, el éxito de las aplicaciones táctiles, dependerá de algunos factores que considera claves:

– la integración de los toolkits con las APIs para gestures,
– soporte táctil para aplicaciones implementadas con anterioridad,
– el diseño de nuevas aplicaciones, pensando en la interacción basada en los dedos.

También comentan que están trabajando en esos tres frentes y que esperan mantenerla como un área de mayor interés en las próximas iteraciones de releases, incluída hasta la 12.04 LTS, y que se están trabajando con fabricantes de productos táctiles y los proveedores de las tecnologías subyacentes, con el objetivo de llevar estas innovaciones a un público más amplio.

LSB 4.0 para fines de 2008

Las distintas distribuciones Linux tienen diferencias en sus componentes, como versiones de bibliotecas y aplicaciones Esta divergencia motivó al nacimiento de LSB (Linux Standard Base).

Para fines de este año será publicado LSB 4.0 (Linux Standard Base) esperando que los desarrolladores independientes puedan crear aplicaciones para ser utilizadas por cualquier distribución que contemple el estánrd LSB. Si se logra una adopción de LSB por una buena cantidad de distribuciones GNU/Linux, este podría ser el comienzo de una nueva era en cuanto al desarrollo de las aplicaciones.

El objetivo de la LSB es desarrollar y promover un conjunto de estándares que aumentarán la compatibilidad entre las distribuciones Linux y que permitirán que los programas puedan ser ejecutados en cualquier sistema Linux que se adhiera a el.

La LSB especifica: librerías estándar, un conjunto de comandos y utilidades que extiendan el estándar POSIX, una estructura jerárquica del sistema de archivos, los niveles de ejecución (runlevels) y varias extensiones al sistema gráfico XWindow.

LSB define tamibién el conjunto central de la API (del inglés Application Programming Interface o Interfaz de Programación de Aplicaciones) y bibliotecas, de forma que los distribuidores independientes puedan desarrollar aplicaciones que puedan funcionar en cualquier distribución de GNU/Linux certificada para LSB. La Fundación Linux actualizó LSB por última vez en febrero con la versión 3.2.

Según el director ejecutivo de la Fundación Linux, Jim Zemlin, “Es de importancia crítica para Linux, tener una forma fácil para que los desarrolladores puedan escribir código para cualquier distribución, ya sea Red Hat, Ubuntu o Novell.”

Comparación de filesystems Hammer y Tux3

En palabras de Daniel Phillips, “La gran ventaja de Hammer sobre Tux3 es que la primera está siendo utilizada actualmente en la distro Dragonfly”, quien ofrece una comparación entre los dos sistemas de archivos. Continúa: “la mayor desventaja es que se ejecuta en BSD, no en Linux, y que utiliza fuertemente funcionalidades provistas por el VFS y capa de bloques que portar a Linux no sería para nada trivial. De todas formas podría suceder, pero probablemente en el mismo lapso en que Tux3 se convirtiera en estable.” Esto llevó a una larga e interesante discusión técnica entre Daniel y el autor de Hammer, Matthew Dillon, quienes compararon el diseño de ambos sistemas de archivos.

Matthew hizo su revisión de Tux3 y respondió, “suena como si Tux3 estuviera usando varias ideas similares a las de Hammer. Pienso que estás en la senda correcta. Agregaré una gran nota de atención, a partir de mi experiecia implementando Hammer, porque pienso que vas a llegar tarde o temprano a las mismas cuestiones por las que yo pasé. Dediqué 9 meses a diseñar Hammer y 9 meses a implementarlo. Durante el transcurso de la implementación tuve que deshacerme de un 80% de las ideas originales de diseño.” Daniel apuntó que está trabajando en el diseño de Tux3 desde hace unos diez años, “y trabajando seriamente en los elementos simplificadores durante los últimos 3 años, tanto enteramente en papel como en trabajos relacionados como ddsnap y LVM3.” Matthew advirtió, “Si me queda una preocupación acerca de tu implementación, esta radica en el área de la complejidad algorítmica. Tenés que lidiar con el cache in-memory, el log, árboles-B, además de indexado secundario para elementos “snapshotted” y una tonelada de casos especiales que van apareciendo por todos lados. Tu código general de búsqueda se hará muy pero muy complejo. Mi diseño original para Hammer era mucho más complejo (¡si puedes creerlo!), entonces… el resultado final. Una buena cantidad de lo que tuve que hacer al llevar el concepto a la realidad fue desinflar un poco esa complejidad.” La amistosa conversación ofreció un panorama muy detallado sobre la elecciones realizadas para el diseño en cada uno de estos filesystems.

De aquí se puede bajar el diseño del filesystem Hammer, de Matt Dillon:

http://apollo.backplane.com/DFlyMisc/hammer01.pdf

Fuente: KernelTraphttp://kerneltrap.org/Linux/Comparing_HAMMER_And_Tux3