Cada dia fas servir un sistema operatiu, però segurament no n'has vist mai cap. El que veus és l'escriptori, el terminal o el navegador; el sistema operatiu és la capa invisible que hi ha a sota i que fa possible que aquests programes existeixin. En aquesta lliçó entendràs quin problema concret resol un sistema operatiu, per què escriure programari sense ell seria insuportable, i quines són les abstraccions que va inventar perquè avui puguis obrir un fitxer amb una sola línia de codi sense saber si és en un disc SSD, en un disc mecànic o en un servidor remot. També coneixeràs Meteora, l'empresa fictícia el servidor Linux de la qual ens acompanyarà durant tot el curs: cada concepte que aprenguis el veuràs aplicat sobre la seva màquina meteo-01.

1. Benvingut a Meteora: l'escenari de tot el curs
2. El problema: maquinari nu i programes que volen conviure
3. Primer paper del SO: la màquina estesa
4. Segon paper del SO: el gestor de recursos
5. Repàs mínim del maquinari que gestiona el SO
6. Les abstraccions fonamentals
7. Anatomia d'un sistema: nucli, biblioteques, shell i aplicacions
8. Què NO és un sistema operatiu
9. Com cada capa sosté meteo-api

Meteora és una empresa (fictícia) que ven dades meteorològiques. Té desplegades centenars d'estacions que mesuren temperatura, humitat i pressió, i ofereix aquestes dades als seus clients mitjançant una API HTTP. Tota la seva infraestructura viu en un únic servidor Linux anomenat meteo-01, i el servei es compon de tres peces que reapareixeran a cada mòdul:

Les convencions de Meteora són fixes durant tot el curs; convé que les memoritzis ara perquè les farem servir sense tornar-les a explicar:

• Dades: /var/lib/meteora/lectures/, amb un fitxer per dia, per exemple 2026-08-31.dat.
• Configuració: /etc/meteora/meteora.conf.
• Registres: /var/log/meteora/meteo-api.log.
• Usuari i grup del sistema: meteora:meteora.
• Estructura de dades recurrent: Lectura, amb els camps estacio_id, timestamp, temperatura, humitat i pressio.

En C, aquesta estructura es declara així:

Repassem el bloc camp per camp, perquè el reutilitzarem moltes vegades:

• #include <stdint.h> dona accés a tipus de mida garantida. uint32_t ocupa exactament 4 bytes en qualsevol màquina, mentre que un int normal podria ocupar-ne 2, 4 o 8 segons el compilador. Quan escrius dades binàries al disc o les envies per xarxa, la mida exacta importa.
• estacio_id és un enter sense signe: no hi ha estacions amb identificador negatiu, així que aprofitem tot el rang.
• timestamp és un int64_t perquè un int32_t desbordaria l'any 2038 (el famós year 2038 problem).
• temperatura, humitat i pressio són float (4 bytes). Amb la precisió d'un sensor real, uns 7 dígits significatius ja fan de sobres.

En total, l'estructura ocupa 24 bytes (4 + 8 + 4 + 4 + 4 = 24, sense farciment addicional en x86-64 gràcies al fet que el camp de 8 bytes queda alineat). Amb 500 estacions enviant una lectura per minut, això són 720.000 lectures al dia, uns 17 MB diaris. Recorda aquests números: els farem servir per raonar sobre memòria i disc.

Imagina't que a meteo-01 no hi hagués sistema operatiu. El programa ingestor arrenca tot sol, amb accés directe al maquinari. Per desar una lectura al disc hauria de:

1. Saber quin model de controladora de disc porta la màquina.
2. Escriure valors concrets als registres d'aquesta controladora per indicar sector, capçal i nombre de blocs.
3. Esperar activament que el disc confirmi l'operació.
4. Interpretar els codis d'error específics del fabricant.

I això només per a un model de disc. Si demà Meteora canvia de servidor, cal reescriure el programa. A més, si agregador es volgués executar alhora, tots dos programes escriurien al mateix disc sense coordinació: es trepitjarien els sectors mútuament i corromprien les dades.

D'aquí surten els dos problemes fonamentals que resol un sistema operatiu:

• La complexitat: el maquinari és difícil, heterogeni i desagradable de programar.
• La compartició: diversos programes volen fer servir alhora recursos que són limitats i, molts d'ells, indivisibles.

A aquests dos problemes corresponen els dos papers clàssics del SO.

