Ayer cuando nos pasamos con Benjamí por Ona Mallorca una persona que trabaja allí me hace la siguiente pregunta:
¿Es verdad que la informática va a pedales entre otras cosas culpa de Linux porque no es microkernel? Eso es lo que me ha dicho una persona que sabe del tema.
Me dejó sorprendido, aunque pensándolo bien no es la primera vez que oigo eso. Y todo parece ser como parte de una estrategia –bastante habitual en la blogocosa– de coger de “oídas” algo que es difícil de comprender y usarlo como argumento para impresionar, parecer “experto” o incluso un friki 
…
el argumento de que si se usase micro kernel en el Linux parece venir derivado del viejo debate Linux es obsoleto de Tanenbaum y Linus Torvalds. También parece estar basado en la creencia popular que Windos NT (y derivados: 2000, XP y Vista) tiene una arquitectura micro kernel –no la tiene en absoluto– o que el Darwin del Mac OS X es un micro kernel puro –no lo es, es híbrido–.
La idea de micro kernel tuvo mucho impulso y fue un hot topic académico en los 80 y principios de los 90. Se podría decir que está englobado dentro de un área más genérica denominada self healing computing, un área de investigación que pretende lograr sistemas totalmente autónomos y que sean capaces de recuperarse automáticamente de los errores de software y hardware.
La idea de un micro kernel no está mal desde el punto de vista de “divide y vencerás” para solucionar los problemas crecientes por el aumento de la complejidad del software de sistemas operativos. Así la idea es reducir al “código crítico” al mínimo posible: un micronúcleo que se encargase de esas tareas críticas como gestión básica de memoria y procesador y gestión de envío de mensajes entre los diferentes módulos –incluso drivers– que se implementarían como procesos de usuarios normales (se llaman “servidores”).
Las principales ventajas que argumentan los promotores de micro núcleos son:
* Reduce la complejidad de los módulos.
* El fallo de un servidor no ocasionaría un problema crítico en el sistema ya que no tiene acceso al hardware y el propio micro núcleo –u otros servidores– serían capaces de re arrancarlo.
* Se facilita la programación y debugging de drivers y otros módulos ya que son procesos normales de usuario.
Desde la comunidad académica siempre se ha afirmado que este tipo de arquitectura tendría sus problemas y que estos no se conocerían en detalle hasta que se desarrollen los primeros sistemas complejos basados en ella.
Los problemas fundamentales de los micro núcleos son:
*El fundamental: problemas de sincronización. En los sistemas monolíticos el núcleo comparte y mapea por igual toda la memoria, lo que facilita enormemente la implementación de técnicas de secciones críticas y sincronización. En un sistema de micro núcleo esto no es posible, por lo que se necesitan técnicas más complejas, sofisticadas y sujetas a errores conceptuales, de complejidad y de implementación.
*Problemas de rendimiento ya que todo acceso al hardware debe hacer fundamentalmente a través de mensajes, lo que significa copia de memoria y la anulación de las ventajas del zero copy que traen todos los sistemas operativos modernos.
*Restricciones del hardware. Los procesadores y arquitecturas modernas de hardware están optimizadas para sistemas de núcleo que pueden mapear toda la memoria. Un ejemplo claro es el TLB (table lookaside buffer).
*Los drivers y el hardware. El 80% de los sistemas operativos son los drivers, y estos suelen ser los módulos de peor calidad. Además el hardware también tienen bugs que ni siquiera pueden ser detectados o corregidos por el software (¿quién no ha tenido que descargar y volver a cargar un módulo de WiFi para que vuelva a funcionar?).
*Integración con las aplicaciones. ¿De qué sirve que el fallo del módulo del sistema de ficheros pueda ser corregido si todas las aplicaciones “mueren” o no son capaces de detectar el fallo y volver a un punto “conocido” –rollback– una vez el sistema corrigió el error?
Todo lo anterior hizo que los sistemas de micro núcleo no pudiesen implementarse en sistemas de uso general y de PCs –son los más complejos–. Existen sistemas de micro núcleo de éxito, como el QNX, pero este es un sistema de tiempo real empotrado que no fue diseñado y desarrollado para un ordenador de escritorio o un servidor web o de base de datos.
El Darwin tampoco es un sistema de micro núcleo puro, es híbrido. Por ejemplo todos los módulos que acceden al hardware –como los drivers– son parte del “micro núcleo” (que no es ya tan “micro”) y mapean toda la memoria. Esto incrementa la posibilidad de que produzcan “fallos genéricos irrecuperables” como en los monolíticos, pero al mismo tiempo facilita el desarrollo de los drivers al disminuir los problemas de sincronización y aumenta la eficiencia notablemente.
Por otro lado Linux –y los Unix– tradicionales nacieron como “núcleos monolíticos”, pero cada vez lo son menos, en primer lugar por la modularización y la carga y descarga dinámica de módulos y últimamente por mover gran parte de las tareas a procesos de usuarios. Por ejemplo el sistema de hotplug y creación dinámica de dispositivos –el udev– e incluso mover muchos drivers a la zona de usuario –user space drivers–.
¿Windows? Bueno, nunca fue micro núcleo, aunque en un principio tenía algo llamado HAL –hardware abstraction layer– que podía interpretarse como una tendencia a una arquitectura micro núcleo, orientada especialmente para ser multiplataforma…. ¿pero alguien se acuerda cuando NT dejó de ser multiplataforma? o mejor dicho ¿alguien se acuerda que alguna vez lo fue?
Afirmar que el no usar microkernels ha frenado el avance de la informática hogareña es como mínimo tan arriesgado como:
La domótica estaría mucho más extendida si se usase 12 V como en los coches en vez de los 220 V de ahora.
Así que cuando os vuelvan a decir frases tan contundentes trufadas con términos técnicos que casi nadie conoce en profundidad –como “va a pedales porque no es micro kernel” o “el telnet es más seguro que el ssh”– ponedlas en duda. Hasta que no estéis seguro que tiene un mínimo de racionalidad no las vayáis repitiendo por allí ante desconocidos.
Podría pasar que cuele, pero también que algún día te encuentres con desconocidos que sepan del tema y os sorprenda con un rotundo:
Vaya gilipolleces que dices.
y luego no podáis escuchar las explicaciones por el ruido de las risas. Para evitar estas situaciones embarazosas es mejor ponerlo en un blog y a ver si alguien te lo explica.
