La història dels sistemes operatius no és una llista de dates per memoritzar: és la història d'una seqüència de problemes i solucions. Cada generació de sistemes operatius va néixer per resoldre una limitació concreta de l'anterior, i gairebé tot allò que avui et sembla obvi —que puguis tenir diverses finestres obertes, que un programa no tombi els altres, que et puguis connectar a una màquina remota— va ser en el seu moment una idea nova i polèmica. Entendre aquest recorregut et donarà una cosa valuosa: quan als mòduls següents vegis un mecanisme complicat (la memòria virtual, els semàfors, el sistema de fitxers amb journaling), sabràs quin desastre concret venia a evitar. I veuràs que les idees de disseny que van sobreviure són sorprenentment poques.

1. Abans del sistema operatiu: la màquina nua i els monitors residents
2. Processament per lots: aprofitar cada minut d'una màquina caríssima
3. Multiprogramació: que la CPU no esperi el disc
4. Temps compartit: retornar la interactivitat al programador
5. UNIX i una filosofia de disseny
6. L'ordinador personal: CP/M, MS-DOS, Windows i Macintosh
7. El programari lliure i el naixement de Linux
8. L'era de la xarxa i d'Internet
9. L'era actual: mòbil, núvol i contenidors
10. Taula cronològica de fites
11. Les idees que van sobreviure i per què

Dècades de 1940 i 1950. Els primers ordinadors (ENIAC, EDSAC, IBM 701) no tenien sistema operatiu. El programador reservava la màquina per hores, entrava físicament a la sala, carregava el seu programa mitjançant interruptors o targetes perforades, l'executava i llegia els resultats en llums o en una impressora.

El problema era brutal i molt mesurable: una màquina que costava milions de dòlars passava la major part del temps aturada, esperant que un humà canviés de cinta o de targetes. S'estima que el temps útil de càlcul no arribava al 20 % del temps llogat.

La primera solució va ser el monitor resident: un petit programa que es quedava permanentment a la memòria i s'encarregava de carregar la feina següent automàticament quan l'anterior acabava. No planificava, no protegia, no repartia res: només evitava la intervenció humana entre feina i feina. Tot i així, és l'avantpassat directe del nucli, perquè va introduir la idea de codi que hi és sempre i controla els programes.

Anys 50 i principis dels 60. El pas següent va ser agrupar feines semblants en lots (batches): es recollien les targetes perforades de molts programadors, es passaven a cinta magnètica en una màquina barata, i la màquina cara executava la cinta sencera de cop.

Aquí apareix una idea que continua vigent: el llenguatge de control de treballs (JCL als sistemes IBM), amb el qual el programador descrivia quins recursos necessitava la seva feina. Era, en essència, el primer script de desplegament.

Encara que la sintaxi resulti estranya, el contingut et sonarà molt:

• JOB declara la feina, a qui es factura (COMPTE) i quant temps màxim pot consumir (TIME=(0,30), 30 segons). És exactament el mateix concepte que un límit de recursos en un contenidor modern.
• EXEC PGM=AGREGADOR diu quin programa cal executar.
• Les línies DD (Data Definition) associen noms lògics a conjunts de dades concrets. És el mateix principi que un descriptor de fitxer o una variable d'entorn amb una ruta: el programa fa servir un nom lògic i el sistema decideix què hi ha al darrere.

Limitació que quedava pendent: mentre la feina llegia de la cinta, la CPU estava aturada. I llegir una cinta era milers de vegades més lent que calcular.

Anys 60. La solució va ser mantenir diverses feines a la memòria alhora. Quan la feina A es bloqueja esperant la cinta, el sistema passa la CPU a la feina B. Quan A rep les seves dades, torna a la cua. Això és la multiprogramació, i amb ella neix de debò el sistema operatiu com a gestor de recursos.

L'impacte és fàcil de quantificar. Suposem que una feina passa el 80 % del seu temps esperant entrada/sortida. Amb una sola feina a la memòria, la CPU s'aprofita un 20 %. Amb n feines independents a la memòria, la probabilitat que totes estiguin esperant alhora és 0,8ⁿ, així que l'aprofitament és 1 − 0,8ⁿ:

