Un sistema operativo no es una categoría única: el firmware que gobierna una estación meteorológica y el núcleo Linux de un servidor de centro de datos resuelven el mismo problema de fondo, pero con prioridades opuestas y con una diferencia de tamaño de cuatro órdenes de magnitud. En esta lección vas a aprender a clasificar sistemas operativos por criterios independientes —modo de procesamiento, número de usuarios y tareas, ámbito de uso y modelo de licencia— y, sobre todo, a usar esa clasificación para lo que de verdad sirve: elegir. Al final aplicaremos el criterio a las tres piezas de la infraestructura de Meteora y verás que la respuesta correcta es distinta en cada caso.

1. Por qué clasificar: los criterios no son excluyentes
2. Clasificación por modo de procesamiento
3. Clasificación por número de usuarios y de tareas
4. Clasificación por ámbito de uso
5. Clasificación por licencia y modelo de desarrollo
6. Tabla comparativa y criterios de elección
7. Caso aplicado: qué elige Meteora para cada pieza

El primer error al estudiar este tema es tratar la clasificación como una lista de cajones donde cada sistema cae en uno solo. No funciona así. Los criterios son dimensiones independientes, y cualquier sistema real ocupa una posición en todas a la vez.

Tomemos Linux en meteo-01:

• Por modo de procesamiento: interactivo/tiempo compartido, aunque también ejecuta trabajos por lotes durante la noche.
• Por usuarios: multiusuario.
• Por tareas: multitarea apropiativa.
• Por ámbito: de servidor, aunque el mismo núcleo se usa en escritorio, en móviles y en sistemas empotrados.
• Por licencia: libre (GPL v2).

El mismo núcleo Linux, con otra configuración y otras herramientas alrededor, puede ser un sistema empotrado monousuario de 8 MB. Por eso la clasificación útil no describe "qué es" un sistema, sino qué prioridades tiene y para qué está afinado.

Este criterio responde a: ¿cómo llegan los trabajos al sistema y qué se optimiza al atenderlos?

Los trabajos se acumulan y se ejecutan sin interacción con el usuario. Lo que se optimiza es la productividad (throughput): trabajos completados por hora. Que un trabajo concreto tarde más da igual si en conjunto se procesan más.

Suenan antiguos, pero están más vivos que nunca: la facturación mensual de un banco, el reentrenamiento nocturno de un modelo, la generación de informes o el propio cálculo de medias diarias de Meteora son procesamiento por lotes. Lo que cambió es el envoltorio: hoy se llaman jobs, cron, pipelines o batch workloads.

Explicación del bloque, que es un trabajo por lotes de manual:

• 30 2 * * * son los cinco campos de cron: minuto 30, hora 2, cualquier día del mes, cualquier mes, cualquier día de la semana. Es decir, todos los días a las 02:30.
• meteora es el usuario con el que se ejecuta. Nunca se usa root para esto: si el programa tiene un fallo, el daño queda limitado a lo que puede tocar meteora.
• El resto es el programa y sus argumentos.
• No hay nadie mirando: el trabajo se ejecuta, escribe su salida y termina. Si falla, lo sabremos por los registros. Esa ausencia de interactividad es exactamente lo que define el modo por lotes.

El sistema atiende a usuarios (o clientes) que esperan una respuesta. Lo que se optimiza no es la productividad total sino el tiempo de respuesta y su previsibilidad.

La consecuencia técnica es que el planificador debe favorecer a los procesos que hacen mucha entrada/salida y poco cálculo, porque suelen ser los interactivos. Cuando en meteo-01 conviven agregador (mucha CPU) y meteo-api (mucha espera de red), el planificador da preferencia al segundo precisamente por esto. Lo estudiarás en Planificación de la CPU.

Aquí lo que importa no es ir rápido sino cumplir plazos. Un sistema de tiempo real garantiza que una tarea se completa antes de un instante límite (deadline). La distinción clave:

Una idea contraintuitiva pero fundamental: un sistema de tiempo real no es un sistema rápido, es un sistema predecible. Un RTOS suele tener un rendimiento medio peor que Linux, porque renuncia a optimizaciones (cachés agresivas, planificadores adaptativos) cuyo comportamiento en el peor caso no se puede acotar. Prefiere ser siempre igual de lento a ser normalmente muy rápido y a veces impredecible.

Puedes comprobar en meteo-01 que Linux ofrece políticas de planificación de tiempo real blando:

Qué significa esta salida:

• chrt consulta y modifica las políticas de planificación en tiempo real. La opción -m muestra los rangos de prioridad disponibles.
• SCHED_OTHER es la política normal, la que usan ingestor, agregador y meteo-api. No tiene prioridades de tiempo real (rango 0/0).
• SCHED_FIFO y SCHED_RR son políticas de tiempo real blando con 99 niveles de prioridad. Un proceso SCHED_FIFO se ejecuta hasta que se bloquea o cede voluntariamente: puede monopolizar un núcleo.
• SCHED_DEADLINE permite declarar un plazo explícito, y el núcleo comprueba que el conjunto de tareas sea admisible.

Aun con estas políticas, Linux estándar no es un sistema de tiempo real duro: no garantiza una cota máxima de latencia en todos los casos. Para eso existen sistemas como QNX, VxWorks, FreeRTOS o Zephyr, o parches como PREEMPT_RT. El tema completo está en Sistemas Operativos Móviles y de Tiempo Real.

Son dos dimensiones distintas que a menudo se confunden.

Un sistema multiusuario mantiene identidades separadas con recursos y permisos propios, y garantiza que un usuario no accede a lo que es de otro. No requiere que haya varias personas conectadas a la vez: meteo-01 es multiusuario aunque nadie inicie sesión, porque cada servicio corre con una identidad distinta.

De hecho, ese es el uso más importante hoy del modelo multiusuario: no separar personas, sino separar servicios.

Interpretación:

• Los tres procesos de Meteora corren como meteora, no como root. Si un atacante compromete meteo-api, solo obtiene los permisos de meteora: puede leer /var/lib/meteora/, pero no modificar el sistema.
• nginx corre como www-data, otra identidad distinta, con sus propios permisos.
• systemd-resolved usa una identidad dedicada del sistema.
• Solo lo estrictamente necesario (systemd, sshd) corre como root.

Esto es el principio de mínimo privilegio aplicado mediante el modelo multiusuario, y lo desarrollaremos en Principios de Protección y Control de Acceso.

Un sistema monotarea ejecuta un programa cada vez (MS-DOS, el firmware más simple de un microcontrolador). Un sistema multitarea mantiene varios en ejecución concurrente. Y dentro de la multitarea hay una distinción decisiva:

La historia ya dictó sentencia sobre esto: todos los sistemas de propósito general son hoy apropiativos, porque un sistema no puede depender de la buena voluntad de los programas que ejecuta. Si agregador entrara en un bucle infinito en un sistema cooperativo, meteo-01 dejaría de responder por completo y habría que reiniciarlo físicamente.

Este criterio es el más útil en la práctica, porque describe para qué está afinado el sistema.

Merece la pena detenerse en tres:

• Servidor. No lleva interfaz gráfica, prioriza el rendimiento sostenido sobre la latencia de un clic, y admite ciclos de actualización largos y predecibles. Una distribución de servidor como Debian estable o RHEL ofrece soporte de 5 a 10 años sin cambios incompatibles, lo cual es exactamente lo contrario de lo que quiere un usuario de escritorio.
• Empotrado. El sistema vive dentro de un aparato que no se percibe como un ordenador. Los requisitos cambian radicalmente: arranque en milisegundos, funcionamiento durante años sin reiniciar, consumo de microamperios en reposo y a menudo ausencia total de disco y de gestión de memoria virtual.
• Distribuido. Un sistema operativo distribuido genuino presenta varias máquinas como si fueran una sola. Es una idea académicamente bonita que apenas se usa en su forma pura; en la práctica lo que se hace es poner una capa de orquestación encima de sistemas operativos normales. Lo verás en El Sistema Operativo en la Nube.

Dos precisiones que casi siempre se pasan por alto:

• Libre no significa gratis en el sentido relevante. Red Hat Enterprise Linux es software libre y cuesta dinero: lo que se paga no es la licencia sino el soporte, la certificación y las actualizaciones garantizadas. Para una empresa, esa diferencia importa más que el precio.
• Dentro del software libre hay dos familias de licencia. Las copyleft (GPL, la del núcleo Linux) obligan a que las obras derivadas se distribuyan también como libres. Las permisivas (BSD, MIT, Apache) permiten crear derivados propietarios; por eso partes de FreeBSD están dentro de macOS y de la consola PlayStation.

Reunimos todo en una tabla de decisión. Las columnas son las preguntas que de verdad se hacen al elegir un sistema:

Y el orden en que conviene hacerse las preguntas:

