(cc) por Louis VOLANT

El código de Android fue eliminado de la rama principal de Linux (núcleo) por no cumplir con lo necesario para ser integrado oficialmente.  La medida se tomó tras varios intentos por lograr que Google hiciera los cambios que exigen los desarrolladores de Linux, incluyendo ofertas de horas de ingeniería.

Hace poco, la permanencia del código de Microsoft también fue puesta en duda, ya que los drivers que entregaron no cumplían con los estándares que requiere el código para ser aceptado.  A diferencia de Google, los desarrolladores de Microsoft si hicieron caso del llamado de atención y están trabajando para mejorar su código.

En Linux no se trata de llegar y meter código, aquí  no aplica el famoso dicho de “a caballo regalado no se le miran los dientes”.  Independiente de quién entregue el código, si no alcanza el nivel requerido de calidad, simplemente no es aceptado.

Como esta exigencia complicaba a muchos fabricantes y desarrolladores independientes que quisieran participar por primera vez, se creó un área especial en el kernel para alojar el código que estaba en desarrollo o no cumplía con los niveles mínimos de calidad para ser aceptado oficialmente. Inicialmente se llamó “The Crap” (o la porquería) y ahora se conoce como Staging Area o Área de Ensayo.

La idea del Área de Ensayo es dejar en claro cuál es el código que necesita trabajo, por ser defectuoso, poco confiable o bajo los estándares mínimos, pero si el código es abandonado por quien lo envió, simplemente se elimina y eso lo que pasó con Google.

Se requiere el esfuerzo de Google para destrabar la aceptación

Greg Kroah-Hartman, líder de Linux Driver Project, indica que además el código de Android tiene una dificultad adicional:  No se trata simplemente de drivers, sino que requiere cambios al interior de Linux.  Cuando el código llegó, los desarrolladores de Linux identificaron algunos problemas y se los mostraron a Google, pero la compañía no hizo nada para corregirlo, por lo que esos cambios internos sólo existen en la versión de Linux que Google maneja internamente.

Mientras Google no corrija su código, no se podrán hacer los cambios que Android necesita, y esto está causando un problema adicional: Varios fabricantes que hicieron drivers para Android tampoco pueden lograr que sus drivers sean aceptados en Linux mientras el código de Google no sea corregido y aplicado oficialmente.

Lo irónico es que el mismo Greg es un feliz usuario de Android y como muchos otros, está muy interesado en que este problema se resuelva.  Pero mientras el código de Android no se integre en Linux, sólo Google puede hacer los cambios que se requieren.

Link: Android and the Linux kernel community (blog de Greg Kroah-Hartman)

(cc) por Aaron Hockley

En una reciente entrevista publicada por la revista Linux User & Developer, el líder de Linux Driver Project, Greg Kroah-Hartman destacó a la empresa Intel como un gran caso de éxito contribuyendo al núcleo del sistema operativo y a otros componentes claves, como el sistema gráfico.

Greg fundó Linux Driver Project hace 4 años como un esfuerzo unificado para desarrollar drivers para Linux, generando documentación y ayudando a las empresas de hardware a crear y mantener sus propios drivers.  Hoy en día hay unos 400 usuarios que se mantienen suscritos a la lista de correo del proyecto, y muchos de ellos son desarrolladores activos de drivers.

En estos 4 años, Intel ha hecho un gran trabajo contribuyendo a Linux de varias formas, tanto contratando ingenieros que son muy activos en la comunidad como Keith Packard, y entrenando a su propia gente para incorporarla en este trabajo.

En la misma entrevista indicó que lo sucedido con los drivers de Microsoft, respecto a que necesitaron muchos cambios para ser considerados como aceptables en Linux, también ha sucedido con otras empresas que finalmente aprendieron a participar en el desarrollo de Linux como es el caso de Google y por supuesto Intel.

El crecimiento de Greg junto a Linux Driver Project

Greg relata que se inició escribiendo drivers USB a través de ingeniería inversa, pero que a medida que los fabricantes comenzaron a entregar documentación, aplicar estas técnicas se ha hecho cada vez menos necesario.  Greg dice que se siente cómodo trabajando en drivers USB porque conoce muy bien este subsistema, pero que cada vez es más difícil encontrar hardware USB que necesite nuevos drivers, por lo que su trabajo en esa área ha ido perdiendo prioridad en el tiempo.

