Pero hasta hace poco, no se sabía mucho de qué uso y qué tipo de problemas encontraba Google en su intensivo uso de Linux.  Digo hasta hace poco porque en el reciente Kernel Summit realizado en Japón, Mike Waychison de Google asistió para exponer a los principales hackers del kernel, el uso que este gigante informático le da a Linux.

Google usa un sistema de control de versiones del software bastante arcaico para lo que está acostumbrada la comunidad del código abierto, lo que provocó risas en los asistentes.  Se trata de Perforce, y en comparación a nuevos sistemas como Git, tiene limitaciones o modos de trabajo que uno jamás pensaría que tendrían en Google.  No es de extrañar el interés despertado en los asistentes a la presentación que hizo Linus Torvalds sobre Git en Google hace un tiempo atrás.

Y eso es sólo el comienzo, ya que Google maneja versiones bastante atrasadas de Linux.  Alrededor de 30 ingenieros trabajan sobre una única base de código, aplican cambios y aproximadamente cada 18 meses sincronizan su propia versión con una versión pública de Linux.  Al ritmo que se desarrolla el kernel, la cantidad de cambios acumulados en todo ese tiempo lo convierten en una tarea titánica.

Es tanto así, que muchas de las lineas de código que Google agrega a su propia versión son funcionalidades que se han implementado en Linux pero que no existían en la versión que usaron como base. Así sucedió por ejemplo con el soporte de 64-bit y el soporte de SATA.  Actualmente se están preparando para mezclar con 2.6.26, mientras que la versión pública ya se acerca a 2.6.32.  Los cambios de Google serán aproximadamente 300.000 líneas de código en donde un 25% corresponde a backports de nuevas características.

El código es horrible

Linus Torvalds quien obviamente estaba presente y no fue sólo a sacarse fotos a Japón, preguntó por qué Google no aplicaba sus cambios al kernel público.  Mike respondió que el código era bastante horrible y basado en versiones antiguas de Linux, además de que no tenían seguridad de que los cambios aplicados por ellos tuvieran alguna utilidad para otros y que probablemente sólo la mitad de éste sería publicable.  Hay que recordar que licencias como GPL no obligan a publicar el código que se usa internamente, por lo que Google está en su derecho de no publicar sus cambios.

Otro aspecto importante es que los estándares para aceptar código en el kernel son bastante altos, por lo tanto un cambio que Google puede hacer rápidamente se convertiría en un proyecto de largo o mediano plazo al entrar en un proceso más exigente como es el desarrollo de Linux.

Mike también habló de uno de los aspectos críticos del kernel para Google, que es la forma en que se ejecutan los procesos.  En un sistema multihilos como Linux, existe un componente que se encarga de decidir qué proceso usará la CPU en un momento determinado, este componente se llama scheduler o planificador.  Para Google se trata de un componente en donde los cambios tienen un alto impacto, ya que en sus sistemas corren unos 5000 hilos en 16 a 32 cores, mientras que en el equipo de Linux este aspecto se ataca con criterios de diseño que apuntan a un uso más tradicional.

En general Google aplica varios cambios a medida que los necesita, en forma independiente a cómo se implementan en el kernel, hasta que llega el momento de cambiar de versión. Según los asistentes, esta participación en Linux Summit fue bastante productiva ya que se puede decir que la comunidad aprendió mucho de uno de sus principales y extremos usuarios.

Link: How Google uses Linux (LWN.net)

Tux se ve bien hinchado

Habitualmente, los jóvenes se rebelan de sus padres cuando llegan a la adolescencia. Curiosamente, en el caso del software libre, la lógica se invirtió. Linus Torvalds criticó a Linux, su “hijo” de 18 años, por estar hinchado y enorme. Un buen correctivo paternal.

Durante la LinuxCon, en Portland, Estados Unidos, Tovalds fue consultado sobre los nuevos recursos que se agregan al kernel de Linux, y cómo éstos repercuten en la rapidez y estabilidad del sistema. Según James Bottomley, un reputado ingeniero de software, Linux sufre una caída de un 2% en su desempeño con cada nueva versión, lo que acumula un 12% en sus últimas ediciones. “¿Esto es un problema?”, le consultó a Torvalds.

“El núcleo está hinchado y enorme. Es un problema. Definitivamente no somos el núcleo simplificado e híper-eficiente que imaginé cuando comencé a escribir Linux, y cada que le ponemos una nueva funcionalidad se pone peor”, respondió, sincero, Torvalds.

