Arch vs NixOS als werkstation: professioneel en privégebruik

TL;DR Arch en NixOS heb ik allebei als dagelijkse machine gedraaid, en vandaag is het Arch op beide desktops en NixOS op de servers. Arch z’n reputatie voor kapotgaan is meestal een ontbrekende snapshot. Met btrfs, Snapper, dotfiles in git en een packagelijst kost een rollback 2 minuten en is de angst voor updates weg. NixOS verdient z’n leercurve terug zodra meerdere machines identiek moeten blijven, en op een server zou ik niks anders meer willen.

De vraag die ik het vaakst krijg van mensen die al Linux draaien is welke distro er op hun werkmachine moet. Arch of NixOS. Ze willen een werkstation dat ze van boven tot onder snappen, en ze zijn klaar met eentje dat zichzelf update wanneer iemand anders dat bedacht heeft.

Allebei heb ik gedraaid als m’n echte machine. Niet in een VM, niet voor een weekendje. Als de laptop waar ik m’n DevOps- en platform-engineering-werk op doe, en als de desktop waar al het andere op gebeurt. Dan weet je maar meteen waar ik uitkwam, want bij de tweede tabel had je het toch door. Arch op beide desktops, NixOS op de servers. Ik heb er redenen voor, en die zijn specifieker dan “Arch is fijner”, dus die loop ik met je door. De redenen zijn het nuttige deel.

Allebei goed. Allebei met trade-offs die ik op m’n eigen machine gevoeld heb. Welke past hangt meer van je leven af dan van de software, en m’n leven veranderde. Ik heb nu kinderen, dus de zaterdagmiddag voor een kapotte Xorg-config bestaat niet meer. De machine moet het doen, elke keer als ik de klep opendoe. Wat me verraste is dat Arch z’n reputatie voor instabiliteit grotendeels een skill issue bleek, en dat zet de hele vergelijking op z’n kop.

Het ene verschil waar al het andere aan hangt

Arch is een leeg canvas. Je bouwt het systeem stuk voor stuk en elk stuk is van jou. Het is mutable, dus je bewerkt bestanden, installeert packages, en het systeem drift en groeit met de jaren mee. Rolling release betekent dat je altijd op de huidige versie van alles zit.

NixOS is declaratief. Je beschrijft in configbestanden hoe het systeem eruit moet zien, en Nix bouwt precies dat. Het is grotendeels immutable. Aan het draaiende systeem kom je niet, je past de config aan en herbouwt, en elke wijziging is reproduceerbaar.

Dat verschil verandert hoe je over de machine denkt. Op Arch is het systeem iets wat je bijhoudt. Op NixOS is het de uitkomst van een bestand dat je van boven naar beneden kunt lezen.

Waar ik op vergelijk

Voor een werkende engineer met weinig vrije tijd beslissen vier dingen dit. Komt een update binnen zonder iets te slopen. Hoe snel heb je de package die je nodig hebt. Hoe steil is de leercurve. En hoe het is om er dag in dag uit in te leven. Ik splits het in werk en privé, want dezelfde trade-off komt er met het omgekeerde teken uit, afhankelijk van achter welke machine je zit.

Arch op het werk

Standaard Linux, om te beginnen. Alles werkt zoals de documentatie zegt en je spiergeheugen van de servers gaat één op één mee. De packages zijn actueel. De nieuwste kubectl, terraform of Go nodig? Staat in de repos of in de AUR, meestal binnen een paar dagen na de release. En de AUR dekt bijna al het andere. yay -S slack-desktop spotify en je bent klaar. De Arch Wiki is de beste Linux-documentatie die ik ken, voor welke distro dan ook. En er zitten geen abstractielagen tussen. Wat je installeert is wat er draait.

Dan de andere kant. Rolling release betekent dat er af en toe iets kapotgaat. Een kernelupdate sloopt je wifi-driver. Een library-bump breekt één app. Dat overkomt je. Niks is reproduceerbaar, dus “works on my machine” is geen grap meer en je collega krijgt jouw setup niet zomaar nagebouwd. Het drift. Na een jaar heb je zoveel geïnstalleerd dat je vergeten bent wat er staat en waarom. En rollback is er niet, tenzij je die zelf inricht, dus een update die iets breekt fix je met de hand.

Ik heb Arch jaren voor m’n werk gedraaid. In het begin verloor ik elke paar maanden tijd aan iets wat kapot was. Toen kreeg ik door dat de meeste “Arch is instabiel”-klachten, die van mij ook, kwamen van draaien zonder vangnet. Met de juiste setup houdt het bij mij sindsdien stand. De volgende sectie is die setup.

Arch een update laten overleven

