Ya tenemos nueva versión del kernel de Linux y entre sus mejoras se puden destacar las siguientes:
-
Mejoras del gestor de procesos: Además de unas mejoras de rendimiento que ponen a CFS al nivel del antiguo gestor de procesos (e incluso un poco mejor), en 2.6.24 se podrá escoger cómo particionar el tiempo de CPU. Hay dos métodos: uno que lo particiona por cada usuario, es decir, si un usuario ejecuta un programa con un bucle cerrado y otro usuario ejecuta dos, el primer usuario tendrá un 50% para su programa y el otro el otro 50% para sus dos programas (25% cada uno). Para un servidor multiusuario esto es muy útil; las “bombas fork” por poner un ejemplo no serían capaces de afectar a otros usuarios. El otro sistema particiona la CPU de un modo completamente configurable: Se crean “grupos de control de recursos”, se configura el grupo, ej: que tenga el doble de tiempo de CPU disponible para sus procesos, y se pueden asignar los PIDs que tu desees a ese grupo. El PID heredará las propiedades del grupo automáticamente, es decir, tendrá más prioridad que un proceso normal, es decir, como un “nice”, pero aplicado a un grupo de procesos aleatorio, no a uno solo ni a un solo usuario. Este sistema está basado en su parte de configuración en los “task control groups”, que también es algo nuevo y se comenta y se entiende mejor en el siguiente punto.
-
Task Control Groups, o grupos de control de procesos. Este es un invento que sirve para la asignación y control de recursos a grupos de procesos, que es algo que algunos UNIX tienen hace tiempo y que Linux, aunque lleva años pensando el como y tiene mil implementaciones sueltas por ahí, añade finalmente en esta versión despues de años de trabajo. La idea es que el usuario crea “grupos de control de procesos”, algo que en la práctica consiste crear uno o varios directorios en un sistema de archivos virtual especial. Ese directorio contiene, nada más crearle, un montón de archivos que pone ahí el kernel y que son la interfaz de configuración. Leyendo o escribiendo a esos archivos uno configura las propiedades del grupo creado: ej. el tiempo de CPU, como se explicaba en el punto anterior. Por supuesto, por si solo un grupo configurado no sirve de nada, para que tenga alguna utilidad hay que añadir procesos al grupo creado, que en la práctica se traduce a escribir su PID en un archivo del directorio del grupo que has creado: Ese proceso heredará automáticamente las propiedades del grupo. Puedes crear todos los grupos que quieras, configurarle las propiedades que quieras y vincular los procesos que quieras con él. Se ha mencionado que se puede configurar el tiempo de CPU, pero también se pueden configurar otras cosas, como las CPUs o nodos de memoria en los que quieres que se ejecuten los procesos del grupo; incluso puedes especificar que no se permita que otros procesos se ejecuten en las CPUs que has reservado. De manera que puedes hacer cosas como que unos procesos que a ti te caen bien tengan el doble de tiempo de CPU que un proceso normal, se ejecuten solo en las CPUs 1, 2, 5, 10 y 11, y que su memoria se ubique solamente en el nodo de memoria 1. Esta es la infraestructura base de asignación de recursos a procesos, y a día de hoy existen las posibilidades citadas: control del tiempo de cpu, de CPU y nodo de memoria en el que se ejecutan los procesos…pero en el futuro se añadirán más posibilidades (máximo tamaño de memoria ocupado, quizás prioridades I/O, etc).
-
Soporte de Tickless (NO_HZ) para x86-64, PPC, UML, ARM, MIPS….por cierto, también está “cpuidle”, una nueva infraestructura para gestionar el tiempo muerto de la CPU, con una política (opcional) optimizada para NO_HZ. En resumen, que es algo que sirve, como titulaba una charla de un ingeniero de Intel, para…How to do nothing…efficiently.
-
Reunificación de las fuentes de x86-32 y x86-64: Ya no hay arch/i386 y arch/x86_64, hay un solo directorio arch/x86 (aunque se conservan algunos enlaces simbólicos en los directorios antiguos, por compatibilidad). Esto no significa que se elimine una arquitectura: en realidad, buena parte del código fuente sigue sin compartirse y se compila exactamente igual siempre. Lo que se ha hecho es mover todos los archivos de las dos arquitecturas a ese arch/x86, pero añadiendo los sufijos “_32.c” y “_64.c” a los archivos de cada arquitectura. Poco a poco, los programadores buscan similitudes entre los archivos de nombres equivalentes pero sufijos distintos, lo unifican y lo ponen en un mismo archivo sin sufijo. Es una manera de unificar la máxima cantidad de código fuente posible entre ambas arquitecturas.
-
Puntos de montaje “bind” de solo lectura: A día de hoy existe, aunque no se utilize mucho, la opcion “mount –bind”. –bind sirve para montar un directorio o punto de montaje ya existente en cualquier otro lado. Por ejemplo, si haces “mount –bind ~/midirectorio /tmp”, tu directorio “midirectorio” se montará y será accesible en /tmp tambien. Pues bien, ahora en 2.6.24 se pueden hacer monturas –bind de solo lectura, de manera que no se pueda escribir al directorio montado. Esto util desde el punto de vista de seguridad, para dar a los servidores para servir directorios a los que no se podrá escribir si un cracker logra acceso al sistema.
-
Espacios de nombres para los PIDs y la pila de red: Esto tiene que ver con la virtualización a nivel de sistema operativo, tipo vserver o openvz, las “jails” de los BSDs o los “containers” de solaris: un proceso puede crear un nuevo espacio de nombes de PIDs…de manera que al mirar la lista de procesos del sistema, solo verá….¡su proceso! Todos los demás procesos del sistema no le serán visibles. Es como un chroot, pero mejor hecho. Idem respecto a los espacios de nombre de la pila de red: cada espacio de nombres de red podrá tener sus propias reglas de cortafuegos, y cosas así. Esto es muy bonito pero solo será util cuando se haya introducido el soporte completo de containers y utilizando las utilidades de vserver/openvz. Como tantas otras cosas, esto estaba disponible hace años en forma de vserver/openvz, pero solo ahora entra a formar parte del kernel principal.
-
Límites de memoria “sucia” para cada dispositivo: Aunque parezca raro, hasta el día de hoy Linux mantenía un límite global de la cantidad de memoria que puede estar “sucia” (sin escribir a disco). Esto tiene unos efectos divertidísimos cuando tienes en una máquina dispositivos como ej: un disquete y unos discos ultra rápidos, que “limpian” la memoria a velocidades muy diferentes. Y no cuento nada en el caso de dispositivos de bloques “anidados”, como es el caso de cualquier máquina con LVM/MD. En 2.6.24 los límites son independientes para cada dispositivo y se calculan dinámicamente teniendo en cuenta el ritmo de escritura de cada dispositivo. Esto mejora el rendimiento en muchas configuraciones.
-
Soporte SPI/SDIO en la capa MMC: ¿Sabían ustedes que las mierdas de ranuras donde se meten las tarjetas de memoria MMC en las cámaras digitales pueden actuar como bus si al fabricante le da la gana añadir los cables y chips necesarios, y que se les puede conectar tarjetas wireless y cosas así? El dia
blo no dejará nunca de sorprendernos. En cualquier caso, ahora Linux soporta esa tecnología diabólica, para que ustedes condenen sus almas con esos inventos propios de Microsoft.
-
Autorización USB: Pues resulta que como parte de los esfuerzos para soportar USB wireless (si, hay USB sin cables, aunque aun es muy nuevo) ahora la pila USB puede configurarse a través de sysfs para que los dispositivos USB conectados al sistema no pasen a funcionar inmediatamente. Han de estar “autorizados” para funcionar. En el caso de USB wireless, es imprescindible pues no se puede permitir que los dispositivos USB wireless que pasen por tu lado se conecten automáticamente a tu ordenador. Pero puesto que esto tambien esta disponible para el USB normal y corriente, es muy útil para crear configuraciones “kiosk” en cybers o en “clientes tontos” en los que sea imposible conectar cosas a la torera si no hay autorización expresa.
-
Markers: Esta es una de las partes que conforma lo que podríamos llamar “Dtrace de linux”, es decir, systemtap (la otra es kprobes, que ya está; ya solo falta utrace). Un sistema como systemtap puede insertar “probes” en cualquier lado dinámicamente, pero hay puntos del kernel (ej; donde se gestionan los “fallos de página”, para contarlos) que por su importancia se tiende a insertar “probes” muchas veces en ellos: Por eso es más práctico añadir un “probe” estático, que además es más eficiente.
-
Antifragmentación de la memoria: tres años, tres, ha estado un tipo implementando unos parches que reduzcan la fragmentación de la memoria, es decir, que permitan satisfacer grandes asignaciones de memoria contigua (es decir, múltiplos de 4KB en x86 – 8KB, 12KB, 16 KB) despues de que el sistema lleve mucho tiempo siendo utilizado. Sin estos parches, un sistema muy utilizado puede tener MBs disponibles de memoria libre…¡pero puede que ni tan siquiera unas pocas decenas de KB de esos MB sean contiguos! Si se ha tardado tanto es porque se trata de una mejora que afecta a la asignación de memoria al más bajo nivel posible, y ha habido mucha discusión sobre como debía hacerse, y los parches se han rehecho mil veces, incluso ha habido parches implementado más de una alternativa. El caso es que por fin se ha incluido, que mucha falta hacía.
- Drivers para dispositivos inalámbricos: En Linux se añaden drivers continuamente, pero en esta ocasión se ha añadido una buena cantidad: 8, 2.3 MB de código en C, soportando una amplia variedad de dispositivos: Intel PRO/Wireless 3945ABG/BG, Intel Wireless Wifi Link AGN (4965), rt2400 pci/pcmcia, rt2500 pci/pcmcia, rt61 pci/pcmcia, rt2500 usb, rt73 usb, BCM43xx IEEE 802.11G, prism54….además de esos, se incluyen otros cuantos de red pero no-wireless; Intel(R) 82598 PCI-Express 10GbE, E1000E pci-express, IP1000A….
La Comunidad de KDE anuncia la inmediata disponibilidad de KDE 4.0.0. Esta significativa versión marca tanto el final del largo e intensivo período de desarrollo que lleva a KDE 4.0 como el principio de la era KDE 4