Geschiedenis van Linux-distributies uitgelegd

Wat een Linux-distributie daadwerkelijk is

De geschiedenis van Linux-distributies begint met een leemte: de Linux-kernel op zichzelf doet niets wat een gebruiker kan inzetten. Hij start op en detecteert hardware. Daarna stopt het proces. Iemand moet een userland toevoegen, bepalen hoe software wordt geïnstalleerd en bijgewerkt, en toezeggen dit jarenlang te onderhouden. Een distributie is die verzameling keuzes, plus de groep mensen die daarna betrokken blijft.

Het bestaat uit vijf onderdelen. Wijzig er één en u heeft een andere distributie, zelfs als het merendeel van de binaries overeenkomt:

• Een kernel, in een door het project gekozen versie, inclusief de toegevoegde patches en drivers.
• Een userland: de C-library, de shell, het init-systeem, de standaardcommando's.
• Een pakketformaat en de tool die dit installeert.
• Een releasebeleid: wat er mag veranderen, hoe vaak, en hoe lang elke release wordt ondersteund.
• Mensen: pakketbeheerders, een security-team en iemand die reageert wanneer een pakket defect raakt.

De kernel is het gedeelde onderdeel, waardoor twee Linux-distributies veel dichter bij elkaar liggen dan bij een andere Unix-variant. Dat is het onthouden waard wanneer u Linux en FreeBSD als serverplatformen vergelijkt, waarbij de kernel en de basis-userland door één project worden gebouwd en gezamenlijk worden uitgebracht. Bij Linux zijn die onderdelen afkomstig van afzonderlijke upstreams, en de distributie is de entiteit die ervoor zorgt dat ze op elkaar aansluiten.

Een geschiedenis van Linux-distributies in drie families

Drie projecten die in 1993 en 1994 van start gingen, vormden de basis voor drie families: Slackware, Debian en Red Hat. Vrijwel elke image in een hedendaags VPS-configuratiescherm is een van deze distributies of een afgeleide daarvan. Een afgeleide erft het pakketformaat, de bestandslayout en doorgaans de releasegewoonten; daarom voelt een Debian-afgeleide nog steeds als Debian aan, zelfs nadat de branding is verwijderd.

De onafhankelijke distributies verdienen een eigen vermelding, omdat zij van niemand zijn afgesplitst. Arch, Gentoo, Alpine, NixOS en Void hebben elk hun eigen pakketbeheerder en hun eigen regels geschreven. Twee daarvan, Arch en Alpine, zijn uiteindelijk toch op de imagelijst van uw provider beland, om redenen die niets met de desktop te maken hadden.

1992: de distributies vóór de families

