En general nuestro amigo Linus parece haber quedado bastante satisfecho con las nuevas características integradas en el nuevo kernel, el que ahora agrupa casi 15 millones de líneas de código.

Dentro de las novedades que presenta el Kernel 3.2 de Linux destacan importantes mejoras en el soporte del sistema de ficheros Ext4 (bloques de 4 Kbytes a 1 Mbyte) y nuevas opciones para el soporte de Btrfs.

Además se sumaron una serie de mejoras en el planificador de procesos cuando este se encuentra realizando muchas escrituras en memoria, mejoras en el Device Mapper, en el protocolo TCP (para recuperar la conexión cuando existen paquetes perdidos) y el soporte de nuevas arquitecturas (como el procesador Hexagon DSP de Qualcomm).

Aquellos que deseen conocer en detalle los cambios introducidos en esta nueva versión del Kernel de Linux, los invitamos a leer en detalle los enlaces disponibles al final de la nota.

Links:

- Linux 3.2 (Linus Torvalds )

- Linux 3.2 (Kernel Newbies)

- What’s new in Linux 3.2 (H-Online)

Entre las novedades que se han incorporado a este nuevo kernel destacan el soporte para la tecnología Near-Field Communication (NFC), para los procesadores OpenRISC y para los controles Wiimote de Nintendo.

Además se incluyó una nueva herramienta denominada cpupowerutils (derivada de cpufrequtils), con la que los usuarios podrán administrar algunos parámetros del sistema y que pueden resultar en un mejor rendimiento del mismo.

En el apartado gráfico destaca el soporte para la aceleración 3D en algunas tarjetas gráficas de la serie GeForce de NVIDIA, junto con incorporar importantes mejoras en los sistemas de virtualización KVM y Xen.

Quienes deseen probar el nuevo Kernel deberán descargarlo desde el repositorio de GitHub.

Links:

Linux 3.1 is here – Update (H-Online)

Linux 3.1 (Linus Torvalds)

Linux 3.1 (Kernel Newbies)

“El objetivo al final (bueno, *uno* de los objetivos) del desarrollo distribuido es que ningún lugar específico es realmente diferente de otro, así que como hice una cuenta de Github para mi divelog, ¿por qué no ver qué tan bien se comporta si pongo todo mi repositorio de kernel ahí también?”, escribió Torvalds. “Así que mientras kernel.org esté abajo, veamos cómo le va a GitHub”.

GitHub funcionará así como un mirror temporal del desarrollo oficial.

Links:
- GitHub
- LKML (vía Slashdot)

La infección ocurrió el 12 de agosto y no fue detectada hasta 17 días después, según el administrador jefe de kernel.org, John “Warthog9″ Hawley. Según relató en un correo a los desarrolladores, se encontró un troyano en la máquina personal del desarrollador de kernel H. Peter Anvin y luego en dos servidores de kernel.org llamados Hera y Odin1.

“Intrusos obtuvieron acceso root al servidor Hera. Creemos que pueden haber obtenido acceso a través de las credenciales de un usuario; cómo lograron explotar ese acceso root es hasta el momento desconocido y está en investigación”, señala un comunicado en el sitio de kernel.org.

Se cree que los repositorios usados para almacenar el código fuente de Linux no se vieron afectados por la vulnerabilidad, aunque la seguridad de los mismos está siendo verificada. El comunicado agrega que el daño potencial que se puede hacer rooteando kernel.org es menos que el que se podría lograr en repositorios de software comunes, debido a los métodos de seguridad que están dentro del sistema.

“Por cada uno de los casi 40.000 archivos en el kernel de Linux, se calcula criptográficamente un hash SHA-1 seguro para definir de manera única los contenidos exactos de ese archivo. Una vez publicados, no es posible cambiar las versiones antiguas sin ser notado”, señala el comunicado.

Cada hash es almacenado en miles de sistemas diferentes alrededor del mundo, haciendo fácil que los usuarios chequeen la validez de los archivos Linux antes de correrlos en sus máquinas.

