TEMA 1 — CONCEPTOS DE SISTEMAS OPERATIVOS

Características, Evolución, Estructura, Componentes y Funciones

Nota de estudio: Este tema es la base conceptual de toda la asignatura. Dominar estos conceptos permite responder correctamente preguntas como la 1 (comandos Linux), la 9 (permisos NTFS), y entender los fundamentos de seguridad, redes y almacenamiento que aparecen en el resto del examen.

1. DEFINICIÓN Y CONCEPTO DE SISTEMA OPERATIVO

Un sistema operativo (SO) es el conjunto de programas que gestiona los recursos hardware de un ordenador y proporciona servicios comunes a los programas de aplicación. Es el intermediario entre el hardware físico y el software que ejecutan los usuarios.

Tiene tres roles simultáneos e inseparables:

1. Gestor de recursos: controla y distribuye de forma eficiente la CPU, la memoria RAM, el almacenamiento y los dispositivos de E/S entre todos los procesos que compiten por ellos, evitando conflictos.

2. Máquina extendida (o máquina virtual): oculta la complejidad del hardware real y ofrece a los programadores una interfaz abstracta, uniforme y más sencilla de usar. Un programa no necesita saber si el disco es NVMe, SATA o una unidad en red; el SO presenta una misma interfaz de ficheros.

3. Árbitro: resuelve conflictos entre procesos que quieren acceder al mismo recurso, garantizando aislamiento, seguridad y equidad.

Analogía: El SO es como el director de un aeropuerto: los aviones (aplicaciones) no se comunican directamente con las pistas, el combustible o el control de tráfico (hardware); el director (SO) coordina todo para que cada avión despegue y aterrice sin colisiones.

2. FUNCIONES PRINCIPALES DEL SISTEMA OPERATIVO

2.1 Gestión de procesos

¿Qué es un proceso?

Un proceso es un programa en ejecución. No es lo mismo que el programa (fichero en disco, estático); el proceso es ese programa cargado en memoria con su estado de ejecución, sus variables, su contador de programa y sus recursos asignados.

Componentes de un proceso:
- Código (text segment): instrucciones del programa.
- Datos (data segment): variables globales y estáticas.
- Heap: memoria dinámica asignada en tiempo de ejecución (malloc, new).
- Stack (pila): variables locales, parámetros de funciones y direcciones de retorno.
- PCB (Process Control Block): estructura de datos del SO que almacena toda la información del proceso (PID, estado, registros de CPU, prioridad, recursos asignados...).

Estados de un proceso

Un proceso pasa por los siguientes estados a lo largo de su vida:

                  admitido
  [ NUEVO ] ─────────────────► [ LISTO ] ◄──────────── interrupción
                                    │                        │
                              despachado                     │
                                    │                        │
                                    ▼                        │
                              [ EJECUTANDO ] ────────────────┘
                                    │
                    ┌───────────────┴──────────────┐
               E/S o evento               termina
                    │                              │
                    ▼                              ▼
              [ BLOQUEADO ]               [ TERMINADO ]
                    │
           E/S o evento completado
                    │
                    └──────────────► [ LISTO ]

Ejemplo práctico: Cuando abres un navegador web (nuevo → listo → ejecutando), haces clic en un enlace y el navegador espera la respuesta del servidor (ejecutando → bloqueado), cuando llega la respuesta (bloqueado → listo → ejecutando) y cuando cierras el navegador (ejecutando → terminado).

Hilos (Threads)

Un hilo (thread o proceso ligero) es la unidad mínima de ejecución dentro de un proceso. Un proceso puede contener múltiples hilos que comparten el mismo espacio de memoria (heap, código, datos globales) pero cada uno tiene su propio stack y sus propios registros de CPU.

Modelos de hilos:

• Modelo 1:1 (un hilo de usuario por un hilo de kernel): usado en Linux y Windows. Cada hilo de usuario tiene un hilo de kernel correspondiente. El SO gestiona directamente cada hilo, lo que permite aprovechar múltiples núcleos. Ejemplo: pthreads en Linux.

• Modelo N:1 (muchos hilos de usuario por un hilo de kernel): todos los hilos de usuario se mapean a un único hilo de kernel. Ventaja: gestión muy rápida. Inconveniente: si un hilo se bloquea en E/S, se bloquean todos. No aprovecha múltiples núcleos.

• Modelo N:M (hilos de usuario por M hilos de kernel): híbrido. El sistema puede mapear varios hilos de usuario a varios hilos de kernel. El más flexible pero el más complejo de implementar.

2.2 Planificación de la CPU (Scheduling)

La planificación decide qué proceso usa la CPU en cada instante. Es una de las funciones más críticas del SO porque impacta directamente en el rendimiento percibido.

Tipos de planificador

• Planificador a largo plazo (job scheduler): decide qué procesos pasan de la cola de espera al estado listo. Controla el grado de multiprogramación.
• Planificador a corto plazo (CPU scheduler): decide qué proceso listo pasa a ejecutar. Se ejecuta muy frecuentemente (cada pocos milisegundos).
• Dispatcher: ejecuta el cambio de contexto real (guarda registros del proceso saliente, carga los del entrante). El tiempo que tarda se llama latencia de despacho y es overhead puro.

Criterios de evaluación

