Un sistema operatiu no és una categoria única: el microprogramari que governa una estació meteorològica i el nucli Linux d'un servidor de centre de dades resolen el mateix problema de fons, però amb prioritats oposades i amb una diferència de mida de quatre ordres de magnitud. En aquesta lliçó aprendràs a classificar sistemes operatius per criteris independents —mode de processament, nombre d'usuaris i de tasques, àmbit d'ús i model de llicència— i, sobretot, a fer servir aquesta classificació per a allò que de debò serveix: triar. Al final aplicarem el criteri a les tres peces de la infraestructura de Meteora i veuràs que la resposta correcta és diferent en cada cas.

1. Per què classificar: els criteris no són excloents
2. Classificació per mode de processament
3. Classificació per nombre d'usuaris i de tasques
4. Classificació per àmbit d'ús
5. Classificació per llicència i model de desenvolupament
6. Taula comparativa i criteris de tria
7. Cas aplicat: què tria Meteora per a cada peça

El primer error quan s'estudia aquest tema és tractar la classificació com una llista de calaixos on cada sistema cau en un de sol. No funciona així. Els criteris són dimensions independents, i qualsevol sistema real ocupa una posició en totes alhora.

Prenguem Linux a meteo-01:

• Per mode de processament: interactiu/temps compartit, encara que també executa feines per lots durant la nit.
• Per usuaris: multiusuari.
• Per tasques: multitasca apropiativa.
• Per àmbit: de servidor, encara que el mateix nucli es fa servir en escriptori, en mòbils i en sistemes encastats.
• Per llicència: lliure (GPL v2).

El mateix nucli Linux, amb una altra configuració i altres eines al voltant, pot ser un sistema encastat monousuari de 8 MB. Per això la classificació útil no descriu «què és» un sistema, sinó quines prioritats té i per a què està afinat.

Aquest criteri respon a: com arriben les feines al sistema i què s'optimitza en atendre-les?

Les feines s'acumulen i s'executen sense interacció amb l'usuari. El que s'optimitza és la productivitat (throughput): feines completades per hora. Que una feina concreta trigui més tant és si en conjunt se'n processen més.

Sonen antics, però són més vius que mai: la facturació mensual d'un banc, el reentrenament nocturn d'un model, la generació d'informes o el mateix càlcul de mitjanes diàries de Meteora són processament per lots. El que va canviar és l'embolcall: avui es diuen jobs, cron, pipelines o batch workloads.

Explicació del bloc, que és una feina per lots de manual:

• 30 2 * * * són els cinc camps de cron: minut 30, hora 2, qualsevol dia del mes, qualsevol mes, qualsevol dia de la setmana. És a dir, cada dia a les 02:30.
• meteora és l'usuari amb què s'executa. Mai no es fa servir root per a això: si el programa té una fallada, el dany queda limitat al que pot tocar meteora.
• La resta és el programa i els seus arguments.
• No hi ha ningú mirant: la feina s'executa, escriu la seva sortida i acaba. Si falla, ho sabrem pels registres. Aquesta absència d'interactivitat és exactament el que defineix el mode per lots.

El sistema atén usuaris (o clients) que esperen una resposta. El que s'optimitza no és la productivitat total sinó el temps de resposta i la seva previsibilitat.

La conseqüència tècnica és que el planificador ha d'afavorir els processos que fan molta entrada/sortida i poc càlcul, perquè solen ser els interactius. Quan a meteo-01 conviuen agregador (molta CPU) i meteo-api (molta espera de xarxa), el planificador dona preferència al segon precisament per això. Ho estudiaràs a Planificació de la CPU.

Aquí el que importa no és anar de pressa sinó complir terminis. Un sistema de temps real garanteix que una tasca es completa abans d'un instant límit (deadline). La distinció clau:

Una idea contraintuïtiva però fonamental: un sistema de temps real no és un sistema ràpid, és un sistema predictible. Un RTOS sol tenir un rendiment mitjà pitjor que Linux, perquè renuncia a optimitzacions (memòries cau agressives, planificadors adaptatius) el comportament de les quals en el pitjor cas no es pot acotar. Prefereix ser sempre igual de lent que no pas ser normalment molt ràpid i de vegades imprevisible.

Pots comprovar a meteo-01 que Linux ofereix polítiques de planificació de temps real tou:

Què significa aquesta sortida:

• chrt consulta i modifica les polítiques de planificació en temps real. L'opció -m mostra els rangs de prioritat disponibles.
• SCHED_OTHER és la política normal, la que fan servir ingestor, agregador i meteo-api. No té prioritats de temps real (rang 0/0).
• SCHED_FIFO i SCHED_RR són polítiques de temps real tou amb 99 nivells de prioritat. Un procés SCHED_FIFO s'executa fins que es bloqueja o cedeix voluntàriament: pot monopolitzar un nucli.
• SCHED_DEADLINE permet declarar un termini explícit, i el nucli comprova que el conjunt de tasques sigui admissible.

Fins i tot amb aquestes polítiques, Linux estàndard no és un sistema de temps real dur: no garanteix una cota màxima de latència en tots els casos. Per a això existeixen sistemes com QNX, VxWorks, FreeRTOS o Zephyr, o pedaços com PREEMPT_RT. El tema complet és a Sistemes Operatius Mòbils i de Temps Real.

Són dues dimensions diferents que sovint es confonen.

Un sistema multiusuari manté identitats separades amb recursos i permisos propis, i garanteix que un usuari no accedeix a allò que és d'un altre. No requereix que hi hagi diverses persones connectades alhora: meteo-01 és multiusuari encara que ningú no hi iniciï sessió, perquè cada servei corre amb una identitat diferent.

De fet, aquest és l'ús més important avui del model multiusuari: no separar persones, sinó separar serveis.

Interpretació:

• Els tres processos de Meteora corren com a meteora, no com a root. Si un atacant compromet meteo-api, només obté els permisos de meteora: pot llegir /var/lib/meteora/, però no modificar el sistema.
• nginx corre com a www-data, una altra identitat diferent, amb els seus propis permisos.
• systemd-resolved fa servir una identitat dedicada del sistema.
• Només allò estrictament necessari (systemd, sshd) corre com a root.

Això és el principi de privilegi mínim aplicat mitjançant el model multiusuari, i el desenvoluparem a Principis de Protecció i Control d'Accés.