Aunque es raro, esta no es la primera vez que una respetada organización que distribuye software de código abierto, de la que dependen miles de otras organizaciones, es atacada. En diciembre, la fuente principal de código de la Free Software Foundation, GNU Savannah, fue derribada después de un hackeo que filtró contraseñas. Los administradores no pudieron determinar esa vez si hubo acceso de root.

En abril de 2010 también la Apache Software Foundation sufrió un ataque que consiguió contraseñas que cualquiera que usara el servicio de rastreo de bugs de la web.

Kernel.org bajó los servidores infectados y están en proceso de reinstalar completamente el sistema operativo en cada máquina de la organización. También están trabajando con los 448 usuarios de kernel.org para cambiar sus credenciales de autenticación, incluyendo claves SSH. Además se notificó a autoridades en Estados Unidos y Europa.

Link: The Linux Kernel Archives (vía The Register – Gracias Víctor)

El anuncio ocurre una semana después de que Torvalds iniciara una discusión sobre si había que terminar con la serie 2.6 del kernel y pasar a otro número. Al principio se sugirió pasar a 2.8, pero Linus cambió de idea y lo bautizó como 3.0.

La idea general entre quienes contribuyen en el kernel es que sería un buen momento para eliminar algunas características antiguas que ya no son necesarias junto con el cambio de número. El 3.0 simboliza en parte que Linux entra a su tercera década de existencia, después de que Torvalds lo anunciara por primera vez en agosto de 1991. La versión 2.0 del kernel apareció en 1996, y varios desarrolladores habían estado pidiendo durante mucho tiempo que las versiones tuvieran alguna relación con las fechas como para ordenarse más fácil.

Así el 3.0 suponemos que durará hasta la próxima década. “Será lanzado cerca del aniversario de los 20 años, lo que es una excusa para mi, aunque honestamente la verdadera razón es que ya no podía contar cómodamente hasta 40″, indicó Torvalds en una nota, respecto a que el número de kernel que correspondía según el sistema antiguo era 2.6.40.

Además de los cambios normales de drivers y varios arreglos de bugs, Torvalds señaló que no hay una gran revolución en el kernel 3.0.  ”No estamos haciendo KDE 4 o Gnome 3 aquí”, indicó. Así que no hay novedades asombrosas ni especiales que reportar por ahora. “Hemos hecho lanzamientos por fechas por muchos años hasta ahora, así que esto no se trata de nuevas características”, agregó.

Entre las cosas nuevas que sí vienen, están los driver de Linux para usar Kinect de Microsoft, drivers actualizados para tarjetas gráficas y mejoras para plataformas Intel (Sandy Bridge e Ivy Bridge) y los APUs de AMD.

Link: Say hello to Linux 3.0; Linus just tagged 3.0-rc1 (Phoronix)

Fabrice Bellard es un programador independiente francés quien consiguió hacer funcionar el kernel de Linux dentro de un navegador web gracias al uso de JavaScript.

Para lograrlo, lo que hizo Bellard fue crear una especie de emulador compatible tanto con Firefox 4 como con Chrome 11, que es capaz de ejecutar el Kernel de Linux en su versión 2.6.20.

Bellard señaló que creó esto “porque es divertido. Los nuevos motores de JavaScript son lo suficientemente rápidos para hacer cosas complicadas”.

Según el programador francés, su emulador corre dos veces más lento con el motor JavaScript V8 de Chrome, comparado con el motor Jaeger Monkey de Firefox. Su desarrollo ya fue probado por Brendan Eich, programador de Mozilla y creador de JavaScript, y Bellard cree que se puede usar como un sistema de prueba (un benchmark) para los motores de JavaScript.

Links:
- Sitio de Fabrice Bellard(Vía The Register)
- Emulador

En noviembre del año pasado un parche de 233 líneas del desarrollador Mike Galbrait demostró que podría  acelerar notablemente la experiencia del escritorio en Linux, reduciendo la latencia hasta en 60 veces. En esta versión de Linux, el parche cambia la forma en que el planificador  asigna tiempo de CPU a cada proceso para que el sistema pueda agrupar todos los procesos con el mismo identificador de sesión.

Por otro lado, los cambios en el sistema virtual de archivos (VFS) no solo hacen que las cargas de trabajo multi-hilo sean escalables, sino que también hace que algunas cargas con procesos únicos sean mucho más rápidos. En esencia, el dcache VFS (directorio de caché) y los mecanismo de búsqueda de ruta se han revisado a fin de ser más escalables.

La memoria permitida para procesar aumentará de tamaño de 4KB a 2 MB gracias a las “Transparent Huge Pages”, que reducen el número de asignaciones de memoria y aprovechan el mayor rendimiento del hardware. Según Tim Burke, vicepresidente de Ingeniería Linux de Red Hat, el impacto de la inclusión de las THP en Linux 2.6.38 es que ofrecen un mejor desempeño en las cargas de trabajo que requiere una gran cantidad de memoria, tales como servidores de JVM y base de datos.

Adiciones importantes a Linux 2.6.38:

• Compresión LZO y snapshots de sólo lectura en Btrfs: Btrfs añade soporte para el algoritmo de compresión LZO, como alternativa a zlib. También se añade soporte para marcar un snapshot como sólo lectura y la característica “force mounting” (forzar montaje) que hará que el código base sea más tolerante a fallos.
• Transparent huge pages - Esta alternativa al API basado en el sistema de archivos aprovecha de las ventajas de rendimiento de los procesadores modernos con mayor cache. El código de Transparent huge pages ahora se utiliza por defecto cuando sea aplicable, pero puede ser configurado para ser utilizado siempre o sólo cuando se solicite. El aumento será especialmente notable con el incremento en cargas de trabajo intensivas de datos, como bases de datos o sesiones KVM, que con frecuencia accesan a direcciones virtuales.
• Protocolo de malla B.A.T.M.A.N. – Better Approach To Mobile Ad-hoc Networking es un protocolo de ruteo proactivo para Redes Mesh Ad-hoc Inalámbricas [PDF], incluyendo las redes ad-hoc móviles (en inglés MANETs). El protocolo mantiene proactivamente información sobre la existencia de todos los nodos en la malla, que son accesibles a través de enlaces de comunicación de uno o múltiples saltos. La estrategia de B.A.T.M.A.N. es determinar para cada destino en la malla un vecino de un salto, el cual puede ser utilizado como mejor gateway para comunicarse con el nodo de destino. En estas redes, cada nodo de enrutamiento participa en los datos de reenvío para otros nodos de forma dinámica y se dice que es útil para situaciones de emergencia como desastres naturales.
• Soporte para AMD Fusion – Esta versión incluye el soporte para los nuevos APUs Fusión basados en una o más instancias del núcleo “Bobcat”.
• Límites de memoria sucia – Esta función controla los límites de Dirty Pages (Buffer de páginas que contienen modificaciones que no se han escrito en el disco) de cada controlador de memoria cgroups.

Linux 2.6.38  también ofrece una variedad habitual variedad de ajustes, adiciones y correcciones de errores, incluyendo mejoras en el núcleo, el planificador (scheduler), gestión de memoria, manejo de bloques, sistemas de archivos, creación de redes, criptografía, virtualización, seguridad y trazado.

Links:
- Linux 2.6.38 speeds group scheduling, VFS (Linux for Devices)
- What’s new in Linux 2.6.38 (H-Online)
- Linux Kernel 2.6.38 arrives with desktop ‘wonder patch’ (TechWord)

Esta versión cuenta con:

• Mejoras de escalabilidad y rendimiento en los sistemas de archivos Ext4 y XFS
• Posibilidad de compilar el kernel sin el BKL (Big Kernel Lock), bloqueo más molesto del núcleo que no tenía impacto en el rendimiento
• Dispositivo de bloques basado en el sistema de archivos distribuido Ceph.
• Soporte de limitación I/O, esto hace posible que con cgroup se limite la lectura/escritura de un grupo de procesos.

