Sistemas operativos modernos

Un enfoque alterno (y, en opinión del autor, mejor) sería olvidarse del Plug and Play y te­ ner un icono en la pantalla rotulado “Instalar hardware nuevo”. Después de conectar un disposi­ tivo de hardware nuevo, el usuario haría clic en este icono para iniciar la exploración del bus, en vez de efectuarlo en cada arranque. Por supuesto, los diseñadores de los sistemas actuales esta­ ban muy conscientes de esta opción, pero la rechazaron, en esencia porque supusieron que los usuarios eran demasiado tontos como para hacer esto en forma correcta (aunque ellos lo expresa­ rían de forma más diplomática). Éste es sólo un ejemplo, pero hay muchos más en los que el de­ seo de hacer al sistema “amigable para el usuario” (o “a prueba de idiotas”, dependiendo del punto de vista) hace al sistema cada vez más lento para todo mundo. Tal vez lo más importante que los diseñadores de sistemas pudieran hacer para mejorar el desempeño sería mostrarse mucho más selectivos en cuanto a añadir nuevas funciones y carac­ terísticas. La pregunta obligada no es: “¿Esto gustará a los usuarios?”, sino, “¿Esta caracterís­ tica justifica el precio que inevitablemente se pagará en cuanto a tamaño del código, lentitud, complejidad y confiabilidad?” Sólo deberá incluirse si las ventajas superan en forma clara a las desventajas. Los programadores tienden a suponer que el tamaño del código y el número de errores de programación será cero y que la velocidad será infinita. La experiencia demuestra que esa acfitud es un poco opfimista. Otro factor es el markefing de los productos. Para cuando sale al mercado la versión 4 o 5 de algún producto, lo más seguro es que ya se hayan incluido todas las funciones que en ver­ dad son úfiles, y que todas las personas que necesitan el producto ya lo tengan. A fin de man­ tener las ventas, los fabricantes siguen produciendo nuevas versiones, con más funciones, tan sólo para poder vender modernizaciones a sus clientes actuales. La adición de nuevas funcio­ nes nada más por añadirlas quizá ayude a las ventas, pero casi nunca al desempeño. 12.4.2 ¿Qué debe optimizarse? Por regla general, la primera versión del sistema debe ser lo más directa posible. Las únicas op- fimizaciones deben ser de cosas que es obvio que van a causar problemas, y que por tanto son inevitables. Un ejemplo de esto es tener un caché de bloques para el sistema de archivos. Una vez que el sistema está en operación, deben efectuarse mediciones minuciosas para ver en qué se está inviniendo realmente el fiempo. Con base en estas cifras, deben realizarse opfimizacio- nes en los aspectos en los que serán más úfiles. He aquí una anécdota real de un caso en el que una optimización en vez de ayudar, perju­ dicó. Uno de los estudiantes del autor (cuyo nombre no se mencionará) escribió el programa mirfs de MINIX. Este programa crea un sistema de archivos nuevo en un disco recién forma­ teado. El estudiante pasó cerca seis meses opfimizándolo, lo que incluyó poner caché de dis­ co. Cuando lo entregó, no funcionó y requirió varios meses más de depuración. Este programa por lo regular se ejecuta una vez en el disco duro durante toda la vida de una computadora: cuan­ do se instala el sistema. También se ejecuta cada vez que se formatea un disco flexible. Cada ejecución tarda aproximadamente dos segundos. Incluso si la versión no optimizada hubiera tar­ dado un minuto, dedicar tanto tiempo a opfimizar un programa que se usa con tan poca frecuen­ cia consfituye un desjjerdicio de recursos.