Betriebssysteme sind ein umfangreiches Thema. Hier dominiert seit Jahrzehnten ein Ansatz: Unix. In der Tat halten sich die meisten modernen Systeme, einschließlich der meisten GNU / Linux-Distributionen * BSD und macOS, an die Unix-Architektur. (Es gibt kein Windows, aber zu diesem Thema gibt es fast nichts Interessantes).
Im Jahr 2000 hielt Rob Pike einen Vortrag darüber, warum die
Erforschung von Systemsoftware nicht relevant ist . Aufgrund von Pessimismus oder Missachtung der Community scheint er die Beschwerden, die viele Unix-Benutzer im
Unix-Haters-Handbuch (1994) gesammelt haben, völlig ignoriert zu haben. Das Buch ist absichtlich sarkastisch, weist jedoch auf einige kritische Probleme mit Unix-Systemen hin - und sie wurden noch nicht gelöst.
Im Jahr 2006 veröffentlichte Elko Dositra seine Dissertation
„Ein voll funktionsfähiges Software-Bereitstellungsmodell“, in der der funktionale Nix-Paketmanager beschrieben wird. 2008 veröffentlichte der Autor
NixOS: eine voll funktionsfähige Linux-Distribution . Während NixOS viel 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 großer Fortschritt in der Systemtechnik. Dieses Betriebssystem löste nicht nur viele Unix-Probleme (einschließlich Kritik aus der oben genannten Sammlung), sondern ebnete auch den Weg für viele andere Funktionen und Studien, die in unserer Zeit eine sehr wichtige Rolle spielen können, in der Zuverlässigkeit und Sicherheit zum Hauptthema vieler wissenschaftlicher, öffentlicher und politischer Organisationen geworden sind Debatte.
Pike hat sich geirrt. Und dies beweist einen weiteren allgemeineren Punkt: Es ist wahrscheinlich klüger, keine Forschung für irrelevant zu erklären, wenn Sie die Unmöglichkeit einer weiteren Entwicklung nicht beweisen können. Und der erwähnte Bericht kann kaum als mathematischer Beweis angesehen werden. Er bekräftigte nur die Idee, dass Unix „gut genug“ ist und dass Sie sich mit seinen Funktionen und Problemen auseinandersetzen sollten.
Glücklicherweise erwies sich dieser unnötige Pessimismus als kurzsichtig und hielt nicht lange an: Nur ein paar Jahre später bewies das Nix-System, dass es falsch war.
Guix Aussehen
Guix ist der Paketmanager unter Nix und GuixSD ist das Betriebssystem, das NixOS entspricht und ein „voll programmierbares Betriebssystem“ sein soll. In der Tat ist fast alles hier 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 Änderungsgrad bewerten:
Guix Vorteile
Die Vorteile von Guix sind so revolutionär, dass der Rest des Betriebssystems im Vergleich dazu wie Legacy-Systeme aussieht.
Meine persönlichen Lieblingsmerkmale:
- Systemunverwundbarkeit: Guix führt einen Verlauf aller Änderungen sowohl auf System- als auch auf Benutzerebene. 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, hat der Benutzer oder Systemadministrator die vollständige Kontrolle. Bei anderen Unix-Varianten ist es viel schwieriger zu sagen, wann sich eine zufällige Konfigurationsdatei ändert.
- Voll programmierbares Betriebssystem: Programmieren Sie Systemkonfigurationen und verwenden Sie ein Versionskontrollsystem. Viele Systemdienste können im Guile-Schema konfiguriert werden: von udev-Regeln bis zu Xorg, PAM usw. Dank Guile kann die Konfiguration von der Hardware oder sogar vom Hostnamen abhängig gemacht werden!
- Direkter Ersatz für andere (nicht so gute) Paketmanager: Warum sollten Sie 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.
- Guile-Paketdefinitionen: Es ist viel effizienter, Paketdefinitionen in großen Mengen zu entwickeln. Es ersetzt vorteilhaft Konzepte wie Portage USE-Flags (siehe unten ).
- Verschiedene Arten der Ausgabe von Paketen: Ein Guix-Paket kann mehrere Arten der Ausgabe haben, mit denen die verschiedenen Komponenten (Bibliotheken, zusätzliche Tools, Dokumentation usw.) getrennt werden. Auf anderen Betriebssystemen (normalerweise Debian) ist es schwieriger zu erraten, welche Pakete zusammenpassen.
- Nicht multiplizierende Eingaben: In der Guix-Terminologie sind „Eingaben“ Paketabhängigkeiten. Das Benutzerprofil und die Umgebung enthalten nur Pakete, die vom Benutzer explizit installiert wurden, und nicht unbedingt deren Abhängigkeiten. Siehe beispielsweise inxi , ein Tool zum Melden von Systeminformationen: Wenn ich nur an Berichten über das inxi-System / die inxi-Ausrüstung interessiert bin, müssen
PATH nicht zwei bis drei Dutzend zusätzliche Befehlszeilentools hinzugefügt werden. Mit Guix können Sie im Benutzerprofil nur das anzeigen, was er wirklich benötigt.
- Guix-Umgebungen: Wenn Sie eine Guix-Umgebung
guix environment SOME-PACKAGES Guix richtet eine temporäre Umgebung ein, in der alle Anforderungen für SOME-PACKAGES . Dies kann verwendet werden, um die Build-Umgebung für das Projekt sowie für andere Zwecke einfach zu konfigurieren (siehe unten). Eine großartige Qualität: Mit ihnen können Sie Programme ausführen, ohne sie im Benutzerprofil zu installieren.
- Teilaktualisierungen: 100% unterstützt. Dies ist wahrscheinlich die Hauptursache für Ausfälle in Floating-Releases wie Arch Linux und Gentoo: Da dort nur mehrere Versionen gleichzeitig unterstützt werden (normalerweise nur eine), muss das gesamte System als Ganzes aktualisiert werden. Dies bedeutet mehr Verkehr mit jedem Update. Mit Guix wird jedes Paket einzeln aktualisiert.
- Kontinuierliche Integration oder warum Guix ohne Paketbetreuer funktionieren kann: Dank reproduzierbarer Assemblys und Unterstützung für Teilaktualisierungen funktioniert das Paket unter Guix „immer“ und einige Abhängigkeiten werden beim nächsten Update nicht unterbrochen (genauer gesagt, wenn die Abhängigkeit das Paket zerstört). dann ist dies trivial behoben, um die richtige Version der Bibliothek zu verwenden). So kann die Arbeit mit Paketen auf „Montagefarmen“ übertragen werden (eine auf Hydra aus dem Nix-Projekt, die andere auf Cuirass ). Vergleichen Sie dies mit den meisten anderen GNU / Linux-Communities, bei denen Dutzende von Betreuern Tausende von Paketen aktualisieren müssen. Dieser Ansatz lässt sich nicht skalieren: Letztendlich stagnieren diese Verteilungen bei einigen tausend Paketen. In Guix kann die Anzahl der Pakete leise wachsen, ohne dass ein Zusammenbruch befürchtet wird. Gleichzeitig können Mitwirkende effizienter eingesetzt werden.
In Guix ist das Erstellen aus der Quelle genauso einfach. Tatsächlich ist dies für den Endbenutzer nicht so wichtig: Guix kann problemlos von den Quellen zur Assembly zurückkehren, wenn das fertige Paket nicht verfügbar ist.
guix import und guix refresh : Automatisch und rekursiv guix refresh erstellen oder aktualisieren. Hunderte von Definitionen werden gleichzeitig verarbeitet. Solche Funktionen unterstreichen die Vorteile einer echten Programmiersprache im Betriebssystem. Was auf den meisten Betriebssystemen eine schwierige Aufgabe ist, ist in Guix relativ einfach zu implementieren.
- Guix-Kanäle: eine meiner Lieblingsfunktionen! Für 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-Kanäle ersetzen gewinnbringend AUR-Overlays von Arch Linux und Gentoo, sodass jeder seine Paketdefinitionen beispielsweise über Git-Repositorys verteilen kann. Dies garantiert wiederum vollständige Transparenz (Rückschläge, Verlauf 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 können nicht wiedergegeben werden und sind in Wirklichkeit undurchsichtige Binärdateien, was für Benutzer, denen Vertrauen, Sicherheit und Datenschutz wichtig sind, grundsätzlich nicht akzeptabel ist . Im Gegenteil, Guix-Packs sind absolut klar, reproduzierbar und transparent.
guix system vm und guix system disk-image : Guix macht es trivial, das gesamte aktuelle System als Live-USB, innerhalb der VM oder auf einem Remote-Computer abzuspielen.
Guix im Vergleich zu Wettbewerbern
Debian, Arch Linux und die meisten anderen GNU / Linux-Distributionen
GNU / Linux-Distributionen bieten normalerweise nicht die oben genannten Vorteile von Guix. Die kritischsten Mängel:
- Mangelnde Unterstützung für mehrere Versionen von Paketen oder "Abhängigkeitshölle". Angenommen, das neueste mpv erfordert ein neues ffmpeg, aber das Aktualisieren von ffmpeg bricht die meisten anderen Programme. Wir befinden uns in einem Dilemma: Entweder brechen Sie einige Pakete oder speichern Sie alte Versionen. Schlimmer noch, es gibt möglicherweise überhaupt kein geeignetes Paket oder es gibt keine Betriebssystemunterstützung. Dieses Problem tritt bei den meisten Distributionen auf, die die Erfüllung ihrer Hauptaufgabe nicht garantieren können: ein Paket für jedes Programm.
- Kritische Abhängigkeit von Betreuern. Nicht funktionierende Paketverwaltung bedeutet, dass alle Pakete ständig auf Kompatibilität getestet werden müssen. Dies ist eine Menge harte Arbeit für diejenigen, denen diese Aufgabe anvertraut wurde. In der Praxis bedeutet dies, dass die Qualität des Paketmanagements stark von den Menschen abhängt. Eine Verteilung ohne eine ausreichende Anzahl von Betreuern wird unweigerlich leiden und möglicherweise sterben. Dieser Arbeitsaufwand ist normalerweise nicht skaliert 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
Gentoo und andere Distributionen mit dem
Portage- Paketmanager haben eine berühmte Funktion:
USE-Flags zum Aktivieren von Funktionen im gesamten System (z. B. Stummschalten, Aktivieren der GUI-Unterstützung usw.).
USE-Flags machen es trivial, Funktionen des Autors des Pakets zu aktivieren oder zu deaktivieren (und der Vorteil ist, dass sie getestet werden). Auf der anderen Seite können Sie mit Portage keine Funktionen konfigurieren, die nicht im Voraus geplant wurden. Wenn ein Paket beispielsweise einen zusätzlichen Sound hat, der Autor jedoch das entsprechende Flag nicht gesetzt hat, kann der Benutzer nichts dagegen tun (außer eine neue Paketdefinition zu erstellen).
Im Vergleich dazu können Sie mit Guix alles vollständig anpassen, allerdings mit etwas mehr Schema-Code. Im Pseudocode sieht es ungefähr so aus:
(loop-over (TARGET-PACKAGES) (package (inherit TARGET) (changes-here... including patches, build options, etc.))
Ein solcher Code-Batch legt die Definitionen für
TARGET-PACKAGES mit 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 Paketen vorgenommen werden können.
Ich habe Gentoo geliebt, aber nach dem Wechsel zu Guix wurden die Einschränkungen von Portage offensichtlich.
- Das USE-Flag-System erlaubt keine Anpassung ungeplanter beliebiger Funktionen.
- Die Verwendung von Flags fügt eine ganze Klasse von Komplexität hinzu (siehe die ziemlich komplizierte Atomsemantik ), 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.
Darüber hinaus leidet Portage unter demselben Problem, da mehrere Versionen nicht ordnungsgemäß unterstützt werden, und Flags erhöhen das Ausmaß des Problems erheblich (eine häufige Beschwerde über Portage): Wenn inkompatible USE-Flags für einige Abhängigkeiten gelten, muss der Benutzer manuell nach einer Lösung suchen. Manchmal bedeutet dies, dass die erforderliche Funktion nicht anwendbar ist (zumindest ohne wesentliche 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 (z. B. FreeBSD) leiden unter ähnlichen Problemen bei
make config .
Nix
Nix war ein historischer Durchbruch in der Betriebssystemforschung, und Guix hat fast alle seine Ideen von dort übernommen. Heute ist Nix immer noch eines der besten aktiven Betriebssysteme. Guix hätte wahrscheinlich nicht existiert, wenn es nicht einen Fehler gegeben hätte.
Meiner Meinung nach löst Guix das Hauptproblem von Nix: Anstelle seiner eigenen
domänenspezifischen Sprache (DSL) wird hier eine vollwertige Lisp-basierte Guile Scheme-Programmiersprache verwendet.
"Implementieren Ihrer eigenen Programmiersprache" ist ein weit verbreitetes Missverständnis in der Softwareentwicklung. Dies traf viele Projekte, bei denen die Konfigurations- oder Programmiersprache unter folgenden Nachteilen litt:
- begrenzte Ausdruckskraft und Fähigkeiten;
- Eine andere Sprache zum Lernen (aber nicht sehr nützlich und universell), die vom Benutzer einige Anstrengungen erfordert und somit eine Eintrittsbarriere schafft;
- weniger lesbarer Code (zumindest zuerst);
- oft schlechte Leistung.
Es gibt so viele Projekte in einheimischen oder zu begrenzten Sprachen:
- XML, HTML (noch besser: S-XML )
- Make, Autoconf, Automake, Cmake usw.
- Bash, Zsh, Fish (noch besser: Eshell oder scsh )
- JSON, TOML, YAML
- Portage zu Nix Ebuild und vielen anderen Syntaxregeln für Betriebssystempaketdefinitionen
- Firefox bei Verwendung von XUL (Mozilla hat es inzwischen aufgegeben) und den meisten anderen einheimischen Sprachen für Erweiterungen
- SQL
- Octave, R, PARI / GP, die meisten wissenschaftlichen Programme (z. B. Common Lisp, Racket und andere Programme)
- Reguläre Ausdrücke ( rx in Emacs , PEG in Racket usw.)
- sed, AWK usw.
- Die meisten Init-Konfigurationen, einschließlich systemd (noch besser: GNU Shepherd )
- cron (noch besser: mcron )
- conky (nicht vollständig programmierbar, obwohl dies 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 noch als Zwischenschritt bei der Erstellung des PDF verwendet)
- Die meisten Programme mit Konfigurationen, die keine universelle Programmiersprache verwenden.
Das Rad neu zu erfinden ist normalerweise keine gute Idee. Wenn es um so wichtige Tools wie Programmiersprachen geht, hat dies sehr dramatische Konsequenzen. Unnötige zusätzliche Anstrengungen sind erforderlich, Fehler treten auf. Die Community zerstreut sich. Konsolidiertere 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, weitere Kerne außerhalb des Linux-Ökosystems zu unterstützen (sagen wir * BSD,
GNU Hurd oder vielleicht 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 konkurrieren kann (obwohl die Portierung auf eingebettete Systeme einige Arbeit erfordert).
Selbstreproduzierendes Live-USB
Oben habe ich das
guix system disk-image : So können Sie beispielsweise das aktuelle System auf einem USB-Flash-Laufwerk neu erstellen.
Somit ist ein Klon des aktuellen Systems einfach überall zu verbinden und die genaue aktuelle Umgebung (abzüglich der Hardware) zu replizieren. Dort können Sie Benutzerdaten einfügen: PGP-Schlüssel, E-Mail. Alles ist sofort nach dem Download verfügbar.
Offensichtlich funktioniert das Klonen weiter von dem Computer entfernt, auf dem der Klon installiert ist: Anstelle des „nackten“ Guix wird ein vollwertiges Betriebssystem bereitgestellt, das betriebsbereit ist.
Andere Paketmanager ersetzen
Emacs, Python, Ruby ... und die Kraft der guix environment
Guix kann jeden Paketmanager ersetzen, einschließlich Paketmanager von Programmiersprachen. Es hat mehrere Vorteile:
- Allgegenwärtige Reproduzierbarkeit.
- Allgegenwärtige Rollbacks.
- Sie müssen keinen anderen Paketmanager lernen.
An dieser Stelle sollten Sie die
guix environment erwähnen. Dieser Befehl richtet eine temporäre Umgebung mit nur einem bestimmten Satz von Paketen wie
virtualenv . Das Killer-Feature ist, dass es für alle Sprachen und ihre Kombinationen universell ist.
Texlive
(Haftungsausschluss: Ab Januar 2019 wird das TeXlive-Build-System für Guix neu gestaltet.)
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 Paketsuite. Zum Beispiel hat Arch Linux ein Dutzend davon. Wenn Sie einige TeX-Pakete aus verschiedenen Sets benötigen, bleibt Arch Linux keine andere Wahl, als Tausende (möglicherweise unnötige) Pakete zu installieren, und TeXlive nimmt
viel Platz ein: Hunderte von Megabyte.
Alternativ können Sie TeXlive manuell installieren, aber seien wir
tlmgr :
tlmgr ist nur ein schlechter Paketmanager und erfordert mühsame zusätzliche Arbeit.
Mit Guix werden TeXlive-Pakete wie alles andere separat installiert. Auf diese Weise können Sie Ihre eigenen TeXlive-Pakete verwalten oder sogar Spezifikationen für die virtuelle Umgebung zum Kompilieren bestimmter Dokumente erstellen.
Der Kern
Viele Betriebssysteme bieten nur begrenzte Unterstützung für benutzerdefinierte Kernel. Wenn Benutzer vom Standardkernel abweichen möchten, muss der nicht standardmäßige Kernel manuell verwaltet werden.
Es ist bekannt, dass Gentoo den Benutzerkern als empfohlenen (obligatorischen?) Installationsschritt "benötigt". Dies ist jedoch kaum eine Voraussetzung, und die Benutzer selbst müssen die Kernelkonfiguration unterstützen.
In Guix ist der Kernel wie jedes andere ein vollständig anpassbares reguläres Paket. Sie können alles konfigurieren und die Kernel-Konfigurationsdatei an die Paketdefinition übergeben.
Im Folgenden finden Sie beispielsweise Definitionen eines nicht freien Linux-Kernels mit dem
iwlwifi Treiber (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"))))
Der benutzerdefinierte Kernel und die Firmware können bedingt in die aktuelle Systemkonfiguration aufgenommen werden (einige
config.scm Dateien):
(define *lspci* (let* ((port (open-pipe* OPEN_READ "lspci")) (str (get-string-all port))) (close-pipe port) str)) (operating-system (host-name "...")
Führen Sie dann die folgenden Schritte aus, um eine neue Systemkonfiguration zu installieren:
sudo -E guix system reconfigure config.scm
Ohne einen neuen Kernel zu installieren, können Sie direkt ein Image erstellen, das zum Booten von einem USB-Laufwerk bereit ist.
Die Spiele
Da Guix-Pakete fortschrittliche Technologien verwenden (z. B. die neuesten Versionen von Mesa) und eine vollständige Kernel-Optimierung ermöglichen, ist dies eine ideale Plattform für Spiele und insbesondere zum
Verpacken von Spielen!
Leider ist die Spielebranche weit von einer Philosophie der freien Software entfernt, und nur sehr wenige Spiele werden im Rahmen des offiziellen Guix-Projekts verpackt.
Obwohl Guix freie Software bevorzugt und keine Eigentumsrechte in seinem Repository akzeptiert, machen viele erweiterte Funktionen Guix ironischerweise zum idealen Paketmanager für proprietäre Software.
Einige der Vorteile:
guix environment können Sie jede Anwendung in einem isolierten Container ausführen, der den Zugriff auf das Netzwerk einschränkt, das Dateisystem verbirgt (es besteht kein Risiko, dass das proprietäre Programm einige Ihrer Dateien stiehlt, z. B. Bitcoin Wallet- oder PGP-Schlüssel) und sogar Informationen auf Systemebene, z als Benutzername. Dies ist erforderlich, um ein unzuverlässiges Closed-Source-Programm auszuführen.
- Funktionale Paketverwaltung: Closed-Source-Programme bestehen normalerweise nicht den Test der Zeit und brechen ab, wenn eine Bibliotheksabhängigkeit ihre API ändert. Da Guix Pakete über jede Version einer Abhängigkeit definiert (ohne Konflikte mit dem aktuellen System), können Sie mit Guix Pakete für Spiele mit geschlossenem Quellcode erstellen, die für immer funktionieren.
- Reproduzierbare Umgebung: Closed-Source-Programme sind im Allgemeinen schlecht portiert und können sich auf Systemen mit leicht unterschiedlichen Abhängigkeiten unterschiedlich verhalten. Die Reproduzierbarkeitseigenschaft von Guix impliziert, dass das Guix-Paket immer funktioniert, wenn es einmal funktioniert (mit Ausnahme eines Hardwareausfalls oder einer Änderung der Hardwarekonfiguration).
Aus diesen Gründen ist Guix ein ideales Tool zum Verpacken und Verteilen von Closed-Source-Spielen.
Dies ist jedoch ein großes separates Thema, das besser für einen anderen Artikel übrig bleibt.
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 übergehen, Generationen verwalten, die „Unterschiede“ zwischen ihnen drucken und vieles mehr.
Es verfügt über Entwicklungsmodi für Assemblierung und Programmierung sowie eine spezielle interaktive Umgebung namens Scheme
REPL . Dies ist eine einzigartige Benutzeroberfläche für das Betriebssystem.
Es gibt auch die
Helm System Packages- Oberfläche, die sich teilweise mit Emacs-Guix überschneidet, aber für schnelle Paketsuchen und schnelle Operationen für mich angenehmer erscheint.
Datenspeicherung
Da Guix mehrere Generationen von Systemkonfigurationen speichert (einschließlich des gesamten Paketverlaufs), benötigt es mehr Speicherplatz als andere Betriebssysteme.
Nach meiner Erfahrung musste die 25-GB-Partition im Jahr 2018 etwa einmal im Monat gereinigt werden (unter Berücksichtigung der großen Anforderungen an die Anzahl der Pakete), und die 50-GB-Partition kann ein ganzes Jahr lang unbeaufsichtigt bleiben.Es ist praktisch, den Befehl zum Bereinigen des Speichers zu verwenden guix gc, aber es können "zu viele Pakete" entfernt werden, dh Pakete, die beim nächsten Update sofort benötigt werden.Emacs-Guix verfügt über einen Befehl mx 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 der Ausgabe kombiniert werden guix build ..., um die verschiedenen Elemente des Abhängigkeitsgraphen anzuzeigen.Öffnen Sie beispielsweise die vom folgenden Befehl zurückgegebene Datei, um den Code für eines der Build-Skripte anzuzeigen: $ guix gc --references $(guix build -d coreutils) | grep builder /gnu/store/v02xky6f5rvjywd7ficzi5pyibbmk6cq-coreutils-8.29-guile-builder
Manifestierte 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 in Ihrem Profil aus ~/.guix-profile: $ guile -s manifest-to-manifest.scm ~/.guix-profile
Meine Punktedateien verfolgen den Verlauf der installierten Pakete. Da ich auch die Version von Guix behalte, kann ich jederzeit in der Vergangenheit zum genauen Status meines Systems zurückkehren.Referenzen
Einige Webschnittstellen:Dokumente:Inoffizielle Pakete: