Hay una especie de "regla no escrita" en el mundo linuxero que dice que toda persona "debe" compilar su propio kernel, como parte de su proceso de aprendizaje o de incremento de su "estatus geek". Nada más lejos de la realidad
El kernel, al igual que el resto del software del sistema, no deberia necesitar compilarse - como cualquier software diseñado decentemente. Lo que mucha gente no sabe es que Linux 2.6 es lo suficientemente avanzado como para que un kernel precompilado funcione perfectamente sin retoques en la mayoría de sistemas
* Razón 1: Hay un mito sobre el kernel: La gente piensa que optimizando el kernel, el sistema irá más rápido, y que si no lo haces irá lentísimo y estarás desaprovechando tu equipo.
Vamos a ignorarlo y hacer un análisis serio. Pregunta: ¿Cuanto tiempo de CPU gasta un sistema normal ejecutando codigo en espacio de usuario y cuanto gasta ejecutando código del kernel?. sar (maravilloso programa que no debería faltar en vuestros sistemas) puede decirlo:
20:05:01 CPU %user %nice %system %iowait %idle
20:05:01 all 6,23 0,00 0,50 0,25 93,03
Como se puede ver en este caso, de todo el tiempo de CPU transcurrido en mi sistema en un uso típico de escritorio (email, firefox, escribir artículos malos) solo un 0.50% del tiempo de CPU ha sido utilizado por el kernel, y un 6.23% por programas de espacio de usuario (un servidor dará diferentes números, de hecho un servidor web dará porcentajes diferentes a un pc haciendo de router). Es decir, 12.46 veces más. De todos los ciclos de CPU durante el que se ejecuta "software real" (todo lo que no es tiempo "idle") el 92.57% se ejecutan en espacio de usuario, y un 7.42% en el kernel.
Lo que quiere decir esto es que en un uso normal el sistema se pasa la mayor parte del tiempo ejecutando software en espacio de usuario, y que por lo tanto optimizar el kernel no mejorar el rendimiento del sistema de manera notable, por la simple razón de que la mayor parte del tiempo no es su código el que se está ejecutando. En las distros precompiladas tiene especialmente poco sentido: ¿Para qué optimizar para el procesador de turno el 7.42% del tiempo de ejecución si el software que se ejecuta el 92.57 del tiempo está "optimizado" para i586 o i386?.
Esto tampoco quiere decir que la optimización no influya en absoluto: Hay ciertas funciones (como las funciones que mueven porciones de memoria de un sitio a otro) que se utilizan mucho y algunas tienen incluso optimizaciones específicas en ensamblador. Lo que quiero decir es que esperar que el optimizar el kernel vaya a acelerar notablemente un sistema típico es lo mismo que esperar que un grano de arena sea distinguible en un desierto.
* Razón 2: Las diferencias entre procesadores puede que no justifican la optimización. Eso tampoco quiere decir que no existan esas diferencias o que no vayan a influir: Simplemente, las diferencias no son tan grandes como para justificar la optimización. Las distribuciones suelen tener un kernel i586 por defecto (excepto ubuntu y debian) y muchas kernels precompilados adicionales disponibles (para k7, para athlon64, para p4) en los repositorios. En serio, no necesitas recompilar el kernel solo porque en el kernel no añadieron una opción al gcc que tu "sabes" que en "teoria" optimiza mucho el ejecutable para tu máquina. Como ejemplo extremo está Ubuntú: Su kernel por defecto está optimizado con instrucciones de i386 (pero optimizadas para un pentium 4, esto es otro tema), y apuesto a que mucha gente ni siquiera se ha dado cuenta. Además hay que tener en cuenta una pecularidad de la plataforma x86: Todos sus procesadores se parecen "enormemente" entre si. De hecho, es la base de su éxito: Si x86 está donde está es en gran parte por no cambiar demasiado y preservar la compatibilidad lo máximo posible. En general, cuando las empresas dedicadas a CPUs preparan una nueva versión de CPU intentan copiar al máximo y dentro de las posibilidades de la nueva arquitectura el comportamiento de los procesadores anteriores, por la simple razón de que los compiladores tardan años en optimizarse para una arquitectura determinada. Eso puede suponer que al salir el producto a la calle el rendimiento sea pobre y que el producto fracase comercialmente. ¿A alguien le suena Itanium?
Una de las principales diferencias entre los x86 (además de las diferencias fundamentales como netburst vs opteron etc) son las extensiones "multimedia": MMX, SSE, 3dnow. Estas son especialmente irrelevantes para el kernel: Existe una regla en el kernel que prohibe utilizar código en punto flotante en el kernel excepto en unos pocos lugares controlados (usarlo demasiado obligaría a guardar los contenidos del coprocesador matemático entre cambios de contexto y eso enlentecería mucho el kernel). Se utilizan en algunos puntos, pero se evitan como si tuvieran la peste
Lo que quiero decir aquí es que esto es como los benchmarks de Intel vs AMD: "En x benchmark AMD gana a intel un 5%". Si, el AMD es más rápido, pero esa "ventaja" supone que en vez de tardar un minuto el amd lo hace en 59 segundos, que es prácticamente lo mismo. Es muy probable que no notes las optimizaciones que estes haciendo al compilar a mano el kernel. Son demasiado pequeñas. Las principales diferencias vienen casi siempre de mano los algoritmos: No hay optimización de procesador en el mundo que vaya a hacer que el kernel descarte correctamente tal o cual dato en el cache de disco o el orden correcto en el elevator del kernel, por ejemplo, y te aseguro que esa decisión va a influir muchísimo más en el rendimiento de tu máquina que cualquier optimización a nivel de procesador
* Razón 3: Seguridad: Si descargas y compilas tu propio kernel, el día que haya un fallo de seguridad en el kernel tendrás que: 1) Enterarte. Algo que no es fácil, porque los fallos de seguridad del kernel casi nunca se reportan en barrapunto o slashdot o osnews (y si piensas que si, significa que no te has enterado de muchos fallos de seguridad o incluso de que alguien ha hackeado tu servidor gracias a uno de esos bugs y tiene instalado un rootkit en él ahora mismo, y no tengo por qué estar siendo paranoico) 2) reconfigurar 3) recompilar
Sin embargo, si instalas un kernel precompilado, lo instalarás a partir de los paquetes de tu distro, y los sistemas de actualización de tu distro te lo actualizarán automáticamente en cuanto haya nueva actualización de seguridad. Es una opción bastante más inteligente...
* Razón 4: Tener muchas cosas (opciones) compiladas en el kernel no daña necesariamente el rendimiento: Alguna gente se cree que tener todos los sistemas de archivos en el kernel, o la emulación de coprocesador matemático va a hacer las cosas mas lentas. ¿Por qué? No se trata mas que de un gran IF: Si algo no se usa, no tiene porque afectar al resto. El código de un dispositivo que no se tiene jamás se ejecutará. Y por supuesto la mayoría de kernels precompilados no hacen esas cosas - se modularizan las cosas exageradamente, hasta el punto que algunas distros nisiquiera compilan el sistema de archivos del sistema de archivos root / en el kernel, compilan todos como módulo y cargan el necesario en el initrd
* Razón 5: Tener muchos módulos es útil: La gente suele compilar su kernel porque quiere "compilar solo el soporta para su hardware y quitar el resto". Esto está relacionado con el punto anterior. La pregunta es: ¿Por qué? Los módulos no utilizan nada más que espacio en el disco al menos que no se carguen. Probablemente tengas un /usr/X11R6/lib/modules/drivers/vmware_drv.o en tu sistema. ¿Recompilas las X solo para desactivar ese driver? ¿Recompilas para desactivar las librerias de accesibilidad de gnome solo porque no las necesitas? Tener 100 o los módulos que sean ahí no hace daño. Tampoco es ninguna guarrada: Es lo correcto. El objetivo del kernel es que tu hardware funcione, y el soportar más hardware del que tienes significa que podrás cambiar de hardware sin recompilar el kernel: Y esto es importante para todos, porque con USB y firewire es imposible determinar en tiempo de compilación que dispositivos vas a acabar conectando a tu equipo. La flexibilidad es una característica del software, y es buena.
Una vez sufrí un problema relacionado con esto: No tengo un lápiz USB, asi que no tenía compilado el soporte. Pero resulta que un amigo vino con un disco duro externo USB, y como no tenia ganas de hacerle soportar la espera de compilar un kernel, tuve que iniciar en Windows. Windows paraba la transferencia a la mitad y el driver dejaba de funcionar asi que finalmente tuve que hacer esperar a mi amigo. Moraleja: Un sistema moderno tiene USB y firewire y por lo tanto no tiene una configuración de hardware estática
Udev es quien se encarga de hacer gran parte del trabajo de configurar el hardware del sistema y cargar los modulos de tu hardware y no cargar los que no son. Si yo por ejemplo enchufo mi webcam Creative Go Plus, el kernel notifica a udev de que se ha insertado un dispositivo en el bus usb, udev mira que es mirando identificando el hardware y carga los dos ó 3 módulos de soporte básico de USB, el módulo de la camara, el módulo del chip de la camara, y el módulo de V4l. Automaticamente. Pero si no la enchufo, no las carga, y puedo hacer que udev descargue los módulos cuando desenchufo la cámara - no hay "bloatware" en ningún lado. Las máquinas se inventaron para hacer cosas por nosotros. Utilizalas para ello y utiliza un kernel precompilado y udev. Muchisima gente de la que compila su kernel a mano no activa el soporte de hotplug (necesario para udev), porque piensa "que no lo necesita". Lo cual nos lleva al siguiente punto
* Razón 6: Configurar el kernel no es fácil y los mantenedores del paquete precompilado saben que necesitas mucho mejor que tú, aunque no lo creas: El número de opciones disponibles en la fase de configuración del kernel se multiplica en cada versión, y a día de hoy es prácticamente imposible saber configurar correctamente todas las opciones. Mi config tiene 1034 opciones diferentes entre las activadas y desactivadas. ¿Sabes configurar correctamente esas 1034 opciones? Puedes pensar que sabes, pero siendo realistas no hay nadie en el mundo que sepa configurar por si mismo un kernel por completo. Yo llevo años compilando decenas y decenas de kernels por afición al desarrollo del kernel, y aun hay muchas opciones que no se que hacen, ni si debería activarlas o no. Ni tan siquiera los hackers del kernel lo saben, ni Linus Torvalds, te lo aseguro (bueno, quizás Alan Cox...) Los que mantienen una arquitectura no se enteran de que cosas están haciendo los del soporte USB, y viceversa. Por si fuera poco, muchas opciones no están documentadas (o están mal documentadas, que es peor), algunas son peligrosas y otras no puedes saber si activarlas o desactivarlas porque simplemente te da lo mismo (como pasa con cualquier proyecto software que tenga este tamaño: nadie puede conocer 200 MB de código C, además en linux se tiene la "manía" de hacer todo extremadamente configurable hasta el punto que dudo mucho que exista un kernel más configurable) Y la configuración por defecto que trae el kernel de kernel.org está muy lejos de tener los valores por defecto ideales. Moraleja: Deja que los mantenedores de tu distribución se ocupen de la compleja tarea de configurar el kernel. Ellos tienen los recursos (varias personas, sistemas de seguimiento de bugs por si se equivocan en algo, etc) para hacerlo, tú no.
¿Y esto para que lo escribo? Para intentar evitar que la gente se pase la vida compilando kernels por "tradición". Eso no quiere decir que esté prohibido compilarles: Compilar kernels es una actividad divertida y entretenida para un geek, siempre que tenga una razón para ello (por ejemplo, que le da la gana). Lo absurdo es hacer lo que hace la gente: Compilar por que si, sin tan siquiera tener ganas, como si fuera una "obligación" a su estatus de "geek".
Autor: Diego Calleja - http://diegocg.blogspot.com/
Entradas
