Nixos.org: Unterschied zwischen den Versionen

Aus lugvswiki
Zur Navigation springenZur Suche springen
(Angelegt)
 
(Umgearbeitet)
Zeile 1: Zeile 1:
==Einführung in [http://nixos.org nixos.org]==
+
==Einführung in nixos.org==
  
 
''Zusammenfassung aus einer Email an die Mailingliste von Marc:''
 
''Zusammenfassung aus einer Email an die Mailingliste von Marc:''
  
Deswegen schreibe Ich hier nochmal die wichtigsten Features auf, auch
+
Die wichtigsten Features:
für jene die abwesend waren.
 
  
  url: nixos.org
+
URL: [http://nixos.org nixos.org]
  wiki: http://nixos.org/wiki/Main_Page (Mit Verweis zu Mailingliste)
+
WIKI: [http://nixos.org/wiki/Main_Page nixos.org/wiki/Main_Page] (Mit Verweis zu Mailingliste)
  irc: irc.freenode.net, #nixos
+
IRC:  [irc://irc.freenode.net irc.freenode.net]  #nixos
  unterstützte Architekturen: sheevaplug, i686, x64, PI, vielleicht noch
+
Unterstützte Architekturen: [http://de.wikipedia.org/wiki/SheevaPlug SheevaPlug], [http://de.wikipedia.org/wiki/I686 i686], [http://de.wikipedia.org/wiki/X64 x64], [http://de.wikipedia.org/wiki/Raspberry_Pi (Raspberry) PI], vielleicht noch ein paar mehr.
  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.
+
2 repositories nixos (system) und nixpkgs (Pakete) bilden mit /etc/nixos/configuration.nix (System-Konfiguration) ein Linux System.
Beispiel:
 
  
  /nix/store/hash-glibc-2.10
 
  /nix/store/hASH-glibc-2.11o
 
  /nix/store/HASH-firefox/bin/firefox (rpath wählt die passede gilbc)
 
  
 +
Einzelne Pakete werden ähnlich wie git Commits mit Hash versehen. Beispiel:
  
Damit ist est möglich verschiedene Programmversionen mit leicht
+
/nix/store/hash-glibc-2.10
variierenden Abhängigkeiten auf der gleichen Festplatte zu speichern,
+
/nix/store/hASH-glibc-2.11o
und entsprechend Umgebungen für Virtual-Machines etc zur Verfügung zu
+
/nix/store/HASH-firefox/bin/firefox (rpath wählt die passende gilbc)
stellen.
 
  
Jedes Paket hat klar definierte buildtime/runtime Abhängigkeiten, was
 
ein einfaches vollständigkes Kopieren auf andere Computer ermöglicht.
 
  
Wenn keine Binaries von der offiziellen Hydra-Buildfarm verwendet
+
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.
werden können (zb 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 'nen Treiber vergessen hat ists 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
+
Jedes Paket hat klar definierte buildtime/runtime Abhängigkeiten, was ein einfaches vollständiges Kopieren auf andere Computer ermöglicht.
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.
 
  
Für User gibts dann noch eigene Profile, so dass jeder User seine eigene
 
Software installieren kann.
 
  
Ein Nachteil der Reproduzierbarkeit (von beidem: funktionierenden Setups
+
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.
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
+
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.
aus dem Manual: http://hydra.nixos.org/build/4201682/download/1/nixos/manual.html
+
 
 +
 
 +
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.
 +
 
 +
 
 +
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 http://hydra.nixos.org/build/4201682/download/1/nixos/manual.html]
 +
 
 +
<nowiki>
 +
  {pkgs, config}:{
 +
 
 +
  # pkgs: alle installierbaren Pakete
 +
 
 +
  # config: Die System-Konfiguration
 +
 
 +
{
  
{pkgs, config}:{
 
# pkgs: alle installierbaren Pakete
 
# config: Die System-Konfiguration
 
{
 
 
   boot.loader.grub.device = "/dev/sda";
 
   boot.loader.grub.device = "/dev/sda";
  
 
   fileSystems."/".device = "/dev/disk/by-label/nixos";
 
   fileSystems."/".device = "/dev/disk/by-label/nixos";
  
   swapDevices =
+
   swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
    [ { device = "/dev/disk/by-label/swap"; } ];
 
  
 
   # mit openssh Server support
 
   # mit openssh Server support
 +
 
   services.sshd.enable = true;
 
   services.sshd.enable = true;
 +
 
   services.sshd.permitRootLogin = true;
 
   services.sshd.permitRootLogin = true;
  
 
   # und so weiter
 
   # und so weiter
}
+
}
 +
</nowiki>
 +
 
 +
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 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:
 +
 
 +
<nowiki>
 +
  ~/.nixpkgs/config.nix:
 +
 
 +
{
 +
 
 +
    packageOverrides = p: {
 +
 
 +
      vim_configurable = p.vim_configurable.override { pythonSupport = true; }
 +
 
 +
    }
 +
 
 +
}
 +
</nowiki>
 +
 
  
Wer mehr Interesse hat dem kann Ich Zugang zu einer virtual-machine
+
Dementsprechend einfach ist es auch dev/preview/alpha/beta/.. Programme zu supporten.
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 zB in dieser Art und Weise python support für Vim
+
KDE zum Beispiel ist unterstützt, GNOME desktop soweit Ich weiss nicht.
aktivieren, und dann eine für ihn kompilierte Version bekommen:
 
  
~/.nixpkgs/config.nix:
 
  
{
+
Es sind nur 20-30 mehr oder weniger "Freizeit-Entwickler", die das System voranbringen.
  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 weiss nicht.
+
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.
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, zB 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 gibts ab und zu auch Probleme, zB python/ruby etc erwarten
+
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.
manchmal, dass alles in einem Verzeichnis installiert wird. Hier muss
 
dann manchmal doch einiges gepatcht werden.
 

Version vom 24. Februar 2013, 15:59 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 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.


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 weiss 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 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.