Was ist der Vorteil der Art und Weise, wie Linux die Dateien installierter Programme organisiert? [geschlossen]

Unter Windows verfügt das Systemlaufwerk C:über ein Verzeichnis program_files, unter dem jedes Programm ein eigenes Verzeichnis hat.

In Linux, unter /usr/und /usr/local/gibt es /bin, /etc, /share, /srcetc.

In Windows sind also alle Dateien jedes Programms in demselben Verzeichnis gruppiert, während sich unter Linux Dateien desselben Typs aus allen Programmen befinden.

Ich bin der Meinung, dass die Art und Weise, wie Windows die installierten Programme organisiert, logischer ist als die von Linux, und daher sind installierte Programme einfacher manuell zu verwalten.

Was ist der Vorteil der Art und Weise, wie Linux die Dateien installierter Programme organisiert? Vielen Dank.

Ich habe diese Frage, wenn ich das Problem habe, wie installierte Programme in $ HOME für Shell organisiert werden, um sie beim Ausführen zu suchen. , wo ich versuche, meine Programme nach $HOMEWindows zu organisieren, aber Probleme beim Festlegen der Suchpfade für die Programme habe.

Unter Linux spiegeln die verschiedenen Speicherorte normalerweise, wenn sie gut gepflegt sind, eine gewisse Logik wider. Z.B.:

• /bin enthält die grundlegendsten Werkzeuge (Programme)
• /sbin enthält die grundlegendsten Verwaltungsprogramme

Beide enthalten die elementaren Befehle, die beim Booten und bei der grundlegenden Fehlerbehebung verwendet werden. Und hier sehen Sie den ersten Unterschied. Einige Programme sind nicht für normale Benutzer gedacht.

Dann schauen Sie doch mal rein /usr/bin. Hier sollten Sie eine größere Auswahl an Befehlen (Programmen) finden, normalerweise mehr als 1000 davon. Sie sind Standardwerkzeuge, aber nicht so wichtig wie die in /binund /sbin.

/usr/binenthält die Befehle, während sich die Konfigurationsdateien an anderer Stelle befinden. Dies trennt sowohl die funktionalen Entitäten (Programme) als auch deren Konfigurations- und andere Dateien. In Bezug auf die Benutzerfunktionalität ist dies jedoch praktisch, da die Befehle, die nicht mit anderen Elementen vermischt sind, die einfache Verwendung der PATHVariablen ermöglichen, die auf die ausführbaren Dateien verweist. Es führt auch Klarheit ein. Was auch immer ist, sollte ausführbar sein.

Schau dir meine an PATH,

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

Es gibt genau sechs Speicherorte, die die Befehle enthalten, die ich direkt aufrufen kann (dh nicht anhand ihrer Pfade, sondern anhand der Namen ihrer ausführbaren Dateien).

• /home/tomas/bin ist mein privates Verzeichnis in meinem Home-Ordner für meine privaten ausführbaren Dateien.
• /usr/local/bin Ich werde unten separat erklären.
• /usr/bin ist oben beschrieben.
• /bin ist auch oben beschrieben.
• /usr/local/gamesist eine Kombination aus /usr/local(weiter unten zu erklärenden) und Spielen
• /usr/gamessind Spiele. Um nicht mit ausführbaren Dienstprogrammen gemischt zu werden, haben sie separate Speicherorte.

Nun zu /usr/local/bin. Dieser ist etwas rutschig und wurde bereits hier erklärt: Was ist / usr / local / bin? . Um dies zu verstehen, müssen Sie wissen, dass der Ordner /usrmöglicherweise von vielen Computern gemeinsam genutzt und von einem Netzspeicherort aus bereitgestellt wird. Die dortigen Befehle werden beim Booten nicht benötigt, wie bereits erwähnt, im Gegensatz zu denen in /bin, sodass der Speicherort in späteren Phasen des Bootvorgangs bereitgestellt werden kann. Es kann auch schreibgeschützt montiert werden. /usr/local/binAuf der anderen Seite ist für die lokal installierten Programme und muss beschreibbar sein. Während viele Netzwerkcomputer möglicherweise das allgemeine /usrVerzeichnis gemeinsam nutzen, wird auf jedem von ihnen ein eigenes /usr/localim gemeinsamen Verzeichnis bereitgestellt /usr.

Schauen Sie sich zum Schluss PATHmeinen Root-Benutzer an:

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Es enthält diese:

• /usr/local/sbin, der die admin-Befehle des Typs enthält /usr/local
• /usr/local/binDies sind die gleichen, die der normale Benutzer verwenden kann. Auch hier kann ihr Typ beschrieben werden als /usr/local.
• /usr/sbin sind die nicht wesentlichen Verwaltungsdienstprogramme.
• /usr/bin sind die nicht wesentlichen Verwaltungs- und regulären Benutzerdienstprogramme.
• /sbin sind die wesentlichen Admin-Tools.
• /bin sind die wesentlichen Tools für Administratoren und reguläre Benutzer.

Heutzutage denke ich, dass dies ein historisches Erbe des klassischen UNIX ist.

In den ersten UNIX-Versionen waren die Programme nicht so groß wie heute. Die Programme bestanden häufig aus einer ausführbaren Datei, die Systembibliotheken verwendet. Daher dachte niemand an Programme, die aus einigen eigenen Bibliotheken bestehen werden. Die Hauptbibliothek war die C-Bibliothek, und jedes Programm wusste über den Speicherort Bescheid.