1. ¿Hay plazos que incumplir sea inaceptable? Si sí, tiempo real duro; el resto de criterios pasan a segundo plano.
2. ¿Cuántos recursos hay? Con kilobytes de RAM, un sistema de propósito general está descartado.
3. ¿Quién y cómo lo va a operar? Un equipo que administra por SSH no necesita entorno gráfico.
4. ¿Cuánto debe durar el despliegue sin tocarse? Determina si necesitas una versión con soporte extendido.
5. ¿Qué ecosistema necesitas? A veces la decisión la impone una biblioteca o un cliente que solo existe para un sistema.
6. ¿Qué riesgo de dependencia del proveedor aceptas?

Meteora tiene que decidir tres sistemas operativos distintos. Veamos el razonamiento completo.

Elección: Linux de servidor, distribución estable (Debian stable o RHEL).

Un matiz importante: elegir "Linux" no cierra la decisión, hay que elegir distribución. Una distribución de actualización continua como Arch daría software más moderno, pero los cambios frecuentes son un riesgo en producción. Meteora prefiere versiones más antiguas pero con parches de seguridad garantizados durante años.

Elección: sistema de tiempo real empotrado, tipo FreeRTOS o Zephyr, sobre un microcontrolador.

El razonamiento cambia por completo:

• Recursos: un microcontrolador típico tiene 64-256 KB de RAM y no tiene disco. Linux, incluso en versión reducida, necesita al menos varios megabytes y una MMU. Está descartado por tamaño.
• Energía: la estación funciona con batería y panel solar. El sistema debe pasar la mayor parte del tiempo dormido y despertar solo para medir y transmitir. Un RTOS ofrece control fino sobre los modos de bajo consumo.
• Determinismo: el muestreo del sensor debe hacerse a intervalos regulares. No es tiempo real duro en el sentido de "muere alguien si falla", pero sí requiere previsibilidad: una lectura desplazada 300 ms corrompe la serie temporal.
• Fiabilidad sin mantenimiento: la estación puede estar en una montaña, inaccesible durante meses. Debe recuperarse sola de cualquier fallo (temporizador de vigilancia o watchdog) y no debe tener fugas de memoria acumulativas.
• Sin interfaz: no hay pantalla ni teclado. Toda la interacción es por radio.

Una excepción razonable: si una estación tuviera que hacer procesado local pesado (por ejemplo, análisis de imagen de una cámara), la elección cambiaría a un Linux empotrado construido con Yocto o Buildroot sobre un SoC más potente. El criterio de recursos manda sobre el resto.

Elección: Android e iOS, es decir, ninguna elección real.

Aquí el análisis técnico es casi irrelevante porque la decisión la impone el mercado: los clientes ya tienen el dispositivo y el sistema. Lo interesante es entender qué aporta ese sistema a la app de Meteora:

• Aislamiento por aplicación: cada app se ejecuta con su propio identificador de usuario y solo puede acceder a su directorio privado. Es el modelo multiusuario clásico reutilizado para separar aplicaciones en lugar de personas.
• Permisos explícitos: acceder a la ubicación para mostrar la estación más cercana requiere consentimiento del usuario, gestionado por el sistema.
• Gestión agresiva de energía: el sistema puede suspender o matar la app en segundo plano. Meteora no puede asumir que su app siga viva; debe usar los mecanismos de notificación del sistema en lugar de sondear cada minuto.
• Ciclo de vida controlado por el sistema: la app no decide cuándo termina.

La conclusión de este caso es la más valiosa de la lección: la misma empresa, con el mismo producto, necesita tres sistemas operativos de tipos completamente distintos, y la razón no es el gusto de nadie sino las restricciones de cada entorno.

• Tratar los criterios como excluyentes. "¿Linux es multiusuario o multitarea?" es una pregunta mal planteada: es ambas cosas, porque son dimensiones distintas.
• Creer que tiempo real significa rápido. Significa predecible. Un RTOS suele tener peor rendimiento medio que Linux; lo que garantiza es el peor caso.
• Pensar que multiusuario implica varias personas. El uso dominante hoy es separar servicios, no personas. meteo-01 aprovecha el modelo multiusuario aunque solo lo administre una persona.
• Elegir el sistema por familiaridad y no por requisitos. Instalar Ubuntu Desktop en un servidor porque "es el que conozco" añade cientos de paquetes innecesarios, consumo de memoria y superficie de ataque.
• Olvidar que "Linux" no es una decisión completa. Elegir entre Debian, Alpine, RHEL o una imagen construida con Yocto cambia más cosas en la práctica que elegir entre Linux y FreeBSD.
• Consejo: cuando tengas que justificar una elección, escribe primero los requisitos no funcionales (latencia, disponibilidad, memoria, vida útil, quién opera) y solo después mira qué sistemas los cumplen. Al revés siempre se acaba justificando la opción que ya se había decidido.

