A la lliçó anterior va quedar clar que Linux és un nucli i que la caixa completa és una distribució. Ara toca respondre una pregunta que sembla de cultura general però que és profundament pràctica: per què Linux és com és?

Quan d'aquí a uns mòduls escriguis alguna cosa com cat acces.log | grep ERROR | sort | uniq -c, estaràs fent servir un idioma dissenyat el 1969 en un laboratori de Nova Jersey. Quan et preguntis per què la configuració d'un servidor són fitxers de text i no un registre binari, la resposta és en aquella mateixa dècada. I quan et sobti que una ordre que funciona no imprimeixi absolutament res, també.

Aquesta lliçó no és un adorn històric: és l'explicació del disseny. Veuràs d'on ve Unix, quins són els seus principis, com el projecte GNU i el nucli d'un estudiant finlandès es van trobar per casualitat el 1991, i com es desenvolupa avui el nucli que corre a srv-tramontana.

1. Per què la història importa per entendre el disseny actual
2. Unix als Bell Labs (1969)
3. La filosofia Unix i els seus principis
4. La fragmentació d'Unix i l'estàndard POSIX
5. El projecte GNU (1983) i la peça que faltava
6. Linus Torvalds i l'anunci de 1991
7. Per què es diu "GNU/Linux"
8. Línia de temps: de 1991 al núvol
9. Com es desenvolupa avui el nucli

Un sistema operatiu no és un producte neutre: és la cristal·lització de les decisions de les persones que el van fer, en les condicions en què el van fer. Unix va néixer en un ordinador amb 8 KB de memòria que s'havien de compartir entre diversos usuaris simultanis. Aquella escassetat brutal va imposar un estil: res de programes gegants, res d'interfícies decoratives, res de gastar un byte de més.

Tres trets que veuràs cada dia a Linux només s'expliquen així:

Aquest últim punt és el més important dels tres. Que /etc/tramontana/app.conf sigui text pla i no un binari propietari és el que et permetrà buscar-hi amb grep, versionar-lo amb Git, generar-lo amb un script i desplegar-lo amb Ansible a 200 màquines. Tot el Mòdul 3 i el Mòdul 4 d'aquest curs existeixen gràcies a aquella decisió de 1970.

A finals dels seixanta, els Bell Labs d'AT&T participaven juntament amb el MIT i General Electric en Multics, un sistema operatiu ambiciós, pensat per donar servei informàtic com qui dona electricitat. Multics tenia idees brillants, però es va tornar enorme i lent. El 1969 Bell Labs va abandonar el projecte.

Dos dels seus enginyers, Ken Thompson i Dennis Ritchie, es van quedar amb la frustració i amb les idees. Thompson va trobar un PDP-7 en desús i va escriure en unes setmanes un sistema mínim per poder continuar jugant a Space Travel, un programa de simulació espacial. Aquell sistema tenia un sistema de fitxers jeràrquic, processos i un intèrpret d'ordres. Brian Kernighan el va batejar com a UNICS (mig en broma, com un «Multics castrat»), i va acabar quedant Unix.

Les fites que ho van canviar tot:

• 1969: primer Unix al PDP-7, escrit en assemblador.
• 1971: primera edició documentada; apareixen les pàgines de manual (man), que continuaràs fent servir a la lliçó 02-02.
• 1972: Dennis Ritchie crea el llenguatge C.
• 1973: Unix es reescriu en C. Aquest és el moment decisiu.

Reescriure un sistema operatiu en un llenguatge d'alt nivell era gairebé heretgia: es perdia rendiment. Però guanyava una cosa molt més valuosa: portabilitat. Fins llavors cada sistema operatiu estava lligat a un model d'ordinador; a partir d'aleshores, Unix es podia portar a una altra màquina recompilant-lo. És la raó última que avui el mateix Linux corri al teu portàtil, en un servidor, en un mòbil i en un supercomputador.