Sinds de kinderen er zijn heb ik nul geduld met een kapotte laptop onder werktijd. M’n antwoord was Arch behandelen als semi-ephemeral. De machine mag elk moment omvallen, en binnen een paar minuten moet ik weer aan het werk kunnen. Het is hetzelfde resilience-denken dat ik op infrastructuur loslaat, nu gericht op m’n eigen laptop. Falen voorkomen heb ik opgegeven. Herstel goedkoop maken, dat wel.

De stack:

• Btrfs met Snapper. Een snapshot voor elke pacman-transactie. Gaat er iets stuk? snapper rollback en rebooten. Klaar.
• Timeshift met rsync als je niet op btrfs zit. Vergelijkbare bescherming, minder elegant.
• Dotfiles in git. M’n hele config zit in een chezmoi-repo. Verse installatie? chezmoi init --apply en m’n omgeving is terug.
• Een packagelijst in dezelfde repo. pacman -Qqe > pkglist.txt heen, pacman -S --needed - < pkglist.txt terug.
• Een aparte /home. Die overleeft een herinstallatie, dus m’n data ook.
• Volledige backups. Borg naar m’n NAS, dagelijks. In het ergste geval zet ik alles terug.

Dat geeft me drie manieren om te herstellen:

1. Klein probleem. Snapper-rollback, 2 minuten.
2. Groot probleem. Verse installatie, dan dotfiles, dan de packagelijst, 30 minuten.
3. Hardware dood. Nieuwe machine plus een backup terugzetten, 1 uur.

Vechten tegen rolling release heb ik opgegeven. Ik leun er nu juist op. Updates kunnen dingen slopen, dus heb ik slopen goedkoop gemaakt. Zodra een rollback 2 minuten kost, is een update niet eng meer. Ik update nu wekelijks. Gaat er iets stuk, dan rol ik terug en wacht op de fix. Geen debugsessie, geen ongemakkelijk berichtje aan een klant waarom ik te laat ben.

NixOS op het werk

Je configuration.nix beschrijft het hele systeem. Clone de repo, draai nixos-rebuild, en je hebt dezelfde machine. Elke generatie wordt bewaard, dus een slechte update betekent de vorige booten vanuit het bootmenu. Twee seconden. Geïnstalleerde packages staan in de config, dus er drift niks en je weet altijd wat er op de bak staat. nix-shell en devenv geven elk project z’n eigen dependencies zonder aan het systeem te komen. En experimenteren kost niks, want wat je ook sloopt, je rolt terug.

De prijs is de leercurve. De Nix-taal is een ding op zich, de documentatie is berucht dun, en de eerste weken zijn taai. Nixpkgs is enorm maar conservatiever dan Arch, dus op de nieuwste versie van iets wacht je soms weken. Het mentale model is ook anders. Even apt install en doorgaan zit er niet in, je moet declaratief denken. Al die generaties kosten schijfruimte, en /nix/store wordt groot. En sommige dingen zijn gewoon lastiger. Proprietary software, alles met een afwijkende layout, alles wat FHS aanneemt, daar moet extra werk in.

Ik ben voor m’n werk naar NixOS gegaan na één Arch-storing te veel. De eerste maand deed pijn. Nix leren, m’n config herschrijven, vechten met rare package-issues. Daarna hield het. Updates braken nooit iets, en nixos-rebuild switch op een vrijdagmiddag kon zonder erover na te denken. Toen ik een nieuwe laptop kreeg, draaide m’n complete omgeving binnen een uur.

Wat ik voor werk zou zeggen

Waar een kapotte machine echt geld kost, valt er weinig tegen de betrouwbaarheid van NixOS in te brengen. De adder onder het gras is de leertijd. Moet je morgen productief zijn en kun je geen week aan Nix kwijt, dan ben je op Arch eerder aan het werk.

Dus de vraag is wat downtime je kost. Betekent een kapot systeem een gemiste klantafspraak of een late deploy, dan verdient de Nix-leercurve zichzelf terug. Kun je af en toe een uurtje troubleshooten hebben, dan wint de vertrouwdheid van Arch. En hier wordt het nette antwoord rommelig. Zodra ik de snapshot- en backupdiscipline van hierboven had, zakte m’n Arch-downtime naar ongeveer wat NixOS me gaf, zonder die week Nix leren. Dat is wat me terug deed kantelen.

Arch thuis

Hier draait de trade-off om.

Op een privémachine is prutsen het doel. Arch dwingt je je systeem te begrijpen omdat je het zelf gebouwd hebt. Gamen wil de nieuwste Mesa-drivers en creatief werk wil de nieuwste GIMP, en Arch heeft ze als eerste. De AUR heeft die obscure Japanse rhythm game en die rare hardwaretool, want Arch-gebruikers packagen alles. De forums zijn actief en behulpzaam, zodra je geleerd hebt eerst de wiki te lezen. En het is leuk. Een systeem precies zoals jij het wilt, daar zit echte voldoening in.