También destaca el trabajo hecho por Linux Printing Project/OpenPrinting, en donde se han implementado los drivers para impresoras con la participación de importantes fabricantes como HP.  Este proyecto funciona fuera del kernel ya que se trata de capas de mayor abstracción que se apoyan en subsistemas de bajo nivel ya construidos (como USB, SCSI).  En Linux Printing Project han logrado que el uso de impresoras en Linux haya dejado de ser una preocupación para la mayoría de los usuarios.

Finalmente dice que una de las cosas que más ha aprendido como mantenedor de Linux es sobre humildad, ya que siempre hay alguien mejor que uno y que puede localizar problemas en el código propio.  Lo bueno es que esto a la larga hace que el código mejore sin importar quién sea el responsable, y más aún, sin importar a qué empresa pertenece.

Hay un objetivo global de lograr que Linux sea cada vez mejor y cada compañía se preocupa de trabajar en el área que más le interese, lo que hace que en conjunto se tenga un proyecto suficientemente versátil para ser usado en ambientes que van desde los supercomputadores a los teléfonos celulares.

Es sólo a través de miles de diferentes colaboradores, y cientos de compañías, todos trabajando en conjunto para mejorar Linux para ellos mismos, que algo como esto ha evolucionado.  Ha cambiado la forma en que la gente piensa sobre las prácticas de la ingeniería de software, y cómo los grandes proyectos se pueden construir y llevar a cabo.

Link: Greg Kroah-Hartman speaks (Linux User & Developer)

(cc) by Aaron Hockley

El líder de Linux Driver Project, Greg Kroah-Hartman, tuvo que alzar la voz ya que un grupo de drivers añadidos al kernel de Linux habían sido abandonados por sus autores, lo que ponía en duda su permanencia.  Entre estos drivers se encontraban los incorporados por Microsoft para mejorar el rendimiento de Linux al correr sobre Hyper-V de Microsoft.

En el kernel de Linux existe un área especial llamada Staging Area en donde se encuentra todo el código que no está suficientemente maduro para ser incorporado oficialmente.  Esta separación ayuda a enfocar los esfuerzos identificando todo aquel código que necesita trabajo.

Los drivers de Microsoft se encontraban en esta área, pero después del anuncio que acaparó los medios especializados, desaparecieron sus desarrolladores y el código cayó en un estado de abandono.  No se podía aceptar el código tal como fue entregado, ya que entre otros problemas, no cumplía con un requisito mínimo: Estar construido siguiendo los estándares de codificación definidos para el kernel de Linux.

El mismo Greg aplicó unos unos 200 parches para corregir este problema, sin embargo era inaceptable que los desarrolladores simplemente arrojaran el código ahí sin encargarse de mantenerlo, por lo que Greg anunció que si no aparecía ningún responsable, el código sería eliminado para el release 2.6.32

Finalmente aparecieron los desarrolladores, que ni siquiera contestaban los correos de Greg.  Aunque se comprometieron a trabajar en su código, hasta ahora sólo han actualizado la lista de tareas por hacer (TODO list).

Greg dice que esta situación es común, y es normal que después de un llamado de atención aparezcan los responsables del código.  En esta ocasión fueron 25 los drivers cuestionados, de los cuales la mayoría ya han aclarado su situación.

Links:
- Linux driver chief calls out Microsoft over its driver code submission (ComputerWorld)
- Staging tree status for the .32 kernel usage (blog de Greg Kroah-Hartman)

Linux Driver Project ataca el problema de raíz: Las empresas interesadas sólo deben entregar la documentación de cómo interactuar con su hardware y un grupo de desarrolladores se encarga de escribir el driver para incluirlo en el kernel de Linux.  Posteriormente si la empresa lo desea, puede ser capacitada para mantener el driver por sí misma.

La estrategia ha funcionado bastante bien, con unos 200 desarrolladores ya se han escrito varios drivers en esta modalidad. Algunas compañías ya mantienen por sí mismas el código para su hardware en el kernel, lo que les permite tener un control completo sobre el camino que toman sus drivers en Linux.  La demanda de capacitación es tan grande que se está buscando a más gente para que ayude a las compañías a adquirir este conocimiento.