• Utilización de CPU: porcentaje del tiempo que la CPU está ejecutando procesos (no ociosa). Se busca maximizar.
• Throughput: número de procesos completados por unidad de tiempo. Se busca maximizar.
• Tiempo de retorno (turnaround): tiempo total desde que el proceso llega hasta que termina. Se busca minimizar.
• Tiempo de espera: tiempo que el proceso pasa en la cola de listos. Se busca minimizar.
• Tiempo de respuesta: tiempo hasta la primera respuesta (especialmente importante en sistemas interactivos). Se busca minimizar.

Algoritmos de planificación

FCFS — First Come, First Served (Primero en llegar, primero en ser atendido)

• El proceso que llega antes a la cola de listos es el primero en ejecutarse.
• No preventivo: un proceso no es expulsado de la CPU hasta que termina o se bloquea.
• Ventaja: simple de implementar y sin inanición (todo proceso acaba ejecutando).
• Inconveniente: efecto convoy. Si llega primero un proceso largo, todos los cortos esperan.

Ejemplo:

Con FCFS: P1 ejecuta de t=0 a t=24, P2 de t=24 a t=27, P3 de t=27 a t=30.
- Tiempo de espera: P1=0, P2=23, P3=25. Media = 16 ms. (muy alto por el efecto convoy)

SJF — Shortest Job First (Trabajo más corto primero)

• Se selecciona el proceso con la ráfaga de CPU más corta.
• Óptimo teórico en cuanto a tiempo de espera medio, pero en la práctica no se puede conocer de antemano la duración de la siguiente ráfaga.
• Puede causar inanición (starvation) de procesos largos si siguen llegando procesos cortos.
• Versión preventiva: SRTF (Shortest Remaining Time First). Si llega un proceso con ráfaga más corta que el tiempo restante del proceso en ejecución, se expulsa al actual.

Planificación por prioridades

• A cada proceso se le asigna un número de prioridad; la CPU se da al proceso de mayor prioridad.
• Puede ser preventiva o no preventiva.
• Problema: inanición de procesos de baja prioridad.
• Solución: envejecimiento (aging). La prioridad de un proceso aumenta gradualmente cuanto más tiempo lleva esperando.

Round Robin (RR)

• Cada proceso recibe un quantum de tiempo (típicamente 10-100 ms). Al agotarlo, es expulsado y puesto al final de la cola de listos.
• Preventivo por diseño.
• Justo: ningún proceso espera más de (n-1) × quantum si hay n procesos.
• El rendimiento depende críticamente del quantum:
• Quantum muy pequeño → muchos cambios de contexto → overhead elevado.
• Quantum muy grande → se convierte en FCFS.
• Es el algoritmo base de los SO de propósito general modernos (Linux, Windows usan variantes de RR con prioridades).

Ejemplo con quantum = 4 ms:

Orden: P1(4ms) → P2(4ms) → P3(4ms) → P1(4ms) → P3(1ms) → P1(2ms)
Todos los procesos avanzan equitativamente.

Multilevel Queue (Cola multinivel)

• La cola de listos se divide en varias colas según la naturaleza del proceso: procesos interactivos (primer plano), procesos batch (segundo plano), procesos del sistema, etc.
• Cada cola tiene su propio algoritmo (RR para interactivos, FCFS para batch).
• Los procesos no se mueven entre colas.

Multilevel Feedback Queue (Cola multinivel con retroalimentación)

• Como Multilevel Queue pero los procesos pueden moverse entre colas según su comportamiento.
• Si un proceso usa mucho la CPU (ráfagas largas), baja a una cola de menor prioridad.
• Si un proceso espera mucho o hace E/S frecuente (proceso interactivo), sube a una cola de mayor prioridad.
• Es el algoritmo más flexible y el que usan en la práctica los SO modernos (el planificador CFS de Linux y el del scheduler de Windows se inspiran en este concepto).

2.3 Comunicación entre procesos (IPC)

Los procesos necesitan a veces comunicarse o sincronizarse. El SO proporciona mecanismos de IPC (Inter-Process Communication):

Relevancia para el examen: El comando kill de Linux envía señales a procesos. kill -9 PID envía SIGKILL (terminación forzosa); kill -15 PID envía SIGTERM (petición de terminación elegante).

2.4 Sincronización y problemas de concurrencia

Cuando múltiples procesos o hilos comparten datos, pueden surgir problemas graves.

Condición de carrera (Race condition)

Ocurre cuando el resultado de una operación depende del orden de ejecución de los procesos, y ese orden no está controlado.

Ejemplo: Dos procesos leen una variable saldo=100, ambos suman 50, ambos escriben. El resultado debería ser 200, pero como ambos leyeron 100 y sumaron sobre ese valor, ambos escriben 150. Se pierde una actualización.

Sección crítica

Fragmento de código que accede a datos compartidos y que solo puede ejecutar un proceso a la vez. Para protegerla se necesitan tres condiciones:

1. Exclusión mutua: solo un proceso ejecuta la sección crítica a la vez.
2. Progreso: si nadie está en la sección crítica, un proceso que quiera entrar debe poder hacerlo en tiempo finito.
3. Espera acotada: un proceso no puede ser pospuesto indefinidamente.

Deadlock (Interbloqueo)

Situación en que dos o más procesos esperan indefinidamente un recurso que sostiene el otro, por lo que ninguno puede avanzar.

Condiciones de Coffman (se deben cumplir las cuatro simultáneamente para que ocurra un deadlock):