De nadelen zijn dezelfde als op het werk. Ze prikken minder als het je eigen machine is en er niemand op je zit te wachten.

NixOS thuis

Home-manager geeft je declaratieve dotfiles, dus je hele gebruikersomgeving staat in configbestanden. Flakes maken die configs reproduceerbaar en samen te stellen. Je NixOS-config kan een publieke repo zijn waar anderen van leren en patches naartoe sturen. En heb je een laptop en een desktop, dan houdt één config ze identiek.

Wat je inlevert is het prutsen. Alles gaat via Nix. Even een binary pakken en draaien zit er niet in, wat mooi is voor de betrouwbaarheid en vervelend voor de “laat me dit even proberen”-jeuk. Gamen is meer werk. Proton en Steam draaien, maar Lutris en de diverse launchers willen allemaal Nix-wrappers. En dan het konijnenhol. Je besteedt meer avonden aan het perfectioneren van configuration.nix dan aan de computer gebruiken.

Wat ik voor thuis zou zeggen

Privé kies ik Arch, en hier hoef ik niet met mezelf in discussie. Het prutsen is de hobby. Dat er af en toe iets stukgaat hoort bij het plezier. Voor gamen en willekeurige software wint de flexibiliteit van Arch het van de puurheid van Nix.

Draai je dezelfde config op meerdere privémachines, of wil je je privé- en werksetup identiek, dan is het declaratieve model sterk genoeg om dat te veranderen. Voor mij, met één desktop, doet het dat niet.

Wat ik vandaag draai

De werklaptop is Arch met btrfs en Snapper. Met de snapshotdiscipline is hij stabiel gebleven, ik heb actuele tools zonder op nixpkgs te wachten, en herstel van wat dan ook is minuten weg. De privédesktop is ook Arch, dezelfde setup. Gamen werkt beter dan het op NixOS deed, en de AUR heeft alles wat ik wil. De homelab-servers zijn NixOS. Voor een server wint declaratieve config het glansrijk. Ik herbouw elke server vanuit git, en er drift niks omdat er niks kán driften.

Dus het patroon is Arch voor de machines waar ik achter zit, NixOS voor de machines waar ik niet achter zit. Op een desktop wil ik de vertrouwde Linux, de package op de dag dat hij uitkomt, en de vrijheid om iets te downloaden en te draaien. Snapshots en backups vangen de instabiliteit op. Op een server wil ik reproduceerbaarheid en infrastructuur als code, en een server heeft de nieuwste packages of de gamingsupport niet nodig die Arch op een desktop de moeite waard maken.

Naast elkaar

Package-beschikbaarheid

Systeembeheer

Development-workflows

Wie wat zou moeten kiezen

Kies Arch als:

• Je Linux diepgaand wilt leren
• Je eenvoud en transparantie waardeert
• Je af en toe troubleshooten niet erg vindt
• Gamen belangrijk is
• Je liever imperatief “gewoon doen” werkt

Kies NixOS als:

• Betrouwbaarheid kritiek is (werkmachine)
• Je meerdere machines beheert
• Je reproduceerbare omgevingen wilt
• Je van declaratieve configuratie houdt
• Je bereid bent vooraf leertijd te investeren

Kies allebei als:

• Je meerdere machines hebt met verschillende doelen
• Je stabiliteit wilt voor werk en vrijheid voor privé

Waar ik uitkwam

Een universeel antwoord is er niet, en ik ben op allebei tevreden geweest, om verschillende redenen.

Arch leerde me hoe Linux werkt, omdat ik elk onderdeel en elk configbestand zelf moest opzetten. NixOS leerde me declaratief denken, met elke wijziging in een bestand en elk experiment omkeerbaar. Beide lessen zijn blijven hangen.

Degene die m’n werkstationkeuze veranderde is simpeler. De instabiliteit van Arch is op te lossen. Wie zegt dat Arch constant kapotgaat, draait het meestal zonder snapshots en zonder herstelplan, en dat heb ik jaren zo gedaan. Geef het dat vangnet en het is net zo betrouwbaar als alles wat ik gedraaid heb, met actuele packages en vertrouwde tooling erbovenop.

Kinderen gaven me minder tijd om te prutsen. Ik dacht dat dat me naar NixOS op alles zou duwen. Het duwde me naar goedkoop herstel. Snapshots, dotfiles in git, een packagelijst en backups, dat is wat de rolling-release-angst heeft weggenomen.

Loer je naar Arch maar zit je over de stabiliteit in, bouw dan eerst het herstel. Btrfs en Snapper kosten een middagje, en dat middagje heeft zich bij mij meerdere keren terugverdiend. Update daarna. En voor servers blijf ik NixOS kiezen, elke keer, want een server hoort uit git herbouwbaar te zijn en verder nergens uit.

• Linux
• NixOS
• DevOps
• Desktop