Nota de estudio: Esta parte cierra el Tema 1 con los conceptos más "de arquitectura": qué tipos de SO existen y cuándo usar cada uno, cómo funcionan en detalle los SO que más aparecen en el mundo real (Linux, Windows, Android), virtualización completa (VMs, contenedores, hipervisores) y las tendencias que están redefiniendo el sector. Conecta directamente con preguntas sobre Wake-on-LAN (Q3), switches y redes (Q4, Q10), VPNs (Q5) y almacenamiento (Q8) del examen de la Politécnica, porque todos esos temas dependen de entender en qué tipo de entorno (servidor, embebido, nube, virtualizado) trabaja el SO.
Los SO no son todos iguales ni sirven para lo mismo. La clasificación por tipo es fundamental para elegir el SO correcto para cada escenario, lo cual es una pregunta habitual en exámenes de administración de sistemas.
Diseñados para ejecutar una gran variedad de aplicaciones heterogéneas en hardware convencional. Optimizan la experiencia interactiva del usuario y el throughput medio, sin garantías estrictas sobre tiempos de respuesta.
Características:
- Multitarea preventiva con planificación de prioridades dinámicas.
- Memoria virtual con paginación bajo demanda.
- Interfaz gráfica y/o de línea de comandos.
- Amplia compatibilidad de drivers y aplicaciones.
- Actualizaciones frecuentes del SO y aplicaciones.
Compromiso de diseño: se optimiza para el caso promedio, no para el peor caso. Si el sistema está bajo carga alta, un proceso puede tener que esperar decenas o cientos de milisegundos para obtener CPU. Esto es aceptable para un navegador web o un procesador de texto, pero inaceptable para el sistema de control de un avión.
Ejemplos y su nicho:
- Windows 11: escritorio corporativo y doméstico. Ecosistema de aplicaciones muy amplio, especialmente software empresarial y de diseño.
- Ubuntu Linux (escritorio): desarrollo de software, entornos científicos, servidores.
- macOS: diseño gráfico, vídeo, música, desarrollo para ecosistema Apple.
- Ubuntu/RHEL/Debian Server: servidores web, bases de datos, infraestructura cloud.
Un RTOS no es necesariamente más rápido que un SO de propósito general; es predecible y determinista. La diferencia no es la velocidad media sino la garantía del tiempo de respuesta en el peor caso.
Las tareas deben completarse dentro de sus plazos (deadlines). Superar el plazo, aunque sea por un milisegundo, se considera un fallo del sistema. No hay tolerancia.
Ejemplos de aplicaciones:
- Frenos ABS: si el sistema de control tarda más del plazo en responder a un bloqueo de rueda, el coche puede perder el control. Un fallo en el plazo puede costar vidas.
- Marcapasos: el impulso eléctrico debe generarse exactamente en el instante correcto. Un retardo puede causar fibrilación ventricular.
- Control de vuelo fly-by-wire: los actuadores de las superficies de control deben responder en microsegundos a las entradas del piloto o al piloto automático.
- Robots industriales: los movimientos deben estar perfectamente sincronizados para evitar colisiones o productos defectuosos.
- Sistemas de armas: misiles guiados, radares.
¿Por qué un SO de propósito general NO sirve para hard real-time?
- La paginación puede introducir fallos de página imprevisibles (decenas de milisegundos de latencia para cargar la página desde disco).
- El garbage collector (en lenguajes gestionados como Java o C#) puede pausar todos los hilos durante periodos impredecibles.
- Las interrupciones del hardware pueden desplazar tareas críticas.
- El planificador CFS de Linux no garantiza latencias máximas acotadas.
- El propio kernel puede tener secciones con interrupciones desactivadas durante periodos variables.
Las tareas deberían completarse dentro de sus plazos, pero superarlos ocasionalmente es tolerable y no implica un fallo del sistema, solo una degradación de calidad.
Ejemplos:
- Streaming de vídeo: si un frame no se renderiza a tiempo, se salta o se muestra con baja calidad. El usuario nota una pérdida de fluidez, pero no es catastrófico.
- Videoconferencia: un paquete de audio tardío causa un breve corte, no un fallo del sistema.
- Sistemas de audio (DAW): si el buffer de audio no se llena a tiempo, hay un "glitch" (clic o silencio breve). Molesto pero tolerable.
- Juegos online: la latencia alta degrada la experiencia pero no "rompe" el juego.
Los SO de propósito general pueden cumplir soft real-time con la configuración adecuada (kernel RT-Preempt en Linux, ajuste de prioridades, reducción de swapping).
Planificador determinista: el planificador de un RTOS debe garantizar que la tarea de mayor prioridad ejecuta dentro de un tiempo máximo conocido tras ser activada. Típicamente se usa planificación por prioridades estrictas preventiva (Rate Monotonic, EDF).
Rate Monotonic Scheduling (RMS): algoritmo clásico de RTOS. Las tareas más frecuentes (menor período) reciben mayor prioridad. Teóricamente óptimo para tareas periódicas con plazos iguales a su período.
EDF (Earliest Deadline First): la tarea con el plazo más próximo recibe la CPU. Óptimo en términos de utilización de CPU pero más complejo de implementar.
Sin paginación a disco: la memoria de las tareas críticas está siempre en RAM (locked pages). No puede haber fallos de página durante la ejecución de tareas de tiempo real. En Linux, mlockall(MCL_CURRENT | MCL_FUTURE) previene que las páginas de un proceso sean paginadas a swap.
Latencias de interrupción acotadas: el tiempo desde que el hardware genera una interrupción hasta que la ISR correspondiente empieza a ejecutar debe estar garantizado. En FreeRTOS: <1 μs típico. En VxWorks: similar. En Linux con RT-Preempt: ~20-50 μs (suficiente para soft real-time, borderline para hard real-time).
Prioridad de inversión: problema clásico de RTOS. Una tarea de alta prioridad espera a una de baja prioridad que retiene un recurso compartido (mutex), mientras una de media prioridad se ejecuta. La alta queda "invertida" por la media. Solución: herencia de prioridad (la tarea de baja prioridad hereda temporalmente la prioridad de la alta hasta que libera el recurso).
Ejemplos de RTOS:
| RTOS | Uso principal | Características |
|---|---|---|
| FreeRTOS | IoT, microcontroladores (Arduino, ESP32) | Open source, muy ligero (~10 KB ROM), ampliamente usado |
| VxWorks | Aeroespacial, defensa, automoción | Certificado para sistemas críticos (DO-178C, IEC 61508) |
| QNX | Automoción (infotainment, ADAS), médico | Microkernel, certificado, Unix-like |
| Zephyr | IoT, wearables | Open source (Linux Foundation), muy modular |
| RTEMS | Aeroespacial (NASA, ESA) | Usado en sondas espaciales y satélites |
| Linux RT-Preempt | Industrial, soft real-time | Parche del kernel Linux para reducir latencias |
Un sistema embebido es un sistema informático diseñado para realizar una función específica, integrado dentro de un dispositivo mayor. Sus recursos son radicalmente más limitados que un PC: desde microcontroladores con 2 KB de RAM hasta procesadores ARM con 512 MB.
Características que los distinguen:
- Recursos muy limitados: RAM en KB o pocos MB, almacenamiento en flash (sin disco duro).
- Función específica: no son de propósito general; hacen una cosa concreta.
- A menudo sin interfaz de usuario (o con una muy básica: pantalla LCD simple, LEDs).
- Funcionamiento continuo: muchos sistemas embebidos deben funcionar 24/7 durante años sin reiniciarse.
- Arranque rápido: un router o una cámara IP no puede tardar minutos en arrancar.
- Bajo consumo energético: especialmente en dispositivos con batería.
Espectro de SO embebidos:
En el extremo más ligero (microcontroladores con KB de RAM): FreeRTOS, Zephyr, o incluso código "bare metal" sin SO.
En el extremo más capaz (procesadores ARM con cientos de MB): Linux embebido, que es un kernel Linux configurado con solo los módulos y drivers necesarios, reduciendo el tamaño de imagen de cientos de MB a unos pocos.
Yocto Project: framework para construir distribuciones Linux embebidas personalizadas. Define exactamente qué paquetes, drivers y configuraciones incluir. Usado por Intel, Texas Instruments, y prácticamente todos los fabricantes de hardware que usan Linux embebido.
Buildroot: alternativa más simple a Yocto para crear imágenes Linux embebidas mínimas.
Ejemplos concretos:
| Dispositivo | SO embebido | Características relevantes |
|---|---|---|
| Router doméstico | OpenWRT (Linux embebido) | Kernel Linux + BusyBox (reemplaza 300+ utilidades Unix en un único binario de ~1 MB) |
| Smart TV | Linux embebido o Android TV | Múltiples capas gráficas, gestión de DRM (Digital Rights Management) |
| Impresora de red | Linux embebido o RTOS propietario | Gestión de colas de impresión, protocolo IPP/LPD |
| PLC industrial | RTOS (VxWorks, CODESYS) | Control de maquinaria en tiempo real |
| Cámara IP | Linux embebido (OpenIPC, Buildroot) | Codificación H.264/H.265 en tiempo real |
| Dispositivo médico | RTOS certificado (VxWorks, QNX) | Certificación FDA/CE, trazabilidad, sin actualizaciones no validadas |
| Vehículo Tesla | Linux (infotainment) + RTOS (control) | Dos dominios separados: un Linux para la pantalla, RTOS para el tren motriz |
Herramientas clave para SO embebidos:
- BusyBox: implementa más de 300 utilidades Unix/Linux (ls, cp, mv, grep, ifconfig, wget...) en un único ejecutable de ~1 MB. Indispensable en sistemas con poco almacenamiento.
- U-Boot: bootloader universal para sistemas embebidos ARM, MIPS, PowerPC. Equivalente a GRUB pero para embebido.
- Device Tree: mecanismo para describir el hardware a un kernel Linux genérico sin compilarlo para cada placa concreta. El hardware se describe en un fichero .dts y el kernel lo lee al arrancar.
Un SO distribuido gestiona un conjunto de máquinas interconectadas presentándolas al usuario como si fueran un único sistema. El usuario no necesita saber (ni puede saber fácilmente) en qué máquina física se ejecuta su proceso o dónde están almacenados sus ficheros.
Propiedades que debe proporcionar:
Desafíos únicos:
- Ausencia de reloj global: no existe un reloj perfectamente sincronizado entre todos los nodos. Coordinar el orden de eventos distribuidos requiere algoritmos especiales (relojes de Lamport, vectoriales).
- Fallos parciales: en un SO centralizado, o todo funciona o todo falla. En un SO distribuido, algunos nodos pueden fallar mientras otros siguen funcionando. Hay que diseñar para la falla parcial.
- Latencia de red: la comunicación entre nodos es miles de veces más lenta que la comunicación dentro de un nodo (RAM vs red).
Ejemplos históricos y modernos:
Plan 9 (Bell Labs, 1992): sucesor espiritual de Unix. Todo es un fichero, incluyendo los recursos de otros nodos de la red. Accedes a la pantalla gráfica de otra máquina como si fuera un fichero local en /dev/screen. Extremadamente elegante pero no tuvo éxito comercial.
Amoeba (Andrew Tanenbaum, 1987): SO distribuido de microkernel. Cada objeto (proceso, fichero, dispositivo) tiene una capability (un identificador con permisos criptográficamente protegido) para acceder a él. Muy influyente académicamente.
Kubernetes como SO distribuido moderno: aunque técnicamente Kubernetes es un orquestador de contenedores y no un SO, cumple muchas funciones de un SO distribuido: gestiona recursos entre nodos, programa workloads, gestiona el ciclo de vida de procesos (pods), proporciona transparencia de ubicación (un servicio es accesible por su nombre independientemente de en qué nodo corra).
Esta distinción aparece frecuentemente en exámenes y puede confundirse.
| Aspecto | SO de Red | SO Distribuido |
|---|---|---|
| Visión del sistema | Múltiples máquinas independientes conectadas | Una única máquina lógica distribuida |
| Ubicación de recursos | El usuario CONOCE dónde está cada recurso | El usuario NO SABE (ni necesita saber) dónde está |
| Acceso a recursos remotos | Explícito: el usuario especifica el servidor (\\servidor\carpeta, ssh usuario@host) |
Transparente: el usuario accede como si fuera local |
| Autonomía de los nodos | Cada nodo tiene su propio SO y administración independiente | Los nodos se gestionan como una unidad |
| Fallos | Un fallo en un nodo es visible y afecta solo a ese nodo | Los fallos se ocultan al usuario mediante redundancia |
| Ejemplo | Windows Server con carpetas compartidas (SMB/CIFS), NFS en Linux | Plan 9, Amoeba, (conceptualmente) Kubernetes |
Ejemplo práctico para clarificarlo:
SO de red: en tu empresa, accedes a \\fileserver01\proyectos\informe.docx. Sabes que el fichero está en el servidor fileserver01. Si ese servidor falla, el fichero no está disponible. Tu cliente Windows y el servidor Windows son máquinas autónomas con sus propios SO.
SO distribuido: abres informe.docx desde tu directorio de trabajo. El SO distribuido lo ha replicado en 3 nodos del cluster. No sabes ni importa en cuál de los 3 está "principalmente". Si uno de los nodos falla, el SO distribuido recupera automáticamente el fichero desde los otros dos. Todo transparente.
UNIX nace en 1969 en los Bell Labs de AT&T de la mano de Ken Thompson y Dennis Ritchie. Su contexto: el proyecto MULTICS (Multiplexed Information and Computing Service) había demostrado que un SO extremadamente complejo y ambicioso es prácticamente ingobernable. UNIX fue la reacción: hacer lo mismo pero de forma simple, elegante y modular.
Dennis Ritchie creó el lenguaje C específicamente para reescribir UNIX en un lenguaje de alto nivel pero con acceso a bajo nivel. Antes, los SO se escribían en ensamblador (específico de cada procesador). Al estar UNIX escrito en C, podía portarse a otras arquitecturas simplemente recompilando el código fuente. Esto fue revolucionario: antes de UNIX, cada arquitectura tenía su propio SO incompatible.
Estos principios siguen siendo influyentes en el diseño de software 55 años después:
1. Haz una cosa y hazla bien (Do One Thing Well):
Cada herramienta tiene un propósito específico. ls lista directorios. grep busca patrones. wc cuenta. sort ordena. cut extrae columnas. Ninguna hace todo.
2. Escribe programas para trabajar juntos (Composability):
Las herramientas se combinan mediante tuberías (pipes):
# Contar cuántos usuarios distintos han fallado el login hoy
cat /var/log/auth.log | grep "Failed password" | grep "$(date +%b\ %d)" | \
awk '{print $11}' | sort | uniq -c | sort -rn | head -10
# Cada comando hace una cosa; juntos hacen algo complejo
3. Todo es un fichero (Everything is a File):
Dispositivos, procesos, conexiones de red, configuración del kernel en tiempo de ejecución: todo se expone como una entrada en el sistema de archivos. Esto permite usar las mismas herramientas (cat, echo, dd, chmod, grep...) para interactuar con cosas muy diferentes.
# Leer temperatura de la CPU (es un fichero en /sys)
cat /sys/class/thermal/thermal_zone0/temp
# Ver qué proceso ocupa el PID 1 (es un directorio en /proc)
cat /proc/1/cmdline
# Enviar audio a un dispositivo de audio (es un dispositivo en /dev)
cat audio.raw > /dev/dsp
# Ver los atributos de una interfaz de red
cat /sys/class/net/eth0/speed
4. Usa texto plano (Prefer text streams):
Las herramientas leen y producen texto. Esto las hace componibles: la salida de cualquier programa puede ser la entrada de cualquier otro.
5. Diseña para ser probado:
Los programas Unix son fácilmente testeables porque leen de stdin y escriben a stdout. Se pueden probar pasándoles datos de prueba sin necesidad de un entorno complejo.
UNIX (Bell Labs, 1969-1979)
│
├── BSD (Berkeley, 1977)
│ ├── FreeBSD → pfSense, TrueNAS, PlayStation OS
│ ├── OpenBSD → seguridad extrema
│ ├── NetBSD → portabilidad máxima
│ └── Darwin (Apple) → macOS, iOS, iPadOS, tvOS, watchOS
│
├── System V (AT&T, 1983)
│ ├── Solaris (Sun/Oracle) → ZFS, DTrace, Zones
│ ├── HP-UX (Hewlett-Packard)
│ └── AIX (IBM)
│
└── POSIX (estándar IEEE, 1988)
└── Cualquier SO que implementa la interfaz POSIX es compatible
Linux, macOS, BSD, Solaris, QNX, Cygwin en Windows...
POSIX (Portable Operating System Interface): estándar IEEE que define la interfaz que debe implementar un SO "compatible con Unix". Cubre las llamadas al sistema, el shell, las utilidades básicas y las librerías. Un programa escrito para POSIX puede compilarse y ejecutarse en cualquier SO POSIX-compatible sin modificaciones.
El 25 de agosto de 1991, Linus Torvalds publica en el grupo de noticias comp.os.minix:
"Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones."
Treinta y cuatro años después, Linux corre en:
- El 96,4% de los 1 millón de servidores web más visitados del mundo.
- El 100% de los 500 superordenadores más potentes del mundo.
- Todos los dispositivos Android del mundo (>3.000 millones de dispositivos).
- La infraestructura de AWS, Google Cloud, Azure, y prácticamente cualquier proveedor cloud.
- La Estación Espacial Internacional.
- La mayoría de los routers, switches gestionables y dispositivos de red de nivel empresarial.
┌─────────────────────────────────────────────────────────────┐
│ Espacio de usuario │
│ Aplicaciones │ libc (glibc) │ Shell │ Systemd │ Daemons │
└─────────────────────────────────────────────────────────────┘
↕ Interfaz de llamadas al sistema (syscall table)
┌─────────────────────────────────────────────────────────────┐
│ Kernel Linux │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │Planifica-│ │ Memoria │ │ VFS │ │ Pila de Red │ │
│ │dor (CFS, │ │ Virtual │ │ (Virtual │ │ (TCP/IP, │ │
│ │ RT, BFS) │ │ (VMM) │ │ File Sys)│ │ Netfilter) │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────────┘ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Módulos cargables (drivers, FS, etc.) │ │
│ │ e1000e (Intel Ethernet) │ ext4 │ ahci │ usb │ ... │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
↕ Interfaz con el hardware
┌─────────────────────────────────────────────────────────────┐
│ Hardware: CPU, RAM, Disco, Red, USB, GPU... │
└─────────────────────────────────────────────────────────────┘
VFS (Virtual File System): capa de abstracción que permite al kernel tratar todos los sistemas de archivos (ext4, NTFS, FAT32, NFS, procfs, sysfs...) con la misma interfaz interna. Un programa llama a open() y el VFS redirige la operación al driver del sistema de archivos correcto.
Netfilter: framework del kernel Linux para gestión de paquetes de red. Es la base de:
- iptables / nftables (cortafuegos en Linux).
- NAT (Network Address Translation).
- Filtrado de paquetes.
- Connection tracking (seguimiento de conexiones para cortafuegos stateful).
Conexión con el examen: la pregunta 6 sobre cortafuegos de inspección de paquetes con estado está implementada en Linux mediante Netfilter con connection tracking. En Windows, la función equivalente es Windows Filtering Platform (WFP).
CFS (Completely Fair Scheduler): el planificador por defecto de Linux desde 2007. En lugar de prioridades estáticas y colas multinivel, CFS usa un árbol rojo-negro ordenado por el "tiempo virtual de CPU consumido" por cada proceso. El proceso con menor tiempo virtual acumulado tiene prioridad. Esto garantiza que todos los procesos reciben una cantidad de CPU proporcional a su peso (prioridad nice). Es el planificador más sofisticado de un SO de propósito general.
Systemd: el sistema de init moderno de Linux (PID 1). Gestiona el arranque del sistema, los servicios, los logs (journald), los dispositivos (udevd), la red (networkd), los montajes (systemd-mount), los contenedores (systemd-nspawn) y mucho más. Muy criticado por hacer "demasiadas cosas" (violando la filosofía Unix), pero ampliamente adoptado por su funcionalidad y velocidad de arranque en paralelo.
Las distribuciones son combinaciones del kernel Linux con un conjunto de software de usuario (gestor de paquetes, herramientas, escritorio...). No son SO distintos; son distintas configuraciones del mismo kernel.
Familia Debian:
| Distribución | Ciclo de vida | Caso de uso ideal |
|---|---|---|
| Debian | ~2 años (muy estable, paquetes antiguos) | Servidores que requieren estabilidad máxima; base para otras distros |
| Ubuntu LTS | 2 años (paquetes más recientes que Debian) | Servidores en producción, escritorio empresarial, VMs en AWS |
| Ubuntu regular | 6 meses | Escritorio con software más nuevo |
| Kali Linux | Rolling (siempre actualizado) | Pentesting y seguridad ofensiva; no para producción |
| Raspbian/Raspberry Pi OS | Basado en Debian | Raspberry Pi y hardware embebido ARM |
Familia Red Hat:
| Distribución | Ciclo de vida | Caso de uso ideal |
|---|---|---|
| RHEL | 10 años | Entornos empresariales críticos con soporte comercial |
| CentOS Stream | Rolling | Previsualización de RHEL; no para producción estable |
| Rocky Linux | 10 años | Alternativa gratuita a RHEL 1:1 compatible (post-CentOS) |
| AlmaLinux | 10 años | Ídem, con mayor énfasis en la comunidad |
| Fedora | ~13 meses | Últimas novedades; laboratorio de lo que llegará a RHEL |
| SUSE Linux Enterprise | 10-13 años | Empresas europeas, especialmente con SAP |
Rolling release:
| Distribución | Características | Caso de uso |
|---|---|---|
| Arch Linux | Minimalista, siempre actualizado, DIY | Usuarios avanzados que quieren control total |
| openSUSE Tumbleweed | Rolling con QA riguroso | Escritorio con software muy reciente pero más estable que Arch |
| NixOS | Configuración declarativa, reproducible | DevOps, infraestructura como código |
Todos los Windows modernos (desde NT 3.1 de 1993 hasta Windows 11) comparten la misma arquitectura fundamental:
┌─────────────────────────────────────────────────────────────┐
│ Modo usuario │
│ ┌──────────────┐ ┌────────────────┐ ┌───────────────────┐ │
│ │ Aplicaciones │ │ Subsistema │ │ Servicios del │ │
│ │ Win32/UWP │ │ Win32 (csrss) │ │ sistema (SCM) │ │
│ └──────────────┘ └────────────────┘ └───────────────────┘ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ DLLs del sistema (ntdll.dll, kernel32.dll, │ │
│ │ advapi32.dll, user32.dll, ws2_32.dll...) │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
↕ Interfaz de llamadas al sistema (ntdll → syscall)
┌─────────────────────────────────────────────────────────────┐
│ Modo kernel │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Ejecutivo del Kernel (ntoskrnl.exe) │ │
│ │ ┌──────┐ ┌───────┐ ┌──────┐ ┌──────┐ ┌──────────┐ │ │
│ │ │Proc. │ │Memori │ │ E/S │ │Segur.│ │Objetos │ │ │
│ │ │Hilos │ │Virtual│ │Mgr. │ │(SRM) │ │(OM) │ │ │
│ │ └──────┘ └───────┘ └──────┘ └──────┘ └──────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ ┌──────────────┐ ┌─────────────────────────────────────┐ │
│ │ Kernel NT │ │ Drivers (win32k.sys, ndis.sys, │ │
│ │ (scheduler, │ │ storport.sys, ntfs.sys, tcpip.sys) │ │
│ │ sync, IPC) │ └─────────────────────────────────────┘ │
│ └──────────────┘ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ HAL (Hardware Abstraction Layer) │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
↕
┌─────────────────────────────────────────────────────────────┐
│ Hardware │
└─────────────────────────────────────────────────────────────┘
HAL (Hardware Abstraction Layer): capa delgada que aísla el kernel del hardware concreto. Permite que el mismo kernel funcione en x86, x86-64 y ARM64 (como en Surface Pro X o Windows 11 en dispositivos Qualcomm) cambiando solo el HAL.
El Ejecutivo del kernel (ntoskrnl.exe): el proceso con PID 4 en el Administrador de Tareas. Contiene todos los subsistemas del kernel:
- Process Manager: gestiona procesos e hilos.
- Virtual Memory Manager (VMM): gestión de memoria virtual, paginación, page file.
- I/O Manager: gestiona todas las operaciones de E/S, conecta aplicaciones con drivers.
- Security Reference Monitor (SRM): verifica todos los accesos a objetos contra las ACLs. Impone el modelo de seguridad de Windows.
- Object Manager (OM): Windows gestiona casi todo como "objetos" con handles. Ficheros, procesos, hilos, eventos, semáforos, sockets... todos son objetos con un namespace unificado.
El modelo de objetos de Windows: a diferencia de Unix donde "todo es un fichero", en Windows "todo es un objeto". Los objetos tienen tipos (Process, Thread, File, Key [registro], Event, Mutex...), tienen handles (referencias numéricas), y el Object Manager gestiona su ciclo de vida y conteo de referencias.
Active Directory (AD) es el servicio de directorio de Microsoft. En entornos empresariales, es el componente más crítico de la infraestructura Windows. Sin AD, no hay autenticación centralizada, no hay políticas de grupo, no hay gestión unificada.
Conceptos fundamentales:
Dominio: unidad administrativa básica. Un dominio es un conjunto de usuarios, equipos y recursos que comparten una base de datos de seguridad común gestionada por controladores de dominio (Domain Controllers, DCs).
Controlador de Dominio (DC): servidor que ejecuta Active Directory Domain Services (AD DS). Autentica usuarios y equipos, almacena el directorio, aplica políticas. Para alta disponibilidad, siempre debe haber al menos dos DCs por dominio.
LDAP (Lightweight Directory Access Protocol): protocolo estándar para leer y escribir en directorios como AD. Permite búsquedas como "dame todos los usuarios del departamento IT con cuenta activa".
Kerberos: protocolo de autenticación estándar que usa AD. Basado en tickets temporales:
1. El usuario se autentica al DC y obtiene un TGT (Ticket Granting Ticket).
2. Para acceder a un servicio (fichero compartido, servidor SQL...), el cliente pide al DC un Service Ticket usando el TGT.
3. El cliente presenta el Service Ticket al servicio para acceder.
4. Nunca se envía la contraseña al servicio; solo tickets firmados criptográficamente.
GPO (Group Policy Objects): mecanismo para aplicar configuraciones de seguridad y del sistema automáticamente a usuarios y equipos según su posición en el árbol de AD. Ejemplos de lo que puede hacer una GPO:
- Forzar una política de contraseñas (longitud mínima, complejidad, expiración).
- Instalar software automáticamente en todos los equipos de un departamento.
- Deshabilitar el acceso a USB en equipos con información confidencial.
- Configurar el fondo de escritorio y la pantalla de bloqueo corporativa.
- Mapear unidades de red automáticamente al iniciar sesión.
- Instalar certificados digitales de la CA corporativa.
- Configurar Windows Firewall con reglas corporativas.
FSMO Roles (Flexible Single Master Operations): en un dominio AD hay operaciones que deben hacerse en un único servidor para evitar conflictos (como cambiar el esquema del directorio o resetear contraseñas con el PDC emulator). Hay 5 roles FSMO distribuidos entre los DCs.
macOS es un SO de propósito general para consumidores y profesionales creativos, pero su arquitectura interna es radicalmente diferente de Windows: es un Unix certificado.
Darwin: el núcleo de código abierto de macOS. Combina:
- Mach microkernel (Carnegie Mellon University, 1985): gestiona la memoria virtual (con una abstracción muy potente llamada VM Objects), la comunicación entre tareas (IPC mediante Mach ports), y la planificación básica.
- FreeBSD userland: las syscalls POSIX, el sistema de ficheros, la pila de red, las herramientas de línea de comandos (ls, grep, bash...) vienen de FreeBSD.
- I/O Kit: framework orientado a objetos (C++) para drivers de dispositivos. Los drivers son plugins que se cargan/descargan dinámicamente (similar a los módulos de Linux).
XNU (X is Not Unix): el kernel resultante de combinar Mach + BSD. Es el corazón de macOS, iOS, iPadOS, tvOS, watchOS y visionOS.
Capa de compatibilidad POSIX: macOS es certificado como UNIX por The Open Group. Puedes compilar y ejecutar casi cualquier software Linux/Unix en macOS con pocas o ninguna modificación.
Terminal en macOS: aunque tiene GUI, macOS tiene un terminal de primera clase con zsh (por defecto desde Catalina), Homebrew como gestor de paquetes no oficial, y todas las herramientas Unix estándar.
Seguridad específica de macOS:
- Gatekeeper: impide ejecutar aplicaciones de fuentes no verificadas (no descargadas desde App Store ni firmadas con un certificado de desarrollador Apple).
- SIP (System Integrity Protection): incluso root no puede modificar ciertos directorios del sistema (/System, /usr, /bin, /sbin). Para modificarlos hay que desactivar SIP desde el modo de recuperación.
- Secure Enclave: procesador de seguridad dedicado (en los chips Apple Silicon y T2) que almacena claves biométricas (Touch ID, Face ID) y gestiona el cifrado. Las claves nunca salen del Secure Enclave.
- APFS (Apple File System): sistema de archivos propio de Apple. Copy-on-Write (sin corrupción ante fallos), snapshots instantáneos (base de Time Machine), cifrado nativo por volumen, optimizado para SSDs (usa "clonación" de ficheros a nivel de sistema de archivos para copias casi instantáneas).
Android demuestra que el kernel Linux es extraordinariamente versátil: el mismo kernel que corre en superordenadores corre en un smartphone.
┌─────────────────────────────────────────────────────────┐
│ Aplicaciones │
│ Gmail │ Chrome │ Maps │ WhatsApp │ Apps de terceros... │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ Framework de Aplicaciones │
│ Activity Manager │ Window Manager │ Location Manager │
│ Notification Manager │ Package Manager │ Camera... │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ Android Runtime (ART) + Librerías nativas │
│ ART (Ahead-of-Time compilation) │ OpenGL ES │ WebKit │
│ SQLite │ libc (Bionic, versión propia de Android) │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ HAL (Hardware Abstraction Layer) │
│ Cámara HAL │ Audio HAL │ Bluetooth HAL │ Sensor HAL │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ Kernel Linux │
│ Drivers │ Gestión de energía │ Binder IPC │ Memoria │
└─────────────────────────────────────────────────────────┘
ART (Android Runtime): compila el bytecode Dalvik/DEX de las apps a código nativo durante la instalación (AOT: Ahead-of-Time compilation). Esto hace que las apps arranquen más rápido que si se compilaran en tiempo de ejecución. A diferencia de la JVM de Java (que compila JIT: Just-in-Time), ART precompila.
Binder IPC: mecanismo de IPC propio de Android. A diferencia de los pipes y sockets de Unix, Binder permite llamadas a procedimientos remotos (RPC) entre procesos con identificación del llamante (el kernel pasa el UID del proceso llamante, permitiendo control de acceso). Es la base de todos los servicios del sistema Android: cuando una app llama a getSystemService(CAMERA_SERVICE), usa Binder para comunicarse con el servicio de cámara.
Modelo de seguridad Android:
- Cada app tiene su propio UID (user ID) de Linux. El aislamiento de procesos a nivel de SO garantiza que la app A no puede acceder a los datos de la app B (porque son de diferentes usuarios Unix).
- Sandbox de apps: cada app ejecuta en su propio proceso con un UID único. Los datos de cada app están en /data/data/nombre.paquete/ y solo son accesibles por esa app.
- Permisos declarados: cada app debe declarar en su AndroidManifest.xml qué permisos necesita (cámara, contactos, localización...). El usuario los concede explícitamente. Desde Android 6.0, los permisos peligrosos se solicitan en tiempo de ejecución, no durante la instalación.
- SELinux: Android usa SELinux (MAC) para confinamiento adicional. Incluso si un proceso escapa de su sandbox, SELinux limita lo que puede hacer.
iOS es el SO de Apple para iPhone, iPad y iPod Touch. Comparte el mismo kernel XNU que macOS, pero con un modelo de seguridad y restricciones radicalmente más estrictas.
Diferencias fundamentales respecto a macOS y Android:
Antes de la virtualización: para ejecutar 20 servicios diferentes (servidor web, base de datos, servidor de correo, DNS...) necesitabas 20 servidores físicos. Cada servidor subutilizado (al 5-15% de CPU típicamente). Alto coste de hardware, energía y mantenimiento.
Con virtualización: un servidor físico potente ejecuta 20 VMs, cada una con su propio SO y aplicaciones. La consolidación de servidores reduce el hardware necesario en un 80-90%.
Ventajas adicionales más allá de la consolidación:
- Aislamiento: un fallo en una VM no afecta a otras (a diferencia de colocar todos los servicios en el mismo SO).
- Snapshots: captura el estado completo de una VM en un momento. Permite volver atrás si una actualización falla.
- Migración en vivo (live migration): mover una VM en ejecución de un servidor físico a otro sin detenerla. Permite mantenimiento del hardware sin interrupciones.
- Recuperación ante desastres: las VMs son ficheros copiables. Si falla el servidor físico, la VM se inicia en otro servidor en minutos.
- Entornos de desarrollo/prueba: los desarrolladores pueden tener VMs con distintas configuraciones sin afectar al sistema real.
El hipervisor es el primer software que ejecuta directamente sobre el hardware, antes de cualquier SO. Las VMs son "huéspedes" que creen estar ejecutando sobre hardware real.
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ VM1: Linux │ │ VM2: Win. │ │ VM3: Linux │
│ (Servidor │ │ Server │ │ (Base de │
│ Web) │ │ (AD) │ │ datos) │
└──────────────┘ └──────────────┘ └──────────────┘
┌─────────────────────────────────────────────────┐
│ HIPERVISOR TIPO 1 │
│ (VMware ESXi / Hyper-V / KVM / XenServer) │
└─────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────┐
│ Hardware │
└─────────────────────────────────────────────────┘
¿Cómo ejecuta el hipervisor código de las VMs? Las instrucciones normales de la VM ejecutan directamente en la CPU sin emulación (virtualización asistida por hardware: Intel VT-x, AMD-V). Las instrucciones privilegiadas (que el SO huésped no puede ejecutar directamente) causan una "VM exit": el control vuelve al hipervisor, que las emula o ejecuta de forma segura.
VMware ESXi: el estándar histórico en centros de datos empresariales. Tiene un SO propio mínimo (ESXi) y se gestiona con vCenter (para gestionar múltiples hosts ESXi).
Microsoft Hyper-V: integrado en Windows Server y Windows 11 Pro/Enterprise. También tiene versión standalone (Hyper-V Server). Arquitectura peculiar: el "host" de Hyper-V en realidad es también una VM (la "partition root") que tiene acceso privilegiado al hardware.
KVM (Kernel-based Virtual Machine): módulo del kernel Linux que convierte a Linux en un hipervisor Tipo 1. Combinado con QEMU (emulador que proporciona los dispositivos virtuales), forma la base de la infraestructura de virtualización de prácticamente todos los proveedores cloud (AWS EC2, Google Compute Engine, OpenStack...). Gestionado con libvirt y Virt-Manager.
Xen: hipervisor open source muy utilizado en cloud (AWS originalmente usaba Xen). Arquitectura interesante: el dominio privilegiado (Dom0) es un SO Linux que gestiona el hardware y los otros dominios (DomU).
El hipervisor ejecuta como una aplicación sobre un SO convencional (Windows, Linux, macOS). Las VMs son procesos del SO anfitrión.
┌──────────────┐ ┌──────────────┐
│ VM1: Linux │ │ VM2: Win. │
└──────────────┘ └──────────────┘
┌─────────────────────────────────┐
│ HIPERVISOR TIPO 2 │
│ (VirtualBox / VMware Workst.) │
└─────────────────────────────────┘
┌─────────────────────────────────┐
│ SO Anfitrión (Windows/Linux) │
└─────────────────────────────────┘
┌─────────────────────────────────┐
│ Hardware │
└─────────────────────────────────┘
Overhead adicional: las llamadas al sistema de las VMs pasan por el SO anfitrión antes de llegar al hardware. Más capas = más latencia. Menos eficiente para producción.
VirtualBox (Oracle): gratuito, multiplataforma (Windows, Linux, macOS), muy usado para desarrollo y pruebas. Soporta snapshots, redes virtuales, carpetas compartidas con el anfitrión.
VMware Workstation/Fusion: de pago, mayor rendimiento que VirtualBox. Workstation para Windows/Linux, Fusion para macOS.
Los contenedores son la tecnología que ha transformado el despliegue de software en la última década. Es importante entenderlos bien porque aparecen frecuentemente en exámenes de administración moderna.
Un contenedor es un proceso (o conjunto de procesos) del SO anfitrión que tiene una vista restringida y aislada del sistema. A diferencia de una VM, no tiene su propio kernel ni hardware virtual: comparte el kernel del SO anfitrión.
El aislamiento se logra mediante dos mecanismos del kernel Linux:
Namespaces (espacios de nombres): cada contenedor tiene sus propios espacios de nombres, lo que le da una vista privada e independiente de ciertos recursos del kernel:
| Namespace | Qué aísla | Efecto |
|---|---|---|
| PID | Árbol de procesos | El contenedor solo ve sus propios procesos; el proceso 1 del contenedor es su init, no el init del host |
| NET | Interfaces de red, tablas de routing, puertos | El contenedor tiene su propia interfaz de red virtual y dirección IP |
| MNT | Sistema de archivos montado | El contenedor tiene su propio filesystem root (su imagen de contenedor) |
| UTS | Hostname | El contenedor puede tener su propio hostname |
| IPC | Semáforos, colas de mensajes compartidas | Aísla la comunicación IPC del contenedor |
| USER | UIDs y GIDs | El UID 0 dentro del contenedor puede mapearse a un UID no-root en el host |
| CGROUP | Vista de los cgroups | El contenedor solo ve sus propios cgroups |
Cgroups (Control Groups): mecanismo del kernel para limitar, contabilizar y aislar el uso de recursos por grupos de procesos:
- Limitar la CPU que puede usar un contenedor (p.ej. máximo 2 cores de 8).
- Limitar la RAM (p.ej. máximo 512 MB).
- Limitar el ancho de banda de disco (IOPS, MB/s).
- Limitar el ancho de banda de red.
- Contabilizar el uso de recursos para billing.
# Ver los cgroups asignados a un contenedor Docker
docker stats mi_contenedor
# Limitar un contenedor a 1 core y 256 MB de RAM
docker run --cpus=1 --memory=256m nginx
Imagen: plantilla de solo lectura que define el sistema de ficheros del contenedor (qué ficheros, binarios, librerías están disponibles). Las imágenes se construyen en capas (layers) apiladas. Cada instrucción del Dockerfile añade una capa. Las capas se reutilizan entre imágenes que comparten capas.
Contenedor: instancia en ejecución de una imagen. Es una imagen a la que se le añade una capa de escritura temporal encima.
Registro (Registry): repositorio de imágenes. Docker Hub es el registro público por defecto. Las empresas tienen registros privados (Harbor, AWS ECR, Azure Container Registry).
# Ejemplo de Dockerfile para una app web en Node.js
FROM node:18-alpine # capa base: imagen de Node.js sobre Alpine Linux (5 MB)
WORKDIR /app # directorio de trabajo
COPY package*.json ./ # copia los ficheros de dependencias
RUN npm install # instala dependencias (crea una nueva capa)
COPY . . # copia el código fuente
EXPOSE 3000 # documenta el puerto (no lo abre; es solo documentación)
CMD ["node", "server.js"] # comando por defecto al iniciar el contenedor
Una aplicación moderna puede tener decenas o cientos de microservicios, cada uno ejecutando en múltiples réplicas de contenedores. Gestionar esto manualmente es imposible. Kubernetes (K8s) automatiza el despliegue, escalado y gestión de aplicaciones en contenedores.
Conceptos fundamentales de Kubernetes:
Pod: la unidad mínima de despliegue. Un pod es uno o más contenedores que comparten la misma red (IP) y almacenamiento. Los contenedores dentro de un pod se comunican por localhost.
Deployment: define cuántas réplicas de un pod deben estar siempre ejecutando. Si un pod muere, el Deployment crea uno nuevo automáticamente.
Service: abstracción de red que expone un conjunto de pods como un servicio estable. Los pods tienen IPs efímeras; el Service tiene una IP/DNS estable que no cambia aunque los pods cambien.
Namespace (en Kubernetes, diferente de los namespaces del kernel): agrupación lógica de recursos dentro del mismo cluster. Permite multi-tenancy: diferentes equipos o entornos (prod, staging, dev) en el mismo cluster físico.
Node: una máquina (física o virtual) que forma parte del cluster K8s. Tiene el kubelet (agente K8s) y un runtime de contenedores (containerd, CRI-O).
Control Plane: el cerebro del cluster. Incluye el API server (punto de entrada), etcd (base de datos distribuida del estado del cluster), el scheduler (decide en qué nodo va cada pod) y el controller manager (mantiene el estado deseado).
| Aspecto | Máquina Virtual | Contenedor |
|---|---|---|
| Qué virtualiza | Hardware completo (CPU, RAM, disco, red virtuales) | Espacio de nombres del SO (filesystem, red, procesos) |
| Kernel | Cada VM tiene su propio kernel completo | Comparten el kernel del SO anfitrión |
| Aislamiento | Muy alto: si el kernel de la VM falla, solo cae esa VM | Menor: comparten el kernel; una vulnerabilidad del kernel afecta a todos |
| Tamaño | GBs (imagen del SO + aplicación) | MBs (solo la aplicación + sus dependencias, sin SO duplicado) |
| Tiempo de arranque | 30 segundos a varios minutos | Milisegundos a segundos |
| Overhead de rendimiento | 2-10% (virtualización asistida por hardware) | <1% (procesos nativos del kernel) |
| Densidad | 10-50 VMs por servidor físico típico | Cientos de contenedores por servidor físico |
| Uso de red | Cada VM tiene su propia interfaz virtual (overhead de red) | Containers comparten la pila de red del host (menor overhead) |
| Casos de uso | Workloads que requieren SO diferente al host; mayor aislamiento; Legacy apps | Microservicios; apps cloud-native; CI/CD; desarrollo |
| Mejor para | Seguridad máxima, SO heterogéneos, compliance estricto | Velocidad de despliegue, eficiencia, DevOps, escala |
¿Son excluyentes? No. En la práctica se combinan: se usan VMs para obtener aislamiento a nivel de infraestructura, y dentro de cada VM se ejecutan contenedores. AWS, Azure y GCP funcionan así: tus contenedores Docker corren dentro de VMs KVM (aunque tú solo ves los contenedores).
La evolución hacia microservicios y contenedores es la tendencia más establecida. El "nuevo servidor" no es una VM con un SO completo sino un nodo Kubernetes ejecutando decenas de pods.
Implicaciones para el administrador:
- El foco se desplaza de "gestionar servidores" a "gestionar el cluster".
- Herramientas: kubectl (CLI de Kubernetes), Helm (gestor de paquetes de K8s), ArgoCD (despliegue continuo).
- Observabilidad: Prometheus (métricas), Grafana (visualización), Jaeger (trazas distribuidas).
El modelo tradicional de SO es mutable: se instala, se configura, se parchea, se actualiza. Con el tiempo, los servidores acumulan configuraciones manuales, paquetes no documentados, ficheros residuales. Dos servidores "idénticos" pueden comportarse diferente. Este problema se llama configuration drift (deriva de configuración).
El SO inmutable invierte el modelo: el SO arranca desde una imagen de solo lectura, verificada criptográficamente, que no puede modificarse durante el tiempo de ejecución. Toda la configuración y las aplicaciones están en la imagen o en volúmenes de datos externos.
¿Cómo se actualiza? No se parchea in situ. Se construye una nueva imagen (con los parches incluidos), se despliega en los nodos (en paralelo o de forma rolling), y si algo falla, se vuelve automáticamente a la imagen anterior (rollback atómico).
Ventajas:
- Reproducibilidad total: dos nodos con la misma imagen se comportan exactamente igual, garantizado.
- Sin configuration drift: imposible que los nodos diverjan porque no se pueden modificar.
- Seguridad mejorada: si un atacante compromete el sistema y modifica ficheros del SO, al reiniciar el nodo esos cambios desaparecen.
- Rollback instantáneo: si una actualización rompe algo, volver al estado anterior es trivial.
- Auditoría simplificada: el estado del sistema en cualquier momento es exactamente el de la imagen desplegada.
Ejemplos:
- Fedora CoreOS: diseñado específicamente para ejecutar contenedores. Actualizado automáticamente con rollback automático en caso de fallo. Basado en rpm-ostree (sistema de archivos orientado a SO inmutable).
- Talos Linux: SO para nodos Kubernetes. Sin shell, sin SSH, sin acceso al sistema operativo directamente. Toda la gestión se hace a través de la API de Kubernetes. Extremadamente seguro.
- Flatcar Linux: heredero de CoreOS (Container Linux). Usado en producción por muchas empresas.
- ChromeOS: el SO de los Chromebooks es inmutable. Las actualizaciones se aplican a una partición secundaria; si el SO A falla, arranca desde el SO B.
- Android: cada actualización del sistema es una imagen completa verificada (A/B partitions).
El firmware UEFI verifica la firma criptográfica del bootloader antes de ejecutarlo. Previene bootkits. Integrado en todos los PCs modernos desde ~2012.
Chip hardware dedicado (o firmware emulado) que proporciona:
El modelo tradicional de seguridad es perimetral: los dispositivos dentro de la red corporativa son de confianza; los de fuera no. Una vez dentro, tienes acceso relativamente libre.
El problema: el perímetro ya no existe. Los empleados trabajan desde casa, desde cafeterías, desde hotel. Las aplicaciones están en la nube, no en el CPD corporativo. El VPN tradicional "dentro = confianza" ya no sirve.
Zero Trust (confianza cero): ningún usuario, dispositivo ni proceso es de confianza por defecto, independientemente de su ubicación. Todo acceso requiere verificación explícita.
Principios de Zero Trust:
Verificar explícitamente: siempre autenticar y autorizar basándose en todos los datos disponibles: identidad del usuario + estado del dispositivo (¿está actualizado? ¿tiene EDR activo?) + localización + comportamiento.
Mínimo privilegio: dar solo el acceso necesario para la tarea concreta. Un desarrollador que necesita leer la base de datos de producción para depurar un bug no necesita acceso de escritura ni acceso a otras bases de datos.
Asumir la brecha: diseñar como si el atacante ya estuviera dentro. Segmentar el acceso, cifrar todo el tráfico (incluso interno), monitorizar continuamente.
Implementación en el SO:
- Cada acceso a un recurso requiere autenticación y autorización (no solo el login inicial).
- Micro-segmentación de red: incluso los procesos en el mismo servidor no pueden comunicarse libremente; necesitan estar explícitamente autorizados.
- EDR (Endpoint Detection and Response): el SO ejecuta un agente que monitoriza comportamientos anómalos en tiempo real.
Una de las innovaciones más importantes del kernel Linux en años recientes. eBPF permite ejecutar programas pequeños y verificados directamente en el kernel Linux sin modificar el código fuente del kernel ni cargar módulos.
¿Cómo funciona? El programador escribe un programa eBPF (en C restringido). Un compilador lo compila a bytecode eBPF. El kernel verifica que el programa es seguro (no puede colgarse, no puede acceder a memoria inválida, debe terminar). Si la verificación pasa, el programa se compila a código máquina nativo y se "engancha" a un punto del kernel (cuando llega un paquete de red, cuando se hace una syscall específica, cuando se ejecuta una función del kernel...).
Casos de uso:
- Observabilidad: monitorizar todas las syscalls de todos los procesos con overhead mínimo (<1%). Herramientas: bcc, bpftrace.
- Seguridad: Falco, Cilium Tetragon detectan comportamientos maliciosos en tiempo real (un proceso intentando abrir ficheros que no debería, escaneo de puertos desde dentro del contenedor...).
- Redes: Cilium usa eBPF para reemplazar iptables con un datapath de red mucho más eficiente. Base de la red en Google Kubernetes Engine y Cloudflare.
- Rendimiento: detectar cuellos de botella en el kernel con resolución de nanosegundos.
El Edge Computing lleva el procesamiento cerca de donde se generan los datos, en lugar de enviarlo todo a la nube central.
¿Por qué edge y no cloud?
- Latencia: un vehículo autónomo no puede esperar 50 ms de round-trip a la nube para decidir si frenar. La decisión debe tomarse localmente en <1 ms.
- Ancho de banda: una fábrica con 500 cámaras generando 4K a 30 fps genera cientos de Gbps. Enviar todo a la nube es inviable económicamente.
- Privacidad y regulación: datos de salud o de cámaras de vigilancia pueden no poder salir de ciertos países.
- Disponibilidad: si se corta la conexión a la nube, los sistemas críticos (control de maquinaria, seguridad) no pueden dejar de funcionar.
Arquitectura típica de Edge:
[Sensores/Actuadores]
↓
[Gateway Edge] ← SO embebido/RTOS ligero
↓ (datos preprocesados, solo lo relevante)
[Edge Node] ← Linux embebido / k3s (Kubernetes ligero)
↓ (agregados, anomalías, modelos entrenados)
[Cloud Central] ← Kubernetes full, almacenamiento masivo
K3s: versión ligera de Kubernetes para edge y sistemas embebidos. Ocupa ~50 MB de RAM en lugar de los cientos de MB de K8s completo. Usado en dispositivos ARM, Raspberry Pi, routers industriales.
SO para IoT:
- Zephyr RTOS: SO open source (Linux Foundation) para microcontroladores. Muy modular (puedes incluir solo los componentes que necesitas). Soporte para Bluetooth LE, Zigbee, LoRaWAN, Thread.
- FreeRTOS (Amazon): el RTOS más usado en el mundo. Integrado en el SDK de AWS IoT.
- Mbed OS (Arm): SO para microcontroladores ARM Cortex-M. Integrado con el ecosistema Arm.
Los SO modernos empiezan a incorporar capacidades de IA a nivel del propio sistema:
Gestión predictiva de recursos:
- Predecir qué aplicaciones abrirá el usuario a continuación y precargarlas en memoria.
- Anticipar picos de carga y escalar recursos preventivamente.
- Linux desde el kernel 5.x incluye mecanismos para aprendizaje de patrones de acceso a memoria.
Detección de anomalías a nivel de SO:
- Comparar el comportamiento actual de los procesos con patrones históricos.
- Detectar que un proceso que normalmente lee unos pocos ficheros de configuración está intentando acceder a miles de ficheros: posible ransomware.
- EDR modernos (CrowdStrike, SentinelOne) usan modelos de ML integrados con el SO para esto.
Asistentes con lenguaje natural:
- Microsoft Copilot integrado en Windows 11: interacción con el SO mediante lenguaje natural.
- Próxima generación: gestión de sistema (configurar red, instalar software, diagnosticar problemas) mediante instrucciones en lenguaje natural que el asistente traduce a comandos.
Los SO modernos incorporan infraestructura de observabilidad de primera clase porque en entornos cloud y contenedores, diagnosticar problemas sin buenas herramientas es casi imposible.
Los tres pilares de la observabilidad:
Logs: registros de eventos del sistema.
- Linux (journald): el demonio systemd-journald captura todos los logs del sistema en formato binario estructurado, consultable con journalctl. Ventajas: filtrado por tiempo, servicio, prioridad, UID; logs persistentes entre reinicios; indexados para búsqueda rápida.
journalctl -u nginx --since "1 hour ago" # logs de nginx de la última hora
journalctl -p err -b 0 # errores desde el último arranque
journalctl -f # tail en tiempo real
Métricas: valores numéricos que cambian en el tiempo (CPU, memoria, latencia...).
- Prometheus: sistema de monitorización y alerta open source. Recopila métricas de endpoints HTTP en formato texto cada pocos segundos. Almacena en base de datos de series temporales. Integrado con prácticamente todo.
- eBPF: permite recopilar métricas del kernel con overhead casi nulo.
Trazas: seguimiento del camino de una petición a través de múltiples servicios.
- OpenTelemetry: estándar abierto para generar, recopilar y exportar trazas, métricas y logs. Integrado en el código de las aplicaciones y en los runtimes de contenedores.
- Jaeger / Zipkin: herramientas para visualizar trazas distribuidas.
| Concepto A | Concepto B | Diferencia clave | Ejemplo / Caso de uso |
|---|---|---|---|
| Proceso | Hilo | Proceso: memoria propia, aislado. Hilo: comparte memoria del proceso, más ligero | Un servidor web usa hilos por petición; un navegador usa procesos por pestaña |
| Programa | Proceso | Programa: fichero estático en disco. Proceso: programa en ejecución con estado dinámico | Puedes tener 3 instancias del mismo Firefox (3 procesos, 1 programa) |
| Kernel monolítico | Microkernel | Monolítico: todo en kernel, rápido pero frágil. Microkernel: mínimo en kernel, estable pero más lento | Linux vs QNX |
| Kernel monolítico | Kernel híbrido | Monolítico: arquitectura pura. Híbrido: microkernel con compromisos de rendimiento | Linux vs Windows NT |
| Multitarea cooperativa | Multitarea preventiva | Cooperativa: proceso cede voluntariamente (riesgo de bloqueo). Preventiva: SO fuerza el cambio | Windows 3.x vs Windows 95+ |
| Memoria física | Memoria virtual | Física: RAM real, limitada, compartida. Virtual: espacio abstracto por proceso, puede superar la RAM | Puedes ejecutar un proceso de 8 GB con 4 GB de RAM física |
| Paginación | Segmentación | Paginación: bloques fijos, transparente. Segmentación: bloques variables con significado | ext4/NTFS usan paginación; x86 original usaba segmentación |
| Hard real-time | Soft real-time | Hard: incumplir el plazo es fallo del sistema. Soft: incumplir degrada calidad | ABS/marcapasos vs streaming de vídeo |
| RTOS | SO propósito general | RTOS: determinista, sin paginación. General: mayor throughput medio, no determinista | FreeRTOS vs Linux |
| Deadlock | Starvation | Deadlock: todos bloqueados en ciclo. Starvation: uno nunca obtiene el recurso pero podría | Deadlock: A espera a B, B espera a A. Starvation: proceso de baja prioridad nunca ejecuta |
| BIOS | UEFI | BIOS: 2 TB max, 4 particiones, sin Secure Boot. UEFI: discos ilimitados, 128 particiones, Secure Boot | Todos los PCs modernos desde ~2012 usan UEFI |
| MBR | GPT | MBR: 2 TB, 4 particiones primarias, sin redundancia. GPT: 9 ZB, 128 particiones, CRC32, backup | Discos >2 TB requieren GPT |
| VM | Contenedor | VM: kernel propio, SO completo, GBs, minutos arranque. Contenedor: kernel compartido, MBs, segundos | VMware/KVM vs Docker/Kubernetes |
| Hipervisor Tipo 1 | Hipervisor Tipo 2 | Tipo 1: sobre hardware directamente, más eficiente, para producción. Tipo 2: sobre SO, para desarrollo | VMware ESXi vs VirtualBox |
| BIOS/MBR | UEFI/GPT | Antiguo, limitado, sin seguridad. Moderno, sin límites prácticos, Secure Boot | Hardware pre-2012 vs post-2012 |
| DAC | MAC | DAC: propietario controla permisos (Unix rwx, NTFS ACL). MAC: sistema impone reglas (SELinux, AppArmor) | Usuario puede cambiar chmod en DAC; en MAC no puede cambiar política SELinux |
| DAC | RBAC | DAC: permisos en el recurso. RBAC: permisos en roles asignados a usuarios | Unix chmod vs Active Directory grupos |
| Autenticación | Autorización | Autenticación: ¿quién eres? Autorización: ¿qué puedes hacer? | Login (autenticación) vs comprobación de permisos (autorización) |
| SO de red | SO distribuido | Red: el usuario sabe dónde está cada recurso. Distribuido: transparencia total de ubicación | Windows Server shares vs Plan 9 |
| Namespace (kernel) | Namespace (Kubernetes) | Kernel: aísla recursos del SO (PID, NET, MNT...). K8s: agrupación lógica de objetos del cluster | docker run --pid=host vs kubectl -n produccion |
| Cgroups | Namespaces | Cgroups: limitan cuántos recursos puede usar un contenedor. Namespaces: determinan qué puede ver | CPU max 2 cores (cgroup) vs el contenedor solo ve sus propios procesos (namespace PID) |
| Comando | Syscall principal | Para qué sirve | Ejemplo del examen |
|---|---|---|---|
pwd |
getcwd() |
Muestra el directorio de trabajo actual | pwd → /home/usuario/proyectos |
sudo cmd |
setuid() + execve() |
Ejecuta cmd con privilegios de root (SUID) | sudo systemctl restart nginx |
touch f |
open() / utimensat() |
Crea fichero vacío o actualiza timestamps | touch /tmp/lock.pid |
chmod 755 f |
chmod() |
Cambia permisos de acceso | chmod +x script.sh |
kill -9 PID |
kill(PID, SIGKILL) |
Envía señal SIGKILL (terminación forzosa) | kill -9 4821 para matar proceso colgado |
| FS | Journaling | Permisos | Max fichero | Cuándo usarlo |
|---|---|---|---|---|
| FAT32 | No | No | 4 GB | Pendrives, compatibilidad universal |
| exFAT | No | No | 128 PB | Tarjetas SD grandes, discos externos Mac/Win |
| NTFS | Sí | ACL (muy granular) | 16 EB | Windows (sistema y datos), discos con permisos |
| ext4 | Sí (3 modos) | Unix + ACL opcional | 16 TB | Linux servidores y escritorio |
| XFS | Sí | Unix + ACL | 8 EB | Servidores con ficheros muy grandes |
| Btrfs | CoW | Unix + ACL | 16 EB | Linux moderno, snapshots, RAID software |
| ZFS | CoW | Sí | 16 EB | NAS, almacenamiento crítico, integridad máxima |
| Pregunta del examen | Concepto de esta parte del tema |
|---|---|
| Q1a — pwd | Gestión del sistema de archivos: directorio de trabajo, syscall getcwd() |
| Q1b — sudo | Seguridad: SUID, escalada de privilegios controlada, DAC, auditoría en /var/log/auth.log |
| Q1c — touch | Sistema de archivos: inodos, timestamps (atime, mtime, ctime), syscalls open()/utimensat() |
| Q1d — chmod | Permisos Unix (rwx), notación octal, syscall chmod(), SUID/SGID/sticky bit |
| Q1e — kill | Gestión de procesos: señales Unix (SIGTERM, SIGKILL), syscall kill(), PCB |
| Q2 — MFA | Autenticación: factores (saber/tener/ser), TOTP (HMAC-SHA1), tokens, biometría |
| Q3 — Wake-on-LAN | SO de red, gestión de interfaces de red por el kernel, interrupciones de hardware |
| Q4 — Switch/Router | Pila de red del SO (Netfilter, namespaces de red), SO de red |
| Q5 — VPN | Virtualización de red, namespaces NET del kernel Linux, tun/tap devices |
| Q6 — Cortafuegos | Netfilter/iptables en Linux, connection tracking (stateful inspection), DAC/MAC |
| Q7 — Malware | Protección del SO: DAC, MAC (SELinux), sandboxing, auditoría, Secure Boot |
| Q8 — NAS/Backups | Sistema de archivos (NFS, SMB/CIFS), SO de red vs distribuido, journaling, ZFS/Btrfs |
| Q9 — Permisos NTFS | NTFS (MFT, ACL, ADS, EFS, journaling), DAC en Windows, permisos heredados |
| Q10 — Red edificio | VLANs (requieren SO de red en switches gestionables), STP, alta disponibilidad |
Pregunta 1
Una empresa industrial necesita un sistema de control para sus robots de soldadura. El sistema debe garantizar que los movimientos de los robots se calculan y ejecutan con una latencia máxima de 500 microsegundos. Actualmente están considerando usar Ubuntu Server 22.04 o VxWorks. Analiza razonadamente qué SO es más adecuado para este caso. ¿Qué características del SO elegido lo hacen apropiado? ¿Por qué el SO descartado no sería válido para esta aplicación, aunque tuviera suficiente potencia de procesamiento?
Pregunta 2
Explica en qué se diferencia un SO de red de un SO distribuido. Una empresa tiene un servidor Windows Server con carpetas compartidas accesibles desde los PCs de los empleados, y también usa Google Drive como almacenamiento corporativo. ¿Cuál de estos dos entornos se comporta más como un SO de red y cuál como un SO distribuido? Razona la respuesta considerando transparencia de ubicación, gestión de fallos y visibilidad de los recursos para el usuario.
Pregunta 3
Describe la arquitectura interna del sistema operativo Linux distinguiendo entre: el espacio de usuario y el espacio de kernel, los subsistemas principales del kernel (VFS, Netfilter, planificador CFS, VMM), el sistema de módulos cargables y su relación con los drivers. ¿Qué ventaja específica aporta el modelo de módulos cargables de Linux frente a un kernel monolítico puro? ¿Y respecto a un microkernel?
Pregunta 4
Una empresa de mediana escala (200 empleados) quiere migrar su infraestructura de servidores físicos a una plataforma virtualizada. Actualmente tienen 15 servidores físicos. Explica las ventajas de la virtualización para este escenario. Compara hipervisor Tipo 1 vs Tipo 2 e indica cuál usarías para producción y por qué. Describe además tres funcionalidades específicas de la virtualización (no solo la consolidación) que mejorarían la operativa de la empresa.
Pregunta 5
Explica qué son los contenedores Docker y cómo los mecanismos del kernel Linux (namespaces y cgroups) hacen posible su funcionamiento. Describe detalladamente qué aísla cada tipo de namespace relevante. ¿Qué ventaja de seguridad tiene usar un hipervisor (VM) respecto a un contenedor? ¿Y al revés, qué ventaja tiene el contenedor? ¿En qué escenario combinarías ambas tecnologías?
Pregunta 6
El Active Directory es la pieza central de la gestión de identidad en entornos Windows empresariales. Explica qué es un Dominio AD, qué es un Controlador de Dominio y qué protocolo de autenticación usa. Describe qué son las GPO (Group Policy Objects) y da tres ejemplos concretos de políticas de seguridad que implementarías con GPO en una empresa con 50 empleados y datos confidenciales. ¿Cómo se relaciona AD con el modelo de control de acceso RBAC?
Pregunta 7
Define el concepto de SO inmutable y explica en qué se diferencia del modelo tradicional de SO mutable. ¿Qué problema de administración de sistemas resuelve específicamente? Describe el proceso de actualización de un SO inmutable comparándolo con el proceso de patcheo tradicional. ¿Qué ventajas de seguridad aporta? ¿En qué escenarios es especialmente apropiado y en cuáles puede ser un inconveniente?
Pregunta 8
Describe la arquitectura de seguridad de Android en capas, desde el kernel Linux hasta las aplicaciones. Explica específicamente: cómo el modelo de UID de Linux proporciona aislamiento entre apps; qué es el sandbox de apps y cómo funciona; cómo gestiona Android los permisos a partir de Android 6.0; y qué papel juega SELinux en la seguridad del sistema. Compara este modelo con el de iOS indicando las diferencias fundamentales en la filosofía de seguridad de ambas plataformas.
Pregunta 9
La tecnología eBPF se describe como una de las innovaciones más importantes del kernel Linux en años recientes. Explica qué es eBPF, cómo funciona técnicamente (incluyendo el proceso de verificación) y para qué se usa actualmente. ¿Qué lo diferencia de cargar un módulo del kernel tradicional? ¿Qué garantías de seguridad ofrece? Da dos ejemplos concretos de casos de uso en entornos de producción.
Pregunta 10
Un administrador de sistemas debe elegir el sistema de archivos para tres escenarios distintos: (a) un servidor NAS empresarial que almacenará copias de seguridad de 50 TB con requisitos de integridad máxima; (b) un servidor de ficheros Windows Server que debe integrar permisos granulares por departamento; (c) un pendrive USB que debe ser accesible desde Windows, macOS y Linux. Para cada escenario indica qué sistema de archivos elegirías, justifica técnicamente la elección y describe las características específicas del sistema elegido que lo hacen idóneo para ese caso.
Fin de la Parte 3 — Tipos de SO, SO Relevantes, Virtualización, Tendencias y Resumen
Las tres partes juntas conforman el Tema 1 completo de Conceptos de Sistemas Operativos