1. Exclusión mutua: los recursos no pueden compartirse.
2. Retención y espera: un proceso retiene al menos un recurso mientras espera otro.
3. Sin desalojo: un recurso no puede ser arrebatado a un proceso; este debe liberarlo voluntariamente.
4. Espera circular: existe una cadena circular de procesos donde cada uno espera un recurso retenido por el siguiente.

Estrategias frente al deadlock:

• Prevención: diseñar el sistema de forma que al menos una de las condiciones de Coffman nunca se cumpla. Ejemplo: si todos los procesos piden todos sus recursos al inicio, eliminas "retención y espera".
• Detección y recuperación: dejar que ocurra, detectarlo mediante un grafo de asignación de recursos y recuperarse (matando algún proceso o arrebatando recursos).
• Evasión (algoritmo del banquero): antes de asignar un recurso, el SO comprueba si el estado resultante es "seguro" (existe una secuencia de ejecución que permite terminar a todos los procesos). Si no, pospone la asignación.
• Ignorarlo (Ostrich algorithm): si los deadlocks son muy raros y el coste de prevenirlos es alto, simplemente se ignoran. Muchos SO de propósito general (¡incluyendo Linux y Windows en ciertos contextos!) adoptan esta postura en la práctica.

Starvation (Inanición)

Un proceso espera indefinidamente porque siempre hay otros de mayor prioridad que se adelantan. No es un bloqueo pero el proceso nunca progresa. Solución: envejecimiento (aging).

2.5 Gestión de memoria

Objetivos

El gestor de memoria del SO tiene que conseguir simultáneamente:
- Relocalización: un proceso puede ejecutarse en cualquier parte de la RAM sin importar en qué dirección fue compilado.
- Protección: un proceso no puede acceder a la memoria de otro.
- Compartición: a veces se quiere que dos procesos compartan código (librerías compartidas) sin duplicarlo.
- Organización lógica: los programas se organizan en módulos; la memoria debe soportar esta estructura.

Jerarquía de memoria

La memoria no es un bloque homogéneo. Existe una jerarquía ordenada por velocidad y coste:

  Más rápido, más caro, menos capacidad
  ┌──────────────┐
  │  Registros   │  ~1 ns    ~KB
  ├──────────────┤
  │ Caché L1/L2  │  ~5 ns    ~MB
  ├──────────────┤
  │ RAM (DRAM)   │  ~100 ns  ~GB
  ├──────────────┤
  │    Disco     │  ~10 ms   ~TB
  └──────────────┘
  Más lento, más barato, más capacidad

Memoria virtual

La memoria virtual es la ilusión creada por el SO de que cada proceso tiene acceso a una cantidad de memoria mucho mayor que la RAM física disponible. Los procesos trabajan con direcciones virtuales que el hardware (MMU) traduce a direcciones físicas.

Ventajas:
- Cada proceso cree tener para sí toda la memoria del sistema.
- Los procesos están protegidos entre sí.
- Se pueden ejecutar procesos más grandes que la RAM física.

Paginación

La memoria se divide en bloques de tamaño fijo llamados páginas (en el espacio del proceso) y marcos de página (en la RAM física). El tamaño típico es 4 KB.

El SO mantiene una tabla de páginas por proceso que mapea cada página virtual a su marco físico:

Dirección virtual: [ número de página | desplazamiento ]
                           │
                    tabla de páginas
                           │
                           ▼
Dirección física:  [ número de marco  | desplazamiento ]

La MMU (Memory Management Unit) es el componente hardware que realiza esta traducción en cada acceso a memoria.

El TLB (Translation Lookaside Buffer) es una caché hardware muy rápida de las traducciones más recientes de la tabla de páginas. Si la dirección buscada está en el TLB (TLB hit), la traducción es instantánea. Si no (TLB miss), hay que consultar la tabla de páginas en RAM, lo que es más lento.

Fallo de página (Page fault)

Si la página a la que accede el proceso no está en RAM (está en disco, en el área de intercambio o swap), se produce un fallo de página. El SO:

1. Para la ejecución del proceso.
2. Encuentra el marco libre (o libera uno usando un algoritmo de reemplazo).
3. Carga la página desde disco a RAM.
4. Actualiza la tabla de páginas.
5. Reanuda el proceso.

Este mecanismo permite que procesos más grandes que la RAM puedan ejecutarse, pero si hay demasiados fallos de página el sistema se ralentiza enormemente (thrashing: el SO pasa más tiempo gestionando páginas que ejecutando código).

Algoritmos de reemplazo de páginas

Cuando no hay marcos libres y hay que cargar una página, el SO debe elegir qué página expulsar:

Segmentación

Alternativa a la paginación donde la memoria se divide en segmentos de tamaño variable con significado lógico (segmento de código, de datos, de pila). Las direcciones virtuales tienen la forma [segmento:desplazamiento].

Diferencia clave con paginación:
- Paginación: bloques de tamaño fijo, transparente al programador, eficiente.
- Segmentación: bloques de tamaño variable, visible al programador, permite protección por segmento.

Los procesadores x86 modernos combinan ambos (segmentación + paginación), aunque en la práctica los SO modernos usan paginación plana (segmentos que cubren todo el espacio de direcciones).

Swapping

El SO puede mover un proceso completo desde RAM al disco para liberar espacio, y traerlo de vuelta cuando sea necesario. Diferente del paging (que trabaja con páginas individuales); el swapping trabaja con procesos completos. Es muy lento y solo se usa en situaciones de emergencia de memoria.