I hi va haver un accident afortunat: AT&T era un monopoli telefònic regulat i tenia prohibit comercialitzar programari. Així que va distribuir Unix a les universitats per un cost simbòlic, amb el codi font. Generacions senceres d'estudiants van aprendre sistemes operatius llegint, modificant i millorant Unix. D'aquí en va sortir, entre altres coses, la branca BSD de la Universitat de Califòrnia a Berkeley, avantpassat directe del macOS actual.

Aquesta secció és la més important de la lliçó. Els principis que segueixen no són història: són el manual d'estil amb el qual està escrit tot el que aprendràs.

Doug McIlroy, cap del departament on va néixer Unix, ho va resumir així:

«Escriu programes que facin una sola cosa i la facin bé. Escriu programes que col·laborin entre ells. Escriu programes que manegin fluxos de text, perquè aquesta és una interfície universal.»

Desglossem els principis operatius.

A Linux no hi ha un gran programa «gestor de registres». Hi ha cat (mostrar), grep (filtrar), sort (ordenar), uniq (comptar repetits), cut (extreure columnes), wc (comptar). Cadascun fa una sola tasca i la fa bé.

L'avantatge: aprendre 30 eines petites et dona milers de combinacions útils, mentre que aprendre un programa monolític et dona exactament el que el seu autor va preveure.

Un document és un fitxer. Un directori és un fitxer. El teu disc dur és un fitxer (/dev/sda). El teu terminal és un fitxer. La informació del processador és un fitxer (/proc/cpuinfo). Un sòcol de xarxa és un fitxer.

Per què és tan potent? Perquè amb un mateix joc d'operacions (open, read, write, close) manipules coses radicalment diferents, i per tant les mateixes eines serveixen per a tot. Ho veuràs en detall a la lliçó 01-06.

Una canonada (pipe, el caràcter |) connecta la sortida d'un programa amb l'entrada del següent. Va ser idea de McIlroy, implementada per Thompson el 1973, i és probablement la millor idea de la història dels sistemes operatius.

Mira aquest exemple amb les dades de Tramontana. Suposa el fitxer /var/log/tramontana/acces.log:

Sortida:

Què ha passat, peça a peça:

• cat /var/log/tramontana/acces.log bolca el contingut del fitxer a la seva sortida.
• El caràcter | connecta aquesta sortida amb l'entrada del programa següent. No es desa res al disc: les dades flueixen en memòria.
• grep ERROR deixa passar únicament les línies que contenen el text ERROR.
• wc -l compta línies (word count, opció lines).
• Resultat: 17 errors al registre d'accés.

Cap dels tres programes sap de l'existència dels altres. Cap no es va escriure pensant en Tramontana. I tanmateix resolen junts un problema concret. Això és componibilitat, i és el motiu pel qual un administrador de Linux pot respondre en 10 segons preguntes que en altres sistemes exigeixen escriure un programa.

No et preocupis si ara mateix no domines la sintaxi: les canonades són el cor del Mòdul 3. Aquí només cal que entenguis la idea.

Si tots els programes parlen text pla línia a línia, qualsevol es pot connectar amb qualsevol. Un format binari, per molt eficient que sigui, trenca aquesta cadena.

Una ordre Unix que funciona correctament no diu res. Només parla quan hi ha un problema. Això desconcerta al principi («ho ha fet o no?») i després s'agraeix: en un script que processa 5.000 fitxers, no vols 5.000 missatges de confirmació.

El sistema et dona eines i no t'imposa com fer-les servir. No hi ha una «manera correcta» d'organitzar els teus scripts. Aquesta llibertat és potent i també perillosa: la disciplina l'hi poses tu.

El 1984, la ruptura del monopoli d'AT&T li va permetre finalment comercialitzar Unix. El codi va deixar de circular lliurement i cada fabricant va desenvolupar la seva pròpia versió comercial, incompatible amb les altres:

A això se'n va dir les guerres d'Unix. Un programa escrit per a Solaris no compilava en AIX sense retocs. Els clients quedaven atrapats amb el seu fabricant. La fragmentació va afeblir Unix justament quan Windows NT començava a menjar-li el mercat corporatiu.

La resposta va ser POSIX (Portable Operating System Interface), un estàndard de l'IEEE publicat a partir de 1988 que defineix un mínim comú: quines crides al sistema hi ha d'haver, quines ordres, quin comportament del shell, quins senyals. Si escrius el teu programari respectant POSIX, funcionarà en qualsevol sistema conforme.

Linux no està certificat formalment com a POSIX (la certificació costa diners i a ningú no li ha compensat), però és àmpliament conforme a la pràctica. Això té una conseqüència molt concreta per a tu: quan al Mòdul 4 escriguis scripts respectant POSIX, funcionaran igual a Ubuntu, a Rocky Linux, a Alpine dins d'un contenidor i a macOS. És una habilitat transferible, no un coneixement de producte.

I una lliçó estratègica que explica el present: la GPL va evitar que a Linux li passés el que li va passar a Unix. Com que qualsevol modificació distribuïda s'ha de publicar, no hi va haver manera de crear un «Linux d'IBM» tancat i incompatible. La llicència va ser el pegament que va mantenir unit l'ecosistema.

Richard Stallman treballava al laboratori d'intel·ligència artificial del MIT, en una cultura on el codi es compartia sense més. A principis dels vuitanta aquella cultura es va esfondrar: els programes van passar a distribuir-se només en binari i amb acords de confidencialitat. L'anècdota fundacional és cèlebre: Stallman va voler arreglar el controlador d'una impressora Xerox que encallava treballs i no li van donar el codi font.

El setembre de 1983 va anunciar el Projecte GNU, acrònim recursiu de GNU's Not Unix: crear un sistema operatiu complet, compatible amb Unix, però enterament lliure. El 1985 va fundar la Free Software Foundation i el 1989 va escriure la GPL.

Durant els anys següents, el projecte GNU va produir un arsenal de programari de primeríssima qualitat, la major part del qual continues fent servir avui sense saber-ho:

El 1991 GNU tenia pràcticament tot el sistema operatiu... menys el nucli. El seu nucli, GNU Hurd, apostava per una arquitectura de micronucli, tècnicament elegant però endimoniadament difícil d'estabilitzar. Portava anys de retard. Hurd existeix encara avui i continua sense ser d'ús general.

Hi havia un sistema operatiu lliure complet esperant un nucli.

A Hèlsinki, un estudiant de 21 anys anomenat Linus Torvalds estudiava sistemes operatius amb Minix, un Unix petit i didàctic escrit pel professor Andrew Tanenbaum. Minix tenia codi disponible, però la seva llicència era restrictiva i el seu autor el mantenia deliberadament simple perquè continués sent ensenyable.

Torvalds, frustrat amb aquelles limitacions i amb un PC 386 acabat de comprar, va començar a escriure el seu propi nucli. El 25 d'agost de 1991 va publicar al grup de notícies comp.os.minix un missatge que avui és història:

«Estic fent un sistema operatiu (lliure i gratuït) (només un hobby, no serà gran ni professional com GNU) per a clons d'AT 386(486). [...] M'agradaria saber quines funcionalitats vol la majoria de la gent.»

Dues observacions sobre aquell text, perquè ensenyen més que qualsevol moralitat:

• La modèstia era sincera i estava equivocada. «Només un hobby, no serà gran ni professional» descriu el nucli que avui mou la major part d'internet.
• La pregunta final és la clau de l'èxit. «M'agradaria saber quines funcionalitats vol la majoria de la gent» no era retòrica. Torvalds publicava versions cada pocs dies i integrava pedaços de desconeguts. Aquell model —publicar aviat, publicar sovint, integrar contribucions— va ser tan innovador com el codi mateix.