Clasifica cada sistema en las cuatro dimensiones vistas (modo de procesamiento, usuarios, tareas, ámbito y licencia). Si alguna dimensión no aplica o es ambigua, explica por qué:

1. El firmware de un microondas.
2. Android en un teléfono.
3. Debian en meteo-01.
4. MS-DOS en 1985.

Meteora quiere añadir un sistema de alerta temprana: si una estación detecta una caída de presión superior a 5 hPa en 10 minutos, debe emitir un aviso. Se plantean dos diseños:

• (A) La estación detecta la condición localmente y transmite una alerta prioritaria.
• (B) La estación transmite todo normalmente y agregador en meteo-01 detecta la condición.

Analiza qué tipo de sistema operativo requiere cada diseño y qué compromisos implica cada uno en términos de latencia, consumo de energía, fiabilidad y complejidad.

Un compañero propone instalar en meteo-01 una distribución de actualización continua (rolling release) "para tener siempre lo último y no quedarnos atrás en seguridad". Escribe una respuesta razonada de al menos cuatro argumentos, señalando también en qué caso su propuesta sí sería la correcta.

Solución 1

1. Firmware de un microondas

• Modo de procesamiento: tiempo real blando. Debe reaccionar al teclado y al temporizador con plazos, pero un retraso de 100 ms no causa daño. Algunos aspectos de seguridad (cortar el magnetrón al abrir la puerta) se resuelven normalmente en hardware, no en software.
• Usuarios: monousuario, o más bien "sin concepto de usuario": no hay identidades ni permisos.
• Tareas: monotarea o multitarea muy simple con un bucle de eventos.
• Ámbito: empotrado.
• Licencia: propietaria casi siempre, aunque puede usar un núcleo libre como FreeRTOS por debajo.

2. Android en un teléfono

• Modo: interactivo, con componentes de tiempo real blando (audio, vídeo).
• Usuarios: multiusuario en su implementación (cada app tiene su UID) aunque monousuario de cara a la persona en la mayoría de dispositivos. Es el ejemplo perfecto de que la dimensión "usuarios" se usa hoy para aislar software, no personas.
• Tareas: multitarea apropiativa, con la particularidad de que el sistema puede matar apps en segundo plano para ahorrar batería.
• Ámbito: móvil.
• Licencia: mixta. El núcleo Linux es GPL, el resto de AOSP es Apache 2.0 (libre), pero las capas de Google (Play Services) son propietarias. Un buen ejemplo de que la dimensión de licencia rara vez es binaria.

3. Debian en meteo-01

• Modo: interactivo/tiempo compartido, con trabajos por lotes nocturnos. No es tiempo real.
• Usuarios: multiusuario.
• Tareas: multitarea apropiativa.
• Ámbito: servidor.
• Licencia: libre, mayoritariamente GPL.

4. MS-DOS en 1985

• Modo: interactivo, en el sentido limitado de que respondía a un usuario en un terminal.
• Usuarios: monousuario, sin ningún concepto de identidad ni permisos.
• Tareas: monotarea. Existían trucos (los programas TSR, residentes en memoria) que simulaban concurrencia, pero sin apropiación ni protección.
• Ámbito: escritorio/personal.
• Licencia: propietaria.

Solución 2

Diseño A: detección en la estación

• Sistema requerido: el mismo RTOS empotrado, pero con más lógica. Hay que mantener una ventana deslizante de las últimas lecturas en RAM, lo que consume memoria (10 minutos a una lectura por minuto son 10 valores de presión, unos 40 bytes: perfectamente asumible incluso en 64 KB).
• Latencia: excelente. La alerta se emite en el mismo instante de la detección, sin depender de la red ni del ciclo de agregación. Si el ciclo normal de transmisión es de 15 minutos, esto ahorra hasta 15 minutos de retraso.
• Energía: peor en dos sentidos. Hay que despertar el microcontrolador para evaluar la condición en cada lectura (aunque el cálculo es trivial y cuesta microsegundos) y, sobre todo, hay que activar la radio fuera del ciclo previsto, que es lo que de verdad consume.
• Fiabilidad: mejor ante fallos de red o del servidor, porque la detección no depende de que la lectura llegue. Peor ante fallos del propio sensor: una estación con un sensor defectuoso puede generar falsas alertas sin que nadie las contraste.
• Complejidad: alta a medio plazo. Cambiar el umbral de 5 hPa a 4 hPa exige actualizar el firmware de cientos de estaciones desplegadas en el campo, lo que requiere un mecanismo de actualización remota fiable, que es de las cosas más delicadas de un sistema empotrado.

