News Linux-Distribution: NixOS 26.05 erscheint mit mehr als 20.000 neuen Paketen

1. Reproduzierbarkeit & Updates
Dein Einwand ist richtig: Wenn du heute nixpkgs (das Paketrepository) ziehst, bekommst du andere Versionen als in drei Monaten. Die Config allein ist also nicht deterministisch – solange du keine Version fixierst.
Aber: NixOS verwendet standardmäßig einen Lockfile (bei Flakes heißt der flake.lock). Der wird automatisch aktualisiert, wenn du nix flake update ausführst, und legt exakt fest, welcher Snapshot von nixpkgs verwendet wird. Wenn du die Config + flake.lock auf einen anderen Rechner kopierst, bekommst du garantiert dasselbe System – gleiche Kernelversion, gleiche Paketversionen, alles identisch. Das ist die eigentliche "Superkraft" von NixOS.


2. Pinning & Updates
Genau – normalerweise definiert man keine konkreten Versionen. Stattdessen referenziert man einen nixpkgs-Input, der auf einen Branch zeigt (z.B. nixos-unstable oder nixos-26.05). Der flake.lock schnappt sich dann den aktuellen Commit dieses Branches und friert ihn ein.
  • nix flake update → aktualisiert den Lockfile auf den neuesten Commit (neue Paketversionen)
  • Ohne nix flake update → bleibt alles exakt gleich, auch nach Monaten
  • Für spezielle Fälle kannst du auch gezielt einen bestimmten Commit im Lockfile eintragen (url = github:NixOS/nixpkgs/<commit-hash>)
Wenn in der Config keine Version definiert ist und du kein Lockfile verwendest (also reine Config ohne Flakes), dann installiert nixos-rebuild switch tatsächlich die aktuellsten Pakete aus dem Channel, den du subscribed hast. Das ist die einzige Konstellation, in der dein Gedanke zutrifft.


Config + flake.lock = reproduzierbar. Nur Config ohne Lock = fließende Versionsstände. In der Praxis verwendet aber quasi jeder Flakes genau deshalb.
 
  • Gefällt mir
Reaktionen: KitKat::new() und Krik
@Krik
Solange du nix flake update nicht erneut ausführst, wird jeder spätere Build exakt dieselben Paketversionen nutzen, egal ob morgen oder in zwei Jahren.
nix flake update brauchst du nur dann, wenn du gezielt und kontrolliert alle deine Software-Pakete, den Kernel und die Treiber auf den neuesten Stand bringen willst, ohne sofort das System neu zu bauen.

Ich habe 4 Alias
Bash:
  # Aliases für alle Shells
  environment.shellAliases = {
  nfu = "cd ~/nixos-config && nix flake update";
  gts = "cd ~/nixos-config && git add . && git commit -m \"$(date +'%Y-%m-%d %H:%M')\"";
  nrs = "sudo nixos-rebuild switch --flake ~/nixos-config#pc";
  nup = "nfu && gts && nrs";
 };

Ich habe meine nix Dateien nach ~/nixos-config umgezogen, damit ich es ohne sudo Bearbeiten und speichern kann. Mit git commit(offline) und yubikey wird abgesichert, damit ich weiß, dass niemand außer mir die Dateien bearbeitet hat.
Meine flake:
Bash:
# /etc/nixos/flake.nix
{
  description = "NixOS configuration";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    stylix = {
      url = "github:nix-community/stylix";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = { self, nixpkgs, home-manager, stylix, ... } @ inputs: {
    nixosConfigurations = {
      pc = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        specialArgs = { inherit inputs; };
        modules = [
           stylix.nixosModules.stylix
          ./configuration.nix
          home-manager.nixosModules.home-manager {
        home-manager.useGlobalPkgs = true;
        home-manager.useUserPackages = true;
       home-manager.backupFileExtension = "backup";

        home-manager.users.rebellz = {
          imports = [          
            ./home.nix
            ./sway.nix
            ./quickshell-bar.nix        
         ];
            };
          }
        ];
      };
    };
  };
}


Meine NixOS Installation hat heute Jubiläum.
2 Jahre alt auf Tag genau.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Krik
xXMortiXx schrieb:
Config + flake.lock = reproduzierbar. Nur Config ohne Lock = fließende Versionsstände.
Die .lock-Datei habe ich irgendwie übersehen oder überlesen.
Vielen Dank für deine Antwort, sie war sehr ausführlich. 👍 😘

@D.S.i.u.S.
Da fehlt doch noch ein git push, sonst landet der Commit nur in deinem lokalem Repo. ;) Oder hast du kein Remote Repo (aufm NAS oder so)?
Als ich über NixOS gelesen habe, habe ich öfters gesehen, dass die Leute ihre Config gerne in ein (Remote) Repo schieben. Das ist schon genial, weil sie so quasi ein komplettes Backup des Systems angelegt haben.
 
Genau so ises.
Nixos is so lange genial wie es das Paket in dem repo gibt. Sobalds das nicht is wirds richtig komplex das rein zu bekommen wenn nicht sogar unmöglich.

Zudem ich finde die wichtigen Sachen hat man auf nem os egal welches auch so schnell wieder hergestellt oder halt einmalig mit nem Script erledigt.

Dazu lohnt sich oft der komplexere deklarative Ansatz nciht. Wobei die config find und fand icb immer cool in nixos weils echt easy zu verstehen war sobalds aber um flakes geht wirds echt komplex und es gibt dann auch noch Millionen mglk. Was umzusetzen.

