La historia de los sistemas operativos no es una lista de fechas que memorizar: es la historia de una secuencia de problemas y soluciones. Cada generación de sistemas operativos nació para resolver una limitación concreta de la anterior, y casi todo lo que hoy te parece obvio —que puedas tener varias ventanas abiertas, que un programa no tumbe a los demás, que puedas conectarte a una máquina remota— fue en su momento una idea nueva y polémica. Entender ese recorrido te dará algo valioso: cuando en los próximos módulos veas un mecanismo complicado (la memoria virtual, los semáforos, el sistema de archivos con journaling), sabrás qué desastre concreto vino a evitar. Y verás que las ideas de diseño que sobrevivieron son sorprendentemente pocas.

1. Antes del sistema operativo: la máquina desnuda y los monitores residentes
2. Procesamiento por lotes: aprovechar cada minuto de una máquina carísima
3. Multiprogramación: que la CPU no espere al disco
4. Tiempo compartido: devolver la interactividad al programador
5. UNIX y una filosofía de diseño
6. El ordenador personal: CP/M, MS-DOS, Windows y Macintosh
7. El software libre y el nacimiento de Linux
8. La era de la red e Internet
9. La era actual: móvil, nube y contenedores
10. Tabla cronológica de hitos
11. Las ideas que sobrevivieron y por qué

Décadas de 1940 y 1950. Los primeros ordenadores (ENIAC, EDSAC, IBM 701) no tenían sistema operativo. El programador reservaba la máquina por horas, entraba físicamente en la sala, cargaba su programa mediante interruptores o tarjetas perforadas, lo ejecutaba y leía los resultados en luces o en una impresora.

El problema era brutal y muy medible: una máquina que costaba millones de dólares pasaba la mayor parte del tiempo parada, esperando a que un humano cambiara de cinta o de tarjetas. Se estima que el tiempo útil de cálculo no llegaba al 20 % del tiempo alquilado.

La primera solución fue el monitor residente: un pequeño programa que se quedaba permanentemente en memoria y se encargaba de cargar el siguiente trabajo automáticamente cuando el anterior terminaba. No planificaba, no protegía, no repartía nada: solo evitaba la intervención humana entre trabajo y trabajo. Aun así, es el antepasado directo del núcleo, porque introdujo la idea de código que está siempre ahí y controla a los programas.

Años 50 y principios de los 60. El siguiente paso fue agrupar trabajos parecidos en lotes (batches): se recogían las tarjetas perforadas de muchos programadores, se pasaban a cinta magnética en una máquina barata, y la máquina cara ejecutaba la cinta entera de golpe.

Aquí aparece una idea que sigue vigente: el lenguaje de control de trabajos (JCL en los sistemas IBM), con el que el programador describía qué recursos necesitaba su trabajo. Era, en esencia, el primer script de despliegue.

Aunque la sintaxis resulte extraña, el contenido te sonará mucho:

• JOB declara el trabajo, a quién se le factura (CUENTA) y cuánto tiempo máximo puede consumir (TIME=(0,30), 30 segundos). Es exactamente el mismo concepto que un límite de recursos en un contenedor moderno.
• EXEC PGM=AGREGADOR dice qué programa ejecutar.
• Las líneas DD (Data Definition) asocian nombres lógicos a conjuntos de datos concretos. Es el mismo principio que un descriptor de fichero o una variable de entorno con una ruta: el programa usa un nombre lógico y el sistema decide qué hay detrás.

Limitación que quedaba pendiente: mientras el trabajo leía de cinta, la CPU estaba parada. Y leer una cinta era miles de veces más lento que calcular.

Años 60. La solución fue mantener varios trabajos en memoria a la vez. Cuando el trabajo A se bloquea esperando a la cinta, el sistema pasa la CPU al trabajo B. Cuando A recibe sus datos, vuelve a la cola. Esto es la multiprogramación, y con ella nace de verdad el sistema operativo como gestor de recursos.