Además agrega varias mejoras en Btrfs, pruebas estáticas más eficientes, soporte a los módulos de prueba perf y listados de variables locales y globales accesibles, hibernación de imágenes utilizando la compresión LZO, PPP a través de IPv4 y varias microoptimizaciones de redes, sin mencionar los nuevos controladores para dispositivos.

Link: Linux 2 6 37 (Kernel Newbies)

Es una versión que no ha crecido en tamaño – ya que los desarrolladores recortaron considerablemente los archivos de configuración por defecto – pero tiene cientos de avances importantes como el soporte para una nueva interfaz de notificación para el sistema de ficheros llamada “fanotify” y la arquitectura Tilera, optimizaciones de colas de trabajo (workqueue) para la concurrencia, soporte para la funcionalidad  Intel Intelligent Power Sharing en sistemas Intel Core i3/i5, cacheo local de CIFS, la integración de KMS con el KDB (kernel debugger), un  OOM (Out of Memory Killer) reescrito, una mejor respuesta de escritorio relacionada con la Máquina Virtual y por último pero no menos importante, el sistema de seguridad AppArmor.

• La arquitectura Tile tiene un diseño multi-núcleo destinado a escalar cientos de núcleos en un solo chip.  El objetivo es proporcionar una CPU de alto rendimiento, con buena eficiencia energética y mayor flexibilidad que los procesadores de propósito específico como los DSP. El chip se compone de una malla de 64 “cuadros” interconectados, donde cada pieza contiene un procesador de propósito general, caché y un switch sin bloqueo.
• AppArmor es un sistema de seguridad MAC (Mandatory Access Control), fue desarrollado originalmente por Immunix en 1998 y ha sido parte de algunas distribuciones de Linux desde hace mucho tiempo. AppArmor permite al administrador del sistema asociar a cada programa un perfil de seguridad que restrinja las capacidades de ese programa. Complementa el modelo tradicional de control de acceso discrecional de Unix (DAC) proporcionando el control de acceso obligatorio (MAC).
• Las plataformas Intel Core i3/i5 con gráficos tienen el soporte dinámico para el consumo de energía entre la CPU y la GPU (Intel Intelligent Power), maximizando el rendimiento en un determinado TDP. Un nuevo de controlador junto para la frecuencia de la CPU y los controladores i915 proporcionan esta funcionalidad. Se monitoriza la potencia de la GPU y la temperatura para optimizar el consumo energético.
• El Out of Memory Killer es la parte de la máquina virtual que mata a un proceso cuando no hay memoria (RAM y swap). El algoritmo que decide cual es mejor proceso para ser “matado” se ha reescrito en esta versión y deberá tomar mejores decisiones.

También hay varios cambios en el núcleo, la seguridad, sistema de archivos, red, mapeo, bloqueo y virtualización que puedes revisar en kernelnewbies.

Link: Linux kernel 2.6.36 released (H-Online)

(c) Henrique Vicente

El investigador israelí Gil Dabah descubrió una nueva vulnerabilidad en el kernel de Windows, por medio de la cual se podría causar una escalada de privilegios en todas las versiones de Windows (incluso las versiones 64 bits).

La vulnerabilidad estaría centrada en la librería win32k.sys, encargada de realizar varias funciones consideradas como clave en Windows (como la gestión de ventanas y gráficos 2D).

De esta manera se podría causar una de las temidas BSOD introduciendo datos corruptos en el portapapeles e, incluso, ejecutar código malicioso (aunque esto aún no se ha logrado comprobar).

Claro que para que un atacante pueda aprovechar esta vulnerabilidad debe tener una cuenta local en el equipo, por lo que Secunia le asignó la calificación de “poco crítico”.

