El Cedazo

En el último capítulo de esta serie vimos las diferencias entre los ordenadores reales y los sistemas supersimplificados que hemos contado aquí para aprender, y vimos que muchas de esas diferencias solo se entendían como apoyo en su relación con el sistema operativo.

Pero, ¿qué es el sistema operativo? En el último capítulo esperábamos que tuvieras una idea más o menos intuitiva de lo que era un sistema operativo simplemente viendo los ejemplos de nuestra vida cotidiana: Windows, en todas su variantes, es un sistema operativo. Linux también lo es. Mac OS. Android, iOS,… en fin, esos son los ejemplos que a todos nos vienen a la mente rápidamente. En sistemas más grandes tenemos UNIX en todas sus variantes, así como los sistemas operativos de los mainframes de IBM y similares: z/OS (el antiguo MVS), DOS/VSE…

Así que ya tenemos claro lo que es un sistema operativo… ¿o no?

Pues no, no tanto. Y es que la discusión no es baladí, incluso con implicaciones legales y denuncias por abuso de monopolio de por medio.

Existen muchas definiciones sobre lo que es el sistema operativo, casi tantas como libros que existen sobre el tema, pero nosotros vamos a intentar una más: el sistema operativo es la parte del software que se encarga de gestionar los recursos del ordenador a petición de las aplicaciones.

Supongo que te has quedado como estabas. O peor aún, porque antes lo tenías más o menos claro, y ahora quizá ya no tanto.

Así que vamos a intentar una aproximación histórica, a ver si poco a poco vamos centrando la definición. Para ello vamos a ver cómo eran y cómo se usaban los ordenadores inicialmente, y cómo el sistema operativo surgió casi por necesidad, más que por diseño.

Empezamos la batallita a mediados del siglo XX, justo después de que von Neumann diseñara su arquitectura. El que quería usar el ordenador se escribía su programa, iba allí, lo ejecutaba y listo. Al fin y al cabo, solamente unos pocos privilegiados tenían acceso a dicha máquina,^[1] y menos aún sabían cómo hacer programas para ella, así que todo lo más había una pizarra donde se apuntaban para decir “eh, de 8 a 12 necesito usar el ordenador para calcular unos logaritmos” (salvo que lo necesitara el jefe entre medias, me imagino).

Supongo que rápidamente aparecerían las primeras bibliotecas de programas. No solo para operaciones matemáticas, sino también (y esta es la parte que nos interesa) para acceder a los dispositivos de entrada-salida: leer del teclado, escribir en la impresora (porque no, no había pantallas todavía), leer y escribir en las cintas magnéticas…  Si recuerdas cómo se escribía en nuestra rudimentaria pantalla, ¿imaginas lo complicado que debe ser escribir en una cinta magnética o en un teletipo? Una vez que has escrito la biblioteca de programas que lo hace, y encima funciona, no quieres volver a escribirla nunca más; ni siquiera a tus enemigos se lo deseas. Así que supongo que los afortunados que vivieron aquello probablemente compartirían esas bibliotecas: alguien creaba la biblioteca, la hacía sencilla de usar (dejando en el interior toda la complejidad de manejar los dispositivos de entrada-salida) y la dejaba a disposición de los demás.^[2] Es decir estas bibliotecas nacieron como una forma de abstraer el uso del hardware. Fíjate en que hasta aquí no “gestiona” dicho hardware, solo simplifica su uso.

También en esta época se empezaron a usar en los ordenadores las tarjetas perforadas,^[3] de modo que el científico-programador almacenaba cómodamente las tarjetas una vez perforadas en su despacho, y así cuando fuera a usar el ordenador perdería poco tiempo cargando el programa. ¡Hemos avanzado una barbaridad! Empezamos los años 50.

