Todos los días usas un sistema operativo, pero probablemente nunca has visto uno. Lo que ves es el escritorio, la terminal o el navegador; el sistema operativo es la capa invisible que hay debajo y que hace posible que esos programas existan. En esta lección vas a entender qué problema concreto resuelve un sistema operativo, por qué escribir software sin él sería insoportable, y cuáles son las abstracciones que inventó para que hoy puedas abrir un fichero con una sola línea de código sin saber si está en un disco SSD, en un disco mecánico o en un servidor remoto. También conocerás a Meteora, la empresa ficticia cuyo servidor Linux nos acompañará durante todo el curso: cada concepto que aprendas lo verás aplicado sobre su máquina meteo-01.

1. Bienvenido a Meteora: el escenario de todo el curso
2. El problema: hardware desnudo y programas que quieren convivir
3. Primer papel del SO: la máquina extendida
4. Segundo papel del SO: el gestor de recursos
5. Repaso mínimo del hardware que el SO gestiona
6. Las abstracciones fundamentales
7. Anatomía de un sistema: núcleo, bibliotecas, shell y aplicaciones
8. Qué NO es un sistema operativo
9. Cómo cada capa sostiene a meteo-api

Meteora es una empresa (ficticia) que vende datos meteorológicos. Tiene desplegadas cientos de estaciones que miden temperatura, humedad y presión, y ofrece esos datos a sus clientes mediante una API HTTP. Toda su infraestructura vive en un único servidor Linux llamado meteo-01, y el servicio se compone de tres piezas que reaparecerán en cada módulo:

Las convenciones de Meteora son fijas durante todo el curso; conviene que las memorices ahora porque las usaremos sin volver a explicarlas:

• Datos: /var/lib/meteora/lecturas/, con un fichero por día, por ejemplo 2026-08-31.dat.
• Configuración: /etc/meteora/meteora.conf.
• Registros: /var/log/meteora/meteo-api.log.
• Usuario y grupo del sistema: meteora:meteora.
• Estructura de datos recurrente: Lectura, con los campos estacion_id, timestamp, temperatura, humedad y presion.

En C, esa estructura se declara así:

Repasemos el bloque campo por campo, porque lo reutilizaremos muchas veces:

• #include <stdint.h> da acceso a tipos de tamaño garantizado. uint32_t ocupa exactamente 4 bytes en cualquier máquina, mientras que un int normal podría ocupar 2, 4 u 8 según el compilador. Cuando escribes datos binarios a disco o los envías por red, el tamaño exacto importa.
• estacion_id es un entero sin signo: no existen estaciones con identificador negativo, así que aprovechamos todo el rango.
• timestamp es un int64_t porque un int32_t desbordaría en 2038 (el famoso year 2038 problem).
• temperatura, humedad y presion son float (4 bytes). Con la precisión de un sensor real, unos 7 dígitos significativos sobran.

En total, la estructura ocupa 24 bytes (4 + 8 + 4 + 4 + 4 = 24, sin relleno adicional en x86-64 gracias a que el campo de 8 bytes queda alineado). Con 500 estaciones enviando una lectura por minuto, eso son 720.000 lecturas al día, unos 17 MB diarios. Recuerda estos números: los usaremos para razonar sobre memoria y disco.

Imagina que en meteo-01 no hubiera sistema operativo. El programa ingestor arranca solo, con acceso directo al hardware. Para guardar una lectura en disco tendría que:

1. Saber qué modelo de controladora de disco lleva la máquina.
2. Escribir valores concretos en los registros de esa controladora para indicar sector, cabezal y número de bloques.
3. Esperar activamente a que el disco confirme la operación.
4. Interpretar los códigos de error específicos del fabricante.

Y esto solo para un modelo de disco. Si mañana Meteora cambia de servidor, hay que reescribir el programa. Además, si agregador quisiera ejecutarse a la vez, ambos programas escribirían en el mismo disco sin coordinación: se pisarían los sectores mutuamente y corromperían los datos.

De aquí salen los dos problemas fundamentales que resuelve un sistema operativo:

• La complejidad: el hardware es difícil, heterogéneo y desagradable de programar.
• La compartición: varios programas quieren usar a la vez recursos que son limitados y, muchos de ellos, indivisibles.

A esos dos problemas corresponden los dos papeles clásicos del SO.

