Was sind die Alternativen zur FHS?

Ich bin seit über 15 Jahren ein langjähriger Linux-Benutzer, aber eine Sache, die ich leidenschaftlich hasse, ist die vorgeschriebene Verzeichnisstruktur. Ich mag sie nicht , dass /usr/binder Abladeplatz für Binärdateien oder Bibliotheken in ist /usr/lib, /usr/lib32, /usr/libx32, /lib, /lib32etc ... Random Sachen in /usr/shareetc. Es ist dumm und verwirrend. Aber manche mögen es und schmecken anders.

Ich möchte eine Verzeichnisstruktur, in der jedes Paket isoliert ist. Stellen Sie sich stattdessen vor, der Media Player-Drache hätte eine eigene Struktur:

/software/dragon
/software/dragon/bin/x86/dragon
/software/dragon/doc/README
/software/dragon/doc/copyright
/software/dragon/lib/x86/libdragon.so

Oder:

/software/zlib/include/zlib.h
/software/zlib/lib/1.2.8/x86/libz.so
/software/zlib/lib/1.2.8/x64/libz.so
/software/zlib/doc/examples/...
/software/zlib/man/...

Du verstehst den Punkt. Welche Möglichkeiten habe ich? Gibt es eine Linux-Distribution, die so etwas wie mein Schema verwendet? Kann eine Distribution so geändert werden, dass sie funktioniert, wie ich es möchte (Gentoo ??) oder brauche ich LFS? Gibt es in diesem Bereich Stand der Technik? Wie Publikationen darüber, ob das Schema machbar oder nicht machbar ist?

Nicht auf der Suche nach OS X. :) Aber OS X-inspiriert ist völlig in Ordnung.

Edit : Ich habe keine Ahnung , wie PATH, LD_LIBRARY_PATHund andere Umgebungsvariablen , die auf einem kleinen Satz von Pfaden abhängen soll aus arbeiten. Ich denke, wenn ich den KDE-Editor Kate installiert /software/kate/bin/x86/bin/katehabe, muss ich den vollständigen Pfad zur Binärdatei eingeben, um sie zu starten. Wie es bei dynamischen Bibliotheken und dlopenAufrufen funktionieren soll, weiß ich nicht, aber es kann kein unlösbares technisches Problem sein.

Zunächst ein erster Hinweis zu Interessenkonflikten: Ich bin ein langjähriger GoboLinux-Entwickler.

Zweitens ein erster Anspruch an Domain-Expertise: Ich bin ein langjähriger GoboLinux-Entwickler.

Derzeit werden einige unterschiedliche Strukturen verwendet. GoboLinux hat eine, und Tools wie GNU Stow , Homebrew usw. verwenden etwas ganz Ähnliches (hauptsächlich für Benutzerprogramme). NixOS verwendet auch eine nicht standardmäßige Hierarchie für Programme und Lebensphilosophie. Es ist auch ein recht häufiges LFS-Experiment.

Ich werde all diese beschreiben und dann aus Erfahrung kommentieren, wie das in der Praxis funktioniert ("Machbarkeit"). Die kurze Antwort lautet: Ja, es ist machbar, aber man muss es wirklich wollen .

GoboLinux

GoboLinux hat eine Struktur, die Ihrer Beschreibung sehr ähnlich ist. Die Software wird installiert unter /Programs: /Programs/ZSH/5.0.8Enthält alle zu ZSH 5.0.8 gehörenden Dateien in den üblichen Verzeichnissen bin/ lib/ .... Die System-Tools erstellen Symlinks zu diesen Dateien unter einer /System/LinksHierarchie, die auf /usr¹ abgebildet wird. Die PATHVariable enthält nur das einzige einheitliche ausführbare Verzeichnis und LD_LIBRARY_PATHwird nicht verwendet. Es können mehrere Softwareversionen gleichzeitig vorhanden sein, es wird jedoch nur eine Datei mit einem bestimmten Namen ( bin/zsh) gleichzeitig aktiv verknüpft. Sie können auf die anderen über ihre vollständigen Pfade zugreifen.

Eine Reihe von Kompatibilitäts Symlinks besteht auch, so /binund /usr/binKarte mit dem Unified Executables - Verzeichnis, und so weiter. Dies erleichtert der Software zur Laufzeit das Leben. Mit einem Kernel-Patch, GoboHide, können diese Kompatibilitätssymlinks aus Dateilisten ausgeblendet werden (sie können jedoch weiterhin verwendet werden).

Entgegen einer anderen Antwort müssen Sie den Kernel-Code nicht ändern: GoboHide ist rein kosmetisch und der Kernel ist im Allgemeinen nicht von User-Space-Pfaden abhängig². GoboLinux verfügt zwar über ein spezielles Init-System, dies ist jedoch nicht erforderlich.

