Guix - das fortschrittlichste Betriebssystem

Published on January 21, 2019

Guix - das fortschrittlichste Betriebssystem

Ursprünglicher Autor: Pierre Neidhardt
  • Übersetzung
Betriebssysteme (OS) sind ein umfangreiches Thema. Hier dominiert seit Jahrzehnten ein Ansatz: Unix. In der Tat sind die meisten modernen Systeme, einschließlich der meisten GNU / Linux-Distributionen, * BSD und macOS, an die Unix-Architektur gebunden. (Windows ist nicht, aber es gibt fast nichts Interessantes zu diesem Thema).

Im Jahr 2000 hielt Rob Pike eine Präsentation darüber, warum Systemsoftwareforschung nicht relevant ist . Aufgrund von Pessimismus oder Vernachlässigung der Community scheint er die Beschwerden, die von vielen Unix-Anwendern im The Unix-Haters Handbook (1994) gesammelt wurden, völlig ignoriert zu haben . Das Buch ist absichtlich sarkastisch, weist aber auf einige kritische Probleme von Unix-Systemen hin - und diese wurden noch nicht gelöst.

2006 veröffentlichte Elko Dositra seine Dissertation"Voll funktionsfähiges Software-Bereitstellungsmodell" , das den funktionalen Paketmanager Nix beschreibt. Im Jahr 2008 veröffentlichte der Autor NixOS: eine voll funktionsfähige Distribution von Linux . Während NixOS viele freie Software für Unix-Systeme wiederverwendet, ist es so weit von Unix-Design und -Philosophie entfernt, dass es kaum als "Unix-System" bezeichnet werden kann.

Nix ist ein riesiger Fortschritt in der Systementwicklung. Dieses Betriebssystem hat nicht nur viele Unix-Probleme gelöst (einschließlich Kritik aus der oben genannten Sammlung), sondern auch den Weg für viele andere Funktionen und Forschungen geebnet, die in unserer Zeit, in der Zuverlässigkeit und Sicherheit das Hauptthema vieler wissenschaftlicher, öffentlicher und politischer Themen geworden sind, eine sehr wichtige Rolle spielen können Debatten.

Pike hat sich geirrt. Und dies ist ein weiterer allgemeiner Punkt: Es ist wahrscheinlich klüger, die Irrelevanz von Forschungen nicht zu deklarieren, wenn Sie die Unmöglichkeit einer weiteren Entwicklung nicht nachweisen können. Und der erwähnte Bericht kann kaum als mathematischer Beweis angesehen werden. Er hat nur die Idee bekräftigt, dass Unix „gut genug“ ist und dass man sich mit seinen Funktionen und Problemen auseinandersetzen sollte.

Glücklicherweise war dieser unnötige Pessimismus kurzsichtig und hielt nicht lange an: Nur ein paar Jahre später bewies das Nix-System, dass er falsch lag.

Guix Aussehen


Guix ist der Paketmanager unter Nix, und GuixSD ist das Betriebssystem, das NixOS entspricht und ein "voll programmierbares Betriebssystem" sein soll. Tatsächlich ist hier fast alles im Guile-Schema geschrieben und konfiguriert : von der Guix-Paketverwaltung bis zum GNU-Shepherd- Initialisierungssystem .

Guix unterscheidet sich erheblich von Unix-Betriebssystemen. Sie können die Dokumentation anzeigen und den Grad der Änderung bewerten:


Guix Vorteile


Die Vorteile von Guix sind so revolutionär, dass die übrigen Betriebssysteme im Vergleich dazu veraltet aussehen.