Un sistema operativo es, ante todo, una máquina virtual más agradable que la real. Toma un hardware feo y ofrece encima una interfaz limpia, uniforme y estable. Es lo que se llama máquina extendida o abstracción del hardware.

Compara las dos formas de guardar una lectura en meteo-01:

En la práctica, el programa de Meteora escribe una lectura así:

Qué hace cada línea y por qué:

• open(...) pide al sistema operativo acceso a un fichero por su nombre. El SO traduce ese nombre a una ubicación física; el programa nunca ve sectores.
  • O_WRONLY: solo vamos a escribir.
  • O_CREAT: si el fichero del día aún no existe, créalo.
  • O_APPEND: cada escritura se añade al final. Es importante: garantiza que dos escrituras no se pisen aunque haya varios procesos escribiendo.
  • 0640: permisos del fichero si hay que crearlo (lectura y escritura para el usuario meteora, lectura para el grupo meteora, nada para el resto). Los veremos en detalle en Seguridad y Permisos de Archivos.
• open devuelve un descriptor de fichero (fd): un simple número entero que el SO usa como identificador de esa conexión abierta. Es una abstracción pura: no existe físicamente.
• write(fd, &l, sizeof(l)) entrega 24 bytes al núcleo. El programa no sabe (ni le importa) si acaban en un SSD NVMe o en un disco de red.
• close(fd) libera el descriptor.

Ese puñado de líneas funciona igual en un portátil, en un servidor y en una Raspberry Pi. Esa portabilidad es el producto que vende el sistema operativo.

La otra mitad del trabajo es repartir. En meteo-01 conviven ingestor, agregador, meteo-api, más los procesos del propio sistema, y todos quieren la misma CPU, la misma memoria y el mismo disco.

El sistema operativo reparte los recursos de dos maneras complementarias:

• Multiplexación en el tiempo: los usuarios del recurso se turnan. Es lo que ocurre con la CPU. Si meteo-01 tiene 4 núcleos y hay 40 procesos, el SO da a cada uno unos milisegundos y va alternando tan deprisa que parece simultáneo. Esto se estudia en Planificación de la CPU.
• Multiplexación en el espacio: el recurso se divide en trozos y cada usuario se queda con uno. Es lo que ocurre con la memoria RAM y con el disco. Cada proceso recibe su porción y no puede tocar la de los demás; lo verás en Gestión de Memoria.

Gestionar no es solo repartir: también implica proteger (que meteo-api no pueda leer la memoria de agregador), contabilizar (saber cuánta CPU consume cada proceso) y arbitrar conflictos (decidir quién escribe primero cuando dos procesos piden el disco a la vez).

Un ejemplo con números: si agregador arranca su cálculo horario y consume el 100 % de un núcleo durante 20 segundos, sin un gestor de recursos meteo-api dejaría de responder a los clientes. Con el planificador del SO, ambos avanzan: meteo-api recupera la CPU en cuanto llega una petición de red, porque el planificador favorece a los procesos que pasan mucho tiempo esperando entrada/salida.

No hace falta ser ingeniero electrónico, pero sí conocer las piezas que el SO administra, porque casi toda decisión de diseño de un sistema operativo se explica por una característica del hardware.

La CPU ejecuta instrucciones en un ciclo perpetuo: buscar la siguiente instrucción, decodificarla y ejecutarla. Para trabajar tiene unos pocos almacenes internos ultrarrápidos, los registros:

• Registros generales (en x86-64: rax, rbx, rcx…): guardan datos intermedios.
• Contador de programa (rip): la dirección de la siguiente instrucción.
• Puntero de pila (rsp): dónde está la cima de la pila.
• Registro de estado (rflags): incluye, entre otras cosas, el bit de modo que distingue si estamos en modo usuario o en modo núcleo. Ese bit es la base de toda la protección del sistema y lo estudiaremos en Modo Usuario, Modo Núcleo y Llamadas al Sistema.

El conjunto de registros de un proceso es su contexto. Cuando el SO cambia de un proceso a otro, guarda todos esos registros y carga los del siguiente: eso es el cambio de contexto.

No existe una memoria que sea a la vez rápida, grande y barata, así que se apilan varias. Estos son órdenes de magnitud típicos en un servidor actual:

La lectura de esta tabla es la clave de casi todo el curso: cuanto más bajas en la jerarquía, más caro es el acceso, y en proporciones brutales. Cuando agregador lee el fichero del día desde disco, cada acceso cuesta el equivalente a 600 accesos a RAM. Por eso el SO mantiene una caché de páginas en RAM con los datos leídos recientemente, y por eso el segundo cálculo horario del mismo día es mucho más rápido que el primero.