Passar d'1 a 5 feines triplica el rendiment sense canviar el maquinari. Aquest càlcul va justificar per si sol tota la complexitat afegida.

Però la multiprogramació va portar problemes nous, i d'aquí en surten tres mòduls sencers d'aquest curs:

• Si hi ha diversos programes a la memòria, cal protegir-los els uns dels altres → gestió de memòria i protecció.
• Cal decidir a qui li toca la CPU → planificació.
• Els programes poden interferir-se en fer servir recursos compartits → concurrència i sincronització.

Els sistemes emblemàtics d'aquesta etapa van ser OS/360 d'IBM (1964) i Multics (del qual parlem tot seguit). OS/360 també és cèlebre pel seu desenvolupament desastrós, que Fred Brooks va explicar a The Mythical Man-Month: va ser el primer projecte que va demostrar que afegir programadors a un projecte endarrerit encara l'endarrereix més.

El processament per lots era eficient per a la màquina, però horrible per a l'humà: lliuraves les teves targetes i rebies el resultat l'endemà. Si t'havies deixat una coma, perdies un dia sencer.

La idea del temps compartit (time-sharing) va ser donar a cada usuari una porció de temps de CPU tan breu i tan freqüent que cadascun es pensés que tenia la màquina per a ell sol. Com que els humans pensem a poc a poc i escrivim a poc a poc, una sola màquina podia atendre desenes d'usuaris simultanis.

• CTSS (Compatible Time-Sharing System, MIT, 1961) va ser el primer que va funcionar de debò. Va demostrar que la idea era viable.
• Multics (MIT, Bell Labs i General Electric, des de 1965) va ser el projecte ambiciós que volia portar la idea a l'extrem: un «servei de computació» comparable a la xarxa elèctrica, amb seguretat per anells de privilegi, memòria segmentada, sistema de fitxers jeràrquic i alta disponibilitat. Multics va ser massa ambiciós i va arribar tard, i Bell Labs va abandonar el projecte el 1969.

Multics se sol explicar com un fracàs, però és un fracàs extraordinàriament influent: els anells de privilegi, el sistema de fitxers jeràrquic amb directoris imbricats, els enllaços dinàmics i la idea de tractar la memòria i els fitxers de manera uniforme vénen d'aquí. I el seu abandonament va produir directament el sistema operatiu més influent de la història.

1969, Bell Labs. Ken Thompson, frustrat per la desaparició de Multics, va escriure en un PDP-7 en desús un sistema molt més petit i simple. Brian Kernighan el va batejar UNICS en broma (un joc de paraules amb Multics), i va acabar anomenant-se UNIX.

Dues decisions ho van canviar tot:

1. Reescriure'l en C (1973, amb Dennis Ritchie). Fins llavors els sistemes operatius s'escrivien en assemblador, lligats a una màquina concreta. Un sistema escrit en un llenguatge d'alt nivell es podia portar a un altre maquinari recompilant-lo. Va ser una idea considerada arriscada i ineficient en el seu moment; avui és la norma absoluta.
2. Distribuir-lo amb el codi font a les universitats per un preu simbòlic. Això va crear tota una generació de programadors que van aprendre llegint un sistema operatiu real, i va donar lloc a BSD (Berkeley Software Distribution), d'on van sortir la implementació de TCP/IP més usada del món, els sòcols i l'editor vi.

La filosofia UNIX, que continua sent la millor guia de disseny de programari que existeix, es resumeix en pocs principis:

• Escriu programes que facin una sola cosa i la facin bé.
• Escriu programes que treballin junts, comunicant-se mitjançant fluxos de text.
• El text pla és la interfície universal.
• Tot és un fitxer.

Un exemple amb dades de Meteora il·lustra la potència d'aquests principis millor que qualsevol explicació:

Anem part per part:

• grep 'estacio=118' ... filtra del registre només les línies de l'estació 118. grep no sap res de meteorologia: només busca text.
• | és la canonada (pipe), l'aportació estrella d'UNIX: connecta la sortida d'un programa amb l'entrada del següent, sense fitxers temporals i sense que cap dels dos sàpiga de l'existència de l'altre.
• awk '{print $4}' extreu el quart camp de cada línia (suposem que és l'hora de la petició). awk no sap què significa aquest camp.
• sort ordena, requisit per al pas següent.
• uniq -c col·lapsa línies repetides i hi anteposa quantes vegades apareixia cadascuna.
• sort -rn reordena numèricament (-n) i de major a menor (-r).
• head -5 es queda amb les cinc primeres.

Resultat: les cinc hores amb més consultes a l'estació 118. Cap d'aquests sis programes no va ser escrit pensant en Meteora ni en els altres cinc, i tanmateix cooperen. Aquest és l'assoliment de disseny d'UNIX, i és la raó que la línia de comandes continuï sent una eina de primer nivell cinquanta anys després (hi tornarem a La Línia de Comandes com a Interfície del Sistema).

Anys 70 i 80. El microprocessador va abaratir el maquinari fins al punt que una persona podia tenir un ordinador. Però aquell ordinador era molt més limitat que els grans sistemes: sense memòria protegida, amb molt poca RAM i amb un sol usuari. Curiosament, això va suposar un retrocés tècnic: els primers sistemes operatius de PC van oblidar gairebé tot el que s'havia après en multiprogramació i protecció, simplement perquè el maquinari no ho permetia.

• CP/M (Gary Kildall, 1974) va ser el primer SO àmpliament utilitzat en microordinadors de 8 bits. La seva gran idea va ser la BIOS: separar la part del sistema que depèn del maquinari concret de la resta, perquè el mateix CP/M funcionés en màquines de fabricants diferents. És un cas primerenc de capa d'abstracció de maquinari.
• MS-DOS (Microsoft, 1981) va arribar a l'IBM PC. Tècnicament era pobre —monotasca, sense protecció de memòria, amb noms de fitxer de 8+3 caràcters— però va ser el sistema de l'ordinador que es va convertir en estàndard de la indústria.
• Macintosh (Apple, 1984) va popularitzar la interfície gràfica amb finestres, icones, menús i ratolí, idees nascudes a Xerox PARC amb l'Alto i el sistema Smalltalk. Va canviar per sempre qui podia fer servir un ordinador.
• Windows va començar com un entorn gràfic sobre MS-DOS (1985). Windows 95 va barrejar codi de 16 i 32 bits amb multitasca cooperativa, cosa que explica la seva llegendària inestabilitat. La ruptura real va arribar amb Windows NT (1993), dissenyat des de zero per un equip dirigit per Dave Cutler, que venia de VMS: nucli híbrid, memòria protegida, multitasca apropiativa i multiusuari. Tot el Windows modern descendeix d'NT, no de MS-DOS.

1983-1991. Richard Stallman va llançar el projecte GNU amb l'objectiu de construir un sistema operatiu complet i lliure, compatible amb UNIX. GNU va produir peces fonamentals —el compilador gcc, el depurador gdb, bash, les coreutils— i, sobretot, la llicència GPL, que garanteix que el codi derivat continuï sent lliure. El que li faltava a GNU era precisament el nucli: el seu projecte de nucli, Hurd, no va arribar mai a estar llest.

1991. Linus Torvalds, estudiant a Hèlsinki, va publicar un nucli propi com a projecte personal. El seu missatge original deia que seria «només una afició, res de gran ni professional com GNU». Combinat amb les eines GNU, aquell nucli va formar un sistema operatiu complet i lliure.

La clau del seu èxit no va ser només tècnica sinó organitzativa: el model de desenvolupament obert i distribuït, amb milers de col·laboradors i un cicle d'integració ràpid, va resultar més eficaç del que ningú esperava. Avui el nucli Linux té més de 30 milions de línies de codi i rep contribucions de milers de persones i de gairebé totes les grans empreses tecnològiques. A meteo-01, com a la immensa majoria de servidors del món, és aquest nucli el que està treballant:

Què et diu cada camp:

• Linux és el nucli; meteo-01, el nom de la màquina.
• 6.1.0-18-amd64 és la versió del nucli i l'arquitectura.
• SMP significa Symmetric MultiProcessing: suport per a diversos nuclis de CPU, herència directa de la multiprogramació.
• PREEMPT_DYNAMIC indica que el nucli pot ser apropiat (interromput) fins i tot mentre executa codi del nucli mateix, cosa que redueix les latències.
• GNU/Linux recorda precisament això darrer: el sistema és nucli Linux + eines GNU.

Anys 80 i 90. Amb la connexió permanent van aparèixer requisits nous que el SO va haver d'absorbir:

• La pila de xarxa com a part del nucli. TCP/IP va deixar de ser un afegit per convertir-se en un subsistema central. La implementació de BSD va ser la referència mundial i la seva API de sòcols continua sent l'estàndard.
• L'abstracció de sòcol, que va estendre «tot és un fitxer» a la comunicació remota: un sòcol es llegeix i s'escriu com un fitxer.
• Sistemes de fitxers en xarxa (NFS, SMB), que van permetre que un directori d'una màquina aparegués dins l'arbre d'una altra.
• La seguretat com a problema real. Amb una màquina aïllada, la protecció era gairebé un assumpte acadèmic. Amb una màquina connectada, qualsevol fallada és explotable des de l'altra punta del món. El cuc Morris de 1988 ho va demostrar de manera espectacular en infectar una part significativa de la Internet de l'època, i és l'origen que el mòdul 5 d'aquest curs existeixi.

Des dels 2000. Tres desplaçaments han marcat l'etapa actual:

• Mòbil. Android (sobre nucli Linux) i iOS (sobre un nucli derivat de Mach i BSD) van portar els sistemes operatius a milers de milions de dispositius, amb dues prioritats noves: la bateria (el sistema apaga agressivament allò que no es fa servir) i l'aïllament per aplicació (cada app s'executa amb el seu propi usuari i permisos explícits, en comptes d'heretar els de l'usuari humà).
• Núvol. La virtualització va permetre que moltes màquines virtuals compartissin un servidor físic, convertint el còmput en un servei que es lloga per minuts. Curiosament, és la vella idea de Multics —la computació com a servei públic— acomplerta seixanta anys després.
• Contenidors. En comptes de virtualitzar el maquinari sencer, s'aïlla un conjunt de processos dins el mateix nucli mitjançant namespaces i cgroups. És una volta de rosca sobre la protecció clàssica del SO, no una tecnologia aliena.

