Ein Major-Update steht an. Zudem binden wir Programme aus dem Rolling-Release-Zweig ein – und nutzen Software, ohne sie überhaupt zu installieren.
Es ist eine sehr günstige Fügung, dass in die noch laufende Artikelserie auch ein Major-Upgrade von NixOS fällt. Diese Steilvorlage nehme ich natürlich direkt auf.
Wer der Reihe gefolgt ist, hat mittlerweile ein solides NixOS-Setup auf einem oder sogar mehreren Rechnern. Das System läuft stabil, die Kommunikation mit Codeberg klappt reibungslos, und die zwei Skripte update-push und pull-update erledigen die Verwaltung mit einem einzigen Befehl. Eigentlich könnte man sich entspannt zurücklehnen.
Aber manchmal nervt es dann doch, wenn ein bestimmtes Programm in der stabilen Version ziemlich hinterherhinkt. Gerade beim Browser und meiner Fotosoftware machen ein paar Versionen manchmal einen echten Unterschied. Zum Glück hat NixOS auch dafür eine elegante Antwort parat.
Und dann gibt es noch die andere Seite: Was ist, wenn ich Chrome kurz für einen Test brauche, das Programm aber eigentlich nicht auf meinem System haben möchte? Auch dafür hat NixOS etwas Feines im Köcher.
Major Upgrade: Auf NixOS 26.05 wechseln
NixOS erscheint zweimal jährlich – im Mai und im November. Das Versionsschema ist dabei denkbar einfach: Jahr.Monat. Wir kommen gerade von 25.11 und wechseln auf 26.05.
Wichtig zu verstehen: update-push und pull-update führen zwar regelmäßig nix flake update aus – aber das aktualisiert nur die Pakete innerhalb des festgelegten Kanals. Solange nixos-25.11 in der flake.nix steht, bleibt man auf 25.11 – egal wie oft man updatet. Ein Versionssprung ist eine bewusste Entscheidung und passiert nie automatisch im Hintergrund. Das ist gewollt: kein ungewolltes Major-Upgrade, kein böses Erwachen am Montagmorgen.
Der Wechsel selbst ist erfreulich unspektakulär. Zwei Zeilen in der flake.nix ändern:
inputs = {
# Von nixos-25.11 auf nixos-26.05
nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";
nixpkgs-unstable.url = "github:NixOS/nixpkgs/nixos-unstable";
home-manager = {
# Auch home-manager auf release-26.05 anheben
url = "github:nix-community/home-manager/release-26.05";
inputs.nixpkgs.follows = "nixpkgs";
};
};
Danach:
update-push
Das war's. NixOS baut das System neu, GNOME, Kernel und alle stabilen Pakete kommen auf den Stand von 26.05. Läuft etwas schief, ist ein Rollback wie immer mit einem Befehl erledigt – oder durch Auswahl einer älteren Generation im Bootmenü.
Tipp: Es empfiehlt sich, ein paar Wochen nach dem offiziellen Release zu warten. In dieser Zeit werden die meisten Kinderkrankheiten gemeldet und behoben. NixOS macht das Warten aber entspannter als anderswo – dank Rollback kann man auch früh wechseln ohne wirklich etwas riskieren zu müssen.
Wichtiger Hinweis zur home.stateVersion: In der home.nix gibt es eine Zeile home.stateVersion = "25.11". Diese darf beim Versionssprung nicht geändert werden – sie beschreibt den Stand zum Zeitpunkt der Erstinstallation und dient Home Manager zur internen Kompatibilität. Das ist eine der wenigen Zeilen in NNixOS, dieman wirklich in Ruhe lassen sollte!
Pakete aus unstable einbinden
In den vorherigen Teilen haben wir nixos-26.05 als unseren stabilen Kanal eingerichtet. Stabil heißt hier: die Paketversionen sind eingefroren und ändern sich bis zum nächsten NixOS-Release nicht mehr wesentlich. Das ist sicher, aber manchmal auch etwas angestaubt.
Daneben gibt es nixos-unstable – den Rolling-Release-Zweig. "Unstable" klingt beängstigender als es ist. Alle Pakete durchlaufen auch dort die automatisierte NixOS-Testsuite (Hydra), bevor sie im Unstable-Zweig landen. In der Praxis ist nixos-unstable auf dem Desktop sehr gut verwendbar. Der Unterschied zum stabilen Kanal: die Pakete sind aktueller, manchmal tagesaktuell.
Die Idee: das Beste aus beiden Welten
Ich möchte nicht das gesamte System auf unstable umstellen – das wäre für GNOME, Kernel und Systemdienste weder nötig noch sinnvoll. Was ich möchte, ist: für ausgewählte Programme die neueste Version, für den Rest die bewährte Stabilität.
NixOS macht das möglich indem man einfach beide Kanäle gleichzeitig einbindet und dann je Paket entscheidet, welcher Kanal verwendet werden soll.
Schritt 1: flake.nix anpassen
In der flake.nix den unstable-Kanal als zweiten Input hinzufügen:
inputs = {
# Stabiler Kanal – für System, GNOME, Kernel
nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";
# Unstable-Kanal – für ausgewählte Programme
nixpkgs-unstable.url = "github:NixOS/nixpkgs/nixos-unstable";
home-manager = {
url = "github:nix-community/home-manager/release-26.05";
inputs.nixpkgs.follows = "nixpkgs";
};
};
Dann müssen die unstable-Pakete dem Rest des Systems bekannt gemacht werden. Das passiert über specialArgs (für die configuration.nix) und extraSpecialArgs (für die home.nix):
outputs = { self, nixpkgs, nixpkgs-unstable, home-manager, ... }:
let
system = "x86_64-linux";
# Unstable-Pakete als eigene Variable – allowUnfree nicht vergessen
pkgs-unstable = import nixpkgs-unstable {
inherit system;
config.allowUnfree = true;
};
common-modules = [
./configuration.nix
home-manager.nixosModules.home-manager
{
home-manager.useGlobalPkgs = true;
home-manager.useUserPackages = true;
home-manager.backupFileExtension = "backup";
# pkgs-unstable an home.nix weitergeben
home-manager.extraSpecialArgs = { inherit pkgs-unstable; };
home-manager.users.DEIN-USERNAME = import ./home.nix;
}
];
in {
nixosConfigurations = {
DEIN-HOSTNAME = nixpkgs.lib.nixosSystem {
inherit system;
# pkgs-unstable auch an configuration.nix weitergeben
specialArgs = { inherit pkgs-unstable; };
modules = common-modules ++ [
./hardware-configuration.nix
{ networking.hostName = "DEIN-HOSTNAME"; }
];
};
};
};
Schritt 2: home.nix anpassen
Die home.nix muss pkgs-unstable als Argument empfangen:
# Erste Zeile anpassen:
{ config, pkgs, pkgs-unstable, ... }:
Danach kann man je Paket wählen: stabiler Kanal oder unstable? Das Prinzip ist denkbar einfach – statt pkgs.paketname schreibt man pkgs-unstable.paketname:
home.packages = [
# Aus stable – ändert sich selten, läuft zuverlässig
pkgs.git
pkgs.starship
# Aus unstable – immer die neueste Version
pkgs-unstable.libreoffice-fresh # Office-Suite
pkgs-unstable.thunderbird # E-Mail
pkgs-unstable.obsidian # Notizen (unfree)
];
Hinweis: Da pkgs-unstable explizit mit allowUnfree = true initialisiert wurde, funktionieren auch proprietäre Pakete wie Obsidian ohne weitere Konfiguration – vorausgesetzt nixpkgs.config.allowUnfree = true steht ebenfalls in der configuration.nix.
Schritt 3: System neu bauen
update-push
Beim ersten Mal dauert es etwas länger – Nix lädt jetzt zwei Kanäle und baut die unstable-Pakete erstmalig. Danach ist es wie gewohnt.
Was passiert beim Update?
Hier liegt eine wichtige Nuance. Das Skript update-push führt nix flake update aus – das aktualisiert die flake.lock für beide Kanäle. Stable-Pakete bekommen ihre regulären Sicherheits-Updates, unstable-Pakete rücken auf die tagesaktuellen Versionen vor. Das Beste aus beiden Welten, genau wie versprochen.
Sonderfall: Module aus unstable beziehen
Wer meiner Reihe aufmerksam gefolgt ist, stellt jetzt vielleicht fest: Firefox steht in der home.nix gar nicht als pkgs-unstable.firefox – Firefox ist bei uns als NixOS-Modul installiert. Und Module funktionieren anders als einfache Pakete.
Ein Modul wie programs.firefox ist tief ins System integriert. Es lässt sich nicht einfach auf pkgs-unstable umbiegen, weil das Modul intern auf das stabile pkgs.firefox zeigt. Der Trick heißt Overlay – man sagt NixOS: „Wenn du firefox aus pkgs holst, nimm bitte die unstable-Version."
Das passiert in der configuration.nix:
# pkgs-unstable wird via specialArgs übergeben (siehe flake.nix)
{ config, pkgs, pkgs-unstable, ... }:
{
# Overlay: firefox aus pkgs wird durch die unstable-Version ersetzt
nixpkgs.overlays = [
(final: prev: {
firefox = pkgs-unstable.firefox;
})
];
# Das Modul selbst bleibt unverändert – es greift nun automatisch
# auf die unstable-Version zu
programs.firefox = {
enable = true;
languagePacks = [ "de" ];
};
}
Das Schöne daran: Das Modul programs.firefox muss überhaupt nicht angefasst werden. Es merkt durch den Overlay nicht einmal, dass es jetzt eine andere Firefox-Version verwendet – es fragt einfach nach pkgs.firefox, und der Overlay liefert still und leise die unstable-Version.
Das gleiche Prinzip funktioniert für jedes andere Modul – überall wo pkgs.paketname im Hintergrund steht, kann man durch einen Overlay die unstable-Version einschleusen.
Wegwerf-Pakete – Software ohne Installation
Nixos hat noch einen Trick auf Lager, der mich beim ersten Mal wirklich begeistert hat. Die Frage: Was tun, wenn ich ein Programm einmalig brauche, es aber nicht dauerhaft installieren möchte?
Klassische Antwort: installieren, benutzen, deinstallieren – und dabei hoffen, dass keine Spuren zurückbleiben. Genau das ist unter normalen Linux-Systemen oft mühsam, weil Deinstallation selten wirklich vollständig ist.
NixOS-Antwort: einfach gar nicht erst installieren.
nix-shell – die Wegwerf-Umgebung
Der Befehl nix-shell -p paketname öffnet eine temporäre Shell in der das gewünschte Programm verfügbar ist. Verlässt man die Shell, ist das Programm wieder weg – aus dem PATH zumindest. Der Nix-Store räumt beim nächsten Garbage-Collection-Lauf auch den Rest auf.
Das Paradebeispiel ist Chrome. Google Chrome möchte ich nicht dauerhaft auf meinem System haben – aber manchmal brauche ich ihn kurz, um etwas in einem anderen Browser zu testen oder eine Seite zu besuchen, die Firefox partout nicht mag.
NIXPKGS_ALLOW_UNFREE=1 nix-shell -p google-chrome --impure
Die Umgebungsvariable NIXPKGS_ALLOW_UNFREE=1 ist nötig weil Chrome proprietär ist. Das --impure erlaubt Nix diese Variable zu lesen. Der Download dauert beim ersten Mal einen Moment – danach öffnet sich eine neue Shell in der google-chrome als Befehl bereitsteht:
google-chrome
Browser benutzen, fertig, Shell verlassen:
exit
Chrome ist wieder weg. Kein Eintrag in der home.nix, kein Rebuild, keine Spuren.
nix run – noch kürzer
Wer nicht einmal eine Shell öffnen möchte, kann nix run verwenden:
NIXPKGS_ALLOW_UNFREE=1 nix run --impure nixpkgs#google-chrome
Ein Befehl, Programm startet, fertig. Schließt man das Fenster, ist es vorbei.
Wann ist das sinnvoll?
Das ist nicht nur ein Spielzeug für Neugierige. Es gibt handfeste Anwendungsfälle:
- Kompatibilitätstest: Wie sieht meine Webseite in Chrome aus?
- Einmalige Aufgabe: Ein PDF-Werkzeug für genau dieses eine Dokument.
- Ausprobieren: Bevor man ein Paket dauerhaft in die
home.nix schreibt, einfach mal schauen ob es das Richtige ist.
- Fremder Rechner: Auf einem Rechner den man nicht administriert, kann man so Software verwenden ohne etwas zu verändern.
Für freie Software entfällt die ganze NIXPKGS_ALLOW_UNFREE-Zeremonie – Chromium zum Beispiel geht einfach so:
nix-shell -p chromium
Der Unterschied zu nix-env
Aufmerksame Leserinnen und Leser erinnern sich vielleicht, dass wir in Teil 3 kurz nix-env -iA nixos.git verwendet haben – mit dem Hinweis, dass das nicht die bevorzugte Methode ist. Der Unterschied:
nix-env installiert dauerhaft ins Benutzerprofil – imperativ, der Zustand landet nicht in der Konfigurationnix-shell -p ist temporär – verschwindet nach dem Schließen der Shellhome.nix ist deklarativ – der Nix-Way für alles was dauerhaft da sein soll
Für Git in Teil 3 war nix-shell -p git die eigentlich sauberere Wahl – die temporäre Shell hat ausgereicht um den einmaligen Setup-Schritt zu erledigen.
Fazit
Vier Werkzeuge, die das NixOS-Erlebnis noch runder machen: das Major Upgrade auf 26.05 in zwei Zeilen, pkgs-unstable für Programme wo die neueste Version wirklich zählt, der Overlay-Trick für Module wie Firefox, und nix-shell für alles was man einmal braucht und dann nie wieder sehen möchte. Zusammen ergibt das ein System das sowohl aktuell als auch stabil ist – und das trotzdem keine unnötige Software ansammelt.
Artikel der NixOS-Reihe
GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren
Chat-Gruppen oder im
Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das
Formular auf unserer Webseite ein.
Das Spiel gibt an bestimmten Stellen Hinweise, wenn etwas noch nicht stimmt. Wer zum Beispiel einen Gesteinsplaneten besiedelt hat, aber noch keinen Bergbau erforscht, bekommt den Hinweis direkt im Dashboard. Kein stilles Warten, keine Raterei warum die Rohstoffe nicht wachsen. Der Tipp verschwindet, sobald die passende Forschung gestartet ist.
sollte 2044 sein. Aber 20044 ist cooler 