Todo lo que no es CPU ni RAM se conecta mediante buses (PCIe, USB, SATA). Cada dispositivo tiene un controlador (el chip que lo maneja) y un controlador de software o driver (el código del SO que sabe hablar con ese chip). Cuando un dispositivo termina su trabajo, avisa a la CPU mediante una interrupción: una señal que hace que la CPU deje lo que estaba haciendo y atienda al dispositivo. Los detalles están en Controladores, Interrupciones y Operaciones de E/S.

Un sistema operativo no es un catálogo de funciones sueltas: es un puñado de ideas abstractas bien elegidas. Estas cuatro son las que sostienen todo lo demás.

Un proceso es un programa en ejecución, con todo lo que necesita para vivir: su código, sus datos, su pila, sus ficheros abiertos, su identidad de usuario y su estado. Es la abstracción de "un ordenador para mí solo".

Qué estamos viendo:

• ps -eo ... lista todos los procesos (-e) mostrando solo las columnas que pedimos (-o).
• pid es el identificador único del proceso; user el usuario propietario (aquí, meteora); comm el nombre del ejecutable.
• --sort=-%cpu ordena de mayor a menor consumo de CPU.
• El proceso 1 es siempre el primero que arranca el núcleo; en un Linux moderno es systemd, que veremos en Servicios, Arranque y systemd.

Fíjate en que agregador está al 98,7 % de CPU y aun así meteo-api sigue vivo: eso es el gestor de recursos trabajando.

Cada proceso cree que dispone de toda la memoria de la máquina, empezando en la dirección 0. Esa ilusión se llama espacio de direcciones, y es lo que impide que un fallo en ingestor corrompa la memoria de meteo-api. Dos procesos pueden usar la dirección 0x400000 a la vez sin colisionar porque el hardware traduce cada dirección virtual a una física distinta. Es el tema de Memoria Virtual y Paginación.

Un fichero es una secuencia de bytes con nombre. Nada más. No tiene formato impuesto por el SO: el significado se lo da la aplicación. Los ficheros se organizan en directorios, formando un árbol único que empieza en /.

UNIX llevó la abstracción de fichero hasta el final: casi todo se representa como un fichero. Un disco, un terminal, un generador de números aleatorios o incluso información del propio núcleo se leen y escriben con las mismas llamadas.

Explicación:

• La primera letra de los permisos indica el tipo: b es un dispositivo de bloques (se accede por bloques, como un disco), c es un dispositivo de caracteres (flujo de bytes, como un terminal).
• Los números 8, 0 y 1, 3 son el major y el minor: el major identifica qué driver atiende el dispositivo, el minor qué unidad concreta.
• /proc/1099/status no existe en ningún disco: el núcleo lo genera al vuelo cuando lo lees. Aun así, se lee con cat como cualquier fichero. Esta es la potencia de la abstracción: una interfaz, muchísimas implementaciones.

Cuando alguien dice "el sistema operativo", suele referirse a un conjunto de capas distintas. Distinguirlas evita muchísima confusión.

Dos matices importantes:

• Solo el núcleo es imprescindible. Todo lo demás son programas ordinarios que se ejecutan sin privilegios especiales y que hablan con el núcleo mediante llamadas al sistema.
• El shell no es parte del núcleo. bash es un programa como cualquier otro: puedes sustituirlo por zsh o fish sin tocar el sistema operativo. Eso demuestra que la interfaz es intercambiable, no fundamental.

Tres confusiones frecuentes que conviene desactivar ya:

• El SO no es la interfaz gráfica. GNOME, KDE o el escritorio de Windows son aplicaciones que se ejecutan encima del sistema operativo. meteo-01 no tiene ninguna interfaz gráfica instalada y funciona perfectamente: los servidores rara vez la llevan, porque consume memoria y aumenta la superficie de ataque.
• El SO no es la distribución. Ubuntu, Debian, Fedora o Alpine no son sistemas operativos distintos: todas usan el mismo núcleo, Linux. Lo que cambia es el conjunto de programas empaquetados, el gestor de paquetes y las decisiones de configuración. Cuando alguien dice "instalé otro sistema operativo" al pasar de Ubuntu a Debian, en rigor cambió de distribución.
• El SO no es el conjunto de aplicaciones que trae. Un navegador, un editor o un reproductor multimedia se distribuyen con el sistema por comodidad, no porque formen parte de él.