Diseño B: detección en el servidor

• Sistema requerido: ninguno nuevo. La estación sigue siendo tonta y agregador en Linux se encarga.
• Latencia: peor. Depende del ciclo de transmisión más el ciclo de agregación. Si agregador procesa cada 5 minutos y la estación transmite cada 15, el retraso puede llegar a 20 minutos.
• Energía: sin cambios, que es una ventaja considerable.
• Fiabilidad: peor ante cortes de red, pero mejor en detección de anomalías, porque el servidor puede contrastar con estaciones vecinas y descartar una caída de presión que solo ve una estación como probable fallo de sensor.
• Complejidad: mucho menor. Cambiar el umbral es modificar /etc/meteora/meteora.conf y reiniciar un servicio.

Recomendación razonada: empezar por B, porque es reversible y barato, y pasar a A (o a un diseño híbrido: detección local con umbral conservador más confirmación en servidor) solo si se demuestra que la latencia de 20 minutos tiene un coste real para los clientes. Es el principio general de no llevar lógica al borde de la red antes de que un requisito lo exija.

Solución 3

Argumentos contra la propuesta:

1. Seguridad no equivale a última versión. Una distribución estable como Debian aplica backports de los parches de seguridad sobre versiones antiguas. Recibes la corrección sin recibir los cambios de comportamiento. La premisa de que "no actualizar la versión = estar inseguro" es falsa.
2. Cada actualización es un riesgo de indisponibilidad. En una rolling release, cientos de paquetes cambian cada semana, incluidos bibliotecas de las que dependen ingestor, agregador y meteo-api. Un cambio incompatible en una biblioteca puede tumbar el servicio en un momento no elegido.
3. Los cambios no son atómicos ni reversibles fácilmente. Volver atrás en una rolling release es notoriamente difícil, mientras que una distribución estable ofrece un camino de actualización probado entre versiones concretas.
4. El coste operativo se multiplica. Actualizar continuamente exige probar continuamente. Meteora tendría que mantener un entorno de pruebas equivalente y validar cada semana, cuando su valor está en los datos meteorológicos, no en administrar el sistema.
5. La superficie de cambio no aporta valor al negocio. Tener una versión más reciente de una biblioteca gráfica en un servidor sin entorno gráfico no aporta nada.

Cuándo sí tendría razón el compañero:

• Si el servicio dependiera de una funcionalidad muy reciente del núcleo o de una biblioteca (por ejemplo, un driver para hardware nuevo o una función de red no disponible en la versión estable).
• En un entorno de desarrollo local, donde un fallo no afecta a los clientes y conviene detectar pronto incompatibilidades futuras.
• Si la aplicación se desplegara en contenedores con imágenes inmutables, donde el sistema base del anfitrión importa menos y las actualizaciones son reversibles: basta con volver a desplegar la imagen anterior. Esto lo verás en Contenedores: Namespaces y cgroups.

Los sistemas operativos se clasifican en dimensiones independientes y simultáneas: modo de procesamiento (lotes, interactivo, tiempo real duro o blando), número de usuarios y de tareas, ámbito de uso (escritorio, servidor, empotrado, móvil, distribuido, de red) y modelo de licencia. Un sistema real ocupa una posición en todas ellas a la vez, y la clasificación solo es útil si se usa para elegir con criterio, poniendo primero los requisitos no funcionales y después los candidatos.

El caso de Meteora deja la idea central: una misma empresa necesita un Linux de servidor estable para meteo-01, un RTOS empotrado de kilobytes para sus estaciones y los sistemas móviles que impone el mercado para su app. Las restricciones de cada entorno —determinismo, memoria, energía, ecosistema— mandan sobre cualquier preferencia.

Pero fíjate en que, por debajo de esa diversidad, todos hacen lo mismo: gestionan procesos, memoria, almacenamiento, dispositivos, red y seguridad, y ofrecen alguna interfaz. Cambian las prioridades y la escala, no las funciones. En la siguiente lección, Funciones Principales de un Sistema Operativo, recorreremos esas funciones una a una: son el mapa del resto del curso y las seguiremos a través del ciclo de vida completo de una petición HTTP a meteo-api.