El impacto es fácil de cuantificar. Supongamos que un trabajo pasa el 80 % de su tiempo esperando entrada/salida. Con un solo trabajo en memoria, la CPU se aprovecha un 20 %. Con n trabajos independientes en memoria, la probabilidad de que todos estén esperando a la vez es 0,8ⁿ, así que el aprovechamiento es 1 − 0,8ⁿ:

Pasar de 1 a 5 trabajos triplica el rendimiento sin cambiar el hardware. Ese cálculo justificó por sí solo toda la complejidad añadida.

Pero la multiprogramación trajo problemas nuevos, y de ahí salen tres módulos enteros de este curso:

• Si hay varios programas en memoria, hay que protegerlos entre sí → gestión de memoria y protección.
• Hay que decidir a quién le toca la CPU → planificación.
• Los programas pueden interferirse al usar recursos compartidos → concurrencia y sincronización.

Los sistemas emblemáticos de esta etapa fueron OS/360 de IBM (1964) y Multics (del que hablamos enseguida). OS/360 es también célebre por su desarrollo desastroso, que Fred Brooks contó en The Mythical Man-Month: fue el primer proyecto que demostró que añadir programadores a un proyecto retrasado lo retrasa más.

El procesamiento por lotes era eficiente para la máquina, pero horrible para el humano: entregabas tus tarjetas y recibías el resultado al día siguiente. Si te habías dejado una coma, perdías un día entero.

La idea del tiempo compartido (time-sharing) fue dar a cada usuario una porción de tiempo de CPU tan breve y tan frecuente que cada uno creyera tener la máquina para sí. Como los humanos pensamos lento y escribimos lento, una sola máquina podía atender a decenas de usuarios simultáneos.

• CTSS (Compatible Time-Sharing System, MIT, 1961) fue el primero que funcionó de verdad. Demostró que la idea era viable.
• Multics (MIT, Bell Labs y General Electric, desde 1965) fue el proyecto ambicioso que quería llevar la idea al extremo: un "servicio de computación" comparable a la red eléctrica, con seguridad por anillos de privilegio, memoria segmentada, sistema de ficheros jerárquico y alta disponibilidad. Multics fue demasiado ambicioso y llegó tarde, y Bell Labs abandonó el proyecto en 1969.

Multics se suele contar como un fracaso, pero es un fracaso extraordinariamente influyente: los anillos de privilegio, el sistema de ficheros jerárquico con directorios anidados, los enlaces dinámicos y la idea de tratar la memoria y los ficheros de forma uniforme vienen de ahí. Y su abandono produjo directamente el sistema operativo más influyente de la historia.

1969, Bell Labs. Ken Thompson, frustrado por la desaparición de Multics, escribió en un PDP-7 en desuso un sistema mucho más pequeño y simple. Brian Kernighan lo bautizó UNICS en broma (un juego de palabras con Multics), y acabó llamándose UNIX.

Dos decisiones lo cambiaron todo:

1. Reescribirlo en C (1973, con Dennis Ritchie). Hasta entonces los sistemas operativos se escribían en ensamblador, atados a una máquina concreta. Un sistema escrito en un lenguaje de alto nivel se podía portar a otro hardware recompilando. Fue una idea considerada arriesgada e ineficiente en su momento; hoy es la norma absoluta.
2. Distribuirlo con el código fuente a las universidades por un precio simbólico. Eso creó una generación entera de programadores que aprendieron leyendo un sistema operativo real, y dio lugar a BSD (Berkeley Software Distribution), de donde salieron la implementación de TCP/IP más usada del mundo, los sockets y el editor vi.

La filosofía UNIX, que sigue siendo la mejor guía de diseño de software que existe, se resume en pocos principios:

• Escribe programas que hagan una sola cosa y la hagan bien.
• Escribe programas que trabajen juntos, comunicándose mediante flujos de texto.
• El texto plano es la interfaz universal.
• Todo es un fichero.

Un ejemplo con datos de Meteora ilustra la potencia de esos principios mejor que cualquier explicación:

Vamos parte por parte:

• grep 'estacion=118' ... filtra del registro solo las líneas de la estación 118. grep no sabe nada de meteorología: solo busca texto.
• | es la tubería (pipe), la aportación estrella de UNIX: conecta la salida de un programa con la entrada del siguiente, sin ficheros temporales y sin que ninguno de los dos sepa de la existencia del otro.
• awk '{print $4}' extrae el cuarto campo de cada línea (supongamos que es la hora de la petición). awk no sabe qué significa ese campo.
• sort ordena, requisito para el paso siguiente.
• uniq -c colapsa líneas repetidas y antepone cuántas veces aparecía cada una.
• sort -rn reordena numéricamente (-n) y de mayor a menor (-r).
• head -5 se queda con las cinco primeras.

Resultado: las cinco horas con más consultas a la estación 118. Ninguno de esos seis programas fue escrito pensando en Meteora ni en los otros cinco, y sin embargo cooperan. Ese es el logro de diseño de UNIX, y es la razón de que la línea de comandos siga siendo una herramienta de primer nivel cincuenta años después (volveremos a ello en La Línea de Comandos como Interfaz del Sistema).

Años 70 y 80. El microprocesador abarató el hardware hasta el punto de que una persona podía tener un ordenador. Pero ese ordenador era mucho más limitado que los grandes sistemas: sin memoria protegida, con muy poca RAM y con un solo usuario. Curiosamente, eso supuso un retroceso técnico: los primeros sistemas operativos de PC olvidaron casi todo lo aprendido en multiprogramación y protección, simplemente porque el hardware no lo permitía.

• CP/M (Gary Kildall, 1974) fue el primer SO ampliamente usado en microordenadores de 8 bits. Su gran idea fue el BIOS: separar la parte del sistema que depende del hardware concreto del resto, para que el mismo CP/M funcionara en máquinas de fabricantes distintos. Es un caso temprano de capa de abstracción de hardware.
• MS-DOS (Microsoft, 1981) llegó al IBM PC. Técnicamente era pobre —monotarea, sin protección de memoria, con nombres de fichero de 8+3 caracteres— pero fue el sistema del ordenador que se convirtió en estándar de industria.
• Macintosh (Apple, 1984) popularizó la interfaz gráfica con ventanas, iconos, menús y ratón, ideas nacidas en Xerox PARC con el Alto y el sistema Smalltalk. Cambió para siempre quién podía usar un ordenador.
• Windows empezó como un entorno gráfico encima de MS-DOS (1985). Windows 95 mezcló código de 16 y 32 bits con multitarea cooperativa, lo que explica su legendaria inestabilidad. La ruptura real llegó con Windows NT (1993), diseñado desde cero por un equipo dirigido por Dave Cutler, que venía de VMS: núcleo híbrido, memoria protegida, multitarea apropiativa y multiusuario. Todo Windows moderno desciende de NT, no de MS-DOS.

1983-1991. Richard Stallman lanzó el proyecto GNU con el objetivo de construir un sistema operativo completo y libre, compatible con UNIX. GNU produjo piezas fundamentales —el compilador gcc, el depurador gdb, bash, las coreutils— y, sobre todo, la licencia GPL, que garantiza que el código derivado siga siendo libre. Lo que le faltaba a GNU era precisamente el núcleo: su proyecto de núcleo, Hurd, nunca llegó a estar listo.

1991. Linus Torvalds, estudiante en Helsinki, publicó un núcleo propio como proyecto personal. Su mensaje original decía que sería "solo una afición, nada grande ni profesional como GNU". Combinado con las herramientas GNU, ese núcleo formó un sistema operativo completo y libre.

La clave de su éxito no fue solo técnica sino organizativa: el modelo de desarrollo abierto y distribuido, con miles de colaboradores y un ciclo de integración rápido, resultó más eficaz de lo que nadie esperaba. Hoy el núcleo Linux tiene más de 30 millones de líneas de código y recibe contribuciones de miles de personas y de casi todas las grandes empresas tecnológicas. En meteo-01, como en la inmensa mayoría de servidores del mundo, es ese núcleo el que está trabajando:

Qué te dice cada campo:

• Linux es el núcleo; meteo-01 el nombre de la máquina.
• 6.1.0-18-amd64 es la versión del núcleo y la arquitectura.
• SMP significa Symmetric MultiProcessing: soporte para varios núcleos de CPU, herencia directa de la multiprogramación.
• PREEMPT_DYNAMIC indica que el núcleo puede ser apropiado (interrumpido) incluso mientras ejecuta código del propio núcleo, lo que reduce las latencias.
• GNU/Linux recuerda precisamente lo anterior: el sistema es núcleo Linux + herramientas GNU.

Años 80 y 90. Con la conexión permanente aparecieron requisitos nuevos que el SO tuvo que absorber:

• La pila de red como parte del núcleo. TCP/IP dejó de ser un añadido para convertirse en un subsistema central. La implementación de BSD fue la referencia mundial y su API de sockets sigue siendo el estándar.
• La abstracción de socket, que extendió "todo es un fichero" a la comunicación remota: un socket se lee y se escribe como un fichero.
• Sistemas de ficheros en red (NFS, SMB), que permitieron que un directorio de una máquina apareciera dentro del árbol de otra.
• La seguridad como problema real. Con una máquina aislada, la protección era casi un asunto académico. Con una máquina conectada, cualquier fallo es explotable desde el otro lado del mundo. El gusano Morris de 1988 lo demostró de forma espectacular al infectar una parte significativa de la Internet de la época, y es el origen de que el módulo 5 de este curso exista.

Desde los 2000. Tres desplazamientos han marcado la etapa actual:

• Móvil. Android (sobre núcleo Linux) e iOS (sobre un núcleo derivado de Mach y BSD) llevaron los sistemas operativos a miles de millones de dispositivos, con dos prioridades nuevas: la batería (el sistema apaga agresivamente lo que no se usa) y el aislamiento por aplicación (cada app se ejecuta con su propio usuario y permisos explícitos, en lugar de heredar los del usuario humano).
• Nube. La virtualización permitió que muchas máquinas virtuales compartieran un servidor físico, convirtiendo el cómputo en un servicio que se alquila por minutos. Curiosamente, es la vieja idea de Multics —la computación como servicio público— cumplida sesenta años después.
• Contenedores. En lugar de virtualizar el hardware entero, se aísla un conjunto de procesos dentro del mismo núcleo mediante namespaces y cgroups. Es una vuelta de tuerca sobre la protección clásica del SO, no una tecnología ajena a él.

Estos tres temas se desarrollan en el módulo 6: Virtualización: Hipervisores y Máquinas Virtuales, Contenedores: Namespaces y cgroups y Sistemas Operativos Móviles y de Tiempo Real. Aquí solo nos interesa situarlos en la línea del tiempo.

Si comparas un sistema de 1970 con meteo-01, cambia casi todo el código pero se mantiene el esqueleto conceptual. Estas son las ideas que resistieron, y la razón de que lo hicieran:

1. El proceso como unidad de ejecución aislada. Sobrevive porque resuelve dos problemas a la vez (contabilidad y protección) con un solo concepto.
2. La separación entre modo usuario y modo núcleo. Es la única forma conocida de que el sistema pueda confiar en sí mismo aunque no confíe en los programas que ejecuta. Ninguna alternativa ha sido mejor. Es el tema de Modo Usuario, Modo Núcleo y Llamadas al Sistema.
3. El fichero como secuencia de bytes con nombre. Sobrevive por lo que no impone: al no dictar ningún formato, sirve igual para un .dat de lecturas, una imagen o un ejecutable.
4. La jerarquía de directorios. Un árbol único es lo bastante simple de entender y lo bastante flexible para organizar millones de ficheros.
5. "Todo es un fichero". Reutilizar una interfaz conocida para cosas nuevas (dispositivos, sockets, información del núcleo) reduce enormemente lo que hay que aprender y lo que hay que programar.
6. Las tuberías y la composición de programas pequeños. Sobreviven porque escalan a problemas que nadie previó.
7. La memoria virtual. Da a cada proceso un espacio propio, permite usar más memoria de la que hay y simplifica la carga de programas. Tres beneficios por un mecanismo.
8. El tiempo compartido con apropiación. Sin la capacidad del SO de quitarle la CPU a un proceso, un solo programa mal escrito paraliza la máquina. La era de la multitarea cooperativa (Windows 3.x, Mac OS clásico) demostró en la práctica lo mal que funciona la alternativa.