Meine persönlichen Lieblingsmerkmale:

  • Unverwundbarkeit des Systems: Guix zeichnet alle Änderungen auf System- und Benutzerebene auf. Wenn das Update etwas kaputt macht, können Sie jederzeit einen Rollback durchführen. Dies macht das System praktisch unverwundbar .
  • Integrität: Da die Konfiguration deklarativ ist, erhält der Benutzer oder Systemadministrator die vollständige Kontrolle. In anderen Versionen ist es unter Unix viel schwieriger zu erkennen, wann sich eine zufällige Konfigurationsdatei ändert.
  • Voll programmierbares Betriebssystem: Programmieren Sie Systemkonfigurationen und verwenden Sie das Versionskontrollsystem. Viele Systemdienste können im Guile-Schema konfiguriert werden: von udev-Regeln bis zu Xorg, PAM usw. Dank Guile kann die Konfiguration an der Hardware oder sogar am Hostnamen liegen!
  • Direkter Ersatz für andere (nicht so gute) Paketmanager: Warum Emacs-, Python- oder TeXlive-Pakete separat verwalten, wenn es für jeden eine einzige Schnittstelle gibt (siehe unten )! Es ist einfacher, Deklarationen für Benutzerprofile zu schreiben und zu verwalten.
  • Definitionen Pakete mit Guile: viel effektiver die Definition eines Pakets in der Entwicklung einer Masse um. Es ersetzt vorteilhaft Konzepte wie die Portage USE-Flags (siehe unten ).
  • Verschiedene Arten der Ausgabe von Paketen: Ein Guix-Paket kann verschiedene Arten der Ausgabe haben, die dazu dienen, verschiedene Komponenten (Bibliotheken, zusätzliche Tools, Dokumentation usw.) voneinander zu trennen. Auf anderen Betriebssystemen (normalerweise Debian) ist es schwieriger zu erraten, welche Pakete für einander geeignet sind.
  • Nicht propagierte Eingaben: In der Guix-Terminologie sind „Eingaben“ Paketabhängigkeiten. Das Benutzerprofil und die Umgebung enthalten nur explizit installierte Benutzerpakete und nicht unbedingt deren Abhängigkeiten. Siehe z. B. inxi  - ein Systeminformationsberichtstool: Wenn ich nur an inxi-System- / Geräteberichten interessiert bin, müssen nicht PATHzwei bis drei Dutzend zusätzliche Befehlszeilentools hinzugefügt werden. Mit Guix können Sie nur das anzeigen, was Sie wirklich in Ihrem Benutzerprofil benötigen.
  • Guix-Umgebungen: Beim Start guix environment SOME-PACKAGESrichtet Guix eine temporäre Umgebung ein, in der alle Anforderungen für dargestellt werden SOME-PACKAGES. Dies kann verwendet werden, um auf einfache Weise die Build-Umgebung für ein Projekt sowie für andere Zwecke einzurichten (siehe unten). Eine bemerkenswerte Eigenschaft: Mit ihnen können Sie Programme ausführen, ohne sie im Benutzerprofil festzulegen.
  • Teilaktualisierungen: 100% unterstützt. Dies ist wahrscheinlich der Hauptgrund für Ausfälle in Floating-Releases wie Arch Linux und Gentoo: Da nur wenige Versionen gleichzeitig unterstützt werden (normalerweise nur eine), sollte das gesamte System als Ganzes aktualisiert werden. Dies bedeutet mehr Verkehr mit jedem Update. Mit Guix wird jedes Paket separat aktualisiert.
  • Kontinuierliche Integration oder warum Guix ohne Paketbetreuer arbeiten kann: Dank reproduzierbarer Builds und Unterstützung für Teilaktualisierungen funktioniert ein Paket in Guix immer und bricht nicht mit dem nächsten Update einer Abhängigkeit (genauer gesagt, wenn die Abhängigkeit das Paket bricht, dann wird es trivial korrigiert, um die richtige Version der Bibliothek zu verwenden). Auf diese Weise kann die Arbeit mit Paketen auf „Montagefarmen“ übertragen werden (eine an Hydra aus dem Nix-Projekt, die andere an Cuirass)). Vergleichen Sie dies mit den meisten anderen GNU / Linux-Communities, für die Dutzende von Betreuern Tausende von Paketen aktualisieren müssen. Dieser Ansatz ist nicht skalierbar: Infolgedessen stagnieren diese Distributionen auf einigen tausend Paketen. In Guix kann die Anzahl der Pakete leicht wachsen, ohne dass ein Zusammenbruch befürchtet wird. Gleichzeitig können Mitwirkende effizienter eingesetzt werden.

    Guix lässt sich genauso einfach aus dem Quellcode erstellen. Tatsächlich ist dies für den Endbenutzer nicht so wichtig: Guix kann problemlos von der Quelle zum Erstellen zurückkehren, wenn nicht das gesamte Paket verfügbar ist.
  • guix importund guix refresh: automatische und rekursive Erstellung oder Aktualisierung von Paketdefinitionen. Hunderte von Definitionen werden gleichzeitig verarbeitet. Solche Funktionen unterstreichen die Vorteile einer echten Programmiersprache im Betriebssystem. Was in den meisten Betriebssystemen eine schwierige Aufgabe ist, lässt sich in Guix relativ einfach implementieren.
  • Guix-Kanäle: eine meiner Lieblingsfunktionen! In Arch Linux oder Gentoo müssen Sie ein lokales Repository erstellen. Da sie keine Teilaktualisierungen unterstützen, muss der Benutzer von Zeit zu Zeit einige Wartungsarbeiten durchführen (d. H. Sicherstellen, dass Abhängigkeitsaktualisierungen keine Pakete beschädigen). Guix-Feeds nutzen AUR aus Arch Linux- und Gentoo-Overlays, sodass jeder seine Paketdefinitionen beispielsweise aus Git-Repositories verteilen kann. Auch dies garantiert volle Transparenz (Kickbacks, Historie usw.).
  • Emacs-Guix : Soweit ich weiß, ist Guix die einzige Distribution, die über die leistungsstärkste Emacs-Benutzeroberfläche verfügt!
  • Guix-Packs : Eine echte Alternative zu Containern wie Docker. Die meisten Containersysteme leiden unter kritischen Problemen: Sie sind nicht replizierbar und in Wirklichkeit undurchsichtige Binärdateien, was für Benutzer, die Wert auf Vertrauen, Sicherheit und Datenschutz legen, völlig inakzeptabel ist . Im Gegensatz dazu sind Guix-Packs absolut klar, reproduzierbar und transparent.
  • guix system vmund guix system disk-image: Guix macht es einfach, das gesamte aktuelle System als Live-USB, in einer VM oder auf einem Remote-Computer abzuspielen.

Guix im Vergleich zu Mitbewerbern


Debian, Arch Linux und die meisten anderen GNU / Linux-Distributionen


Bei GNU / Linux-Distributionen fehlen normalerweise die oben genannten Guix-Vorteile. Die kritischsten Mängel:

  • Fehlende Unterstützung für mehrere Paketversionen oder "Abhängigkeitshölle". Nehmen wir an, das letzte mpv erfordert ein neues ffmpeg, aber das Aktualisieren von ffmpeg bricht die meisten anderen Programme ab. Wir stecken in einem Dilemma: Entweder brechen wir einige Pakete oder wir behalten alte Versionen. Schlimmer noch, es gibt möglicherweise überhaupt kein geeignetes Paket oder es gibt keine Unterstützung für das Betriebssystem. Dieses Problem ist den meisten Distributionen eigen, die die Ausführung ihrer Hauptaufgabe nicht garantieren können: ein Paket für ein Programm.
  • Kritische Abhängigkeit von Betreuern. Nicht funktionierendes Paketmanagement bedeutet, dass alle Pakete ständig auf Kompatibilität geprüft werden müssen. Dies ist eine Menge harter Arbeit für diejenigen, die diese Aufgabe übernommen haben. In der Praxis bedeutet dies, dass die Qualität des Paketmanagements in hohem Maße von den Menschen abhängt. Eine Distribution ohne eine ausreichende Anzahl von Betreuern wird unweigerlich leiden und möglicherweise sterben. Dieser Arbeitsaufwand ist nicht normal skalierbar und führt mit zunehmender Anzahl von Paketen zu einer Zunahme der Komplexität (sowohl in der Codebasis als auch in der Verwaltung).