Tarjetas perforadas (Marcin Wichary, cc-by-2.0, http://www.fotopedia.com/items/flickr-2210753092)

Pero, con el tiempo, cada vez más gente quería usar el ordenador, y cuando llegaban a usarlo no siempre estaba libre, así que tenían que esperar. De modo que entrenaron a un señor cuya misión era cargar el siguiente programa que estaba en la lista de espera en cuanto el que estaba ejecutándose hubiera terminado, y recoger la salida que hubiera generado para llevársela a quien había encargado el trabajo (job es como se llamaban esa tareas, trabajo, en inglés). Así que los científicos que querían usar el ordenador escribían su programa (o mejor dicho, lo perforaban en las tarjetas perforadas) y se lo daban al operario para que lo cargara, a la espera de que hubiera hueco libre para ejecutarlo. Por cierto que en esta época es cuando se inventaron los lenguajes de programación y los compiladores (FORTRAN, inicialmente). Estamos a finales de los 50. Pero, claro, rápidamente se pensó que se podía prescindir de ese ser humano cargador (loader, en inglés), y que los programas podían quedarse en el propio sistema, listos para ser ejecutados, pero a la espera de que terminara el que estuviera antes que ellos en la cola. Como la cola de una frutería, vamos. A esto se le llamó sistemas batch (batch es “lote” en inglés).

¿Y quién iba a encargarse de ir dando entrada a los programas según quedara hueco libre? Hubo que escribir algún “programa” un poco especial, que estuviera siempre cargado en la máquina, y que fuera ejecutándose cuando un programa “de usuario” terminase, pasando a ejecutar al siguiente en la cola. Había nacido el sistema operativo.

Pero también rápidamente se dieron cuenta de que ocurría un efecto curioso: cuando el programa tenía que hacer operaciones puramente de cálculo, estaba ahí, a todo trapo, ejecutando instrucciones sin parar. Pero cuando necesitaba interactuar con los dispositivos de entrada-salida (leer o escribir algún dato) se quedaba parado por largos periodos de tiempo mientras el dispositivo de entrada-salida hacía lo que le habían pedido hacer. No estamos refiriéndonos a nuestro ejemplo del teclado, en el que esperamos a que el usuario pulse una tecla. Ni que decir tiene que estos primeros programas no eran en absoluto interactivos, así que ni se pensaba en que el usuario pulsara alguna tecla mientras se ejecutaba el programa. A lo que me refiero es a la comunicación con otras máquinas. Piensa por ejemplo en una impresora a la que le das orden de hacer un salto de línea: la impresora tiene que encender un motor, girarlo unos cuantos grados (para mover el cilindro que arrastra el papel hasta la siguiente línea), luego moverlo hacia la derecha para que se posicione en la primera columna… ¿cuánto tarda en hacer eso? Que tarde del orden de un segundo, o incluso más, dependiendo del tipo de periférico que sea, no es descabellado.

Hasta para aquellos primitivos ordenadores, eso era muchísimo tiempo. Para que te hagas una idea, el IBM 360 original (de 1964) ejecutaba 34000 instrucciones por segundo; un ordenador de sobremesa puntero actual sobrepasa ampliamente los 10.000.000.000 de instrucciones por segundo, así que imagina lo que le da tiempo a hacer en 1ms… una barbaridad.

Inauguración del primer IBM 360 instalado en Francia, en 1967 (Nicolas Roussel, cc-by-3.0, http://www.fotopedia.com/items/d66945df-37cc-4ce2-aa76-eb2ce9809ae7)

En paralelo se dio otro efecto, esta vez de negocio: los ordenadores ya no eran un juguete de los científicos, que hacían millones de operaciones matemáticas para calcular el trigésimo decimal de PI, sino equipos que usaban las grandes agencias gubernamentales, los grandes bancos, las grandes universidades… para su negocio. Por un lado, esa gente hacía muchas más operaciones de entrada-salida que los científicos, ya que sus ordenadores se solían usar para procesar grandes volúmenes de datos (que a menudo estaban en cintas magnéticas) en lugar de para realizar muchos cálculos matemáticos. Y, por otro, ya había que empezar a tener en cuenta el presupuesto… y el precio de ese ordenador tenía tantos ceros y había tanta gente a la cola esperando para usarlo que el coste de esas pausas, desperdiciadas simplemente esperando a que se rebobinara la cinta, empezaba a no ser despreciable.

Así que se les ocurrió lo siguiente: si tenemos programas en la cola, esperando para ser ejecutados, ¿por qué no vamos empezando con ellos en las pausas del programa que se está ejecutando? Con esto (principios de los setenta) nacieron los sistemas multiprogramados: más de un trabajo podía estar “medioejecutándose” a la vez. Obviamente, ejecutándose-ejecutándose de verdad, solo había uno, pero en cuando ese se quedaba esperando a alguna operación de entrada-salida, otro ocupaba inmediatamente su lugar en la CPU, para ir avanzando. Con esto nació la gestión de procesos tal y como la conocemos hoy (ya existía cierta gestión de procesos en la decisión de cargar un trabajo cuando el otro acababa, pero era poco más que gestionar una cola, como el Turn-O-Matic de la charcutería).

Pero claro, ahora ya teníamos varios programas a la vez en el ordenador. Imagina que a uno de ellos le da por escribir en una posición de memoria que es de otro programa. Ni siquiera estoy pensando en temas de seguridad o privacidad de los datos del otro programa, sino en simples errores. A lo mejor el “otro programa” era el cálculo de los impuestos del Departamento del Tesoro (el equivalente al Ministerio de Hacienda en España) y modificar por error un número allí podía tener consecuencias catastróficas (para alguien). Así que había que aislar unos programas de otros: la memoria de unos no podía ser vista por otros. Así que los programas se vieron forzados a pedirle por favor al sistema operativo que les diera memoria, a liberarla cuando terminasen, a no salirse de ella y cosas así. Había nacido la gestión de memoria.

Lo mismo ocurría respecto a la entrada/salida: ahora ya podía haber más de un programa que intentara por ejemplo imprimir, y, si se permitía, al final saldría todo embarullado por la impresora. Así que no se puede permitir que los programas impriman directamente, sino que deben pedirle al sistema operativo que imprima, y él ya lo hará cuando considere que no interfiere con los demás programas (y lo mismo, por supuesto, aplica al resto de dispositivos de entrada y salida: la pantalla, leer/escribir en cinta, en disco…). Es decir, el sistema operativo tuvo que empezar a gestionar el hardware.

Pero todo era aún muy rudimentario (desde nuestro punto de vista, claro). Macluskey cuenta siempre que el Sistema Operativo del ordenador en que comenzó a trabajar a mediados de los setenta sólo ocupaba 3 Kb en la memoria de la máquina. 3Kb: 3.000 octetos, así que imaginaros lo poquito que podía hacer con tan poco código. Los trabajos no eran nada interactivos: una vez empezaban, seguían hasta que acababan o hasta que daban un error… lo cual no era infrecuente. Si has programado alguna vez un simple “ahorcado”, ¿te puedes imaginar lo que puede ser programar eso en  FORTRAN o, peor aún, en ensamblador? La probabilidad de cometer un error era más bien una certeza. Pero el problema es que, aun con los sistemas multiprogramados, desde que tú enviabas el programa al ordenador hasta que volvía el resultado de su ejecución podían pasar horas o incluso días. Y todo para descubrir a lo peor que tenías un error de sintaxis en la cuarta línea del programa y que la espera no había servido de nada.^[4][5]

Así que se buscó que los programadores pudieran utilizar el ordenador aún cuando ya hubiera un programa ejecutándose. La solución es muy sencilla: en los sistemas multiprogramados metíamos un programa de los de la cola cuando el principal hacía operaciones de entrada-salida… ¿por qué no hacemos ese cambio de forma obligada cada cierto tiempo? Mejor aún: si tengo 6 programas cargados, puedo darle la CPU primero al 1, luego al 2, luego al 3… así hasta el 6… y luego otra vez al 1, y al 2… y así continuamente. ¿No? Si hago eso, y lo hago lo bastante rápido (por ejemplo, cada 10ms) a todos los programas casi les parece que están continuamente ejecutándose, aunque en realidad vayan a saltos. Grosso modo ocurre que si hay 8 programas ejecutándose a ratitos en un ordenador de potencia 100 (signifique eso lo que signifique), casi casi le parece a cada uno de ellos que en realidad se está ejecutando él solo en un ordenador de potencia 12,5 (12,5=100/8). Habían nacido los sistema de tiempo compartido.^[6]

Ordenador Cray2, que en 1985 era el ordenador más potente del mundo… y permaneció el primero hasta 1990 (Matthew Phillips, cc-by-nd-2.0, http://ja.fotopedia.com/items/flickr-2456335311 ; expuesto en el Musée des arts et metiers de París)

Las posibilidades de esta aproximación fueron ingentes. No solo para los programadores, que ahora podían probar sus programas rápidamente, sino porque permitía hacer programas que utilizaran usuarios sin formación técnica. Era posible hacer programas interactivos: el programa podía pedirle al usuario que hiciera algo y actuar en consecuencia. Simplemente, mientras el programa estaba esperando a que el usuario tecleara sus datos nunca le tocaba la CPU y listo. El sistema operativo se encargaba de ello. Y cuando tenía trabajo que hacer, le iba tocando la CPU a ráfagas cortas y rápidas. Se desplegaron terminales, de forma que más de un usuario pudiera usar el ordenador a la vez, y se les pusieron los terminales en el despacho. Ahora ya era posible hacer editores de texto, hojas de cálculo, bases de datos interactivas,… ¡incluso juegos! Había nacido la informática moderna.

El resto… ya casi ni es historia. Los sistemas se miniaturizaron, se hicieron más baratos, su consumo energético se redujo, se inventaron los interfaces visuales, las redes… de forma que hoy en día llevas más potencia en tu teléfono móvil que aquellos primitivos ordenadores de von Neumann (pero no un poquito, no, sino muchos órdenes de magnitud más). Si eres un lector habitual de este blog, conoces la serie de Macluskey sobre la historia de la informática. Y si no la conoces, ¿a qué estás esperando, alma de cántaro? Te estás perdiendo una de las mejores series que se ha escrito en El Cedazo.

En el próximo capítulo profundizaremos un poco más (solo un poco) en el funcionamiento del sistema operativo.

1. El UNIVAC 1, el primer ordenador con arquitectura Von Neumann. [↩]
2. Digo “supongo” con toda la intención, porque no recuerdo haberlo leído en ningún sitio. Pero vaya, no parece una suposición descabellada. [↩]
3. Existían desde hacía mucho tiempo para definir el patrón que debían usar los telares. [↩]
4. Yo me desespero cuando hoy en día una prueba tarda más de unos cuantos segundos, así que me imagino lo que debía ser esperar hasta el día siguiente. [↩]
5. Nota de Macluskey: Cuando no habías conocido otra cosa, no lo echabas de menos: así era como se funcionaba, y punto. Usabas los tiempos muertos en escribir tu o tus siguientes programas… en realidad también nosotros, los programadores de la época, éramos multiprogramadores. [↩]
6. De hecho, debido al tiempo perdido en la entrada-salida, estadísticamente a los programas les parece que es incluso mejor que 12,5. [↩]

The Computador mágico XXIX – Sistema operativo I: historia by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.