Y una idea que no sobrevivió pero conviene conocer: los sistemas que confiaban en la buena voluntad de los programas (multitarea cooperativa, memoria sin protección) fracasaron siempre. La lección práctica, que vale también para el software que escribas tú, es que un sistema no debe depender de que sus usuarios se porten bien.

• Estudiar las fechas en vez de los problemas. Nadie te va a preguntar en qué año salió Multics. Lo que sí importa es que sepas explicar qué problema resolvió el tiempo compartido y por qué la multiprogramación exige protección de memoria.
• Creer que la evolución fue siempre hacia adelante. No lo fue: los primeros sistemas de PC fueron un retroceso técnico frente a los grandes sistemas de los 60. Las restricciones del hardware y del mercado mandan tanto como las buenas ideas.
• Confundir Linux con GNU/Linux, o con una distribución. Linux es solo el núcleo. Lo que instalas es un conjunto formado por ese núcleo más herramientas GNU y muchos otros programas, empaquetado por una distribución.
• Pensar que UNIX está superado. macOS es un UNIX certificado, Android usa el núcleo Linux, iOS deriva de BSD y prácticamente todos los servidores del mundo son UNIX o Linux. El modelo no solo no está superado: ganó.
• Consejo: cuando en los siguientes módulos aparezca un mecanismo que te parezca innecesariamente complicado, pregúntate qué desastre concreto evita. Casi siempre hay una anécdota histórica detrás, y recordarla fija el concepto mucho mejor que la definición.

Para cada limitación de la izquierda, indica qué avance histórico la resolvió y qué nuevo problema introdujo ese avance:

1. La CPU está parada mientras el humano cambia las tarjetas.
2. La CPU está parada mientras el trabajo lee de la cinta.
3. El programador espera un día entero para saber si su programa compila.
4. El sistema operativo hay que reescribirlo entero al cambiar de máquina.

En meteo-01, ingestor pasa el 90 % de su tiempo esperando datos de red y solo el 10 % calculando. Usando la fórmula de aprovechamiento de CPU de la multiprogramación (1 − p^n, con p la fracción de espera), calcula el aprovechamiento con 1, 3, 6 y 12 procesos de ese perfil. ¿Merece la pena pasar de 6 a 12? Razona qué otro factor del sistema real limita esta fórmula.

Escribe una única línea de comandos, al estilo de la filosofía UNIX, que a partir de /var/log/meteora/meteo-api.log obtenga las tres direcciones IP que más peticiones han hecho. Supón que la IP es el primer campo de cada línea, separado por espacios. Explica qué principio de la filosofía UNIX ejemplifica tu solución y por qué no hace falta un programa específico de Meteora para resolverlo.

Solución 1

1. Humano cambiando tarjetas → lo resolvió el procesamiento por lotes con monitor residente, que encadenaba trabajos automáticamente. Problema nuevo: el usuario pierde toda interactividad, ya no puede intervenir mientras su trabajo se ejecuta.
2. CPU parada esperando la cinta → lo resolvió la multiprogramación, manteniendo varios trabajos en memoria y conmutando cuando uno se bloquea. Problemas nuevos: hay que proteger la memoria de unos trabajos frente a otros, hay que decidir a quién se le da la CPU (planificación) y aparecen las condiciones de carrera al compartir recursos.
3. Un día de espera por el resultado → lo resolvió el tiempo compartido, dando porciones muy breves de CPU a muchos usuarios interactivos. Problemas nuevos: cómo garantizar tiempos de respuesta razonables cuando hay muchos usuarios, cómo evitar que uno monopolice el sistema y cómo aislar a usuarios que ahora conviven de verdad (nace la necesidad de cuentas, permisos y contraseñas).
4. Reescribir el SO al cambiar de máquina → lo resolvió escribir el sistema operativo en C (UNIX, 1973), aislando en unas pocas partes el código dependiente del hardware. Problema nuevo: una pequeña pérdida de rendimiento frente al ensamblador hecho a mano y la necesidad de disponer de un compilador fiable para cada arquitectura destino. El intercambio resultó tan favorable que hoy nadie se plantea lo contrario.