2.6 Gestión de entrada/salida (E/S)

Tipos de dispositivos

• Dispositivos de bloque: almacenan y transfieren datos en bloques de tamaño fijo. Permiten acceso aleatorio. Ejemplos: discos duros, SSDs, pendrives.
• Dispositivos de carácter: transfieren datos byte a byte de forma secuencial. Ejemplos: teclado, ratón, puerto serie, terminales.
• Dispositivos de red: caso especial; no encajan bien en ninguna de las dos categorías anteriores.

Drivers (controladores de dispositivo)

Un driver es software específico para un dispositivo hardware que traduce las llamadas genéricas del SO (read, write, open...) a los comandos específicos del hardware. Corre en modo kernel.

El SO presenta a las aplicaciones una interfaz uniforme (las mismas llamadas al sistema para cualquier dispositivo), mientras que cada driver implementa internamente esa interfaz de forma específica para su hardware.

Técnicas de E/S

E/S programada (Polling)

La CPU espera activamente a que el dispositivo termine (comprueba repetidamente un registro de estado). Muy ineficiente: la CPU no puede hacer otra cosa mientras espera. Solo aceptable para dispositivos muy rápidos.

E/S por interrupciones

El proceso que pide la E/S se bloquea. Cuando el dispositivo termina, genera una interrupción hardware que fuerza al procesador a ejecutar una rutina de servicio de interrupción (ISR). La ISR desbloquea el proceso. La CPU queda libre para ejecutar otros procesos mientras tanto. Eficiente para la mayoría de los casos.

DMA (Direct Memory Access)

Para transferencias grandes de datos (lectura de un fichero grande del disco), hacer que la CPU transfiera byte a byte es ineficiente incluso con interrupciones.

El controlador DMA es hardware especializado que puede transferir bloques de datos directamente entre el dispositivo y la RAM sin intervención de la CPU. La CPU solo inicia la transferencia y recibe una interrupción al final.

Sin DMA: Disco → CPU → RAM (la CPU trabaja todo el tiempo)
Con DMA: Disco → DMA → RAM (la CPU solo interviene al inicio y al final)

Buffering, Spooling y Caching

• Buffering: almacén temporal en RAM para suavizar diferencias de velocidad entre el SO y los dispositivos. Ejemplo: al leer un fichero, el SO lee un bloque mayor del necesario y lo guarda en buffer; las siguientes lecturas pueden servirse del buffer sin ir a disco.

• Spooling (Simultaneous Peripheral Operations Online): técnica donde los trabajos destinados a un dispositivo lento (como una impresora) se almacenan en disco. El SO los va enviando a la impresora de uno en uno en segundo plano. Permite que varios usuarios "impriman" a la vez sin bloquearse.

• Caching de E/S: copias en RAM de datos recientemente accedidos del disco (page cache en Linux). Si el mismo dato se vuelve a pedir, se sirve desde la caché sin acceder al disco.

2.7 Gestión del sistema de archivos

Conceptos fundamentales

• Archivo: unidad lógica de almacenamiento. Colección de información relacionada con un nombre. Puede ser texto, binario, ejecutable...
• Directorio: estructura que organiza archivos y otros directorios (jerárquicamente). En Linux, todo parte del directorio raíz /.
• Metadatos: información sobre el archivo (nombre, tamaño, fecha de creación/modificación, propietario, permisos). Almacenados en el inodo en sistemas Unix.
• Inodo: estructura de datos en ext4/NTFS que contiene todos los metadatos de un fichero y los punteros a los bloques de disco donde están los datos. El nombre del fichero no está en el inodo sino en el directorio.

Principales sistemas de archivos

Journaling

El journaling (registro en diario) protege la integridad del sistema de archivos ante fallos inesperados (corte de luz, cuelgue del sistema). Antes de escribir los datos definitivamente, el SO registra la operación pendiente en un área especial (el journal). Si el sistema falla a mitad de la escritura, al reiniciar el SO puede revisar el journal y completar o deshacer la operación incompleta.

Sin journaling (FAT32): un apagado brusco puede dejar el sistema de archivos corrupto e inconsistente.

Con journaling (NTFS, ext4): la recuperación es mucho más rápida y fiable.

Permisos en Linux (rwx)

En Linux, cada archivo tiene tres conjuntos de permisos:

-rwxr-xr--  1  usuario  grupo  1234  Jun 9 2025  fichero.txt
│└──┴──┴──┘
│  │  │  └── Otros (others): r-- = solo lectura
│  │  └───── Grupo (group): r-x = lectura y ejecución
│  └──────── Propietario (owner): rwx = lectura, escritura, ejecución
└─────────── Tipo: - fichero regular, d directorio, l enlace simbólico

• r (read, 4): leer el contenido del fichero / listar el directorio.
• w (write, 2): modificar el fichero / crear o eliminar ficheros en el directorio.
• x (execute, 1): ejecutar el fichero / acceder al directorio (atravesarlo).

El comando chmod modifica estos permisos. Se puede usar notación simbólica o numérica (octal):

chmod 755 fichero    # rwxr-xr-x
chmod u+x fichero    # añade ejecución al propietario
chmod go-w fichero   # quita escritura a grupo y otros

Relevancia para el examen: chmod es exactamente la pregunta 1.d del examen de la Politécnica.