Pero no todo fue malo en la intervención de Torvalds, quien afirmó que la estabilidad del sistema no se ha visto comprometida, pues los desarrolladores solucionan los bugs apenas los encuentran. Además, dijo que el “engorde” del núcleo es inaceptable, pero completamente inevitable.

Amigos linuxeros, ¿tiene razón don Linus en sus dichos o no? ¿Habrá perdido el norte o es un simple llamado de atención a la comunidad?

Link: Linus calls Linux ‘bloated and huge’ (The Register vía FayerWayer Brasil)

(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)

En esta entrega también se incluye el soporte para Kernel Mode Setting en tarjetas de video basadas en los chips R5xx de ATI, con miras a agregar este soporte a los chips R6xx/R7xx en el próximo release.  Este soporte se complementa con el desarrollo del resto de la infraestructura necesaria para que los chips de ATI queden soportados completamente con código abierto.

También se incluye la implementación del nuevo estándar USB 3.0, en donde Linux es el primer sistema operativo en tener soporte gracias al trabajo de Intel.  Por si esto pareciera poco, también agrega el soporte del nuevo hardware gráfico de Intel (Clarkdale & Arrandale) del cual se tuvo conocimiento al ver los cambios que Intel hacía en el driver de video para su hardware en X.org.

La lista completa de cambios y mejoras a los distintos drivers y subsistemas se puede encontrar en el wiki de Kernel Newbies.

Links:
- Linux 2.6.31 (Kernel Newbies)
- Linux 2.6.31 kernel released, with ATI KMS Glory (Phoronix)

Dada la buena respuesta que han tenido los últimos artículos conceptuales queremos continuar cubriendo algunos temas que son bastante conocidos a nivel de desarrolladores, pero poco manejados por el público general.

En esta ocasión hablaremos de un cambio realizado en Linux que a primera vista se ve poco relevante, pero que al examinar más a fondo abre nuevas oportunidades.  Se trata de Kernel Mode Setting o Configuración de Modo de Video en el Kernel.

Configurar un modo de video es una tarea que puede ser más compleja de lo que parece, sobre todo ahora que existen distintos tipos de salidas de video y hay que preocuparse de muchos más aspectos que de sólo un monitor.

En Linux el código que se encarga de configurar el modo de video se encuentra en varias partes, e incluso se puede apoyar en la BIOS para hacer este trabajo.  Pero esto provoca algunos inconvenientes:

• Algunas BIOS vienen con modos predefinidos que no se ajustan al hardware.  Sucede o sucedía con los primeros laptops que usaron modos widescreen pero cuyas BIOS sólo conocían los modos tradicionales.
• Qué tan correcto sea el manejo del modo de video y las salidas de video dependen exclusivamente de la implementación particular de la aplicación que necesita usar el video, por ejemplo X.org o el terminal en modo de texto.
• Cuando una aplicación configura el modo de video para trabajar en él, debe almacenar su estado y de alguna forma cederlo cuando otra aplicación necesita reconfigurar el modo de video.  Por ejemplo si estamos en una sesión gráfica en X.org y queremos pasar a una sesión de texto (Ctrl-Alt-F1), entonces X.org debe guardar el estado del video antes de que el terminal cambie a modo de texto.  Por otra parte el terminal de texto debe configurar el modo de video que necesita desde cero.  Cuando se vuelve a modo gráfico, se realiza el mismo proceso a la inversa: El terminal de texto guarda el estado, X.org reinicializa el video desde cero y luego restaura el estado que guardó previamente.

Todos al kernel

Con Kernel Mode Setting, la lógica de cambiar de modos de video se elimina de X.org y otras aplicaciones para implementarse únicamente en el kernel.  De esta forma hay sólo una implementación para esta funcionalidad común y todas las aplicaciones que necesiten cambiar de modo de video pueden pedir el servicio al kernel.  Por lo tanto desde el punto de vista de la calidad, ahora todas las aplicaciones compartirán la mejor implementación.

Antes, las aplicaciones no tenían cómo saber a qué modo de video se iba a cambiar, por lo tanto siempre el modo de video se reinicializaba.  Pero como ahora es el kernel quien se encarga de esta tarea, puede detectar que el modo de video que se está pidiendo es el mismo que ya se está usando, por lo que sólo bastará con limpiar la pantalla, sin necesidad de cambiar el modo de video.  Esto reduce al mínimo todos los pestañeos que un usuario de Linux está acostumbrado ver cuando se inicia el sistema.  Al mismo tiempo se asegura el correcto uso de las salidas de video adicionales como es el caso de un proyector o un monitor externo.