Hasta hace un tiempo, otro de los problemas para integrar código al kernel eran los estándares de calidad exigidos, esto hacía que algunos drivers que se encontraban en desarrollo no podían ser integrados en el kernel, obligando al pobre usuario a descargarlo desde internet y realizar indeterminados pasos para dejarlo andando.  Ahora se ha creado un área especial del kernel en donde se da cabida al código que está en pleno desarrollo, para que los usuarios con este hardware puedan contar con el soporte inmediato, sin esperar a que el código sea integrado oficialmente.  El resto de los usuarios no se ve afectado, ya que simplemente no utiliza este código, al final todos ganan.

Bonus track : ¿Y qué dicen los fabricantes?

Para algunas empresas como Dell y HP, el soporte de drivers en Linux ya no es un tema.  Una de las acciones que han aplicado es trabajar codo a codo con sus partners de hardware y preocuparse de que se provea el soporte necesario a Linux. Esto no es de extrañar, ya que ambas compañías tienen lineas de servidores de todo tamaño y como se sabe desde hace mucho tiempo, el área de los servidores es el hábitat natural para este sistema operativo.

Donde se ven novedades es en el área del escritorio.  Si bien Linux aún está lejos de llegar al mercado hogareño, en el mercado corporativo ya está comenzando a abarcar los escritorios, especialmente en aquellos que antes eran dominados por sistemas Unix : empresas de producción cinematográfica y efectos especiales, las compañías top de Wall Street, el área de la banca, ingeniería como Audi y Peugeot, etc.

El escritorio corporativo tiene varias ventajas sobre el hogareño cuando se trata de cambiar de sistema operativo.  Como se trata de grandes volúmenes, por ejemplo en Audi son unos 20.000 escritorios, se trata de hardware uniforme y certificado para funcionar sobre el sistema, con áreas de soporte especializadas para asegurar que toda la maquinaria productiva se mantenga funcionando.

Ante esta realidad, los proveedores de estaciones de trabajo corporativas deben asegurar que su hardware funcione correctamente con Linux, en forma indirecta estas mejoras terminan llegando al resto de los usuarios.

Links:
- Requests for Linux drivers flowin in (ZDNet Asia)
- Linux Driver Project status report as of June 2009 (Linux Kernel Monkey Blog)

©2008 CBS Interactive Inc. Used by permission.

El aporte de Microsoft de unas 20.000 líneas de código licenciados como GPL para Linux no pasó desapercibido para quienes conocen la historia de la compañía respecto al desarrollo de código abierto, y sobre todo del sistema que numerosas veces ha sido descrito como su mayor amenaza.

La compañía que una vez trató de promover el mensaje de que Linux era un cáncer, sorprendió a todos anunciando su primer aporte directo a este sistema operativo, pero para algunos no se trató de un hecho digno de alabanza, sino de una acción que la compañía necesitaba tomar para evitar un problema de licenciamiento mayor.

Esto puede tener varias interpretaciones, una de ellas ha sido muy comentada en la red y se enfoca en la idea de que Microsoft simplemente resolvió un problema de licenciamiento y se vio obligado a adoptar la licencia GPL, para luego anunciar el hecho como un acto heroico y de buena voluntad.

Otra visión muy distinta es la de los desarrolladores de Linux que se vieron directamente involucrados en el asunto.  Steve Hemminger relata que los usuarios de Vyatta comenzaron a preguntar por el driver necesario para Hyper-V y éste se encontraba disponible pero con el problema de que combinaba código GPL con código binario, lo que está prohibido por la licencia GPL.  Por lo tanto él se puso en contacto con Greg Kroah-Hartman – quien trabaja para Novell en el Linux Driver Proyect – para que realizara las acciones necesarias que permitieran resolver el problema con Microsoft.

Greg dice que éste no se trata de un caso particular, y en muchas ocasiones ha trabajado con distintas compañías para ayudarles a resolver este tipo de problemas e incluir su código en Linux.  Greg dice que esto sucede al menos con dos compañias nuevas cada mes, pero como esta vez se trató de Microsoft, el asunto tomó mayor vuelo.

Link : It’s getting cold here (blog de Greg Kroah-Hartman)

Andrew Morton y Keith Packard (cc) by Linux Foundation

Y seguimos con noticias desde Linux Collaboration Summit en San Francisco.  En esta ocasión los muchachos de Ars Technica nos cuentan que hubo un interesante panel acerca del desarrollo del kernel de Linux en donde participaron destacados hackers.  Entre los temas que se tocaron estuvieron los sistemas de archivo, la arquitectura gráfica, y el rol de “la porquería” en el desarrollo del kernel.  Así es, hablaremos de “la porquería” (the crap(tm))

