Lo que traerá Linux 2.6.26

Faltan unos días para que salga Linux 2.6.26. He aquí el resumen de las principales novedades en español.

• Read-only bind mounts: Desde Linux 2.4.0 se soportan los montajes "bind" (a través del parámetro --bind de mount), que son una especie de enlaces simbólicos a nivel de VFS que permiten tener un solo directorio en dos ubicaciones distintas. Por ejemplo, si tienes un directorio /foo, con mount --bind /foo /bar tendremos en /bar un directorio con exactamente los mismos contenidos que /foo. Sin embargo, hasta hoy si /foo era un directorio al cual se podía acceder en modo lectura/escritura, heredaba incondicionalmente esa propiedad. En 2.6.26 se podrá especificar que /bar este en modo de solo lectura al margen de lo que haga /foo. Esto es útil en casos como virtualización con "containers" pues permite mostrar al usuario virtualizado directorios a los cuales no podrá escribir aunque sea root. Tambien es útil para FTPs, chroots, etc. (PD: En el post sobre 2.6.24 anuncié está novedad por error; lo que había en esa versión era tan solo una preparación de lo que ha venido ahora)
• KVM portado a PPC, S390 e IA64: La solución de virtualización completa KVM ha sido portada a esas arquitecturas.
• Soporte de redes wifi "mesh": La IEEE está trabajando en un estándar para redes mesh wifi, 802.11s. Llamadas en español redes en malla (¿por qué esa palabra me recuerda a Batman?). Se caracteriza por basarse en que cada nodo encamina sus tráfico de red a través de cualquier nodo que esté a su alcance, pudiendo prescindir de ese modo de un servidor central y soportando sin problemas que un nodo desaparezca, pues simplemente se utiliza otro. Gracias al proyecto open80211s y las empresas que lo apoyan, en 2.6.26 habrá soporte preliminar de los borradores de este estándar.
• Soporte de PAT (Page Attribute Table) en x86: Esto no es algo que afecte directamente al usuario, pero es interesante porque consiste en utilizar una característica de los x86. Se trata de un sustituto/complemento de los MTRR. Los MTRR permiten configurar como se va cachear un rango de la memoria, lo cual es necesario por vaya a saber usted qué razones. Puede que alguno recuerde haber tenido conflictos con los MTRR y las X. Bien, pues PAT consiste en lo mismo: configurar como se va a cachear parte de la memoria. La diferencia es que en vez de configurar un rango, con PAT se configura ese aspecto individualmente para cada página de memoria (4KB). Lo cual es más flexible y además no tiene las restricciones de los MTRRs, que no podían configurar muchos rangos de memoria a la vez. Esta característica no es precisamente nueva en los x86: los parches actuales en Linux se empezaron a desarrollar en 2006, y hay rastros de implementaciones preliminares de Enero del 2001. En gran medida porque tampoco se trata de algo tan importante, y los MTRRs cumplían su función sin demasiados problemas.
• 'Securebits' para cada proceso: Creo recordar que uno de los creadores de Unix admitió que los suid fue el mayor error de diseño que cometieron. Los sistemas derivados de Unix llevan décadas intentando librarse de ellos sin demasiado éxito. Para ello se inventó una cosa denominada "capabilities". Se preguntarán algunos: ¿pero no tenía linux "capabilities" desde hace tiempo? Eso mismo pensaba yo, y es cierto que las tenía, pero limitaciones prácticas hacían imposible la construcción de un sistema que prescindiera de los suid y utilizara "capabilities". Parece ser que en 2.6.26 se elimina esa limitación, haciendo posible construir por primera vez un sistema sin suid.
• KGDB: Durante años, Linus Torvalds se ha negado rotundamente a meter un depurador de kernels en el núcleo: "When things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger [..] I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_." (email completo). Sin embargo, muchos otros desarrolladores llevan años queriendo tener uno. Ahora que Linus se mete mucho menos en decisiones y deja que la comunidad decida más a su aire, finalmente se ha conseguido meter KGDB.
• Memtest: Todos conocemos memtest. Pues ahora Linux tambien está implementando uno que se activa pasando un parámetro. No es su objetivo -en principio- sustituir al memtest que todos conocemos, en realidad este memteste es muy, muy simple y mucho menos capaz. Pero al poder distribuirse con el kernel es muy práctico.
• Semáforos genéricos: Hasta la introducción de los mutexes, los semáforos eran utilizados en partes del código muy críticas en cuanto a rendimiento. En el mundo linux eso significa que la implementación de los semáforos se codificaba independientemente para cada arquitectura soportada, optimizado con ensamblador. Sin embargo, tras la introducción de los mutexes los semáforos no se utilizan en casos que se necesite rendimiento crítico. Por eso se ha podido hacer una implementación genérica que elimina 7365 líneas de código.
• Mejor soporte de webcams: Existe un estándar "USB Video Device Class" (UVC) para webcams que es implementado por muchas cámaras actuales (ej: iSigth) y lo será de casi todas las del futuro. Con la inclusión del driver que lo implementa, Linux añade soporte para una importante variedad de webcams existentes en el mercado.
• /proc/PID/mountinfo: Con las recientes evoluciones en el VFS (como por ejemplo, las "bind mounts") en su objetivo de evolucionar hacia Plan 9, /proc/PID/mounts se ha quedado obsoleto y se hace necesario un nuevo archivo que describa con más detalle los puntos de montaje.
• /sys/class/bdi: En 2.6.24 se incluyó un mecanismo que pasaba a regulaba la cantidad de memoria "sucia" (que se tiene que escribir al disco) que puede generar cada proceso independientemente para cada dispositivo, no globalmente. Ahora en 2.6.26 se puede tunear el mecanismo en ese directorio de sysfs.

En fin, esto es lo principal, hay muchas otras cosas, como unas mejoras de rendimiento de RAID y del journaling de ext3, y de FUSE, y soporte del OLPC y de la aceleración 3D de las ATI r500, y muchos drivers nuevos. La lista completa está aquí.