Otro cambio importante es que ahora el kernel puede configurar el mejor modo de video lo antes posible.  Por ejemplo, apenas se inicia el kernel, algo que toma un par de segundos, se puede iniciar el modo de video definitivo y desde ese momento en adelante nunca más cambiar, ni tampoco reinicializar.  Por lo tanto el splash de inicio, el gestor de login y el entorno de escritorio usarían todos la misma configuración de video y a ojos del usuario se verían sólo como imágenes de fondo que cambian.

El proceso de suspender el sistema y luego despertarlo se simplifica, ya que es el mismo kernel que está coordinando la suspensión y restauración quien tiene toda la información respecto al estado del video, lo que hace que el proceso entero sea más confiable y rápido como se muestra en el video que acompaña este artículo.

Nuevos horizontes

Ahora se podrán escribir nuevas aplicaciones que usen el video directamente, por ejemplo aplicaciones que funcionen en modo fullscreen y que necesiten su propia configuración.  A ojos del usuario, la aplicación se mantiene en el mismo ambiente, sin embargo se encuentra con una disponibilidad del 100% del hardware de video, sin ni siquiera un sistema de ventanas o un gestor de composición.  Estas nuevas aplicaciones podrían ser un salvapantallas, un juego, reproductor de videos, entornos gráficos livianos como Wayland, escritorios remotos, etc.

Aventurando un poco más la imaginación, se podrían tener transiciones al cambiar de una aplicación a otra, imaginen un cubo que gira como el de Compiz pero que actúa cuando se cambia a modo de texto, cuando se lanza una aplicación en modo fullscreen o cuando se cambia la sesión de usuario.

Distribuciones como Fedora ya incluyen Kernel Mode Setting pero su uso depende de la implementación de los drivers de video que se estén utilizando.  Otras distribuciones como Ubuntu lo integrarán en la siguiente versión.

Link : Artículos de Phoronix respecto a Kernel Mode Setting

En el esquema tradicional, la memoria usada por el código se considera como equivalente a la usada por los datos a la hora de copiarlas al disco cuando la memoria es insuficiente.  Esto provoca que las aplicaciones detengan temporalmente su ejecución cuando el código que necesitan se encuentra en disco.

Para evitar este problema, el código ejecutable tendrá una marca especial para que el sistema operativo haga lo posible por mantenerlo siempre en memoria, sin llevarlo a disco.  El cambio es bastante pequeño, pero los resultados son interesantes.

En pruebas realizadas se detectó que en un escritorio corriendo OpenOffice, Firefox y el entorno GNOME con 512MB, la necesidad de copiar segmentos de memoria desde el disco a RAM se redujo a la mitad, mientras que la cantidad de segmentos que se trajeron desde el disco se redujo a sólo un tercio.  Esto implica que el tiempo necesario para hacer swap se redujo como mínimo a la mitad.

Bonus Track: Memoria física y memoria lógica

En un sistema operativo existe el concepto de memoria física y memoria lógica.  La memoria física es la que provee el hardware (1GB, 2GB, etc).  La memoria lógica es la que ven las aplicaciones.  La memoria lógica se divide en páginas de tamaño fijo y se va asignando a las aplicaciones a medida que éstas lo requieran, el sistema operativo internamente tiene una tabla en donde dice en qué parte de la memoria física está cada página de la memoria lógica, lo que se conoce como mapa de memoria.

Entre todas las aplicaciones se puede usar más memoria lógica que la que se dispone físicamente. Como no se necesita usar toda la memoria al mismo tiempo, algunas páginas que estaban en la memoria física se guardan en disco mientras no se ocupen, luego si se necesitan se traen de vuelta del disco a la memoria física.  Eso es lo que se conoce como swap o intercambio.

Mientras más memoria tenga el equipo, es menor la necesidad de mover páginas al disco, y por lo tanto menor el tiempo perdido en esperar a que las páginas se copien desde o hacia el disco.  Pero si la memoria es poca, frecuentemente se necesita usar el disco para hacer espacio en memoria física, lo que hace que el sistema se comporte más lento.

Con el cambio aplicado en Linux 2.6.31, se mejora la estrategia para decidir qué páginas deben sacarse de RAM cuando hay poca memoria disponible, de tal forma de dejar en memoria física aquellas que se usen intensivamente, eliminando la necesidad de usar el disco.

Link: Make mapped executable pages the first class citizen (log de cambio en el kernel)

Un par de ejemplos visibles de estos cambios son:

• Kernel Mode Setting: En donde parte de la funcionalidad del sistema gráfico se sacó de X.org y se integró en el kernel.  Específicamente se trata de la configuración del modo de video, lo que permite reutilizar un modo gráfico ya configurado para no tener que reinicializar el video al cambiar de sistema de despliegue gráfico, evitando los molestos pestañeos.  También permite que otros sistemas gráficos como Wayland sean más simples de programar.
• FUSE: Se trata de sistemas de archivos que se pueden implementar fuera del kernel, lo que se conoce como User Space (en vez de Kernel Space).   Con FUSE se pueden agregar nuevos sistemas de archivo a Linux sin tener que integrarlos en el kernel, esto permitió implementar tranquilamente el soporte para sistemas de archivo NTFS.

En la próxima versión del kernel se incluirá una nueva extensión llamada CUSE o Character Devices in User Space.  La idea es similar a FUSE, pero en vez de que sean sistemas de archivos externos al kernel, ahora se trata de drivers o controladores de dispositivos externos al kernel.

En Linux y Unix en general se utilizan algunos archivos especiales para comunicar a las aplicaciones con los drivers, se trata de esos archivos que se encuentran en el directorio /dev.  Un problema que surge, especialmente con aplicaciones antiguas, es que las aplicaciones al usar directamente los archivos que están ahí, necesitan que exista el driver relacionado con cada archivo.  Un ejemplo clásico son los archivos /dev/dsp y /dev/mixer que se usaban en el antiguo sistema de sonido Open Sound System.

Con CUSE ahora son aplicaciones las que podrán tomar el control de esos dispositivos especiales y como es de esperar, la primera aplicación práctica es un proxy de OSS que permitirá que las aplicaciones crean que están usando OSS, pero serán direccionadas a PulseAudio/ALSA para aprovechar toda la potencialidad de estos sistemas de audio.

Otro uso propuesto es atender las solicitudes a /dev/pilot que realizan aplicaciones antiguas que se conectan a Palm Pilot.  Con CUSE no será necesario tener un driver especial, sino que se podrá escribir un proxy que tome las solicitudes a /dev/pilot y las convierta en lo necesario para comunicarse con el dispositivo bajo estándares actuales.

Con CUSE, nuevos desarrolladores podrán dar soporte a sus dispositivos de una forma sencilla, y aplicaciones antiguas podrán seguir funcionando, adaptándose automáticamente a las nuevas funcionalidades que se vayan incorporando al sistema.

Links:
- Kernel Log – Coming in 2.6.31: CUSE… (The H Open)
- Character devices in user space (LWN.net)

De acuerdo a un reporte [PDF] por parte de la Fundación Linux no solo es escrito por hackers desinteresados y nerds escondidos en el sótano de casa de sus padres, es decir, programadores sin una afiliación a alguna compañía. Al parecer el “espíritu de software libre” se encuentra más en las compañías que pagan a personas para el desarrollo de Linux, como es el caso de Red Hat, IBM, Novell e Intel.

Para ser exactos los 10 principales contribuyentes en el desarrollo del Kernel de Linux representa el 70% del total, incluido el grupo de “Desconocidos” (7.6%) de los que no se les ha determinado una afiliación corporativa y al menos han hecho 10 cambios o modificaciones al kernel y el grupo “Ninguno” (18.2%) que representa a los desarrolladores que hacen el trabajo por su cuenta sin ninguna atribución financiera.

A pesar del gran número de los desarrolladores individuales, todavía hay un número relativamente pequeño que está haciendo la mayoría de la obra. En los últimos 5 años, los 10 principales desarrolladores individuales han aportado casi el 12% del número de cambios y los 30 principales desarrolladores han contribuido con más del 25%.

Tan solo basta con notar que David S. Miller (2,239 números de cambios, 1.5%) e Ingo Molnar (2,125 cambios, 1.5%) encabezan la lista de contribuciones en el historial de los repositorios desde la versión del Kernel 2.6.12 hasta 2.6.30 (con 11,560,971 líneas de código) y ambos trabajan para la compañía Red Hat.

Tabla de los principales contribuyentes en el desarrollo del núcleo de Linux

1. Ninguno: 18.2 %
2. Red Hat: 12.3%
3. Desconocidos: 7.6%
4. IBM: 7.6%
5. Novell: 7.6%
6. Intel: 5.3%
7. Consultor independiente: 2.5%
8. Oracle: 2.4%
9. Linux Foundation: 1.6%
10. SGI 1.6%
11. Parallels 1.3%
12. Renesas Technology: 1.3%
13. Academia: 1.2%
14. Fujitsu: 1.1%
15. MontaVista: 1.1%
16. MIPS Technologies: 1.1%
17. Analog Devices: 1.0%
18. HP: 1.0%

Ya lo decía Linus Torvalds en relación a la polémica 20,000 líneas de código para el kernel de Linux por parte de Microsoft:

“No me importa de dónde vienen las contribuciones del código mientras haya razones sólidas para su inclusión… Estoy de acuerdo que está impulsado por razones egoístas, pero esa es la razón por la que se escribe todo el código. Así es como empezó Linux, claro que han elegido un área que les favorece. Eso es lo que mueve el open source, la posibilidad de realizar código con el objetivo de favorecer tus necesidades particulares”

Links:
- Who writes Linux: Big Business (ComputerWorld)
- Torvalds y el odio a Microsoft (Muy Computer)

Estoy seguro que olvidamos algo, y sé que hay algunas regresiones pendientes.  Al mismo tiempo, necesitamos la cobertura de un release y en general se ve bastante bien.  Hemos solucionado algunas regresiones en los últimos días, y siempre hay un 2.6.30.x

También agrega que en la documentación oficial algo importante no fue mencionado:

Una cosa que parece no haber sido mencionada es que al parecer estaríamos listos con la re-estructuración del manejo de interrupciones para suspender/resumir, y esto nos lleva a un nuevo orden mundial.  Aunque sospecho que un montón de detalles cambiarán, por supuesto.

El sitio H-Open realizó un exhaustivo análisis de los cambios más importantes, tenemos desde cambios que se quedaron pendientes de ser incluidos oficialmente en 2.6.29 hasta nuevos drivers y sistemas de archivo.

La siguiente es una selección que hemos realizado de lo que encontraremos en esta versión, y que seguramente veremos en las distribuciones que serán lanzadas a fines de año como es el caso de Ubuntu 9.10 en Octubre junto a  Fedora 12 y openSUSE 11.2 en Noviembre.

Mejoras en ext3 y ext4

Se realizaron cambios al sistema de archivos ext4 para prevenir el riesgo de inconsistencias.  Estos cambios hacen que el rendimiento se vea afectado mínimamente en pro de tener un sistema más robusto.

Por otra parte, en ext3 hay dos formas de escribir en el sistema de archivos, una es escribir los datos apenas se necesite, de a pedacitos (data=ordered), y otra es acumular datos en memoria para escribirlos como un sólo bloque grande (data=writeback).  El primer caso requiere acceder más veces al disco, lo que provoca tiempo perdido esperando que el disco termine de grabar.  Es lento pero seguro, ya que los datos se escriben lo antes posible para no perderlos en caso de un corte de energía.  El segundo caso es una especie de caché de escritura, no pierde tiempo en esperas pero en caso de corte de energía se pierden los datos que estaban en memoria y no se escribieron en el disco. En esta versión se incluye un nuevo modo que es un punto intermedio entre ambos casos, es seguro pero no tan rápido como writeback.

Otro cambio es el manejo del famoso atributo atime o access time: Cuando se accede un archivo, se modifica su fecha de acceso lo que obliga a escribir en el disco cada vez que se lee un archivo.  Por mucho tiempo, los power users desactivaban la escritura de este atributo para mejorar el rendimiento de las lecturas.  Dado que ahora son pocas las aplicaciones que necesitan tener un valor exacto en ese campo, se ha modificado el sistema para escribirlo sólo una vez al día con la opción de habilitar el comportamiento anterior de alta precisión sólo si es necesario.

Sistema de archivos NILFS2

En un sistema de archivos común y corriente las operaciones de lectura son apoyadas por caché’s de lectura en memoria, es decir, cuando se necesita un bloque, se leen varios bloques del disco y se dejan en memoria, y cuando se necesita otro bloque en vez de ir a buscarlo nuevamente al disco, se toma de memoria en caso de que se haya leído previamente.

Para operaciones de escritura no hay muchas opciones, dado que se tiene que sacrificar rendimiento por seguridad como lo explicamos anteriormente.  Por otra parte al escribir un archivo se tiene que modificar varias partes del disco.

NILFS2 o New Implementation of a Log-structured File System se trata de un sistema de archivos que opera en base a registros históricos.  Cada vez que se modifica el sistema de archivos se escribe como un registro de cambio, a continuación del cambio anterior.  Por lo tanto en un sistema basado en registros históricos, la escritura se realiza en un solo lugar y no requiere esperar a que el dispositivo busque otros lugares donde escribir, mejorando notablemente el rendimiento de escritura.   Por otra parte, esta técnica permite en cualquier momento obtener rápidamente una versión anterior del sistema de archivos en modo de sólo lectura para respaldar o para recuperar un archivo eliminado accidentalmente sin afectar al resto del sistema que continúa con sus operaciones normales.

