Evolución del tamaño del kernel Linux

Uno de los dessarrolladores del núcleo Linux ha realizado un estudio del tamaño de las distintas versiones del kernel Linux, y como era de esperar el gráfico resultante demuestra ese crecimiento que se ha acentuado a partir de la versión 2.2.0.

Como explica Jérôme Pinot en la lista LKML y en el post de su blog, el crecimiento es en su mayoría “exponencial”, y si se mantiene al mismo ritmo, el kernel Linux ocupará 100 Mbytes en su versión tar.bz2 para cuando lleguemos a Linux 3.19 (el kernel 3.1.1, que apareció el pasado 11 de noviembre, pesa 73,7 Mbytes).

En el post original podéis encontrar las fuentes de información que ha usado este desarrollador para generar el gráfico, para el que ha utilizado este fichero de gnuplot. Curioso esfuerzo, y muy representativo de ese gran tamaño que se debe esencialmente a la inclusión de más y más controladores de dispositivos.

evolución Kernel kernel Linux Linux tamaño

Marcelo
Un claro reflejo del éxito de Linux. Somos mucho pero mucho más que ese mísero 1%.
- WeNDaL
  El crecimiento no deriva en el número de usuarios que lo usan. Más bien depende de las estrategias y aportes que muchas empresas hacen al núcleo, especialmente para entornos de servidores y plataformas tipo Android, Ese mísero 1% al que haces referencia, son los usuarios de escritorio, y esos no creo que sean muchos más. Ahora bien, si tienes en cuenta el crecimiento que ha tenido el núcleo linux en proyectos para tablets y smartphones, por supuesto que existe más de 1% de usuarios.
  Un saludo
  - Marcelo
    Creo que no me has entendido. Según mi parecer, si miras el asunto en más profundidad, verás que este abrupto crecimiento del núcleo es un claro indicio del éxito del sistema (lo que es igual a un aumento de usuarios). Me baso para ello en el siguiente razonamiento:
    Si algo evoluciona de manera tan contundente, es porque hay muchos interesados en ello. Ergo… es exitoso… ergo… sus usuarios son muchos más de lo que nos quieren hacer creer.
    - Ootneg
      Siento decirte que ese razonamiento es una falacia.
      El incremento de controladores del núcleo se debe al continuo desarrollo de la industria, que produce continuamente nuevos dispositivos que necesitan ser controlados, es un aumento de la demanda, sí, pero no por un crecimiento equivalente del número de usuarios sino del número de dispositivos en el mercado. De hecho la inmensa mayoría de los controladores no son necesarios para un usuario medio (prueba a compilar tu núcleo a mano con “make xconfig” o “make menuconfig” y léete la ayuda sobre cada módulo, verás como la mayoría no sabes ni qué dispositivos controlan.
  - LoboOscuro
    Es cierto, puede que tengas razon, no me fije si la kernel posee modulos o controladores para celulares. Si es asi lo estan haciendo mal, tienen que separar en 2 fuentes para no mezclar con los modulos de celulares, de lo contrario su configuracion durante la compilacion se puede complicar todavia mas…
  - Ootneg
    Y no olvidemos para quiénes desarrollan mayoritariamente esos nuevos módulos del núcleo: empresas que entre sus clientes corporativos tienen a universidades, laboratorios, agencias de seguridad, servidores, centros de investigación, etc; por no hablar de que Linux sí está experimentando un enorme crecimiento en los sistemas empotrados (mi televisor LED Samsung tiene como SO Linux), pero efectivamente eso no significa que el número de usuarios personales sea mucho mayor que ese 1-1’5% que se dice.
- Pedro
  Lo único que se refleja es que el Hardware aumenta exponencialmente y que parte de ese hardware está siendo soportado igual exponencialmente (aunque no precisamente tiene porqué ser con la misma Base).
  - Danubio
    Aunque en las futuras versiones del kernel se va eliminando lo que es el Hardware demasiado viejito para eso se instala un kernel mas viejo para lo que es un sistema muy antiguo ya que en el nuevo kernel van quitando lo pasado.
    - cpcbegin
      Pues me parece fatal que se elimine hardware antiguo porque eso complica la vida a los que tenemos equipos con más años.
      GNU/Linux no se puede convertir en otro sistema operativo para ricos.
      - Ootneg
        Tampoco es eso, hombre. Esos controladores se eliminan del kernel, pero por supuesto que puedes compilarlos e instalarlos por tu cuenta. Por ejemplo tengo un portátil de hace 7 años con una inalámbrica rara para la cual no hay controlador en el núcleo, y comprendo que sea así, el resto de usuarios del mundo no tiene por qué ver sus núcleos engordados inutilmente simplemente porque al fabricante de este ordenador le dio por poner la tarjeta wifi más friki que había, pero tengo en internet una página de un desarollador que mantiene el controlador de mi tarjeta y que sólo tuve que instalar con un tradicional “make && make install”.
        No te preocupes, que a no ser que nadie quiera mantener los controladores para tu equipo, su exclusión del núcleo sólo significa que tendrás que tomar una pequeña molestia, pero nada más.
    - yo
      Lo siento, pero no se elimina lo que es el Hardware demasiado viejito. Sino los controladores que nadie quiere mantener, que suele coincidir con el Hardware demasiado viejtio. Pero es una coincidencia. Si aparece alguien dispuesto a seguir mejorando, cambiandolo a las nuevas técnicas internas de linux, el soporte seguirá ahí. (por cierto, también puede volver a aparecer bajo los mismos requisitos).
LordMarcus
mi pregunta es si los controladores no podrian estar en un mòdulo aparte? y dejar el kernel “puro” en otro mòdulo, a ver cuanto ocupa.
- arag
  el kernel son los controladores
  - joshua
    si eso fuera así, porque tenemos que buscarlos cuando no reconoce el hardware? el kernel podría vivir sin controladores y facilitar la integración de nuevos controladores, así seria mas rápido y liviano.
    - jale
      Porque los controladores se cargan como módulos del kernel, pero siguen siendo parte del kernel y están en el código fuente del kernel
      La facilidad de integración de nuevos controladores (módulos del kernel) es que estos se cargan de forma dinámica.
      El modelo monolítico con carga dinámica de controladores, es el más eficiente y liviano (por detrás de la compilación de kernels a medida de tu máquina)
- Garolard
  Se supone que si, pero incluyéndolos, la versión genérica del núcleo se vuelve más compatible. El que quiera un núcleo mínimo siempre puede compilarlo para su sistema específico incluyendo los controladores que necesita, eso si, hay que echarle huevos.
  @arag el kernel no solo son controladores
- elvis
  en teoriael kernel puede ser compilado para solo contener lo que realmente necesitas si no necesitas un modulo porque tendrias necesidad de cargarlo ?. el kenel esta diseñado para contener el mayor soporte posible eso podria explicar un poco el crecimiento en cuanto a tamañaop que ha tenido en los ultimmos años. El problema es que la mayoria de los usuario al ser soilo usuarios a nivel desktop no estan preocupados por obtimizar sus instalaciones y retirar lo que no necesitan del kernel.
  En parte le doy la culpa a las distros de escritorio como ubuntu por ejemplo. le dan al usuario uyna distro usable y relativamente amigable eso les hace olvidar los detalles ( lo cual en parte es bueno ).
  El kernel es modular pero tienes que tomarte el tiempo para decidir que modulos quieres y cuales nop
  - julio
    porque hablais sin tener ni puta idea?
    el kenel (udev) solo carga aquellos modulos que son necesarios para el hardware, no carga los miles de módulos que tiene. haz un lsmod y lo veras.
Bernat
Este dato se sabía, sería interesante saber cúal ha sido el crecimiento sin contar los controladores, seguramente no demasiado. Es bueno que haya tal crecimiento de controladores, significa que cada vez hay más soporte de hardware.
jalp
No sé si es un disparate lo que voy a decir(o si es factible o no), pero creo que se debería trabajar en que el núcleo sea modular y no monolítico. Algo como lo que hicieron con osx.
Supongo que de ser posible será costoso de programar y llevará mucho tiempo, pero podría ayudar a que se agilice el desarrollo en un futuro, y nos podría quitar muchos problemas con drivers privativos y demás historias.
Todo esto lo digo desde el desconocimiento, igual es una burrada, no lo sé.
- Juan Carlos
  Esos dos tipos de núcleos se utilizan en Linux; pasate por:
  http://www.nosolounix.com/2011/11/kernels-modulares-y-monoliticos.html
  O mejor (más amplio), por acá:
  http://www.frm.utn.edu.ar/soperativos/Archivos/nucleolinux.pdf
  Saludos
- Andres Ing informatico
  El Kernel linux es modular no es monolitico ya de por si, cuando compilas puedes elegir entre quitar algo, ponerlo como modulo o incrustado en el kernel. de hecho en la configuración por defecto casi todo viene como modulo, ojo, viene, osea te ocupa espacio pero no cargas los modulos si tu ordenador no necesita usarlos.
  - Pasaba por aquí
    Creo que a lo que el se podría referir es a lo que hicieron referencia antes, que los controladores vengan en paquetes de instalación aparte del kernel “puro”. Aunque de esas cosas tampoco sé…
    - julio
      Y luego en miles de foros y post preguntando que modulos necesita x hardware para z versión del kernel? la verdad es que no lo veo.
      Si solo quieres tener x módulos, compilas el kernel con los módulos seleccionados. Que esto no es posible para todo el mundo, desde luego que no, pero es que lo primero tampoco.
      Y no me digáis que se tarda mucho en compilar el kernel, en un equipo de hace dos años, tardas menos de media hora.
      Y si os seguis quejando de modulos y dependencias, pues que todo el mundo se pase a gentoo, que incluso a la hora de compilar los paquetes puedes elegir si quieres que el programa soporte tal característica o no
      - Pasaba por aquí
        Por si las dudas uso Gentoo desde hace dos años, sólo estaba tratando de saber qué era lo que quería decir jalp.
    - ox1d0
      @Pasaba por aquí
      Si usas gentoo sabes que no todos los modulos que nesesita tu hardware vienen integrados en el kernel algunos ni como modulos.. O que te refieres con Kernel puro..?
      con un make clean te limpia el kernel y lo deja puro o puedes borrar el .conf en /usr/src ..
      - Abel
        No se usa más make mrproper
  - TheGodDemon
    Osea que solo ocupa espacio en disco, mas no en memoria? porque si solo ocupa espacio en disco entonces no hay problema a mi parecer, los discos duros cada ves son mas grandes y 100mb no es nada, y existe distros para pcs viejas para los que mensionen discos de 3gb o algo asi.
    - arag
      el problema viene siendo que ocupa espacio en los cd y dvd de instalación, pero tampoco es tan problematico por que siempre las distros para usuarios normales usan kernel modificados donde sacan módulos de hardware que no se encuentra en en una computadora de escritorio
  - bonares
    Va ser que no, ya que estas confundiendo modular a nivel arquitectura, algo que no es:
    http://en.wikipedia.org/wiki/Monolithic_kernel
  - jale
    El kernel de linux es modular y monolítico
    Modular porque se pueden cargar diferentes partes del kernel de forma dinámica
    Monolítico, porque los módulos (o drivers) se ejecutan en el mismo espacio y privilegio que el propio núcleo
  - mauricio
    El kernel linux si es monolítico, no es 100% modular, en todo caso la definición mas acertada sería hibrido
fran
@LordMarcus creo que solo se montan los modulos que hacen falta en cada momento no el total del kernel,
#
Hombre, si tenemos en cuenta que el eje x es LA VERSIÓN, no me parece que el crecimiento sea exponencial para nada, al menos en la línea temporal. La 2.2 duró unos 2 años, la 2.4, 3, mientras que la 2.6 lleva con nosotros casi 8 años…
Si encima recordamos de que la decisión de cambiar la numeración de 2.6 a 3.x vino de que a Linus no le gustan los números grandes, mejor ni hablamos.
- Daniel
  Es cierto, la gráfica debería estar basada en tiempo natural y no en versiones del kernel
nechus
Ojalá el número de usuarios de Linux en el escritorio generara un gráfico igual. :(
- pues pídelo
  Pues hagamos algo, poco es mucho más que nada:
  http://malagaoriginal.blogspot.com/2011/10/lucha-activa-por-el-software-libre.html
NERvo
¡Crecimiento Exponencial!
SergioSistemas
Que alaraquera por miserables 100 megas de kernel……………
Luis
pues yo nompre una laptop sony vaio vpcsc y ningun linux y ningun ubuntu le es compatible. Solo Natty pudo ser instalado funcionando perfecto pero se traga la bateria en 2 horas y se calienta como una colegiala. Muy a mi pesar me quedo con windows 7
- ox1d0
  cuando aprendas a compilar modulos tus problemas se resolveran
Pingback: Gráfico: el tamaño del kernel Linux | Nunca funciona a la primera()
Hector Macias Ayala
Vaya criterio más infantil para medir la evolución de algo, ha crecido porque viene con más controladores que antes.
- francesco
  El tuyo anda que también… si tiene más controladores signfiica que hay más hardware , eso también significa que hay más gente con pc’s de distintos tipos, y eso significa que algo aumentó, no mucho pero aumentó.
  - Hector Macias Ayala
    Todos los sistemas tienen más contorladores al aparecer más hardware, eso no significa nada en absoluto en cuanto a la evolución en términos cualitativos, no es más rápido, seguro ni estable por ese motivo.
ox1d0
En todo Caso no crecio el kernel propiamente Crecieron los modulos que puedes o no embeber en el Kernel..
MichaelSOG
Si esa gráfica es una campana de Gauss, le falta muchísimo por “engordar” al núcleo, y luego empezará a adelgazar, interesante xD
- LA
  Pero no lo es y no tiene sentido ese tipo de curva en estos casos.
  - MichaelSOG
    Anda pues, hagamosla exponencial entonces.
Pingback: Evolución del tamaño del kernel Linux()
jefer94
creo que los controladores y el nucleo tienen que ser separados, y que ya deje de ser monolitico, que trabaje por modulos para el nucleo, linus igual sacara todo pero distinto, y ademas de nosotros poder compilarlo podremos agregarle modulos, pero bueno, tengo entendido que este crecimiento exponencial ocurrio en 10 años, mucho tiempo, por otra parte, si linux tubo un crecimiento exponencial en 10 años tambien sus distribuciones, pogramas, y windows, no a diferencia de nero que solo es un quemador y pesa demaciado para su uso real
vean
http://nero.softonic.com/info
http://nero-burning-rom.softonic.com/info
http://brasero.softonic.com/linux/info
y de hecho, los pogramas de peso exajerado para lo que realmente es lleva un nombre del que no me acuerdo ahora, y a gnome como tal lo unico que le desprecio es que sus aplicaciones no son multiplataforma, y cuando me pase para linux una de las cosas que me afectaron es que 2 pogramas esenciales mios(idm, format factory) no estaban para linux, el gestor lo ignore, pero el conversor no eh conseguido ninguno que me funcine por ahora, y si en un futuro todos se pasan de linux a otra plataforma podria repetirse lo que me ocurrio
Ootneg
Este engorde hace cada vez más necesaria la existencia de algún sitio web en el que se explique bien y en perfecto castellano cómo optimizar nuestro núcleo. Cada vez hay más controladores que nunca usaremos porque sencillamente no lo tenemos, ningún equipo lleva todo el hardware que se soporta por defecto en los núcleos precompilados con las opciones por defecto. Necesitamos mejor documentación, más comprensible, y tampoco vendría mal una mejora de los configuradores gráficos como menuconfig o xconfig, traducirlos bien y hacer el proceso de configuración mucho más gráfico, con asistentes y mejor documentado, si no Linux acabará siendo tan pesado como Windows.
Por cierto, mi kernel 3.0.6 compilado a mano pesa 46 MB en RAM, y sé que si xconfig estuviese mejor documentado, con información menos críptica, podría afinarlo mucho mejor. No es obligatorio arrastrar un bocharraco pesado y lento, pero los desarrolladores y traductores deberían hacer un esfuerzo por facilitar el proceso de compilación.
Pingback: Linux sobrepasa los 15 millones de líneas de código()
Pingback: El kernel 3.3 sobrepasa los 15 millones de líneas de código()
Pingback: El kernel 3.3: 15 millones de líneas de código » dopther()

Evolución del tamaño del kernel Linux

Lo último

Suscríbete gratis a MuyLinux

Gracias, recibirás un correo para confirmar tu suscripción.