2.8 Gestión de seguridad

Autenticación

Proceso de verificar la identidad de un usuario o proceso. Métodos:

• Algo que sabes: contraseña, PIN.
• Algo que tienes: token físico, tarjeta inteligente, código TOTP (Time-Based One-Time Password).
• Algo que eres: huella dactilar, reconocimiento facial, iris.

La autenticación multifactor (MFA) combina dos o más de estos factores, como explora la pregunta 2 del examen.

Autorización

Una vez autenticado, la autorización determina qué puede hacer el usuario. Se implementa mediante:

• DAC (Discretionary Access Control): el propietario del recurso decide quién puede acceder (modelo Unix/Windows con permisos rwx y ACLs). Flexible pero puede ser inseguro si los usuarios no gestionan bien sus permisos.
• MAC (Mandatory Access Control): el sistema impone reglas de acceso que los usuarios no pueden modificar. Basado en etiquetas de seguridad. Usado en entornos militares y críticos. SELinux y AppArmor en Linux son implementaciones de MAC.
• RBAC (Role-Based Access Control): los permisos se asignan a roles, y los usuarios se asignan a roles. El modelo más común en entornos empresariales (Active Directory en Windows).

Auditoría

Registro de eventos relevantes de seguridad: accesos, modificaciones de ficheros, cambios de configuración. Fundamental para la detección de intrusiones y la investigación forense.

Relevancia para el examen: El comando sudo (pregunta 1.b) es el mecanismo de Linux para ejecutar comandos con privilegios de superusuario de forma controlada y auditada. Cada uso de sudo queda registrado en /var/log/auth.log.

3. ESTRUCTURA INTERNA DEL SO: EL KERNEL

3.1 Modo usuario vs modo kernel

El procesador opera en dos modos distintos:

• Modo usuario (user mode): nivel de privilegios restringido. Las aplicaciones no pueden acceder directamente al hardware ni a la memoria de otros procesos. Un fallo en este modo solo afecta al proceso que lo causó.

• Modo kernel (kernel mode / supervisor mode): nivel de privilegios máximo. El SO puede ejecutar cualquier instrucción y acceder a cualquier dirección de memoria. Un fallo en este modo puede tumbar todo el sistema (pantalla azul en Windows, kernel panic en Linux).

3.2 Llamadas al sistema (System Calls)

Las llamadas al sistema son la interfaz entre las aplicaciones (modo usuario) y el kernel (modo kernel). Cuando una aplicación necesita un servicio del kernel (leer un fichero, crear un proceso, abrir un socket...), realiza una system call.

Mecanismo:

Aplicación (modo usuario)
    │
    │  1. La aplicación invoca la system call con sus parámetros
    │     (p.ej. read(fd, buffer, size))
    ▼
  Instrucción TRAP (syscall / int 0x80)
    │  2. El procesador cambia a modo kernel y salta al manejador de syscalls
    ▼
Kernel del SO (modo kernel)
    │
    │  3. El kernel verifica los parámetros y ejecuta la operación solicitada
    │     (lee del disco, comprueba permisos, etc.)
    ▼
  Retorno al modo usuario
    │  4. El kernel devuelve el resultado y el procesador vuelve a modo usuario
    ▼
Aplicación (modo usuario) — continúa con el resultado

Tipos de llamadas al sistema:

Los comandos Linux touch, pwd, chmod y kill de la pregunta 1 del examen son programas de usuario que internamente realizan estas llamadas al sistema.

3.3 Arquitecturas del kernel

Kernel monolítico

Todo el código del SO (gestión de procesos, memoria, sistemas de archivos, drivers, redes) reside en un único bloque que ejecuta completamente en modo kernel.

┌─────────────────────────────────────────────┐
│              KERNEL MONOLÍTICO               │
│  Procesos | Memoria | FS | Drivers | Redes  │
└─────────────────────────────────────────────┘
              Hardware

• Ventaja: comunicación directa entre componentes → muy rápido.
• Inconveniente: un bug en cualquier driver puede causar kernel panic.
• Ejemplos: Linux (aunque permite módulos cargables en tiempo de ejecución, que es una ventaja híbrida), versiones antiguas de UNIX.

Microkernel

El kernel solo incluye las funciones más esenciales: gestión básica de memoria (espacio de direcciones) y comunicación entre procesos (IPC). Todo lo demás (drivers, sistema de archivos, pila de red) corre en modo usuario como procesos servidores.

┌──────────────────────────────────────────┐  Modo usuario
│  Servidor FS  | Servidor Red | Drivers   │
└──────────────────────────────────────────┘
┌──────────────────────────────────────────┐  Modo kernel
│      Micro-kernel: IPC + memoria básica  │
└──────────────────────────────────────────┘
              Hardware

• Ventaja: mayor estabilidad (un driver que falla no tira el kernel) y mayor seguridad.
• Inconveniente: comunicación entre componentes vía IPC → más lento (cambios de contexto constantes entre modo usuario y kernel).
• Ejemplos: Minix 3, QNX, L4, Mach (base de macOS).

Kernel híbrido

Combina el núcleo pequeño del microkernel con algunos servicios en modo kernel por rendimiento. En la práctica, la mayoría de los SO modernos son híbridos.

• Windows NT/10/11: diseñado con filosofía de microkernel pero con muchos subsistemas en modo kernel por rendimiento. Híbrido pragmático.
• macOS (XNU): combina el microkernel Mach con componentes de BSD en modo kernel.