Gentoo, * BSD


In Gentoo und anderen Ausschüttungen aus dem Paketmanager Portage ist das berühmte Merkmal: die USE - Flags Funktionen im gesamten System zu aktivieren (zB Mute aktivieren GUI - Unterstützung, etc ...).

Die USE-Flags machen das Aktivieren und Deaktivieren von Funktionen des Paketautors zum Kinderspiel (und der Vorteil ist, dass sie getestet werden). Portage hingegen erlaubt keine Funktionen, die nicht im Voraus durchdacht wurden. Wenn das Paket beispielsweise einen zusätzlichen Sound hat, der Autor jedoch das entsprechende Flag nicht gesetzt hat, kann der Benutzer nichts dagegen unternehmen (außer zum Erstellen einer neuen Paketdefinition).

Im Vergleich dazu ermöglicht Guix die vollständige Anpassung von allem, wenn auch mit etwas mehr Schema-Code. Im Pseudocode sieht es so aus:

(loop-over (TARGET-PACKAGES)
  (package
    (inherit TARGET)
    (changes-here... including patches, build options, etc.))

Dieser Code legt die Definitionen für das Paket TARGET-PACKAGESmit Ihren Änderungen fest. Keine der Änderungen muss an der Paketdefinition vorgenommen werden. Der Benutzer behält jederzeit die volle Kontrolle über die Änderungen, die an den Paketen vorgenommen werden können.

Ich habe Gentoo geliebt, aber nach dem Wechsel zu Guix wurden die Einschränkungen von Portage offensichtlich.

  • Das USE-Flags-System erlaubt keine Konfiguration ungeplanter beliebiger Funktionen.
  • Die Verwendung von Flags fügt eine ganze Klasse von Komplexität hinzu (siehe die ziemlich komplexe Semantik von Atom ), um die Beziehung von Funktionen zwischen Paketen zu beschreiben und zu verwalten. Guix beseitigt diese Komplexität mithilfe des Guile-Schemas zum Programmieren von Beziehungen vollständig.

Außerdem leidet Portage unter demselben Problem, da mehrere Versionen nicht ordnungsgemäß unterstützt werden, und die Flags erhöhen das Ausmaß des Problems erheblich (eine häufige Beschwerde über Portage): Wenn in einigen Abhängigkeiten inkompatible USE-Flags angewendet werden, muss der Benutzer manuell nach einer Lösung suchen. Manchmal bedeutet dies, dass die erforderliche Funktion nicht anwendbar ist (zumindest ohne umfangreiche Arbeit an Paketdefinitionen).

In der Praxis bietet Guix vorkompilierte Pakete an - eine enorme Zeitersparnis im Vergleich zu Gentoo (obwohl Portage die Verteilung von Binärpaketen unterstützt).

* BSD-Systeme (wie FreeBSD) leiden unter ähnlichen Problemen in make config.

Nix


Nix war ein historischer Durchbruch in der Betriebssystemforschung, und Guix borgte fast alle seine Ideen von dort aus. Noch heute ist Nix eines der besten aktiven Betriebssysteme. Wahrscheinlich würde Guix nicht existieren, wenn es nicht einen Fehler gäbe.

Meiner Meinung nach löst Guix das Grundproblem von Nix: Anstelle seiner eigenen domänenspezifischen Sprache (DSL) wird hier die vollwertige Lisp- basierte Programmiersprache verwendet.

"Implementieren Ihrer eigenen Programmiersprache" ist ein weit verbreitetes Missverständnis in der Softwareentwicklung. Viele Projekte, bei denen die Konfigurations- oder Programmiersprache folgende Mängel aufwies, waren hart betroffen:

  • begrenzte Ausdruckskraft und Möglichkeiten;
  • eine andere Sprache zu lernen (aber nicht sehr nützlich und universell), die einige Anstrengungen des Benutzers erfordert und somit eine Eintrittsbarriere schafft;
  • weniger lesbarer Code (zumindest zuerst);
  • oft schlechte Leistung.

Es gibt eine Vielzahl von Projekten in einheimischen oder zu eingeschränkten Sprachen:

  • XML, HTML (noch besser: S-XML )
  • Make, Autoconf, Automake, Cmake usw.
  • Bash, Zsh, Fish (noch besser: Eshell oder scsh )
  • JSON, TOML, YAML
  • Ebuilds von Portage nach Nix und viele andere Syntaxregeln zum Definieren von Betriebssystempaketen
  • Firefox bei Verwendung von XUL (da Mozilla dies abgelehnt hat) und den meisten anderen einheimischen Sprachen für Erweiterungen
  • SQL
  • Octave, R, PARI / GP, die meisten wissenschaftlichen Programme (zum Beispiel Common Lisp, Racket und andere Programme)
  • Reguläre Ausdrücke ( Empfang in Emacs , PEG in Racket usw.)
  • sed, awk und andere
  • Die meisten Konfigurationen für init, einschließlich systemd (noch besser: GNU Shepherd )
  • cron (noch besser: mcron )
  • conky (nicht vollständig programmierbar, obwohl es das am meisten erwartete Merkmal eines ähnlichen Programms sein sollte)
  • TeX, LaTeX (und alle Derivate), Asymptote (noch besser: Scribble , Skribilo - noch in der Entwicklung; ab Januar 2019 wird TeX / LaTeX immer noch als Zwischenschritt bei der Erstellung des PDF verwendet)
  • Die meisten Programme mit Konfigurationen, die keine universelle Programmiersprache verwenden.

Ein Rad neu zu erfinden ist normalerweise keine gute Idee. Wenn es um so wichtige Tools wie Programmiersprachen geht, hat dies dramatische Konsequenzen. Benötigt unnötigen Mehraufwand, treten Fehler auf. Die Community löst sich auf. Mehr konsolidierte Communities sind effizienter und nutzen ihre Zeit besser, wenn sie vorhandene, gut entwickelte Programmiersprachen verbessern.

Nicht nur für den Desktop


Guix unterstützt mehrere Architekturen (i686, x86_64, ARMv7 und AArch64 ab Januar 2019) und plant die Unterstützung weiterer Kernel außerhalb des Linux-Ökosystems (z. B. * BSD, GNU Hurd oder möglicherweise Ihr eigenes System!).

Dies macht Guix zu einem großartigen Tool für die Bereitstellung (reproduzierbarer) Server und anderer spezialisierter Systeme. Ich denke, dass Guix in eingebetteten Systemen sehr gut mit OpenWRT mithalten kann (obwohl es einige Arbeiten zur Portierung auf eingebettete Systeme erfordern wird).

Selbst reproduzierbares Live-USB


Ich erwähnte oben guix system disk-image: Zum Beispiel können Sie das aktuelle System auf einem USB-Flash-Laufwerk neu erstellen.

Auf diese Weise kann ein Klon des aktuellen Systems überall problemlos verbunden und die genaue aktuelle Umgebung (ohne Hardware) repliziert werden. Dort können Sie Benutzerdaten eingeben: PGP-Schlüssel, E-Mail. Alles ist sofort nach dem Laden verfügbar.

Offensichtlich funktioniert das Klonen weiter mit der Maschine, auf der der Klon installiert ist: Anstelle des "nackten" Guix wird ein vollwertiges Betriebssystem bereitgestellt, das betriebsbereit ist.

Ersetzen anderer Paketmanager


Emacs, Python, Ruby ... und Power guix environment


Guix kann jeden Paketmanager ersetzen, einschließlich Paketmanager für Programmiersprachen. Es hat mehrere Vorteile:

  • Ubiquitäre Reproduzierbarkeit.
  • Allgegenwärtige Rückschläge.
  • Sie müssen keinen weiteren Paketmanager lernen.

An dieser Stelle müssen Sie erwähnen guix environment. Dieser Befehl richtet eine temporäre Umgebung nur mit einer bestimmten Gruppe von Paketen ein, z virtualenv. Das Killer-Feature ist, dass es für alle Sprachen und ihre Kombinationen universell ist.

Texlive


(Haftungsausschluss: Ab Januar 2019 wird das TeXlive-Montagesystem für Guix geändert.)

TeXlive erhielt eine besondere Erwähnung, weil es besonders schrecklich ist :), was erneut die rettende Rolle von Guix bestätigt!

Die meisten Unix-basierten Betriebssysteme vertreiben TeXlive normalerweise als Teil einer Reihe von Paketen. In Arch Linux gibt es beispielsweise ein Dutzend davon. Wenn Sie einige TeX-Pakete aus verschiedenen Sätzen benötigen, bleibt Arch Linux keine andere Wahl, als Tausende (möglicherweise unnötige) Pakete zu installieren, und TeXlive beansprucht viel Platz: Hunderte von Megabyte.

Alternativ können Sie TeXlive manuell installieren, aber seien wir ehrlich: tlmgr - Nur ein schlechter Paketmanager, und es erfordert mühsame zusätzliche Arbeit.

Mit Guix werden TeXlive-Pakete wie alles andere auch separat installiert, damit Sie Ihre eigenen TeXlive-Pakete behalten oder sogar Spezifikationen für die virtuelle Umgebung erstellen können, um bestimmte Dokumente zu kompilieren.

Core


Viele Betriebssysteme bieten nur eingeschränkte Unterstützung für nicht standardmäßige Kernel. Wenn Benutzer vom Standardkernel abweichen möchten, muss der nicht standardmäßige Kernel manuell gepflegt werden.

Es ist bekannt, dass Gentoo einen Benutzerkern als empfohlenen (obligatorischen?) Installationsschritt "benötigt". Dies ist jedoch kaum eine zwingende Voraussetzung, und die Benutzer müssen die Konfiguration des Kernels selbst unterstützen.