El panel del kernel fue una de las discusiones más técnicas que se llevaron a cabo en el evento.  Este panel fue moderado por Jonathan Corbet, editor del prestigioso medio LWN.net .  Los convocados fueron :

• Andrew Morton : uno de los principales desarrolladores del kernel de Linux. Tiene su propia rama en donde se prueban cambios que posteriomente entran a la rama de Linus Torvalds.  Andrew fue contratado por Google en el año 2006 para dedicarse por completo al desarrollo del kernel.
• Greg Kroah-Hartman : encargado del soporte de USB y creador de udev entre otros.  Trabaja a tiempo completo para Novell en el Linux Driver Project, una iniciativa para implementar drivers de código abierto con la cooperación de los fabricantes de hardware.  Greg es el fundador de este proyecto que hoy tiene más de 200 desarrolladores.
• Theodore Ts’o (Ted) : Es el desarrollador conocido por colaborar en el área de sistemas de archivo en Linux. Es el principal culpable del veloz ext4. Trabaja bajo el alero de Linux Foundation y tiene planes de volver a IBM a fines de año.
• Keith Packard : es el hombre responsable de las impresionantes mejoras que se han realizado en el sistema gráfico de Linux en la última década.  Aceleración por hardware, escritorios 3D, alpha blending, etc.  Trabaja en X Window desde la década de los 80.  Inició revolución gráfica mientras trabajaba para HP Labs y actualmente se encuentra en las filas de Intel.

La porquería

Kroah-Hartman discutió acerca de un área especial del kernel que se incluyó en la versión 2.6.28 para mantener en forma separada un conjunto de componentes y drivers del kernel que estuvieran incompletos o inestables.  La comunidad del kernel le llamó “la porquería”.

Esta área ayuda a que estos componentes sin terminar sean mas visibles y así atraigan el interés de otros desarrolladores para completarlos y llevarlos a un nivel de madurez suficiente para su uso normal.  La gran cantidad de mejoras que se hicieron a la porquería en la versión 2.6.30 demuestra que esta definición efectivamente ha servido para su propósito original.

El kernel y su influencia en el área gráfica

Keith Packard describió algunos cambios que se han realizado a la arquitectura gráica de Linux.  Hay componentes que se han sacado desde lo que se conoce como userspace y se han incluido como parte del kernel.  Aqui encontramos la arquitectura de aceleración (UXA), la configuración de los modos de video (KMS) y la administración de memoria (GEM).

Estos cambios han reducido las barreras para crear nuevos tipos de sistemas gráficos para la plataforma Linux, incluso ya han surgido algunos experimentos interesantes como es Wayland.

Packard explicó que los drivers gráficos son extremadamente complejos y que construirlos requiere un gran compromiso de tiempo, recursos y dedicación de los fabricantes.  Intel ha hecho una inversión significativa en la arquitectura gráfica para mejorar la compatibilidad de Linux con el hardware de Intel.  Por otra parte dice que ATI ha comenzado a tomar un rol activo permitiendo que la comunidad de soporte a sus chips.  Nvidia aun no ha llegado a este nivel de compromiso.

Ext4 : un refrito de tecnología de los ’70

Ted Ts’o habló sobre ext4 y cómo ha sido bien recibido por las distribuciones como Ubuntu y Fedora que lo incluyen como opción de instalación.  Se espera que pronto ext3 deje de ser el sistema de archivos por omisión en las distribuciones más populares.

Aunque ext4 agrega interesantes características, Ts’o no lo ve como un gran avance.  Incluso le baja el perfil a ext4 calificándolo como un refrito de tecnología de los ’70 y lo describe como una solución de corto plazo mas bien conservadora.  Cree que el camino a seguir es Btrfs, el sistema de archivo que viene de las manos de Oracle en donde si hay mejoras significativas respecto a escalabilidad, confiabilidad y facilidad de administración.

Al concluir el panel, Linux Foundation entregó por primera vez el premio del héroe anónimo (Unsung Hero) a Andrew Morton por su rol como mantenedor de la rama mm del kernel.

Link : Panelists ponder the kernel at Linux Collaboration Summit (Ars Technica)