Un criterio útil para decidir si algo es parte del sistema operativo: ¿se ejecuta en modo núcleo? Si la respuesta es sí, forma parte del SO en sentido estricto. Si no, es un programa más, por muy imprescindible que parezca.

Cerremos juntando todo. Un cliente pide GET /medias?estacion=118&dia=2026-08-31. Esto es lo que aporta cada capa:

1. Hardware: la tarjeta de red recibe el paquete y lanza una interrupción.
2. Núcleo: el subsistema de red reensambla la petición TCP y la deja disponible en el socket de meteo-api. El planificador marca el proceso como listo para ejecutarse y le asigna CPU.
3. Bibliotecas: meteo-api llama a funciones de glibc para leer del socket y para abrir el fichero del día; glibc traduce esas llamadas cómodas en llamadas al sistema.
4. Núcleo otra vez: busca 2026-08-31.dat en el sistema de archivos, comprueba que el usuario meteora tiene permiso de lectura, sirve los bloques desde la caché de páginas si están, o pide al disco que los traiga si no.
5. Aplicación: meteo-api calcula la respuesta, la serializa en JSON y la escribe en el socket.
6. Núcleo, por última vez: fragmenta la respuesta en paquetes y ordena a la tarjeta de red que los envíe.

Ninguna de estas capas conoce los detalles de las otras, y esa es precisamente la razón de que el sistema sea manejable. En Funciones Principales de un Sistema Operativo recorreremos este mismo camino con más detalle.

• Confundir "sistema operativo" con "lo que veo en pantalla". La interfaz gráfica es la parte más visible y la menos fundamental. Si te acostumbras a trabajar en un servidor sin entorno gráfico, el concepto queda claro enseguida.
• Pensar que el SO se ejecuta continuamente en paralelo a los programas. No es así: el núcleo no es un proceso que corre siempre. La mayor parte del tiempo está inactivo, y solo entra en acción cuando algo lo invoca (una llamada al sistema, una interrupción o una excepción). Es más un conjunto de rutinas de respuesta que un programa perpetuo.
• Creer que un fichero "está" en un sitio del disco que el programa conoce. El programa solo conoce un nombre y un descriptor. La ubicación física puede cambiar (desfragmentación, copy-on-write, sistemas de archivos en red) sin que la aplicación se entere.
• Ignorar la jerarquía de memoria al razonar sobre rendimiento. Muchísimos problemas de rendimiento que parecen "de CPU" son en realidad de acceso a memoria o a disco. Interioriza los órdenes de magnitud de la tabla: te ahorrarán horas de diagnóstico erróneo.
• Consejo práctico: instala una máquina virtual con una distribución Linux sin entorno gráfico (Debian netinst o Alpine sirven) y trabaja ahí durante el curso. Ver el sistema sin adornos acelera mucho la comprensión.

Clasifica cada uno de estos elementos de meteo-01 como (a) parte del núcleo, (b) biblioteca del sistema, (c) utilidad o shell, o (d) aplicación. Justifica cada respuesta con el criterio del modo de ejecución:

1. El planificador que decide qué proceso usa la CPU.
2. bash.
3. glibc.
4. El controlador de la tarjeta de red.
5. meteo-api.
6. systemctl.

agregador necesita leer las 720.000 lecturas de un día (17 MB) para calcular las medias horarias. Usando los tiempos de la tabla de jerarquía de memoria, estima el orden de magnitud del tiempo de lectura en dos escenarios: (a) el fichero no está cacheado y hay que leerlo de un SSD NVMe; (b) el fichero ya está en la caché de páginas en RAM. Supón lecturas en bloques de 4 KB y un coste por bloque de 50 µs desde SSD y 80 ns desde RAM. ¿Qué implicación práctica tiene la diferencia?

Explica, sin usar la palabra "abstracción", por qué el mismo programa en C que escribe una Lectura con write() funciona sin cambios en un portátil con SSD y en un servidor con almacenamiento en red. Indica en qué punto exacto del recorrido desaparece la diferencia entre ambos hardware.

Solución 1

El criterio es: ¿se ejecuta en modo núcleo, con acceso directo al hardware?

