Pérdida de rendimiento

  Dado que, en los SSOO distribuidos actuales, las abstracciones suministradas y los mecanismos empleados en la distribución son de propósito general y puesto que todas las aplicaciones están forzadas a utilizarlos, todas pagan por lo que no necesitan [4, 116, 125]. Basta ver la necesidad de incremento de recursos a medida que salen nuevas versiones del sistema incluso cuando seguimos utilizando el ordenador para hacer lo mismo. La razón hay que buscarla en que con cada nueva habilidad del sistema perjudicamos también a quienes no la utilizan.

La implementación de abstracciones por parte del sistema consume recursos que podrían utilizar las aplicaciones y la consideración de sólo recursos locales por parte del núcleo hace necesaria la realización de trabajo adicional para distribuir el sistema [19, 153, 83].

Basta tomar como ejemplo a cualquier sistema de ficheros distribuido (SFD). Actualmente todas las aplicaciones comparten la misma implementación del SFD. No obstante, no son las mismas las necesidades de distribución (aunque sí los algoritmos empleados actualmente para soportarlas) en los siguientes casos:

• Un sistema de ficheros (SF) que contiene ejecutables del sistema tiene transferencias masivas y pocas modificaciones --salvo por eventuales actualizaciones masivas--, admite como posibilidad el uso de versiones antiguas y no precisa contemplar la pérdida de datos (estos pueden reinstalarse fácilmente). Por otra parte los ficheros viven durante largos intervalos de tiempo.
• En un SF con datos temporales rara vez se comparten datos, sus transferencias suelen ser pequeñas y no admite el uso de datos antiguos. Además, sus ficheros son de poca duración.
• Un SF con directorios conteniendo ficheros de usuarios no admite el uso de versiones antiguas para el dueño de los ficheros (aunque sí para los demás), tiene transferencias pequeñas y precisa de cierta tolerancia a fallos (actualmente suministrada mediante ``back-ups''). Sus ficheros suelen vivir aún más en los mencionados en el primer punto.

La imposición de mecanismos y políticas en la distribución del sistema impiden una solución optimizada para cada caso concreto y suministran una pobre solución ``media''.

El uso de lenguajes de programación distribuidos y de alto nivel empobrece aún mas el rendimiento debido a que sus soportes de tiempo de ejecución reimplementan gran parte de las abstracciones del sistema, duplicando trabajo ya hecho [105, 9, 65, 104, 113, 144].

Por el contrario, en un kernel distribuido adaptable, como el que proponemos, la simplicidad de las abstracciones hace que su implementación sea extremadamente eficiente --este hecho se ha comprobado ya en sistemas centralizados [60]. Como cada aplicación puede adaptarlas o extenderlas de forma óptima en función del uso que haga de las mismas, la eficiencia en los servicios tradicionales o de alto nivel puede aumentar también en gran medida [46]. Por último, la consideración de recursos físicos remotos evita la duplicación de trabajo en la distribución del sistema [12, 11].