Desde Microsoft confirmaron la existencia de la vulnerabilidad, limitándose a señalar que esta podría ser corregida por medio de un parche que estaría a disposición de los usuarios.

De momento los sistemas afectados por la vulnerabilidad son: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 y Windows Server 2008 R2.

Link: New Windows kernel mode flaw points to future attack vectors (Ars Technica)

El kernel ahora soporta muchas características de manejo de energía ofrecidas por los chips gráficos Radeon y soporta las características de decodificación H.264 y VC1 en chips Intel G45+. El sistema de archivos Btrfs (B-tree FS) ahora puede manejar Direct I/O (una técnica utilizada para eludir el sistema de archivos de caché) y mejoras agregadas por Google para distribuir la carga de red a través de las CPUs disponibles en el sistema – mejor rendimiento de la red y menos latencia en los sistemas multi-núcleo.

Otras mejoras incluyen la optimización del código para las funciones de administración de energía y el soporte para la función Turbo Core de los recientes CPUs de AMD de seis núcleos, interfaces para analizar el rendimiento del hipervisor KVM (Kernel-based Virtual Machine), un programa de configuración del kernel y características para la de-fragmentación de la memoria de trabajo. Además de nuevos y mejorados drivers, como los del soporte extendido para USB 3.0 y las mejoras en la tasa de transmisión del controlador ath_5k Wi-Fi.

Link: Linux Kernel 2.6.35 Released (Slashdot)

Viene con importantes mejoras y características nuevas, entre las que se destacan la implementación de suspensión/resumen asíncronos y GPU switching, la inclusión de dos nuevos sistemas de archivos LogFS y Ceph, el driver Vhost net que mejora el rendimiento de las redes en KVM y mejoras en el sistema de archivos Btrfs.

A continuación detallaré algunas de las mejoras incluidas:

El sistema de archivos Ceph

Es un sistema de archivos distribuído creado por Sage Wiel (inicialmente como parte de su tesis), capaz de soportar sistemas con grandes volúmenes de datos, estamos hablando de Terabytes o Petabytes (incluso más allá) de información. La escalabilidad de este sistema de archivos está pensada tanto en términos de volumen de trabajo como de almacenamiento total, ya que Ceph está diseñado para manejar cargas considerables de trabajo en el que cientos o miles de clientes pueden acceder o escribir de manera simultánea sobre un mismo archivo o directorio.

Algunas de las características que diferencian a Ceph de los otros sistemas de archivos son:

• Escalamiento flexible: Un sistema de archivos Ceph puede ser ampliado de manera sencilla añadiendo nodos de almacenamiento (OSD), migrando los datos de manera automática a los diferentes dispositivos que lo requieran, garantizando que los datos sean distribuidos de manera adecuada.
• Gran estabilidad y rápida recuperación: Todos los datos contenidos en un sistema de archivos Ceph es replicado a través de múltiples nodos OSD, en el caso de que algún OSD falle, los datos automáticamente son replicados a otros dispositivos.
• Servidor de metadatos MSD: Ceph está diseñado para adaptar de manera dinámica su comportamiento ante la sobrecarga de trabajo. La jerarquía del sistema de archivos se redistribuye entre los servidores de metadatos disponibles, según el tamaño y la popularidad de los cambios a través del tiempo, lo que permite equilibrar la carga y el uso eficaz del los recursos.

A pesar de que Ceph promete mucho, este aún se considera un sistema de archivos experimental.

El sistema de archivos LogFS

Es un sistema de archivos diseñado para dispositivos de almacenamiento basados en memoria flash (como por ejemplo discos duros SSD). En comparación con otros sistemas de archivos de su tipo como JFFS2, este ofrece tiempos de montaje y consumo de RAM menores. Este sistema de archivos al igual que Ceph se encuentra en estado experimental.

Mejoras en el sistema de archivos Btrfs

Este sistema de archivos se caracteriza por su tolerencia a fallos y su sencilla reparación y administración. En esta versión del núcleo se han mejorado aspectos como la capacidad para cambiar el subvolúmen que se monta por defecto, lo que permite tomar snapshots que pueden ser recuperados en caso de que ocurra alguna falla o perdida de información. También se han añadido: la capacidad para listar todos los subvolúmenes, calcular el df, defragmentar archivos individuales o partes de estos y una nueva herramienta llamada “btrfs” que reemplaza a las anteriores.

Implementación de suspensión y resumen asíncronos

En las versiones anteriores del núcleo, las suspensión y resumen era de manera síncrona, esto quiere decir que cada unos de los dispositivos se suspendía o resumía de manera secuencial (uno detrás de otro). En esta versión se ha modificado el código del administrador de energía para permitir que los dispositivos se puedan suspender o resumir en paralelo, lo cual permite que estos procedimientos tarden menos tiempo. En esta versión los dispositivos PCI, USB y SCSI vienen con esta implementación por defecto.

GPU switching

Algunos laptops poseen dos GPUs, una de alto rendimiento y consumo de energía y otra de bajo rendimiento y consumo de energía. En esta versión se ha incluido la posibilidad de que los usuarios puedan cambiar de una a otra GPU en tiempo de ejecución, aunque se debe reiniciar el X.

El driver Vhost net que mejora el rendimiento de las redes en KVM

Se trata de un driver que optimiza las funciones de red de la interfaz de IO (virtio) que Linux utiliza para la interacción entre los huéspedes y invitados en sistemas de virtualización. Este driver elimina 4 llamadas del sistema por cada paquete de red, lo que permite que los invitados de un sistema KVM puedan tener un rendimiento de red similar al del hardware nativo.

Estas son sólo algunas de las nuevas características que trae el núcleo 2.6.34, pero existen bastantes más, relacionadas sobre todo con el núcleo base, otros sistemas de archivos, redes, virtualización, arquitecturas y drivers, cuya descripción puedes leer en el siguiente enlace.

Link: Linux 2 6 34 (KernelNiewbies)

“Esta actualización de seguridad incluye un detector que impide la instalación de la actualización de seguridad, si existen ciertas condiciones anormales en los sistemas de 32 bits… Estas condiciones en el sistema podrían ser el resultado de una infección con un virus que modifica algunos archivos del sistema operativo, haciendo que el ordenador infectado sea incompatible con la actualización del kernel“

Por lo tanto, Microsoft exhorta a descargar su herramienta de detección de software malintencionado (Malicious Software Removal) que elimina una serie de vulnerabilidades comunes (incluyendo el rootkit Alureon) y ejecutar el parche tan pronto como sea posible.

Win32/Alureon es una familia de troyanos que roban datos. Estos troyanos permiten a un atacante para interceptar el tráfico de Internet con el fin de obtener información confidencial como nombres de usuario, contraseñas y datos de tarjetas de crédito. Permite que un atacante transmita datos maliciosos a la computadora infectada. El troyano puede modificar la configuración de DNS en el equipo host para permitir que el atacante realice estas tareas. Por lo que podría ser necesaria la reconfiguración de su DNS después de que elimine el troyano.

Al parecer el bug que había estado por 17 años en el kernel de todas las versiones de 32 bits de Windows no será fácil de corregir mientras Alureon interactué con los parches de actualización.

Link: Infected XP owners left unpatched (BBC News)

Linux ha dejado de ser software libre desde 1996, cuando Linus Torvalds aceptó incluir las primeras piezas de software no libre, dejando de ser un incentivo para que los fabricantes de hardware respetaran las libertades esenciales de la GPL. Aproximadamente 143 KB de código objeto se encontraban presentes en el tarball comprimido de 4.7 MB en la versión 2.0 del núcleo publicada en junio de 1996, en la actualidad, la versión 2.6.33 que pesa alrededor de 62 MB (en un archivo tarball comprimido) contiene aproximadamente 10 MB correspondientes a código objeto propietario.”

La FSFLA ha desarrollado algunos scripts que eliminan el código perteneciente al núcleo que para ellos es “no libre” y así han creado su versión propia del núcleo que han denominado “la versión libre y limpia de Linux”.

Si bien es cierto que el núcleo posee código propietario, se encuentra sólo en casos en donde no existe una implementación libre y sus autores han dado el consentimiento para que se incluya como parte del núcleo. De esta forma se puede asegurar el funcionamiento de dispositivos que de otro modo requerirían pasos adicionales por parte del usuario, como descargar archivos desde la red, lo que sería imposible si justamente estos drivers corresponden a dispositivos de red.

Por otra parte, el anuncio de FSFLA sugiere que Linus y los desarrolladores del núcleo nos están tratando de engañar, porque según ellos el código se encuentra como código fuente que genera un binario, y no como un simple binario, como si quisieran ocultar código binario al interior de código fuente. Lo que sucede en realidad es que el código se ha incluido como texto para ser manejado como cualquier otra pieza del núcleo en el sistema de control de versiones, se trata de motivaciones técnicas y no conspirativas como pretende la FSFLA.

Si fueramos rigurosos y hubiéramos esperado a que esas piezas estuvieran disponibles como libres desde un principio para poder usarlas, llevaríamos años de retraso en la difusión de Linux con muchos usuarios descontentos porque su hardware no funciona.

Links:
- Recupera tu libertad, con Linux-2.6.33-libre (FSFLA)
- Linux 2.6.33 viene con una mejora importante para netbooks y móviles (Fayerwayer)

(cc) por zopeuse/Aurel

Aunque se esperaba para los primeros días de Marzo, la nueva versión de Linux (el núcleo) numerada como 2.6.33 ya fue publicada oficialmente.

Sin mayor preámbulo, veamos cuáles son algunas de las mejoras más interesantes.

• Esta versión incluye por primera vez la integración del driver de código abierto Nouveau para chips gráficos Nvidia. Recordemos que estos drivers fueron desarrollados por la comunidad de código abierto sin apoyo de la compañía y a pesar de la complejidad del proyecto por no contar con información sobre cómo funcionan estos chips, ya se cuenta con un grado de madurez que lo hace usable para tareas básicas,evitando la necesidad de descargar el driver cerrado de Nvidia.
• Se ha agregado DRBD. Se trata de un esquema de almacenamiento distribuido para aplicaciones que requieren alta disponibilidad.  Es un esquema muy similar a algo que se conoce como RAID-1 en donde se tienen varios discos con información duplicada, si falla un disco, simplemente se reemplaza mientras el otro sigue funcionando. Con DRBD los discos están separados físicamente y la sincronización se realiza a través de la red.
• Linux cuenta con un mecanismo llamado ftrace para monitorear el sistema en forma no intrusiva. Se puede pensar como un mecanismo que permite enchufarse a una funcionalidad del sistema para ver qué está haciendo. En esta versión se han agregado utilidades para obtener información acerca del rendimiento del sistema.

• Se incluye TCP Cookie Transactions. Se trata de un mecanismo para evitar ataques de denegación de servicio. Una técnica usual en este tipo de ataques es solicitar una gran cantidad de conexiones al mismo tiempo (SYN Flood), lo que hace que el servidor trate de atenderlas porque no tiene cómo distinguir cuales son realmente válidas.  Con TCPCT se establece una negociación para asegurar que quien pide la conexión sea un cliente válido.
• En la versión anterior se incluyó KSM para mejorar el uso de memoria en sistemas virtualizados. Una debilidad de esta ingeniosa idea era que las páginas de memoria compartidas no se podían llevar a disco cuando se necesitaba más memoria. Esta limitación ha sido eliminada con esta nueva versión.

Ahora que el kernel se encarga los detalles de bajo nivel de el sistema gráfico a través de kernel mode setting, se ha incluido como funcionalidad universal una llamada al sistema para sincronizar las aplicaciones con el refresco de la pantalla. Esto significa que ahora las aplicaciones o bibliotecas gráficas podrán saber cuándo es el mejor momento para actualizar lo que está dibujado en pantalla sin riesgo de que se dibuje parcialmente durante un cuadro, causando el famoso efecto de tearing.