Otra ventaja de usar un sistema de archivos basado en registros históricos es que es muy rápido de recuperar en caso de corte de energía a diferencia de un sistema de archivos tradicional con soporte de journal (ext3, ext4, ntfs, etc).  Simplemente se busca el último registro histórico consistente y se monta como lectura/escritura a partir de ese momento.

Boot Fast Stupid!

En esta versión se integraron los últimos cambios pendientes para mejorar el tiempo de inicio desde el punto de vista del kernel.  Este es el tiempo desde que se carga el kernel hasta que se inicia el proceso init que desencadena la carga de servicios y la inicialización de subsistemas.

Uno de los problemas casi inevitables en este tramo es la inicialización de los dispositivos.  Algunos se demoran bastante en dar señales de vida, y en casos como unidades ópticas o discos duros incluso hay que esperar a que se pongan en movimiento.

La técnica aplicada para evitar estas demoras es bastante sencilla en el papel, pero difícil de implementar en un sistema tan complejo.  El cambio consiste en inicializar los dispositivos de forma asíncrona, esto quiere decir que en vez de esperar a que el dispositivo responda, éste se inicializa y en forma posterior se obtiene el resultado, de esta forma se pueden inicializar varios dispositivos o subsistemas en forma paralela.

Nuevos y mejores drivers

Como es costumbre, muchos drivers han sido mejorados en esta versión, y también hay primerizos.  En la lista de cambios se ve soporte mejorado (o nuevo) para varios dispositivos inalámbricos, tarjetas de captura de video, mejoras en soporte de video ATI R600/R700 (gestión de memoria y kernel mode setting DRM para proveer aceleración 2D y xvideo), tv-out en los nuevos chipsets de intel, etc.

Otros cambios son: optimizaciones para discos SSD, inclusión de ALSA 1.0.20, mejoras en hibernación y virtualización.

Ah! y lo olvidaba ¡Vuelve Tux!.

Link : Fine tuning – What’s new in Linux 2.6.30 (The H Open Source)

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)

El cambio más obvio y superficial, es el reemplazo temporal de la mascota Tux por Tuz, quien se quedará sólo en esta versión.  El resto de los cambios tienen distinto nivel de impacto en los usuarios finales, por ejemplo se incluyen cambios que por el momento pasarán desapercibidos para algunos usuarios como es el caso de Kernel Mode Setting que debe esperar a que los drivers de video comiencen a usarlo, hasta cambios que pueden impactar fuertemente en el rendimiento como el nuevo sistema de archivos ext4 que algunas distribuciones como Ubuntu o Fedora ya están ofreciendo al momento de instalar.

Hemos comentado las nuevas características de este kernel en varios artículos de FayerWayer, pero para facilitar la labor de nuestros lectores, vamos a hacer un breve resumen agregando aquellas características de las que no hemos hablado

• Sistema de archivos Ext4 : Además de las características ya comentadas, se agrega un cambio para deshabilitar el registro de journal.  Esto quiere decir que los valientes pueden tener un sistema de archivos más rápido pero en caso de corte de luz no quedará otro remedio que revisar su consistencia como en los viejos tiempos.
• Modo Access Point : permite usar Linux como si se tratara de un Access Point para compartir la conexión inalámbrica (nice!)
• Soporte de hasta 4096 CPU’s
• FileSystem Freeze : Popularmente conocido como “un dos tres momia es”,  se trata de un mecanismo para detener en forma inmediata las escrituras al sistema de archivos para crear un respaldo u otra operación que pueda ser distraida por una escritura.
• Soporte para WiMAX
• Nuevo soporte para dispositivos WiFi : Atheros otus, Ralink rt2860/70 entre otros.
• Integración del nuevo sistema de archivos Btrfs : inicialmente creado por Oracle y posteriormente liberado como GPL y por supuesto integrado oficialmente al kernel 2.6.29.  Provee manejo de grandes volúmenes de almacenamiento, compresión, revisión y deframentación en linea, manejo eficiente de archivos pequeños, etc.
• Integración de Kernel Mode Setting KMS : cuando no existía KMS, las aplicaciones que necesitaban acceder al video debían preocuparse de manejar el modo de video de la pantalla y su estado interno.  Al pasar de un X server a otro o por ejemplo desde el splash de inicio al X server, se producen varios pestañeos cuando uno de ellos cierra el modo de video y el siguiente lo asigna.  Ahora esa funcionalidad la hace el kernel sólo si es necesario, reduciendo el esfuerzo que se requiere para pasar de una aplicación gráfica a otra y permitiendo que surgan proyectos como el ya comentado Wayland.
• SquashFS : Un sistema de archivos comprimido de solo lectura, ideal para LiveCD’s o para usar Linux en sistemas empotrados en donde el almacenamiento puede ser crìtico
• FastBoot : Nombre que agrupa varios cambios que se han realizado para mejorar el tiempo de inicio del sistema.  Si consideramos que con ext4 y las mejoras en las distribuciones ya se ha logrado reducir bastante este tiempo, este kernel promete mejorarlo aún más.