Exokernel

Arquitectura experimental donde el kernel apenas abstrae el hardware: lo expone directamente a las aplicaciones con controles de seguridad mínimos. Las aplicaciones gestionan directamente sus propios recursos. Máximo rendimiento teórico pero enorme complejidad para el programador. Principalmente en investigación.

4. INTERFAZ DE USUARIO DEL SO

4.1 CLI (Command Line Interface)

Interfaz de texto donde el usuario introduce comandos. El componente que interpreta estos comandos se llama shell.

Ventajas del CLI:
- Mucho más potente para administración: scripts, automatización, acceso remoto (SSH).
- Menor consumo de recursos.
- Precisión y reproducibilidad (un script hace exactamente lo mismo siempre).

Inconvenientes:
- Curva de aprendizaje pronunciada.
- No intuitivo para usuarios no técnicos.

4.2 GUI (Graphical User Interface)

Interfaz gráfica con ventanas, iconos y ratón. Más accesible para el usuario general.

Ventajas del GUI:
- Intuitivo y accesible.
- Adecuado para tareas creativas (edición de imágenes, video...).

Inconvenientes:
- Mayor consumo de recursos.
- Menos eficiente para administración masiva.
- Difícil de automatizar.

4.3 Shells en Linux/Unix

El shell es el intérprete de comandos que lee las instrucciones del usuario, las analiza y las ejecuta llamando a los programas correspondientes mediante system calls.

4.4 Shells en Windows

4.5 Comandos Linux fundamentales (relevantes para el examen)

Tal y como aparece en la pregunta 1 del examen de la Politécnica, estos son sus significados:

5. ARRANQUE DEL SISTEMA (BOOT)

5.1 BIOS vs UEFI

Cuando enciendes un ordenador, antes de que el SO arranque, hay un firmware que inicializa el hardware.

BIOS (Basic Input/Output System):
- Firmware tradicional, existe desde los años 80.
- Almacenado en un chip ROM de la placa base.
- Limitado a discos de hasta 2 TB (usa tablas de partición MBR con direcciones de 32 bits).
- Solo puede arrancar desde el primer sector del disco (MBR, 512 bytes).
- Sin interfaz gráfica, solo texto.

UEFI (Unified Extensible Firmware Interface):
- Sucesor moderno de BIOS, estándar desde ~2010.
- Soporte para discos mayores de 2 TB (usa GPT, tabla de particiones GUID con 64 bits).
- Interfaz gráfica, soporte para ratón.
- Secure Boot: verifica criptográficamente la firma digital del bootloader antes de ejecutarlo, impidiendo la ejecución de malware en el arranque (bootkits).
- Arranque más rápido.

5.2 MBR vs GPT

5.3 Proceso de arranque completo

1. [ENCENDIDO] La CPU empieza a ejecutar desde la dirección del firmware (BIOS/UEFI)

2. [POST] Power-On Self Test: el firmware verifica la RAM, CPU, dispositivos...

3. [LOCALIZA EL BOOTLOADER] 
   - BIOS: lee el primer sector del disco (MBR) donde está el código de arranque
   - UEFI: busca en la partición EFI (ESP) el bootloader registrado

4. [BOOTLOADER] (GRUB en Linux, Windows Boot Manager en Windows)
   - Presenta menú de arranque si hay varios SO
   - Carga el kernel del SO en memoria y lo ejecuta

5. [KERNEL] 
   - Inicializa los subsistemas internos (memoria, procesos, drivers)
   - Monta el sistema de archivos raíz
   - Lanza el primer proceso de usuario

6. [INIT / SYSTEMD] (Linux) o [Session Manager] (Windows)
   - Lanza todos los servicios y daemons del sistema
   - Presenta la pantalla de login

7. [LOGIN] El usuario se autentica y accede al escritorio o shell

6. EVOLUCIÓN HISTÓRICA DE LOS SO

Primera generación (1945–1955): sin sistema operativo

Los primeros ordenadores (ENIAC, UNIVAC) se programaban directamente en hardware mediante conexión de cables (plugboards) o tarjetas perforadas. No existía el concepto de SO. Cada programa tenía control absoluto del hardware. Un solo trabajo a la vez. Enormes y carísimos.

Segunda generación (1955–1965): sistemas de procesamiento por lotes (batch)

Aparecen los transistores y los primeros ordenadores comerciales (IBM 701, 1401). Los trabajos (jobs) se agrupan en lotes de tarjetas perforadas y se procesan secuencialmente. Surge el monitor residente: un pequeño programa que carga automáticamente el siguiente trabajo cuando el anterior termina. Es el precursor del SO. Problema: la CPU queda ociosa mientras el lector de tarjetas o la impresora trabajan.

Tercera generación (1965–1980): multiprogramación y tiempo compartido

IBM lanza el System/360 (1964): la primera familia de ordenadores con una arquitectura unificada. El SO OS/360 introduce la multiprogramación: varios trabajos residen en memoria, y cuando uno espera E/S, la CPU ejecuta otro. Aprovechamiento radical de la CPU.

El tiempo compartido (time-sharing) lleva esto más lejos: múltiples usuarios conectados por terminales (teletipo) usan el mismo ordenador de forma interactiva, con la ilusión de que cada uno tiene el ordenador para sí. El SO de referencia de esta era es MULTICS (1969), y de él nace UNIX ese mismo año, creado por Ken Thompson y Dennis Ritchie en los laboratorios Bell de AT&T. UNIX sentará las bases de todos los SO modernos.