El setembre de 1991 va aparèixer la versió 0.01: unes 10.000 línies, sense capacitat d'arrencar tota sola. El gener de 1992, amb la versió 0.12, Torvalds va prendre la decisió més transcendent de totes: canviar la llicència a GPL. La llicència original que havia escrit prohibia la venda comercial, cosa que n'hauria frenat l'adopció. Anys després ell mateix ho va qualificar com «el millor que he fet mai».

L'encaix va ser immediat. El nucli de Torvalds necessitava eines d'espai d'usuari; GNU les tenia totes. GNU necessitava un nucli; allà n'hi havia un que funcionava. La combinació nucli Linux + userland GNU era, d'un dia per l'altre, un sistema operatiu lliure complet i utilitzable. La versió 1.0 va arribar el març de 1994, amb 176.000 línies de codi i suport de xarxa.

Stallman i la FSF sostenen que anomenar «Linux» el sistema complet és injust: el nucli és una part important, però el compilador, el shell, les biblioteques i la majoria de les utilitats van sortir del projecte GNU, que portava vuit anys treballant amb aquell objectiu explícit. La seva proposta és GNU/Linux.

Torvalds i bona part de la comunitat prefereixen l'ús curt per comoditat. La discussió dura trenta anys i no es resoldrà.

Postura pràctica per a la teva vida professional:

• Tots dos noms són correctes i tothom entén els dos.
• En l'ús quotidià i en aquest curs direm Linux, per brevetat.
• Debian i algunes distribucions fan servir oficialment GNU/Linux.
• El que sí que és un error tècnic és creure que el nucli és el sistema. Aquesta part de la reivindicació de Stallman és simplement certa, i ja la tens clara des de la lliçó anterior.

Un matís interessant: avui existeixen sistemes Linux sense GNU. Android fa servir el nucli Linux amb la biblioteca Bionic; Alpine Linux (la base de la majoria de contenidors, que veuràs al Mòdul 7) fa servir musl i BusyBox en lloc de glibc i coreutils. En aquests casos «GNU/Linux» seria directament incorrecte.

Val la pena aturar-se en tres moments d'aquesta línia:

• 1993-1994, les distribucions. El nucli tot sol era intractable per a la majoria. Slackware i Debian primer, i Red Hat després, van resoldre el problema de reunir i instal·lar el conjunt. És quan Linux deixa de ser un projecte i comença a ser un producte.

• 1998-2004, l'entrada a l'empresa. IBM va invertir mil milions de dòlars en Linux el 2001. Els grans fabricants de programari van portar-hi els seus productes. Linux va passar de «joguina d'estudiants» a plataforma amb suport comercial. En paral·lel, Google va construir la seva infraestructura sobre Linux des del principi.

• 2013 endavant, el núvol i els contenidors. Les funcionalitats del nucli que fan possibles els contenidors (namespaces i cgroups, que veuràs al Mòdul 7) portaven anys allà. Docker les va empaquetar de manera usable el 2013 i va canviar la indústria. Avui no hi ha núvol sense Linux, i el remat simbòlic va arribar el 2018 amb Microsoft —el mateix que el 2001 qualificava Linux de «càncer»— incorporant un nucli Linux dins de Windows.

I una dada final que tanca el cercle: el 2001 Microsoft era el gran adversari; avui és un dels majors contribuents corporatius al nucli Linux i el propietari de GitHub, on viu bona part del programari lliure del món.

Entendre el procés t'ajuda a saber quina versió de nucli tens a srv-tramontana i què en pots esperar.

Linux segueix un ritme predictible des de fa més d'una dècada:

1. Merge window (2 setmanes). Torvalds accepta totes les funcionalitats noves que els mantenidors li envien. Es tanca i es publica la -rc1.
2. Candidates a release (7-8 setmanes). Cada diumenge surt una -rc2, -rc3... Només s'admeten correccions d'errors.
3. Release final. Surt la versió estable. L'endemà s'obre la finestra de la següent.

