Comparativa de sistemas de ficheros
El sistema de ficheros determina cómo se organizan y protegen los datos en disco. Cada SO usa uno distinto, con capacidades muy diferentes:
| Sistema de ficheros | SO principal | Tamaño máx. fichero | Journaling | Permisos Unix | Cifrado nativo | Año |
|---|
| FAT32 | Pendrives, SD, legacy | 4 GB − 1 byte | ❌ No | ❌ No | ❌ No | 1996 |
| NTFS | Windows | 16 TB (práctico) | ✅ Sí | ✅ ACLs | ✅ BitLocker | 1993 |
| ext4 | Linux (default) | 16 TB | ✅ Sí | ✅ rwxrwxrwx | ❌ No nativa | 2008 |
| APFS | macOS, iOS | 8 EB | ✅ Copy-on-Write | ✅ Sí | ✅ FileVault 2 | 2017 |
¿Para quién es útil este visualizador?
🎓Estudiante de informática
Preparas un examen de Sistemas Operativos y necesitas entender de verdad la diferencia entre Round Robin y FIFO, o qué ocurre paso a paso cuando hay un page fault. Los diagramas interactivos sustituyen horas de teoría abstracta.
💻Desarrollador con bugs de concurrencia
Tu aplicación se bloquea de forma intermitente y sospechas un deadlock o una condición de carrera entre hilos. El diagrama de estados de procesos te ayuda a visualizar las transiciones y entender cuándo un proceso queda atrapado en estado bloqueado.
🖧Administrador de sistemas Linux
Optimizas un servidor y necesitas decidir entre algoritmos de scheduling, elegir el sistema de ficheros correcto para un volumen crítico o entender por qué el swap está saturado. La comparativa de page faults por tamaño de RAM es especialmente útil.
🔍Curioso que quiere entender su ordenador
Siempre te has preguntado qué hace el ordenador mientras espera que cargue una app, o por qué abrir demasiadas pestañas del navegador se come la RAM. Este visualizador te da la respuesta sin que necesites saber programar.
Preguntas frecuentes
- ¿Qué diferencia hay entre un proceso y un hilo (thread)?
- Un proceso es un programa en ejecución con su propio espacio de memoria aislado. Un hilo es una unidad de ejecución dentro de un proceso — comparte la memoria con los demás hilos del mismo proceso. Crear un hilo cuesta ~10 µs; crear un proceso, ~1 ms. Si un hilo falla sin control puede tumbar todo el proceso, pero si falla un proceso no afecta a los demás.Ejemplo: Chrome ejecuta 1 proceso por pestaña y varios hilos dentro de cada uno (UI, red, JS, render).
- ¿Por qué Round Robin es el algoritmo de scheduling más usado?
- Porque es el más equitativo: ningún proceso acapara la CPU indefinidamente. Cada proceso recibe un quantum de tiempo (típicamente 10-100 ms) y luego cede la CPU al siguiente. Esto garantiza tiempos de respuesta aceptables para todos los procesos y es especialmente adecuado para sistemas de propósito general como Linux o Windows, donde conviven procesos interactivos (requieren respuesta rápida) con procesos de fondo (toleran espera).El quantum de Linux varía entre 10 ms y 200 ms según la prioridad del proceso.
- ¿Qué es un page fault y es siempre un error?
- Un page fault ocurre cuando un proceso intenta acceder a una página de memoria que no está cargada en RAM en ese momento. No es necesariamente un error: es el mecanismo normal de la memoria virtual. El SO detiene el proceso, carga la página desde disco (swap), y reanuda la ejecución. Se convierte en problema cuando hay demasiados page faults por segundo (thrashing), lo que significa que el sistema está constantemente paginando y la CPU dedica más tiempo a gestionar páginas que a ejecutar código útil.Un PC moderno puede tolerar miles de page faults por segundo sin notar degradación.
- ¿Por qué 32 bits solo pueden usar 4 GB de RAM?
- Un registro de 32 bits puede representar 2³² = 4.294.967.296 valores distintos. Como cada valor representa una dirección de memoria de 1 byte, el máximo direccionable es exactamente 4 GB. Con 64 bits, el límite teórico sube a 2⁶⁴ = 16 exabytes, aunque los procesadores actuales usan 48 bits efectivos (256 TB por proceso). Por eso instalar más de 4 GB de RAM en un sistema de 32 bits es inútil: el SO sencillamente no puede acceder a esa memoria.Algunos SO de 32 bits usaban PAE para alcanzar hasta 64 GB, pero con límites por proceso de 4 GB.
- ¿Qué es un kernel y qué diferencia hay con el espacio de usuario?
- El kernel es el núcleo del SO: el único software que tiene acceso directo al hardware (CPU, RAM, dispositivos). Se ejecuta en modo privilegiado (kernel space). El resto de programas (navegador, editor, juego) se ejecutan en user space con acceso restringido. Para acceder al hardware, hacen una llamada al sistema(syscall) que le pide al kernel que lo haga en su nombre. Esta separación protege la estabilidad: si tu app falla, el kernel sigue funcionando.Linux tiene ~400 syscalls distintas. `open()`, `read()`, `write()` y `fork()` son las más frecuentes.
- ¿Qué es un deadlock y cómo se evita?
- Un deadlock (interbloqueo) ocurre cuando dos o más procesos se bloquean mutuamente esperando recursos que el otro tiene. Las cuatro condiciones necesarias son: exclusión mutua, retención y espera, no expropiación y espera circular. Para evitarlo se usan técnicas como ordenación de recursos (siempre pedir A antes que B), timeouts en la adquisición de locks, o algoritmos de detección y recuperación.Los deadlocks en bases de datos son comunes; los SGBD los detectan automáticamente y abortan una transacción.
Del clic al píxel: qué ocurre cuando abres una aplicación
- 1
El SO crea un nuevo procesoEl kernel llama a fork() + exec() (Unix) o CreateProcess()(Windows). Se reserva un PCB (Process Control Block) con el estado inicial del proceso: PID, prioridad, tabla de páginas vacía, descriptores de fichero (stdin, stdout, stderr).
- 2
Carga del ejecutable en memoria virtualEl cargador (loader) mapea el fichero ejecutable en el espacio de direcciones virtual del proceso. Las páginas de código y datos no se cargan en RAM todavía: se producirán page faults bajo demanda cuando el proceso intente acceder a ellas por primera vez.
- 3
El planificador encola el procesoEl proceso pasa al estado LISTO y el scheduler lo añade a la cola de procesos listos. En Linux, el CFS (Completely Fair Scheduler) le asigna un tiempo de ejecución proporcional a su prioridad (nice value). Cuando le toca, la CPU hace un cambio de contexto y comienza la ejecución.
- 4
Ejecución e I/O: procesos bloqueados y reanudadosCada vez que la app necesita leer un fichero, conectarse a la red o esperar entrada del usuario, hace una syscall y pasa a estado BLOQUEADO. La CPU queda libre para ejecutar otro proceso. Cuando la operación I/O termina, una interrupción del hardware despierta al proceso: vuelve a LISTO y espera su turno de CPU.
- 5
Render y presentación en pantallaLa app escribe píxeles en un framebuffer compartido con el compositor del SO (Compositor de Windows, Wayland/X11 en Linux, Quartz en macOS). El compositor combina todas las ventanas en una imagen final y la envía a la GPU, que la muestra en pantalla. Este proceso ocurre típicamente 60 veces por segundo (60 Hz).
Claves para entender los SO a fondo
🔬Estudia desde lo concreto
Ejecuta htop o el Administrador de tareas mientras abres apps y observa cómo cambian los procesos en tiempo real. Ver el scheduling en vivo es más útil que memorizar fórmulas.
📊Prioridad al scheduling correcto
Para elegir algoritmo: si la latencia importa (UI, juegos) usa Round Robin con quantum pequeño; si el throughput importa (servidores batch) usa SJF o FIFO; si hay procesos críticos usa prioridades con aging para evitar inanición.
💾El swap no es RAM extra gratuita
Usar swap es entre 100x y 1000x más lento que RAM. Si el sistema está constantemente en swap, la solución es añadir más RAM, no más swap. El swap es solo un salvavidas de emergencia.
🔒Los permisos Unix son sencillos pero potentes
Aprende a leer rwxr-xr-x de derecha a izquierda: otros → grupo → propietario. Nunca des permisos 777 en producción. El principio de mínimo privilegio es la base de la seguridad Unix.
🧩Entiende el kernel antes que las APIs
Todo framework, lenguaje o librería acaba llamando a syscalls del kernel. Saber qué ocurre por debajo te ayuda a diagnosticar problemas que las abstracciones de alto nivel ocultan: cuellos de botella de I/O, leaks de memoria, deadlocks.
⚠️Conceptos erróneos frecuentes sobre sistemas operativos
- "Más RAM siempre mejora el rendimiento" — Falso. Si tus procesos ya caben en RAM, añadir más no cambia nada. El cuello de botella suele ser CPU, I/O de disco o red, no RAM.
- "Un proceso que no usa CPU no consume recursos" — Falso. Un proceso bloqueado sigue ocupando RAM (sus páginas), descriptores de fichero y entradas en la tabla de procesos del kernel.
- "Matar un proceso siempre libera su memoria inmediatamente" — No siempre. En sistemas con copy-on-write y páginas compartidas, la memoria puede no liberarse hasta que el último proceso que la referencia termine.
- "El disco duro es solo un sitio para guardar ficheros" — También se usa como swap (extensión de RAM), para journaling del sistema de ficheros, y en bases de datos como almacenamiento de datos estructurados con control transaccional.
- "Un ordenador solo ejecuta un programa a la vez" — Técnicamente cierto por núcleo de CPU, pero el scheduling crea la ilusión de paralelismo conmutando entre procesos miles de veces por segundo. Con múltiples núcleos sí hay paralelismo real.