Der Slogan war schon immer "das Dateisystem ist der Paketmanager", aber es gibt einigermaßen gewöhnliche Paketverwaltungstools im System. Sie können alles , was mit tun cp, rmund ln, though.

Wenn Sie GoboLinux verwenden möchten, sind Sie herzlich willkommen. Ich werde jedoch bemerken, dass es sich um ein kleines Entwicklungsteam handelt und Sie wahrscheinlich feststellen werden, dass einige Software, die Sie möchten, nicht gepackt ist, wenn sie zuvor noch niemand verwenden wollte. Die gute Nachricht ist, dass es im Allgemeinen ziemlich einfach ist, ein Programm für das System zu erstellen (ein Standard- "Rezept" besteht aus drei Zeilen). Die schlechte Nachricht ist, dass es manchmal unangenehm kompliziert ist, worauf ich im Folgenden näher eingehen werde.

Veröffentlichungen

Es gibt einige "Veröffentlichungen". Ich habe auf der linux.conf.au 2010 einen Vortrag über das gesamte System gehalten, der alles allgemein abdeckt, was als Video verfügbar ist: ogv mp4 (auch auf Ihrem lokalen Linux Australia-Spiegel); Ich schrieb auch meine Notizen in Prosa. Auf der GoboLinux-Website gibt es auch einige ältere Dokumente, darunter das berühmte " Ich bin nicht ahnungslos " , das sich mit einigen Einwänden und Problemen befasst. Ich denke, wir sind heutzutage alle ein bisschen weniger verrückt und ich vermute, dass eine zukünftige Veröffentlichung als Basis für die Symlinks dienen wird./usr

NixOS

NixOS legt jedes installierte Programm in einem eigenen Verzeichnis unter /nix/store. Diese Verzeichnisse haben ungefähr den Namen /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/- es gibt einen kryptografischen Hash, der die gesamten Abhängigkeiten und Konfigurationen darstellt, die zu diesem Programm führen. In diesem Verzeichnis befinden sich alle zugehörigen Dateien mit mehr oder weniger normalen Speicherorten vor Ort.

Sie können auch mehrere Versionen gleichzeitig verwenden. Mit NixOS ist eine ganze Philosophie der reproduzierbaren Konfiguration verbunden: Es ist im Wesentlichen ein Konfigurationsmanagementsystem von Anfang an eingebaut. Es beruht auf einigen Manipulationen der Umgebung, um dem Benutzer die richtige Welt der installierten Programme zu präsentieren.

LFS

Es ist ziemlich einfach, Linux From Scratch zu durchlaufen und genau die Hierarchie einzurichten, die Sie möchten: Erstellen Sie einfach die Verzeichnisse und konfigurieren Sie alles, um es am richtigen Ort zu installieren. Ich habe es einige Male beim Erstellen von GoboLinux-Experimenten gemacht, und es ist nicht wesentlich schwieriger als einfaches LFS. In diesem Fall müssen Sie die Kompatibilitätssymlinks erstellen. Andernfalls ist es wesentlich schwieriger, aber die sorgfältige Verwendung von Verbindungselementen könnte dies wahrscheinlich vermeiden, wenn Sie dies wirklich möchten.

Ich habe das Gefühl , dass es irgendwann einen LFS-Hinweis dazu gab , aber ich kann ihn jetzt anscheinend nicht finden.

Auf Machbarkeit

Das Besondere an der FHS ist, dass es sich um einen Standard handelt, der sehr verbreitet ist und im Großen und Ganzen die zum Zeitpunkt der Erstellung vorhandene Verwendung widerspiegelt. Die meisten Benutzer werden sich niemals auf einem System befinden, das im Wesentlichen nicht diesem Layout folgt. Das Ergebnis ist, dass viele Software-Anwendungen latente Abhängigkeiten haben, die niemand bemerkt, oftmals völlig ungewollt.

Alle diese Skripte mit #!/bin/bash? Nicht gut, wenn du keinen Bash da hast. Aus diesem Grund verfügt GoboLinux über alle diese Kompatibilitätssymlinks. es ist nur praktisch. Eine Menge Software funktioniert entweder zur Erstellungszeit oder zur Laufzeit unter einem nicht standardmäßigen Layout nicht und erfordert dann Patches, um sie zu korrigieren, was häufig recht aufdringlich ist.

Ihr grundlegendes Autoconf-Programm installiert sich normalerweise von selbst, wo immer Sie es mitteilen, und es ist ziemlich einfach, den Prozess der Übergabe des richtigen Programms zu automatisieren --prefix. Andere Build-Systeme sind nicht immer so nett, entweder indem sie absichtlich in der Hierarchie gebacken werden oder indem führende Autoren nicht-portable Konfigurationen schreiben. CMake ist ein Haupttäter in der letzteren Kategorie. Das bedeutet, dass man, wenn man in dieser Welt leben will, bereit sein muss, eine Menge fummeliger Vorarbeit in den Build-Systemen anderer Leute zu leisten. Es ist sehr mühsam, generierte Dateien während der Kompilierung dynamisch zu patchen.