Esta es una funcionalidad que siempre se pidió pero no había un acuerdo sobre cómo implementarla.  En sistemas antiguos que no eran multitarea era increíblemente simple de implementar, pero en sistemas multitarea y con el gran desorden que existía en el mundo de los drivers antes de kernel-mode-setting, el desafío era bastante grande.

He dejado para el final uno de los cambios que me parece más interesante y que da el título de este artículo.  Se trata de una mejora radical en el uso de la memoria que beneficiará sobre todo a equipos pequeños como netbooks y teléfonos móviles.  El concepto es bastante simple pero poderoso, para entenderlo bien recomiendo leer mi artículo anterior sobre Kernel Samepage Merging.

¿Listos? Vamos a ver:

Al esquema de swapping o intercambio existente, incluyendo la unificación de páginas de memoria con contenido repetido, se ha agregado un paso intermedio de compresión.  En vez de ir directamente al disco, ahora el swap se podrá hacer a un dispositivo virtual que comprime las páginas de memoria no utilizadas en RAM sin necesidad de llevarlas al disco, mejorando considerablemente el rendimiento por no tener que recurrir a un disco físico cuando la memoria se hace escasa.

¿Qué tan bueno es?  Se han realizado varios benchmarks en donde sólo se ha encontrado un caso en donde no trae beneficios. En estos benchmarks destacan aquellos en donde se han detectado tasas de compresión de 4:1, o bien, una reducción de un 25% de la memoria necesaria para usar el sistema.  Por ejemplo si tu entorno de escritorio junto a las aplicaciones requieren 256MB de RAM, ahora sólo necesitarán 64MB de RAM.

Si esto no te parece impresionante, también se puede ver desde el punto de vista del rendimiento.  Se hicieron pruebas al realizar tareas rutinarias con el mecanismo estándar de swap a disco, usando un disco de 10.000 RPM y se obtuvo un promedio de 200-300 milisegundos ocupados en swap, con el nuevo sistema, estos tiempos bajan a sólo 10 microsegundos.

Link: Linux 2.6.33 (kernel newbies)

Todas las características han sido añadidas y ahora estamos en un proceso de pruebas. Una de mis cosas favoritas es un driver denominado Nouveau. Esto ha sido un esfuerzo maestro de ingeniería inversa.”

Pese a la negativa por parte de Nvidia de ayudar en el desarrollo de este driver, de todas maneras gracias al gran trabajo de estos desarrolladores se incluirá en esta nueva versión del núcleo. Tal como les comentamos hace algunas semanas, Linus Torvalds se había presentado algo molesto por el poco esfuerzo que se había hecho para incluir a Nouveau directamente en el núcleo (considerando que ya estaba en Fedora) y la presión que ha hecho finalmente ha dado frutos.

Jonathan también comenta que en esta nueva versión se incluirá soporte para un ftrace dinámico, que permitirá a los administradores de sistemas analizar qué está pasando en el sistema operativo o en las aplicaciones de los usuarios, incluyendo las aplicaciones más críticas. El tracing es uno de los mayores desafíos de esta nueva versión del núcleo, en donde la mayor parte del trabajo se lo ha llevado la escalabilidad, no sólo para los grandes sistemas, sino también para los sistemas más pequeños.

Para que se den cuenta de la magnitud de un proyecto como es el núcleo de Linux, en total trabajan más de 2.000 desarrolladores en sus diferentes ramas, realizando más de 50.000 cambios en el código cada año. Para este nuevo release se encuentran trabajando alrededor de 1100 desarrolladores, principalmente solucionando errores, pero también agregando características nuevas como las que hemos comentado.

Link: Linux.conf.au: Latest Linux kernel release due early March (ComputerWorld AU)

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)