Nixos.org - Versionsgeschichte

Marc: /* Einführung in nixos.org */

2022-05-26T16:01:49Z

Einführung in nixos.org

Marc: Beispiel Haskell development mit NixOS

2022-05-26T16:00:54Z

Beispiel Haskell development mit NixOS

Marc: Update mit einer konkreten Konfiguration die Bekannte von mir nutzen.

2022-05-26T15:41:20Z

Update mit einer konkreten Konfiguration die Bekannte von mir nutzen.

Änderungen zeigen

Stippi: orthografische Optimierungen + Back link

2016-11-26T17:16:23Z

orthografische Optimierungen + Back link

Ulf: Umgearbeitet

2013-02-24T14:59:55Z

Umgearbeitet

Änderungen zeigen

Ulf: Angelegt

2013-02-24T11:49:31Z

Angelegt

Neue Seite

==Einführung in [http://nixos.org nixos.org]==

''Zusammenfassung aus einer Email an die Mailingliste von Marc:''

Deswegen schreibe Ich hier nochmal die wichtigsten Features auf, auch
für jene die abwesend waren.

url: nixos.org
wiki: http://nixos.org/wiki/Main_Page (Mit Verweis zu Mailingliste)
irc: irc.freenode.net, #nixos
unterstützte Architekturen: sheevaplug, i686, x64, 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 passede gilbc)

Damit ist est 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ändigkes Kopieren auf andere Computer ermöglicht.

Wenn keine Binaries von der offiziellen Hydra-Buildfarm verwendet
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
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
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 zB 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, 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
manchmal, dass alles in einem Verzeichnis installiert wird. Hier muss
dann manchmal doch einiges gepatcht werden.

@@ Zeile 2: / Zeile 2: @@
 Paketliste: https://search.nixos.org/packages oder Overlays auf Github (unterschiedliche Qualität)
 Webseite: https://nixos.org
 Dokumentation: https://nixos.org/manual/nixos/stable/
@@ Zeile 603: / Zeile 605: @@
+}
 </pre>
 == Zusammenfassung: ==

← Nächstältere Version		Version vom 26. Mai 2022, 16:00 Uhr
Zeile 633:		Zeile 633:
	Aber ein Crash oder halbfertiges System beim Benutzer (Update-Probleme) sind		Aber ein Crash oder halbfertiges System beim Benutzer (Update-Probleme) sind
	passieren nicht mehr oder sind zurückstellbar in kalkulierbaren 5 Minuten.		passieren nicht mehr oder sind zurückstellbar in kalkulierbaren 5 Minuten.
		+
		+
		+
		+	== Wie geht nutzt man z.B. Python oder Haskell mit NixOS? ==
		+
		+	<pre>
		+	cabal2nix_init(){
		+	local dir=$(basename `pwd`)
		+	local defaultGHC=${1:-ghc921}
		+
		+	$(nix-build -A cabal2nix $NIXPKGS_ALL)/bin/cabal2nix . > $dir.nix
		+
		+	cat > default.nix << EOF
		+	{ nixpkgs ? import <nixpkgs> {}, compiler ? "${defaultGHC}" }:
		+	nixpkgs.haskell.packages.\${compiler}.callPackage ./$dir.nix { }
		+	EOF
		+
		+	cat > shell.nix << EOF
		+	{ nixpkgs ? import <nixpkgs> {}, compiler ? "${defaultGHC}" }:
		+	(import ./default.nix { inherit nixpkgs compiler; }).env
		+	EOF
		+
		+	# nix-shell -A env ./default.nix
		+	</pre>
		+
		+	das cabal2nix_init Script erstellt einige .nix Dateien die dann genutzt werden
		+	um die Abhängikgeiten im Store bereitzustellen. Dann kann mit nix-shell eine Shell
		+	bereitgestellt werden wo ghc ghc-pkg cabal etc vorhanden sind und jene finden.
		+	D.h. einem ./Setup configure && ./Setup build steht nichts mehr im Wege.
		+
		+	Das geht meistens gut - manchmal leider auch nicht.
		+
		+	Ähnliche Tools gibts für Ruby, Python ..
		+
		+	Auf die Art und Weise lassen sich auch derivations generieren so dass man
		+	Software über environment.systemPackages schnell installieren kann.
		+
		+	Nach meiner Meinung ist das alles einfacher als Pakete für Debian / Suse
		+	bereitzustellen (wenns klappt)

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