Die Laufzeit ist wieder eine andere Sache. Viele Programme gehen davon aus, wo sich ihre eigenen oder fremden Dateien entweder relativ zu ihnen oder absolut befinden. Wenn Sie anfangen, Symlinks zu verwenden, um eine konsistente Ansicht darzustellen, sind viele Programme mit Fehlern behaftet (oder manchmal mit möglicherweise korrektem Verhalten, das für Sie nicht hilfreich ist). Beispielsweise kann ein Tool foobarerwarten, die bazausführbare Datei neben oder in zu finden ../sbin. Abhängig davon, ob der Symlink gelesen wird oder nicht, können dies zwei verschiedene Stellen sein, und keine davon ist ohnehin korrekt.

Ein kombiniertes Problem ist das /usr/shareVerzeichnis. Natürlich für gemeinsam genutzte Dateien, aber wenn Sie jedes Programm in ein eigenes Präfix setzen, werden diese nicht mehr gemeinsam genutzt. Dies führt dazu, dass Programme keine Standardsymbole und dergleichen finden können. GoboLinux hat sich auf ziemlich hässliche Weise damit befasst: $prefix/shareZum Zeitpunkt der Erstellung war ein Symlink zu $prefix/Sharedund nach der Erstellung wurde der Link sharestattdessen auf das globale Verzeichnis gezeigt. Es verwendet jetzt Sandboxing zur Kompilierungszeit und das Verschieben von Dateien, um mit share(und den anderen Verzeichnissen) umzugehen , aber Laufzeitfehler beim Lesen von Links können immer noch ein Problem sein.

Suiten mit mehreren Programmen sind ein weiteres Problem. GoboLinux hat GNOME noch nie vollständig zum Laufen gebracht, und ich glaube auch nicht, dass NixOS dies getan hat, da die Layout-Abhängigkeiten so stark sind, dass es einfach nicht möglich ist, sie alle zu heilen.

Also ja, es ist machbar , aber:

• Es ist ziemlich viel Arbeit, Dinge zum Funktionieren zu bringen.
• Manche Software funktioniert möglicherweise nie.
• Die Leute werden dich lustig ansehen.

All dies kann für Sie ein Problem sein oder auch nicht.

¹ Version 14.01 verwendet /System/Index, die direkt auf abbildet /usr. Ich vermute, dass eine zukünftige Version die Links / Index-Hierarchie löschen und /usrauf der ganzen Linie verwenden kann.

² Es muss /bin/shstandardmäßig vorhanden sein.

Sowohl GoboLinux (von F.sb erwähnt) als auch GNU Guix sind Distributionen, die eine paketweise Verzeichnisstruktur zusammen mit Symlinks verwenden, um auf die "aktuelle" Version einer Binärdatei zu verweisen.

GoboLinux scheint die bessere Wahl zu sein, wenn Sie ein stabiles System wünschen. GNU Guix sagt ausdrücklich, dass es noch nicht produktionsbereit ist. GoboLinux gibt es schon seit Jahren. Ich habe es auch noch nie selbst versucht.

Überprüfen Sie den GoboLinux .

Wenn Sie möchten, dass die Verzeichnisstruktur geändert wird, sollten Sie Kernel-Code, Boot-Prozess, Verzeichnis-Runlevel basierend auf RC-Dateien und Paket-Manager sowie die Verzeichnisstruktur ändern.

Linux FHS basiert auf dem, was Sun und andere UNIX-Unternehmen Ende der 1980er Jahre beschlossen haben.

Eine wichtige Änderung war zu dieser Zeit zu verlassen /usr/local/und einzuführen /opt// { bin! lib! man! ...}

Wenn Sie nach dem Grund suchen, warum / usr / bin heute als Abladeplatz verwendet wird, glaube ich, dass GNOME eines der verantwortungsvollsten Projekte ist.

Was mit den 32-Bit- und 64-Bit-Bibliotheken passierte, scheint von FHS verursacht zu werden.

Solaris hat plattformspezifische Unterverzeichnisse in /lib /usr/binund eingeführt /usr/lib. Tun Sie Ihren Wunsch, wie Sun das Basiskonzept von 1988 erweitert hat.

Wenn jedes Paket seinen eigenen Teil des Dateisystems hatte, dann würden Sie müssen extrem groß und unhandlich Umgebungsvariablen PATH, LD_LIBRARY_PATHund ähnliches.

Natürlich können Sie Pakete auf diese Weise selbst installieren und dann mithilfe von GNU-Modulen verwalten, ob sie sich in Ihrer Umgebung befinden oder nicht. Dies tun wir für wissenschaftliche Software, für die ich arbeite, aber nicht Systemsoftware.