El mito del microkernel
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 
Desvariando un poco. Me hace recordar a algo que me contaron hace muy pocos días. Le preguntan a un responsable técnico del servicio informático de una organización mediana por qué no usaba GNU/Linux en los servidores de correo en vez de los sistemas tan caros y obsoletos actuales. La respuesta fue alucinante:
[GNU/]Linux no soporta los discos hot-swappables.
No sé si ese técnico estaba realmente convencido lo que decía –lo que demuestra que sufre una enorme disfunción metacognitiva– o lo hace a posta para engañar a los directivos no expertos –menos mal que todavía funciona el escepticismo en muchos “directivos”–.
En realidad hay otra bastante más alucinante. En la UIB preguntan a uno de los responsables porqué se sigue usando telnet para acceder al servidor central –incluso vía Internet– y no el ssh. La respuesta fue:
El telnet es mucho más seguro, el ssh tuvo problemas de vulnerabilidades y el telnet del VMS no.
Alucinante.
Pero a lo que iba, 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
“Dos más dos es una estrella próxima a Alpha Centauri”. Contra argumentos de tal calibre es imposible discutir.
En fin, la primera afirmación (microkernels) la hace un fanboy, por lo que le podemos acusar de ignorancia.
Pero las otras dos (hot-swap, telnet) son de supuestos “profesionales”, que están engañando deliberadamente, y habría que colgarlos de los pulgares por ser tan mentirosos. ¿El Colegio de Ingenieros Informáticos Superiores Supremos también nos protegerá de estos abusos?
Comment by DZPM — Saturday 26/5/2007 @ 15:17
Muy buen artículo. Una minucia, s/empotardo/unpetardo/ :p
Comment by Tribe — Saturday 26/5/2007 @ 16:40
La pregunta fue del Juli Valls, técnico de sonido en Ona Mallorca
Comment by Benjamí — Saturday 26/5/2007 @ 17:24
Muy interesante. No se porqué hace poco estuve leyendo de este tema. De hecho me he bajado Minix para ver que tal funcionaba, porque si lees la Wikipedia dice precisamente que el problema principal de los microkernels es el rendimiento.
Por lo que pude leer lo que Linus decía era que, entre otras cosas, con un kernel monolítico el desarrollo era mucho más simple. Curioso.
Por otro lado me pregunto si esto nos afecta en algo a nosotros, los usuarios finales. Creo que no. Es como presumir entender el funcionamiento del sistema electrónico de tu coche. Saber un poco de mecánica viene bien, pero hoy en día hay lugares del coche que como no vayas a un taller, nada puedes hacer.
Todo lo relacionado con los ordenadores se ha vuelto tan complejo que para un usuario no informático es un gran misterio. Y presumir de saber sobre algo tan poco conocido es tentador para muchos. Lástima que la mayoría de la gente es tan cómoda que ni siquiera se molesta en buscar información en internet…
Y siempre es agradable leer algo sobre como funcionan por detrás un SO que venga de alguien que realmente sabe de lo que habla.
Comment by Demian — Saturday 26/5/2007 @ 20:25
hombre, por acordarse, yo me acuerdo que NT 3.51 corría en Alpha. Nunca ví ninguno en funcionamiento, pero en teoría existían. ¿No?.
Por lo demás, hay veces que es mucho más fácil decir que es culpa de la junta de la trócola o del condesador de fluzo, que intentar explicar detenidamente una cuestión altamente técnica a alguien que por formación va a ser incapaz de entenderla.
Comment by uno que pasaba — Saturday 26/5/2007 @ 20:42
Que artículo más bueno. Gracias.
Comment by DN — Saturday 26/5/2007 @ 20:50
#5 Si, yo lo vi (y medio sufrí) en un Alpha (era algo peculiar) Además creo que soportó ¿RISC? y actualmente soporta 3 arquitecturas… x86, x64 e Itanium… que a muchos no les vale como distintas arquitecturas… pero al departamento comercial de microsoft creo que si.
En teoría Windows también soporta muchos otros procesadores para PDAs, móviles… etc. etc. pero el núcleo del windows mobile creo que no tiene nada que ver con el windows de la serie NT.
Comparado con otros sistemas operativos casi no soporta nada… pero si lo comparamos con MaxOs… la verdad es que soporta bastantes mas
Comment by DN — Saturday 26/5/2007 @ 20:56
Joyas como éstas hace que te tenga en Bloglines.
Gracias!
Comment by Angelillo — Saturday 26/5/2007 @ 21:52
Hombre, esta bien que haya que desmentir a esa gente que nomas dice cosas porque las escucho por ahi y en realidad no entiende de lo que habla, pero parece que estas argumentando que los microkernels son una utopia o que no se han utilizado comercialmente.
Realmente los microkernels tienen un diseño excelente y ahora que tenemos pc’s bastante mas potentes el rendimiento no sera problema.
Me recuerda aquella vez que le preguntaron a Andy Tanenbaum “¿Porque si el diseño del microkernel es superior, no se utiliza mas?” y respondio “¿Porque Linux se utiliza menos que Windows?”
En fin, el tiempo lo dirá, veremos como se desarrolla Minix3 que es el primer intento decente de llevarlo a escritorio.
Comment by pablasso — Saturday 26/5/2007 @ 22:53
> Realmente los microkernels tienen un diseño excelente y ahora que tenemos pc’s bastante mas potentes el rendimiento no sera problema.
Eso depende de cómo se diseñe cada uno de los sistemas con microkernel. El Minix3 todavía es muy simple y es incomparable con un Linux, aún así su rendimiento en temas POSIX es bastante peor.
Comment by gallir — Saturday 26/5/2007 @ 23:21
Yo añadiría que los microkernels son tambien producto de una obsesión con los kernel. Quiero decir que está muy bien eso de que cada módulo esté aislado y a salvo….el problema es que los microkernelitas son incapaces de asumir que es perfectamente posible asumir que el kernel es UN solo módulo, dbus otro, X.org otro, openoffice otro…..
Es increible su obsesión con los kernels, que han demostrado ser capaces de adaptarse con el tiempo y que son estables y bastante resistentes…y no hacen NADA por aplicar sus ideas al software de espacio de usuario, que es el lugar de donde más fallos y cuelgues se producen. Si coges cualquier aplicación de KDE o GNOME y le ejecutas el ldd…esa aplicación está integrando un montón de código y librerias en un mismo espacio de direcciones…y un solo puntero inválido en cualquier parte de ese código hará que el proceso entero se caiga. ¿Por que no aplican sus tecnicas ahi?
De los problemas que mencionas me quedo con el último: ¿De qué sirve que todo esté isolado, si cuando muera el proceso encargado de hacer TCP/IP tus conexiones se van a ir a la mierda aunque rearranques el proceso? ¿De que sirve tener el sistema de archivos en un proceso separado, si cuando muera perderás igualmente los datos de los bufferes, el estado de los descriptores de archivo de cada proceso, y no serás capaz de rearrancar el proceso porque el proceso que necesitas rearrancar está ubicado precisamente en el disco que no puedes acceder?
Con respecto a Darwin y NT (que tambien es un microkernel híbrido, derivado de Mach, según dicen)….al eliminar la isolación de los espacios de direcciones de cada proceso, poner todo en el mismo y comunicar cada módulo mediante simples llamadas a funciones….estan eliminando precisamente la principal razón que tenían para ser un microkernel y transformándolo efectivamente en un kernel monolítico. La pregunta es: Si al final vas a construir un kernel monolítico, ¿por qué partir de un microkernel y tener que cargar con el trabajo de cambiarlo? La única razón para hacerlo sería la modularidad forzada que implica el microkernel en el diseño y en el código, pero los kernels monolíticos han demostrado que esa modularidad tambien es aplicable no solo a los kernels monolíticos, sino a cualquier proyecto de software. La modularidad no es exclusiva de nadie.
Y por otra parte ¿que impide que un diseñador de un microkernel cree una mala interfaz para un determinado proceso que fuerze a los procesos que necesitan de sus servicios a ser modificados y remcopilados para adaptarse a un cambio de la interfaz que has sido necesaria para resolver, por ejemplo, un fallo de seguridad de diseño? Absolutamente nada.
Comment by Diego — Saturday 26/5/2007 @ 23:30
#10, #9 No es que no tenga fe en el desarrollo de Minix….pero no estaría mal recordar que Minix (al igual que Hurd, que era libre y cualquiera podía mejorarlo) existía antes que Linux. Vamos, que cuando se oye decir “Minix aun es muy simple/poco usado/tiene poca atencion/etc”…si hay algo que no le ha faltado a los microkernels son oportunidades, tiempo, proyectos iniciados, financiación (QNX)…
Comment by Diego — Saturday 26/5/2007 @ 23:39
El mite del micronucli (castellà)…
Perquè actualment s’usen sistemes operatius amb nuclis monolítics? En Ricado Gallir intenta explicar els problemes dels micronuclis….
Trackback by latafanera.net — Sunday 27/5/2007 @ 1:17
Bueno. El tema del paso de mensajes parece tan evidente… ¿Cómo puede ser que desde el plano teórico se creyera tan profundamente que el microkernel iba a revolcionar los S.O.? La respuesta pasa indudablemente por el hecho de que nadie preveía que existiría un desarrollo libre con múltiples colaboraciones.
¿Qué más da el microkernel si el software es libre? A mí me parece una de tantas teorías sobre software vistas desde el prisma del software privativo que debe proveer de un mecanismo a terceros para poder desarrollar soft que enriquezca el producto inicial.
Es como preguntarse a día de hoy porqué Java es interpretado. La respuesta es la misma.
Lo único que no cuadra en esta teoría es que se haya invertido tanto esfuerzo en Hurd - libre - completamente orientado a microkernel… ¿Se hizo más con el corazón que con la cabeza? ¿Veremos un microkernel libre, un GNU/Hurd al mismo nivel que un GNU/Linux algún día?
Al menos, divertido, sí que será.
Comment by Paco Ros — Sunday 27/5/2007 @ 1:59
> Lo único que no cuadra en esta teoría es que se haya invertido tanto esfuerzo en Hurd - libre - completamente orientado a microkernel… ¿Se hizo más con el corazón que con la cabeza? ¿Veremos un microkernel libre, un GNU/Hurd al mismo nivel que un GNU/Linux algún día?
Eso lo reconoce Stallman en sus charlas, que en su momento parecía lo más adecuado para hacerlo rápido, pero que no ha sido así.
En Palma le preguntaron por qué se ponía más esfuerzo en adelantar el Hurd y así tener un sistema GNU “puro” completo y lo que dijo creo que deja claro que es ya casi una discusión sin sentido (Stallman seguramente es un de los mejores expertos mundial en estos temas):
“Ya tenemos un núcleo libre, no tiene sentido duplicar esfuerzos cuando hay otras prioridades porque estamos por detrás, por ejemplo el reconocimiento de voz”.
Comment by gallir — Sunday 27/5/2007 @ 2:08
Para el paso de mensajes no es estrictamente necesario hacer copia de datos. En teoría, si se implementa un sistema de mensajes de tamaño fijo (o limitado a un máximo razonable), sería posible que el sistema operativo pudiera evitar la copia del contenido del mensaje de un proceso a otro mapeando en el proceso destino la (o las) páginas correspondientes al mensaje en el proceso origen usando CoW (Copy On Write).
Comment by Felipe Alfaro Solana — Sunday 27/5/2007 @ 2:34
No olvidemos que en la versión 3.5 y 3.51 de Windows NT el controlador de la tarjeta gráfica se ejecutaba de forma separada del núcleo. Sin embargo, en la versión 4.0 de Windows NT, los controladores de vídeo se modificaron para integrase con el núcleo alegando “problemas de rendimiento”.
Curioso, sobre todo el hecho de que en las versiones más recientes de Windows es posible “desacelerar” o eliminar el soporte de aceleración para incrementar la “estabilidad” del sistema.
Comment by Felipe Alfaro Solana — Sunday 27/5/2007 @ 3:02
#10, como dices Minix3 no esta suficientemente desarrollado, son incomparables en este momento y lo seran asi por un buen tiempo
#12, minix tuvo licencia restrictiva bastante tiempo, nunca fue desarrollado mas, porque solo era una herramienta educativa que creo el mismo Tanenbaum, para ese proposito era absurdo crecerle en complejidad, apenas con Minix3 se esta comenzando a desarrollarlo con fines practicos
Comment by pablasso — Sunday 27/5/2007 @ 14:37
Yo cuando propuse lo de telnet / rlogin / rsh sobre SSL, o mejor todavía, SSH directamente, se me rieron en toda la cara. Hará como 7 u 8 años de eso. Veo que siguen tan mal como siempre. Muy triste…
Comment by guillem — Sunday 27/5/2007 @ 17:29
[tec] El mito del microkernel…
Interesante artículo de Ricardo acerca de la idea de los sistemas operativos microkernel y sus mitos y leyendas….
Trackback by meneame.net — Monday 28/5/2007 @ 10:13
Sólamente un apunte: TLB -> Translation Lookaside Buffer
Comment by Mike — Monday 28/5/2007 @ 11:54
Sólo una puntualización, el primer Windows NT que salío al mercado sí era multiplataforma, había una versión para los Alpha, que se desarrolló en paralelo a la x86 para garantizar que el SO no fuera dependiente del procesador, como prueba de esto, se puede ver cómo en el API Win32 desaparecieron las funciones de Win16 que hacía referencia a estructuras exclusivas de los Intel.
Saludos
Comment by Migue — Monday 28/5/2007 @ 16:50
Posicionarse a favor o en contra de los micronúcleos es algo muy arriesgado. Si bien es cierto que ya ha pasado la “época dorada” de esta tecnología, también lo es el hecho de que se ha avanzado mucho desde entonces, y se sigue avanzando ahora. El trabajo de los distintos “sabores” de la especificación original de L4 (http://os.inf.tu-dresden.de/L4/), el del equipo de KeyKOS/Coyotos (http://www.coyotos.org) y, en menor medida, el de Minix3 (http://minix3.org) son buena muestra de ello.
De hecho, se ha demostrado que la principal causa de la lentitud no es el sistemas paso de mensajes (el cual, convenientemente optimizado, no resulta mucho más pesado que la comunicación con las tradicionales llamadas al sistema), sino los frecuentes cambios de contexto, que en determinadas arquitecturas reducen el rendimiento de la caché del procesador. Para solventar este problema se está trabajando en técnicas como Hilos Migratorios (Migrating Threads), la reducción del working set del núcleo (acercándose al nanonúcleo), o el uso especializado del TLB Etiquetado (Tagged TLB) de los nuevos procesadores.
Respecto al tema de la integración con las aplicaciones, todo depende de la implementación. De hecho, a los más aventureros les recomiendo que hagan el siguiente experimento con Minix3 (sí, puede hacerse en una máquina virtual ;-): pongan a copiar un archivo grande (o múltiples archivos pequeños) y mientras la copia esté en curso, “maten” el proceso del controlador de su disco duro. Verán como tras unos instantes de parada, la copia continúa como si nada. ¡Incluso es posible añadir o quitar unidades de disco duro o CD en caliente realizando este mismo procedimiento!
En definitiva, que a los micronúcleos aún les queda mucho camino por andar, y más vale no desestimar ninguna tecnología, no vaya a ser que en unos años nos llevemos una sorpresa
P.D: El núcleo de NT fue concebido como micronúcleo, aunque esta característica se fue perdiendo con el paso de las versiones.
Comment by Sergio Lopez — Monday 28/5/2007 @ 17:00
[…] http://mnm.uib.es/gallir/posts/2007/05/26/1093/ 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. […]
Pingback by Blog de Alejo » Blog Archive » El mito del Microkernel — Tuesday 29/5/2007 @ 4:51
Si ssh tiene una vulnerabilidad conocida ampliamente y explotable de forma remota “que no se puede evitar” y el acceso por telnet no se hace desde “cualquier cibercafé” y confías en las máquinas de la ruta, probablemente no sea ninguna tontería usar telnet en lugar de ssh aunque envíes todos los datos en claro para acceder a esa máquina. Sería algo similar al acceso a us servidor web con “WWW-Authenticate: Basic” vs un acceso cifrado comprometido públicamente.
Comment by haxor3lt3_chupiguay — Tuesday 29/5/2007 @ 5:02
Sobre el telnet… en realidad es cierto que históricamente ha tenido muchísimos menos problemas de seguridad. Y es cierto también que manda los datos sin cifrar. Pero… sinceramente, cuántos casos conocen de máquinas que han sido comprometidas debido a un empleado de un proveedor de internet que haya esnifeado una clave? Y a cambio, cuántos casos conocen de equipos que hayan sido comprometidos debidos a fallas de seguridad en el software?
Actualmente hace ya tiempo que no aparecen problemas importantes en ssh, así que podemos considerarlo suficnetemente seguro. Pero si vamos a poner sobre la balanza posibilidad de que alguien esnifee una clave entre millones de paquetes que pasan por segundo y la posibilidad de que aparezca un agujero de seguridad por un estúpido buffer overflow, creo que no queda duda de que la segunda es mucho más frecuente y a la que más atención debermos poner.
Motivos a favor de usar ssh en lugar de telnet? Aparte del cifrado, que obviamente no está de más, está el hecho de que es más avanzado, permite redirección de puertos, transferencia de archivos, etc.
Comment by anv — Tuesday 29/5/2007 @ 9:07
El mayor problema “práctico” los micronúcleos es que los procesadores actuales están demasiados orientados hacia los núcleos monolíticos y se producen una gran cantidad de fallos de caché y de TLB. La llegada inminente de las TLBs etiquetadas puede que resuelva este problema.
El problema de los driver ya no lo es. Para comprobarlo basta con ver los últimos trabajos sobre velocidad y rendimiento de los controladores en, por ejemplo, Mungi. Con la ayuda inestimable de las IOMMU (unidades de gestión de memoria de entrada/salida) que también empiezan a incorporar los procesadores.
Si os fijais los procesadore actuales tienden a disponer de un número cada vez mayor de núcleos y esto también marcará una diferencia entre lo que pueden conseguir los micronúcleos y los núcleos monolíticos.
Con estas 3 mejoras de los procesadores “modernos” la diferencia de rendimiento entre micronúcleos y núcleos monolíticos tenderán a desaparecer con lo que la ventaja en cuanto a seguridad que aportan, y esto nadie lo discute, empezará a cobrar importancia.
La tendencia actual de linux es precisamente parecer cada vez un poco más basado en paso de mensajes. Esto es apreciable en el mayor número de controladores en espacio de usuario que aparecen cada día. También teniendo en cuenta que el sistema X en realidad se basa en un sistema de paso de mensajes.
puffffff… vaya rollo que acabo de soltaros
Comment by DrLecter — Tuesday 29/5/2007 @ 10:44
¿Alguien sabe si el kernel de BeOS era microkernel? funcionaba de lujo y por cierto, respecto al comentario nº23 se podía copiar un archivo del punto A al B y antes de terminar la copia transladarloo del B al C sin que hubiera problemas de copia (era una iso de linux de 650 megas e instaló perfectamente despues de grabarla desde el punto C)
Comment by Webadicto — Tuesday 29/5/2007 @ 11:25
“¿Alguien sabe si el kernel de BeOS era microkernel?”
En la wikipedia version inglesa aparece como hibrido, y en la version española como microkernel. Probablemente añadieron alguna cosilla extra al kernel, de manera que no es microkernel puro.
Comment by DD — Tuesday 29/5/2007 @ 11:46
#5 y 7.
Si, yo tambien he usado NT 3.51 en Alpha (que es risc) y un compañero del curro lo uso en un IBM powerpc 604 (tambien risc). En los CDs originales de NT tambien viene la version para MIPS( Si quereis probar… http://gavare.se/gxemul/gxemul-stable/doc/guestoses.html#windows_nt_mips). Tambien se planificaron versiones para PA-RISC y para SPARC que no llegaron a salir
Comment by PacoLinux — Tuesday 29/5/2007 @ 12:05
>Hombre, esta bien que haya que desmentir a esa gente que nomas dice cosas porque las escucho por ahi y en realidad no entiende de lo que
>habla, pero parece que estas argumentando que los microkernels son una utopia o que no se han utilizado comercialmente.
Totalmente de acuerdo.
Comparar el argumento de que la informática va mal por culpa de la no implantación de los microkernels, con el tema de telnet vs. ssh me parece una exageración. Del tema telnet vs. ssh no hay ninguna duda de qué es lo cierto, pero en el tema microkernels no está tan claro, es un asunto muy discutible (sólo basta con mirar la extensión de tu artículo), e incluso el propio Tanenbaum opina lo contrario que tú. [Por cierto, ahora resulta que el tema telnet vs. ssh también es discutible
]
Aquí sólo hay una discusión: estabilidad vs. rendimiento. En la programación de hoy día está ganando lo primero a pesar de lo segundo (C++ vs. C#/Java). Algún día ocurrirá lo mismo con los sistemas operativos.
Alguien argumenta por ahí que para qué sirve eso: pues como diría el de “lo bueno si breve, dos veces bueno”, para evitar kernel panics. No tiene sentido que un driver de una tarjeta wifi casque el kernel al completo.
>Si coges cualquier aplicación de KDE o GNOME y le ejecutas el ldd…esa aplicación está integrando un montón de código y librerias en un mismo >espacio de direcciones…y un solo puntero inválido en cualquier parte de ese código hará que el proceso entero se caiga. ¿Por que no aplican >sus tecnicas ahi?
Ya las aplican, por ejemplo, a la hora de inventar lenguajes con administración automática de la memoria y gestión de excepciones, como C# y Java. Lo que pasa es que Gnome sigue usando C y KDE C++.
>Es como preguntarse a día de hoy porqué Java es interpretado.
¿Java interpretado? ¿No querrás decir el bytecode de Java (el cual es autogenerado por un compilador, por lo que no es error-prone)? Como mucho te podría aceptar que es “semi-interpretado”, porque tiene que compilar código intermedio a código nativo en el comienzo, pero no compilar código de usuario a código nativo como otros (Perl, PHP, etc.).
Comment by knocte — Tuesday 29/5/2007 @ 12:23
Una última cosa a cuento de:
>Por lo que pude leer lo que Linus decía era que, entre otras cosas, con un kernel monolítico el desarrollo era mucho más simple.
Este argumento es el mismo argumento que tienen los detractores de los lenguajes estáticamente tipados (C#, Java, C++…) en pro de los dinámicamente tipados (aka débilmente tipados, sin semántica de tipos), pero a la larga, ¿qué es mejor? ¿descubrir un bug en tiempo de compilación o en tiempo de ejecución?
Lo que quiero decir es que a veces la seguridad de un sistema (estabilidad) es más importante que la productividad que los desarrolladores tengan para implementarlo.
Comment by knocte — Tuesday 29/5/2007 @ 12:43
[…] Un interesante artículo de Ricardo Galli […]
Pingback by deveraux.dyndns.org » Blog Archive » El mito del microkernel — Tuesday 29/5/2007 @ 13:17
Comentando algo que se ha dicho en el comentario 19.
Si quieres rearrancar un proceso muerto como consecuencia de la muerte del proceso que controla es sistema de ficheros te informo que un proceso no puede estar en un disco duro. En el disco duro se almacenan programas y se almacenas archivos de datos.
Un proceso es una imagen en memoria de un programa que se está ejecutando o listo para ejecutarse (o colgado).
Comment by dardo — Tuesday 29/5/2007 @ 13:21
>#34
Ejem… /proc/ … ejem…
Comment by anonymono — Tuesday 29/5/2007 @ 15:06
#34: […] que un proceso no puede estar en un disco duro […]
Bueeeno, siempre que no este en memoria de intercambio ¿no? ;P
Comment by opsi — Tuesday 29/5/2007 @ 17:12
Perdon por el bold, solo era para la primera linea, pero olvide cerrarlo
Comment by opsi — Tuesday 29/5/2007 @ 17:14
Ni kernel monolitico ni microkernel, se trata de simplificar y no de agregar caracteristicas que a la larga complican. Vean como un SO de 64KB es utilizado para hacer un CAD de diseño de circuitos en www.colorforth.con.
Comment by Pablo Reda — Tuesday 29/5/2007 @ 20:18
[…] » notícia original […]
Pingback by alturgellLog » Blog Archive » El mite del micronucli (castellà) — Friday 1/6/2007 @ 13:47
En la wikipedia version inglesa aparece como hibrido, y en la version española como microkernel. Probablemente añadieron alguna cosilla extra al kernel, de manera que no es microkernel puro.
Comment by Natola — Tuesday 12/6/2007 @ 21:46
Yo si me acuerdo del NT multiplataforma (PPC, MIPS y DEC Alpha ¿qué fue de de Digital?), lo usé en un PowerPC y recuerdo un artículo muy sesudo de por qué andaba tan mal en los potentes Compaq-Digital con esos procesadores Alpha y esa RAM del copón… Pero bueno, al final esa batalla la ganó Wintel.
Comment by manuti — Thursday 14/6/2007 @ 11:17
[…] mito del microkernel Dejo un enlace a un artículo de Ricardo Galli con este mismo título, lo tenia en lista de espera y me ha parecido super […]
Pingback by El mito del microkernel « M & M — Saturday 4/8/2007 @ 20:42
Ni uno ni otro.
Esto es como la tipica pelea entre Linux y Windows.
A nivel diseño, los microkernells son muhco más seguros y estables, de esto no hay dudas, pero eso tiene su precio en rendimiento.
Las probabilidades de cometer un error en un kernell de 4.000 lineas no son comparables con las mismas probabiidades en uno de 4.000.000 que en realidad son retazos de distintos fabricantes.
De todos modos, decidir por uno u el otro tiene que ver con analizar el caso en particular.
Todo sistema monolítico corre el riesgo de dejar a cualquier usuario (root) ejecutar lo que se le cante, y a cualquier fabricante hacer lo que quiera en la pc con su device driver, incluzo destrozar un File System. Esto nunca ocurrirá en un sistema de microkernell.
Creo que la peléa la ganarán los hibridos. No me gustaría que mi sistema invierta el 50% del tiempo en mandar mensajes, pero tampoco que cualquier device driver pueda hacer lo que quiera con el pc.
Antes de irme, quiero acotar que si de fanatismos hablamos, no existen personas más fanáticas que los Linuxeros, quienes encuentran todas las opciones no adoptadas por Linux como una porquería, muy diferente al pensamiento de Tovald, quien se abrio a nuevas ideas al momento de desarrollar su kernell.
Creo que Minix hoy en día no llego a ser lo que Linux es por una simple razón: Tanenbaum, quien se negó rotundamente a meterle interfaces y aplicaciones, con una simple justificación, su sistema operativo era para estudiarlo, no para sacarle el jugo.
Sinceramente agradezco esta desición, gracias a eso, todas las universidades del mundo tienen a su disposición un sistema operativo de pocas lineas, bien diseñado y estructurado para poder explicar a los alumnos metiendo la mano en la gasa lo que es un SO.
Saludos!!
Comment by Carlos — Friday 17/8/2007 @ 18:14
En mis 4 intentos por compilar el kernel de linux, siempre he tenido problemas, en otras palabras: Kernel panic.
no soy titulado (todavía), pero con todo lo que aprendí en mis investigaciones, un microkernel tiene menos
inconvenientes (mejor si es un kernel híbrido, que es un microkernel con código adicional); una prueba de ello:
Window$ (y me duele mencionarlo). ¿O puedes instalar un controlador para un dispositivo en un par de clic’s, en linux?
y en cuanto a rendimiento, se puede compensar reduciendo la latencia en cada interrupción del hardware…
y comparto el comentario de Carlos y con aquellos que prefieren un sistema microkernel…
…¿por qué linux no puede ser microkernel o híbrido? no recuerdo la fuente, pero dicen por “pereza”…
y creo que tienen mucha razón…
saludos.-
wenupix®
Comment by wenupix® — Friday 24/8/2007 @ 22:51