Nixos.org: Unterschied zwischen den Versionen

Aus lugvswiki
Zur Navigation springenZur Suche springen
(Umgearbeitet)
(orthografische Optimierungen + Back link)
Zeile 21: Zeile 21:
  
  
Damit ist es möglich verschiedene Programmversionen mit leicht variierenden Abhängigkeiten auf der gleichen Festplatte zu speichern, und entsprechend Umgebungen für Virtual-Machines etc zur Verfügung zu stellen.
+
Damit ist es möglich verschiedene Programmversionen mit leicht variierenden Abhängigkeiten auf der gleichen Festplatte zu speichern und entsprechend Umgebungen für Virtual-Machines etc. zur Verfügung zu stellen.
  
  
Zeile 30: Zeile 30:
  
  
Mehrere System-Konfigurationen auf der gleichen Festplatte bedeutet auch, dass man die "alten" Konfigurationen über Grub-Boot-Menues automatisch zur Verfügung stellen kann, wenn also ein neues Setup nicht bootet, weil man einen Treiber vergessen hat ist es kein Problem, man bootet das alte, behebt das Problem und versucht alles noch einmal.
+
Mehrere System-Konfigurationen auf der gleichen Festplatte bedeutet auch, dass man die "alten" Konfigurationen über Grub-Boot-Menues automatisch zur Verfügung stellen kann, wenn also ein neues Setup nicht bootet, weil man einen Treiber vergessen hat ist es kein Problem: man bootet das alte, behebt das Problem und versucht alles noch einmal.
  
  
Dadurch das alle Pakete, die ein System ausmachen, im /nix/store vorbereitet werden können, ohne das laufende System zu beeinträchtigen ist eine Umsetllung auf eine neue Version in sehr kurzer Zeit möglich. Es reicht aus PATH neu zu setzen, /etc neu zu füllen und alle Services neu zu starten.
+
Dadurch das alle Pakete, die ein System ausmachen, im /nix/store vorbereitet werden können ohne das laufende System zu beeinträchtigen ist eine Umstellung auf eine neue Version in sehr kurzer Zeit möglich. Es reicht aus PATH neu zu setzen, /etc neu zu füllen und alle Services neu zu starten.
  
  
Zeile 39: Zeile 39:
  
  
Ein Nachteil der Reproduzierbarkeit (von beidem: funktionierenden Setups und Bugs) ist das Security Update Problem: Wenn eine Lücke in curl gefunden wird (wie erst vor kurzem, Weiterleitung auf ftp:// ähnliche Protokolle), dann reicht es nicht aus curl.so zu ersetzen, sondern alles muss neu kompiliert werden.
+
Ein Nachteil der Reproduzierbarkeit (von beidem: funktionierenden Setups und Bugs) ist das Security Update Problem: Wenn eine Lücke in curl gefunden wird (wie erst vor kurzem, Weiterleitung auf ftp:// ähnliche Protokolle), dann reicht es nicht aus curl so zu ersetzen, sondern alles muss neu kompiliert werden.
  
  
Zeile 69: Zeile 69:
 
  </nowiki>
 
  </nowiki>
  
Wer mehr Interesse hat dem kann Ich Zugang zu einer virtual-machine geben, zum testen und ausprobieren.
+
Wer mehr Interesse hat dem kann ich Zugang zu einer virtual-machine geben, zum testen und ausprobieren.
  
  
Zeile 96: Zeile 96:
  
  
KDE zum Beispiel ist unterstützt, GNOME desktop soweit Ich weiss nicht.  
+
KDE zum Beispiel ist unterstützt, GNOME Desktop soweit ich weiß nicht.  
  
  
Zeile 105: Zeile 105:
  
  
Natürlich gibts ab und zu auch Probleme, zB python/ruby etc erwarten manchmal, dass alles in einem Verzeichnis installiert wird. Hier muss dann manchmal doch einiges gepatcht werden.
+
Natürlich gibt's ab und zu auch Probleme, zB python/ruby etc erwarten manchmal, dass alles in einem Verzeichnis installiert wird. Hier muss dann manchmal doch einiges gepatcht werden.
 +
 
 +
----
 +
Zurück zur [[Hauptseite]]

Version vom 26. November 2016, 19:16 Uhr

Einführung in nixos.org

Zusammenfassung aus einer Email an die Mailingliste von Marc:

Die wichtigsten Features:

URL:  nixos.org
WIKI: nixos.org/wiki/Main_Page (Mit Verweis zu Mailingliste)
IRC:  irc.freenode.net  #nixos
Unterstützte Architekturen: SheevaPlug, i686, x64, (Raspberry) PI, vielleicht noch ein paar mehr.


2 repositories nixos (system) und nixpkgs (Pakete) bilden mit /etc/nixos/configuration.nix (System-Konfiguration) ein Linux System.


Einzelne Pakete werden ähnlich wie git Commits mit Hash versehen. Beispiel:

/nix/store/hash-glibc-2.10
/nix/store/hASH-glibc-2.11o
/nix/store/HASH-firefox/bin/firefox (rpath wählt die passende gilbc)


Damit ist es möglich verschiedene Programmversionen mit leicht variierenden Abhängigkeiten auf der gleichen Festplatte zu speichern und entsprechend Umgebungen für Virtual-Machines etc. zur Verfügung zu stellen.


Jedes Paket hat klar definierte buildtime/runtime Abhängigkeiten, was ein einfaches vollständiges Kopieren auf andere Computer ermöglicht.


Wenn keine Binaries von der offiziellen Hydra-Buildfarm verwendet werden können (z.B. weil man eigene Patches verwenden will), kann man die Builds auf mehrere Rechner verteilen.


Mehrere System-Konfigurationen auf der gleichen Festplatte bedeutet auch, dass man die "alten" Konfigurationen über Grub-Boot-Menues automatisch zur Verfügung stellen kann, wenn also ein neues Setup nicht bootet, weil man einen Treiber vergessen hat ist es kein Problem: man bootet das alte, behebt das Problem und versucht alles noch einmal.


Dadurch das alle Pakete, die ein System ausmachen, im /nix/store vorbereitet werden können ohne das laufende System zu beeinträchtigen ist eine Umstellung auf eine neue Version in sehr kurzer Zeit möglich. Es reicht aus PATH neu zu setzen, /etc neu zu füllen und alle Services neu zu starten.


Für User gibt es dann noch eigene Profile, so dass jeder User seine eigene Software installieren kann.


Ein Nachteil der Reproduzierbarkeit (von beidem: funktionierenden Setups und Bugs) ist das Security Update Problem: Wenn eine Lücke in curl gefunden wird (wie erst vor kurzem, Weiterleitung auf ftp:// ähnliche Protokolle), dann reicht es nicht aus curl so zu ersetzen, sondern alles muss neu kompiliert werden.


Beispiel /etc/nixos/configuration.nix aus dem Manual: http://hydra.nixos.org/build/4201682/download/1/nixos/manual.html

  {pkgs, config}:{

   # pkgs: alle installierbaren Pakete

   # config: Die System-Konfiguration

 {

  boot.loader.grub.device = "/dev/sda";

  fileSystems."/".device = "/dev/disk/by-label/nixos";

  swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];

  # mit openssh Server support

  services.sshd.enable = true;

  services.sshd.permitRootLogin = true;

  # und so weiter
 }
 

Wer mehr Interesse hat dem kann ich Zugang zu einer virtual-machine geben, zum testen und ausprobieren.


Hier noch ein Beispiel, dass auch compile time Parameter einfach konfiguriert werden können, so dass vom nixos Distributions-Default einfach abgewichen werden kann: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/configurable.nix


Ein User würde z.B. in dieser Art und Weise python support für Vim aktivieren, und dann eine für ihn kompilierte Version bekommen:

  ~/.nixpkgs/config.nix:

 {

    packageOverrides = p: {

      vim_configurable = p.vim_configurable.override { pythonSupport = true; }

    }

 }
 


Dementsprechend einfach ist es auch dev/preview/alpha/beta/.. Programme zu supporten.


KDE zum Beispiel ist unterstützt, GNOME Desktop soweit ich weiß nicht.


Es sind nur 20-30 mehr oder weniger "Freizeit-Entwickler", die das System voranbringen.


Die Vorteile sind immer dann ganz besonders deutlich, wenn geringe Script-Features sinnvoll sind, z.B. beim definieren von systemd mit php-fpm Pools (die gleichen Sockets müssen an verschiedenen Stellen definiert werden: systemd, damit es php-fpm Daemon starten kann, apache und nginx, damit sie wissen wohin sie sich verbinden müssen etc). In solchen Fällen kann man dann einmal ein Nixos-Modul schreiben, und kann damit die Arbeit deutlich reduzieren.


Natürlich gibt's ab und zu auch Probleme, zB python/ruby etc erwarten manchmal, dass alles in einem Verzeichnis installiert wird. Hier muss dann manchmal doch einiges gepatcht werden.


Zurück zur Hauptseite