Solución 2

Con p = 0,9 (fracción de tiempo que un proceso pasa esperando):

¿Merece la pena pasar de 6 a 12? En términos de esta fórmula, sí: se gana casi 25 puntos porcentuales, un poco más de lo que se ganó al pasar de 3 a 6 (19,8 puntos). Pero fíjate en que el rendimiento marginal ya está cayendo: cada proceso añadido aporta menos que el anterior, porque la curva se aplana al acercarse al 100 %.

Qué limita la fórmula en el mundo real:

• La memoria. Cada proceso adicional ocupa RAM. Si al añadir procesos el sistema empieza a intercambiar páginas con el disco (swapping), el rendimiento se hunde en lugar de mejorar. Lo verás en Memoria Virtual y Paginación.
• La independencia estadística que la fórmula supone. Si todos los procesos esperan al mismo recurso (por ejemplo, el mismo disco o la misma tarjeta de red), sus esperas están correlacionadas y el aprovechamiento real es mucho peor que el predicho.
• El coste del cambio de contexto. Conmutar entre procesos cuesta tiempo de CPU que la fórmula ignora. Con demasiados procesos, una parte creciente de la CPU se dedica a gestionar la conmutación en lugar de a trabajo útil.

Solución 3

Paso a paso:

• awk '{print $1}' imprime solo el primer campo de cada línea, es decir, la IP. Podríamos usar también cut -d' ' -f1, que es equivalente y algo más rápido.
• sort agrupa las líneas iguales, poniéndolas consecutivas. Es imprescindible porque uniq solo detecta repeticiones adyacentes.
• uniq -c sustituye cada grupo de líneas idénticas por una sola precedida del número de repeticiones.
• sort -rn ordena por ese número (-n, numérico) de mayor a menor (-r).
• head -3 se queda con las tres primeras.

Principio que ejemplifica: la composición de programas pequeños y especializados mediante tuberías, con texto plano como interfaz universal. Ninguno de los cinco programas sabe qué es una IP, qué es Meteora ni qué hacen los demás; cada uno hace una transformación mínima sobre líneas de texto.

Por qué no hace falta un programa específico: porque el formato del registro es texto y las operaciones necesarias (filtrar, extraer, agrupar, contar, ordenar) son genéricas. Escribir un analizador-meteora en Python daría el mismo resultado, pero costaría veinte veces más tiempo, habría que mantenerlo y solo serviría para este caso. El error común aquí es el contrario: usar la línea de comandos para tareas que ya requieren estado complejo o lógica de negocio, donde un programa de verdad sí es la respuesta correcta.

Los sistemas operativos evolucionaron resolviendo un problema tras otro: primero la intervención humana, luego la CPU ociosa, después la falta de interactividad, más tarde la portabilidad y finalmente el aislamiento en un mundo conectado. Cada solución trajo problemas nuevos, y esa cadena explica por qué un sistema moderno tiene la estructura que tiene.

Del recorrido conviene que te lleves tres cosas. Primera, que la multiprogramación es el origen de casi toda la complejidad de un SO: sin ella no harían falta ni la protección de memoria, ni la planificación, ni la sincronización. Segunda, que UNIX ganó por simplicidad y portabilidad, no por potencia, y que su filosofía sigue siendo la mejor guía de diseño disponible. Y tercera, que las ideas que sobrevivieron son pocas y muy generales: proceso, modo dual, fichero, jerarquía, memoria virtual.

Toda esta evolución produjo una variedad enorme de sistemas actuales, desde el firmware de una estación meteorológica que ocupa unos pocos kilobytes hasta el núcleo de un servidor con millones de líneas de código. En la siguiente lección, Tipos de Sistemas Operativos, pondremos orden en esa variedad clasificándola por criterios claros, y decidiremos qué tipo de sistema le conviene a cada pieza de la infraestructura de Meteora.