Gunnar Wolf escribe: > - Seguridad: Hay varios exploits que basan su funcionamiento en > incrustarse como m�dulo en el kernel, y pueden ser virtualmente > indetectables. Si tu kernel no sabe cargar m�dulos, lo puedes compilar > como un binario grandote, y te olvidas de este tipo de exploits.
Cuando un n�cleo necesita cierto m�dulo, lo busca en ciertos sitios prefijados y si lo encuentra lo carga. � Como puede cargarse un m�dulo corrupto en mi sistema ? > - Estabilidad: Los m�dulos son archivos independientes en el sistema de > archivos. Es muy poco probable que se corrompan o da�en, pero siempre hay > m�s probabilidad si son varios archivos y no uno s�lo, un kernel En ese caso todos los programas modulares corren ese riesgo, la verdad es que es muy poco probable que esto ocurra. En cuanto a estabilidad prefiero mil veces a Qmail que Sendmail, por ejemplo, el primero se divide en varios subprogramas encargados de realizar tareas muy espec�ficas, el segundo es mas mazacote, pero mas estable seg�n tu razonamiento. La filosof�a de Unix desde un principio fue la de: divide y vencer�s, tenemos un mont�n de programas sencillos encargados de realizar tareas muy espec�ficas, � Es Unix inestable por este motivo ?. A lo mejor Unix est� perdiendo esta filosof�a, pero otros sistemas operativos aun la siguen > grandotote. Un kernel lo cargas una vez, y punto. Y hace sus chequeos - Si > est� corrupto, no va a cargar y punto. No hay funcionamiento err�tico. En > cambio, los m�dulos los cargas y los sueltas muchas veces de manera > autom�tica durante la operaci�n del sistema. Prefiero correr el riesgo de cargar en memoria la m�nima expresi�n del n�cleo y utilizar m�s en el momento que lo necesite, de lo contrario estoy derrochando in�tilmente memoria. > - Rendimiento (aunque marginal): Cargar m�dulos toma tiempo. Si ya los > tienes en el kernel, es m�s r�pido usar su funcionalidad. Y hay veces que > esto es indispensable. � Cuando ? -- [EMAIL PROTECTED] [EMAIL PROTECTED]