Esta lista está lejos de ser completa, sólo hemos tocado los cambios de grueso calibre.  Pueden encontrar la lista completa de cambios en el análisis del Kernel 2.6.29 en Linux Kernel Newbies.

El sitio Phoronix publica un interesante benchmark de distintas versiones del kernel en donde se ven mejoras en esta nueva versión y en algunos casos se ha recuperado el rendimiento que se había perdido en versiones recientes.

Links :

- Linux 2.6.29 (Linux Kernel Newbies)
- Tux se toma un receso por una noble causa (FayerWayer)
- Fedora 11 pone las cartas sobre la mesa (FayerWayer)
- Ubuntu 9.04 no incluirá el kernel 2.6.29 (FayerWayer)
- Ext4 : Un nuevo sistema de archivos para Linux (FayerWayer)
- Benchmarking the Linux 2.6.24 through 2.6.29 kernels (phoronix.com)

El demonio de tasmania es nativo de Australia, y durante la reciente conferencia linux.conf.au se decidió que Tuz tomaría el lugar de Tux para enfatizar la preocupación por esta criatura que se encuentra en peligro de extinción debido a un tumor facial que se transmite.

El kernel 2.6.29 del que ya hemos hablado en otras ocasiones, está pronto a ser liberado en forma oficial, y el commit que reemplaza a Tux por Tuz ya se hizo en el repositorio oficial del kernel.

Según Rusty Russell, el autor del cambio:

Tux se toma tres meses sabáticos para trabajar como barbero, asi que Tuz se queda con nosotros.

El cambio de Tux por Tuz lo podrán ver todos aquellos que inicien el sistema en modo gráfico y sin algun tipo de splash de inicio como usplash o plymouth.

Links:

- Save the Tasmanian devil (tassiedevil.com.au)
- The Linux Kernel saves animals, gets new logo (phoronoix.com)
- Linux.conf.au 2009: Tuz – git commit (git.kernel.org)

Actualmente esta disponible la versión estable 2.6.28.7 llamada “Erotic Pickled Herring” que supera las 10 millones de líneas de código. Para su versión 2.6.25 el kernel de Linux poseía 8.396.250 líneas de código escritas en el lenguaje de programación C con el uso del compilador GCC. 

Recientemente el proyecto LinuxDNA logró compilar sin errores la versión 2.6.22 del kernel con el compilador de Intel C/C++.

Estrictamente hablando, Linus Torvalds dio a conocer Linux de manera oficial en septiembre de 1991 con la versión 0.01 que originalmente tenía el nombre de Freax y que más tarde adoptaría el nombre Linux. Esta versión ocupaba solo 62KB, y que aún está disponible para su descarga para aquellos nostálgicos

Lo que en un principio empezó como un remplazo no comercial de MINIX (un clon del sistema operativo UNIX) por porte de Torvalds, más tarde terminaría siendo Linux. Actualmente Linux está ganando mercado gracias al impulso de las diversas distribuciones en los notebooks y netbooks, así como el extendido uso en el campo educativo gracias al software libre.

Por último les recomiendo un excelente documental llamado Revolution OS sobre la historia de Linux, GNU y el movimiento del software libre, donde aparecen  testimonios de  Linus Torvalds, Richard M. Stallman y Eric Raymond entre otros.

Link: Happy Birthday, Linux! (CrunchGear)

Uno de los aspectos que estaba en duda era si incluir el kernel 2.6.29 o quedarse con el actual 2.6.28.  Aunque en un proyecto abierto normal ese cambio de número significa que sólo hay bugfixes, en el caso del kernel significa que hay nuevas características y en 2.6.29 se agregaron algunos cambios radicales:

• Modo Access Point : permite usar Linux como si se tratara de un Access Point para compartir la conexión inalámbrica (nice!)
• Soporte para WiMAX
• Nuevo soporte para dispositivos WiFi : Atheros otus, Ralink rt2860/70 entre otros.
• Integración del nuevo sistema de archivos Btrfs : inicialmente creado por Oracle y posteriormente liberado como GPL y por supuesto integrado oficialmente al kernel 2.6.29.  Provee manejo de grandes volúmenes de almacenamiento, compresión, revisión y deframentación en linea, manejo eficiente de archivos pequeños, etc.
• Integración de Kernel Mode Setting KMS : cuando no existía KMS, las aplicaciones que necesitaban acceder al video debían preocuparse de manejar el modo de video de la pantalla y su estado interno.  Al pasar de un X server a otro o por ejemplo desde el splash de inicio al X server, se producen varios pestañeos cuando uno de ellos cierra el modo de video y el siguiente lo asigna.  Ahora esa funcionalidad la hace el kernel sólo si es necesario, reduciendo el esfuerzo necesario para pasar de una aplicación gráfica a otra y permitiendo que surgan proyectos como el ya comentado Wayland.

Los cambios introducidos son grandes, y en el caso de BtrFS es demasiado reciente.  Mientras que distribuciones como Fedora en algun momento incluyeron KMS para después tener que deshabilitarlo, y ahora incluirán se lanzan con 2.6.29, en aras de la estabilidad, Canonical ha declarado que la próxima versión de Ubuntu vendrá con el kernel 2.6.28:

Jaunty absoluta, positivamente y sin ninguna duda, se liberará con kernel 2.6.28.  ¿Es eso suficientemente claro como para desmentir todos los rumores?

A buen entendedor, pocas palabras.

Links:
- Jaunty kernel version? (Ubuntu Kernel team mailing list)
- Ubuntu will NOT ship with the Linux 2.6.29 kernel (phoronix.com)
- Kernel Log : What’s new in 2.6.29 (Heise Online)

La vulnerabilidad fue descubierta por la compañía de seguridad Phion y se encuentra en el núcleo de Vista, comprobándose que se encuentra presente en las versiones Ultimate y Entrerprise. Aunque los investigadores señalan que es altamente probable que afecte a la totalidad de las versiones de 32 y 64 bits.

En detalle la vulnerabilidad se ubica en el sistema de red, cuando son enviadas solicitudes a la API iphlpapi.dll y puede hacer que la computadora se apague o provocar que esta pierda su conectividad a la red.

Si bien para poder hacer uso de esta vulnerabilidad se necesitan permisos de administrador, se podrían utilizar paquetes DHCP sin permisos de administrador para aprovecharla.

Por el momento no se tiene información sobre si la vulnerabilidad se ha utilizado en algún tipo de ataque y se espera que sea corregida en el SP 2 de Windows Vista.

Link: Microsoft VISTA TCP/IP stack buffer overflow (vía ZDNet)

Según una estimación realizada por la Fundación Linux, desarrollar la distribución Fedora 9 de Linux desde cero tendría un costo de USD$10.800 millones.

Según el análisis realizado esta distribución está compuesta por 204,5 millones de líneas de código, las que se encuentran contenidas en 2.547 paquetes.

La estimación sobre el trabajo invertido en el desarrollo del software arroja un total de 60.000 años hombre, de los cuales unos 7.500 corresponderían al desarrollo del kernel.

En los últimos dos años 3.200 desarrolladores de 200 países han realizado algún tipo de contribución al desarrollo del kernel de Linux, pero la cantidad que han trabajado sólo en la distribución Fedora es mucho mayor.

Y después reclaman siendo que es gratis.

Link: Estimating the Total Development Cost of a Linux Distribution (The Linux Foundation)

Mediante un simple post publicado el día 5 de octubre de 1991 en la lista comp.os.minix, Linus Torvals anunciaba lo que a la larga se traduciría en uno de los hitos más importantes en la historia del Software Libre.

El anuncio señalaba la disponibilidad de la versión 0.02 del kernel que estaba desarrollando y que por esos días aún no tenía un nombre definido.

Para muchos el “nacimiento” de Linux es anterior, cuando Linus publicó en este misma lista sus intenciones de lo que sería el desarrollo de este nuevo sistema operativo.

La importancia del kernel 0.02 de Linux radica en que fue el primero que se podía utilizar y el primero oficialmente anunciado. Por lo demás, el kernel 0.02 era capaz de ejecutar un bash y gcc. En palabras de Linus:

Como ya comenté hace un mes, estoy trabajando en una versión gratuita de un sistema similar a Minix para ordenadores AT-386. Por fin ha alcanzado el estado en el que es incluso usable (aunque puede que no lo sea según lo que quieras), y estoy dispuesto a ofrecer el código fuente del mismo para que se distribuya de forma más amplia. Es únicamente la versión 0.02… pero he ejecutado bash, gcc, gnu-make, gnu-sed, compress, etc. en él.

De ahí en adelante la historia es por todos conocida, tal vez en un futuro esté dentro de los hitos más importantes de la humanidad.

Link: Linux Turns 17 Today (Slashdot)