Aquests tres temes es desenvolupen al mòdul 6: Virtualització: Hipervisors i Màquines Virtuals, Contenidors: Namespaces i cgroups i Sistemes Operatius Mòbils i de Temps Real. Aquí només ens interessa situar-los a la línia del temps.

Si compares un sistema de 1970 amb meteo-01, canvia gairebé tot el codi però es manté l'esquelet conceptual. Aquestes són les idees que van resistir, i la raó per la qual ho van fer:

1. El procés com a unitat d'execució aïllada. Sobreviu perquè resol dos problemes alhora (comptabilitat i protecció) amb un sol concepte.
2. La separació entre mode usuari i mode nucli. És l'única manera coneguda que el sistema pugui confiar en si mateix encara que no confiï en els programes que executa. Cap alternativa no ha estat millor. És el tema de Mode Usuari, Mode Nucli i Crides al Sistema.
3. El fitxer com a seqüència de bytes amb nom. Sobreviu per allò que no imposa: com que no dicta cap format, serveix igual per a un .dat de lectures, una imatge o un executable.
4. La jerarquia de directoris. Un arbre únic és prou simple d'entendre i prou flexible per organitzar milions de fitxers.
5. «Tot és un fitxer». Reutilitzar una interfície coneguda per a coses noves (dispositius, sòcols, informació del nucli) redueix enormement el que cal aprendre i el que cal programar.
6. Les canonades i la composició de programes petits. Sobreviuen perquè escalen a problemes que ningú no va preveure.
7. La memòria virtual. Dona a cada procés un espai propi, permet fer servir més memòria de la que hi ha i simplifica la càrrega de programes. Tres beneficis per un mecanisme.
8. El temps compartit amb apropiació. Sense la capacitat del SO de treure la CPU a un procés, un sol programa mal escrit paralitza la màquina. L'era de la multitasca cooperativa (Windows 3.x, Mac OS clàssic) va demostrar a la pràctica com de malament funciona l'alternativa.