Vor allem aufm Mac habe ich das gemerkt da kannst du ja auch den Package Manager nutzen. Aber das gibt’s so viele unterschiedliche mglk. Das umzusetzen Profiles das offizielle nixos pkg System was oft gar nicht funktioniert.

Irgendwann hatte ich kein Bock mehr und bin doch bei brew geblieben.
 
Lupin9 schrieb:
Genau so ises.
Nixos is so lange genial wie es das Paket in dem repo gibt. Sobalds das nicht is wirds richtig komplex das rein zu bekommen wenn nicht sogar unmöglich.
Also bisher habe ich bei nixos jedes Packet bekommen. Mein Problem ist nur das nicht alle so aktuell sind wie auf ArchLinux bzw. man halt manchmal etwas länger warten muss. Im großen und ganzen ist aber alles vorhanden. Ich weiß nicht genau ob NixOS nicht sogar eins der größten Repository (nixpkgs) hat im vergleich zu anderen. Einzig was unheimlich nervt ist das FHS wenn man z.B Appimage braucht. Das artet dann aus. Denke deswegen nutzen auch viele Flatpak. Wenn aber jemand ein Flake anbietet am besten noch ein Cachix dazu dann ist es echt einfach.
 
xXMortiXx schrieb:
Mein Problem ist nur das nicht alle so aktuell sind wie auf ArchLinux bzw. man halt manchmal etwas länger warten muss.
Sind dafür nicht Flakes gedacht, in die man die Git-Repos einträgt? Er würde sich dann immer den aktuellsten Code runterladen.

xXMortiXx schrieb:
Ich weiß nicht genau ob NixOS nicht sogar eins der größten Repository (nixpkgs) hat im vergleich zu anderen.
Hat es. Über 120k sollen sich darin befinden. ArchLinux hat nur 10k, und weitere 113k im AUR. Die Repos von CachyOS haben aktuell über 23k Pakete. Da sind aber viele doppelte Pakete drin, weil oft Pakete in "originaler" und in "optimierter" Form angeboten werden. Wer ein ArchLinux-Derivat hat, kann sich die Anzahl mit pacman -Ssq | wc -l ausgeben lassen.
 
Krik schrieb:
Sind dafür nicht Flakes gedacht, in die man die Git-Repos einträgt? Er würde sich dann immer den aktuellsten Code runterladen.
Naja nicht für jedes packet gibt es ein Flake. Aber ja es gibt möglichkeiten die auch so einzubinden. ist halt hin und wieder etwas Bastelarbeit. Man muss so etwas mögen :-)
Lieber ist mir aber ein Cache-Server da gehts wenigstens schneller :D
 
xXMortiXx schrieb:
Mein Problem ist nur das nicht alle so aktuell sind wie auf ArchLinux bzw. man halt manchmal etwas länger warten muss.
Als nixpkgs committer weise ich an der Stelle freundlich darauf hin, dass wenige Distributionen das Erstellen von Pull Requests so einfach machen wie wir. Du kannst also Teil der Problemlösung sein und Paketupdates beisteuern. :)

Abgesehen davon muss man natürlich auch beachten, dass NixOS im Gegensatz zu Arch keine Rolling Release Distribution ist. Wir haben ein halbjähriges Release Intervall. In der Regel sollen abwärtskompatible Paketupdates auch auf das aktuelle stabile Release ausgerollt werden, in der Praxis sind viele Maintainer da aber eher zurückhaltend, es gibt also hauptsächlich nur Sicherheitsupdates für viele Pakete, bis zum nächsten NixOS Release.

Für den Desktopeinsatz kann ich grundsätzlich die meiste Zeit nixos-unstable guten gewissens empfehlen, dann hat man auch immer direkt Zugriff auf die aktuellsten Pakete sobald diese eingepflegt wurden.
Wer problemlose automatische Updates auf Servern genießen möchte ist mit dem aktuellen Stable Release aber definitiv besser beraten.
 
  • Gefällt mir
Reaktionen: the_IT_Guy und KitKat::new()
Guten Morgen,

generell hast du recht. Klar kann man seinen Beitrag leisten. Aber anfangs möchte man einfach ein funktionierendes System :-D Alles andere kommt dann nach und nach.

Ein bisschen umgeschaut habe ich mich dort auch schon. Dabei musste ich aber feststellen, dass andere schneller waren. Dennoch gab es teilweise eine lange Wartezeit. Ich denke einfach, dass es an etwas anderem lag. Vielleicht weil Hydra Build-Probleme hatte, ich weiß es nicht so genau.

Erst mal geht es mir persönlich darum, dass mein System läuft, und da gibt es aktuell immer mal wieder was zu tun :-) Das liegt aber auch mit an der Lernkurve, vieles weiß man anfangs schlicht noch nicht.

Wenn man auf Unstable ist, dann ist es ja auch ein Rolling Release :-D Für einen Server würde ich aber nie auf Unstable gehen. Da ist die Aktualität auch nicht ganz so wichtig, finde ich. Wichtiger ist dort die Sicherheit.

Im Großen und Ganzen bin ich aber glücklich mit NixOS, ich vermisse Arch nicht. Man muss halt seine Gewohnheiten hier und da etwas ändern :-)
 

Ähnliche Themen

Zurück
Oben