Cuarta generación (1980–2000): PC y GUI

Los microprocesadores hacen los ordenadores accesibles para particulares. Apple presenta el Apple II (1977) y el Macintosh (1984), con interfaz gráfica revolucionaria. Microsoft lanza MS-DOS (1981) para el IBM PC, un SO simple de línea de comandos.

En 1991 Linus Torvalds publica el kernel Linux, que junto con las herramientas GNU de Richard Stallman forma el primer SO libre y de código abierto completo. Windows NT (1993) introduce una arquitectura moderna de 32 bits con kernel híbrido, que es la base de todos los Windows actuales.

Quinta generación (2000–presente): internet, móviles, nube y contenedores

Los SO se rediseñan para la era en red. Windows Server, distribuciones Linux para servidores (Red Hat, Debian). La virtualización con VMware (1998) y luego KVM y Hyper-V revolucionan los centros de datos. Android (2008, basado en Linux) e iOS (2007, basado en Darwin/BSD) crean el ecosistema móvil. Docker (2013) y Kubernetes (2014) transforman el despliegue de aplicaciones. El SO se convierte en infraestructura efímera y automatizable.

7. TIPOS DE SISTEMAS OPERATIVOS

7.1 SO de propósito general

Diseñados para ejecutar una gran variedad de aplicaciones. Optimizan el throughput medio y la experiencia interactiva. Ejemplos: Windows 11, Ubuntu Linux, macOS.

7.2 SO de tiempo real (RTOS)

Hard real-time: las respuestas deben producirse dentro de plazos estrictos e inviolables. Un fallo en el plazo es un fallo del sistema. Ejemplos de uso: sistemas de control de aviones, centralitas nucleares, frenos ABS, marcapasos.

Soft real-time: se prefiere respetar los plazos pero ocasionalmente superarlos no es catastrófico. Ejemplos: streaming de vídeo, videoconferencia, sistemas de audio.

Características de un RTOS: planificador determinista, latencias predecibles, sin paginación (podría causar fallos de página impredecibles), sin garbage collection.

Ejemplos: FreeRTOS, VxWorks, QNX, Zephyr.

7.3 SO embebidos

Diseñados para dispositivos con recursos muy limitados (microcontroladores, electrodomésticos, impresoras). Muy ligeros, a menudo sin interfaz de usuario. Pueden ser RTOS o no. Ejemplos: Linux embebido (OpenWRT en routers), RTOS FreeRTOS.

7.4 SO distribuidos

El SO gestiona un conjunto de máquinas interconectadas como si fueran un único sistema. El usuario no sabe en qué máquina se ejecuta su proceso. Transparencia total. Ejemplos históricos: Plan 9, Amoeba. En la práctica moderna: los clústeres de Kubernetes son una forma de computación distribuida, aunque el SO subyacente sigue siendo Linux en cada nodo.

7.5 SO de red vs SO distribuido

• SO de red: cada máquina tiene su propio SO; el SO de red añade servicios para compartir recursos (ficheros, impresoras) en red. Los usuarios conocen la ubicación de los recursos. Ejemplo: Windows Server con recursos compartidos, NFS en Linux.
• SO distribuido: los recursos se gestionan globalmente; los usuarios no saben dónde están físicamente.

8. SISTEMAS OPERATIVOS MÁS RELEVANTES

8.1 UNIX

Creado en 1969 por Ken Thompson y Dennis Ritchie en los Bell Labs de AT&T. Escrito en C (lenguaje creado por los mismos autores), lo que le dio portabilidad entre arquitecturas hardware: algo revolucionario para la época.

Filosofía UNIX:
- Cada programa hace una sola cosa y la hace bien.
- Los programas se pueden encadenar mediante tuberías (pipes): la salida de uno es la entrada del siguiente (ls -l | grep .txt | wc -l).
- Todo es un fichero (dispositivos, procesos en /proc, sockets...).
- Preferencia por interfaces de texto.

8.2 Linux

Kernel creado por Linus Torvalds en 1991, publicado bajo licencia GPL (software libre). Combinado con las herramientas GNU de Richard Stallman, forma el sistema GNU/Linux.

Arquitectura: kernel monolítico modular. El núcleo es monolítico en arquitectura, pero los drivers y módulos pueden cargarse y descargarse en caliente (insmod, rmmod, modprobe) sin reiniciar. Esto combina el rendimiento del monolítico con la flexibilidad de los módulos.

Principales distribuciones:

8.3 Windows

Arquitectura NT: el kernel de Windows NT (y todos sus sucesores: XP, Vista, 7, 8, 10, 11, Server) está basado en un diseño híbrido inspirado en los microkernels. Tiene:

• Modo kernel: HAL (Hardware Abstraction Layer), kernel ejecutivo (gestión de procesos, memoria, objetos, E/S), drivers.
• Modo usuario: subsistemas de entorno (Win32, POSIX...), servicios del sistema, aplicaciones.

Active Directory (AD): servicio de directorio de Microsoft para gestionar centralizadamente usuarios, equipos y políticas de seguridad en redes corporativas. Es la pieza central de la administración de entornos Windows empresariales. Permite autenticación centralizada (Kerberos), políticas de grupo (GPO), asignación de recursos, etc.