I una idea que no va sobreviure però que convé conèixer: els sistemes que confiaven en la bona voluntat dels programes (multitasca cooperativa, memòria sense protecció) van fracassar sempre. La lliçó pràctica, que val també per al programari que escriguis tu, és que un sistema no ha de dependre que els seus usuaris es portin bé.

• Estudiar les dates en comptes dels problemes. Ningú no et preguntarà l'any en què va sortir Multics. El que sí que importa és que sàpigues explicar quin problema va resoldre el temps compartit i per què la multiprogramació exigeix protecció de memòria.
• Creure que l'evolució va anar sempre endavant. No hi va anar: els primers sistemes de PC van ser un retrocés tècnic respecte als grans sistemes dels 60. Les restriccions del maquinari i del mercat manen tant com les bones idees.
• Confondre Linux amb GNU/Linux, o amb una distribució. Linux és només el nucli. El que instal·les és un conjunt format per aquest nucli més eines GNU i molts altres programes, empaquetat per una distribució.
• Pensar que UNIX està superat. macOS és un UNIX certificat, Android fa servir el nucli Linux, iOS deriva de BSD i pràcticament tots els servidors del món són UNIX o Linux. El model no només no està superat: va guanyar.
• Consell: quan als mòduls següents aparegui un mecanisme que et sembli innecessàriament complicat, pregunta't quin desastre concret evita. Gairebé sempre hi ha una anècdota històrica al darrere, i recordar-la fixa el concepte molt millor que la definició.

Per a cada limitació de l'esquerra, indica quin avenç històric la va resoldre i quin problema nou va introduir aquest avenç:

1. La CPU està aturada mentre l'humà canvia les targetes.
2. La CPU està aturada mentre la feina llegeix de la cinta.
3. El programador espera un dia sencer per saber si el seu programa compila.
4. El sistema operatiu s'ha de reescriure sencer en canviar de màquina.

A meteo-01, ingestor passa el 90 % del seu temps esperant dades de xarxa i només el 10 % calculant. Fent servir la fórmula d'aprofitament de CPU de la multiprogramació (1 − p^n, amb p la fracció d'espera), calcula l'aprofitament amb 1, 3, 6 i 12 processos d'aquest perfil. Val la pena passar de 6 a 12? Raona quin altre factor del sistema real limita aquesta fórmula.

Escriu una única línia de comandes, a l'estil de la filosofia UNIX, que a partir de /var/log/meteora/meteo-api.log obtingui les tres adreces IP que han fet més peticions. Suposa que la IP és el primer camp de cada línia, separat per espais. Explica quin principi de la filosofia UNIX exemplifica la teva solució i per què no cal un programa específic de Meteora per resoldre-ho.

Solució 1

1. Humà canviant targetes → ho va resoldre el processament per lots amb monitor resident, que encadenava feines automàticament. Problema nou: l'usuari perd tota la interactivitat, ja no pot intervenir mentre la seva feina s'executa.
2. CPU aturada esperant la cinta → ho va resoldre la multiprogramació, mantenint diverses feines a la memòria i commutant quan una es bloqueja. Problemes nous: cal protegir la memòria d'unes feines respecte de les altres, cal decidir a qui es dona la CPU (planificació) i apareixen les condicions de carrera en compartir recursos.
3. Un dia d'espera per tenir el resultat → ho va resoldre el temps compartit, donant porcions molt breus de CPU a molts usuaris interactius. Problemes nous: com garantir temps de resposta raonables quan hi ha molts usuaris, com evitar que un monopolitzi el sistema i com aïllar usuaris que ara conviuen de debò (neix la necessitat de comptes, permisos i contrasenyes).
4. Reescriure el SO en canviar de màquina → ho va resoldre escriure el sistema operatiu en C (UNIX, 1973), aïllant en unes poques parts el codi dependent del maquinari. Problema nou: una petita pèrdua de rendiment respecte a l'assemblador fet a mà i la necessitat de disposar d'un compilador fiable per a cada arquitectura de destinació. L'intercanvi va resultar tan favorable que avui ningú no es planteja el contrari.