Un sistema monotasca executa un programa cada vegada (MS-DOS, el microprogramari més simple d'un microcontrolador). Un sistema multitasca en manté diversos en execució concurrent. I dins la multitasca hi ha una distinció decisiva:

La història ja va dictar sentència sobre això: tots els sistemes de propòsit general són avui apropiatius, perquè un sistema no pot dependre de la bona voluntat dels programes que executa. Si agregador entrés en un bucle infinit en un sistema cooperatiu, meteo-01 deixaria de respondre del tot i s'hauria de reiniciar físicament.

Aquest criteri és el més útil a la pràctica, perquè descriu per a què està afinat el sistema.

Val la pena aturar-se en tres:

• Servidor. No porta interfície gràfica, prioritza el rendiment sostingut sobre la latència d'un clic, i admet cicles d'actualització llargs i predictibles. Una distribució de servidor com Debian estable o RHEL ofereix suport de 5 a 10 anys sense canvis incompatibles, cosa que és exactament el contrari del que vol un usuari d'escriptori.
• Encastat. El sistema viu dins d'un aparell que no es percep com un ordinador. Els requisits canvien radicalment: arrencada en mil·lisegons, funcionament durant anys sense reiniciar, consum de microampers en repòs i sovint absència total de disc i de gestió de memòria virtual.
• Distribuït. Un sistema operatiu distribuït genuí presenta diverses màquines com si fossin una de sola. És una idea acadèmicament bonica que amb prou feines es fa servir en la seva forma pura; a la pràctica el que es fa és posar una capa d'orquestració sobre sistemes operatius normals. Ho veuràs a El Sistema Operatiu al Núvol.

Dues precisions que gairebé sempre es passen per alt:

• Lliure no vol dir gratuït en el sentit rellevant. Red Hat Enterprise Linux és programari lliure i costa diners: el que es paga no és la llicència sinó el suport, la certificació i les actualitzacions garantides. Per a una empresa, aquesta diferència importa més que el preu.
• Dins el programari lliure hi ha dues famílies de llicència. Les copyleft (GPL, la del nucli Linux) obliguen que les obres derivades es distribueixin també com a lliures. Les permissives (BSD, MIT, Apache) permeten crear derivats propietaris; per això parts de FreeBSD són dins de macOS i de la consola PlayStation.

Ho reunim tot en una taula de decisió. Les columnes són les preguntes que de debò es fan a l'hora de triar un sistema:

I l'ordre en què convé fer-se les preguntes:

1. Hi ha terminis que incomplir sigui inacceptable? Si és que sí, temps real dur; la resta de criteris passen a segon pla.
2. Quants recursos hi ha? Amb kilobytes de RAM, un sistema de propòsit general queda descartat.
3. Qui l'operarà i com? Un equip que administra per SSH no necessita entorn gràfic.
4. Quant ha de durar el desplegament sense tocar-lo? Determina si necessites una versió amb suport estès.
5. Quin ecosistema necessites? De vegades la decisió la imposa una biblioteca o un client que només existeix per a un sistema.
6. Quin risc de dependència del proveïdor acceptes?

Meteora ha de decidir tres sistemes operatius diferents. Vegem-ne el raonament complet.

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

Un matís important: triar «Linux» no tanca la decisió, cal triar distribució. Una distribució d'actualització contínua com Arch donaria programari més modern, però els canvis freqüents són un risc en producció. Meteora prefereix versions més antigues però amb pedaços de seguretat garantits durant anys.

Tria: sistema de temps real encastat, tipus FreeRTOS o Zephyr, sobre un microcontrolador.

El raonament canvia del tot:

• Recursos: un microcontrolador típic té 64-256 KB de RAM i no té disc. Linux, fins i tot en versió reduïda, necessita com a mínim uns quants megabytes i una MMU. Queda descartat per mida.
• Energia: l'estació funciona amb bateria i panell solar. El sistema ha de passar la major part del temps adormit i despertar-se només per mesurar i transmetre. Un RTOS ofereix control fi sobre els modes de baix consum.
• Determinisme: el mostreig del sensor s'ha de fer a intervals regulars. No és temps real dur en el sentit de «mor algú si falla», però sí que requereix previsibilitat: una lectura desplaçada 300 ms corromp la sèrie temporal.
• Fiabilitat sense manteniment: l'estació pot ser en una muntanya, inaccessible durant mesos. S'ha de recuperar sola de qualsevol fallada (temporitzador de vigilància o watchdog) i no ha de tenir fuites de memòria acumulatives.
• Sense interfície: no hi ha pantalla ni teclat. Tota la interacció és per ràdio.

Una excepció raonable: si una estació hagués de fer processament local pesant (per exemple, anàlisi d'imatge d'una càmera), la tria canviaria a un Linux encastat construït amb Yocto o Buildroot sobre un SoC més potent. El criteri de recursos mana sobre la resta.

Tria: Android i iOS, és a dir, cap tria real.

Aquí l'anàlisi tècnica és gairebé irrellevant perquè la decisió la imposa el mercat: els clients ja tenen el dispositiu i el sistema. El que és interessant és entendre què aporta aquest sistema a l'app de Meteora:

• Aïllament per aplicació: cada app s'executa amb el seu propi identificador d'usuari i només pot accedir al seu directori privat. És el model multiusuari clàssic reutilitzat per separar aplicacions en comptes de persones.
• Permisos explícits: accedir a la ubicació per mostrar l'estació més propera requereix consentiment de l'usuari, gestionat pel sistema.
• Gestió agressiva d'energia: el sistema pot suspendre o matar l'app en segon pla. Meteora no pot pressuposar que la seva app continuï viva; ha de fer servir els mecanismes de notificació del sistema en comptes de sondejar cada minut.
• Cicle de vida controlat pel sistema: l'app no decideix quan acaba.

La conclusió d'aquest cas és la més valuosa de la lliçó: la mateixa empresa, amb el mateix producte, necessita tres sistemes operatius de tipus completament diferents, i la raó no és el gust de ningú sinó les restriccions de cada entorn.

• Tractar els criteris com a excloents. «Linux és multiusuari o multitasca?» és una pregunta mal plantejada: és totes dues coses, perquè són dimensions diferents.
• Creure que temps real vol dir ràpid. Vol dir predictible. Un RTOS sol tenir pitjor rendiment mitjà que Linux; el que garanteix és el pitjor cas.
• Pensar que multiusuari implica diverses persones. L'ús dominant avui és separar serveis, no persones. meteo-01 aprofita el model multiusuari encara que només l'administri una persona.
• Triar el sistema per familiaritat i no per requisits. Instal·lar Ubuntu Desktop en un servidor perquè «és el que conec» hi afegeix centenars de paquets innecessaris, consum de memòria i superfície d'atac.
• Oblidar que «Linux» no és una decisió completa. Triar entre Debian, Alpine, RHEL o una imatge construïda amb Yocto canvia més coses a la pràctica que triar entre Linux i FreeBSD.
• Consell: quan hagis de justificar una tria, escriu primer els requisits no funcionals (latència, disponibilitat, memòria, vida útil, qui l'opera) i només després mira quins sistemes els compleixen. A l'inrevés sempre s'acaba justificant l'opció que ja s'havia decidit.

Classifica cada sistema en les quatre dimensions vistes (mode de processament, usuaris, tasques, àmbit i llicència). Si alguna dimensió no s'hi aplica o és ambigua, explica per què:

1. El microprogramari d'un microones.
2. Android en un telèfon.
3. Debian a meteo-01.
4. MS-DOS el 1985.

Meteora vol afegir un sistema d'alerta primerenca: si una estació detecta una caiguda de pressió superior a 5 hPa en 10 minuts, ha d'emetre un avís. Es plantegen dos dissenys:

• (A) L'estació detecta la condició localment i transmet una alerta prioritària.
• (B) L'estació transmet tot normalment i agregador a meteo-01 detecta la condició.

Analitza quin tipus de sistema operatiu requereix cada disseny i quins compromisos implica cadascun en termes de latència, consum d'energia, fiabilitat i complexitat.

Un company proposa instal·lar a meteo-01 una distribució d'actualització contínua (rolling release) «per tenir sempre l'última cosa i no quedar-nos enrere en seguretat». Escriu una resposta raonada amb almenys quatre arguments, assenyalant també en quin cas la seva proposta sí que seria la correcta.

Solució 1

1. Microprogramari d'un microones

• Mode de processament: temps real tou. Ha de reaccionar al teclat i al temporitzador amb terminis, però un retard de 100 ms no causa cap dany. Alguns aspectes de seguretat (tallar el magnetró en obrir la porta) es resolen normalment en maquinari, no en programari.
• Usuaris: monousuari, o més aviat «sense concepte d'usuari»: no hi ha identitats ni permisos.
• Tasques: monotasca o multitasca molt simple amb un bucle d'esdeveniments.
• Àmbit: encastat.
• Llicència: propietària gairebé sempre, encara que pot fer servir un nucli lliure com FreeRTOS per sota.

2. Android en un telèfon

• Mode: interactiu, amb components de temps real tou (àudio, vídeo).
• Usuaris: multiusuari en la seva implementació (cada app té el seu UID) encara que monousuari de cara a la persona en la majoria de dispositius. És l'exemple perfecte que la dimensió «usuaris» es fa servir avui per aïllar programari, no persones.
• Tasques: multitasca apropiativa, amb la particularitat que el sistema pot matar apps en segon pla per estalviar bateria.
• Àmbit: mòbil.
• Llicència: mixta. El nucli Linux és GPL, la resta d'AOSP és Apache 2.0 (lliure), però les capes de Google (Play Services) són propietàries. Un bon exemple que la dimensió de llicència poques vegades és binària.

3. Debian a meteo-01

• Mode: interactiu/temps compartit, amb feines per lots nocturnes. No és temps real.
• Usuaris: multiusuari.
• Tasques: multitasca apropiativa.
• Àmbit: servidor.
• Llicència: lliure, majoritàriament GPL.

4. MS-DOS el 1985

• Mode: interactiu, en el sentit limitat que responia a un usuari en un terminal.
• Usuaris: monousuari, sense cap concepte d'identitat ni de permisos.
• Tasques: monotasca. Hi havia trucs (els programes TSR, residents a la memòria) que simulaven concurrència, però sense apropiació ni protecció.
• Àmbit: escriptori/personal.
• Llicència: propietària.

Solució 2

Disseny A: detecció a l'estació

• Sistema requerit: el mateix RTOS encastat, però amb més lògica. Cal mantenir una finestra lliscant de les últimes lectures a la RAM, cosa que consumeix memòria (10 minuts a una lectura per minut són 10 valors de pressió, uns 40 bytes: perfectament assumible fins i tot en 64 KB).
• Latència: excel·lent. L'alerta s'emet en el mateix instant de la detecció, sense dependre de la xarxa ni del cicle d'agregació. Si el cicle normal de transmissió és de 15 minuts, això estalvia fins a 15 minuts de retard.
• Energia: pitjor en dos sentits. Cal despertar el microcontrolador per avaluar la condició a cada lectura (encara que el càlcul és trivial i costa microsegons) i, sobretot, cal activar la ràdio fora del cicle previst, que és el que de debò consumeix.
• Fiabilitat: millor davant de fallades de xarxa o del servidor, perquè la detecció no depèn que la lectura hi arribi. Pitjor davant de fallades del sensor mateix: una estació amb un sensor defectuós pot generar falses alertes sense que ningú les contrasti.
• Complexitat: alta a mitjà termini. Canviar el llindar de 5 hPa a 4 hPa exigeix actualitzar el microprogramari de centenars d'estacions desplegades al camp, cosa que requereix un mecanisme d'actualització remota fiable, que és de les coses més delicades d'un sistema encastat.

Disseny B: detecció al servidor

• Sistema requerit: cap de nou. L'estació continua sent ximple i agregador a Linux se n'encarrega.
• Latència: pitjor. Depèn del cicle de transmissió més el cicle d'agregació. Si agregador processa cada 5 minuts i l'estació transmet cada 15, el retard pot arribar als 20 minuts.
• Energia: sense canvis, cosa que és un avantatge considerable.
• Fiabilitat: pitjor davant de talls de xarxa, però millor en detecció d'anomalies, perquè el servidor pot contrastar amb estacions veïnes i descartar una caiguda de pressió que només veu una estació com a probable fallada de sensor.
• Complexitat: molt menor. Canviar el llindar és modificar /etc/meteora/meteora.conf i reiniciar un servei.

Recomanació raonada: començar per B, perquè és reversible i barat, i passar a A (o a un disseny híbrid: detecció local amb llindar conservador més confirmació al servidor) només si es demostra que la latència de 20 minuts té un cost real per als clients. És el principi general de no portar lògica a la vora de la xarxa abans que un requisit ho exigeixi.

Solució 3

Arguments contra la proposta:

1. Seguretat no equival a última versió. Una distribució estable com Debian aplica backports dels pedaços de seguretat sobre versions antigues. Reps la correcció sense rebre els canvis de comportament. La premissa que «no actualitzar la versió = estar insegur» és falsa.
2. Cada actualització és un risc d'indisponibilitat. En una rolling release, centenars de paquets canvien cada setmana, incloses biblioteques de les quals depenen ingestor, agregador i meteo-api. Un canvi incompatible en una biblioteca pot tombar el servei en un moment no triat.
3. Els canvis no són atòmics ni reversibles fàcilment. Tornar enrere en una rolling release és notòriament difícil, mentre que una distribució estable ofereix un camí d'actualització provat entre versions concretes.
4. El cost operatiu es multiplica. Actualitzar contínuament exigeix provar contínuament. Meteora hauria de mantenir un entorn de proves equivalent i validar cada setmana, quan el seu valor són les dades meteorològiques, no administrar el sistema.
5. La superfície de canvi no aporta valor al negoci. Tenir una versió més recent d'una biblioteca gràfica en un servidor sense entorn gràfic no aporta res.

Quan sí que tindria raó el company:

• Si el servei depengués d'una funcionalitat molt recent del nucli o d'una biblioteca (per exemple, un driver per a maquinari nou o una funció de xarxa no disponible a la versió estable).
• En un entorn de desenvolupament local, on una fallada no afecta els clients i convé detectar aviat incompatibilitats futures.
• Si l'aplicació es desplegués en contenidors amb imatges immutables, on el sistema base de l'amfitrió importa menys i les actualitzacions són reversibles: n'hi ha prou de tornar a desplegar la imatge anterior. Això ho veuràs a Contenidors: Namespaces i cgroups.

Els sistemes operatius es classifiquen en dimensions independents i simultànies: mode de processament (lots, interactiu, temps real dur o tou), nombre d'usuaris i de tasques, àmbit d'ús (escriptori, servidor, encastat, mòbil, distribuït, de xarxa) i model de llicència. Un sistema real ocupa una posició en totes alhora, i la classificació només és útil si es fa servir per triar amb criteri, posant primer els requisits no funcionals i després els candidats.

El cas de Meteora deixa la idea central: una mateixa empresa necessita un Linux de servidor estable per a meteo-01, un RTOS encastat de kilobytes per a les seves estacions i els sistemes mòbils que imposa el mercat per a la seva app. Les restriccions de cada entorn —determinisme, memòria, energia, ecosistema— manen sobre qualsevol preferència.

Però fixa't que, per sota d'aquesta diversitat, tots fan el mateix: gestionen processos, memòria, emmagatzematge, dispositius, xarxa i seguretat, i ofereixen alguna interfície. Canvien les prioritats i l'escala, no les funcions. A la lliçó següent, Funcions Principals d'un Sistema Operatiu, recorrerem aquestes funcions una a una: són el mapa de la resta del curs i les seguirem a través del cicle de vida complet d'una petició HTTP a meteo-api.