8.4 macOS

Basado en Darwin, que combina el microkernel Mach (de la Universidad Carnegie Mellon) con componentes del sistema BSD (Berkeley Software Distribution). Kernel híbrido llamado XNU. POSIX-compliant. Integra la GUI Aqua.

8.5 Android

Sistema operativo móvil de Google basado en el kernel Linux. Arquitectura en capas:

1. Linux Kernel: gestión de hardware, drivers.
2. HAL (Hardware Abstraction Layer): interfaz estándar para el hardware.
3. Android Runtime (ART): máquina virtual que ejecuta apps compiladas a bytecode (DEX).
4. Framework de aplicaciones: APIs de Java para los desarrolladores.
5. Aplicaciones: apps del sistema y de terceros.

8.6 iOS

De Apple. Basado en Darwin (mismo núcleo que macOS). Modelo de seguridad muy estricto: aplicaciones en sandbox, firma de código obligatoria (App Store), arranque seguro (Secure Enclave), cifrado por hardware.

9. VIRTUALIZACIÓN (DESDE LA PERSPECTIVA DEL SO)

9.1 Concepto

La virtualización abstrae los recursos hardware para permitir que múltiples SO ejecuten simultáneamente sobre el mismo hardware físico. Cada instancia de SO cree tener el hardware para sí sola.

9.2 Hipervisores

El hipervisor (o VMM, Virtual Machine Monitor) es el software que crea y gestiona las máquinas virtuales.

Tipo 1 (bare metal): el hipervisor ejecuta directamente sobre el hardware, sin SO huésped entre medias. Más eficiente y seguro. Uso en producción y centros de datos. Ejemplos: VMware ESXi, Microsoft Hyper-V, Citrix XenServer, KVM (Linux).

Tipo 2 (hosted): el hipervisor es una aplicación más que corre sobre un SO convencional. Más fácil de instalar pero con más overhead. Uso en desarrollo y pruebas. Ejemplos: VirtualBox, VMware Workstation.

9.3 Diferencia fundamental VM vs Contenedor

10. TENDENCIAS ACTUALES EN SO

10.1 Contenedores y orquestación

Docker (2013) popularizó los contenedores Linux. Un contenedor empaqueta la aplicación con todas sus dependencias en una imagen portable, garantizando que funciona igual en cualquier entorno.

Kubernetes (2014, Google) orquesta miles de contenedores: los distribuye entre nodos, los reinicia si fallan, los escala según la carga, gestiona el tráfico de red entre ellos. El SO moderno de servidor es cada vez más la base sobre la que corre Kubernetes.

10.2 Sistemas operativos inmutables

El SO arranca desde una imagen de solo lectura verificada. Las actualizaciones reemplazan la imagen completa de forma atómica (se aplica la nueva imagen y se reinicia; si falla, se vuelve a la anterior). Ventajas: no hay "configuration drift", mayor seguridad, reproducibilidad total.

Ejemplos: Fedora CoreOS (diseñado para ejecutar contenedores), Talos Linux (SO para nodos Kubernetes, sin acceso shell), Flatcar Linux, ChromeOS.

10.3 Seguridad avanzada integrada en el SO

• Secure Boot (UEFI): el firmware verifica la firma criptográfica del bootloader y el kernel antes de ejecutarlos. Impide bootkits y rootkits que se cargan antes que el SO.
• TPM (Trusted Platform Module): chip hardware que almacena claves criptográficas de forma segura, certifica el estado del sistema (attestation) y habilita funciones como BitLocker (cifrado de disco en Windows).
• Zero Trust: modelo de seguridad donde ningún proceso, usuario ni dispositivo es de confianza por defecto, independientemente de si está dentro o fuera de la red corporativa. El acceso siempre requiere verificación explícita.
• eBPF (extended Berkeley Packet Filter): tecnología del kernel Linux que permite ejecutar programas seguros y verificados directamente en el kernel sin modificarlo. Se usa para observabilidad, seguridad y redes con rendimiento extremo.

10.4 Edge Computing e IoT

Millones de dispositivos (sensores, cámaras, vehículos autónomos) procesan datos localmente en lugar de enviarlos todos a la nube. Necesitan SO ligeros y a menudo con garantías de tiempo real. Sistemas como Zephyr RTOS, FreeRTOS, y versiones mínimas de Linux construidas con Yocto Project están diseñados para estos entornos con RAM de KB y procesadores a MHz.

10.5 Inteligencia Artificial integrada en el SO

• Gestión predictiva de recursos: el SO anticipa las necesidades de CPU y RAM para optimizar el rendimiento.
• Detección de anomalías: el SO identifica comportamientos anómalos de procesos (posibles malware o fallos).
• Asistentes con lenguaje natural integrados en el SO.

10.6 Observabilidad nativa

Los SO modernos incorporan infraestructura de observabilidad de primera clase:
- Logs estructurados: systemd-journald en Linux genera logs estructurados (JSON) consultables con journalctl.
- Métricas del kernel: mediante eBPF se pueden extraer métricas del kernel en tiempo real.
- Trazas distribuidas: herramientas como OpenTelemetry integran el SO en sistemas de observabilidad distribuida.

11. TABLA RESUMEN DE COMPARATIVAS PARA EXAMEN

12. CONEXIÓN CON LAS PREGUNTAS DEL EXAMEN

Fin del Tema 1 — Conceptos de Sistemas Operativos