1. Planificador → (a) núcleo. Decide qué proceso ocupa la CPU y para eso debe manipular registros y tablas internas; es código privilegiado por definición.
2. bash → (c) utilidad/shell. Es un programa de usuario corriente. La prueba es que puedes sustituirlo por zsh sin recompilar nada del sistema, y que si bash falla el sistema sigue funcionando.
3. glibc → (b) biblioteca del sistema. Se ejecuta en modo usuario, dentro del espacio de direcciones del proceso que la usa. Su papel es envolver las llamadas al sistema en funciones cómodas (fopen, printf).
4. Controlador de red → (a) núcleo. Programa directamente los registros del hardware y atiende sus interrupciones; necesita privilegios. En Linux suele ser un módulo cargable, pero se ejecuta en modo núcleo igualmente (lo verás en Arquitectura del Núcleo).
5. meteo-api → (d) aplicación. Es el software de negocio de Meteora, sin privilegios especiales; corre como el usuario meteora.
6. systemctl → (c) utilidad. Aunque gestione servicios del sistema, es un cliente de usuario que envía órdenes a systemd, que a su vez es también un proceso de usuario (el PID 1). Nada de esto vive en el núcleo.

Solución 2

Primero, cuántos bloques de 4 KB hay en 17 MB:

(a) Desde SSD NVMe, a 50 µs por bloque:

(b) Desde la caché de páginas en RAM, a 80 ns por bloque:

La diferencia es de un factor de unas 600 veces. La implicación práctica es doble:

• La primera ejecución del cálculo horario después de arrancar la máquina será perceptiblemente más lenta que las siguientes, aunque el código sea idéntico. Si mides rendimiento sin tener esto en cuenta, sacarás conclusiones falsas.
• Merece muchísimo la pena que el fichero del día quepa en la caché de páginas. Con 17 MB diarios, tener 1 GB de RAM libre para caché permite mantener casi dos meses de datos en memoria, lo que hace irrelevante el coste del disco para el trabajo habitual de agregador.

(Nota: esta estimación ignora la lectura anticipada — readahead — que hace el núcleo y que en la práctica mejora mucho el caso (a). El orden de magnitud de la conclusión no cambia.)

Solución 3

El programa funciona igual porque no habla con el disco: habla con el núcleo. Lo único que el programa nombra es una cadena de texto (/var/lib/meteora/lecturas/2026-08-31.dat) y un número entero (el descriptor de fichero). Ninguna de esas dos cosas depende del hardware.

El punto exacto donde desaparece la diferencia es la llamada al sistema write(): al otro lado de esa frontera, el núcleo consulta qué sistema de archivos gestiona esa ruta y le entrega la operación. Ese sistema de archivos, a su vez, se apoya en un controlador concreto — el del SSD o el del cliente de red — y cada uno hace lo que corresponda con su hardware.

Dicho de otro modo: la diferencia entre ambos hardware existe, pero vive por debajo de la llamada al sistema, y el programa nunca cruza esa frontera. El núcleo ofrece siempre el mismo contrato hacia arriba (recibe bytes y un descriptor, devuelve cuántos bytes escribió o un error) y resuelve por debajo la variedad. Ese contrato estable es lo que hace que el código sea portable.

Un sistema operativo resuelve dos problemas que el hardware plantea y no sabe resolver solo: es demasiado complejo para programarlo directamente y es demasiado escaso para que varios programas lo usen sin coordinación. De ahí sus dos papeles: máquina extendida, que ofrece una interfaz limpia y portable, y gestor de recursos, que reparte CPU, memoria y dispositivos en el tiempo y en el espacio.

Para lograrlo introdujo unas pocas abstracciones muy bien elegidas — proceso, espacio de direcciones, fichero y dispositivo-como-fichero — y se organizó en capas: núcleo, bibliotecas del sistema, shell y utilidades, y aplicaciones. Solo la primera se ejecuta en modo privilegiado, y ese es el criterio que separa el sistema operativo de todo lo demás. También has visto qué no es un SO: ni la interfaz gráfica ni la distribución.

Nada de esto surgió de golpe. Cada una de estas ideas apareció como respuesta a una limitación concreta de su época: el reparto de tiempo nació porque los ordenadores eran carísimos y no podían estar parados, y los ficheros con nombre nacieron porque nadie quería recordar sectores. En la siguiente lección, Historia y Evolución de los Sistemas Operativos, recorreremos ese camino generación a generación para entender por qué los sistemas operativos son como son.