Total: una versió nova cada 9-10 setmanes, aproximadament. La numeració (5.x, 6.x) és purament cosmètica: Torvalds puja el primer número quan el segon se li fa incòmodament gran, no perquè hi hagi canvis revolucionaris.

Les versions normals deixen de mantenir-se tan bon punt surt la següent. Per això existeixen els nuclis LTS (Long Term Support), que reben correccions de seguretat durant diversos anys (típicament entre 2 i 6). Són els que fan servir les distribucions de servidor.

Ubuntu Server 24.04 LTS parteix del nucli 6.8, amb pedaços de seguretat respatllats per Canonical durant tot el cicle de vida de la distribució. Això significa una cosa important: no veuràs un nucli 6.14 a srv-tramontana encara que existeixi. En producció es prima l'estabilitat per damunt de la novetat.

Pots comprovar la teva versió en qualsevol moment amb una ordre que veurem amb calma a la lliçó 01-05:

Sortida al servidor de Tramontana:

Interpretació de cada part:

• 6 : versió major.
• 8 : versió menor (nucli 6.8, la base d'Ubuntu 24.04 LTS).
• 0 : nivell de pedaç de la branca estable.
• 41 : número de compilació d'Ubuntu. Aquí és on Canonical incorpora les seves correccions respatllades.
• generic : sabor del nucli. N'hi ha d'altres com aws, azure o lowlatency, optimitzats per a entorns concrets.

La imatge de voluntaris altruistes ja no descriu la realitat:

• Més de 2.000 desenvolupadors d'unes 200 empreses contribueixen a cada versió.
• Al voltant del 85-90 % de les contribucions són de gent pagada per la seva empresa per fer-ho: Intel, Red Hat, Google, AMD, Huawei, Meta, Oracle, Linaro, Microsoft.
• S'integren de l'ordre de 10 a 15 pedaços per hora, tots els dies de l'any.

L'estructura de decisió és una jerarquia de confiança: els desenvolupadors envien pedaços a mantenidors de subsistema (xarxa, sistemes de fitxers, drivers de gràfics...), aquests mantenidors els revisen i els agrupen, i qui integra finalment a la branca principal és Linus Torvalds, amb Greg Kroah-Hartman al capdavant de les branques estables. És un model meritocràtic i notòriament exigent: els pedaços es rebutgen sovint i les revisions poden ser dures.

• Creure que Torvalds va escriure tot Linux. Va escriure el nucli inicial i continua dirigint el projecte, però avui la seva aportació en línies de codi és mínima: la seva feina és integrar i arbitrar. Linux és obra de desenes de milers de persones.
• Confondre Unix, Linux i "tipus Unix". Unix és el sistema original d'AT&T i els seus descendents comercials certificats. Linux no conté codi d'Unix: es va escriure des de zero imitant-ne el comportament. Per això se'n diu Unix-like. Aquest detall no és trivial: va ser el centre del plet de SCO contra IBM (2003-2010), que va perdre sense trobar codi d'Unix a Linux.
• Pensar que la història no serveix per a res pràctic. La filosofia Unix és el criteri amb el qual avaluaràs els teus propis scripts al Mòdul 4: fa una sola cosa?, es pot encadenar?, parla text?
• Tractar l'elecció de llicència com un detall menor. El pas a GPL el 1992 és la raó que existeixi un ecosistema Linux unificat en lloc de vint variants incompatibles. Les llicències tenen conseqüències tècniques.
• Consell. Si vols aprofundir-hi, llegeix «The Art of Unix Programming» d'Eric S. Raymond (disponible lliurement en línia). És el millor desenvolupament de la filosofia Unix que existeix i es llegeix com un assaig, no com un manual.
• Consell pràctic immediat. Quan comencis a escriure scripts, pregunta't sempre: «podria resoldre això encadenant eines que ja existeixen?». A Linux, la resposta és que sí moltíssim més sovint del que et penses.

Relaciona cada característica del Linux actual amb el fet històric que l'explica. Justifica cada relació en dues o tres frases:

1. Les ordres tenen noms molt curts (ls, cp, mv).
2. La configuració del sistema són fitxers de text a /etc.
3. Existeix un estàndard anomenat POSIX.
4. El mateix Linux corre en un mòbil i en un supercomputador.
5. No hi ha versions de Linux privatives i incompatibles entre elles.

En Luis Ferrer ha escrit per a Tramontana un programa anomenat analitzador-tramontana que llegeix el fitxer /var/log/tramontana/acces.log, filtra els errors, els ordena, els compta, genera un gràfic i envia un correu a la Marta. Tot en un únic binari, amb un fitxer de configuració en format binari propietari.

Avalua el disseny segons la filosofia Unix: indica quins principis incompleix i proposa una alternativa concreta que respecti aquesta filosofia. Raona què hi guanya l'equip amb el redisseny.

A srv-tramontana executes uname -r i obtens 6.8.0-41-generic. La Marta ha llegit que existeix el nucli 6.14 i et pregunta per què el servidor «va desactualitzat i probablement insegur». Redacta la resposta que li donaries, explicant la numeració i el concepte de LTS.

Solució a l'Exercici 1

1. Noms d'ordres curts. Unix va néixer el 1969-1970 sobre teletips: terminals que imprimien en paper a velocitats de desenes de caràcters per segon. Escriure era lent i sorollós, i cada caràcter estalviat era temps real guanyat. Aquella economia es va fossilitzar en el joc d'ordres i no es va canviar mai, perquè aleshores ja hi havia milions de scripts i de persones que els feien servir. Avui sobreviuen per compatibilitat, no per necessitat.

2. Configuració en text pla. Deriva directament del principi «el text és la interfície universal». Si la configuració és text, qualsevol eina genèrica la pot manipular: grep per buscar, sed per modificar, Git per versionar, Ansible per desplegar. Un format binari obligaria a una eina específica per a cada fitxer i trencaria tota la cadena de composició.

3. POSIX. És la reacció a les guerres d'Unix dels anys vuitanta. En comercialitzar-se Unix, cada fabricant va crear la seva variant incompatible (AIX, HP-UX, Solaris, IRIX...) i els programes van deixar de ser portables. POSIX defineix el mínim comú denominador de crides, ordres i comportament del shell perquè el programari escrit una vegada funcioni en qualsevol sistema conforme.

4. Portabilitat extrema. És conseqüència de la reescriptura d'Unix en C el 1973. En no dependre de l'assemblador d'una màquina concreta, portar el sistema a un processador nou va passar a ser qüestió de recompilar i adaptar les parts dependents del maquinari. Linux va heretar aquest disseny i avui suporta més de vint arquitectures.

5. Absència de forks privatius. És l'efecte de la llicència GPL adoptada el 1992. El copyleft obliga que qualsevol versió modificada que es distribueixi ho faci també sota GPL i amb el codi font. Cap fabricant no ha pogut crear un Linux tancat, i les millores tornen al tronc comú. És exactament el mecanisme que li va faltar a Unix.

Solució a l'Exercici 2

Principis que incompleix el disseny d'en Luis:

Alternativa respectuosa amb la filosofia Unix:

Descompondre-ho en peces ja existents i encadenar-les, deixant en un script només allò que és específic de Tramontana:

Explicació pas a pas:

• grep ERROR ... filtra les línies d'error. Substitueix el mòdul de filtratge.
• sort les ordena perquè les iguals quedin juntes, requisit d'uniq.
• uniq -c col·lapsa les línies repetides i hi anteposa el nombre de repeticions.
• sort -rn reordena per aquest número, de major a menor (-n numèric, -r invers): els errors més freqüents a dalt.
• > redirigeix el resultat a un fitxer (ho veuràs al Mòdul 3).
• mail envia aquest fitxer per correu. Només aquesta part és "de Tramontana".

I la configuració passaria a ser un fitxer de text a /etc/tramontana/.

Què hi guanya l'equip:

• Menys codi propi per mantenir: cinc eines provades per milions d'usuaris substitueixen cinc mòduls escrits a casa.
• Flexibilitat: si la Marta demana filtrar també per data, s'afegeix un altre grep a la canonada sense tocar res més.
• Reutilització: el mateix sort | uniq -c serveix per analitzar reserves.csv.
• Depurabilitat: pots executar la canonada pas a pas i veure la sortida intermèdia de cada etapa. Amb el binari monolític, si el resultat és estrany no saps quin component ha fallat.
• Automatització: en ser text i ordres, tot això es programa amb cron (Mòdul 3) i es desplega amb Ansible (Mòdul 7).

Solució a l'Exercici 3

Resposta per a la Marta:

«El número no funciona com en una aplicació de mòbil, on el més alt sempre és el millor. A 6.8.0-41-generic, el 6.8 és la línia base del nucli que Ubuntu 24.04 LTS va triar en publicar-se, i el -41 és el que importa: és el número de compilació d'Ubuntu, i puja cada vegada que Canonical incorpora correccions de seguretat a aquesta línia base.

El nucli Linux publica una versió nova cada 9 o 10 setmanes. Cap distribució de servidor no persegueix aquest ritme, perquè cada versió nova porta funcionalitats noves i, amb elles, risc de regressions en els drivers i en el rendiment. El que es fa en producció és fixar una línia base estable i aplicar-li només les correccions de seguretat, una pràctica que s'anomena backporting.

Aquest és el sentit d'una distribució LTS (Long Term Support): Ubuntu 24.04 LTS es manté amb pedaços de seguretat fins al 2029. Quan apareix una vulnerabilitat greu, Canonical la corregeix sobre el 6.8 i publica un -42, un -43, etcètera. Rebem la protecció sense rebre els canvis funcionals.

Així que el servidor no està desactualitzat en allò que importa: està en una línia mantinguda i rep seguretat al dia. Ho podem verificar amb apt list --upgradable i amb l'historial d'actualitzacions. Instal·lar el 6.14 ens donaria funcionalitats que no necessitem, ens trauria del suport oficial de Canonical i ens exposaria a errors de maquinari imprevistos en producció. En un servidor, avorrit és un elogi.»

L'essencial d'aquesta lliçó:

• Unix va néixer als Bell Labs el 1969 i es va reescriure en C el 1973, cosa que li va donar la portabilitat que avui hereta Linux.
• La filosofia Unix —programes petits que fan una cosa bé, tot és un fitxer, compondre amb canonades, text com a interfície universal, silenci si hi ha èxit— és el criteri de disseny que explica pràcticament tot el que veuràs en aquest curs.
• La fragmentació comercial d'Unix va portar a l'estàndard POSIX, que és el que fa transferibles els teus coneixements i els teus scripts entre sistemes.
• El projecte GNU (1983) va construir tot el sistema operatiu lliure menys el nucli; el nucli de Torvalds (1991) va aparèixer just a temps, i el pas a GPL el 1992 va evitar que Linux es fragmentés com Unix.
• El nucli es desenvolupa avui amb un cicle de 9-10 setmanes, versions LTS per a producció i milers de desenvolupadors pagats per empreses.

Amb la genealogia clara, ja pots entendre per què existeixen tants «Linux» diferents i en què es diferencien de debò. A la lliçó següent, Distribucions de Linux, veurem què compon exactament una distribució, les tres grans famílies (Debian/Ubuntu, Red Hat/Fedora i Arch), què significa LTS enfront de rolling release, i prendrem amb criteri professional la decisió que Tramontana ja ha pres: Ubuntu Server 24.04 LTS per a srv-tramontana.