Außerdem wurde die UNIX-Umgebung als fertiges Produkt betrachtet (zur Vorbereitung der Dokumentation). Daher wurde der Pfad zu allen Werkzeugen festgelegt.

Einige Vorteile von festen Pfaden in HDD-Tagen (Hard Disk Drive) sind heutzutage vorhanden. Wenn FSH (File System Hierarchy) auf separate Festplattenpartitionen aufgeteilt und Partitionen mit Binärdateien und Bibliotheken in der Nähe der primären Sektoren der Festplatte platziert werden, ist der Zeitpunkt des Programmstarts etwas kürzer.

Was Sie als modernes Unix-ähnliches System sehen, ist nicht wirklich traditionell.

Normalerweise würde es ziemlich minimal /und /usrHierarchien mit nur Systemprogrammen und Programme werden dann getrennt in ein Unterverzeichnis installiert /usr/local, und dann durch die Schaffung von symbolischen Links zur Verfügung gestellt.

Ein sehr typisches Setup für GNU-Software war das Kompilieren und Installieren mit

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

Das GNU- Dienstprogramm zum Verstauen erstellt symbolische Links, um die Software auf dem Standardpfad verfügbar zu machen, ohne der PATH-Variablen Verzeichnisse hinzufügen zu müssen (wie dies bei Windows der Fall ist und sich Cruft dort ansammelt).

Moderne Linux-Distributionen liefern jedoch alles als vorgefertigte Pakete aus, sodass Programme Teil des "Systems" geworden sind. Da sich der Paketmanager um die Installation kümmert, sind keine symbolischen Verknüpfungen erforderlich, und das Trennen von Programmen dient keinem nützlichen Zweck (würde jedoch den Programmstart verlangsamen, da viele kleine Verzeichnisse gescannt werden müssten).

Wenn Sie Software in Ihrem Home-Verzeichnis installieren möchten, empfehlen wir Ihnen, auch GNU stow zu verwenden. Auf diese Weise können Sie Ihre Programme getrennt halten. Dies ist sinnvoll, wenn Sie keinen Paketmanager verwenden.

Meine traditionelle Setup für das ist ein Verzeichnis , ~/software/DIRdass ich Programme installieren , in, dann innen mit versenkbaren DIRzu erstellen ~/software/bin, ~/software/shareusw. Das bedeutet , ich nur hinzufügen müssen , ~/software/binum das PATH - Variable , um all meine installierte Software.

Verwenden:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

zu installieren, wenn das Programm den GNU-Konventionen entspricht.

Sie sprechen anscheinend über den Stil der Aufteilung einzelner Dateien nach Zweck ( /usr/binfür ausführbare Dateien, /usr/libfür Bibliotheken) und nicht nach Anwendungspaket (C ++ - Compiler in einem Verzeichnis, Bildbearbeitungsprogramme in einem anderen). Während in Unix-Systemen ein Großteil des Grundes für diese Geschichte liegt, gibt es auch aktuelle Kräfte, die dazu neigen, Unix-ähnliche Systeme dazu zu neigen: Paketmanager, die die meisten Programme auf einem System verwalten.

Unter Windows waren Anwendungen in der Vergangenheit und heute noch ziemlich dafür verantwortlich, ein eigenes Installationsprogramm und insbesondere ein Deinstallationsprogramm bereitzustellen, und registrieren sich auch jetzt noch häufig nicht bei einer zentralen Anwendungsliste. In einer solchen Situation ist es für eine Anwendung im Allgemeinen besser, ein "eigenes" Verzeichnis für so viele Dateien wie möglich zu haben. Dies hilft, Konflikte mit anderen Anwendungen zu vermeiden, obwohl dies nicht immer funktioniert (insbesondere bei DLLs ).

Unix-Systeme hingegen haben seit den 90er Jahren im Allgemeinen jeweils einen einzigen akzeptierten Paketmanager und eine Gruppe, die über diesen Paketmanager eine große Menge häufig verwendeter Software bereitstellt. (Offizielle Paketmanager für verschiedene Unices umfassen yumund aptfür Linux-Systeme, pkgsrcfür NetBSD und portsfür FreeBSD. Häufig verfügen kommerzielle Unix-Systeme auch über einen inoffiziellen, aber weithin akzeptierten Paketmanager, z. B. brewfür MacOS.)

Diese Paketmanager haben den Vorteil, dass sie jede Datei auf dem System in den verschiedenen Unterverzeichnissen verfolgen können, die sie "besitzen". Da eine einzelne Gruppe hier den Namen und den Speicherort jeder Datei zuweist, können sie alle einen kleinen Satz von Verzeichnissen verwenden, die von ihnen gemeinsam genutzt werden. Dies bietet verschiedene Vorteile, insbesondere in den Bereichen der gemeinsamen Nutzung von Dateien zwischen Anwendungen und der Verringerung der Anzahl der Pfade, die Sie für die Suche nach Bibliotheken und ausführbaren Dateien benötigen.

Trotzdem gibt es eine lange Tradition der Installation von "Separates Verzeichnis pro Anwendung" auch unter Unix, normalerweise unter dem /optVerzeichnis.