Un sistema operatiu és, abans que res, una màquina virtual més agradable que la real. Agafa un maquinari lleig i n'ofereix a sobre una interfície neta, uniforme i estable. És el que s'anomena màquina estesa o abstracció del maquinari.

Compara les dues maneres de desar una lectura a meteo-01:

A la pràctica, el programa de Meteora escriu una lectura així:

Què fa cada línia i per què:

• open(...) demana al sistema operatiu accés a un fitxer pel seu nom. El SO tradueix aquest nom a una ubicació física; el programa no veu mai sectors.
  • O_WRONLY: només escriurem.
  • O_CREAT: si el fitxer del dia encara no existeix, crea'l.
  • O_APPEND: cada escriptura s'afegeix al final. És important: garanteix que dues escriptures no es trepitgin encara que hi hagi diversos processos escrivint.
  • 0640: permisos del fitxer si cal crear-lo (lectura i escriptura per a l'usuari meteora, lectura per al grup meteora, res per a la resta). Els veurem en detall a Seguretat i Permisos de Fitxers.
• open retorna un descriptor de fitxer (fd): un simple nombre enter que el SO fa servir com a identificador d'aquesta connexió oberta. És una abstracció pura: no existeix físicament.
• write(fd, &l, sizeof(l)) lliura 24 bytes al nucli. El programa no sap (ni li importa) si acaben en un SSD NVMe o en un disc de xarxa.
• close(fd) allibera el descriptor.

Aquest grapat de línies funciona igual en un portàtil, en un servidor i en una Raspberry Pi. Aquesta portabilitat és el producte que ven el sistema operatiu.

L'altra meitat de la feina és repartir. A meteo-01 hi conviuen ingestor, agregador, meteo-api, més els processos del sistema mateix, i tots volen la mateixa CPU, la mateixa memòria i el mateix disc.

El sistema operatiu reparteix els recursos de dues maneres complementàries:

• Multiplexació en el temps: els usuaris del recurs es tornen. És el que passa amb la CPU. Si meteo-01 té 4 nuclis i hi ha 40 processos, el SO dona a cadascun uns quants mil·lisegons i va alternant tan de pressa que sembla simultani. Això s'estudia a Planificació de la CPU.
• Multiplexació en l'espai: el recurs es divideix en trossos i cada usuari es queda amb un. És el que passa amb la memòria RAM i amb el disc. Cada procés rep la seva porció i no pot tocar la dels altres; ho veuràs a Gestió de Memòria.

Gestionar no és només repartir: també implica protegir (que meteo-api no pugui llegir la memòria d'agregador), comptabilitzar (saber quanta CPU consumeix cada procés) i arbitrar conflictes (decidir qui escriu primer quan dos processos demanen el disc alhora).

Un exemple amb números: si agregador engega el seu càlcul horari i consumeix el 100 % d'un nucli durant 20 segons, sense un gestor de recursos meteo-api deixaria de respondre als clients. Amb el planificador del SO, tots dos avancen: meteo-api recupera la CPU tan bon punt arriba una petició de xarxa, perquè el planificador afavoreix els processos que passen molt de temps esperant entrada/sortida.

No cal ser enginyer electrònic, però sí conèixer les peces que el SO administra, perquè gairebé tota decisió de disseny d'un sistema operatiu s'explica per una característica del maquinari.

La CPU executa instruccions en un cicle perpetu: buscar la instrucció següent, descodificar-la i executar-la. Per treballar té uns quants magatzems interns ultraràpids, els registres:

• Registres generals (en x86-64: rax, rbx, rcx…): guarden dades intermèdies.
• Comptador de programa (rip): l'adreça de la instrucció següent.
• Punter de pila (rsp): on és el cim de la pila.
• Registre d'estat (rflags): inclou, entre altres coses, el bit de mode que distingeix si som en mode usuari o en mode nucli. Aquest bit és la base de tota la protecció del sistema i l'estudiarem a Mode Usuari, Mode Nucli i Crides al Sistema.

El conjunt de registres d'un procés és el seu context. Quan el SO canvia d'un procés a un altre, desa tots aquests registres i carrega els del següent: això és el canvi de context.

No existeix una memòria que sigui alhora ràpida, gran i barata, així que se n'apilen diverses. Aquests són ordres de magnitud típics en un servidor actual:

La lectura d'aquesta taula és la clau de gairebé tot el curs: com més baix vas en la jerarquia, més car és l'accés, i en proporcions brutals. Quan agregador llegeix el fitxer del dia des del disc, cada accés costa l'equivalent a 600 accessos a RAM. Per això el SO manté una memòria cau de pàgines a la RAM amb les dades llegides recentment, i per això el segon càlcul horari del mateix dia és molt més ràpid que el primer.

Tot allò que no és CPU ni RAM es connecta mitjançant busos (PCIe, USB, SATA). Cada dispositiu té un controlador (el xip que el maneja) i un controlador de programari o driver (el codi del SO que sap parlar amb aquest xip). Quan un dispositiu acaba la seva feina, avisa la CPU mitjançant una interrupció: un senyal que fa que la CPU deixi el que estava fent i atengui el dispositiu. Els detalls són a Controladors, Interrupcions i Operacions d'E/S.

Un sistema operatiu no és un catàleg de funcions soltes: és un grapat d'idees abstractes ben triades. Aquestes quatre són les que sostenen tota la resta.

Un procés és un programa en execució, amb tot el que necessita per viure: el seu codi, les seves dades, la seva pila, els seus fitxers oberts, la seva identitat d'usuari i el seu estat. És l'abstracció d'«un ordinador per a mi sol».

Què estem veient:

• ps -eo ... llista tots els processos (-e) mostrant només les columnes que demanem (-o).
• pid és l'identificador únic del procés; user, l'usuari propietari (aquí, meteora); comm, el nom de l'executable.
• --sort=-%cpu ordena de major a menor consum de CPU.
• El procés 1 és sempre el primer que arrenca el nucli; en un Linux modern és systemd, que veurem a Serveis, Arrencada i systemd.

Fixa't que agregador és al 98,7 % de CPU i tot i així meteo-api continua viu: això és el gestor de recursos treballant.

Cada procés es pensa que disposa de tota la memòria de la màquina, començant per l'adreça 0. Aquesta il·lusió s'anomena espai d'adreces, i és el que impedeix que una fallada a ingestor corrompi la memòria de meteo-api. Dos processos poden fer servir l'adreça 0x400000 alhora sense col·lidir perquè el maquinari tradueix cada adreça virtual a una de física diferent. És el tema de Memòria Virtual i Paginació.

Un fitxer és una seqüència de bytes amb nom. Res més. No té cap format imposat pel SO: el significat l'hi dona l'aplicació. Els fitxers s'organitzen en directoris, formant un arbre únic que comença a /.

UNIX va portar l'abstracció de fitxer fins al final: gairebé tot es representa com un fitxer. Un disc, un terminal, un generador de nombres aleatoris o fins i tot informació del nucli mateix es llegeixen i s'escriuen amb les mateixes crides.

Explicació:

• La primera lletra dels permisos indica el tipus: b és un dispositiu de blocs (s'hi accedeix per blocs, com a un disc), c és un dispositiu de caràcters (flux de bytes, com un terminal).
• Els números 8, 0 i 1, 3 són el major i el minor: el major identifica quin driver atén el dispositiu, i el minor, quina unitat concreta.
• /proc/1099/status no existeix en cap disc: el nucli el genera al vol quan el llegeixes. Tot i així, es llegeix amb cat com qualsevol fitxer. Aquesta és la potència de l'abstracció: una interfície, moltíssimes implementacions.

Quan algú diu «el sistema operatiu», sol referir-se a un conjunt de capes diferents. Distingir-les evita moltíssima confusió.

Dos matisos importants:

• Només el nucli és imprescindible. Tota la resta són programes ordinaris que s'executen sense privilegis especials i que parlen amb el nucli mitjançant crides al sistema.
• El shell no forma part del nucli. bash és un programa com qualsevol altre: el pots substituir per zsh o fish sense tocar el sistema operatiu. Això demostra que la interfície és intercanviable, no fonamental.

Tres confusions freqüents que convé desactivar ja:

• El SO no és la interfície gràfica. GNOME, KDE o l'escriptori de Windows són aplicacions que s'executen sobre el sistema operatiu. meteo-01 no té cap interfície gràfica instal·lada i funciona perfectament: els servidors poques vegades en porten, perquè consumeix memòria i augmenta la superfície d'atac.
• El SO no és la distribució. Ubuntu, Debian, Fedora o Alpine no són sistemes operatius diferents: totes fan servir el mateix nucli, Linux. El que canvia és el conjunt de programes empaquetats, el gestor de paquets i les decisions de configuració. Quan algú diu «he instal·lat un altre sistema operatiu» en passar d'Ubuntu a Debian, en rigor ha canviat de distribució.
• El SO no és el conjunt d'aplicacions que porta. Un navegador, un editor o un reproductor multimèdia es distribueixen amb el sistema per comoditat, no perquè en formin part.

Un criteri útil per decidir si una cosa forma part del sistema operatiu: s'executa en mode nucli? Si la resposta és sí, forma part del SO en sentit estricte. Si no, és un programa més, per molt imprescindible que sembli.

Tanquem ajuntant-ho tot. Un client demana GET /mitjanes?estacio=118&dia=2026-08-31. Això és el que aporta cada capa:

1. Maquinari: la targeta de xarxa rep el paquet i llança una interrupció.
2. Nucli: el subsistema de xarxa reassembla la petició TCP i la deixa disponible al sòcol de meteo-api. El planificador marca el procés com a llest per executar-se i li assigna CPU.
3. Biblioteques: meteo-api crida funcions de glibc per llegir del sòcol i per obrir el fitxer del dia; glibc tradueix aquestes crides còmodes en crides al sistema.
4. Nucli un altre cop: busca 2026-08-31.dat al sistema de fitxers, comprova que l'usuari meteora té permís de lectura, serveix els blocs des de la memòria cau de pàgines si hi són, o demana al disc que els porti si no hi són.
5. Aplicació: meteo-api calcula la resposta, la serialitza en JSON i l'escriu al sòcol.
6. Nucli, per darrer cop: fragmenta la resposta en paquets i ordena a la targeta de xarxa que els enviï.

Cap d'aquestes capes coneix els detalls de les altres, i aquesta és precisament la raó que el sistema sigui manejable. A Funcions Principals d'un Sistema Operatiu recorrerem aquest mateix camí amb més detall.

• Confondre «sistema operatiu» amb «el que veig a la pantalla». La interfície gràfica és la part més visible i la menys fonamental. Si t'acostumes a treballar en un servidor sense entorn gràfic, el concepte queda clar de seguida.
• Pensar que el SO s'executa contínuament en paral·lel als programes. No és així: el nucli no és un procés que corri sempre. La major part del temps està inactiu, i només entra en acció quan alguna cosa l'invoca (una crida al sistema, una interrupció o una excepció). És més aviat un conjunt de rutines de resposta que no pas un programa perpetu.
• Creure que un fitxer «és» en un lloc del disc que el programa coneix. El programa només coneix un nom i un descriptor. La ubicació física pot canviar (desfragmentació, copy-on-write, sistemes de fitxers en xarxa) sense que l'aplicació se n'assabenti.
• Ignorar la jerarquia de memòria quan raones sobre rendiment. Moltíssims problemes de rendiment que semblen «de CPU» són en realitat d'accés a memòria o a disc. Interioritza els ordres de magnitud de la taula: t'estalviaran hores de diagnòstic erroni.
• Consell pràctic: instal·la una màquina virtual amb una distribució Linux sense entorn gràfic (Debian netinst o Alpine ja fan el fet) i treballa-hi durant el curs. Veure el sistema sense adorns accelera molt la comprensió.

Classifica cadascun d'aquests elements de meteo-01 com a (a) part del nucli, (b) biblioteca del sistema, (c) utilitat o shell, o (d) aplicació. Justifica cada resposta amb el criteri del mode d'execució:

1. El planificador que decideix quin procés fa servir la CPU.
2. bash.
3. glibc.
4. El controlador de la targeta de xarxa.
5. meteo-api.
6. systemctl.

agregador necessita llegir les 720.000 lectures d'un dia (17 MB) per calcular les mitjanes horàries. Fent servir els temps de la taula de jerarquia de memòria, estima l'ordre de magnitud del temps de lectura en dos escenaris: (a) el fitxer no és a la memòria cau i cal llegir-lo d'un SSD NVMe; (b) el fitxer ja és a la memòria cau de pàgines a la RAM. Suposa lectures en blocs de 4 KB i un cost per bloc de 50 µs des de l'SSD i 80 ns des de la RAM. Quina implicació pràctica té la diferència?

Explica, sense fer servir la paraula «abstracció», per què el mateix programa en C que escriu una Lectura amb write() funciona sense canvis en un portàtil amb SSD i en un servidor amb emmagatzematge en xarxa. Indica en quin punt exacte del recorregut desapareix la diferència entre tots dos maquinaris.

Solució 1

El criteri és: s'executa en mode nucli, amb accés directe al maquinari?

1. Planificador → (a) nucli. Decideix quin procés ocupa la CPU i per fer-ho ha de manipular registres i taules internes; és codi privilegiat per definició.
2. bash → (c) utilitat/shell. És un programa d'usuari corrent. La prova és que el pots substituir per zsh sense recompilar res del sistema, i que si bash falla el sistema continua funcionant.
3. glibc → (b) biblioteca del sistema. S'executa en mode usuari, dins l'espai d'adreces del procés que la fa servir. El seu paper és embolcallar les crides al sistema en funcions còmodes (fopen, printf).
4. Controlador de xarxa → (a) nucli. Programa directament els registres del maquinari i atén les seves interrupcions; necessita privilegis. A Linux sol ser un mòdul carregable, però s'executa en mode nucli igualment (ho veuràs a Arquitectura del Nucli).
5. meteo-api → (d) aplicació. És el programari de negoci de Meteora, sense privilegis especials; corre com l'usuari meteora.
6. systemctl → (c) utilitat. Encara que gestioni serveis del sistema, és un client d'usuari que envia ordres a systemd, que al seu torn també és un procés d'usuari (el PID 1). Res d'això no viu al nucli.

Solució 2

Primer, quants blocs de 4 KB hi ha en 17 MB:

(a) Des de l'SSD NVMe, a 50 µs per bloc:

(b) Des de la memòria cau de pàgines a la RAM, a 80 ns per bloc:

La diferència és d'un factor d'unes 600 vegades. La implicació pràctica és doble:

• La primera execució del càlcul horari després d'arrencar la màquina serà perceptiblement més lenta que les següents, encara que el codi sigui idèntic. Si mesures rendiment sense tenir-ho en compte, en trauràs conclusions falses.
• Val moltíssim la pena que el fitxer del dia càpiga a la memòria cau de pàgines. Amb 17 MB diaris, tenir 1 GB de RAM lliure per a memòria cau permet mantenir gairebé dos mesos de dades en memòria, cosa que fa irrellevant el cost del disc per a la feina habitual d'agregador.

(Nota: aquesta estimació ignora la lectura anticipada — readahead — que fa el nucli i que a la pràctica millora molt el cas (a). L'ordre de magnitud de la conclusió no canvia.)

Solució 3

El programa funciona igual perquè no parla amb el disc: parla amb el nucli. L'única cosa que el programa anomena és una cadena de text (/var/lib/meteora/lectures/2026-08-31.dat) i un nombre enter (el descriptor de fitxer). Cap d'aquestes dues coses no depèn del maquinari.

El punt exacte on desapareix la diferència és la crida al sistema write(): a l'altre costat d'aquesta frontera, el nucli consulta quin sistema de fitxers gestiona aquesta ruta i li lliura l'operació. Aquest sistema de fitxers, al seu torn, s'apuntala en un controlador concret —el de l'SSD o el del client de xarxa— i cadascun fa el que correspon amb el seu maquinari.

Dit d'una altra manera: la diferència entre tots dos maquinaris existeix, però viu per sota de la crida al sistema, i el programa no travessa mai aquesta frontera. El nucli ofereix sempre el mateix contracte cap amunt (rep bytes i un descriptor, retorna quants bytes ha escrit o un error) i resol per sota la varietat. Aquest contracte estable és el que fa que el codi sigui portable.

Un sistema operatiu resol dos problemes que el maquinari planteja i no sap resoldre tot sol: és massa complex per programar-lo directament i és massa escàs perquè diversos programes el facin servir sense coordinació. D'aquí en surten els seus dos papers: màquina estesa, que ofereix una interfície neta i portable, i gestor de recursos, que reparteix CPU, memòria i dispositius en el temps i en l'espai.

Per aconseguir-ho va introduir unes poques abstraccions molt ben triades —procés, espai d'adreces, fitxer i dispositiu-com-a-fitxer— i es va organitzar en capes: nucli, biblioteques del sistema, shell i utilitats, i aplicacions. Només la primera s'executa en mode privilegiat, i aquest és el criteri que separa el sistema operatiu de tota la resta. També has vist què no és un SO: ni la interfície gràfica ni la distribució.

Res d'això no va sorgir de cop. Cadascuna d'aquestes idees va aparèixer com a resposta a una limitació concreta de la seva època: el repartiment de temps va néixer perquè els ordinadors eren caríssims i no podien estar aturats, i els fitxers amb nom van néixer perquè ningú no volia recordar sectors. A la lliçó següent, Història i Evolució dels Sistemes Operatius, recorrerem aquest camí generació a generació per entendre per què els sistemes operatius són com són.