In Guix ist der Kernel wie jedes andere reguläre Paket vollständig anpassbar. Sie können alles anpassen und die Kernel-Konfigurationsdatei in die Paketdefinition übertragen.

Zum Beispiel sind die folgenden Definitionen eines nicht freien Linux-Kernels mit einem Treiber iwlwifi(Warnung: Ich empfehle dringend, keine proprietären Treiber zu verwenden, da diese eine ernsthafte Bedrohung für Ihre Privatsphäre und Freiheit darstellen):

(define-module (ambrevar linux-custom)
  #:use-module (guix gexp)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix build-system trivial)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (gnu packages linux)
  #:use-module (srfi srfi-1))
(define-public linux-nonfree
  (package
    (inherit linux-libre)
    (name "linux-nonfree")
    (version (package-version linux-libre))
    (source
     (origin
      (method url-fetch)
      (uri
       (string-append
	"https://www.kernel.org/pub/linux/kernel/v4.x/"
	"linux-" version ".tar.xz"))
      (sha256
       (base32
	"1lm2s9yhzyqra1f16jrjwd66m3jl43n5k7av2r9hns8hdr1smmw4"))))
    (native-inputs
     `(("kconfig" ,(local-file "./linux-custom.conf"))
       ,@(alist-delete "kconfig" (package-native-inputs linux-libre))))))
(define (linux-firmware-version) "9d40a17beaf271e6ad47a5e714a296100eef4692")
(define (linux-firmware-source version)
  (origin
    (method git-fetch)
    (uri (git-reference
	  (url (string-append "https://git.kernel.org/pub/scm/linux/kernel"
			      "/git/firmware/linux-firmware.git"))
	  (commit version)))
    (file-name (string-append "linux-firmware-" version "-checkout"))
    (sha256
     (base32
      "099kll2n1zvps5qawnbm6c75khgn81j8ns0widiw0lnwm8s9q6ch"))))
(define-public linux-firmware-iwlwifi
  (package
    (name "linux-firmware-iwlwifi")
    (version (linux-firmware-version))
    (source (linux-firmware-source version))
    (build-system trivial-build-system)
    (arguments
     `(#:modules ((guix build utils))
       #:builder (begin
		   (use-modules (guix build utils))
		   (let ((source (assoc-ref %build-inputs "source"))
			 (fw-dir (string-append %output "/lib/firmware/")))
		     (mkdir-p fw-dir)
		     (for-each (lambda (file)
				 (copy-file file
					    (string-append fw-dir (basename file))))
			       (find-files source
					   "iwlwifi-.*\\.ucode$|LICENSE\\.iwlwifi_firmware$"))
		     #t))))
    (home-page "https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi")
    (synopsis "Non-free firmware for Intel wifi chips")
    (description "Non-free iwlwifi firmware")
    (license (license:non-copyleft
	      "https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.iwlwifi_firmware?id=HEAD"))))

Benutzerdefinierter Kernel und Firmware können unter bestimmten Bedingungen in die aktuelle Systemkonfiguration (eine beliebige Datei config.scm) aufgenommen werden:

(define *lspci*
  (let* ((port (open-pipe* OPEN_READ "lspci"))
	 (str (get-string-all port)))
    (close-pipe port)
    str))
(operating-system
 (host-name "...")
 ;;...
 (kernel (cond
	   ((string-match "Network controller: Intel Corporation Wireless 8888"
			  *lspci*)
	    linux-nonfree)
	   (#t linux-libre)))
 (firmware (append (list linux-firmware-iwlwifi)
		    %base-firmware))

Führen Sie dann die folgenden Schritte aus, um die neue Systemkonfiguration zu installieren:

sudo -E guix system reconfigure config.scm

Auch ohne Installation eines neuen Kernels können Sie direkt ein Image erstellen, das zum Booten von einem USB-Laufwerk bereit ist.

Spiele


Da Guix-Pakete fortschrittliche Technologien verwenden (zum Beispiel die neuesten Versionen von Mesa) und eine vollständige Kernel-Optimierung ermöglichen, ist dies eine ideale Plattform für Spiele und insbesondere für das Packen von Spielen!

Leider ist die Spieleindustrie weit von der Philosophie der freien Software entfernt und nur sehr wenige Spiele sind Teil des offiziellen Guix-Projekts.

Obwohl Guix für freie Software steht und keine Eigentumsrechte an seinem Repository akzeptiert, machen viele erweiterte Funktionen Guix ironischerweise zu einem idealen Paketmanager für nicht freie Software.

Einige der Vorteile sind:

  • guix environmentErmöglicht Ihnen die Ausführung von Anwendungen in einem isolierten Container, der den Netzwerkzugriff einschränkt, das Dateisystem verbirgt (es besteht kein Risiko, dass ein proprietäres Programm Ihre Dateien stiehlt, z. B. eine Bitcoin-Brieftasche oder PGP-Schlüssel) und sogar Informationen auf Systemebene, z. B. den Namen benutzer Dies ist erforderlich, um ein unzuverlässiges Closed Source-Programm auszuführen.
  • Funktionale Paketverwaltung: Closed-Source-Programme halten in der Regel nicht den Test der Zeit aus und brechen zusammen, wenn eine Bibliotheksabhängigkeit ihre API ändert. Da Guix Pakete über jeder Version einer Abhängigkeit erkennt (ohne Konflikte mit dem aktuellen System), können Sie mit Guix Pakete für Closed-Source-Spiele erstellen, die für immer funktionieren.
  • Reproduzierbare Umgebung: Closed-Source-Programme werden normalerweise schlecht toleriert und können sich in Systemen mit geringfügig unterschiedlichen Abhängigkeiten unterschiedlich verhalten. Die Reproduzierbarkeitsfunktion von Guix impliziert, dass das Guix-Paket immer funktioniert, wenn es einmal ausgeführt wird (außer bei einem Hardwareausfall oder einer Änderung der Hardwarekonfiguration).

Aus diesen Gründen ist Guix das perfekte Tool zum Packen und Verteilen von Closed-Source-Spielen.

Dies ist jedoch ein großes, separates Thema, das sich am besten für einen anderen Artikel eignet.

Tipps und Tricks


Emacs-Guix


Einer der erstaunlichen Vorteile von Guix ist die Emacs-Guix-Oberfläche , mit der Sie Pakete installieren und entfernen, selektiv aktualisieren, suchen, zur Paketdefinition wechseln, Generationen verwalten, "Unterschiede" zwischen ihnen drucken und vieles mehr.

Es verfügt über Entwurfsmodi für Assemblierung und Programmierung sowie eine spezielle interaktive Umgebung. Schema REPL . Dies ist eine eindeutige Benutzeroberfläche für das Betriebssystem.

Es gibt auch die Helm System Packages- Schnittstelle , die sich teilweise mit Emacs-Guix überschneidet, aber für eine schnelle Paketsuche und schnelle Operationen scheint es mir angenehmer zu sein.

Datenspeicherung


Da Guix mehrere Generationen von Systemkonfigurationen (einschließlich des gesamten Paketverlaufs) speichert, benötigt es mehr Speicherplatz als andere Betriebssysteme.

Meiner Erfahrung nach mussten 2018 etwa einmal im Monat 25 GB gesäubert werden (unter Berücksichtigung der großen Anfragen bezüglich der Anzahl der Pakete), und die 50 GB können ein ganzes Jahr lang alleine gelassen werden.

Es ist praktisch, den Befehl zum Löschen des Speichers zu verwenden guix gc, er kann jedoch "zu viele Pakete" entfernen, d. H. Pakete, die beim nächsten Update sofort benötigt werden.

Emacs-Guix verfügt über einen Befehl m-x guix-store-dead-item, mit dem tote Pakete nach Größe sortiert und einzeln gelöscht werden können.

Wenn Sie Abhängigkeiten analysieren müssen, schauen Sie sich guix gc --referencesund an guix gc --requisites. Dies kann mit dem Ausgabeergebnis kombiniert werden.guix build ...um die verschiedenen Elemente des Abhängigkeitsdiagramms zu sehen.

Um beispielsweise den Code für eines der Erstellungsskripts anzuzeigen, öffnen Sie die vom folgenden Befehl zurückgegebene Datei:

$ guix gc --references $(guix build -d coreutils) | grep builder
/gnu/store/v02xky6f5rvjywd7ficzi5pyibbmk6cq-coreutils-8.29-guile-builder

Manifest-Generation


Es ist oft nützlich, ein Manifest aller in einem Profil installierten Pakete zu generieren .

Dies kann mit dem folgenden Guile-Skript erfolgen:

(use-modules (guix profiles)
	     (ice-9 match)
	     (ice-9 pretty-print))
(match (command-line)
  ((_ where)
   (pretty-print
    `(specifications->manifest
      ',(map manifest-entry-name (manifest-entries (profile-manifest where))))))
  (_ (error "Please provide the path to a Guix profile.")))

Führen Sie es beispielsweise im Profil aus ~/.guix-profile:

$ guile -s manifest-to-manifest.scm ~/.guix-profile

Meine Punktedateien verfolgen den Verlauf der installierten Pakete. Da ich auch die Guix-Version speichere, kann ich jederzeit in den exakten Zustand meines Systems zurückkehren.

Links


Einige Webinterfaces:


Dokumente:


Неофициальные пакеты: