VivaLinux!

Soporte para más de 100 webcams al Kernel 2.6.27

De acuerdo a este hilo de discusiones en la lista de correo de uvcvideo (USB Video Class Driver) del Kernel Linux, si todo sale según lo esperado, podemos esperar ver soporte para más de 100 tipos de webcams nuevas y dispositivos similares en el próximo Kernel 2.6.27. De acuerdo a la lista mencionada, el estándar UVC es requerido para obtener "certificación Windows Vista", así que los fabricantes de hardware deben incluirla. Entre los periféricos incluídos en esta categoría se encuentran además de webcams, "camcorders" digitales, conversores de video analógico y sintonizadores de televisión, entre otros.

La buena noticia es que esto significaría soporte automático para todos esos dispositivos, lo que representa a su vez casi todas las webcams incluídas en las computadoras portátiles modernas, y seguramente también las webcams USB más recientes.

Los módulos cerrados son indeseables y dañinos

Una constante espina para los desarrolladores de Linux siempre fué la existencia de módulos de código cerrado para el Kernel, notablemente los de NVidia y ATI, pero también de sistemas de archivos y otros. Los desarrolladores se opusieron a este tipo de módulos desde el principio y, de hecho, los reportes de errores de Kernels "contaminados" con estos módulos son sencillamente ignorados.

Por todo ello, los desarrolladores del Kernel se reunieron y publicaron un documento urgiendo a los vendedores a que liberen sus drivers y módulos como Open Source.

"Nosotros, los desarrolladores del Kernel consideramos a cualquier módulo o driver de codigo cerrado para Linux como indeseable y dañino. Hemos encontrado repetidamente que son un detrimento para los usuarios de Linux, los negocios, y el ecosistema más grande de Linux. Dichos módulos niegan la apertura, estabilidad, flexibilidad y mantenibilidad del modelo de desarrollo de Linux y excluye a sus usuarios de la experiencia de la comunidad".

Drivers de NVidia soportarán el Kernel 2.6.26

Aparentemente, la próxima versión 173.14.09 de los drivers de NVidia para Linux traerán soporte preliminar para el Kernel 2.6.26. Esto significa que uno podrá actualizarse a esa nueva versión del Kernel sin temor a que nuestra configuración de video deje de funcionar. Los drivers mejorarán también el soporte del servidor X.org 1.5 que fué introducido en su versión anterior. Otras novedades incluyen arreglos para una configuración dual de Quadro FX 1700, soluciones para los GPUs móviles GeForce FX 6 y 7, además de una corrección al paquete de configuración de NVidia.

Datos interesantes sobre el Kernel Linux

Unas interesantes estadísticas del Kernel Linux, extraídas de la presentación de Greg Kroah Hartman, el desarrollador a cargo del driver de USB, realizada durante los recientes Google Tech Talks.

• 9,2 Millones de líneas de código, se incrementa 10% cada año.
• El Kernel en sí mismo es el 5%, y los drivers son aproximadamente el 55%.
• 4500 líneas son agregadas, 1800 removidas y 1500 modificadas todos los días.
• Es un sistema jerárquico pero no depende de las personas individuales.
• Una nueva versión cada 2 o 3 meses.
• 2399 desarrolladores, la mitad de ellos contribuye con sólo 1 o 2 parches.
• Ya no hay un Kernel estable (con mumeración par, como el 2.4) y otro inestable (con numeración impar, como el 2.3); este proceso ha sido discontinuado.
• Las actualizaciones de seguridad de una versión vienen numeradas como x.x.x. Por ejemplo, las correcciones para el 2.6.19 se numeran como 2.6.19.1, 2.6.19.2, etc.
• El Kernel es activamente desarrollador las 24 horas del días, los 7 días de la semana, los 365 días del año.

Más información en el susodicho video, en su correspondiente presentación y en este artículo.

Ksplice parcha tu Kernel sin reiniciarlo

Ksplice le permite a los administradores de servidores aplicar parches de seguridad a un Kernel Linux sin tener que reiniciar el sistema luego. Ksplice toma como entrar el código fuente del cambio a realizar en formato diff unificado y lo aplica al correspondiente Kernel que se esté ejecutando. El Kernel en ejecución no necesita ser preparado antes de ninguna manera.

Para ser específicos, el diseño de Ksplice está limitado a parches que no introduzcan cambios semánticos a las estructuras de datos; pero la mayoría de los parches de seguridad no realizan este tipo cambios.

Una prueba con los parches de seguridad del Kernel Linux desde Mayo del 2005 hasta Diciembre del 2007 descubrió que Ksplice pudo aplicar automáticamente el 84% de ellos.

Lo que traerá el Kernel 2.6.25

• RCU "apropiativo" (preemptible): RCU es un sistema de sincronización que permite a Linux escalar a máquinas con miles de procesadores. Sin embargo, una parte del sistema de RCU no es "apropiativo", es decir, no puede ser interrumpido mientras se ejecuta. En 2.6.25 se puede elegir entre el RCU clásico y el nuevo, que es apropiativo. Este nuevo sistema ha sido desarrollado a la sombra de los esfuerzos que tratan de hacer que Linux sea un SO de tiempo real.
• Real Time Group scheduling: En el Kernel 2.6.24 se introdujo un sistema que permitía organizar las prioridades de CPU de manera mucho mas flexible. En el 2.6.25 se ha extendido este sistema para que pueda manejar, además de los procesos "normales", los procesos SCHED_RT, es decir, de tiempo real, y trate de satisfacer sus necesidades especiales. (Además de esto, se ha mejorado el sistema de balanceo de procesos entre CPUs del gestor de procesos, para gestionar mejor las necesidades de los procesos de tiempo real - como se puede ver, hay mucho movimiento alrededor de este tema)
• Memory Resource Controller: Basado en la misma infraestructura de configuración que el anterior punto (cgroups), esto permite configurar algunos aspectos de la utilización del recurso de la memoria a grupos de procesos elegidos al azar.
• Spinlocks FIFO: Los spinlocks son una de las principales herramientas de sincronización en Linux: cuando un proceso adquiere un spinlock, hasta que no lo suelte el resto de CPUs que intente adquirirlo a petición de un proceso entrará en un bucle cerrado. Con los nuevos Spinlocks FIFO (solo x86), las CPUs consiguen permiso para adquirir el spinlock en el mismo orden en el que le solicitaron por primera vez. Esto permite asegurar que ninguna CPU es discriminada por otras y hace que los spinlocks sean un poco más deterministas.
• Nuevas herramientas de medición de memoria: En el 2.6.25 cada proceso exporta en /proc información sobre las páginas que ese proceso está utilizando. Comparando esa información con la de otros procesos se puede conocer con mayor exactitud el uso de memoria de cada proceso.
• timerfd(): Tradicionalmente en Unix las notificaciones de eventos del temporizador se hacen mediante señales, lo cual es muy engorroso. Para solucionarlo, los sistemas UNIX modernos han incorporado sistemas, como FreeBSD/OSX con kevent, y Solaris con un sistema similar. En linux se ha optado por una solución más "unixera": con timerfd() se pueden programar eventos en el temporizador, obtener un descriptor de archivo, y utilizar poll/epoll/read con esos descriptores.
• Latencytop: Se trata de una pequeña infraestructura que permite visualizar cuales son las fuentes de latencia máxima en el Kernel. El programa para poder verlas se encuentra en latencytop.org.
• SMACK (Simplified Mandatory Access Control): Se trata de un sistema de seguridad basado en los mismos principios que SELinux, pero menos capaz y más sencillo de configurar. Al igual que Linux tiene varios sistemas de archivos, ahora tambien habrá varios sistemas de seguridad para que la gente elija el que más le convenga, visto que SELinux no complace a todo el mundo.
• Randomización de ejecutables PIE y del BRK: La ubicación de la memoria manejada por brk() y por ciertas secciones de los ejecutables PIE (Position Independent Executable) se decide de manera aleatoria.
• Actualización de Ext4: Asignación múltiple de bloques, mayor tamaño máximo de bloque, checksumming en el journal, soporte de sistemas de archivos y archivos de mucho mayor tamaño. Con esta actualización ya esta casi todo de lo que traerá Ext4, de hecho ya están todas las que cambian de algun modo el formato del sistema de archivos en el disco, pero aun faltan algunas como delayed allocation.
• Arquitectura MN10300/AM33: Soporte para una nueva arquitectura que no la conoce ni el que la inventó.
• Regulación Termal de ACPI: No se exactamente lo que hace, pero Linux lo soporta. Adicionalmente se añade soporte para WMI, una extensión propietaria de ACPI hecha por Microsoft.
• Protocolo CAN: Para sorpresa de todos, Volkswagen ha decidido contribuir con una implementación de CAN (Controller Area Network), un protocolo de red muy raro.

¿Quién paga por programar Linux?

La Linux Foundation publicó un estudio sobre los tres últimos años de desarrollo del Kernel Linux, desde la versión 2.6.11 a la 2.6.24, revelando que el desarrollador Linux promedio es pagado por alguna gran corporación. "Más del 70% de todas las contribuciones al Kernel provienen de desarrolladores trabajando en compañías como IBM, Intel, The Linux Foundation, MIPS Technology, MontaVista, Movial, NetApp, Novell y Red Hat", afirma el reporte.

Durante los últimos años el número de los desarrolladores de Linux también ha aumentado: Su versión 2.6.11 tenía sólo 483 programadores, la última 2.6.24 tiene 1057. En los 3 años más recientes se han incluído en Linux el trabajo de 3678 programadores.

Así, la mayor parte del código de Linux es escrito por programadores "corporativos", siendo el Top 10 de las compañías que pagan por él:

1. Red Hat (11.2%)
2. Novell (8.9%)
3. IBM (8.3%)
4. Intel (4.1%)
5. The Linux Foundation (3.5%)
6. SGI (2.0%)
7. MIPS Technology (1.6%)
8. Oracle (1.3%)
9. MontaVista (1.2%)
10. Linutronix (1.0%)

Notablemente, durante el período estudiado la contribución de Novell aumentó un 250%, poniéndolo en segundo lugar sólo después de Red Hat.

Kernel.org se pasa a FreeBSD 7.0 (!)

Los administradores de Kernel.org anunciaron un downtime de todos sus servidores (incluídos los Mirrors, los servidores públicos y su backend master) comenzando aproximadamente a patir del 2 de Abril. Después de una acalorada y larga deliberación, los servidores de Kernel.org se actualizarán desde Fedora Core 5 a FreeBSD 7.0. Aparentemente, la decisión no fué fácil, pero un par de puntos clave fueron determinantes para dar ese salto de fé:

1. FreeBSD 7.0 supera a Linux en performance SMP.
2. FreeBSD vs. Linux vs. Windows 2000.

"Sentimos que podemos servir mejor nuestros Mirrors, a nuestros usuarios y a la comunidad haciendo este cambio, y esperamos tener la transición terminada dentro de muy poco", dice uno de los administradores.