Okay, danke für den Hinweis. Dass das irgendwie verschachtelt ist, hatte ich auch so den Eindruck aber heißt dass dann auch dass "from source" dann kompiliert wird oder so Sachen wie "git clone" eingebunden werden?
Im Prinzip ist Nix ein "from source"-Paketmanager, aber es gibt ein Cache-Konzept. Wenn Nix ein Paket bauen möchte, berechnet es zunächst aus allen Inputs (das schliesst indirekt alle transitiven Abhängigkeiten mit ein) einen Output-Hash. Im Normalfall ist dem System min. ein Binary-Cache bekannt (der von nixos.org) bekannt. Der Nutzer kann auch weitere hinzufügen, bis hin zu eigenen (z.B. in Firmen). Man kann sich auch z.B. via
cachix.org (neben anderen) einen privaten Cache anlegen. Viele Projekte haben dort einen Cache, so daß man, wenn man andere Projekte seine Konfig einbindet, nicht alles selbst bauen muß.
Nix schaut nun in allen ihm bekannten Caches nach einem Paket mit diesem Hash nach. Findet es das, wird es vom Cache geladen, ansonsten baut es das selbst. Man kann Nix auch zwingen selbst zu bauen. Oder wenn man Pakete aus dem Repo anpasst (z.B. Compiler-Flags ändern oder eigene Patches anwenden), muß Nix das Paket selber bauen, sofern sich der Output-Hash nicht zufällig in einem der Caches findet (z.B. in dem Firmen-eigenen Cache).
Das nette an Nix ist, daß es distributed Building unterstützt. Ich kann also z.B. in einer Firma mehrere Build-Maschinen bereitstellen und diese dem eigenen System bekannt machen (in der Nix-config). Dann verteilt Nix den Build auf diese Machinen. Man kann z.B. für unterschiedliche Architekturen unterschiedliche Builder bereitstellen und das lokale Nix sucht sich automatisch die passenden Builder passend zu dem, was man bauen möchte. Man kann auch in einem Aufruf sowas sagen wie "vvaluiere lokal, baue auf A, installiere auf B".
Wenn man Pakete in einer CI/CD-Pipline baut, kann man die Builds in seinen eigenen (Firmen)-Cache ablegen lassen.
Das sind aber fortgeschrittene Features, die kaum von Interesse sind, wenn man Nix nur als Paketmanager nimmt (man kann das aber nutzen, wenn man möchte).
Der Lerneffekt ist da bestimmt enorm wenn man sich da reinhängt.
In erster Linie ist die Lernkurve nicht ohne, da man viele Konzepte lernen muß. Zudem muß man erstmal mit dem Konzept funktionaler Programmierung warm werden – und dann noch in der speziellen Ausführung "Nix"(-lang). Aber wie schwer es ist, hängt davon ab, wie sehr man sich in die Nix-Welt wirft. Nix als Paketmanager ist nur leicht schwerer als andere Paketmanager. Einfache System-Konfigs schreiben (in Nix-lang) ist auch noch recht überschaubar. Aber wenn man eigene Pakete (das Pendant zu einem RPM-Paket) oder Konfigurationsmodule (ganz ganz grob das Pendant zu einem Ansible Modul) schreibt, dann steigt die Lernkurve nochmal zügig an.
LinuxFromScratch wäre auch so etwas woran ich mal Interesse hätte
Das ist anders schwer.
Ich würde es eher in die Ecke "akademische Beschäftigung mit einem Betriebssystem" betrachten. (Ich hab es allerdings nie selbst angefasst.)