MCC Interim Linux verscheen in februari 1992, samengesteld door Owen Le Blanc bij het Manchester Computing Centre. Het plaatste de kernel en de GNU (GNU's not Unix) tools op een paar diskette-images met een menu-gestuurd installatieprogramma. Het bestond omdat dit handmatig doen een dag werk kostte.

SLS (Softlanding Linux System), uitgebracht door Peter MacDonald in 1992, ging verder en voegde X (het X Window System) en TCP/IP-netwerken toe. SLS is de reden dat het woord distributie de huidige betekenis heeft. Het was echter ook foutgevoelig en werd traag onderhouden, waardoor in 1993 twee personen onafhankelijk van elkaar besloten dit op te lossen. De één bouwde het opnieuw op. De ander begon opnieuw met vastgelegde regels.

Slackware, 1993: de oudste familie die nog steeds wordt uitgebracht

Patrick Volkerding bracht op 16 juli 1993 Slackware 1.00 uit, gebouwd op basis van SLS waarbij de fouten waren verwijderd. Het wordt nog steeds onderhouden, wat het de oudst overlevende Linux-distributie maakt.

Een Slackware-pakket is een gecomprimeerd tar-archief met daarin een installatiescript. Er is geen afhankelijkheidsresolutie: niets controleert of de bibliotheek die uw nieuwe pakket nodig heeft al op de schijf staat. Die ene beslissing bepaalde alles wat volgde. Als de tool geen afhankelijkheden oplost, moet de meegeleverde set inherent coherent zijn, waardoor releases zeldzaam en conservatief blijven. Slackware 15.0 verscheen in februari 2022, zes jaar na 14.2.

De familie is klein. De vroegste releases van SUSE in het midden van de jaren 90 waren gebouwd op Slackware, voordat het project zijn eigen weg ging met YaST en later het RPM-pakketformaat. Dat laatste punt verwarrt mensen. SUSE en openSUSE gebruiken RPM-pakketten, en zij zijn geen afgeleiden van Red Hat. Het formaat is verplaatst. De afstamming niet.

Debian, 1993: een sociaal contract en een pipeline met drie suites

Ian Murdock kondigde Debian aan op 16 augustus 1993, drie weken na Slackware en om dezelfde reden. De naam combineert die van zijn partner Debra met die van hemzelf. Het Debian Manifesto volgde in januari 1994 en legde de voorwaarden vast: deze distributie zou in de openbaarheid worden onderhouden door vrijwilligers, niet door een bedrijf.

Debian legde de voorwaarden vervolgens schriftelijk vast. Het Debian Social Contract en de DFSG (Debian free software guidelines) werden aangenomen in juli 1997, en de DFSG vormde in 1998 de basis voor de Open Source Definition. Een document dat was geschreven om te bepalen wat er in één distributie thuishoort, definieerde uiteindelijk een licentiecategorie voor de gehele industrie. Dit is ook de reden waarom uw sources.list uit onderdelen bestaat: main bevat software die aan de richtlijnen voldoet, contrib en non-free bevatten wat daar niet aan voldoet, en Debian 12 voegde non-free-firmware toe zodat een laptop met een draadloze netwerkkaart kon installeren zonder dat er naar bestanden gezocht hoefde te worden.

De tooling is de andere erfenis. dpkg installeert één pakket en weigert dit als er iets ontbreekt, waarbij dpkg: dependency problems prevent configuration of wordt getoond. APT (advanced package tool), dat met Debian 2.1 in 1999 de standaard werd, is de laag die uitrekent wat er nog meer moet worden opgehaald en in welke volgorde. Elk apt-commando op elke Debian-afgeleide stamt af van dat werk.

De release-machine heeft drie suites en één regel. Een maintainer uploadt naar unstable, permanent met de codenaam sid. Een script migreert het pakket naar testing na ongeveer 5 tot 10 dagen, mits het is gebouwd op de release-architecturen en er geen nieuwe release-kritieke bugs zijn gevonden. Testing bevriest vervolgens, het release-team ruimt de resterende problemen op, en stable wordt uitgebracht wanneer de buglijst kort genoeg is. Niet op een vaste datum. Dat is de reden waarom Debian stable er oud uitziet en zich stabiel gedraagt: de versienummers stoppen bij de freeze, terwijl beveiligingsupdates erin worden teruggepoort.

Het bestuur is eveneens schriftelijk vastgelegd, met een gekozen projectleider en bindende algemene resoluties. In 2014 koos dat mechanisme voor systemd als het standaard init-systeem, en de mensen die het daar niet mee eens waren, splitsten zich af in Devuan, dat in 2017 zijn eerste release uitbracht. Debian was noch de eerste distributie die die overstap maakte, noch de laatste, en de redenen waarom dit bleef gebeuren, samen met de bezwaren die achteraf terecht bleken, worden beschreven in het verslag van hoe systemd SysV init verving. De grotere afstammelingen zijn Ubuntu, Raspberry Pi OS, Proxmox VE, Kali en Linux Mint.

Red Hat, 1994: RPM, gevolgd door de splitsing in Fedora en RHEL

Marc Ewing bracht rond Halloween 1994 de eerste versie van Red Hat Linux uit. Het bedrijf van Bob Young nam het in 1995 over en samen bouwden zij het eerste Linux-bedrijf dat ondersteuning verkocht in plaats van software. Red Hat ging op 11 augustus 1999 naar de beurs. IBM voltooide de overname van het bedrijf in juli 2019 voor ongeveer 34 miljard dollar; sindsdien is de distributie waarvoor de meeste bedrijfssoftware wordt gecertificeerd, eigendom van IBM.

De blijvende technische bijdrage is RPM (Red Hat package manager), geschreven door Erik Troan en Marc Ewing voor Red Hat Linux 2.0 in 1995. Een RPM declareert zijn afhankelijkheden en wordt geproduceerd vanuit een spec-bestand, een bouwrecept dat iedereen kan uitvoeren. Die tweede eigenschap maakte onafhankelijke rebuilds van het enterprise-product van Red Hat überhaupt mogelijk.

Red Hat Linux 9 was in 2003 de laatste van de oorspronkelijke lijn. Het bedrijf splitste het product in tweeën: Fedora Core 1 in november 2003 als de snelle community-release, en RHEL (Red Hat Enterprise Linux), dat in 2002 was begonnen als Advanced Server 2.1, als de langzame betaalde variant. De reden hiervoor is duidelijk. Eén product kan niet tegelijkertijd de plek zijn waar nieuwe versies worden getest en het platform zijn waarop een bank tien jaar lang ongewijzigde software draait. De twee helften zijn met elkaar verbonden: een major-versie van RHEL wordt afgesplitst van een Fedora-release, wordt gestabiliseerd en vervolgens bevroren. De pakketbeheerder volgde hetzelfde schema, van yum in de jaren 2000 naar dnf als de standaard voor Fedora in 2015, met rpm als de onderliggende basis voor beide.

Waarom CentOS stopte met het zijn van een gratis RHEL-rebuild

CentOS begon in 2004 met een eenvoudige taak: neem de bronpakketten die Red Hat publiceerde, verwijder de handelsmerken, bouw ze opnieuw op en stel het resultaat gratis beschikbaar. Het werd tien jaar lang de standaard gratis serverdistributie en Red Hat nam het project in 2014 in eigen beheer.

Op 8 december 2020 kondigde Red Hat aan dat CentOS Linux 8 op 31 december 2021 zou eindigen, acht jaar eerder dan de geplande datum, en dat de naam zou voortbestaan als CentOS Stream. Stream is geen rebuild. Het is de tak waaruit RHEL-minor-releases worden afgeleid, waardoor het voorloopt op RHEL in plaats van erachteraan te lopen. Voor een machine die u jarenlang wilt behouden, is voorlopen de verkeerde richting, omdat u wijzigingen ontvangt voordat de betalende klanten van Red Hat dat doen.

In 2021 verschenen er twee rebuilds. Rocky Linux werd gestart door Gregory Kurtzer, een van de medeoprichters van CentOS. AlmaLinux werd gefinancierd door CloudLinux. In juni 2023 stopte Red Hat met het publiceren van RHEL-broncodes, behalve via CentOS Stream en het klantportaal. Rocky bleef streven naar identieke rebuilds. AlmaLinux veranderde zijn doel naar ABI-compatibiliteit (application binary interface), wat betekent dat software die voor RHEL is gebouwd werkt, zonder de belofte dat de buglijst regel voor regel overeenkomt. Oracle, SUSE en CIQ richtten later dat jaar OpenELA op om gedeelde broncodes te publiceren. Die hele reeks, van de splitsing in 2003 tot de wijziging in de broncode in 2023 en wat elke rebuild nu belooft, wordt beschreven in het uitgebreidere verslag over Red Hat, CentOS, Rocky en AlmaLinux.

Als de imagelijst van een provider nog steeds CentOS vermeldt, achterhaal dan welke versie wordt bedoeld voordat u daarop bouwt.

cat /etc/os-release

NAME="CentOS Stream" is een rolling development-tak die voorloopt op RHEL. NAME="AlmaLinux" of NAME="Rocky Linux" is een rebuild die RHEL volgt, met een ondersteuningsperiode van tien jaar.

Ubuntu 20.04: een snapshot van Debian unstable, op de kalender

Ubuntu 4.10 werd uitgebracht op 20 oktober 2004, gefinancierd door Mark Shuttleworth. De relatie met Debian is eerder mechanisch dan sentimenteel. Elke cyclus begint met het importeren van pakketten vanuit Debian unstable in de nieuwe Ubuntu-release. Deze import loopt door tot de Debian Import Freeze halverwege de cyclus; daarna voert Ubuntu zijn eigen wijzigingen door. Veel Ubuntu-pakketten bestaan uit het Debian-pakket plus een delta, en het changelog-bestand vermeldt welke dit zijn.

De andere helft is de kalender. Debian brengt een versie uit wanneer deze gereed is. Ubuntu brengt releases uit in april en oktober, en het versienummer is de datum: 24.04 kwam uit in april 2024. Elke tweede april-release is een LTS (long term support), wat een provider bedoelt wanneer deze Ubuntu zonder verdere toevoeging aanbiedt. Welke van de twee op een server thuishoort, is het volledige onderwerp van kiezen tussen Ubuntu LTS en interim-releases, en het overstappen van de ene LTS naar de volgende heeft een eigen procedure, beschreven in de upgrade van 24.04 naar 26.04.

Eén detail treft serverbeheerders elk jaar. Het archief van Ubuntu is opgedeeld in componenten. main wordt door Canonical onderhouden gedurende de volledige ondersteuningsperiode. universe wordt door de community onderhouden en de beveiligingsdekking daarvan is een andere belofte. apt install vermeldt niets over dit verschil. Eén commando toont dit aan:

apt-cache policy nginx

Een repository-regel die eindigt op /main betekent dat het beveiligingsteam van Canonical verantwoordelijk is voor dat pakket. Een regel die eindigt op /universe betekent dat de community dit doet. Controleer dit voor alles wat verbonden is met het internet.

Arch, 2002: rolling releases en de kosten van een gedeeltelijke upgrade

Judd Vinet bracht op 11 maart 2002 Arch 0.1 uit, met een door hemzelf geschreven pakketbeheerder, pacman, en build-recepten die uit eenvoudige shell-scripts bestaan. Arch kent geen versies met releases. De installatiemedia zijn gedateerde snapshots van dezelfde rolling repositories; een machine die in 2019 is geïnstalleerd en wekelijks wordt bijgewerkt, draait dus dezelfde Arch-versie als een machine die vandaag wordt geïnstalleerd. De AUR (Arch user repository) bevat build-recepten die door gebruikers zijn bijgedragen. Dit zijn recepten, geen gecontroleerde pakketten; het lezen van een PKGBUILD voordat u deze uitvoert, hoort daarom bij het werk.

Rolling releases kennen één storingsmodus, en deze is altijd zelfveroorzaakt. Het installeren van een enkel pakket met pacman -Sy foo ververst de pakketdatabase en installeert vervolgens een nieuw binair bestand dat gekoppeld is aan bibliotheken die nieuwer zijn dan de bibliotheken op de schijf. Programma's falen dan als volgt:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

De ondersteunde handeling is pacman -Syu, waarmee alles tegelijk wordt bijgewerkt. Het project publiceert ook nieuwsberichten waarin staat dat handmatige tussenkomst vereist is vóór bepaalde upgrades. Het uitvoeren van de upgrade zonder deze berichten te lezen, kan ertoe leiden dat een machine niet meer opstart.

Dit maakt Arch een slechte keuze voor een server die u van plan bent te negeren. Een machine die wekelijks wordt bijgewerkt, is prima. Een machine die pas na een jaar wordt bijgewerkt, schotelt u echter alle overgeslagen tussenkomsten in één keer voor.

Alpine: een kleine distributie die beroemd werd door containers

Alpine begon rond 2005 als een fork van LEAF (Linux embedded appliance framework), dat zelf afstamde van het Linux Router Project. Natanael Copa bouwde het voor apparaten in plaats van voor desktops. Het vervangt het grootste deel van de gebruikelijke userland: musl in plaats van de GNU C-library, BusyBox in plaats van de GNU core utilities, OpenRC in plaats van systemd, en apk als pakketbeheerder. Alpine 3.0 in 2014 was de release die overstapte op musl.

Containers maakten het populair. Een Alpine-basislaag is slechts een fractie van de grootte van een Debian- of Ubuntu-basis. Vanaf 2016 werd het daarom een veelgebruikte basisimage en draaiden talloze mensen die Alpine nooit zelf hadden geïnstalleerd, het dagelijks.

De keerzijde is dat musl geen glibc is, en dit verschil uit zich in bugs die ongerelateerd lijken. Een binary die gelinkt is tegen glibc faalt op Alpine met een melding die gebruikers laat zoeken naar een bestand dat al aanwezig is:

sh: ./myapp: not found

Het programma bestaat. De ELF-interpreter ervan niet, omdat de loader van glibc ontbreekt. Python is de andere gebruikelijke verrassing: prebuilt wheels die zijn gebouwd voor manylinux installeren niet op musl, waardoor pip terugvalt op compileren vanuit de broncode en stopt wanneer er geen compiler is geïnstalleerd. De musllinux wheel-standaard uit 2021 loste dit op voor projecten die dergelijke wheels publiceren, maar voor niemand anders.

Als host-besturingssysteem op een VPS installeert Alpine klein en updatet het snel, maar het brengt u buiten de gebaande paden waar de meeste documentatie vanuit gaat. Elke handleiding die u opdraagt om systemctl enable uit te voeren, moet worden vertaald naar rc-update add.

De onveranderlijke generatie: atomische updates en image-gebaseerde servers

De nieuwste tak verandert het updatemodel in plaats van de pakketlijst. Een op ostree gebaseerd systeem houdt /usr alleen-lezen. Een update is een volledige nieuwe bestandssysteemboom die wordt gedownload, klaargezet en bij de volgende herstart wordt geactiveerd. De vorige boom blijft behouden als opstartitem, waardoor een mislukte update ongedaan wordt gemaakt door opnieuw op te starten in de oude versie.

Fedora Silverblue bracht dit in 2018 naar de desktop en Fedora CoreOS bracht het in 2019 naar servers, nadat Red Hat in 2018 CoreOS had overgenomen. Flatcar Container Linux zette het oorspronkelijke Container Linux voort toen dat in 2020 werd stopgezet. openSUSE MicroOS bereikt hetzelfde resultaat via btrfs-snapshots en transactional-update. In 2024 voegde Red Hat een image-gebaseerde modus toe aan RHEL, gebouwd op bootc, waarbij het besturingssysteem wordt geleverd als een container-image en een machine wordt bijgewerkt door deze naar een nieuwe tag te verwijzen. Talos Linux gaat het verst en verwijdert de shell en SSH volledig: de machine wordt geconfigureerd via een API, waardoor er nergens op ingelogd kan worden. NixOS, voor het eerst uitgebracht in 2007, benadert dit vanuit een andere hoek. Het hele systeem wordt gebouwd vanuit één declaratieve configuratie en eerdere generaties blijven opstartbaar.

Uw provider biedt waarschijnlijk geen van deze opties aan als een image met één klik, omdat zij verwachten dat deze bij de eerste opstart worden geconfigureerd door Ignition of cloud-init in plaats van door een beheerder die bestanden bewerkt via SSH. Ze renderen hun voordeel bij veel identieke machines; dit is de situatie waarin u zich bevindt zodra u meerdere Linux-servers tegelijk beheert en u voor elke server moet kunnen aantonen dat deze identiek is aan de andere.

Hoe lang wordt een release ondersteund?

Het releasebeleid is het onderdeel van een distributie waar u het langst mee te maken heeft; dit wordt gepubliceerd als een aantal jaren. Hieronder staan de vensters voor 5 huidige server-releases.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine ondersteunt elke 3.x-branch gedurende 2 jaar. Daarom is het geschikter voor een container-image die u vaak opnieuw bouwt dan voor een host die u ongewijzigd laat. Het beveiligingsteam van Debian ondersteunt een stable-release gedurende ongeveer 3 jaar, waarna het LTS-team de gangbare architecturen in totaal tot ongeveer 5 jaar ondersteunt. Een Ubuntu LTS biedt u 5 jaar voor pakketten in main, en een Ubuntu Pro-abonnement verlengt dit tot 10 jaar, gratis voor persoonlijk gebruik op een klein aantal machines. RHEL 10 publiceert 10 jaar, wat de betaalde extended life cycle support-add-on uitbreidt tot 13. AlmaLinux 10 hanteert hetzelfde venster als RHEL van 10 jaar zonder enig abonnement; dit is precies de reden waarom deze rebuilds bestaan.

Arch staat niet in deze rij, omdat een rolling-distributie geen release heeft om te ondersteunen. Het getal dat voor Arch van belang is, is hoe lang u een machine ongemoeid kunt laten, en dat wordt gemeten in weken.

Waarom uw VPS-imagelijst er zo uitziet

Een provider levert de images waar klanten om vragen bij naam en die onbeheerd op de hypervisor worden geïnstalleerd. Daarom opent bijna elke lijst met een Ubuntu LTS en een Debian stable, voegt AlmaLinux of Rocky toe voor gebruikers wiens software is gecertificeerd voor RHEL, en plaatst Alpine, Arch en Fedora verderop op de pagina. Zodra u weet wat een VPS is en hoe het image de schijf bereikt, is het patroon duidelijk: de provider kiest besturingssystemen die een onbeheerde installatie overleven en langer worden ondersteund dan de gemiddelde klant de server behoudt.

De keuze verplicht u tot meer dan alleen een pakketbeheerder. Het bepaalt de upgrade die u over drie jaar uitvoert, en die verschillen volledig per familie. Debian en Ubuntu ondersteunen in-place major upgrades. De Red Hat-familie voert deze uit via leapp. Arch heeft geen upgrade omdat het geen versie heeft. Bij Alpine bewerkt u /etc/apk/repositories en voert u apk upgrade --available uit. De keuze bepaalt ook welke software u kunt installeren zonder een externe repository toe te voegen, wie de patch levert wanneer een CVE (common vulnerabilities and exposures) vermelding verschijnt voor software die u draait, en welk init-systeem en welke C-library uw toekomstige software als aanwezig beschouwt.

Er is nog een effect dat gemakkelijk wordt onderschat. De meeste antwoorden op internet gaan uit van een pad voor de Debian-familie of de Red Hat-familie; kiezen voor iets buiten deze twee betekent dat u gedurende de levensduur van de machine instructies moet vertalen. Kies de familie waarvan het releasebeleid overeenkomt met hoe vaak u bereid bent de server te onderhouden, en blijf daarbij. Het wijzigen van de pakketten daarbovenop is eenvoudig. Het wijzigen van de distributie daaronder betekent dat de machine opnieuw moet worden opgebouwd.

FAQ

Tot welke Linux-distributiefamilie behoort mijn server?

Voer cat /etc/os-release uit. Het veld ID vermeldt de distributie en ID_LIKE de familie; een Ubuntu-machine rapporteert dus ID_LIKE=debian en een AlmaLinux-machine ID_LIKE="rhel centos fedora". De pakketbeheerder is een ander kenmerk. apt en dpkg duiden op de Debian-familie, dnf en rpm op de Red Hat-familie, apk op Alpine en pacman op Arch.

Is CentOS nog steeds een gratis versie van RHEL?

Nee. CentOS Linux 8, de laatste rebuild met die naam, eindigde op 31 december 2021 en CentOS Linux 7 bereikte het einde van zijn levensduur op 30 juni 2024. Het overgebleven project, CentOS Stream, is de tak waaruit RHEL-minor-releases worden opgebouwd; wijzigingen verschijnen hier dus eerder dan in RHEL in plaats van later. De gratis rebuilds die de oude rol hebben overgenomen zijn AlmaLinux en Rocky Linux, beide met een ondersteuningstermijn van tien jaar.

Waarom levert Debian stable zulke oude versienummers?

Omdat het versienummer bevriest terwijl de correcties blijven komen. Debian backport beveiligingspatches naar de versie die het heeft uitgebracht in plaats van een nieuwere upstream-release te importeren. Een pakket dat 2.4.57-2+deb13u1 aangeeft, kan dus een correctie bevatten die vorige week is gepubliceerd. Het achtervoegsel na de upstream-versie is de Debian-revisie en apt changelog <package> vermeldt wat daarin is verwerkt. De beveiliging van een Debian-server beoordelen op basis van versienummers levert steevast een onjuist resultaat op.

Moet ik een rolling release zoals Arch op een VPS draaien?

Alleen als u deze volgens een vast schema bijwerkt. Een rolling distributie gaat ervan uit dat elke machine convergeert naar de huidige pakketset. Het bijwerken van één pakket met pacman -Sy foo leidt daarom tot niet-overeenkomende bibliotheken en fouten zoals cannot open shared object file. Voer regelmatig pacman -Syu uit en lees voor elke run de nieuwspagina van het project; dan blijft het systeem stabiel. Laat u het een jaar liggen, dan wordt de eerste upgrade riskant.

Wat verandert een immutable of atomic distributie precies?

Het verandert het moment waarop updates worden toegepast en hoe u deze ongedaan maakt. /usr is alleen-lezen aangekoppeld, een update wordt klaargezet als een volledig nieuwe boomstructuur en de overschakeling vindt plaats bij een herstart, waarbij de vorige boomstructuur als opstartitem behouden blijft voor een rollback. U krijgt een machine die ofwel volledig is bijgewerkt of helemaal niet, zonder half toegepaste statussen. U levert de mogelijkheid in om software te installeren door bestanden direct te bewerken; applicaties verhuizen daarom naar containers of gelaagde pakketten.