Solució 2

Amb p = 0,9 (fracció de temps que un procés passa esperant):

Val la pena passar de 6 a 12? En termes d'aquesta fórmula, sí: es guanyen gairebé 25 punts percentuals, una mica més del que es va guanyar en passar de 3 a 6 (19,8 punts). Però fixa't que el rendiment marginal ja està caient: cada procés afegit aporta menys que l'anterior, perquè la corba s'aplana en acostar-se al 100 %.

Què limita la fórmula al món real:

• La memòria. Cada procés addicional ocupa RAM. Si en afegir processos el sistema comença a intercanviar pàgines amb el disc (swapping), el rendiment s'enfonsa en comptes de millorar. Ho veuràs a Memòria Virtual i Paginació.
• La independència estadística que la fórmula suposa. Si tots els processos esperen el mateix recurs (per exemple, el mateix disc o la mateixa targeta de xarxa), les seves esperes estan correlacionades i l'aprofitament real és molt pitjor que el predit.
• El cost del canvi de context. Commutar entre processos costa temps de CPU que la fórmula ignora. Amb massa processos, una part creixent de la CPU es dedica a gestionar la commutació en comptes de fer feina útil.

Solució 3

Pas a pas:

• awk '{print $1}' imprimeix només el primer camp de cada línia, és a dir, la IP. També podríem fer servir cut -d' ' -f1, que és equivalent i una mica més ràpid.
• sort agrupa les línies iguals, posant-les consecutives. És imprescindible perquè uniq només detecta repeticions adjacents.
• uniq -c substitueix cada grup de línies idèntiques per una de sola precedida del nombre de repeticions.
• sort -rn ordena per aquest nombre (-n, numèric) de major a menor (-r).
• head -3 es queda amb les tres primeres.

Principi que exemplifica: la composició de programes petits i especialitzats mitjançant canonades, amb text pla com a interfície universal. Cap dels cinc programes no sap què és una IP, què és Meteora ni què fan els altres; cadascun fa una transformació mínima sobre línies de text.

Per què no cal un programa específic: perquè el format del registre és text i les operacions necessàries (filtrar, extreure, agrupar, comptar, ordenar) són genèriques. Escriure un analitzador-meteora en Python donaria el mateix resultat, però costaria vint vegades més temps, s'hauria de mantenir i només serviria per a aquest cas. L'error habitual aquí és el contrari: fer servir la línia de comandes per a tasques que ja requereixen estat complex o lògica de negoci, on un programa de debò sí que és la resposta correcta.

Els sistemes operatius van evolucionar resolent un problema rere l'altre: primer la intervenció humana, després la CPU ociosa, més tard la manca d'interactivitat, després la portabilitat i finalment l'aïllament en un món connectat. Cada solució va portar problemes nous, i aquesta cadena explica per què un sistema modern té l'estructura que té.

Del recorregut convé que t'enduguis tres coses. Primera, que la multiprogramació és l'origen de gairebé tota la complexitat d'un SO: sense ella no caldrien ni la protecció de memòria, ni la planificació, ni la sincronització. Segona, que UNIX va guanyar per simplicitat i portabilitat, no per potència, i que la seva filosofia continua sent la millor guia de disseny disponible. I tercera, que les idees que van sobreviure són poques i molt generals: procés, mode dual, fitxer, jerarquia, memòria virtual.

Tota aquesta evolució va produir una varietat enorme de sistemes actuals, des del microprogramari d'una estació meteorològica que ocupa uns pocs kilobytes fins al nucli d'un servidor amb milions de línies de codi. A la lliçó següent, Tipus de Sistemes Operatius, posarem ordre en aquesta varietat classificant-la per criteris clars, i decidirem quin tipus de sistema convé a cada peça de la infraestructura de Meteora.